Seite 2 von 3

Re: Speicherleck bei Images

Verfasst: 29.09.2017 10:39
von Rings
Lupo hat geschrieben: Ganz ausschließen könnte man aber nicht, dass das Leck vom geladenen Tiff-Bild abhängig ist. Multi-Tiff kämen mir da in den Sinn. Eventuell könntest du dein Testbild zum Download bereitstellen?

Sicher könnte dann auch ein Kollege mit einer aktuellen PB-Version testen.
Rings hat geschrieben:poste doch bitte einmal ein Bild, wo genau das passiert.
Oder besser noch erstelle ein zip wo code und bild drin ist,
so das man es direkt out of the box selbst ausprobieren kann.

Dann wird es einfacher das Problem einzugrenzen und evtl. auch zu fixen.
Ich besorg mir dann auch ne Glaskugel.... ;)

Re: Speicherleck bei Images

Verfasst: 29.09.2017 15:52
von fabulouspaul
Hab gerade unterwegs kein TIF zur Hand, aber es geht mit beliebigen TIFs.
z.B. mit dem hier: https://kk.wikipedia.org/wiki/%D0%A1%D1 ... %D1%8B.TIF

@Lupo: ich habe noch eine alte PB 4.60(x86) unter Win7 ausgegraben, da tritt der Fehler tatsächlich auch nicht auf (bzw. nur die konstante Speichermehrbelegung durch die Decoder-Initialisierung beim LOADIMAGE() wie in der aktuellen PB-Version bei JPGs)

Re: Speicherleck bei Images

Verfasst: 30.09.2017 11:15
von Rings
kein speicherleck PB 5.61 X86 hiermit:

Gepackte source mit der TIF:
Datei von filehorst.de laden

Re: Speicherleck bei Images

Verfasst: 30.09.2017 18:51
von fabulouspaul
Tatsächlich... ich denke es liegt am Format der TIF-Komprimierung.

Unter Datei von filehorst.de laden habe ich mal Rings Image in ein TIF mit Fax-G4-Komprimierung konvertiert (findet bei mit für S/W-Images Anwendung, weil extrem gut komprimiert).
Dabei ist der Speicherverlust deutlich zu erkennen.

Wenn man das o.g. TIF-Image von Wikipedia ohne weitere Konvertierung mit "Bild speichern unter" herunterlädt (Image hat keine Komprimierung) ist der Speicherverlust übrigens auch gut sichtbar.

Re: Speicherleck bei Images

Verfasst: 30.09.2017 19:40
von fabulouspaul
Um festzustellen ab welcher PB-Version der Fehler auftritt habe ich mal das "Museum" bemüht.

Ab der Version 4.61 (ich habe nur die x86 ausprobiert) gibt es den Speicherverlust.
Mit PB 4.60 ist der Speicherverbrauch wie man es erwarten würde.

Um alle Fehlerquellen auszuschliessen habe ich mich auf den Windows Taskmanager verlassen um den Speicherverbrauch der Programme abzulesen und das Programm zum laden und wieder freigeben der Images entsprechend ausgedünnt.
Zum nachvollziehen habe ich die 2 kompilierten Programme (PB4.60 / PB 4.61) unter Datei von filehorst.de laden abgelegt.

Re: Speicherleck bei Images

Verfasst: 30.09.2017 21:13
von Rings
Ja, kann ich hier jetzt mit dem Fax TIF nachvollziehen

Hätteste die mal vorher gepostet hätten wir hier nich wie die
dollen rumgesucht.

dann bitte Error Thread im engl. forum posten .

Re: Speicherleck bei Images

Verfasst: 02.10.2017 09:46
von fabulouspaul
Rings hat geschrieben:...
dann bitte Error Thread im engl. forum posten .
erledigt.

Re: Speicherleck bei Images

Verfasst: 19.10.2017 14:56
von fabulouspaul
Da ein Bugfix ja eine Weile dauern kann, habe ich mal mit TIFFLIB experimentiert.
Mit der DLL lassen sich die TIF-Dateien problemlos laden und es gibt kein Speicherleck.... ABER das Laden eines Images dauert mehr als 3x so lang wie über den PB-eigenen Decoder. :o
Da jew. einige Tausend TIFs bearbeitet werden macht sich das schon sehr negativ bemerkbar.

Hat jemand noch eine andere Idee?
Mir fällt noch GDI+ ein, aber ich habe keine Ahnung, wie ich das unter PB anwende.
Vielleicht kann mir da jemand "auf's Pferd helfen"?

Re: Speicherleck bei Images

Verfasst: 19.10.2017 15:02
von NicTheQuick
Was ist denn die genaue Aufgabe, die du lösen möchtest? Was wird da genau verarbeitet?

Re: Speicherleck bei Images

Verfasst: 19.10.2017 16:18
von fabulouspaul
NicTheQuick hat geschrieben:Was ist denn die genaue Aufgabe, die du lösen möchtest? Was wird da genau verarbeitet?
Ich habe ein Programm, was große Mengen von Images im TIF-Format (Fax-G4-komprimiert) überprüft. Dazu lädt es jede einzelne TIF-Datei. Durch das in diesem Thread beschriebene Speicherleck kommt es nach einigen Tausend TIFs irgendwann zu einem Fehler und zum Programmabbruch.
Wie wir festgestellt haben, tritt der Fehler bei der Verwendung des PB-internen TIF-Decoders auf.

Aufgabe ist nun, eine Möglichkeit zu finden, das Laden der o.g. TIFs anderweitig, ohne Speicherleck, aber in annähernd gleicher Geschwindigkeit wie mit dem PB-internen Decoder abzubilden.
Die geladenen Images müssen danach als Image in PB nutzbar sein, weil die Überprüfung auf den Inhalt der Images zugreifen können muss.

Um es einfach zu sagen: LoadImage() für TIFs soll ersetzt werden durch eine Prozedur oder Funktion in einer Library.