Web-Bildformate

Beim Einstieg dieses Artikels wird einem schonmal ganz anders: Für ein einfaches Laden der Website moto.oakley.com brauchte jemand fast 89 MB. Heute sind es immerhin noch 15 MB. Hauptgrund sind vor allem die Bilder. Wie kann man diese also verkleinern? Bei großen Mengen an Bilder sollte dies – natürlich – möglichst schnell und automatisiert vonstattengehen. Ich werde dabei ein paar Programme aus dem oben bereits verlinkten Artikel testen.

JPEG

Als erstes Format kommt JPEG in Frage. Es ist wohl das populärste Rastergrafikformat, denn es wird beispielsweise in so gut wie allen Kameras verwendet.

JPEGrescan

JPEGrescan benötigt nur perl und das perl-Modul (file-)slurp. Unter Linux-Distributionen geht die Installation damit schnell vonstatten.

Das Ziel von JPEGrescan ist dabei, den Komprimierungsrad der JPEGs so anzupassen, dass wirklich kein Datenverlust – in Form von zum Beispiel Artefakten – auftritt. Dementsprechend fallen auch die Größeneinsparungen meist in den einstelligen Prozentbereich.

Kompilieren muss man hier nichts, sondern kann nach dem Herunterladen des Skripts sofort loslegen. Dazu braucht es nur ein einfaches

1
$ jpegrescan in.jpg out.jpg

adept-jpg-compressor

Ein alternatives Werkzeug ist adept-jpg-compressor. Es ist eigentlich nur ein einfaches Shellskript, welches das Bild zuerst aufteilt. Anschließend wird einzeln probiert, wie stark jeder Teil komprimiert werden kann, um noch die gleiche Qualität zu bieten. Zum Schluss wird das Bild wieder zusammengesetzt. Vorteil: Nicht jeder Bildteil muss gleich stark komprimiert werden. Eine ausführlicherer und bebilderte Beschreibung gibt es in der README auf GitHub.

Die Programmabhängigkeiten belaufen sich überdies auf ImageMagick, jpegoptim, dem weiter oben genannten JPEGrescan und einigen „Standard-Shell-Tools“. Damit ist die Installation und Ausführung simpel: Einfach nur das Shellskript herunterladen und per

1
bash adept.sh /path/to/image.jpg

im selben Ordner starten. Das angepasste Bild wird im selben Verzeichnis mit dem Namenssuffix „adept_compress.jpg“ gespeichert.

Leider fiel in meinem Test die „adepted“ Version des Bildes größer aus als das Original. Möglicherweise hängt dies mit der Fehlermeldung von ImageMagick zu Fonts zusammen. Allerdings habe ich dazu keine weiteren Infos oder eine Lösung gefunden.

PNG

PNG unterscheidet sich vor allem in zwei Punkten gegenüber JPEG:

  • Unterstützung von Transparenz
  • verlustfreies Bildformat (d. h. keine Artefakte)

Der gesamte Verkleinerungsprozess gliedert sich bei PNGs in drei Schritte – und damit drei Programme.

Verlustbehaftete Kompression

Das Programm meiner Wahl beim verlustbehafteten Komprimieren war pngquant2. Es reduziert vor allem die Anzahl der verwendeten Farben, nämlich von 24-bit auf maximal 8-bit (also 256 Farben). Einerseits ist die geringe Anzahl an Farben bei einem direkten Vergleich zwischen Original und deutlich sichtbar. Allerdings wird die Größe des Bildes auch deutlich verkleinert – was bei Bildern für das Web meiner Meinung nach höher wiegt.

Von Version 1.0, die sich noch in Quellen zahlreicher Linux-Distributionen findet, wird indes abgeraten. Beispielsweise wird pngquant2 erst ab Ubuntu 14.04 in den offiziellen Quellen liegen. Daher bleibt nur der Weg von Fremdquellen oder des Kompilierens (siehe dazu weiter oben die verlinkte Website).

Die grundlegende Anwendung erfolgt dabei über

1
pngquant <Datei_zum_Komprimieren.png>

Außerdem verwende ich immer den Parameter -s1. Dies verlängert die Komprimierungszeit ein wenig, erhöht die Qualität allerdings auf ein Maximum. Ein Beispiel findet sich auch hier im Archiv mit den Testbildern unter Spiel/png/speed-fs8. Ferner kann man mit der Anzahl der Farben spielen, um so ggf. ein kleineres Resultat zu erhalten:

1
pngquant <AnzahlFarben> <Datei_zum_Komprimieren.png>

Im Archiv mit allen Testbildern gibt es dazu ein paar Beispiele unter Spiel/png/numberofcolors. Die komprimierten PNGs erhalten immer den Zusatz -or8.png oder -fs8.png.

Filter

Der nächste Schritt ist das Herausfinden des besten Filters.

pngwolf

pngwolf wollte bei mir einfach nicht durch den Compiler und damit auch nicht verwendet werden… Im Folgenden dennoch mein Vorgehen – vielleicht liegt der Fehler einfach bei mir:

  1. Sourecode von GitHub holen
  2. drei Abhängigkeiten herunterladen

    • GAlib: http://lancet.mit.edu/ga/dist/
    • 7-Zip: http://www.7-zip.org/download.html
    • zlib: http://zlib.net/
  3. Ablegen der heruntergeladenen Archive als Unterverzeichnis des Sourcecodes von pngwolf

  4. Umbenennen der drei Ordner in galib, 7zip und zlib
  5. Patch anwenden

    1
    $ patch -p 0 < sevenzip920.patch
    
  6. erhält Fehler vom Patchen → ignoriert

  7. CMake im Ordner von pngwolf ausführen

    1
    $ cmake CMakeLists.txt
    
  8. eigentliches Make (immer noch im selben Verzeichnis)

    1
    $ make
    

Auch ein Skript gab das selbe Resultat. Scheint aber mehr Leuten so zu gehen.

optipng

Die Alternative war dann optipng. Dieses Programm gibt es wiederum in eigentlich jedem Paketrepositorium, zum Beispiel Ubuntu oder Arch Linux. Die Installation ist damit schnell vollbracht.

Der Programmaufruf ist per

1
optipng -out Bild_opti.png Bild.png

möglich. Die Ausgabe erfolgt dann in Bild_opti.png.

Den Komprimierungsgrad kann man dabei über eine Option -o[N] festlegen. [N] kann durch eine Zahl zwischen 0 und 7 ersetzt werden, wobei 7 am längsten dauert und somit am besten komprimiert. Standardeinstellung ist 2.

Als Beispiel habe ich mal die Ergebnisse ein und des selben Bildes verglichen. Mit der Option -o7 benötigte mein Rechner 3 Minuten 33 Sekunden. Mit den Standardoptionen 13,8 s. Die Dateigröße hat sich dabei um gerade mal 9,1 kByte verändert – beide Ausgaben des Spielscreenshots sind dabei annähernd 3 MB groß. (im Archiv mit allen Testbildern finden sich die Bilder unter Spiel/png/optipng-test-o-Option) Ob sich die längere Verarbeitungsdauer also lohnt, muss jeder selbst entscheiden.

Verlustfreie Kompression

Letzter Schritt ist das verlustfreie Komprimieren. Interessant ist hier zopfli. Das verwendete Verfahren ist zu zlib kompatibel, die Dateien werden dabei allerdings um 5 % kleiner. Jedoch verlängert sich die Komprimierungsdauer.

Zur Installation das Archiv von Google Code herunterladen und, solange man nur zopflipng verwenden möchte, ein

1
make zopflipng

ausführen. Nach dem Kompilieren landet das Programm betriebsbereit im selben Ordner. Der einfachste Befehl ist dabei für ein Bild:

1
./zopflipng infile.png outfile.png

Eine längere Liste an Parametern, die auch Filter umfasst, findet sich dann unter ./zopflipng -h. Dafür, dass die Entwickler es als Alpha-Release bezeichnen, arbeitet es in einem ersten Test wirklich stabil.

Onlinetools

Die Onlinetools sind nur für einen Vergleich gedacht. Ich persönliche rate von diesen Diensten ab, weil man a) bei der Menge an zu verkleinernden Bildern begrenzt ist b) (ein kleineres Problem) nicht weiß, was die Dienste mit den Daten machen.

JPEGmini

JPEGmini ist – nach dem Namen eigentlich klar – zum Verkleinern von JPEG-Bildern gedacht. Auf der Startseite wird direkt mit Beispielen geworben, wie viel man durch JPEGMini sparen kann. Das Prinzip ist dabei eigentlich das selbe wie bei den anderen Programmen: den Komprimierungsgrad möglichst hoch und damit die Bildgröße klein halten. Nur soll es hier nicht mathematisch identisch sein, sondern „nur“ für das menschliche Auge identisch erscheinen.

Tinypng

der charakteristische Panda von tinypng

tinypng ist dagegen für PNGs gedacht. Es setzt dabei ähnlich wie pngquant auf eine Reduktion der PNGs auf 8-bit.

Auswertung

Screenshot eines Spieles

Eine kleine Vorbemerkung: Im Nachhinein gesehen ähnelt dieser Screenshot wohl eher einem Foto statt einem „normalen“ Screenshot mit viel gleichfarbiger Fläche. Dafür gibt es noch ein zweites Beispiel im Anschluss.

PNG-Vergleich zum Spiel-Screenshot
Bild verwendete(s) Programm(e) Größe in kB
Original Screenshot per Druck-Taste unter Windows in RAM, anschließend gespeichert mit GIMP 3380
auf 256 Farben pngquant2 942
pngquant2 → optipng 924
pngquant2 → optipng → zopfli 878
tinypng 872

Gerade pngquant verkleinert das Bild immens. Von anfänglich 3380 kB auf 942 kB – das sind über 72 %. optipng und zopfli verkleinern das erhaltenen Bild um weitere 6,8 %. Mit 878 kB in der Endfassung sind die drei Werkzeuge zusammen annähernd so gut wie tinypng. Die 6 kByte Unterschied kann man gerade noch verschmerzen. ;) Allerdings ist das immer noch ein riesiger BLOB gegenüber JPEG…

JPEG-Vergleich zum Spiel-Screenshot
Bild verwendete(s) Programm(e) Größe in kB
Originales JPEG konvertiert aus PNG mit ImageMagick 656
manuell komprimiert mit GIMP 492
JPEGrescan 617
adept compress 769
JPEGmini 454

JPEGMini kommt hier auf eine Dateigröße von circa 454 kB – das Ergebnis ist somit fast halb so groß wie das kleinste PNG-Bild. Das JPEGMini-Bild ist meiner Meinung nach qualitativ etwas schlechter als das manuell angepasste – aber dennoch finde ich das Resultat für ein Stück Software beachtlich. Man muss zudem, um Unterschiede überhaupt erkennen zu können, schon stark bei beiden Bildern zoomen.

JPEGrescan und adept_compress können dagegen nicht sehr viel Platz gut machen. Letzteres Werkzeug vergrößert das Bild in diesem Fall sogar.

Screenshot eines Programms

Bei einem Screenshot mit Programmen sieht die Sache dagegen anders aus: Hier kann pngquant seine volle Stärke ausspielen, da nicht wirklich mehr wie 256 Farben verwendet werden. Einzig die Programmicons auf der linken Seite schauen etwas schlechter aus. Zudem bietet hier PNG generell den Vorteil, dass die Schrift auch bei höheren Zoomstufen noch knackig scharf aussieht.

Bei JPEG erscheint dagegen mit zunehmender Komprimierung ein „grieseliger“ Schatten um die Schrift. Bei der manuellen Verkleinerung mit GIMP war ich also vor allem dadurch beschränkt. In dem Beispiel habe ich versucht, dieses Phänomen in einem akzeptablen Rahmen zu halten.

Unter anderem deshalb liegt der Größenunterschied zwischen dem JPEG und dem originalen PNG nur bei 44 kB. Das optimierte PNG-Bild dagegen ist mit 116 kB wesentlich kleiner gegenüber den anfänglichen 380.

Übersicht Dateigrößen zu Programm-Screenshots
Bild verwendete(s) Programm(e) Größe in kB
Original (mitgeliefertes Screenshot-Tool von Ubuntu 12.04) 380
JPEG manuelle Komprimierung mit GIMP 336
optimiertes PNG pngquant → optipng → zopfli 116

Fazit

Sollte das Bild also keine Transparenz beinhalten, werde ich Bilder im JPEG-Format abspeichern. Grund ist, dass JPEG in Summe meistens kleiner ausfallen bei annähernd ähnlicher Bildqualiät. Ausnahmen bilden hier Screenshots mit viel gleichfarbiger Fläche. PNG scheint da einfach unschlagbar zu sein.

Wenn es nicht allzu viele Bilder auf einmal sind, habe ich zudem vor, JPEGs manuell zu verkleinern. Zumindest kam ich hier mit Augenmaß auf eine ähnliche Dateigröße wie JPEGMini. Das bietet zudem den Vorteil, dass man Bilder auch zurecht schneiden kann. Damit bleibt der Fokus, gerade auf mobilen Geräte mit kleinem Bildschirm, auf das wichtigste Motiv erhalten.

Ansonsten gibt es aber auch genügend Methoden für die Kommandozeile – und damit ist der Prozess leicht automatisierbar.

Weiterführende Infos und Werkzeugliste für Formate wie svg oder gif

Kommentare

Noch kein Kommentar zu diesem Artikel.

Neuen Kommentar schreiben