Bildübertragung bei VNC-ähnlichem Tool

[meisteralex]

bin ja gerade son vnc tool am proggen (rein aus interesse, sonst würd ich auch vnc nehmen als mir die zeit zu verbrauchen )

wollte mal nen paar generelle sachen dazu klären.

1. bring es was das bild in teile zu unterteilen ???, wird ja hier immer als gute methode angeprisen, aber ich hab mal geschaut, wenn sich das bild an einer stelle ändert und ich es z.b. in 16 teile unterteile, und die veränderung komprimiere, so hat die gesammtveränderung in der größe von 1600 x 1200 eine dateigröße von 6kb (ein Pixel geändert, png komprimiert, unveränderte bereiche sind schwarz). teile ich das bild jetzt in 16 Teile und übertragen nur den veränderten teil, hat der immerhin eine bildgröße von 2 kb, bei 400x300.
man sieht also, dass es bei png bildern eigentlich kaum was ausmach, wie groß das bild ist, sondern nur die veränderungen relevant sind.
wie relevant ist es also insgesammt, ob ich jetzt 1 großes oder 1 kleines bild übertrage, wenn dies sich nicht in den veränderten pixeln unterscheidet sondern nur in der Schwarzfläche drumrum ???

2. Was gibts sonst noch für Tricks??

3. Mit was für so genannten Hooks arbeitet VNC??

4. warum benutzt VNC die Jpeg-Kompression, wo PNG für Bildschirmübertragung ja wohl wesentlich bessere und kleinere Bilder macht

5. Jemand irgendne Ahnung das Prinzip von RDC Funktioniert, also der andere Weg den es bei Remote-Control gibt, neben dem Abfotografieren des Bildschrims ??

So ich hoffe wir können mal nen bischen darüber diskutieren.

[Christian18]

Hallo,

meinst du nicht das es schwachsinnig ist ein solches Tool zu proggen??? Gibt es doch schon überall. auch als freeware.

ein bild von desktop zu erstellen und dann über das netzwerk zu verschicken ist nicht sonderlich schwer, dass habe ich auch schon geschafft.

dann wäre aber noch die steuerung des anderen rechners. wie wilst du das machen??? ich würde mir an deiner stelle erstmal einen wasserfesten plan machen bevor man überlegt wie man bilder über das netzwerk verschicken kann. Ich habe irgendwo im Internet mal eine Anleitung gefunden wie man mit Delphi ein Remote Desktop Programm schreiben kann. Also ein kleines Tutorial.

MFG Christian18

[Aenogym]

Zitat von Christian18:

Hallo,

meinst du nicht das es schwachsinnig ist ein solches Tool zu proggen??? Gibt es doch schon überall. auch als freeware.

er hat doch geschrieben, dass er es rein aus interesse proggt. nicht, um damit berühmt zu werden oder so. man kann dabei auch was lernen....

[Christian18]

Zitat von Aenogym:

Zitat von Christian18:

Hallo,

meinst du nicht das es schwachsinnig ist ein solches Tool zu proggen??? Gibt es doch schon überall. auch als freeware.

er hat doch geschrieben, dass er es rein aus interesse proggt. nicht, um damit berühmt zu werden oder so. man kann dabei auch was lernen....

ja ist schon richtig, aber ist das nicht ein bisschen zu groß??? also jetzt das thema an sich?

edit

mein beitrag war jetzt auch nicht böse gemeint oder so. ich wollte damit lediglich ausdrücken, das er noch an die windows steuerung und so denken soll. und ich finde es ist schon ein großer aufwandt.

achso, und keine frage, lernen kann man immer was.

edit

[alzaimar]

Zitat von Christian18:

ein bild von desktop zu erstellen und dann über das netzwerk zu verschicken ist nicht sonderlich schwer, dass habe ich auch schon geschafft.

Dazu gehört ja auch nicht viel. Der Fragesteller wollte ja gar nicht wissen, wie man Bildchen verschickt, sondern wie er z.B. Bildverändungen kompakter darstellen kann...

Ich würde vielleicht gar keine starre PNG nehmen, sondern auch mal mit RLE experimentieren (in Abhängigkeit der Veränderungen). RLE dürfte bei weitgehend einfarbigen Bildern vielleicht noch besser komprimieren.

Wenn Du also die Differenz zweier Bilder dadurch darstellst, das das Differenzbild an den Stellen, wo sich Nichts verändert, z.B. schwarz ist, dann versuche doch mal Folgendes:
Merke Dir beim Vergleich das obere linke (P1) sowie das untere rechte Pixel (P2), das verändert wurde. Das Differenzbild ist nun nicht mehr genauso gross, wie das Bild selbst, sondern umfasst nur den Teil zwischen P1 und P2. Normalerweise verändert sich ja nur ein Rechteck (Fenster/Menü geht auf/zu, Progressbar bewegt sich).

Bei deinen Tests (1 Pixel differenz) ist dann das Differenzbild genau 1x1 Pixel gross, also wesentlich weniger als 2kb. Du überträgst dann P1 sowie das Differenzbild. Bei normalen Änderungen (wenn ich z.B. hier tippe), verändert sich doch auch nur ein ca. 20x20 pixel großes Bild! Wenn Du dann noch die Farbtiefe dieses Minibildes heruntersetzt (das hat doch selten mehr als 5 Farben), dann wird das nochmal richtig klein eingedampft.

Nun kann man das noch weiter treiben, und vielleicht mehrere Subbilder erstellen: Wenn sich nun z.B. 4 Pixel verändert haben, die aber weit auseinander liegen, würde mit dem o.g. Verfahren ein ziemlich grosses Differenzbild erstellt werden, das die 4 Pixel umspannt. Es kann aber besser sein, hier 4 Subbilder mit 4 Offsets zu erstellen. Ich kann mir vorstellen, das die Entscheidung, ob man ein Differenzbild noch weiter unterteilt, oder nicht, sehr interessant ist. Soweit ich weiss, wäre das eine wirkliche Innovation!

Hooks sind übrigens ein Mittel von Windows, um z.B. Mausbewegungen, Tastendrücke etc. 'abzufangen'. Ein Hook sieht immer so aus:

Delphi-Quellcode:

Procedure MyIrgendwassHook (Msg : TMessage; NextProc : THookProc);
Begin
  If ShouldHandleMessage (Msg) Then
     HandleMessage(Msg);
  NextProc (Msg)
End;

Natürlich stimmen die Parameter nicht. Im Prinzip 'hängst' (eng: to hook) Du deine Routine in eine Kette von Behandlungsroutinen rein. Das vorherige Glied der Kette ruft deine Routine auf. Du machst irgendwas mit der Message und rufst dann AUF JEDEN FALL (so die Regel) das nächste Glied der Kette auf.

Ich kenne RDC nicht, aber eine andere Möglichkeit, Änderungen des Bildschirmes zu übertragen, wäre, den Windows-Befehl (also 'ShowWindow', 'MoveWindow', SetMouse etc...) anstatt den Pixeln zu übertragen. Das kann wesentlich schneller gehen, solange Windows-eigene Fensterklassen, also klassische buttons, labels, forms, listviews etc. verwendet werden.

Und JPG verwendet VNC vielleicht deshalb, weil VNC einfach ziemlich alt ist und es PNG damals nicht gab. Vielleicht, weil das nur ne Vermutung ist. Nebenbei verwendet das ursprüngliche VNC doch kein JPG, sondern ein verlustfreies Verfahren (GIF?). Einzelne VNC-Derivate komprimieren jedoch verlustbehaftet, das sieht doch dann aber blöd aus. Ich nehme beim remote controlling (mach ich täglich mehrere Stunden) lieber weniger Farben in Kauf, als mich mit diesen JPG-Artefakten rumzuschlagen.

[meisteralex]

wow vielen dank für die ausführliche antwort.

deine vorschläge sind interessant wenn ich dich richtig verstehe willst du also den bereich eingrenzen, der sich auf dem bildschirm verändert ??
meinst du / ihr es würde sinnvoll sein, bei bildern verschiedene komprimierungen zu betrachten
also nehmen wir an ich realisieren ein bereich der sich verändert hat abgesehen davon ob wir jetzt 1 festen teilbereich, 16 feste teilbereiche, oder dynamische teilbereiche haben, auf verschiedene komprimierungsmethoden zu testen ?
nehmen wir an ich test meinen bereich auf
rle
lzw
png
jpg
nehme das kleineste setzte in den header meines "vnc"-protokolls "usekomp=xxx".
würde das noch hinhauen, oder wäre das zu rechenintensiv ?


weiterhin kam mir gerade folgende idee als ich mir nochmal den aufbau eines mpeg-streams anguckte (nein keine angst ich will nicht versuchen motion-verktoring zu proggen):
Man könnte doch im Cache des Server/Clients nicht nur das letzte Bild speichern sondern die letzten 5-10 Bilder. Der Server prüft nun bevor er ein Bild rausschickt die PixelDifferenz auf die letzten 5-10 Bilder. Nun wird nicht automatisch die Differenz zum letzten Bild gebildet sondern zu dem aus dem im Cache liegenden Bildern, wo die Differenz halt am kleisten ist.
Ist mir mal so aufgefallen, dass das sinnvoll wäre, weil wenn ich hier schreibe, dann blinkt schonmal mein miranda und ich hole es in den vordergrund, danach habe ich wieder fast das selbe bild, wie 2 bilder davor und die differenz wäre wesentlich geringer als zu meinem "miranda-bild".
man könnte das spiel noch weiter treiben und in die liste der gechacheten bilder nur bilder reinnehmen die sich in einer bestimmten pixelanzahl von dem vorangegangenen unterschieden, sprich, wenn ich hier tippe und sich nur 10 pixel verändern, kommt es nicht in den cache, da wir da ja schon so ein ähnliches haben.
ist sowas realisierbar oder zu rechenintensiv???

[Tubos]

Bitte benutze die Suche, es wurden bereits mehrere Tips hier im Forum gepostet, wie man das sehr performant machen kann.

[meisteralex]

echt ?? also so weit hat mich die suche nicht gebracht

[moritz]

Ich werfe mal den Ausdruck "named pipes" in den Thread - Damit solltest du eine schenlle Übertragungsmöglichkeit finden.

[negaH]

Was du brauchst ist eine Komprimierung die die Farbe "Transparent" ebenfalls effizient komprimieren kann.

Zb. mal RLE: dabei wird die Information übertragen Count, Farbe als Tupel. Das heist setze Count Pixels in Farbe. Für Farbe muß es jetzt einen speziellen OpCode geben der sagt "setze Count Pixels ohne Änderung" ergo: überspringe Count Pixels in der Zielbitmap.

Die Dekomprimierung lädt erstmal den aktuell gültigen Desktop und arbeitet dann die neuen Änderungen als RLE Datenstrom direkt darin ein.

Jetzt ist es aber nun so das auf einem normalen Desktop sich meistens rechteckige Bereiche verändern und deine Capture Funktion sowas mitbekommen kann. Also würdest du quasi die Region der Änderungen in einzeln zu ändernde Rechtecke zerlegen und dann diese als Metadaten und RLE Kodierung zu jedem Rechteck verpacken und senden. Das Datenformat dürfte dann inetwa so aussehen:

Code:

Anzahl Rechtecke
Prüfsumme

  X,Y,W,H des 1. Rechteckes
  RLE Daten des 1. Rechteckes

  X,Y,W,H des 2. Rechteckes
  RLE Daten des 2. Rechteckes

...
  
  X,Y,W,H des x. Rechtecks
  RLE Daten des x. Rechecks

Diese Metadaten schiebst du dann noch durch eine Huffman Komprimierung.

Beim Entkomprimieren der Daten zuerst die Huffman Dekodierung, danach die metadaten qausi als Arbeitsanweisung abarbeiten. D.h. lade Originalbild in voller Auflösung in den Speicher, springe an X,Y des 1. Rechtecks in diesen Speicher, entkomprimiere aus RLE Daten W Pixels, erhöhe Addresszeiger um Desktopbreite - W Pixel, entkomprimiere wiederum die nächsten W Pixels der 2. Pixedlzeile des Rechtecks usw. usw. bis du das H Zeilen oft gemacht hast. Dann laden nächste Daten des 2. Rechtecks bis zum X. Rechteck.

Im Grunde ist das sowas wie die Interlaced GIFs bei denen ein Bild in 2 Halbbildern übertragen wird, nur diesesmal wird ein Bild in freiwählbare recheckige Ausschnitte unterteilt und diese könnten sequientiell übertragen werden.

Du benötigst nun einen cleveren Komprimierungsalgo. der die entstandenen Differenzen zweier Bilder so in eine Kette von Rechteckigen Bereichen unterteilen kann das das beste Komprimierungsverhältnis herauskommen muß. Das heist du darfst bei wenigen Pixeländerungen nicht für jeden einzelnen Pixel ein Rechteck speichern, da ja die Koordinaten wie X,Y,W,H zb. jeweils 16 Bits benötigen. Das wäre für 1 Pixel Änderung zuviel Overhead.

[edit]
Oder noch besser:

Dein Desktop Rechteck wird rekursiv in 4 Rechtecke geteilt, diese 4 Rechtecke wiederum in 4 Rechtecke usw. usw.

Bei 800x600 also

Code:

1024x1024
 512x512
 256x256
 128x128
  64x64
  32x32
  16x16 
   8x8

Man hat also 8 verschiedene Größen von Rechtecken und ermittelt nun die Differenzen der beiden Bilder innerhalb dieser Matrix. Dein Header zur Angabe der Größe eines Rechteckes benötigt nun nur noch 3 Bytes für

[Code]
Rechteck Größe aus obiger Liste, Wert 0 bis 7
X,Y Koordinate dieses Rechtecks, X * Pixelgröße[Rechteckgröße] ergibt reale X Koordinate.
[\Code]



[/edit]


Gruß Hagen