Kommentar von Jon Sneyers, Co-Vorsitzender der JPEG XL Ad-hoc-Gruppe Chrome Support für JPEG XL endet – wie geht es weiter?

Anbieter zum Thema

OutSystems

Im Herbst 2022 gab Chrome seine Entscheidung bekannt, die bisher experimentelle Unterstützung für JPEG XL für Chromium zu stoppen. Da dieses Open-Source-Projekt neben Google Chrome auch anderen Browsern wie Edge, Opera, Vivaldi und Brave zugrunde liegt, hat das wohl weitreichende Folgen.

Viele Entwicklerinnen und Entwickler, die mit Bildern für Websites oder Apps arbeiten, wissen den neuen JPEG-XL-Standard zu schätzen. Denn beispielsweise erlaubt das quelloffene, kostenlose Dateiformat für Rastergrafiken sowohl verlustbehaftete als auch verlustfreie Dateikomprimierung.

Die Begründung

Chrome nannte vier Gründe für die Einstellung der experimentellen Unterstützung für JPEG XL, zu denen ich hier Stellung nehmen möchte. Erstens hieß es, dass „experimentelle Referenzen und Code nicht auf unbestimmte Zeit bestehen sollten“. Das ergibt zwar Sinn, aber viele Leute hätten erwartet, dass dies durch die standardmäßige Aktivierung gelöst werden würden und nicht durch die vollständige Einstellung der Unterstützung.

Zweitens wurde festgestellt, dass „das Interesse des gesamten Ökosystems nicht groß genug sei, um weiter mit JPEG XL zu experimentieren“. Hier stellt sich die Frage, ob und wie überhaupt das Interesse des Ökosystems gemessen wurde. Aufgrund des experimentellen Status von JPEG XL konnte das Format hauptsächlich für Experimente genutzt werden, aber nicht für die tatsächliche Nutzung, da die meisten Endnutzer die dazu notwendige Markierung nicht aktiviert haben.

Es gibt also keine aussagekräftigen Nutzungsstatistiken. Hinzukommt, dass der Hauptteil des JPEG XL-Standards (ISO/IEC 18181-1) erst im März 2022 und die Beschreibung der Referenzimplementierung (ISO/IEC 18181-4) sogar erst im August 2022 veröffentlicht. Eine sehr kurze Zeitspanne, um Rückschlüsse auf das Interesse des Ökosystems zu ziehen.

Wenn wir uns andere Browser ansehen, bietet auch Firefox Nightly eine experimentelle Unterstützung für JPEG XL und wird von vielen Webentwicklern und -entwicklerinnen aufgefordert, das Format standardmäßig zu aktivieren. Und Pale Moon, ein auf Firefox basierender Open Source-Webbrowser, der für Microsoft Windows und Linux verfügbar ist, bietet als erster Browser standardmäßig JPEG-XL-Unterstützung. Außerdem gibt es im Chromium Bugtracker positive Rückmeldungen von Facebook, Adobe, Intel und VESA, Flickr, Krita, The Guardian, libvips, Cloudinary und Shopify. Das Argument, es mangele an Unterstützung, ist daher schwer nachzuvollziehen.

Ein kurzes Wort zur Begründung Nummer vier, bevor ich auf Nummer drei näher eingehe. So heißt es, dass, durch die Entfernung der Referenzen und des markierten Codes, der Wartungsaufwand verringert werden und sich die Entwickler*innen besser auf die Verbesserung bestehender Formate in Chrome konzentrieren können. Natürlich bedeutet jede zusätzliche Codezeile einen „Wartungsaufwand“, aber das ist ein ziemlich allgemeines Argument, das für jede neue Funktion gilt.

Bleibt noch Begründung Nummer drei, auf die ich gerne näher eingehen möchte. In der Erklärung von Chrome heißt es: „Das neue Bildformat bringt keine ausreichenden zusätzlichen Vorteile gegenüber den bestehenden Formaten, um seine standardmäßige Aktivierung zu rechtfertigen.“ Natürlich ist „nicht ausreichend“ ziemlich vage, wenn nicht angegeben wird, ab wann ein Vorteil ausreichend ist. Um zu beurteilen, ob die Vorteile ausreichend sind oder nicht, hier einige Informationen zu JPEG XL.

Kurzer Überblick über die Vorteile von JPEG XL

Ein Alleinstellungsmerkmal von JPEG XL ist, dass es möglich ist, vorhandene Bilder im JPEG-Format verlustfrei in eine im Durchschnitt 20 Prozent kleinere JPEG-XL-Datei umzukomprimieren. Tatsächlich kann eine JPEG-Datei jederzeit wieder bis aufs kleinste Bit aus der JPEG-XL-Datei rekonstruiert werden. Kein anderes Bildformat verfügt über diese Funktion. Normalerweise ist die Umwandlung von JPEG-Dateien in andere Formate verlustbehaftet, sodass Kompressionsartefakte oder riesige Dateien entstehen, wenn eine hohe Transkodierungsqualität gewählt wird.

Ein weiterer Vorteil von JPEG XL ist, dass es eine progressive Decodierung unterstützt. Das bedeutet, dass mit nur 15 Prozent der übertragenen Bilddaten bereits eine Vorschau des Bildes in geringerer Qualität angezeigt wird, die verfeinert wird, wenn weitere Daten übertragen werden. Das ist besonders hilfreich, wenn die Internetverbindung langsam ist. Keines der von Videos abgeleiteten Bildformate (WebP, HEIC, AVIF) unterstützt die progressive Decodierung auf Codec-Ebene, da dies eine Funktion ist, die sehr spezifisch für Standbilder ist.

Um dieses Manko zu überwinden, müssen Webentwickler auf Tricks, wie die Verwendung von Platzhaltern für Bilder niedriger Qualität (LQIP) zurückgreifen, um ein progressives Ladeerlebnis zu schaffen. Mit JPEG XL ist dies überflüssig. Das Format kann sogar noch mehr: eine salienzbasierte Progression, bei der zuerst die Bereiche des Bildes aktualisiert werden, die die menschliche Aufmerksamkeit auf sich ziehen.

JPEG XL eignet sich auch hervorragend zur verlustfreien Bildkomprimierung: Es kann schneller kodiert werden, erzeugt kleinere Dateien und bietet mehr Funktionen (zum Beispiel CMYK, Ebenen und 32-Bit-Gleitkomma-Samples). Für den speziellen Anwendungsfall der Bereitstellung im Internet kann eine verlustfreie Komprimierung in manchen Fällen wünschenswert sein, denn bei einigen Arten von Bildinhalten (etwa Screenshots oder Pixelgrafiken) kann eine verlustfreie Komprimierung paradoxerweise zu kleineren Dateien führen als eine verlustbehaftete Komprimierung.

Die Vorteile von JPEG XL in Bezug auf die verlustbehaftete Komprimierung sind nicht leicht zu messen, da sie vom Kompromiss zwischen Komprimierung und Qualität abhängen. Jüngste Tests, die wir bei Cloudinary durchgeführt haben und demnächst veröffentlichen werden, zeigen jedoch, dass JPEG XL in dem für das Web relevanten Qualitätsbereich eine zehn bis 15 Prozent bessere Komprimierung als AVIF erzielen kann, und zwar bei Encoder-Geschwindigkeitseinstellungen, bei denen die JPEG XL-Codierung etwa dreimal so schnell wie AVIF ist.

Ein weiterer Vorteil von JPEG XL ist die Vielseitigkeit des Formats: Neben der Bereitstellung im Internet, kann JPEG XL auch als Aufnahmeformat verwendet werden und dank hoher Präzision, hohen Dynamikbereichs, verlustfreie oder minimal verlustbehaftete Komprimierung, eine ähnliche Rolle spielen wie aktuelle Kamera-Raw-Formate. Es kann auch als Authoring-Format verwendet werden, da es benannte Ebenen, Auswahlmasken und mehrere Alphakanäle unterstützt.

Für Druckanwendungen kann es ebenfalls zum Einsatz kommen, da es etwa CMYK und Schmuckfarben unterstützt. Ebenso kann JPEG XL für medizinische oder wissenschaftliche Anwendungen verwendet werden, da es hochpräzise, verlustfreie Kompression und multispektrale Bildgebung unterstützt. In anderen Worten, JPEG XL ist ein Allzweckformat, das viele digitale Anwendungsfälle abdeckt.

Wie es weiter geht

Trotz seiner Vorteile, es ist nicht zu leugnen, dass die Entscheidung von Chrome viele Experten verunsichert hat. Deshalb habe ich einige Überlegungen für diejenigen zusammengestellt, die bereits mit JPEG XL arbeiten oder erhebliche Entwicklungsressourcen in ihr Projekt investiert haben:

• Ein praktischer Weg, zumindest im Web, ist die Verwendung eines WASM-basierten Workarounds, um JPEG XL-Bilder zu laden – das heißt, Entwickler*innen können einen Workaround („Polyfill“) mit Web Assembly Code erstellen, um JPEG XL zu unterstützen. Diesen Code gibt es bereits als Demo, und das JPEG XL-Team arbeitet derzeit daran, die Bereitstellung einer solchen Lösung zu erleichtern. Natürlich wäre eine native Browserunterstützung vorzuziehen, sowohl was die Leistung als auch die Bequemlichkeit für die Entwickler angeht, aber zumindest einige der Vorteile von JPEG XL könnten auf diese Weise genutzt werden.

• Eine weitere Möglichkeit ist die Einführung von JPEG XL außerhalb des Internets, etwa in mobilen, nicht browserbasierten Apps. Im Prinzip könnte eine App ihren eigenen JPEG XL-Decoder mitliefern. Da dieser nur etwa 200 KB benötigt und damit im Vergleich zu typischen App-Größen recht klein ist, könnte ein Paket von den erheblichen Dateigrößenreduzierungen profitieren, die JPEG XL bei gebündelten Bildinhalten bietet. Dadurch werden auch die Kosten für den Versand eines JPEG XL-Decoders mehr als ausgeglichen, insbesondere wenn zusätzliche Bilder über das Netzwerk übertragen werden.

• Ferner sollten Entwickler und Entwicklerinnen, die an JPEG XL interessiert sind (oder bereits in JPEG XL investiert haben), nicht einfach darauf warten, dass die Browserunterstützung vielleicht später kommt. Stattdessen sollten sie Browser (nicht nur Chrome) explizit auffordern, JPEG XL zu unterstützen. Es ist verständlich, dass neue Funktionen nicht leichtfertig zu den ohnehin schon komplexen Webplattformen hinzugefügt werden. Andererseits wissen die Browser-Hersteller aber nicht, wie weit viele Projekte bereits mit JPEG XL umgesetzt werden. Deshalb sollte man sich zu Wort melden, wenn man neue Funktionen oder Formate wie JPEG XL tatsächlich nutzt.

Trotz Chrome – für JPEG XL gibt es immer noch enorme Möglichkeiten. Ich bin auch aufgrund vieler Rückmeldungen davon überzeugt, dass die technischen Vorzüge von JPEG XL groß genug sind, um früher oder später JPEG und PNG zu ersetzen – sowohl im Web als auch in vielen anderen Anwendungsfällen.

* Dr. Jon Sneyers ist Co-Vorsitzender der JPEG XL Ad-hoc-Gruppe und Initiator des Free Lossless Image Format (FLIF). Er arbeitet als Senior Image Researcher bei Cloudinary, einem Anbieter von cloud-basierten Image- und Videomanagementlösungen. Jon hat an der KU Leuven in Informatik zum Thema Optimierung der Kompilierung und Rechenkomplexität von Constraint-Handling-Regeln promoviert.

(ID:49030370)