gimp läuft amok

[ausfahrt]

Mir wird das komplette System lahm gelegt, wenn ich versuche in gimp 2.10 (debian testing) ein PNG in DIN A2 Größe, RGB 300 dpi zu öffnen. Irgend wann während des Ditherings ist mein Ram (2GB) und mein Swap (2GB) randvoll und der Rechner reagiert nur noch sporadisch und ruckelnd. Als Windowmanager läuft bei mir fluxbox, also müsste RAM ja locker vorhanden sein.
Ich muss das Bild in gimp öffnen, um zu überprüfen, ob nich mehr als 285% Farbe irgend wo hingemanscht wurden. Es soll ja schließlich an eine Druckerei gehen. Hat irgend jemand eine Idee, wie ich gimp das bei biegen kann?

Grüße

[DeletedUserReAsG]

Bei 2GB von „locker vorhandenem“ RAM zu reden, halte ich für gewagt; insbesondere bei diesen Bilddimensionen (4961x7016px, knappe 35 Megapixel, bei 10 Bit Farbtiefe). Entweder mehr RAM reintun, was die beste Option wäre, oder mehr Swap einhängen, was ‘ne Notlösung wäre, aber immerhin funktionieren würde – wenn auch sehr langsam.

[MSfree]

@niemand, 35 Megapixel bedeuten 105MByte RAM, was gerade einmal 5% des RAM sind. Also kein Grun zum Swappen.

Mir wird das komplette System lahm gelegt, wenn ich versuche in gimp 2.10 (debian testing) ein PNG in DIN A2 Größe, RGB 300 dpi zu öffnen.

Da täte mich dann doch interessieren, wie viele Pixel das Bild wirklich hat. Denn die 300DPI Angabe stimmt fast nie und DIN A2 ist keine geeignete Maßeinheit, um digitale Bilder zu beschreiben. Niemand hat ja ausgerechnet, daß ein 300DPI-Bild in DIN A2 etwa 35 Megalpixel hat. Auf den Wert bin ich auch gekommen, vermute aber, daß der DPI-Wert einfach nur aus den Fingern gesaugt ist.

Führe mal in einem Terminal den Befehl:

Code: Alles auswählen

file NameDerBildDatei.png

aus und berichte dann, wie viel Pixel das Bild hat.

[DeletedUserReAsG]

@niemand, 35 Megapixel bedeuten 105MByte RAM, was gerade einmal 5% des RAM sind. Also kein Grun zum Swappen.

Gimp lädt allerdings das Bild nicht einfach plain in den Speicher und lässt es auf den Monitor malen – wenn man das wollte, sollte man ’nen Bildbetrachter nehmen.

[ausfahrt]

@niemand, 35 Megapixel bedeuten 105MByte RAM, was gerade einmal 5% des RAM sind. Also kein Grun zum Swappen.

Mir wird das komplette System lahm gelegt, wenn ich versuche in gimp 2.10 (debian testing) ein PNG in DIN A2 Größe, RGB 300 dpi zu öffnen.

Da täte mich dann doch interessieren, wie viele Pixel das Bild wirklich hat. Denn die 300DPI Angabe stimmt fast nie und DIN A2 ist keine geeignete Maßeinheit, um digitale Bilder zu beschreiben. Niemand hat ja ausgerechnet, daß ein 300DPI-Bild in DIN A2 etwa 35 Megalpixel hat. Auf den Wert bin ich auch gekommen, vermute aber, daß der DPI-Wert einfach nur aus den Fingern gesaugt ist.

Führe mal in einem Terminal den Befehl:

Code: Alles auswählen

file NameDerBildDatei.png

aus und berichte dann, wie viel Pixel das Bild hat.

Also hier die Dateigröße:

Code: Alles auswählen

meineDatei.png: PNG image data, 5031 x 7087, 8-bit/color RGBA, non-interlaced

Das sind DIN A2 (+3mm Anschnitt) mit 300 dpi. Das PNG wurde so aus Inkscape importiert.

Ich habe das Problem gefunden:
Meine Grundeinstellung war, dass alle Bilder in 32bit-Fließkommazahl importiert werden. Dabei wurden bei dieser Größe mit einem Schlag 1,6 GB RAM in Beschlag genommen. Bei 8-bit sind es 332,3 MB. Auch wenn weiter keine großen Sachen den Arbeitsspeicher blockieren, und somit theoretisch zwar schon Swap gebraucht wird, aber noch Luft ist, scheint Gimp mit dieser Datenmenge nicht mehr ordentlich umgehen zu können. Früher gabs mal einen Bug, wo du mit Gimp eine große Datei erzeugst und dadurch root-Rechte erlangen kannst (weils dann auch in für root reservierte Speicherbereiche reinschrieb). Ich hoffe und habe zu wenige Ahnung zu wissen, dass das jetzt nicht so ein Fall ist.
Da Inkscape eh nur in 8-bit exportiert, ist ein Hochrechnen auf 32-bit sinnlos. Ich habs runtergesetzt und dann den Farbauftrag überprüft. Ob bei den Datenmengen und bei einem thinkpad t400 mehr RAM was bringen würden - wer weiß.

Danke für die Aufmerksamkeit

[ausfahrt]

@niemand, 35 Megapixel bedeuten 105MByte RAM, was gerade einmal 5% des RAM sind. Also kein Grun zum Swappen.

Gimp lädt allerdings das Bild nicht einfach plain in den Speicher und lässt es auf den Monitor malen – wenn man das wollte, sollte man ’nen Bildbetrachter nehmen.

Wenns einen Bildbetrachter mit Farbpipette gibt: her damit! Ich habs nicht gefunden.

[frogbert]

Ich benutze das hier:
gpick

[TuxPeter]

Ich habe auch mal aus sportlichen Gründen versucht, mittels Gimp das System lahmzulegen. Erstmal mit xsane ein buntes DIN-A4-Blatt in unsinnig hoher Auflösung und (unsinnigerweise) mit 16 Bit Farbtiefe gescannt und als ".PNM" gespeichert. Ergibt ein File von 850 MB.

Im Speicher von gimp nimmt das Bild 2.7 GB in Anspruch. Der PC ist ein Intel G4580 mit 3,5 GHz, 8 GB Speicher, kein Swap. Die Bearbeitung von Urlaubsfotos beispielsweise flutscht richtig gut durch. Auch dieses Monster wird dank SSD relativ flott geöffnet. Aber wenn ich damit eine etwas aufwendigere Operation durchführe, steht die Kiste. Naja, das System lebt noch, aber beispielsweise eine Konsole zum Killen zu bekommen, das dauert ... Und das Syslog zeigt hinterher an, dass schon vorher diverse gimp-Prozesse automatisch gekillt wurden.

Also: wenn man solche Monster bearbeiten will, brauchts schon etwas mehr Pep in der Hardware.

[sys_op]

Irgend wie müssig, über ein paar Pixel oder Farbtiefe zu diskutieren, wir sind im 21`sten Jahrhundert und das sind 2 GB RAM weniger als mein Telefon zur Verfügung hat.

RAM rein und gut is!

[heinz]

Wenns einen Bildbetrachter mit Farbpipette gibt: her damit! Ich habs nicht gefunden.

Nur als Tipp.
Es gibt auch den praktischen Konsolen-Befehl:

Code: Alles auswählen

grabc

Code: Alles auswählen

man grabc
grabc is s simple but very useful program to determine the color string
in hex (or in RGB components) by clicking on a  pixel  on  the  screen.

[CH777]

Wenns einen Bildbetrachter mit Farbpipette gibt: her damit!

Bei geeqie gibt es so eine Pipette.

[RobertS]

Ob bei den Datenmengen und bei einem thinkpad t400 mehr RAM was bringen würden - wer weiß.

Ich hab gestern auf meinem T500 ein JPG aus meiner Knipse geöffnet und ein wenig mit Farboptimierung gespielt. Also Spaß macht was anderes.
Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz mit 8GB.
Auf meinem Rechenknecht unterm Tisch werkelt ein Quadcore Vendor: "GenuineIntel"
Model: 6.58.9 "Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz" mit auch 8GB aber mit Nvidia Graka.
Der Rechenknecht hat weder Schirm noch Tastatur und darf per ssh -X auf meinen Schirm am T500 malen.
Das System händelt die 930MB im Speicher dann ganz ordentlich, auch möglich daß Gimp von der GPU Beschleunigung profitiert.

[MSfree]

Das System händelt die 930MB im Speicher dann ganz ordentlich, auch möglich daß Gimp von der GPU Beschleunigung profitiert.

Nein, Gimp nutzt keine GPU und es ist nicht einmal (durchgängig) multithreaded. Aber ein eizelner Core i5-3470-Kern ist dreimal so schnell wie ein Kern deines betagten Core2-Duo.