Hat Google JPEG XL wiederbelebt?

 (tonisagrista.com)
5 Punkte von GN⁺ 2025-12-03 | 2 Kommentare | Auf WhatsApp teilen
  • Mit der Wiederherstellung der JPEG-XL-Unterstützung durch die Chromium-Engine rückt ein einst verworfenes Bildformat wieder in den Fokus
  • 2022 strich Google JPEG XL mit der Begründung mangelnden Interesses im Ökosystem, doch der anhaltende Druck der Community und wichtiger Unternehmen ging weiter
  • Mehrere Organisationen wie Meta, Intel, Adobe, Cloudinary und Krita haben öffentlich die Notwendigkeit der Formatbeibehaltung befürwortet
  • Kürzlich hat die PDF Association signalisiert, JPEG XL als Basiformat für HDR-Inhalte nutzen zu wollen, wodurch der Trend verstärkt wurde
  • Die Wiedereinführung durch Chrome wird als Wendepunkt bewertet, der die Möglichkeit einer breiten Standardisierung von JPEG XL erhöht

Hintergrund der Wiederbelebung von JPEG XL

  • 2022 entfernte das Chromium-Team JPEG XL wegen „zu geringen Ökosystem-Interesses“ und unzureichender Vorteile gegenüber bestehenden Formaten – inkl. Code und Flags
    • Die Community hatte damals die Unterstützung von Organisationen wie Meta, Intel, Cloudinary, Adobe, ffmpeg, libvips und Krita erklärt
    • Danach folgten über Blogs, Videos und soziale Netzwerke anhaltende Reaktionen, die die Unangemessenheit der Rücknahmeentscheidung kritisierten
  • Ende 2025 änderte das Chromium-Team den als Obsolete eingestuften JPEG-XL-Issue zu Assigned und leitete offiziell den Wiederherstellungsprozess ein
    • Im Blink-Developer-Group erwähnte Rick Byers, er begrüße einen leistungsfähigen, speichersicheren JPEG-XL-Decoder
    • Diese Entscheidung stützt sich auf positive Signale wie die Unterstützung durch Safari, die geänderte Position von Firefox und die Aufnahmebestrebungen der PDF Association

Firefox und Entwicklung des Rust-basierten Decoders

  • Das Firefox-Team äußerte Sicherheitsbedenken hinsichtlich des C++-basierten libjxl-Decoders und forderte daher eine „speichersichere“ Rust-Version
    • Daraufhin begann Google Research mit der Entwicklung der Rust-Implementierung jxl-rs
    • Dieses Projekt erhöht die Chancen für eine sichere Integration von JPEG XL direkt im Browser

Aufnahmebewegung der PDF Association

  • PDF-Association-CTO Peter Wyatt kündigte an, JPEG XL als Standardbildformat für HDR-Bilder in der PDF-Spezifikation einzubeziehen
    • Dies wirkt als Faktor, der die Standardisierungschancen von JPEG XL im Dokumenten- und Verlagsbereich stärkt

Zentrale technische Merkmale von JPEG XL

  • Unterstützung für verlustfreie Neukomprimierung klassischer JPEGs mit etwa 30 % Platzersparnis bei gleichbleibender Qualität
  • Unterstützung für umfassende Farbräume und HDR, bis zu 32 Bit pro Kanal sowie Verarbeitung von 4.099 Kanälen
  • Unterstützung für eine maximale Bildgröße von 1,073,741,823×1,073,741,824 und damit auch für besonders große Bilder
  • Progressives Decoding wird unterstützt und verbessert so die Übertragungseffizienz im Web
  • Enthält Animation, Alpha-Transparenz und Tiefenkarte (Depth Map)
  • Eine Struktur, die generationsstabil ist, minimiert Qualitätsverluste bei wiederholter Codierung

Fazit

  • JPEG XL erfüllt die Anforderungen als Bildformat der nächsten Generation, und die Rückkehr der Chrome-Engine ist ein entscheidender Schritt zur massenhaften Verbreitung
  • Als Ergebnis des langanhaltenden Drucks der Community ist es wiederbelebt worden und entwickelt sich zum neuen Standardkandidaten des Web-Bildökosystems
  • Der Autor begrüßt die Neubewertung durch Chromium, merkt jedoch an, dass diese Entscheidung zu spät getroffen wurde

Verwandte Beiträge

2 Kommentare

 
GN⁺ 2025-12-03
Hacker-News-Kommentare

  • Eine der weniger bekannten coolen Funktionen von JPEG XL ist ein Modus für verlustfreies Transkodieren von JPEG, der dabei rund 20 % Speicherplatz spart
    Da der ursprüngliche Entropie-Bitstream unverändert erhalten bleibt, ist das vollständig reversibel
    GCP setzt das derzeit in der DICOM Store API ein, sodass man die Platzersparnis von JXL nutzen und dennoch in Echtzeit als JPEG ausliefern kann
    Unser Unternehmen speichert Daten im Umfang von mehreren zehn PB im GCP DICOM Store, daher erwarten wir, mit dieser Funktion die jährlichen Gebühren erheblich senken zu können
    Wir hoffen auch auf native Unterstützung im Browser und haben gehört, dass das Chrome-Team die Unterstützung am Ende wohl doch einführen wird

    • Ich frage mich, wie sich das im Vergleich zu einem durchschnittlichen JPEG-Encoder oder mozjpeg unterscheidet
    • Ich hatte bisher nie Zeit, den GCP DICOM Store zu testen, und würde gern wissen, wie er sich in der Praxis schlägt
      Ich würde gern wissen, ob das ein vollständiges PACS, eine WADO-Implementierung oder einfach nur eine benutzerdefinierte API ist
    • Wenn es reversibel ist, könnte man dann nicht einfach als JPEG XL speichern und bei der Auslieferung zurückkonvertieren?
      Ich frage mich, ob die Verarbeitung vielleicht sehr lange dauert
    • Wenn man das ursprüngliche DICOM ohnehin speichern muss, ist fraglich, ob das Transkodieren überhaupt sinnvoll ist
      Der Großteil der Speicherkosten dürfte wohl auf das DICOM selbst entfallen
    • Letztlich profitieren große GCP-Kunden stark von dieser Funktion, daher denke ich, dass der Grund, warum Chrome JXL vorantreibt, in internen Kunden liegt

  • Der Konkurrent von JPEG XL ist nicht AVIF
    AVIF hat sich bereits als De-facto-Standard etabliert, wird von fast allen Browsern unterstützt und wird auch als Standard-Bildformat von Apple verwendet
    JXL hat bei der Browser-Unterstützung noch Schwächen, etabliert sich aber in Nischen wie Archivierung, professionelle Fotografie und Medizin
    In etwa 10 Jahren könnte es so verbreitet sein, dass die Leute es einfach „JPEG“ nennen
    AVIF ist ein offener, lizenzfreier Standard, komprimiert deutlich besser als JPEG/WebP und liegt auch in einer ähnlichen Größenordnung wie JXL
    JXL unterstützt zwar größere Maximalbildgrößen, aber bei der tatsächlichen Verbreitung liegt AVIF deutlich vorne
    Wenn AV2 erscheint, dürfte der Qualitätsabstand fast verschwinden, und beide Formate werden sich wohl auf einem ähnlichen Qualitätsniveau weiterentwickeln

    • Dass AVIF effizienter komprimiert als JPEG oder WebP, ist selbstverständlich, aber mit JXL kann es nicht konkurrieren
      Bei realistischen Qualitätseinstellungen bietet JXL höhere Kompressionsraten und schnelleres Encoding und Decoding
      Außerdem unterstützt es progressive decoding
      AV2 könnte eines Tages aufholen, aber im Moment ist JXL meiner Meinung nach weit voraus
    • Einer der Gründe, warum das Chrome-Team die JXL-Unterstützung eingestellt hatte, war, dass AVIF bereits gut genug war
      Diese erneute Prüfung scheint mit der damaligen Entscheidung zusammenzuhängen
    • Die Aussage „AVIF ist Apples Standard-Bildformat“ scheint falsch zu sein
      Das iPhone verwendet HEIF
    • Ich habe libjxl selbst ausprobiert und fand den Speicherverbrauch hoch und die Stabilität schlecht
      Zum Kodieren hochauflösender Bilder schien RAM im Terabyte-Bereich nötig zu sein
      Ich war überrascht, wie chaotisch die Codebasis war, und viele Optionen funktionierten nicht richtig
      Dass mit jxl-rs ein neuer Versuch unternommen wird, ist positiv, aber da dieselben Entwickler beteiligt sind, beobachte ich das vorsichtig

  • Chromium wird für die JPEG-XL-Funktion wahrscheinlich das jxl-rs crate verwenden
    Vermutlich will man warten, bis es ausreichend stabil ist, und es dann integrieren
    Das zugehörige Issue ist hier zu finden

    • Mozilla hatte eine ähnliche Haltung, aber Google zeigte eine Zeit lang eine feindselige Haltung
      Trotz des Widerstands der Nutzer wurde das Issue geschlossen und erst vor Kurzem wieder geöffnet
      Vielleicht lag das an PR-Problemen oder internem Unmut
    • Bei jxl-rs gab es einen Zeitraum von über anderthalb Jahren ohne Commits
      Dass es jetzt gut vorangeht, könnte auch einfach ein glücklicher Zufall sein

  • Ich habe mir die Referenzimplementierung (C++) von JPEG XL angesehen, und noch vor zwei Jahren war die Codequalität nicht gut
    Es wirkte so, als könnten daraus Sicherheitsprobleme entstehen

    • Deshalb prüfen sowohl Mozilla als auch Google JXL-Unterstützung nur unter der Bedingung einer speichersicheren Implementierung
      Eine Rust-Version ist in Entwicklung, und Google plant, nach und nach alle Decoder in Chromium durch Rust zu ersetzen
    • Tatsächlich ist großer Bildverarbeitungscode in C++ zum jetzigen Zeitpunkt (2025) an sich schon ein Sicherheitsrisiko
      Das ist kein Problem, das nur JPEG XL betrifft

  • Die maximale Auflösung von JPEG XL beträgt 1.073.741.823 × 1.073.741.824 und kann damit extrem hochauflösende Bilder im Umfang von Hunderten Petabyte darstellen
    Praktisch läge man selbst nach der Komprimierung noch bei Größenordnungen von mehreren zehn bis mehreren hundert PB

    • Bei 600 DPI entspräche eine Seitenlänge etwa einer Marathondistanz
      Wenn man solch riesige Bilder in wenig Byte definieren kann, könnte das auch ein DoS-Angriffsvektor sein
      Ich wollte das in A4-Blätter umrechnen, aber der Gemini-Rechner hat Einheiten verwechselt und Unsinn ausgespuckt
    • Der einzige praktikable Weg, mit solchen gigantischen Bildern umzugehen, ist eine Kachel- und Pyramidenstruktur
    • Das entspräche ungefähr einem Bild der gesamten Erde mit einer Auflösung von etwa 4 cm
    • Ein Selfie in dieser Auflösung wäre wohl auf dem Niveau eines Super-Resolution-Mikroskops
    • JPEG XL unterstützt im Gegensatz zu AVIF effizientes progressive decoding, sodass man schon während des Downloads schnell eine Vorschau in niedriger Qualität sehen kann

  • Sammlung früherer HN-Diskussionen
    Chromium Team Re-Opens JPEG XL Feature Ticket
    FSF Slams Google over Dropping JPEG-XL in Chrome
    Google set to deprecate JPEG XL support in Chrome 110
    Chromium jpegxl issue closed as won't fix

  • Ich nutze seit einigen Jahren .avif
    Es ist nicht perfekt, fühlt sich aber deutlich besser an als .jpg oder .png
    Ich habe auch .webp und jpeg-xl in Betracht gezogen, bin am Ende aber mit .avif zufrieden
    Allerdings missfällt mir, dass Google Webstandards faktisch dominiert
    Es ist nicht wünschenswert, dass ein kommerzielles Unternehmen das digitale Ökosystem kontrolliert

    • Im Satz „.avif ist besser als .jpg“ wird .avif zweimal wiederholt, was verwirrend ist
    • Wenn du hochwertige JPEGs kleiner machen willst, probier jpegli aus
      jpegli GitHub
      Wenn man die Einstellungen für visuell verlustfreies AVIF gut wählt, kann es kleiner als jpegli sein, aber im Durchschnitt ist jpegli effizienter
    • Zur Information: Im Englischen klingt „for several years“ natürlicher als „since some years“
    • JPEG XL verliert auch bei mehrfachem erneuten Speichern nur wenig Qualität, was für das Web von Vorteil ist
      Dazu ein Video: YouTube-Link

  • Nicht „Google insgesamt“, sondern das Chrome-Team hat JXL entfernt
    JXL wurde von Jyrki Alakuijala aus dem Google-Zurich-Labor entworfen; er gehört zu Google Research, nicht zum Chrome-Team
    Das Chrome-Team hat eine auf Mountain View zentrierte geschlossene Kultur

    • Jyrki ist ein hervorragender Ingenieur, der auch Brotli, WebP lossless, WOFF2 und jpegli entwickelt hat
      Dass er nach dem Aus für JpegXL jpegli entwickelt hat, war gewissermaßen eine Reaktion darauf
    • Diese Situation lässt sich vielleicht mit Conway’s Law erklären

  • JXL scheint verzögert worden zu sein, weil es viele C++-basierte Multithreading-Abhängigkeiten hat und dadurch die Sicherheitsangriffsfläche größer werden könnte
    Sowohl Mozilla als auch Google bevorzugen deshalb Rust-Implementierungen, um das zu vermeiden
    Der Standard selbst ist eindeutig ein verbessertes Format gegenüber den bisherigen

    • 100 Millionen Zeilen klingt nach einer stark übertriebenen Zahl
    • Tatsächlich sind es eher rund 30.000 Zeilen, und die Single-Thread-Version liegt bei etwa 10.000 Zeilen
      Auch die Binärgröße ist viel kleiner als bei AVIF, und die Spezifikation ist deutlich kompakter
    • Da Google an der Entwicklung von JXL beteiligt war, ist es ihre eigene Verantwortung, nicht schneller einen speichersicheren Decoder gebaut zu haben
    • War vielleicht eher von 100.000 Zeilen die Rede? Ein erheblicher Teil davon dürfte Testcode sein
    • libjxl hat tatsächlich etwa 112.000 Zeilen, also drei Größenordnungen weniger als die Behauptung von 100 Millionen

  • Die RAW-Dateien des iPhone 17 Pro sollen mit JPEG XL komprimiert sein