ubuntuusers.de

Ich möchte den Vorgang innerhalb von Gimp

Bild → Modus → Indiziert → Optimale Palette erzeugen

gerne über convert/mogrify realisieren. Doch wie würde die Option dafür heissen? Die man-page alleine hilft mir nicht weiter... Hintergrund: Ich habe einen Ordner mit zig .png Bildern. Diese möchte ich nun automatisch durch die Reduktion der Farbpalette verkleinern...

Danke
Christoph

Hallo Christoph,

ob Imagemagick genau die Funktion "Optimale Palette erzeugen" zur Verfügung stellt, weiß ich nicht, ich glaube es eher nicht.

Aber man kann auch Gimp im Batch-Modus betreiben, es sind allerdings ein wenig Scheme-Kenntnisse erforderlich. Ein (sehr) kleines Tutorial findet sich hier: http://gimp.org/tutorials/Basic_Batch/
Das dort angeführte Beispiel müsste sich leicht anpassen lassen. Die Funktion, die du benötigst, findest du in Gimp über "Extras" → "Prozeduren-Browser": gimp-image-convert-indexed.

Soweit ich weiß, erzeugt imagemagick automatisch eine optimale Palette, wenn du

convert -colors X input.png output.png

ausführst. Wenn du eine feste Palette benötigst, dann musst du wohl -map verwenden.

@Pumbaa80
Das mit "-colors X" klappt nicht. Siehe

convert -colors X kde.png kde_test.png
convert: option requires an argument `-colors'.

Unter

http://www.imagemagick.org/script/command-line-options.php#colors

ist das leider auch nicht dokumentiert.

@snlake
Danke dir, schaue ich mir mal an.

Du musst natürlich X durch die gewünschte Anzahl der Farben ersetzen ☺

Du musst natürlich X durch die gewünschte Anzahl der Farben ersetzen ☺

Dann ist das jedoch nicht die optimale Palette 😉 Denn die benötigt keine definierte Anzahl von Farben. Des weiteren wird das Bild - vor allen Dingen Screenshots - eher aufgebläht. Ich mache nen Screenshot

test1.png 88,2 KB (90290 Bytes)

Nun konvertiere ich das Bild

$ convert -colors 256 test1.png test1_256.png

test1_256.png 323,7 KB (331485 Bytes)

$ convert -colors 16 test1.png test1_16.png

test1_16.png 156,3 KB (160092 Bytes)

Selbst mit 16 Farben ist das Bild größer als das Original. (Und sieht dazu noch scheisse aus 😉 ) Das mit Gimp auf die optimale Palette reduzierte Bild hätte nur 27kb ohne dass die Bildqualität in irgeneiner Weise darunter leiden würde...

Chrissss hat geschrieben:

> Du musst natürlich X durch die gewünschte Anzahl der Farben ersetzen ☺

Dann ist das jedoch nicht die optimale Palette 😉 Denn die benötigt keine definierte Anzahl von Farben.

Bei GIMP schon. Okay, es heißt "maximale Anzahl", aber ich denke, dass das auch convert so handhabt.

Das mit der Bildgröße lässt sich bestimmt mit irgendeinem Kompressionsparameter hinbiegen. Spontan tippe ich auf

convert -colors 256 -quality 1000 foo.png bar.png

Das mit der Bildgröße lässt sich bestimmt mit irgendeinem Kompressionsparameter hinbiegen. Spontan tippe ich auf

Mit der "-quality" Option hatte ich auch schon sehr viel rumgespielt, doch nie komme ich auch nur in die Nähe davon, was mir Gimp liefert. Das Wiki Team hatte ja auch schon mit diesem Phänomen zu kämpfen und es afaik bislang nicht lösen können.

Sicherlich nicht der Weisheit letzter Schluss, aber was wäre mit

convert testbild.png -unique-colors -depth 16  txt:-

die Farben rauszufinden, das ganze mit wc zu zählen und dann mit

convert testbild.png -colors $anzahl verändertes.png

zu optimieren?

Ich werfe das einfach mal so in die Runde:

http://optipng.sourceforge.net/
http://pmt.sourceforge.net/pngcrush/
http://www.jonof.id.au/index.php?p=kenutils

fnordschrat hat geschrieben:

http://optipng.sourceforge.net/
http://pmt.sourceforge.net/pngcrush/
http://www.jonof.id.au/index.php?p=kenutils

Sind interessante Programme. Aber in meinen ersten Tests optimieren sie das Bild nur "verlustfrei". Sprich die Dateigröße geht runter. (Ein Screenshot bspw. um rund 25%) Aber ich will ja ne verlustbehaftete Konvertierung. Mit Gimp erreicht man eine Reduzierung von rund 66% ohne dass die Bildqualität eines Screenshots arg leidet.

Das ganze aneinanderzureihen ist auch noch nicht ideal

$ convert -colors 256 test1.png | optipng test1.png

Das Bild ist immer noch grösser als das Original und deutlich grösser als das von Gimp erzeugte Bild. Ich denke ich muss mir wirlich den Batch Modus von Gimp ansehen 😉

... sofern du es mit Gimp machen willst, habe schließlich lange genug nach dem "ignored" Parameter gesucht, "werfe" ich mal das dazu:

Als batch-generate-optimum-palette.scm in /.gimp-2.4/scripts speichern:

(define (batch-generate-optimum-palette pattern
			                                         dither-type
                                                                 palette-type
                                                                 num-cols
                                                                 alpha-dither
			                                         remove-unused
			                                         palette)
(let* ((filelist (cadr (file-glob pattern 1))))
    (while (not (null? filelist))
           (let* ((filename (car filelist))
                  (image (car (gimp-file-load RUN-NONINTERACTIVE filename filename)))
                  (drawable (car (gimp-image-get-active-layer image))))
             (gimp-image-convert-indexed image dither-type palette-type num-cols alpha-dither remove-unused palette)
	     (set! drawable (car (gimp-image-get-active-layer image)))
             (gimp-file-save RUN-NONINTERACTIVE image drawable filename filename)
             (gimp-image-delete image))
           (set! filelist (cdr filelist)))))

Zum Ordner mit den PNGs navigieren und

gimp -i -b '(batch-generate-optimum-palette "*.png" 0 0 256 TRUE TRUE "")' -b '(gimp-quit 0)'

Die PNGs werden überschrieben. Bitte an Kopien testen...

Grüße

Andreas

ntars_68, danke schonmal. Es läuft, bricht aber recht schnell ab.

$ gimp -i -b '(batch-generate-optimum-palette "*.png" 0 0 256 TRUE TRUE "")' -b '(gimp-quit 0)'
PNG-Bild-Warnung: Die Transparenz konnte nicht ohne Verluste gespeichert werden, sie wird stattdessen als deckend gespeichert.

PNG-Bild-Warnung: Die Transparenz konnte nicht ohne Verluste gespeichert werden, sie wird stattdessen als deckend gespeichert.

batch command: experienced an execution error.

(gimp:10303): Gimp-Base-WARNING **: tile cache not empty (307200 bytes left)

Morgähn,

habe den Fehler ein paar Mal gesehen, als ich noch mit den Werten für die Parameter am "Kämpfen" und Testen war.

Bei mir läuft es mit obiger Vorgehensweise. Hardy - Gimp-2.4.5.
Ich denke, dieser Fehler tritt auf, wenn in dem Ordner ein bereits indiziertes PNG liegt.
Da fehlt noch eine Abfrage... wenn indiziert, dann nichts tun ... - oder?

Übrigens hat David's Batch Processor für Gimp (seit Hardy im Paket "gimp-plugin-registry") etwas Ähliches an Bord.
Zu finden unter Extras - Batch Process... und dann auf dem Reiter "Rename".

Grüße

Andreas

Alter Thread, aber ich belebe ihn nochmal. Danke ntars_68 nochmal für deine Hinweise. Hab eine Fallunterscheidung eingebaut. Jetzt läuft das Skript auch durch, wenn schon indexierte Bilder im Verzeichnis liegen...

(define (batch-generate-optimum-palette pattern
	dither-type
	palette-type
	num-cols
	alpha-dither
	remove-unused
	palette
	)

	(let* ((filelist (cadr (file-glob pattern 1))))
		(while (not (null? filelist))
			(let* (
				(filename (car filelist))
				(image (car (gimp-file-load RUN-NONINTERACTIVE filename filename)))
				(drawable (car (gimp-image-get-active-layer image)))
			)
			(if (= FALSE (car (gimp-drawable-is-indexed drawable)))
				(gimp-image-convert-indexed image dither-type palette-type num-cols alpha-dither remove-unused palette)
				)
				(set! drawable (car (gimp-image-get-active-layer image)))
				(gimp-file-save RUN-NONINTERACTIVE image drawable filename filename)
				(gimp-image-delete image)

			)
			(set! filelist (cdr filelist))
		)
	)
)