JPEG XL im Vergleich zu AVIF, WebP und JPEG Bildkompression für das Web

Anbieter zum Thema

PANDUIT

Rittal GmbH & Co. KG

Rosenberger-OSI GmbH & Co. OHG

Während Google das Bildformat JPEG XL aufgab, überraschte Apple damit, das Format in Safari und seinen Betriebssystemen zu unterstützen. Trägt dies zur weiten Verbreitung des Formats bei? Mitentwickler Jon Sneyers ist positiv gestimmt und wagt einen Vergleich der aktuellen Bildformate.

Die Einführung neuer Technologiestandards und deren Akzeptanz ist oft ein steiniger Weg. Neue Bildformate sind da keine Ausnahme. Im Herbst 2022 hatte Google den neuen Bildverarbeitungsstandard JPEG XL für Chromium (das Open-Source-Projekt, auf dem Google Chrome und viele andere Browser wie Edge, Opera, Vivaldi und Brave basieren) abgelehnt.

Dies war ein großer Rückschlag, obwohl JPEG XL auch außerhalb von Browsern weiter verbreitet war. Insbesondere in Bildbearbeitungsprogrammen wie Serif Affinity, Adobe Camera Raw, GIMP, Krita usw. wird JPEG XL häufig verwendet. Dann, im Frühsommer 2023, kündigte Apple auf seiner jährlichen Worldwide Developers Conference (WWDC23) die Unterstützung von JPEG XL an.

In einer Präsentation, in der die neuen Funktionen des Safari-Browsers vorgestellt wurden, wurde auch „JPEG XL“ erwähnt. Nicht nur Safari 17 unterstützt JPEG XL, sondern auch die neuen Versionen von iOS, iPadOS, macOS, watchOS und visionOS. Diese Nachricht kam unerwartet. Keiner der JPEG XL-Entwickler hatte damit gerechnet, dass ausgerechnet Safari der erste Browser sein würde, der dieses von Google mitentwickelte Format unterstützt. Das ist natürlich großartig für die Verbreitung von JPEG XL und lässt hoffen.

Bildkompression verschiedener Standards verstehen

Bildkompression ist ein wichtiges Thema bei der Optimierung von Bildern. Wir benötigen ein tiefes Verständnis dafür, wann wir welchen Codec verwenden – oder besser gesagt, welchen Kodierer und welche Einstellungen. Deswegen haben wir in einem großen Experiment das Cloudinary Image Dataset (CID22) erstellt, einen großen Datensatz mit von Menschen annotierten komprimierten Bildern. So können wir besser verstehen, wie sich die Kompression auf die wahrgenommene Bildqualität auswirkt.

Der Vergleich von Bildkodierern ist keine leichte Aufgabe. Die von den verschiedenen Kodierern verursachten Verzerrungen sind unterschiedlich, und es ist schwierig, ihre Auswirkungen auf die wahrgenommene Bildqualität vorherzusagen. Subjektive Tests sind nach wie vor der beste Weg, um zu bewerten, wie die Bildqualität wahrgenommen wird.

Objektive Metriken wie SSIMULACRA 2 (Structural SIMilarity Unveiling Local And Compression Related Artifacts) können auf der Grundlage von durch Menschen annotierten Bilddatensätzen validiert werden. Obwohl diese Metriken nicht perfekt sind, können sie in großem Maßstab eingesetzt werden, um eine viel größere Anzahl von Bild- und Kodierer-Konfigurationen zu testen, als dies in einem subjektiven Experiment möglich wäre.

Bei der Bildkompression müssen drei Dimensionen gegeneinander abgewogen werden:

• Kompression: Wie stark kann die Dateigröße reduziert werden?

• Qualität: Inwieweit ist die visuelle Qualität des Bildes beeinträchtigt?

• Geschwindigkeit: Wie lange dauert es, ein Bild zu kodieren?

Die Bedeutung der Dimensionen ist relativ und hängt von der jeweiligen Anwendung ab. Bei gleicher visueller Qualität kann die Leistung verschiedener Kodierer etwa in Bezug auf Kompression und Geschwindigkeit betrachtet werden. In der gezeigten Abbildung wird die Metrik SSIMULACRA v2.1 als Indikator für die visuelle Qualität auf der horizontalen Achse verwendet.

Die vertikale Achse zeigt die Kompressionsleistung (als prozentuale Einsparung im Vergleich zu einem nicht optimierten 4:4:4 JPEG) auf der linken Seite. Auf der rechten Achse ist die Kodierungsgeschwindigkeit in Megapixel pro Sekunde dargestellt (bei Verwendung eines einzelnen CPU-Kerns). Das Diagramm zeigt JPEG XL (rot), AVIF/libaom (gelb), WebP (grün) und mozjpeg (weiß), jeweils mit der Standardgeschwindigkeit.

Die gestrichelten Linien verwenden 4:2:0 Chroma-Subsampling (Farbtransformation YUV-420), während die durchgezogenen Linien 4:4:4 (Farbtransformation YUV-444) verwenden. Die Spanne reicht von einer sehr niedrigen Qualität (ca. q30 nach libjpeg, einer freien, in C geschriebenen Bibliothek mit Funktionen zum Umgang von JPEG) bis zu einer sehr hohen Qualität (ca. q95 nach libjpeg).

Das Diagramm zeigt die aggregierten Daten von etwa 300 verschiedenen Quellbildern. Wir sehen, dass WebP gegenüber nicht optimiertem JPEG einen erheblichen Vorteil bietet: eine Einsparung von 25 bis 35 Prozent am unteren Ende des Qualitätsspektrums. Am oberen Ende des Qualitätsspektrums nimmt die Einsparung wegen der erzwungene Begrenzung von WebP im Bereich der Farbtransformation von YUV-420 (bei q90+ kämpft es damit, die Qualität von JPEG zu erreichen, das den vollen YUV-444-Bereich abdecken kann).

Im Vergleich zum optimierten mozjpeg-Kodierer, der ebenfalls erhebliche Vorteile gegenüber nicht optimiertem JPEG bietet, sind die zusätzlichen Vorteile von WebP jedoch nicht so groß: nur etwa drei bis fünf Prozent zusätzliche Einsparungen.

AVIF bringt gegenüber WebP ebenfalls erhebliche zusätzliche Einsparungen von ca. zehn bis 15 Prozent. Da AVIF nicht über eine erzwungene YUV-420-Farbtransformation verfügt, kann es im Gegensatz zu WebP auch im hochqualitativen Bereich erhebliche Einsparungen gegenüber nicht optimiertem JPEG bringen. Diese Einsparungen gehen jedoch zulasten der Geschwindigkeit: Die AVIF-Kodierung ist bei Standardgeschwindigkeit um eine Größenordnung langsamer als WebP oder mozjpeg.

Schließlich bringt JPEG XL gegenüber AVIF eine zusätzliche Einsparung von etwa fünf bis zehn Prozent. Die zusätzliche Einsparung ist im hochwertigen Bereich größer als im qualitativ niedrigeren Bereich. Außerdem geschieht dies mit einer vernünftigen Geschwindigkeit.

Während sich JPEG XL noch auf dem steinigem Weg der Akzeptanz befindet, werden sich viele Webentwickler und -entwicklerinnen fragen, wohin die Reise geht. Angesichts der oben beschriebenen Einsparungen durch JPEG XL ist eines sicher: Wer einen hohen Anteil an iOS- oder Safari-Besuchern hat, für den lohnt es sich, JPEG XL-Bilder anzubieten, auch wenn man für die anderen Besucher weiterhin AVIF-, WebP- oder JPEG-Varianten benötigt.

Um die nächsten Schritte des Standards zu verfolgen oder sich selbst einzubringen, können interessierte Entwicklerinnen und Entwickler gerne auf JPEG XL Discord mitdiskutieren.

(ID:49903811)