Bilder vergleichen -> optimiertes verfahren gesucht!

[turboPASCAL]

Hi, Ihr's.

:gruebel: Habe mal ein Sample-Projekt erstellt das die Bitmaps mit Scanline vergleicht (ca. 33,3.14159 mal schneller als ...Pixel[x, y] ;-) ) also ohne gr32 Units. (Bild 5200 x 2600 auf einem AMD 2000 MHz ca. 0,5 Sekunden)

Original-Bild wird mit Test-Bild verglichen und die Unterschiede im Preview-Bild angezeigt.
Dieser Umstand deshalb, damit nicht die Vergleichs-Zeichnungen als Fehler interpretiert werden.

Mit ScanLine zu Arbeiten ist recht einfach z.B.:

Delphi-Quellcode:

procedure ScanLine_PutPixel(Bitmap: TBitmap; X, Y: Integer; Color: TColor);
var
  Pixel: PRGBQuad;
begin
  Pixel := Bitmap.ScanLine[Y];
  Inc(Pixel, X);

  Pixel^.rgbRed := Byte(Color);
  Pixel^.rgbGreen := Byte(Color shr 8);
  Pixel^.rgbBlue := Byte(Color shr 16);
end;

Link verschoben nach: Bitmap Compare - Bitmaps vergleichen mit Scanline (wegen der Möglichkeit der Bearbeitung)

[DGL-luke]

wieso zur hölle is da ne debugger detection drin?!

macht ja in einem sourcecode-beispiel herzlich wenig sinn...

und ausserdem krieg ich immer gesagt "bilder sind gleich"...

EDIT: und vor allem wieso kann ich von der debugger detection nix im qt finden? hab ich da etwa einen trojaner aufgeschnappt? :pale:

[turboPASCAL]

:gruebel: ne' Debugger Detection ? Sowas benutze ich doch niemals nicht. :zwinker:

Hast Du auch zwei unterschiedliche Bilder geladen (mit "Pixelfehlern") ? Nicht JPEG !

(nochmal nachgeschaut und hochgeladen)

//Edit: Da war noch die Unit JPEG dabei, was nicht sein sollte.

[sniper_w]

Zitat:

und vor allem wieso kann ich von der debugger detection nix im qt finden? hab ich da etwa einen trojaner aufgeschnappt?

Möglicherweise ;).
Also bei mir geht es wunderbar, und vorallem, schnell. Mal OT, aber Delphi ist doch ein RAD Tool. :)

[scp]

Respekt, nicht schlecht!
Hab mal zum Vergleich statt des roten Rechtecks einen Ausschnitt generiert, immernoch rasant:

Delphi-Quellcode:

var
//...
  bRect: TRect;
  MemBmp: TBitmap;

//...

    if RadioButton1.Checked then  // Rotes Rechteck war hier, jetzt Ausschnitt :-)
    begin
      Inc(aRect.Right);
      Inc(aRect.Bottom);

      MemBmp := TBitmap.Create;
      try
        MemBmp.PixelFormat := PrevImage.Picture.Bitmap.PixelFormat;
        MemBmp.Width  := aRect.Right  - aRect.Left;
        MemBmp.Height := aRect.Bottom - aRect.Top ;

        bRect := Rect(0, 0, MemBmp.Width, MemBmp.Height);
        MemBmp.Canvas.CopyRect(bRect, PrevImage.Picture.Bitmap.Canvas, aRect);

        PrevImage.Picture.Bitmap.Assign(MemBmp);
      finally
        MemBmp.Free;
      end;
    end;

[turboPASCAL]

@scp Feine Sache, baue ich schnell mal noch mit ein.

[Begin OT] Und wenn man das ganze noch mit Bilder von 'ner WebCam macht, hat man ein prima Bewegungsmelder mit "Autofocus" ! [End OT]

[sniper_w]

Zitat:

Und wenn man das ganze noch mit Bilder von 'ner WebCam macht, hat man ein prima Bewegungsmelder mit "Autofocus" !

Für so etwas braucht man nicht extra Software. Wenn ich mich nicht irre, sollte man den WebCam-Processor reprogrammieren können, so ist das Ganze mit der Hardware Beschleunigung.

[turboPASCAL]

Hier gibt es keinen [SLP] Knopf, sonst hätte ich ihn noch vorangestellt. :zwinker:

SLP = Slapstick b.z.w. Sinnlos

[sniper_w]

Zitat:

Hier gibt es keinen [SLP] Knopf, sonst hätte ich ihn noch vorangestellt.

Heißt das, daß ch aus dem Bauch gesprochen habe ? :stupid: :mrgreen:

[dizzy]

Ich habe jetzt nicht geprüft ob das in der Version weiter oben schon bedacht wurde, aber die ersten Sources dürften Probleme mit nicht rechteckigen Bereichen haben, insbesondere mit Kreisen.
Grund: Der Top-Pixel wird richtig erkannt, aber der damit verbundene Left-Pixel ist ja nicht zwangsläufig der "linkeste". Analog für Bottom/Right.

Hier mal eine Variante mit der G32. Sie sollte recht fix sein, und o.g. mit abdecken.

Ich hatte zuvor eine Optimierung probiert, indem ich zunächst zu den beiden Ausgangsbildern ein Differenzbild gebildet habe, und in diesem nach nicht schwarzen Pixeln gesucht. Hintergedanke war, dass ein Vergleich auf 0 (=schwarz) schneller ist als ein tatsächlicher Vergleich. Jedoch ist die Differenzbildung an sich deutlich zu aufwändig, was diese Optimierung eher unbrauchbar macht :stupid:

(Anmerkung: Die beiden zu vergleichenden Bilder werden als gleich groß vorausgesetzt! Es findet keine Prüfung statt, so dass es dann zu einer AV kommen sollte ;))

\\edit: Das Verfahren ist umso schneller, je größer der unterschiedliche Bereich ist. Nur so nebenbei :).
Nochwas: Will man NUR die wirklich veränderten Pixel darstellen, und die gleichen die auch innerhalb des Rechtecks liegen hingegen schwarz (oder andersfarbig), so kann man zusätzlich nachher die entsprechenden Pixel der Ausgangsbilder vergleichen, und bei gleichheit den Pixel im Ausgangsbild umfärben. Dann bekommt man das kleinste Rechteck der Änderungen, indem nur Pixel nicht-schwarz sind die tatsächlich verändert sind.