Entwickler-Ecke :: Thema anzeigen - Schneller JPEG-Loader gesucht

Martok - Di 12.04.11 15:27
Titel: Schneller JPEG-Loader gesucht

Hi!

Ich komme momentan echt in Geschwindigkeitsprobleme, weil TJPEGImage aus der Delphi-JPEG-Unit tierisch langsam ist. Einiges rumlesen hat oft den Hinweis auf die Intel JPEG Lib gebracht, aber die hat einen Nachteil: sie existiert nicht mehr. :(

Ich suche also einen schnelleren JPEG-Loader. Schön wäre ein TGraphic-kompatibler Wrapper, aber wenn man den erst bauen muss nicht wäre es auch kein Beinbruch.

Gibts da was schönes? Ich weiß, dass GDI+ einen hat, aber die möchte ich hier eigentlich nicht verwenden.

Danke schonmal,
Martok

Martok - Di 12.04.11 17:34

Danke, ist geringfügig schneller, aber noch lange nicht ausreichend.
6600x4400px, 3MByte; 800Mhz gedrosseltes System:
jpeg.pas: 20s
jpegex.pas (mitgeliefertes Demoprogramm): 16s

ACDSee: 1.6s in Vollansicht (da wird er wohl nicht jeden Block laden), fies reingezoomt ~6s (realistischer).

Irgendwas, was in die Gegend kommt wäre schon toll. Muss ja nicht ganz so schnell sein, aber im Test unter 10s kommen will ich schon ;) Taktgedrosselt deswegen, damit man die Unterschiede einfacher messen kann. Normal kommt ungefähr ein Drittel der Zahlen oben raus.

Martok - Sa 21.05.11 16:21

Und mal wieder an diesem Problem arbeiten... ;)

Aya hat folgendes geschrieben :

Alternativ einfach die libJPEG wrappen, du bräuchtest da nur etwa 5-10 funktionen von - dafür einen Wrapper zu basteln sollte kein großer aufwand sein und dürfte das schnellst-mögliche sein.

5-10 Funktionen stimmt - aber genausoviele seitenlange Structs, die in kaputtem C sowas ähnliches wie Objekte oder viel mehr Interfaces darstellen.

Da steig ich nicht wirklich durch :nixweiss: Gibts sowas nich schon? Kann doch nicht der erste sein der sowas will.

Martok - Sa 21.05.11 18:11

Gerd Kayser hat folgendes geschrieben :

Martok hat folgendes geschrieben :

Intel JPEG Lib gebracht, aber die hat einen Nachteil: sie existiert nicht mehr. :(

Hilft Dir das vielleicht weiter? http://bouchez.info/micropic.html

Könnte es tatsächlich. Er hat ja auch noch einen eigenen Loader geschrieben, wird auf der MyJPEG-Seite verlinkt. Mal alles testen. Im Synopse-Projekt selbst hatte ich sowas ja schon gefunden, aber das war wohl nicht sehr kompatibel (= kann viele Dateien nicht lesen)

So wie ich das verstanden habe, darf man die IJL so direkt ja auch nicht weitergeben. Was ich allerdings mittlerweile rausgefunden habe: ACDSee nutzt die die IJL 1.1, also sogar eine relativ alte. Na mal sehen, vielleicht bau ich auch eine Klasse mit Fallbacks auf irgendwas erlaubtes und überlasse das dem User, da was passendes zu "finden" :P

EDIT/UPDATE:

Testszenario wie im ersten Beitrag

1:
2:
3:

Graphics TJPEGImage: 9193,82994207364ms
MyJPEG TJPEGImage (IJL): 1843,05519276891ms
JPEGFast: 2673,43754583334ms

Also werde ich IJL mit Fallback auf JPEGFast mit Fallback auf MyJPEG ohne IJL (was nur ein paar ms schneller ist als das Original-IJG) nehmen. Irgendwie ;)

Gummibär - Mo 23.05.11 15:19

Ist es nur für eine Vorschau? Diese Riesen-Bilder passen ja eh auf keinen (bezahlbaren) Bildschirm.
Falls ja, könnte TJPEGImage.Scale helfen. Wenn man das beim Laden des JPEGs beispielsweise auf jsQuarter setzt, spart man einiges an Lade-Zeit. Und wenn man dann feststellt, dass das Bild doch kleiner war, lädt man es einfach nochmal mit Scale:=jsFullSize. Die Datei ist dann eh schon im Windows-Cache...

Gruß
Michael

Martok - Mo 23.05.11 16:52

Gummibär hat folgendes geschrieben :

Ist es nur für eine Vorschau? Diese Riesen-Bilder passen ja eh auf keinen (bezahlbaren) Bildschirm.

Sowohl als auch.

Gummibär hat folgendes geschrieben :

Falls ja, könnte TJPEGImage.Scale helfen. Wenn man das beim Laden des JPEGs beispielsweise auf jsQuarter setzt, spart man einiges an Lade-Zeit.

Das ist eine Nette Theorie, hatte ich ursprünglich auch mal probiert, funktioniert aber nicht. Habs mal kurz ins Testprogramm integriert:

Quelltext

1:
2:

Graphics TJPEGImage Eighth: 9288,68864618269ms
Graphics TJPEGImage Full: 9250,47345402838ms

:nixweiss:

jasocul - Mo 23.05.11 17:10

Ich habe vor ein paar Jahren mal was auf die schnelle gebastelt. Programm ist im Anhang.
Wenn das für dich brauchbar ist, dann bekommst du die Sourcen. Aber dann nicht wundern. War wirklich ein Schnellschuss damals.

Mist. Dateianhang kann ich gerade nicht hinzufügen. Ist das ein Bug?

EDIT:
FireFox wollte nicht. Mit dem IE funktioniert es.

Noch ein EDIT:
Jetzt mit Source.
Das ist wirklich nur ein Mini-Programm mit 120 Zeilen Code. Allerdings sind die Jedi-Komponenten drin. Ohne gehts nicht.

Das Programm ist echt schon 6 Jahre alt. :shock:

Gummibär - Mo 23.05.11 17:52

(Irgendwie gehen die BB-Codes nicht, sorry :( )

Zitat Martok:
"Das ist eine Nette Theorie, hatte ich ursprünglich auch mal probiert, funktioniert aber nicht. Habs mal kurz ins Testprogramm integriert:"

Ich habe es jetzt mal mit einem 6000*6000 Pixel Bild versucht (Sorry, die Einrückungen müßt ihr euch denken, die BB-Codes verweigern die Mitarbeit):

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:

procedure TForm1.LoadFast;
VAR
  JPEG: TJPEGImage;
begin
  JPEG := TJPEGImage.Create;
  JPEG.LoadFromFile('big.jpg');
  JPEG.Scale := jsEighth;
  JPEG.DIBNeeded;  // Decompression. Usually not neccessary
  //Image1.Picture.Bitmap.Canvas.Draw(0, 0, JPEG);
  JPEG.Free;
end;

Mit Scale jsEighth komme ich auf ca. 170msec, ohne diese Einschränkung auf die 10-fache Dauer.
Habe auch mal DIBNeeded statt Canvas.Draw getestet, um nicht die Dauer mit zu messen, die für's Umkopieren von JPG nach BMP benötigt wird. Hat aber kaum was geändert (Draw hatte ich gewählt, weil ich das Bitmap so zuvor auch auf 6000*6000 Pixel setzen konnte und beide Methoden keinen Bitmap-Speicher allokieren müssen. Ansonsten hätt's ein assign() auch getan)

Vielleicht hängt das auch von den JPEGs ab? Kompressionsstärke, Progressive, etc.?

Ratloser Gruß
Michael

Moderiert von Narses: Delphi-Tags hinzugefügt

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!