bitmaps schicken

proga

geeky schrieb:

Komprimier die Bilder via jpeg und sende immer nur Bildteile die sich geändert haben, dass bringt besonders bei nem Desktop nen enormen Speed-Vorteil!

Verstehe ich das richtig, dass die Bilder verglichen werden sollen und wenn Sie nicht übereinstimmen, dann gesendet werden ? Oder muss ich nur Teile senden ? Wie soll das denn gehen ?
Und meine zweite Frage war ja, wie versende ich die ? Muss ich dann mit DIBs arbeiten ? Oder wie ?

proga

Da ist noch etwas, die Auflösung die ich verwenden werde ist 640 x 480 bei 8 Bit Farbtiefe (ist ein Industrie-PC)

nirsaja

Man muss das doch auch anders lösen können. Sonst ergibt das nie ein flüssiges Bild.(Und das ist möglich. Ich hab sowas schon mal gesehen) Man müsste die Daten von der Grafikkarte irgendwie gleich verschicken. Nochmal msdn durchwühlen...

flenders

Schau dir mal RealVNC an, da bekommst du sogar den Source-Code

nirsaja

Sieht nett aus. Es ist gerade kein Compiler in Reichweite, aber ich werd's mir heute abend mal reinziehen!

proga

Naja, habe eigentlich gehofft, hier ein paar nütliche Infos zu erhalten. Mein Ziel ist ja nicht, Quellcode zu finden, sondern zu erfahren, mit welchen Klassen, Techniken, unw. man arbeiten muss. Denn wie oben schon gesagt, das ist mein Abschlussprojekt (FIAE), und da möchte ich schon selber Hand anlegen, und nicht Quellcode von anderen benutzen.

flenders

Dann musst du dir eben mit den Infos, die du bekommen hast, selber Gedanken machen und mal in der MSDN nachschlagen
Eigentlich musst du dir eben nur ein Format ausdenken, das beide Seiten verstehen. Und um die Übertragung flüssiger zu gestalten schickst du eben evtl. nicht immer alles, sondern z.B. nur den Bereich, des aktiven Fensters oder eben die Änderungen und komprimierst die Daten

proga

Hallo felnders,
ich bin natürlich für alle Infos, die ich hier erhalten habe, sehr dankbar
Mein Problem ist folgedes: ich muss ja das Projekt planen, und darum mir Gedanken machen, 1. wie ich komprimiere, um den Durchsatz (5 x / sec) bei der gegebenen Auflösung erreichen zu können, und 2. wie ich die Daten sende, auf welche Weise, ob ich da DIB-Objekte verschicke, oder ob ich das mit Buffer mache, oder sonst wie. Habe halt noch nie Bilddateien über Ethernet übertragen. Das Komprimieren und Verschicken der Bilder (Industrie-PC) wird nicht von mir realisiert, sondern von meinen Ausbildern. Ich nehme die Daten entgegen, und zeige diese an (PC).
Ich muss meinen Ausbildern aber sagen, in welcher Form (DIBs, Buffer, oder was auch immer) ich die Daten haben will. Da ich keine Erfahrung damit habe, und meine Durchführungszeit begrenzt ist, möchte ich von Befinn an den richtigen Weg nehmen, damit ich nicht mitten in der Projektdurchführung feststelle, dass das so, wie ich mir das vorgestellt habe, nicht funktioniert.

In der MSDN kann ich natürlich auch nachgucken, aber wonach soll ich denn suchen ???

flenders

proga schrieb:

wie ich die Daten sende, auf welche Weise, ob ich da DIB-Objekte verschicke, oder ob ich das mit Buffer mache, oder sonst wie. Habe halt noch nie Bilddateien über Ethernet übertragen.

Die Übertragung von Bilddaten funktioniert eigentlich nicht anders als die Übertragung anderer Daten und als Format musst du dir eben was passendes suchen (evtl. PNG o.ä.)

proga schrieb:

Das Komprimieren und Verschicken der Bilder (Industrie-PC) wird nicht von mir realisiert, sondern von meinen Ausbildern. Ich nehme die Daten entgegen, und zeige diese an (PC).

Wie jetzt? Musst du jetzt doch nur ein Tool für die Anzeige der Bilddaten schreiben

proga schrieb:

Ich muss meinen Ausbildern aber sagen, in welcher Form (DIBs, Buffer, oder was auch immer) ich die Daten haben will. Da ich keine Erfahrung damit habe, und meine Durchführungszeit begrenzt ist, möchte ich von Befinn an den richtigen Weg nehmen, damit ich nicht mitten in der Projektdurchführung feststelle, dass das so, wie ich mir das vorgestellt habe, nicht funktioniert.

Also wird dieser Part von jemand anderem übernommen, richtig?
Das beste ist natürlich, wenn immer nur die Veränderungen übertragen werden, aber das wäre ja dann eine Sache der Gegenstelle. Ansonsten musst du dir eben überlegen, welche Anforderungen du bzgl. der Qualität stellst. Durch reduzieren der Farbtiefe und Kompression der Daten kannst du dann natürlich noch zusätzlich einiges an Bandbreite sparen. Bei einem fertiges Daten-Format (wie z.B. PNG) o.ä.) hast du eben den Vorteil, dass du auf fertigen Code zurückgreifen kannst.

proga

Hallo flenders,

danke erstmal für deine Antwort.
Also, du hast es richtig verstanden, die Komprimierung auf der Gegenseite wird nicht von mir gemacht, sondern von jemand anders. Aber alles was auf einer Seite komprimiert wird, muss auf der Gegenseite (also von mir) wieder gekomprimiert werden. Zu meinem Projekt gehört halt die Auswahl eines geeigneten Komprimierungsverfahren. Ich glaube ich habe jetzt ungefähr die Übersicht bekommen, wie und was ich machen muss. Danke für die Hilfe

WebFritzi

Ich hab mal in den Code von VNC... geschaut. Die betreiben Message-Hooking und benutzen GetUpdateRgn() in WM_PAINT, um die upzudatende Region zu senden. Hier ein Ausschnitt:

////////////////////////////////////////////////////////////////
		// Messages indicating that an area of the window needs updating
		// Uses GetUpdateRect to find out which
	case WM_PAINT:
		if (prf_use_GetUpdateRect)
		{
			HRGN region;
			region = CreateRectRgn(0, 0, 0, 0);

			// Get the affected region
			if (GetUpdateRgn(hWnd, region, FALSE) != ERROR)
			{
				int buffsize;
				UINT x;
				RGNDATA *buff;
				POINT TopLeft;

				// Get the top-left point of the client area
				TopLeft.x = 0;
				TopLeft.y = 0;
				if (!ClientToScreen(hWnd, &TopLeft))
					break;

				// Get the size of buffer required
				buffsize = GetRegionData(region, 0, 0);
				if (buffsize != 0)
				{
					buff = (RGNDATA *) new BYTE [buffsize];
					if (buff == NULL)
						break;

					// Now get the region data
					if(GetRegionData(region, buffsize, buff))
					{
						for (x=0; x<(buff->rdh.nCount); x++)
						{
							// Obtain the rectangles from the list
							RECT *urect = (RECT *) (((BYTE *) buff) + sizeof(RGNDATAHEADER) + (x * sizeof(RECT)));
							SendDeferredUpdateRect(
								hWnd,
								(SHORT) (TopLeft.x + urect->left),
								(SHORT) (TopLeft.y + urect->top),
								(SHORT) (TopLeft.x + urect->right),
								(SHORT) (TopLeft.y + urect->bottom)
								);
						}
					}

					delete [] buff;
				}
			}

			// Now free the region
			if (region != NULL)
				DeleteObject(region);
		}
		else
			SendDeferredWindowRect(hWnd);
		break;

		////////////////////////////////////////////////////////////////
		// Messages indicating full repaint of this and a different window
		// Send the new position of the window
	case WM_WINDOWPOSCHANGING:
		if (IsWindowVisible(hWnd))
			SendWindowRect(hWnd);
		break;

	case WM_WINDOWPOSCHANGED:
		if (IsWindowVisible(hWnd))
			SendDeferredWindowRect(hWnd);
		break;

Ist alles ganz gut kommentiert. Wer wirklich was reißen will, sollte da mal reinschauen, denke ich.

proga

Hi Leute,

die Software ist jetzt realisiert. Es werden in zyklischen Abständen Bildschirmdaten angefordert und als PNG-Dateien verschicht. Als nächsten Schritt möchte ich das Datenvolumen noch mehr runterfahren, indem ich, wie zuvor von euch angesprochen, nur die Differenzen an den Client schicke.

Ich habe mir folgendes überlegt: ich zerlege den Bildschirm in kleine Rechtecke. Hat sich innerhalb eines Rechecks etwas geändert, so wird dieser gesendet. Die Rechtecke werden an einem Stück gesendet. Wenn das Bild also z.B. aus 20 Rechecken besteht, und 3 davon habe sich geändert, werden diese aneinandergehängt (zusätzlich wird zu jeden Recheck die Position gespeichert), komprimiert (zlib) und verschickt.

Was meint Ihr, ist das ein guter Ansatz, oder könnte man das alles besser lösen?

flenders

Du könntest evtl. auch nur die relativen Veränderungen schicken, also nicht den neuen Farbwert, sondern nur dessen Änderung

flenders schrieb:

Du könntest evtl. auch nur die relativen Veränderungen schicken, also nicht den neuen Farbwert, sondern nur dessen Änderung

Bleibt pie mal Auge bei der gleichen Datengröße, wenn man nur Veränderungen überträgt, sollte man sich ein eigenes Verfahren machen, also ohne PNG.
Dabei könnte man die Bilddaten in den YCbCr (YUV) Farbraum wandeln, für jeden Pixel ein Y-Wert und für je 4 oder gar 8 Pixel je ein zusammgefastes Cb und Cr Wert. In einem Block giebt dann ein Y-Wert den Startwert vor, und die anderen speichern nur den Abstand zu diesem, den Y-wert kann man auch auf 7Bit kürzen, bemerkt man kaum beim Rückwandeln. Das ganze lässt sich dann auch noch weiter komprimieren, z.B. RLE. Das ganze kämme dann der JPEG Struktur nah, bzw. ähnlich MPEG.