WebP in JXL umwandeln

Kaum ein Bildformat wurde in deutschen Computerzeitschriften so ausführlich verhandelt wie JPEG XL. Als Google die experimentelle Unterstützung wieder aus Chrome entfernte, war das in der deutschen Fachpresse ein eigenes Thema, samt der Frage, warum ein Format mit derart überzeugenden Kompressionswerten am Widerstand der großen Browserhersteller scheitert. Wer diese Debatte verfolgt hat, landet irgendwann bei der praktischen Frage: Lohnt sich das eigentlich für die eigene Bildersammlung?

Diese Seite beantwortet das mit einer Messung statt mit einer Meinung. JPEG XL komprimiert Fotos hier spürbar stärker als WebP, verliert aber bei flachem, kantenreichem Material gegen die eigene Quelle — und das ist der Teil der Geschichte, der in der Begeisterung für das Format gern untergeht.

Diese Website hält drei Testmotive vor und kodiert sie durch dieselbe Pipeline, die auch dieser Umwandler nutzt — die Zahlen stammen also direkt von hier. Bei 480 mal 320 Pixeln und Standardqualität: das Foto 14.700 Byte als WebP und 7.240 als JXL — die kleinste Zahl im gesamten Vergleich dieser Website, sogar unter AVIFs 17.599. Die flache Grafik liegt bei 4.428 als WebP gegen 5.016 als JXL. Die Bildschirmaufnahme bei 10.830 als WebP gegen 13.252 als JXL.

Der Ruf des Formats verdient sich also am durchgehenden Farbverlauf und nicht überall. JPEG XLs modulare und VarDCT-Modi wurden mit fotografischem Material im Blick entwickelt und sind bei mittlerer Qualität der stärkste der vier Codecs, die diese Website schreiben kann. Bei flachem, textlastigem Inhalt ist AVIF die bessere Wahl — 5.081 Byte für denselben Screenshot.

Das ist das am häufigsten missverstandene Detail rund um JPEG XL, und es lohnt sich, es vorab zu klären. JXL kann eine bestehende JPEG-Datei verlustfrei umpacken, spart dabei rund zwanzig Prozent und lässt sich später wieder byteidentisch in die ursprüngliche JPEG-Datei zurückverwandeln. Ein cleveres Verfahren — aber spezifisch für die Koeffizienten von JPEG.

Für WebP gibt es keine Entsprechung, dessen Kodierung funktioniert grundlegend anders. Und auch bei JPG als Quelle läuft es hier nicht so: Jede Bildumwandlung auf dieser Website dekodiert auf Pixel und kodiert neu, auf jedem Paar. Was hier entsteht, ist also stets eine frische Kodierung und kein Umpacken — und lässt sich nicht wieder in die ursprüngliche WebP-Datei zurückverwandeln.

Die Qualitätseinstellung reicht bis 100, und der Encoder verhält sich am oberen Ende anders, deshalb lohnt sich eine genaue Zahl. Gemessen an einem 256-mal-256-Testbild: bei der Standardeinstellung 82 wichen 73.647 von 262.144 Werten eines Verlaufs ab, im schlimmsten Fall um 21 Stufen. Bei 100 waren es 334 Werte, keiner um mehr als eine Stufe, und flache Grafik kam bei 100 byteidentisch zurück.

Das ist nahezu verlustfrei, aber nicht verlustfrei. Der dedizierte verlustfreie Modus der Bibliothek ist hier nicht freigeschaltet, eine Behauptung, die JXL-Datei sei eine verlustfreie Kopie, wäre also falsch. Praktisch: 82 für alles, was nur betrachtet wird, 100 für alles, was noch einmal weiterverarbeitet wird, und keins von beiden, wenn eigentlich eine bitgenaue Archivkopie gebraucht wird — dafür ist WebP zu PNG die richtige Seite.

WebP wird ohne Rückfalllösung von jedem aktuellen Browser gelesen, und genau deshalb sind die meisten dieser Dateien überhaupt WebP. JPEG XL wird von einigen gelesen — ein grundlegend anderer Zustand, denn ein Bild, das nicht dekodiert werden kann, ist kein schlechteres Bild, sondern gar keins.

Damit ist das hier eine Entscheidung für die Speicherung, keine für die Auslieferung. Eine Fotobibliothek als JXL zu führen und für die Website WebP oder AVIF daraus zu erzeugen, ist ein schlüssiger Plan. Die WebP-Dateien, die eine Website tatsächlich ausliefert, durch JXL zu ersetzen, ist es nicht — kein picture-Element rettet, wenn die Rückfalldatei genau die ist, die gerade gelöscht wurde.

Die meisten WebP-Dateien, die hier landen, wurden verlustbehaftet erzeugt — der übliche Standardfall für alles, was ein CMS, ein CDN oder eine Build-Pipeline zur Auslieferung erzeugt. Der Encoder hat flache Bereiche bereits geglättet und an harten Kanten geklingelt, und genau das ist jetzt das Bild.

Der JXL-Encoder bildet das originalgetreu nach und legt eine eigene Schicht darüber. Bei Qualität 82 ist das moderat. Vermeiden lässt es sich, indem stattdessen von der ursprünglichen PNG- oder JPG-Datei aus kodiert wird, falls sie noch in einem Repository oder Asset-System existiert — das Ergebnis ist dann sauberer und meist auch kleiner.

Beide Formate führen einen vollen 8-Bit-Alphakanal, ein freigestelltes Bild kommt also mit intakter Transparenz und weichen Kanten an, ohne dass irgendetwas geglättet oder aufgefüllt werden müsste — einer der Gründe, warum dieser Wechsel sauberer verläuft als eine Umwandlung nach JPG oder BMP.

Metadaten reisen nicht mit. EXIF, XMP und ein etwaiges ICC-Profil werden verworfen, weil jede Umwandlung auf reine Pixel dekodiert und daraus neu kodiert — nicht als Einstellung, sondern als Eigenschaft der Pipeline. JPEG XL selbst könnte alle drei tragen, es liegt also nicht am Format, sondern an dem, was diese Seite tut.

WebP führt entweder ein Standbild oder eine Animation, und der hier verwendete Dekoder liest nur die erste Sorte. Eine animierte Datei erzeugt eine lesbare Fehlermeldung statt eines Einzelbilds — die bessere der beiden möglichen Reaktionen, und dasselbe Verhalten bei jedem WebP-Paar auf dieser Website.

JPEG XL könnte im Prinzip eine Animation aufnehmen, aber nichts in dieser Pipeline extrahiert die Einzelbilder, die Frage stellt sich also nicht. Bei einem gemischten Ordner aus Standbildern und Animationen wandelt der Stapel die Standbilder um und meldet den Rest als Fehler — genau das gewünschte Verhalten, denn eine still erzeugte Reihe von Einzelbild-JXL-Dateien wäre schwerer zu bemerken und schwerer rückgängig zu machen.

GIMP und ImageMagick lesen und schreiben JPEG XL direkt, was die meisten skriptgesteuerten und technischen Arbeitsabläufe abdeckt. Photoshop braucht ein Plug-in. Windows- und macOS-Vorschauen sind uneinheitlich, und ein großer Teil gewöhnlicher Software — Office-Programme, Upload-Formulare, ältere Fotoverwaltungen — zeigt nur ein Symbol für eine unbekannte Datei.

Diese Enge ist das eigentliche praktische Argument, und sie erklärt auch, warum das Format trotz technischer Stärke als Nische gilt. Zwei Fälle rechtfertigen den Einsatz ehrlich: ein geschlossener Arbeitsablauf, den man selbst kontrolliert, und ein bewusstes Ausprobieren, bei dem die Originale sicher woanders liegen bleiben.

libwebp dekodiert, libjxl kodiert, beide als WebAssembly und beide erst geladen, wenn tatsächlich eine passende Datei abgelegt wird — ein ganzer Stapel lädt jeden Programmcode also nur einmal. Keine Datei geht dabei über das Netz, es gibt kein Konto und keine Tagesgrenze.

Die kostenlose Grenze liegt bei 100 MB je Datei, weit über jedem Webbild. Ein Ordner läuft mit eigener Fortschrittsanzeige pro Datei, am Ende steht ein ZIP bereit. JPEG-XL-Kodierung dauert länger als WebP und kürzer als AVIF — ein paar hundert Dateien sind also machbar, aber eine Runde mit fünf repräsentativen Bildern vorab lohnt sich, denn bei falschem Inhalt macht diese Umwandlung Dateien größer statt kleiner.