Bildvergleich durch XOR oder OR?

[alleinherrscher]

Hi, ich suche gerade einen Weg (wie auch schon viele andere hier), Screenshots zu vergleichen, um nur die Teile eines Bildes zu übertragen, die sich geändert haben. Ich hab hier schon einige Verfahren gesehen, die z.B. die Bildpixel vergleichen oÄ.

Ich dachte aber mal an was ganz anderes, um es mir etwas einfacher zu machen. Ich gehe mal davon aus, dass ein komplett einfarbiges JPEG eine fast zu vernachlässigende Größe hat, weil das ja komprimiert ist. (ihr könnts ja mal testen, bei mir funktioniert das jedenfalls).

Okay, gehen wir also mal davon aus dass wir einen Screenshot als Bitmap haben und einen etwas älteren Referenzscreenshot (auch als Bitmap). Wenn wir jetzt diese beiden Bitmaps durch irgendeinen Befehl (und genau dieses Befehl suche ich) mit XOR (oder sowas in der Art) übereinanderlegen könnten, sodass sich 2 gleichfarbige Pixel auf den beiden Bitmaps immer zu schwarz addieren, wären alle Flächen, auf denen keine Veränderung zwischen den beiden Bitmaps stattfand komplett schwarz. Jetzt müsste man noch aus den restlichen flächen die originalfarbinformationen zurückrechnen und das ganze als JPEG komprimieren...

Was meint ihr könnte das klappen??

Grüße,
Alleinherrscher

[brechi]

Üverprüf die Pixel doch direkt ( = ) oder mach ne And verknüpfung oder nimm die Masken von BitBlt

Edit:
wenn du aus dem Bild was du bekommst etwas zurückrechen willst musst du subtrahieren oder xor verknüpfung machen

[3_of_8]

xor würde in dem Fall bedeuten, dass zwei gleiche Pixel schwarz werden.

pixel1 and (not pixel2) würden es auch tun, genauso wie not (pixel1 or pixel2).

[dizzy]

Vorsicht beim Maskieren von Bildteilen unter Verwendung von JPEG. Du wirst selbst bei recht hoher Qualität "ausgefranste" Ränder bekommen, die dann beim Zusammenfügen von Alt-Bild und Differenzbild recht unschöne Effekte nach sich ziehen können, die sich mit jedem neuen Differenzbild natürlich auch nicht grad verringern ;).

Für solche Verfahren würde ich eher zu einer Abstufung auf z.B. 8 Bit Farbe, und LZW Kompression tendieren. (GIF ist z.B. ein 8Bit LZW Format soweit ich weiss, spannender sind aber sicher eigene Implementierungen :)) Verlustbehaftete Kompression würde immer Toleranzen bei der Rückrechnung erfordern, die ihrerseits aber natürlich auch wider zu ungewünschten Ergebnissen führen können.

JPEG so wie es gebräuchlich ist, wurde ausschließlich und nur für echte Fotos entwickelt, da dort der Verlust in den meisten Fällen optisch kaum ins Gewicht fällt. Ein Desktop ist da meilenweit von entfernt, mit seinen größeren einfarbigen Flächen und geraden Linienfürungen. Das ist ganz genau nicht die Stärke und das Einsatzgebiet von JPEG.

[Duke_2004]

Genau das hatte ich schonmal woanders gesehen, ich find nur den link net mehr... :-D

Aus den beiden bmp's wurde via XOR ein Differenzbild erzeugt, bei dem die gleichen Teile Schwarz wurden. Dieses Differenzbild und das vorhergehende Vergleichsbild wieder mit XOR ergibt wieder das Originalbild...

Sollte ich den Link nochmal finden, reich ich ihn nach...

[Cicaro]

Um diese bitweise Verknüpfung von Bildern durchzuführen, kann man in der Unit Windows nach SRCCOPY (oder nach anderen bekannten Konstanten) suchen. Daneben stehen andere Parameter-Konstanten mit kurzen und präzisen Kommentaren (bsp: "Dest = Dest or Src").

Außerdem ergeben XOR und Subtrahieren nicht dieselben Differenzen. Je nach dem was ich mit diesen Referenzen vorhabe, würde ich mir überlegen welche Methode ich nehme. Für das Subtrahieren ist auch die Herangehensweise mit ScanLine empfehlenswert.