Letzten Monat habe ich mit fast 23GB Traffic meinen „Inklusivtraffic“ von 25GB überschritten. Zeit, das Blog etwas aufzuräumen und Bilder zu verkleinern. Da sich hier ein paar hundert Bilder und deren Thumbnails angesammelt haben, soll das Verfahren möglichst automatisch ablaufen und das Ergebnis in möglichst kleinen Bildern resultieren, die dennoch gut aussehen.
Mit Imagemagick, Gimp, optipng und pngcrush stehen ein paar Kandidaten zur Auswahl, die hier Besserung versprechen. Erst einmal gilt es jedoch herauszufinden, welches Programm am besten komprimiert. Als Vorlage benutze ich diesen Screenshot.
Ich denke das Bild ist ein gutes Beispiel für Screenshots von Anwendungsprogrammen. Im Original hat das Bild eine Größe von 68966 Bytes. Diesen Wert gilt es also deutlich zu verbessern.
Gimp
Als erstes muss sich Gimp beweisen. Am einfachsten reduziert man die Größe eines PNG-Bildes, indem man die Farbpalette reduziert. Gimp kann eine optimale Palette erzeugen und so eine auf das Bild angepasste Palette produzieren. Die Funktion findet sich unter Bild | Modus | Indiziert | Optimale Palette erzeugen und schrumpft das Bild auf 27026 Bytes ein, d.h. das mit GIMP erzeugte Bild hat nur noch rund 39% der ursprünglichen Dateigröße ohne dass das Bild groß dabei leidet.
Imagemagick
Als nächstes kommt convert aus dem Paket Imagemagick auf die Testbank. Erst einmal versuche ich wieder die Farbpalette zu reduzieren.
$ convert -colors 16 orig.png convert_colors16.png
$ convert -colors 256 orig.png convert_colors256.png
Das Ergebnis ist unter aller Katastrophe, die Bilder sind größer als vorher. Das auf 16 Farben reduzierte Bild hat 103425 Bytes und das mit 256 Farben 184634 Bytes. Convert komprimiert wohl die Bilder nicht per Default, dies muss man mit der Option –quality erst aktivieren. 1000 steht dabei für die höchstmögliche Kompression.
$ convert -colors 16 -quality 1000 orig.png convert_colors16_quality1000.png
$ convert -colors 256 -quality 1000 orig.png convert_colors256_quality1000.png
Auch hier ist das Ergebnis wieder schlecht. Das 16 Farben Bild läuft danach mit 56196 Bytes in Ziel, das Bild mit 256 Farben mit 85889 Bytes. Ergebnis: convert kann keine optimale Palette erzeugen. Dadurch sieht das Bild schrecklich aus und ist dennoch größer als es sein müsste…
optipng
optipng ist ein Programm, dass speziell zum Optimieren und Verkleinern von .png Bildern geschrieben wurde. Es lässt sich in Ubuntu und Debian aus den Paketquellen installieren. Ich komprimiere einmal das „Original“ und einmal ein Bild, das ich vorher mit convert auf eine Palette mit 256 Farben komprimiert habe.
$ optipng -k orig.png
$ optipng -k convert_colors256_quality1000.png
Auch hier ist das Ergebnis wieder mager. optipng komprimiert die Vorlage auf 63539 Bytes, also auf rund 92% des ursprünglichen Bildes. Das Bild mit 256 Farben wird von 184634 Bytes auf 85620 Bytes komprimiert. Gut, wenn man sich die 50% Ersparnis ansieht. Doch schlecht, wenn man bedenkt, dass GIMP ein 27kb großes Bild erzeugen kann…
pngcrush
Alternativ zu optipng gibt es pngcrush. Das Programm findet man ebenso in den Quellen. Auch hier komprimiere ich einmal das Original und einmal das mit Convert auf 256 Farben reduzierte Bild.
$ pngcrush -c 3 -brute orig.png pngcrush.png
$ pngcrush -c 3 -brute convert_colors256_quality1000.png pngcrush_convert_colors256_quality1000.png
Das Ergebnis deckt sich praktisch völlig mit optipng. Einmal bekomme ich 63793 Bytes und einmal 85889 Bytes. Wieder alles deutlich größer als Gimp…
Script-Fu
The Gimp ist also wohl nicht zu schlagen. Kein anderes Programm schafft es auch nur annähernd, in die Reichweite der Größenreduktion von Gimp zu kommen. Einen Haken hat die Sache allerdings… Ein paar Hundert Bilder in Gimp zu laden und sich durch die Menüs zu hangeln? Das wäre enorm viel Klickarbeit.
Aber wozu hat Gimp einen Modus mit dem man eigene Skripte ausführen kann? Mit Script-Fu kann man Gimp komplett über Skripte bedienen. Im uu.de Forum hatte mir ein guter Geist schon einmal ein Skript geschrieben, das für alle .png Dateien in einem Ordner eine optimale Palette erzeugt. Es hatte noch eine Fallunterscheidung gefehlt, die die Indizierung nur auf Bilder loslässt, die noch nicht indiziert wurden. Doch jetzt klappt das 🙂 Wer so etwas sucht, der speichert das Skript…
(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))
)
)
)
…in ~/.gimp-2.6/scripts/batch-generate-optimum-palette ab. Danach kann man es über
$ gimp -i -b '(batch-generate-optimum-palette "*.png" 0 0 256 TRUE TRUE "")' -b '(gimp-quit 0)'
ausführen. Alle .png Bilder, die sich im aktuellen Ordner der Shell befinden, werden dann automatisch optimiert. Legt man dazu noch ein Alias für die Shell an, so hat man ein perfektes Werkzeug um Bilder in großen Massen für das Web aufzubereiten. So habe ich hoffentlich noch etwas Zeit, bis ich den nächst höheren Hostingtarif wählen muss.
Schreibe einen Kommentar