Deshalb war der Gedanke für jeden Thread unterschiedliche Bitmaps zu verwenden. Das sie nicht Threadsave sind habe ich in der Hilfe gelesen.

Also Thread 1 bekommt screen1 und search1 und thread 2 bekommt screen2 und search2. Somit sollten sich die Canvas doch nicht ins Gehege kommen oder sehe ich das falsch ?

Grüße
s0n

Leider ist dem nicht so. Ich habe mal ein Microdemo angehängt bei dem ein paar Bitmaps parallel erzeugt `bemalt` und gespeichert werden (Pfad anpassen). Wenn man sich das Ergebnis ansieht wird klar dass Canvas nicht Threadsave ist. Über lock ließe sich das ganze verhindern, aber dann ist der Gewinn durch die Threads ebenfalls weg. Ich weiß ja nicht was genau der Vergleich machen soll, aber über Scanlines (wenn Dir das hilft) sollte es keine Probleme geben.

TBitmap und Co. wären Threadsave, wenn sie "unabhängig" verwendet werden und nichts Globales nutzen.

Aber sie verwenden intern weitere Klasseninstanten und da werden vorallen für TFont, TBrush uvm. globale Instanzen verwendet (wenn man selber nichts eigenes angibt und die Werte auf "Standard" läßt)
und da dort überall auf die selben globalen Singletons zugegrifen wird muß es zwangsläufig schief gehn, jenachdem was man mit dem Bitmap macht.



Was man machen kann, das Bitmap für die VCL blocken, wenn es z.B. in einem TPicture steckt oder sonstwie angezeigt wird,
im Hauptthread sich den Anfang der Daten (ScanLine der letzen Zeile) besorgt und im thread nur "direkt" selber darin rummalt.

Wenn man das Bild nur aufteilt, dann kann es ja auch passieren das sich der gesuchte Bereich in keinem Bild mehr befindet.

Bild:
111111
222222
333333
444444
555555
666666

Aufteilen in 2 Bilder:
111111
222222
333333

444444
555555
666666

Suche nach dem Bereich:
33
44

Habe ich mir zumindest beim Lesen so überlegt...

Zitat von user0815:

Wenn man das Bild nur aufteilt, dann kann es ja auch passieren das sich der gesuchte Bereich in keinem Bild mehr befindet.

Bild:
111111
222222
333333
444444
555555
666666

Aufteilen in 2 Bilder:
111111
222222
333333

444444
555555
666666

Suche nach dem Bereich:
33
44

Habe ich mir zumindest beim Lesen so überlegt...

jepp das ist korrekt ,deshalb ist es ratsam sagen bei 100x100 das bild nicht in 2st. 50x100 zu teilen sondern um das suchbild größer
also 2St. 55x100 der so. sodass definitiv die Suche erfolgreich ist

Aber recht hast du. Habe ich noch gar nicht dran gedacht ;(

Zitat von sonny2007:

jepp das ist korrekt ,deshalb ist es ratsam sagen bei 100x100 das bild nicht in 2st. 50x100 zu teilen sondern um das suchbild größer
also 2St. 55x100 der so. sodass definitiv die Suche erfolgreich ist

Aber recht hast du. Habe ich noch gar nicht dran gedacht ;(

.. auch das wird nit zu einer 100% Trefferquote führen.
Denn es kann immer noch sein, dass der gesuchte Bildauschnitt auf der Schnittkante der beiden Bilder sich befinden.

Meiner Meinung nach müssen bei einer zweiteilung des Bildes 3 Suchabschnitte durchgeführt werden.

1. 00..50 (erster Bildteil)
2. 51..99 (zweiter Bildteil)
3. 25..75 (Schnittmenge, abhänging von der Größe des gesuchten Bildauschnitts)

Grüße
Klaus

Zitat von user0815:

Wenn man das Bild nur aufteilt, dann kann es ja auch passieren das sich der gesuchte Bereich in keinem Bild mehr befindet.

So war das in meinen Beitrag mit den Streifen gedacht:

Beispiel: Gegeben Gesamtbild mit Höhe 120,
Ausschnitt mit Höhe 30,
3 Threads

Dann sucht Thread 1 in dem Streifen ab vertikaler Position 1 bis 30,
Thread 2 ab Position 31-60 und
Thread 3 ab Position 61-91

Zitat von user0815:

Wenn man das Bild nur aufteilt, dann kann es ja auch passieren das sich der gesuchte Bereich in keinem Bild mehr befindet.

Diese sehr richtige und wichtige Aussage macht deinen aktuellen Ansatz eigentlich komplett zunichte. So sehr, dass ich nicht mehr versuchen würde krampfhaft die Geschwindigkeit eines Verfahrens zu verbessern, dass konzeptionell bereits nicht funktioniert. Entweder du suchst im gesamten Bild Pixel für Pixel (man könnte dabei z.B. gerade und ungerade Zeilen auf 2 Threads verteilen - dann bliebe der Lerneffekt "Umgang mit Threads" erhalten), oder man greift gleich zur Autokorrelation, die genau solche Probleme sehr gut löst.

Medium hast vollkommen recht 99.47 % der Rechenzeit gehen beim kopieren des Bildausschnittes auf die temp.canvas drauf.
Das lässt mich erstmal daran zweifeln ob die Threadverwendung überhaupt notwendig ist. Denn wieso die Auswirkung versuchen auszubügeln,
wenn man doch direkt die Ursache eliminieren kann.

Werde jetzt mal versuchen es ohne Canvas versuchen. Danach das Thread trotzdem versuchen hinzubekommen ^^

Grüße s0n

So ...

erst Gehversuche. Gedanken ( straft mich nicht wenn er komplett falsch ist ) <--- noch nicht so erfahren

1.Schritt beide Bitmaps in Streams zu speichern.
2.Schritt Header Daten von beiden Bitmaps aus den Streams entfern um die reinen Bilddaten zu haben
3.Schritt in einem TempStream nur die erste Pixelreihe des Suchbildes kopieren um eine Vorsuche zu benutzen, da sonst zu lange rechnet ( getestet )
4.Schritt in einer forschleife: immer den Pixelreihenabschnitt mit dem aktuellen Pixelreihenabschnitt des Screens ( genauso lang wie Suchabschnitt ) vergleichen


anbei mal ein bißchen Code

zusammenfalten · markieren

Delphi-Quellcode:

    ScreenBMP.PixelFormat := SearchBMP.PixelFormat ;

    SearchBMP.SaveToStream(SearchStream);
    ScreenBMP.SaveToStream(ScreenStream);
    //showMessage('Größe des Suchbildes x :'+inttostr(SearchBMP.Width)+' Y :'+inttostr(SearchBMP.Height)+' MemorySize :'+inttoStr(SearchStream.Size));
    //showMessage('Größe des Screens x :'+inttostr(ScreenBMP.Width)+' Y :'+inttostr(ScreenBMP.Height)+' MemorySize :'+inttoStr(ScreenStream.Size));

    // Header vom Suchbild entfernen
    SearchStream.Position := 53; // Bitmap Header Size = 54, deshalb Position auf 53
    SearchStream.Seek(0, soFromBeginning);
    tempSearch.CopyFrom(SearchStream,SearchStream.Size-54);
    tempSearch.Position := 0;
    SearchStream.Clear;
    SearchStream.CopyFrom(tempSearch,tempSearch.Size);
    tempSearch.Clear;


    // Header vom Screen entfernen
    ScreenStream.Position := 53; // Bitmap Header Size = 54, deshalb Position auf 53
    ScreenStream.Seek(0, soFromBeginning);
    tempScreen.CopyFrom(ScreenStream,ScreenStream.Size-54);
    tempScreen.Position := 0;
    ScreenStream.Clear;
    ScreenStream.CopyFrom(tempScreen,tempScreen.Size);
    tempScreen.Clear;



    // erste Zeile vom Suchbild als Vorraster benutzen
    SearchStream.Position := 0;
    tempSearch.CopyFrom(SearchStream,SearchBMP.Width*3);

    startTime := GetTickCount;
    for I := 0 to ScreenStream.Size-SearchBMP.Width*3-1 do
        begin
          ScreenStream.Position := i; // 3 wegen 24Bit
          tempScreen.Clear;
          tempScreen.CopyFrom(ScreenStream,SearchBMP.Width*3);
          tempScreen.Position := 0;
          tempSearch.Position := 0;
          if CompareMem(tempScreen.Memory, tempSearch.Memory,SearchBMP.Width*3) then
              showmessage('gleich');
        end;

    showMessage('Durchlaufzeit: '+Floattostr((GettickCount-starttime)/1000)+' s');

Ist der Gedankengang so erstmal richtig. Funktioniert das überhaupt?

Grüße
s0n