Freitag, 1. Oktober 2010

Dateiformat WebP - Messungen

Google hat heute ein neues Dateiformat für Fotos vorgestellt, dass das inzwischen doch arg in die Jahre gekommene JPEG ersetzen soll. Selbst mit 2 MBit sind Full-HD-Bilder nervig zu laden und können daher nicht mal eben in einem Text eingebunden werden. Dazu kommen Internet-Zugänge, bei denen aus eben diesem Grunde Bilder komplett abgeschaltet werden. In ärmeren Ländern teilt sich immer noch oft genug ein ganzes Dorf 56k - da sind Bilder, auf denen man auch Details erkennen kann, dann komplett nervig bis unmöglich. Einen Nutzen für ein solches Format gibt es also.

Allerdings ist für mich fraglich, ob das Format wirklich die erforderliche Verbesserung bringt - anzustreben wäre hier IMHO etwas im Bereich von unter 250 kB für Full-HD (wäre damit in <1s geladen).

Hierzu habe ich eine kleine Stichprobe mit dem Foto aus dem Wikipedia-Artikel zum 1928er Ford Modell A gemacht. Für die Erstellung der JPEG-Dateien wurde Gimp benutzt; hier mag es mit anderen Programmen Unterschiede geben. Die WebP-Dateien erzeugt das bei Google verfügbare Programm 'webpconv', wobei diese zur Betrachtung derzeit noch in PNG-Dateien zurück umgewandelt werden müssen, was aber aufgrund der Arbeitsweise des PNG-Formates die Qualität nicht beeinflusst.

Ergebnisse:
  • wie es da liegt, hat es 1.25MB
  • als PNG abgespeichert, wiederum in Gimp (höchste Komprimierungsstufe, wobei diese nicht die Qualität, sondern nur den Rechenaufwand beeinflusst) werden es 4MB. Diese Datei dient als Ausgangsmaterial für die weiteren Konvertierungen.
  • für JPEG-Dateien benutze ich selbst normalerweise 85%, was 722 kB ergibt.
  • als 75% JPEG (da wird es dann langsam schlechter, besonders anfällig ist das Hinweisschild im Hintergrund, wo auf der grünen Fläche Datenmüll entsteht) sind wir bei 536 kB.
  • WebP versucht sich selbst mit 82% Qualität, hierbei ergibt sich eine Größe von 468 kB. Auffällig war die im Vergleich zu den Konvertierungsvorgängen mit einer von mir vorgegebenen Qualitätsstufe deutlich längere Arbeitszeit – dies liegt daran, dass 'webpconv' die ideale Bildqualität über das Rauschverhalten des Bildes ermittelt.
  • WebP mit 100% liefert 1MB
  • 75%-WebP sieht immer noch gut aus und liefert 384 kB.
  • und einmal die Schmerzgrenze überschritten: 50% WebP. Man sieht Verluste (wieder an dem Schild, diesmal wird es unscharf), aber eindrucksvolle 223 kB.
Die Realität im Internet (100% JPEG) liefert also 1,25 MB. Diese Dateien werden nach dem Grundsatz "viel hilft viel" von den Kameras selbst erstellt. Dort kommt es ja auch auf den Platz nicht an. Mit JPEG selbst kriegt man das ganze auf 722 kB runter (die oben genannten 85%). Darunter fängt bei jedem Bild etwas anders die Schmerzgrenze an, so dass man manuell probieren müsste.

Wenden wir die "viel hilft viel"-Methode nun auf WebP an, sind wir bei 1 MB, also schonmal 20% Gewinn. Dank des mitdenkenden Konvertierungstools fallen aber eben keine 100%-Dateien an, sondern diese sind schon leicht in der Qualität, aber sehr stark in der Größe verkleinert. Somit landet man ohne größere Experimente bei 468 kB – deutlich kleiner, als bei einem JPEG mit manueller Optimierung denkbar wäre (selbst die Datei jenseits der Schmerzgrenze ist noch größer!). Die angestrebten 250 kB sind hier allerdings nicht erreichbar.

Noch ein anderer Versuch ist interessant: Das Logo von heise-Online. Derzeit eine 3,3 kB-Große GIF-Datei. Bereits als PNG schrumpft sie auf 2,6 kB. Ein 85%-JPEG ist mit 2,7 kB minimal größer; wobei ob der extrem einfachen Bildstruktur bereits hier Artefakte auftreten, so man die Datei vergrößert - bei normaler Größe sieht man sie dagegen nicht, da die Abweichungen zu klein sind. Ein recht ähnliches optisches Egebnis liefert auch WebP, dass hier 62% nehmen will. Der Hit ist aber die Dateigröße: Dieses Format liegt mit 1014 Byte knapp unter 1 kB! Hier ist die Einsparung also mehr als 2/3…

Ein deutlich kritischeres Fazit zieht ein x264-Entwickler in seinem Blog, was ob der Konkurrenzsituation zwischen beiden nicht so gänzlich verwundert. Dort hat man ein Bild aus einem Full-HD-Film genommen, welches als 100%-JPEG recht erstaunliche 3,3 MB liefert – weit mehr als das Doppelte von meinem Versuchsobjekt. Die Frage war zudem nicht "wer ist bei gleicher Qualität kleiner?", sondern das Gegenstück "wer ist bei gleicher Größe besser?". Die hierbei angestrebte Größe von 150 kB kann man gewiss als mehr als ambitioniert ansehen, entsprechend sehen alle Ergebnis-Bilder scheiße aus. Die Schreiber dort sind nun allerdings der Meinung, dass das JPEG-Bild "hübscher tot komprimiert" sei… An der gleichen Datei habe ich nun einmal den umgekehrten Weg erprobt: webpconv mit seiner Automatik fördert hier nun 85% und 640 kB zu Tage, ein 85%-JPEG ist mit 846 kB dagegen deutlich größer.

Dieser scheinbare Wiederspruch erklärt sich in der unterschiedlichen Art der Bildfehler. Ein WebP wird mit stärkerer Komprimierung unscharf - ein Merkmal, dass auch durch schlechte Fotografen entstehen kann, weshalb es ohne direkten Vergleich erst auffällt, wenn es sehr stark ausgeprägt wird; dann aber umso mehr. JPEG neigt dagegen zu "komischen Mustern auf glatten Flächen". Diese können auf keine andere Art entstehen, so dass man sofort erkennt "dieses Bild wurde zu stark komprimiert". Werden diese Muster stärker, ändert sich nichts mehr an der Bildwahrnehmung.

Für den Alltag halte ich den Ansatz einer angestrebten Qualität, zu der dann die Größe gesucht wird, für häufiger als den, wo die Größe vorgegeben wird.

Kommentare:

Spacy hat gesagt…

Interessanter Artikel. Den Rechtschreibfehler mit dem "Unternet" solltest du vielleicht noch korrigieren.

Ich finde die Methode mit dem Vergleich der Qualität bei minimaler Dateigröße auch Schwachsinn. In der Regel verwendet niemand die minimale Dateigröße, weil er sich den Upload des Bilds dann genauso gut hätte sparen können.

Anonym hat gesagt…

Kann es sein dass webpconv die Farbtiefe des heise-Logos auf 4 Bit runtergeschraubt hat? ;-)