Codec-Vergleiche sorgfältig abwägen

Als bekannt wurde, dass Chrome die JPEG-XL-Experimente einstellt (https://de.news.hada.io/topic?id=7709), wurde der Issue-Tracker mit Fragen überschwemmt, warum man es entferne. Daraufhin hatte die AVIF-Seite einmal Benchmark-Material veröffentlicht, das ihre eigene Vergleichsstudie untermauern sollte (https://storage.googleapis.com/avif-comparison/index.html). Dieser Artikel analysiert dieses Material und enthält die Gegenargumente der JPEG-XL-Seite.

Unabhängig davon, ob man JPEG XL befürwortet oder ablehnt, ist der Text lesenswert, weil er wichtige Punkte beim Vergleich von Bildformaten herausarbeitet. Einige Kernaussagen in Kürze:

• Die von AVIF angegebene Dekodiergeschwindigkeit basierte auf Chrome und einer alten Version von libjxl und ist daher übertrieben. Nach aktuellem Versionsstand gilt: JPEG XL (Standardeinstellung) ~= 12-Bit-AVIF < JPEG XL (schnelle Dekodier-Einstellung) ~= 8-Bit-AVIF < aus JPEG neu komprimiertes JPEG XL, wobei jede Ungleichung nur etwa 10 % Unterschied bedeutet.

• Wichtiger als die gesamte Dekodiergeschwindigkeit ist, ab welchem Zeitpunkt ein nutzbares Bild erscheint. JPEG XL unterstützt progressives Dekodieren und hat hier daher einen großen Vorteil. (Das ist derselbe Kontext wie Diskussionen über Largest Contentful Paint im Web.)

• Kodierleistung und Qualität des kodierten Bildes werden getrennt verglichen. libjxl kann Kodierleistung und Kodierqualität jedoch vollständig unabhängig voneinander steuern, während das bei AVIF und den meisten anderen Encodern nicht möglich ist. Deshalb lässt sich ein solcher Vergleich nicht einfach übertragen.

• Der angegebene Zielqualitätsbereich beim Kodieren ist zu breit und berücksichtigt keine Wahrscheinlichkeitsverteilung. Die als "On the fly" bezeichnete niedrigste Qualität ist so schlecht, dass sie praktisch für keinen Zweck verwendbar ist. Außerdem ist AVIF im Durchschnitt zwar bei Bildern niedriger Qualität stark, doch schon bei etwas größeren Dateigrößen liegt JPEG XL oft deutlich vorn. Durch eine ungeeignete Mittelwertbildung wurden diese Stärken von JPEG XL verwässert.

• Der für den Test verwendete Datensatz ist ungeeignet. Für verlustfreie Kompression wurde der gescannte Magazinbild-Datensatz Kodak verwendet, und für verlustbehaftete Kompression war unter anderem der Noto-Emoji-Datensatz enthalten, der normalerweise eher für Vektorgrafik oder verlustfreie Kompression verwendet wird. Beides sind keine typischen Anwendungsfälle für verlustfreie bzw. verlustbehaftete Kompression.

• Wenn die Diskussion über Bildkompressionsleistung die Gegenwart betrifft, dann betreffen die von einem Bildformat unterstützten Funktionen die Zukunft. Wenn sich ein einmal in den Browser aufgenommenes Bildformat nicht wieder entfernen lässt, sollte man es bei der Bewertung umso stärker anhand seiner Funktionen beurteilen.

[lifthrasiir]

Da ich das vor der Arbeit hastig geschrieben habe, gibt es ein paar kleinere Fehler (...): Streng genommen bedeutet „on the fly“ nicht die niedrigste Qualität, sondern die höchste Geschwindigkeit (bei den meisten Encodern außer JPEG XL besteht allerdings eine umgekehrte Korrelation zur Qualität). Außerdem habe ich den Kodak-Datensatz, warum auch immer, als Zeitschrift bezeichnet, tatsächlich wurde er aber von Film eingescannt.

[xguru]

Die Vorteile von JPEG XL