AVIF in JXL umwandeln

Diese Umwandlung lohnt sich, wenn etwas Konkretes JPEG XL verlangt: ein Werkzeug, das nichts anderes liest, eine Pipeline, die um das Format herum gebaut wurde, oder eine Archivrichtlinie, die den ISO-Standard ausdrücklich nennt. In diesen Fällen leistet die Umwandlung genau, was gebraucht wird.

Klingt der Grund eher nach „JPEG XL soll ja moderner sein", lohnt sich ein zweiter Blick. Die beiden Formate liegen bei der Kompression eng beieinander, die Umwandlung kostet eine zweite verlustbehaftete Generation, und AVIF ist das Format, das jeder aktuelle Browser liest, während JPEG XL nur teilweise unterstützt wird. Eine funktionierende Weblösung zu JXL umzuwandeln, verbessert an der Stelle, wo das Bild eingesetzt wird, in aller Regel gar nichts.

AVIF wurde 2019 von der Alliance for Open Media veröffentlicht, auf dem Videocodec AV1 aufbauend. JPEG XL folgte 2022 vom JPEG-Komitee selbst als ISO/IEC 18181-1 — technisch ambitioniert und in manchen Punkten sogar der elegantere Entwurf.

Verbreitung folgt selten der technischen Qualität allein. Die Unterstützung für AVIF ist in aktuellen Browsern inzwischen die Regel, die für JPEG XL bleibt lückenhaft. Genau dieser Unterschied entscheidet mehr über den Sinn dieser Umwandlung als jede Frage danach, welcher Codec der bessere ist, und er wird sich kaum von heute auf morgen ändern — das Argument für ein zweites modernes Format wird jedes Jahr schwächer, in dem das erste bereits ausgerollt ist.

Die AVIF-Datei wird zu rohen Bildpunkten dekodiert, und genau diese Bildpunkte kodiert der JPEG-XL-Encoder danach neu. Nichts geht in seiner komprimierten Form direkt hinüber, sodass alles, was der AVIF-Encoder bereits verworfen hat, verworfen bleibt — und der JPEG-XL-Encoder auf dieser Grundlage seine eigenen Entscheidungen trifft.

Bei der Standardqualität von 82 ist der zweite Durchgang bei einem Foto meist nicht auffällig, kostenlos ist er trotzdem nicht: Feine Textur, Filmkorn und die leichte Blockbildung, die verlustbehaftetes AVIF an harten Kanten hinterlässt, sind genau das, was ein zweiter Encoder am schlechtesten verarbeitet — er beschreibt dann die Fehler des ersten Encoders, als wären sie Teil des Motivs.

Auf dem Papier geht JPEG XL in mehreren Punkten weiter als AVIF, die für Fotografie und Archivierung relevant sind: bis zu 32 Bit pro Kanal statt zwölf, gebaut für Farbraumarbeit jenseits von sRGB, und mit Langzeitarchivierung großer Fotosammlungen ausdrücklich als Entwurfsziel statt als Nebeneffekt eines Videocodecs.

Deutsche Digitalisierungsprojekte, etwa die DFG-Praxisregeln „Digitalisierung", setzen für archivische Master-Dateien traditionell auf unkomprimiertes oder verlustfreies TIFF, gerade weil eine bereits verlustbehaftete Quelle diese Vorteile ohnehin nicht ausspielen kann. Genau das trifft auch auf diese Umwandlung zu: Was am Encoder ankommt, hat den Browser-Bildpfad bereits mit acht Bit pro Kanal durchlaufen, sodass die zusätzliche Bittiefe hier rein theoretisch bleibt.

Das stärkste praktische Argument für JPEG XL ist die Fähigkeit, ein bestehendes JPEG rund zwanzig Prozent kleiner zu verpacken, mit unverändert und vollständig rekonstruierbar erhaltenen Bilddaten. Das ist unter Bildformaten selten, und deshalb nehmen große Fotoarchive das Format ernst.

Diese Fähigkeit setzt voraus, dass JPEG-Daten umgeordnet statt neu kodiert werden — eine AVIF-Datei enthält stattdessen AV1-Daten, eine völlig andere Repräsentation des Bildes, ohne Gemeinsamkeit mit einem JPEG außer der Kompression an sich. Es gibt hier also nichts umzuordnen, und diese Umwandlung bleibt ein gewöhnliches Dekodieren und erneutes Kodieren wie jede andere. Wer noch JPEG-Originale besitzt, findet dort das eigentlich interessante Anwendungsfeld für JPEG XL.

GIMP und ImageMagick lesen JPEG XL, und beide lesen auch AVIF — was die Lage auf dem Desktop ziemlich genau zusammenfasst: Wo das eine Format unterstützt wird, meist auch das andere. Diese Umwandlung löst also selten das Problem „ich kann diese Datei nicht öffnen".

Bei Betriebssystemvorschauen, älteren Bildbearbeitungsprogrammen, Upload-Formularen und Druckdiensten wird es schnell dünn, und wo eines von beiden unterstützt wird, ist es häufiger AVIF, weil eine Browser-Engine in sehr viel mehr Software steckt, als man vermutet. Soll das Bild von möglichst vielen ohne Nachfrage geöffnet werden können, sind weder AVIF noch JXL die richtige Wahl — dafür gibt es auf dieser Seite die Umwandlung nach JPG oder PNG.

Ein picture-Element mit einer JXL-Quelle und AVIF oder JPEG als Fallback funktioniert technisch problemlos. Was es nicht liefert, ist eine Ersparnis, denn der Fallback muss ohnehin erzeugt und vorgehalten werden.

Genau das ist die unangenehme Rechnung für den Web-Performance-Fall: Man startet mit einem Format, das praktisch jeden erreicht, bei einer Größe nahe am derzeit Möglichen, und endet mit zwei Dateien, einer Aushandlung und einem Cache, der beide vorhalten muss. Die Ersparnis bei den wenigen Besucherinnen und Besuchern mit JXL-Unterstützung müsste das alles aufwiegen — bei einem Format mit lückenhafter Unterstützung gelingt das selten.

Die Standardeinstellung von 82 ist für ein Foto ein vernünftiger Kompromiss und der Wert, den man ohne besonderen Grund unangetastet lassen sollte. Eine Erhöhung Richtung 95 macht den zweiten Kodierdurchgang konservativer — sinnvoll, wenn die Datei später noch bearbeitet oder erneut umkodiert wird.

Eine Absenkung unter 70 lohnt sich bei diesem Format-Paar selten. Die Quelle ist bereits komprimiert, sodass die Artefakte des ersten und des zweiten Encoders an denselben Kanten zusammenkommen und sich schneller aufsummieren als bei einem echten Original. Ist die Zieldateigröße das eigentliche Problem, ist eine geringere Auflösung fast immer der bessere Hebel als eine niedrigere Qualitätsstufe.

Beide Formate können EXIF, XMP und ein ICC-Profil tragen, und keines davon übersteht diesen Weg. Jede Bildumwandlung hier dekodiert zu rohen Bildpunkten und schreibt daraus eine neue Datei — Aufnahmedatum, Kameramodell und etwaige Koordinaten fallen dabei weg, statt übertragen zu werden.

Für ein Bild, das jemand anderem übergeben wird, ist das oft ein Gewinn und ein Handgriff weniger, weil gerade der Aufnahmeort am häufigsten vergessen wird zu entfernen. Für eine ganze Fotosammlung ist es ein echter Verlust: Das Aufnahmedatum ordnet eine Bibliothek zeitlich, und ein Ordner voller Dateien, die alle „heute erstellt" behaupten, ist kaum noch zu gebrauchen. Für eine solche Migration ist eine Desktop-Anwendung, die die Metadaten mitnimmt, das richtige Werkzeug — nicht ein Browser-Konverter.

Ein ganzer Ordner lässt sich auf einmal ablegen; die Dateien werden nacheinander auf dem eigenen Prozessor umgewandelt und kommen als ein ZIP zurück, ohne dass etwas hochgeladen wird und ohne tägliche Obergrenze. Die Kodierung ist schnell genug, dass ein großer Stapel eine Frage der Geduld ist, kein blockierter Nachmittag.

Die AVIF-Dateien sollten dabei aufbewahrt werden. Sie sind die frühere Generation, sie werden in fünf Jahren noch in jedem Browser angezeigt, und diese Umwandlung erneut auszuführen kostet nichts, falls sich die JXL-Kopien später als unnötig herausstellen. Die Quelle zu löschen, um bei zwei so ähnlich großen Formaten Platz zu sparen, ist der einzige Fehler an dieser Stelle, der sich nicht rückgängig machen lässt.

Der Schaden einer zweiten Generation hängt maßgeblich davon ab, wie sparsam die erste war. Eine AVIF, die selbst bei einer hohen Qualitätsstufe aus einem Original erzeugt wurde, hat noch relativ viel von den ursprünglichen Bildinformationen übrig, und der zweite Encoder findet entsprechend wenig eigene Fehler zum Nachzeichnen. Eine stark komprimierte AVIF, wie sie eine typische Webseite zur Bandbreitenersparnis ausliefert, hat dagegen schon viel verloren, und genau dieser Verlust wird im zweiten Durchgang mühsam nachgebildet.

Wer die Wahl hat, sollte deshalb möglichst die am wenigsten komprimierte verfügbare AVIF-Fassung als Ausgangspunkt nehmen — eine Zwischenversion aus einer Bildbearbeitung etwa, statt der bereits für das Web optimierten Ausgabedatei einer Webseite. Der Unterschied ist am Ende oft größer als jede Feinjustierung der Zielqualität beim JPEG-XL-Encoder selbst.

Bevor eine ganze Sammlung durchläuft, lohnt sich ein einziges Testbild. Ob die JXL-Datei am Ende kleiner oder größer als die AVIF-Quelle ausfällt, hängt am Motiv: Bei einer bereits stark komprimierten AVIF gewinnt der zweite Encoder selten etwas, bei einer eher vorsichtig komprimierten AVIF manchmal doch. Beide Dateien nebeneinanderzulegen und die Größen zu vergleichen dauert eine Minute und erspart die Überraschung nach einem großen Stapel.

Dieser Test lohnt sich besonders, wenn die JXL-Datei tatsächlich für eine Archivrichtlinie erzeugt wird, die eine bestimmte Zielgröße oder Qualitätsstufe vorschreibt. Ein einzelnes Bild zeigt in wenigen Sekunden, ob die Standardeinstellung passt oder ob die Qualitätsstufe für die konkrete Bildart angepasst werden sollte, bevor der gesamte Bestand durchläuft.