Chromium integriert JpegXL

 (chromium-review.googlesource.com)
2 Punkte von GN⁺ 2026-01-14 | 1 Kommentare | Auf WhatsApp teilen
  • Ein JpegXL-Decoder wurde in die Chromium-Codebasis integriert, sodass der Browser Bilder im JXL-Format verarbeiten kann
  • Die Änderung ist auf der Gerrit-Code-Review-Seite unter dem Titel „Wire up JXL decoder“ einsehbar
  • Dieser Merge ist ein zentraler Schritt zur Unterstützung des JpegXL-Formats und umfasst die Anbindung des Decoders
  • Das Code-Review ist als Änderung im src-Repository von Chromium (7184969) eingetragen
  • Dies ist bedeutsam als Erweiterung der Unterstützung für Bildformate der nächsten Generation in Webbrowsern

Integration des JpegXL-Decoders in Chromium

  • Der Gerrit-Code-Review-Eintrag „Wire up JXL decoder (7184969)“ ist eine Änderung zur Anbindung des JpegXL-Decoders an das Chromium-Projekt
    • Diese Änderung wurde im src-Repository von Chromium vorgenommen
    • Als Code-Review-Plattform wird chromium-review.googlesource.com verwendet
  • Wie der Titel sagt, geht es darum, den JXL-(JpegXL-)Decoder innerhalb des Browsers anzubinden (wire up)
  • Auf der Seite werden keine zusätzlichen Erklärungen oder Code-Details angezeigt, lediglich der Titel der Änderung ist sichtbar

Technischer Kontext

  • JpegXL ist ein Bildkompressionsformat der nächsten Generation, das auf eine höhere Effizienz als JPEG abzielt (im Original nicht direkt erwähnt, dort erscheint nur der Technikname)
  • Durch den Merge des Decoders in Chromium wird die Grundlage für die Aktivierung der JXL-Bildverarbeitung auf Code-Ebene geschaffen
  • Diese Änderung ist ein technischer Fortschritt im Zusammenhang mit der Erweiterung des Media-Decoding-Systems der Browser-Engine

Dokumentstatus

  • Die Seite wird als zwischengespeicherter Snapshot eines Gerrit-Code-Reviews angezeigt
  • Sie enthält einen Warnhinweis, dass das Shadow DOM verborgen ist, der eigentliche Code-Inhalt wird jedoch nicht angezeigt
  • Daher sind in diesem Dokument nur der Titel der Änderung und die Review-Kennung (7184969) verifizierbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-14
Hacker-News-Kommentare

  • Ich habe den Cloudinary-Blogbeitrag gesehen; das ist ein alter Klassiker, der webp, jpegxl, avif, jpeg usw. vergleicht
    Die Diagramme sind gut aufbereitet, und AVIF ist sehr langsam

    • Als JPEG auf die niedrigste Qualität eingestellt war, sah es hier deutlich besser aus
      Link zum entsprechenden Abschnitt
    • Ich bin mir nicht sicher, was diese Website genau machen will
      Siehe Screenshot
    • Wenn JPEG XL, wie im zitierten Satz beschrieben, seine Position als bester Codec sowohl für verlustbehaftete als auch verlustfreie Kompression gefestigt hat, dann ist das ein großer Fortschritt, der JPEG und PNG gemeinsam ersetzen könnte
    • Dieser Test verwendet allerdings keine hardwarebeschleunigten Encoder/Decoder

  • Die Bibliothek jxl-rs ist eine Rust-Implementierung von JPEG XL
    Es ist ein relativ neues Projekt, aber dank Rust fühlt es sich in Bezug auf Sicherheitsstabilität beruhigend an
    Bei früheren Chromium-Diskussionen gab es diese Bibliothek noch nicht

    • Soweit ich mich erinnere, lehnte Google JPEG XL wegen „mangelnden Interesses“ ab. Es lag wohl nicht an Sicherheitsproblemen
    • Ich stimme der Aussage nicht zu, dass „Rust Sicherheitsbedenken ausräumt“. Speichersicherheit ist nicht Sicherheit an sich
      Rust kann zu Selbstüberschätzung führen, und dann wird Threat Modeling ausgelassen
      Im Gegenteil kann ein sorgfältiger C-Programmierer sicherer sein
    • Ich habe tatsächlich nachgesehen, wie viel unsafe-Code vorhanden ist
      Link zu den Suchergebnissen

  • Ich habe kürzlich WebP und AVIF verglichen; WebP wird fast sofort encodiert, während AVIF bei einem 1-MP-Bild mehr als 20 Sekunden braucht
    JXL wird wegen der noch geringen Unterstützung in der Praxis noch nicht nutzbar sein, aber ich würde Geschwindigkeit auf WebP-Niveau bei besserer Qualität erwarten

    • rav1e ist seit Jahren ohne Updates eingefroren, daher soll man besser Encoder wie aom oder svt-av1 verwenden
    • Bei AVIF muss man die CPU-Nutzungsparameter anpassen. Die Standardeinstellung verwendet ein zu hohes CPU-Level und ist deshalb langsam
      In meiner Umgebung wird ein 2-MP-AVIF in etwa 100 ms erzeugt

  • Schade ist, dass die öffentliche Spezifikation (spec) von JPEG XL nicht frei zugänglich ist

    • Ich finde es beschämend, einen nicht öffentlich zugänglichen Standard aufrechtzuerhalten
    • Das Problem ist die Realität, dass viele Dokumente von Institutionen wie ISO oder IEC hinter einer Paywall liegen

  • Wir haben wieder ein neues Bildformat bekommen, und ich mache mir Sorgen, dass sich die Situation wiederholt, in der es am Ende ohne Konvertierung nicht nutzbar ist

    • Trotzdem hat sogar Microsoft ein JPEG-XL-Add-on veröffentlicht, und jetzt, da Google zurückgerudert ist, sehe ich eine echte Chance
      Microsoft-Store-Link
    • Tatsächlich unterstützen es bereits viele Apps — Affinity, Photoshop, Microsoft Photos, Gimp und sogar systemweite Unterstützung in iOS 17+/macOS 12+
      Chromium ist eher spät dran
    • Natürlich brauchen neue Formate immer etwa 10 Jahre Einführungszeit

  • Als ich auf Wikipedia die Funktionsliste von JPEG XL gelesen habe, gab es interessante Features wie Mehrkanalbilder oder mehrseitige Dokumente
    Das hat gute Seiten, fühlt sich aber zunehmend so komplex wie TIFF an

  • Zwischen JPEG und JPEG-XL gibt es immer noch viele Gemeinsamkeiten
    Ich frage mich, ob eine neue Implementierung, die auch bestehende JPEG-Unterstützung integriert, die Codegröße reduzieren könnte

    • Tatsächlich gibt es dafür bereits ein Issue im JPEG-XL-Rust-Repository
      Link zu Issue #513

  • Persönlich würde ich lieber weiterhin das bestehende JPEG verwenden als ein neues Format wie WEBP
    Die meisten Programme unterstützen es, und für normale Nutzer reichen JPEG + PNG aus
    Einfache Animationen kann man mit GIF machen, komplexere als Video

    • „JPEG XL“ ist trotz des Namens nicht einfach nur eine Erweiterung von JPEG
      Es ermöglicht verlustfreie Codierung mit kleineren Dateigrößen als PNG und unterstützt reversibles Transcoding, wobei bestehende JPEGs um 20 % weiter komprimiert werden können
      Es bietet verschiedene Funktionen wie HDR, Wide Gamut und progressives Laden und ist damit auch ideal für die Web-Auslieferung
      Siehe jpegxl.info
    • WebP kann man inzwischen praktisch als Standardformat ansehen
      Alle großen Browser unterstützen es seit Safari 14, und seit Windows 10 bzw. macOS Big Sur ist es standardmäßig enthalten
      Siehe Unterstützungsstatus und Softwareliste
    • GIF ist inzwischen ineffizient. Es durch Videos zu ersetzen ist 5- bis 10-mal effizienter
      Verwandter Artikel

  • Ich höre seit Langem die Debatte über JPEG XL, WebP und AVIF, wusste aber nicht viel darüber
    Wenn man sich Benchmarks ansieht, scheint JpegXL sowohl bei Kompressionsgeschwindigkeit als auch Dateigröße besser als WebP zu sein; deshalb frage ich mich, warum Chromium die Einführung so zögerlich angegangen ist

    • WebP und AVIF teilen Code mit VP8/AV1 und lassen sich deshalb leicht in Browser integrieren, während JPEG-XL eine separate Codebasis ist und die Implementierung aufwendiger macht
      Außerdem umfasst libjxl mehr als 100.000 Zeilen C++-Code, sodass das Risiko von Sicherheitslücken bestand
      Mit der Reifung der Rust-Implementierung scheint Chrome das erneut zu prüfen
    • JPEG XL unterstützt progressives Decoding
      Demo-Video
    • Google argumentierte, dass „mehrere ähnliche Formate nur das Sicherheitsrisiko erhöhen“ und AVIF allein ausreiche
    • AVIF ist bei niedriger bpp (geringer Qualität) gut, aber schwach bei verlustfrei, während JXL bei hoher Qualität und verlustfrei stark ist
    • Früher war die C++-Bibliothek für JPEGXL nicht mehr aktiv gepflegt, doch mit dem Erscheinen der Rust-Version wurde eine Browser-Einführung wieder möglich

  • Ich habe mich gefragt, ob JPEG XL Animationen unterstützt

    • Ja, aber ohne Inter-Frame-Kompression ist es ineffizient, daher sind die Dateien größer als bei normalem Video
    • Laut der Chrome-Platform-Status-Seite werden Animationen, HDR und progressives Decoding alle unterstützt
      Detail-Link
    • Ich habe es tatsächlich im Canary-Browser getestet, und die Animation funktionierte gut
    • Jemand sagte scherzhaft, WebP sei im Grunde „ein Bildformat, das eigentlich ein Videoformat ist“, während JPEG XL „ein Videoformat ist, das eigentlich ein Bildformat ist“ — eine paradoxe Symmetrie also 😄