Gwenview frisst Speicher

Ich hab ein Verzeichnis mit rund 12000 Bildern und beim Anzeigen der Thumbnails mit gwenview hängt der Rechner fast. Es hat sich aber herausgestellt, dass es nicht die Zahl der Bilder ist ... es sind bestimmte Bilder, die pro Stück zu einem enormen RAM-Verbrauch führen. Irgendwann ist dann auch der Swap voll. Diese Bilder sind schon jahrelang da und vor einigen Wochen gab es das Problem noch nicht.

Von einem dieser jpg-Bilder mit 7.1 Megapixel / 2.6MB habe ich 22 Exemplare in einem Verzeichnis angelegt und der gwenview bringt dabei einen 16GB-RAM-Rechner von 1.2GiB auf 12.4GiB. Das sind pro Pixel immerhin 77 Byte. Da fallen vergessene Speicherfreigaben im Gwenview als Erklärung eigentlich schon aus, denn was will man mit so vielen Byte pro Pixel? Vielleicht irgendein Kommunikationsproblem von KDE-Komponenten?

Fast dasselbe Bild nur mit einer etwas anderen Zoom-Einstellung 5 Sekunden vorher aufgenommen ist übrigens völlig unproblematisch.

digiKam und nomacs haben keine Probleme mit der Thumbnailanzeige.

Es handelt sich um einen Leap 15.2 Rechner mit gwenview5 20.04.2 lp152.1.1, aber auf einem 15.3er tritt dasselbe Problem auf.

Hat jemand eine Idee?

Zitat von Welm

...es sind bestimmte Bilder...

Die problematischen Bilder sind die mit unsinnigen Einträgen der Canon Maker Notes in "Thumbnail Image Valid Area". Damit gibt man augenscheinlich eigentlich einen Ausschnitt des Thumbnails für die Thumbnail-Anzeige an.

Anzeige:

exiftool -ThumbnailImageValidArea x.jpg

falls da keine plausiblen Pixelkoordinaten stehen sondern lustige Werte zwischen 0 und 65535:

Prüfung:

-verdächtige Datei in ein neues Verzeichnis kopieren

-dort vervielfältigen. z.B. "for I in {01..22}; do cp -a x.jpg pic$I; done"

-KSysGuard oder ähnliches zur Überwachung des RAM-Verbrauchs anwerfen

-dort "gwenview ." starten und mit der Hand über Control-C ggf. rechtzeitig abbrechen bevor die Kiste anfängt zu swappen.

und ggf. Reparatur:

exiftool -ThumbnailImageValidArea="0 0 0 0" x.jpg

Letzteres bedeutet "nimm das ganze Thumbnail als Thumbnail".

Zitat von matbhm

Leider verstehe ich Deine Problembeschreibung und die Lösung aus Post #2 nicht :).

Dann versuch ich mal, es anders zu beschreiben

Gwenview hat beim Anzeigen von Bildern aus einem großen Verzeichnis massenweise RAM gebraucht ... mehr als da war.

Es lag aber nicht an den vielen Bildern. Es waren einzelne dieser Bilder, die enorm RAM geschluckt haben. Die große Masse der Bilder war gar kein Problem. Es lag nicht an der Kamera oder am Motif, denn ich hatte zwei direkt nacheinander mit derselben Kamera aufgenommene Bilder von denen das eine problemlos war und das andere so ein RAM-Schlucker. Geprüft hab ich es dadurch, dass ich das "böse" Bild ein paar Mal in ein neues Verzeichnis kopiert habe und beim Betrachten mit gwenview waren sofort die 16GB weg und der Rechner fing an zu swappen. Ich hab dann erstmal andere Programme statt gwenview benutzt.

Irgendwann hab ich dann doch noch die gemeinsame Eigenschaft dieser "bösen" Bilder gefunden. In einem JPEG kann ja zusätzlich ein kleines Vorschaubild gespeichert werden. Bei JPGs aus Canonkameras wird zusätzlich noch eingetragen, welchen Ausschnitt davon bei Vorschauen das Anzeigeprogramm nehmen soll. Da stand jetzt bei einem Vorschaubild von z.B. 200x300 Pixel dran: Nimm für die Vorschau Pixelspalte 10437 bis 45358 und die Pixelzeilen 3246 bis 61799. Diese Spalten- und Zeilennummern gibt es aber in dem 200x300 Vorschaubild nicht. Da dürften ja nur viel kleinere Zahlen vorkommen. Irgendwie ist gwenview dadurch total durcheinandergeraten.

Ich hab dann mit exiftool die vier unsinnigen Zahlen alle durch 0 ersetzt. Das bedeutet, dass das ganze Vorschaubild genommen werden soll. Die Probleme waren dann weg.

Mit der "Prüfung" soll nur sichergestellt werden, dass man nicht an Dateien herumbastelt, die gar kein Problem machen.

Ich hab aber keine Ahnung woher diese fatalen Canon-Angaben kamen. Dass keiner geantwortet hat könnte ein Hinweise darauf sein, dass ich als einziger so doof war diese Tags kaputt zu machen ...

Aber für den Fall, dass doch noch jemand das Problem bekommt, wollte ich doch gern eine Umgehungsstraße ausschildern :-))