GIF in JXL umwandeln

Wer noch Ordner voller GIFs aus der Zeit der eigenen Tripod- oder Geocities-artigen Homepage besitzt — blinkende Trennlinien, „Under Construction"-Banner, animierte Gästebuch-Icons —, hat meist kein Weiterleitungsproblem, sondern ein Aufbewahrungsproblem. JPEG XL ist genau dafür gedacht: ein Format fürs Archiv, nicht fürs Ausliefern an fremde Browser.

Wer dagegen Dateigröße für eine Webseite sparen will, ist hier falsch — dafür sind die Lieferformate gedacht, die auf breite Browserunterstützung zielen. Diese Seite ist für den Ordner auf der eigenen Festplatte, den jemand seit Jahren nicht mehr angefasst hat und jetzt in ein moderneres Format überführen will.

JPEG XL wurde für kontinuierliche Farbverläufe entwickelt — Fotografien mit vielen Millionen Farben. Ein GIF hat davon nichts: Es ist 256-farbig indiziert und war das schon, bevor die Umwandlung überhaupt beginnt.

Das ist kein Fehler, nur eine Fehlpassung. Der neue Codec bekommt Material, für das er nicht gebaut wurde, und der Größengewinn gegenüber dem Original fällt entsprechend unregelmäßig aus — mal deutlich kleiner, mal kaum anders.

Die Umwandlung stellt einen einzigen Qualitätswert zwischen 1 und 100 bereit, standardmäßig 82, und keinen separaten Modus für verlustfreie Ausgabe. Was herauskommt, ist also eine Neukodierung, keine exakte Kopie der ursprünglichen Bildpunkte.

Für ein Archiv ist das der entscheidende Unterschied. Wer das Original bewahren will, sollte den Regler an das obere Ende stellen und die größere Datei in Kauf nehmen, oder gleich zu einem Format greifen, bei dem Verlustfreiheit keine Einstellung, sondern die Eigenschaft des Formats selbst ist.

PNG komprimiert verlustfrei, öffnet in praktisch jeder Software seit dreißig Jahren und ist für genau dieses Material gebaut — flache Farbflächen, harte Kanten, begrenzte Paletten. Bei einem typischen alten GIF liegt die PNG-Größe nah an der JXL-Größe, und PNG ist dabei exakt.

Wirklich lohnt sich JXL bei einem GIF, das eigentlich ein stark gedithertes Foto oder einen Screenshot eines Fotos zeigt — Material, bei dem die Palettenreduktion Rauschen erzeugt hat, an dem PNGs verlustfreie Kompression nichts findet. Das ist bei den meisten Sammlungen die Minderheit der Dateien. Wer unsicher ist, welcher Fall vorliegt, kann eine einzelne Datei probeweise in beide Formate umwandeln und die beiden Ergebnisgrößen direkt vergleichen, bevor er sich für eine ganze Sammlung entscheidet.

JPEG XL kann Animationen speichern, diese Umwandlung erzeugt aber keine: Ein einzelnes Bild aus dem GIF wird dekodiert, ein einzelnes Bild wird geschrieben. Aus einer animierten Grußkarte oder einem blinkenden Banner wird also genau das Standbild, mit dem das GIF sonst zuerst öffnet.

Für ein Archiv, dem die Animation wichtig ist, bleibt entweder das GIF selbst die richtige Aufbewahrungsform, oder eine Umwandlung in ein Videoformat, bei dem ein echter Videokodierer die Bewegung tatsächlich erhält, statt sie auf ein Bild zu reduzieren.

Ein transparenter Hintergrund im GIF bleibt beim Umwandeln erhalten, weil JPEG XL einen vollständigen Alphakanal kennt und dieser Weg ihn nicht wegfaltet. Was das GIF an Transparenz vorgibt, kommt also an.

Weicher wird sie dadurch nicht: Ein GIF kennt nur „ganz durchsichtig" oder „ganz sichtbar", keine Zwischenstufen, und genau dieser harte Übergang wird übernommen — mit denselben gezackten Kanten, die das GIF ohnehin schon hatte.

Ob der eigene Browser JPEG XL überhaupt darstellen kann, ist für die Umwandlung selbst unerheblich: Der Kodierer ist ein WebAssembly-Modul, das im Tab läuft, unabhängig davon, welche Bildformate der Browser sonst versteht.

Die sichtbare Folge ist, dass sich die entstandene Datei möglicherweise nicht direkt im selben Tab ansehen lässt. Wer prüfen will, ob das Ergebnis stimmt, öffnet die erste Datei am besten in GIMP, in ImageMagick oder in einem eigenständigen Bildbetrachter, bevor eine ganze Sammlung umgewandelt wird.

GIMP liest und schreibt das Format, ImageMagick ebenfalls — was JPEG XL auch skriptfähig macht, falls mit der Sammlung später noch etwas geschehen soll. Einige Desktop-Bildbetrachter haben Unterstützung ergänzt, die Vorschau in Dateimanagern ist dagegen uneinheitlich.

Was auf dieser Liste fehlt, ist die Zusicherung, dass eine Bekannte, ein Kunde oder ein Web-Formular die Datei annimmt. Für alles, was noch geteilt werden könnte, lohnt sich eine Kopie in einem Format, das niemand erklären muss — die JXL-Version bleibt dann die Archivkopie, nicht die einzige.

Ein ganzer Ordner wird auf einmal abgelegt, jede Datei einzeln im Browser kodiert, die Ergebnisse gemeinsam zurückgegeben. Der WebAssembly-Kodierer wird dabei nur einmal geladen und für jede weitere Datei wiederverwendet, sodass nur die erste Datei den Ladeaufwand trägt.

Nichts davon wird hochgeladen, ein Konto wird nicht gebraucht, und die freie Grenze liegt bei 100 MB je Datei — für ein einzelnes Standbild aus einem GIF eine Größe, die praktisch nie erreicht wird. Bis zu hundert Dateien passen in einen einzigen Durchgang, was für einen Ordner mit mehreren hundert alten GIFs bedeutet, ihn in wenigen Gruppen statt in Hunderten einzelnen Schritten abzuarbeiten.

Ein einzelnes Standbild — ein Emoji-artiges Icon, ein statisches Forensymbol, ein Logo, das nie animiert war — verliert beim Umwandeln nichts, was eine Animation betrifft, weil es keine hat. Hier zählt nur, ob die 256 Palettenfarben des GIFs schon alles waren, was das Motiv brauchte, oder ob es eigentlich ein gedithertes Foto ist.

Bei einem echten Icon mit wenigen flachen Farbflächen liegt PNG meist ohnehin sehr nah an der Größe der JXL-Datei, und dann entscheidet eher die gewünschte Zielumgebung als die Dateigröße. Für ein Archiv alter Forensymbole ist das der Fall, bei dem sich die Frage nach JPEG XL am wenigsten lohnt.

Der JPEG-XL-Kodierer ist ein WebAssembly-Modul, das erst beim ersten umgewandelten Bild geladen wird — bei der ersten Datei einer Sitzung ist deshalb eine kurze Pause spürbar, bevor überhaupt etwas passiert. Jede weitere Datei in derselben Sitzung nutzt das bereits geladene Modul erneut.

Bei einer einzelnen Testdatei fällt dieser Ladeaufwand am meisten ins Gewicht; bei einem ganzen Ordner mit hundert Dateien verteilt er sich auf die gesamte Stapelverarbeitung und ist am Ende kaum noch messbar. Wer die Wartezeit prüfen will, wandelt am besten erst eine einzelne Datei um, bevor die ganze Sammlung folgt.

Ein Archiv ist immer auch eine Wette darauf, die Dateien später wieder öffnen zu können. Bei einem Format, dessen Verbreitung sich seit der Standardisierung noch entwickelt, ist es der sicherere Weg, GIF und JXL eine Weile parallel zu behalten, statt sofort auf die neue Version umzustellen.

Plattenspeicher ist der günstigste Teil dieser Abwägung. Ein Ordner mit beiden Formaten kostet ein paar hundert Megabyte mehr; ein Ordner nur mit JXL-Dateien, die sich in fünf Jahren nicht mehr öffnen lassen, kostet die ganze Sammlung.

Ein paar Dutzend GIFs aus einem alten Forenprofil oder einer ICQ-Sammlung sind in wenigen Sekunden umgewandelt, aber der eigentliche Zeitaufwand liegt danach: Jede Datei müsste geöffnet und geprüft werden, ob PNG nicht ohnehin ausgereicht hätte. Bei einer kleinen Sammlung ist dieser Aufwand größer als der gesparte Platz.

Der Fall, in dem sich die Mühe wirklich lohnt, ist eine große Sammlung fotografisch wirkender GIFs — gescannte, geditherte Bilder aus einer Zeit begrenzter Bandbreite —, bei der der Größengewinn über hunderte Dateien tatsächlich spürbar wird.