Operationen mit TImage langsam - Alternativen ?

Für Probleme bezüglich Grafik, Audio, GL, ACS, ...
Antworten
Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Operationen mit TImage langsam - Alternativen ?

Beitrag von af0815 »

Ich habe auf einem RasPi 3B bzw. 3B+ Operationen mit TImage sehr zeitintensiv sind. und suche Alternativen.

Setup:
Ich bekomme von einer GoPro9 die Bilder mit 20 MPx per Wifi als TMemoryStream. In dem Stream sind die JPG Daten 1:1 drinnen. Mit einem einfachen SaveToFile habe ich das auf der (USB-)Harddisk das geht schnell und unkompliziert. Ich habe entweder den Stream direkt oder das File auf der Platte zur Verfügung.

Was muss ich machen und das ist das aktuell zeitintensivste Part:
1) Das Bild mit Textinfos ergänzen (Die werden ins Bild 'eingebrannt')
2) Infos in den EXIF Bereich des Bildes geschrieben (da verwende ich die 'alte' dexif Variante)
3) Anzeigen des Bildes am Display
  • Step3 Start View Picture: 17132ms
    Step3 End View Picture: 24482ms
Alle Operationen nacheinander kosten mir viele Sekunden das sind schon mal bis zu 20 Sek. aktuell ! Besonders Wichtig ist mir da 1 & 2, weil das Anzeigen kann ich ins 'idle' verschieben, das ist nicht ganz so schlimm aber wäre schön was zu alternativ zu finden.

Wie kann ich das ganze Optimieren, da aktuell die meisten Operationen über TImage laufen ist das offensichtlich zu langsam am RasPi.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: Operationen mit TImage langsam - Alternativen ?

Beitrag von wp_xyz »

20 MPx pro Bild? Und wieviele Bilder pro Sekunde?

1) Wenn "ins Bild eingebrannt" bedeutet, das irgendwas auf den Canvas des Bildes geschrieben wird, dann muss das jpg vorher dekodiert und hinterher wieder zurückkodiert werden
3) Auch dieser Schritt bedeutet eine Dekodierung des JPG.

Selbst wenn nur wenige Bilder pro Sekunden ankommen, erscheint mir das nicht machbar. Der JPEG-Decoder der FCL ist relativ langsam, ich weiß nicht wie schnell der von BGRABitmap ist. Es gibt "fast jpeg" Implementationen, aber die sind in der Regel hardware- oder betriebssystemgebunden.

Warum arbeitest du mit TImage, warum nicht mit dem schlankeren TJpegImage, wenn du eh weißt, dass die Bilder jpg's sind?

Benutzeravatar
theo
Beiträge: 10467
Registriert: Mo 11. Sep 2006, 19:01

Re: Operationen mit TImage langsam - Alternativen ?

Beitrag von theo »

Ein bisschen was kann man sicher schrauben, aber da müsste man zuerst wissen, was du gemacht hast und was du brauchst oder was ggf. auch verzichtbar ist.

Ich denke aber, dass die groben Dimensionen gegeben sind: Rpi 3b und 20MPx.
Da wirst du immer etwas warten müssen.

Ich würde wahrscheinlich die Auflösung der Kamera runterschrauben. 20Mpx sind immerhin fast 10 x Full HD.

@wp: Ich glaube, af meint Photos, nicht Video.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Operationen mit TImage langsam - Alternativen ?

Beitrag von af0815 »

Danke für die Rückmeldungungen.

Aktuell nur 20MPx Fotos. Sollen aber mit der GoPro 11 dann 27 MPx werden. Auflösung darf maximal hochgeschraubt werden. Es geht um das spätere Zoomen in das Bild hinein. Das fotografierte Objekt ist größer, gebraucht werden aber kleine Details die über das ganze Objekt verstreut sind. Ist so wie ein Bild von einem Heuhaufen, wo man später mittels hineinzoomen ein paar Stecknadeln mit farbigen Köpfen finden will.

Es sind nicht so viele Bilder 1-5 Bilder und dann 1 Minute Pause, ich muss die Kamera so schnell wie möglich leerräumen, die Infos reinbekommen und ablegen. Ist immer so ein Burst.

Es wird für die Canvas Operation bereits ein TJpegImage verwendet. Nur für die Anzeige das TImage. Danke mal für den Schubser mit dem TJpegImage, das hatte ich ganz vergessen darauf zu schauen.

Das mit BGRA Bitmap schaue ich mir an. Vielleicht is der Dekoder/Encode schneller.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: Operationen mit TImage langsam - Alternativen ?

Beitrag von wp_xyz »

af0815 hat geschrieben:
Do 16. Mär 2023, 12:09
Das mit BGRA Bitmap schaue ich mir an. Vielleicht is der Dekoder/Encode schneller.
Ein schneller Blick in bgraReadJPeg zeigt, dass der Reader von TFPReaderJPeg abstammt, und nur die InternalCheck-Routine zur Formaterkennung überschreibt.

Nachdem die Anzeige des Bildes wahrscheinlich nicht mit der vollen Auflösung erfolgen muss, kannst du den Anzeigeschritt beschleunigen, indem du vor dem laden des Jpeg die Scale- und Performance Properties entsprechend anpasst, in unit TFPReadJpeg TJPEGScale = (jsFullSize, jsHalf, jsQuarter, jsEighth) und TJPEGReadPerformance = (jpBestQuality, jpBestSpeed). jsEighth und jpBestSpeed bringen bei mir (Win 11, Intel) beim Lesen eines 10 MPx Fotos etwa einen Faktor 5:

Code: Alles auswählen

uses
  FPReadJpeg;

procedure TForm1.Button1Click(Sender: TObject);
var
  jpg: TJpegImage;
begin
  jpg := TJpegImage.Create;
  try
    jpg.Scale := jsEighth;
    jpg.Performance := jpBestSpeed;
    jpg.LoadFromFile(datei_name);
    Image1.Picture.Assign(jpg);
  finally
    jpg.Free;
  end;
end;

Benutzeravatar
theo
Beiträge: 10467
Registriert: Mo 11. Sep 2006, 19:01

Re: Operationen mit TImage langsam - Alternativen ?

Beitrag von theo »

Das mit dem JPEG-Scaling wollte ich auch vorschlagen, da ich das schon im Thumbviewer verwendet und FPReadJPEG entsprechend angepasst hatte, aber ich bin mir nicht sicher, ob es hier als Lösung richtig ist.
Das Bild muss er ja doch komplett "auspacken", nicht wie beim Thumbviewer.
Vielleicht ist es aus Speichergründen (Rpi 3) deshalb auch sinnvoller, auf das Image1.Picture.Jpeg zuzugreifen um Mehrspurigkeiten zu vermeiden.
Das müsste man alles testen bzw. im Code ergründen.

Ich glaube bei so etwas gibt es keine Wundermittel. Man muss einfach im Kleinen schauen, wo man Speicher und/oder einen Kodiervorgang sparen kann.

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: Operationen mit TImage langsam - Alternativen ?

Beitrag von wp_xyz »

theo hat geschrieben:
Do 16. Mär 2023, 12:48
Das mit dem JPEG-Scaling wollte ich auch vorschlagen, da ich das schon im Thumbviewer verwendet und FPReadJPEG entsprechend angepasst
Ah, das ist von dir! Danke.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Operationen mit TImage langsam - Alternativen ?

Beitrag von af0815 »

Danke für den Input.

Ich habe jetzt einfach ein paar Bäume im Wald gefällt. Das ist immer gut, wenn man den Wald vor lauter Bäumen nicht sieht :-)

Die Bildanzeige habe ich mal rausgeschmissen und zeige dafür ein statisches Bild an und schreibe Ok dazu :-) Beim Rest werde ich auch noch weiter so vorgehen, alles raus was ein 'nice to have' ist. Und eher historisch drinnen ist, weil auf den richtigen PCs spürt man das nicht.

Dann werde ich mich mit dem JPEG-Scaling, dem EXIF und der Durchlaufzeit beschäftigen.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: Operationen mit TImage langsam - Alternativen ?

Beitrag von wp_xyz »

Am schnellsten von den Aktionen 1 und 2 ist 2, das Schreiben ins EXIF. Daher würde ich den unter 1 zu schreibenden Text als Kommentar ins Comment-Segment der JPEG-Struktur schreiben. Von dort kannst du dann später, wenn Zeit ist, die Information wieder auslesen und auf den Canvas malen. Zum Schreiben eines Kommentars muss nichts dekodiert werden, das ist nur ein Segment (=Block) mit bestimmter Kennung unter all den JPEG-Segmenten. Ich weiß nicht mehr wie dExif es macht, aber mit fpExif (https://sourceforge.net/p/lazarus-ccr/s ... ts/fpexif/) würde es so gehen:

Code: Alles auswählen

uses
  fpeMetaData; 
const
  fn = '20220127_154855.jpg';
  fn_out = 'output.jpg';
var
  imgInfo: TImgInfo;
begin
  imgInfo := TImgInfo.Create;
  try
    imgInfo.LoadFromFile(fn);
    imgInfo.Comment := 'bla-bla';
    imgInfo.SaveToFile(fn_out);  // oder imgInfo.Save
  finally
    imgInfo.Free;
  end;
end.      

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Operationen mit TImage langsam - Alternativen ?

Beitrag von af0815 »

Danke, ich habe aktuell das ganze mal einem Hintergrundthread umgehängt, der sowieso den FTP Transfer macht. Der kann gemütlicher laufend arbeiten und ist damit nicht sichtbar.

Das mit dem fpExif schau ich mir am WE mal in Ruhe an. In den OPM hat es der ja nicht geschafft :-) Sonst hätte ich ihn dort schon gefunden.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: Operationen mit TImage langsam - Alternativen ?

Beitrag von wp_xyz »

af0815 hat geschrieben:
Do 16. Mär 2023, 16:03
In den OPM hat es der ja nicht geschafft :-)
Was heißt nicht geschafft? fpexif würde da schon aufgenommen, aber ich habe es noch gar nicht eingereicht, weil ich immer noch unzufrieden bin, dass die Daten im "Manufacturer"-Tag zerstört werden können, wenn man manche EXIF-tags editiert. Das liegt daran, dass sich die Manufacturer ihre eigenen Daten (in eigenen Formaten) mit Offsets relativ zum Anfang des EXIF-Segments abspeichern, nicht aber zum Anfang des eigenen Tags, so dass beim Bearbeiten von EXIF-Tags, die vor dem Manufacturer-Block liegen, die eigenen Offsets durcheinander kommen können. Und weil der Aufbau des Manufacturer-Blocks nicht bekannt ist, hat eine externe Software genaugenommen keine Chance, das zu korrigieren. Andererseits gibt es durchaus Software wie EXIFTool, die durchaus mit dieser Situation umgehen kann. (dExif kann's aber auch nicht...) Wobei natürlich EXIFTool sowas wie die Referenz-Software zu diesem Thema ist, die haben die meisten Manufacturer-Tags zerpflückt und wissen durchaus wie die aufgebaut sind.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Operationen mit TImage langsam - Alternativen ?

Beitrag von af0815 »

Es war nicht böse gemeint, das mit dem OPM. OPM ist halt bequemer für den Lazarus Benutzer. Und ich wollte mir nicht den ganzen CCR mit GIT auf die Platte holen.

Das die Hersteller teilweise machen was sie wollen war schon bei dExif klar. Die EXIFTools sind natürlich eine eigene Liga und somit Referenz, das ist aber bekannt.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: Operationen mit TImage langsam - Alternativen ?

Beitrag von wp_xyz »

Schon klar. Aber du musst dir nicht das ganze CCR herunterladen, mit "Download Snapshot" auf https://sourceforge.net/p/lazarus-ccr/s ... ts/fpexif/ kannst du dir einen aktuellen Schnappschuss des FPExif-Projekts als zip herunterladen, ohne svn und ohne git.

Benutzeravatar
h-elsner
Lazarusforum e. V.
Beiträge: 259
Registriert: Di 24. Jul 2012, 15:42
OS, Lazarus, FPC: LINUX Mint21.1, Win10, Lazarus 2.2.4, FPC3.2.2
CPU-Target: X86-64; arm 32bit
Wohnort: Illertissen
Kontaktdaten:

Re: Operationen mit TImage langsam - Alternativen ?

Beitrag von h-elsner »

Ich bin treuer Nutzer von FPEXIF und genauso mache ich es. Dann einfach per Package > Open package file (.lpk) > und die frage ob es im Projekt genutzt werden soll mit ja beantworten.
Gruß HE

PS: Vielen Dank für FPEXIF und den Support dafür!

Antworten