Bilder komprimieren und speichern mit Threads

[Schwedenbitter]

Liebe Mitlesende,

ich stehe vor folgendem Problem und dabei ein bisschen auf dem Schlauch:

Gegeben ist ein Programm, dass über TDelphiTwain einen Seitenscanner ansteuert und pro Scan-Auftrag etwa 25 DIN-A4-Seiten als TBitmap geliefert bekommt. Der Scanner schafft ca. 45 Seiten/min.
Die TBitmaps werden zunächst jeweils in einer TObjectList abgelegt. Erst wenn das letzte Bild gescannt wurde, werden diese alle nacheinander beschnitten, größenangepasst, gedreht, ins PNG-Format komprimiert und dann gespeichert.
Das hat ein paar Nachteile: So belegt das Programm während des Scannes viel, viel Speicher, die CPU wird während des Scannens de facto nicht benutzt etc. pp.

Meine Idee war es daher, das ganze in Threads auszulagern. Allerdings habe ich Probleme damit, wie ich das logisch hinbekommen kann. Ich könnte jeweils einen Thread erzeugen, sobald das nächste Bild geliefert wird. Damit würde ich aber den PC heillos überlasten.
Ich müsste es daher hinbekommen, dass ich die Anzahl auf z.B. 10 beschränke. Wenn also 10 Threads gestartet sind, sollen weitere Bilder nach dem alten Muster wieder in eine Liste kommen. Ist ein Thread fertig (also wieder nur 9), soll ein neuer gestartet werden ...

Meine Fragen:

1. Bringt das etwas? Unsere Arbeitsplatzrechner haben alle nur 1 CPU/1Kern.
2. Wie mache ich das Grundsätzlich?
3. Am einfachsten würde ich das wieder über die TObjectList machen, habe aber skrupel, diese aus dem Thread heraus anzufassen (Bild holen und nach dem Speichern löschen). Ich würde die Threads zählen. Fällt die Zahl unter 10, käme der nächste. Geht das so, wie muss ich das machen? Kann ich den Thread-Zähler aus dem Thread einfach so ändern?
4. Ich würde die Threads wegen der besseren Lesbarkeit des Codes gern in eine separate Unit auslagern. Dann komme ich aber an die Liste mit den Bitmaps nicht heran und muss die TBitmaps mit übergeben, sodass 3. eigentlich ausscheidet, richtig?

Bitte auch gern Links, wo ich mich zu dem Thema belesen kann.

Gruß, Alex

[jfheins]

Zitat:

Ich könnte jeweils einen Thread erzeugen, sobald das nächste Bild geliefert wird. Damit würde ich aber den PC heillos überlasten.

Sicher? Wenn die Verarbeitung ungefähr genauso schnell geht wie die Daten kommen (oder schneller) wäre das eigentlich ein guter Ansatz.

Zitat:

Meine Fragen:
Bringt das etwas? Unsere Arbeitsplatzrechner haben alle nur 1 CPU/1Kern.

Das rechnen fängt eben schon nach der ersten Seite an und nicht erst wenn alle fertig sind. Das gibt dir schonmal einen Vorsprung von 32 Sekunden. Außerdem wird das Programm durch die Parallelisierung von Multicores profitieren, die möglicherweise zukünftig angeschafft werden.

Das mit der Objectlist lässt sich leicht lösen. Solange du auf ein Bitmap nur aus einem Thread zugreifst, ist alles OK. Also im Hauptthread erstellen, das Bitmap an den Thread weitergeben und dort dann zerstören sollte kein Problem sein solange du nach der Übergabe im Hauptthread nichts mehr machst ;)

[Schwedenbitter]

Danke für die Antwort.

Zitat:

Zitat von jfheins (Beitrag 1084926)

Also im Hauptthread erstellen, das Bitmap an den Thread weitergeben und dort dann zerstören...

Könntest Du das bitte genauer erklären?

Wenn ich das - bis jetzt - richtig verstanden habe, dann wäre mein Anfang schon falsch,

Delphi-Quellcode:

Constructor TSaveThread.Create(Bitmap: TBitmap; FileName: String;
  Compression: Integer; Resize: Boolean; DPI: Integer; Tolerance: Integer);
Begin
  Inherited Create(True);
  FBitmap:=TBitmap.Create;  // <- Blödsinn???
  FBitmap.Assign(Bitmap);   // <- klappt IMHO nur nach .Create
  ...
End;

Procedure TSaveThread.Execute;
Begin
  ...
  FBitmap.Free;
End;

denn so lege ich ein neues TBitmap an und kopiere lediglich das Bild. Und da ich nicht nach dem Motto Trial-and-error arbeiten kann/wollte, habe ich das hier

Delphi-Quellcode:

FBitmap:=Bitmap;

noch nicht probiert. Es ist auch ein bisschen schwierig für mich. Normalerweise mache ich das schon einmal mit Versuch und Irrtum. Hier hält mich aber davon ab, dass ich den umfangreichen Code nicht zu Testzwecken aus dem Programm herausschreiben kann und ich für jeden Test zig Blätter einscannen muss :lol:

Gruß, Alex

[jfheins]

Okay, ich versuch das mal:

Also: Solange man nur aus einem Thread auf ein Bitmap zugreift kann eigentlich nichts schiefgehen. Du kannst also im Hauptthread das Bitmap erstellen und befüllen. Dann erstellst du einen Thread (Modus Suspended um sicher zu gehen) und übergibst dem Thread das TBitmap-Objekt. Der Thread "übernimmt" das Objekt (ja, mit FBitmap:=Bitmap;) und gibt es am Ende auch frei. Danach kannst du im Hauptthread die Bitmapvariable auf nil setzen (um auch ja keine Sachen mehr damit zu machen) und den Thread anschließend loslaufen lassen.

Das müsste gehen weil ja immer nur ein Thread zugreift. Ich weis nur nicht genau, ob TBitmap zu der (nicht thread-safe) VCL gehört. (Eigentlich wird ja nichts angezeigt...)
Laut dieser Diskussion: http://qc.embarcadero.com/wc/qcmain.aspx?d=43018 könnte es sein, dass du das Canvas locken musst, damit alles gut geht.

[Bummi]

Zitat:

dass du das Canvas locken musst, damit alles gut geht

kann ich aus leidvoller Erfahrung bestätigen.

[Schwedenbitter]

Zitat:

Zitat von Bummi (Beitrag 1084954)

Zitat:

dass du das Canvas locken musst, damit alles gut geht

kann ich aus leidvoller Erfahrung bestätigen.

Wie jetzt? Auch bei der puren Übergabe an den Thread? Ich zeichne nichts auf das Canvas innerhalb eines Thread.

Delphi-Quellcode:

Procedure TScan.TwainTwainAcquire(Sender: TObject;
   Const Index: Integer; Image: TBitmap; Var Cancel: Boolean);
Begin
End;

Mit dieser Procedure kommt das Bild an. Image wird automatisch verworfen/überschrieben oder sonstwas, wenn die Procedure wieder beendet wird. Ich starte meinen Thread genau dort und übergebe das TBitmap.

Ich habe leider keinen Scanner hier, werde es aber morgen dann mal probieren.

Danke, Alex

[Medium]

@Bummi: Wie sinnfrei ist das denn? Also, gut möglich, aber wenn die einzige Referenz im Thread liegt, warum sollte ich dann noch was locken müssen? Klingt für mich nach einer ziemlichen VCL-Nachlässigkeit bzw. Konzeptfehler. Ein Grund mehr, warum ich sowohl in Delphi als auch .NET praktisch grundsätzlich mit eignen Bitmapklassen arbeite, die ihre Daten in hübschen eindimensionalen, performaten Arrays halten. Der ganze Overhead in den diversen Grafikroutinen geht mir langsam auf die Nüsse... aber das nur so nebenbei, und ist ja nicht dein Verschulden =)

Was ich gern mache, ist einem Thread eine List<TAbzuarbeitendeObjektklasse> zu verpassen. Im Thread dann:

Delphi-Quellcode:

procedure Execute;
var
  ref: TAbgearbeiteteObjektklasse;
begin
  repeat
    if MyTaskList.Count>0 do
    begin
      ref := PerformTask(MyTaskList[0]);
      MyTaskList.Delete(0);
      SendMessage(hwndMyMainForm, WM_MYOBJECT_READY, Integer(ref), 0); // falls nötig, dass der MainThread die Fertigstellung mitbekommen muss
      // wobei ddas nicht ganz sauber ist, der MainThread muss dann gesichert "ref" verarbeitet oder kopiert haben, bevor das neue "ref" fertig ist.
      // Da ggf. eine weitere Queue nehmen, oder mit Flags arbeiten.
    end;
    Sleep(1);
  until Terminated;
end;

und im Hauptthread dann

Delphi-Quellcode:

procedure MyNewDataHandler(aObjectToHandle: TAbzuarbeitendeObjektKlasse);
begin
  MyThread.MyTaskList.Add(aObjectToHandle);
end;

Und wenn die zu verarbeitenden Objekte selbst aus einem Thread stammen, bekommt der einen Callback, der o.g. Prozedur auslöst, was wahlweise auch per Windows Message hübsch sein kann. Dadurch gibts dann einen Thread, der ständig auf neue Inputs wartet, und wenn etwas kommt es fix durchrattert, so schnell wie es eben geht, und dann einfach mal fertig damit ist. Die Ergebnisse aus dem Verarbeitungsthread könnten dann ggf. in gleicher Weise an einen Speicher- oder Netzwerk-Thread übergeben werden, der dann entsprechend weiter macht. Im Grunde einfaches Queuing nach FIFO Prinzip. Macht sich für so Arbeitsthreads ganz nett.

\\Edit: Hupps, Code war LIFO, sollte FIFO sein :>

\\Edit2: Natürlich kann man PerformTask() wieder einen neuen Thread auslösen lassen, wodurch man je nach Struktur noch mehr von Multicores profitieren würde, wenn die eigentliche Abarbeitung single-threaded ist. Seit Multicores so langsam Standard sind, nutz ich solche Modelle zumindest ausschweifend =). Dann ändert sich aber natürlich die Stelle fürs Benachrichtigen des Hauptthreads.

\\Edit3: Schleife geändert... zu viel C# in letzter Zeit, ich bring alles durcheinander =)

[Bummi]

Zitat:

Wie sinnfrei ist das denn?

ich sprach lediglich über meine Erfahrungen, mehrere Threads die auf das Canvas der übergebenen Bitmaps zugegriffen haben, jeder sein eigenes Bitmap, keines der Bitmaps war irgendwo sichtbar, trotzdem gab es ohne Canvas.Lock ca. 50 % Artefakte.

[Medium]

Aha okay! Wenn mehrere Threads auf den Canvas zugreifen, dann ist's ja sonnenklar. Dann gehört das auch so :)

[Schwedenbitter]

Danke für Eure vielen Hinweise!

Ich habe mal angefangen und das Ergebnis sieht schon ganz gut aus. Auf mehrere Threads habe ich verzichtet, da wir hier in absehbarer Zeit sowieso vermutlich nie Rechner mit mehreren Kernen haben werden und es so einfacher zu strukturieren war. Ich habe meinen Code mal als Datei angehängt und würde mich freuen, wenn jemand noch gute Hinweise hat. Canvas muss erwartungsgemäß nicht gelocked werden.

Mir geht es insbesondere um das Aufräumen. Ich wollte mich nicht um den Thread kümmern müssen und habe daher

Delphi-Quellcode:

FreeOnTerminate:=True;

gesetzt. Aus diesem Grund muss ich

Delphi-Quellcode:

TObjectList

am Ende von

Delphi-Quellcode:

TThread.Execute;

freigeben, weil der Destructor so nicht aufgerufen wird, in dem ich das sonst getan hätte.
Ferner bin ich mir nicht sicher, ob ich innerhalb des Thread für das Hinzufügen bzw. Löschen von Bildern mit einer CriticalSection arbeiten muss/sollte. Es wäre ja sonst denkbar, dass in exakt demselben Moment mit nicht absehbaren Folgen ein Bild hinzugefügt und ein anderes gelöscht wird.

Den Code habe ich mit FastMM geprüft. Speicherlecks wurden keine angezeigt :-D

Gruß, Alex