Google hat eine umstrittene Entscheidung aus dem Jahr 2022, die die Einführung von Bildern der nächsten Generation blockierte, rückgängig gemacht und offiziell bestätigt, dass die Unterstützung für JPEG XL (JXL) in seinem Chrome-Browser wiederhergestellt wird.
JPEG XL (JXL) ist ein lizenzfreies Bildformat der nächsten Generation, das entwickelt ist, um den alten JPEG-Standard zu ersetzen, indem es überlegene Komprimierung und moderne Funktionen wie HDR, Transparenz und mehr bietet Animation. Sein entscheidender Vorteil ist die Möglichkeit, bestehende JPEGs verlustfrei in kleinere Dateien umzuwandeln (wodurch die Größe um etwa 20 % reduziert wird), ohne dass es zu Qualitätsverlusten kommt.
Googles Schritt folgt auf jahrelange Gegenreaktionen der Entwickler und zunehmenden Druck von konkurrierenden Ökosystemteilnehmern wie Apple und Adobe, die das lizenzfreie Rastergrafikdateiformat angenommen haben, obwohl Google zuvor behauptet hatte, sie hätten „mangelndes Interesse“.
Chrome-Ingenieure sagen jetzt, dass sie die Funktion ausliefern werden, sobald ein speichersicherer Decoder integriert ist. Dies signalisiert einen wichtigen Wendepunkt in den „Codec-Kriegen“ im Web und ebnet den Weg für JXL, den veralteten JPEG-Standard zu ersetzen.
Ein auf Rost basierender Weg zur Erlösung
Rick Byers, ein Leiter des Chrome-Prüfungsteams, durchbrach eine dreijährige Pattsituation und beendete offiziell das Einfrieren der JPEG XL-Integration in der Blink-dev-Mailinglisten-Thread. Die Genehmigung hängt von zwei spezifischen Bedingungen ab: dem Vorhandensein „positiver Signale“ aus dem weiteren Ökosystem und strikter Einhaltung der Sicherheitsvorschriften.
Google lehnt die vorherige C++-Implementierung ausdrücklich zugunsten eines „leistungsfähigen und speichersicheren“ Decoders ab, der wahrscheinlich in Rust geschrieben ist. Byers merkte an, dass „wir uns angesichts dieser positiven Signale über Beiträge zur Integration eines leistungsstarken und speichersicheren JPEG-XL-Decoders in Chromium freuen würden“, und begründete dies mit der externen Übernahme und nicht mit internen Metriken.
Langfristige Wartung bleibt die letzte Hürde, bevor die Funktion Benutzer erreicht. Google benötigt ein spezielles Team, das den Decoder-Code besitzt, bevor er an den Stable-Kanal versendet wird.
Byers präzisierte den Zeitplan und erklärte: „Um ihn standardmäßig in Chromium zu aktivieren, bräuchten wir eine Verpflichtung zur langfristigen Wartung. Wenn diese und unsere üblichen Startkriterien erfüllt wären, würden wir ihn in Chrome versenden.“
Entwickler Helmut Januschka stellte ein detailliertes Status-Update zum Chromium-Bug-Tracker bereit und bestätigte, dass der neue Code auf dem neuesten libjxl-Referenzimplementierung. Im Update des Entwicklers heißt es:
„Aktueller Status: – Funktion abgeschlossen – verwendete die vorherige JXL-Implementierung als Blaupause und wurde auf die neueste Referenzimplementierung aktualisiert – Animationsunterstützung hinzugefügt (Chromium wäre der erste Browser, der JXL-Animationen unterstützt) – Bots sind grün.“
Januschka hat außerdem die folgende Demo veröffentlicht, die die Unterstützung von JPEG XL-Animationen in einem Chromium-Build zeigt.
[eingebetteter Inhalt]
Als „Funktion abgeschlossen“ markiert Berichten zufolge besteht die neue Implementierung die meisten automatisierten Bot-Tests. Die Animationsunterstützung ist in diesem zweiten Versuch ein entscheidendes technisches Unterscheidungsmerkmal und übertrifft möglicherweise die ursprüngliche Implementierung von Safari.
Januschka bemerkte, dass „Chromium der erste Browser wäre, der JXL-Animationen unterstützt“, obwohl diese Behauptung von kleineren Projekten wie dem Thorium-Browser, der JXL-Animationen unterstützt, bestritten wird seit Mitte 2024.
Der „Codec War“-Kontext (2022–2025)
Google hat die JXL-Unterstützung ursprünglich in Chrome 110 im Dezember 2022 entfernt, wodurch die Webdynamik des Formats effektiv zunichte gemacht wurde. Damals erklärte Jim Bankoski , dass „wir beschlossen haben, das JPEG XL-Experiment von Chrome zu stoppen und den mit dem Experiment verbundenen Code zu entfernen“, und verwies auf unzureichende Vorteile gegenüber Googles eigenem AVIF Format.
Kritiker und Bildkomprimierungsexperten warfen Google vor, fehlerhafte Metriken zu verwenden, indem sie nicht optimierte Encoder testeten, um AVIF zu bevorzugen. Die Entfernung löste einen der umstrittensten Threads in der Geschichte von Chromium aus und zog über 1.000 Sterne und Hunderte von Kommentaren von Entwicklern an.
Während der Pause drängte Google aggressiv auf AVIF, abgeleitet vom AV1-Videocodec, als alleinigen Nachfolger von JPEG und WebP. Die Ingenieure entfernten das „Feature Flag“ vollständig aus dem Browser und verhinderten so fast drei Jahre lang sogar eine experimentelle Nutzung.
In dieser Zeit wurde eine „Formatkrieg“-Erzählung gefestigt, indem Googles videobasiertes AVIF dem bildorientierten Design von JPEG XL gegenübergestellt wurde.
Ökosystemdruck und technische Realität
Apple löste die Sackgasse im Jahr 2023, indem es Safari 17. Diese Einführung schuf ein „Split-Web“-Szenario und bedeutete, dass hochauflösende Bilder auf iPhones geladen wurden, auf Android und Chrome jedoch scheiterten.
Adobe integrierte JXL in Lightroom und Photoshop, während Microsoft die JPEG XL-Bilderweiterung zu Windows 11 hinzufügte und sie unabhängig davon als professionellen Standard validierte Browser-Unterstützung.
Mozillas Position änderte sich von „neutral“ zu „positiv“, vorausgesetzt, die Sicherheitsbedenken wurden über einen Rust-basierten Decoder ausgeräumt. Technisch gesehen bietet JXL einen einzigartigen Vorteil: verlustfreie Transkodierung vorhandener JPEGs, um die Größe ohne Generierungsverlust um ca. 20 % zu reduzieren.
AVIF fehlt diese Transkodierungsfunktion, was eine verlustbehaftete Neukodierung erfordert, die die Qualität des Archivinhalts beeinträchtigt. Im Einklang mit dem breiteren Branchentrend, Schwachstellen in der Speichersicherheit beim Parsen komplexer Mediendateien zu beseitigen, sorgt die Umstellung auf einen Rust-basierten Decoder für langfristige Stabilität.
