TIFF in JXL umwandeln

JPEG XL genießt gerade in der deutschen Open-Source-Fotoszene einen guten Ruf — darktable, der freie RAW-Entwickler mit einer aktiven deutschsprachigen Community und Mitwirkenden, hat das Format früh unterstützt, und wer dort mitliest, hat wahrscheinlich gelesen, dass JXL für Archivzwecke ernsthaft in Frage kommt.

Das stimmt für das Format im Allgemeinen und nicht für das, was dieser Konverter daraus macht. Die Pipeline hier dekodiert alles auf 8-Bit-RGB und kodiert mit einer Qualitätsstufe statt verlustfrei — ein gutes, kleines Ableitungsbild, kein archivfähiges Master.

Der Regler reicht bis 100, und der Kodierer verhält sich am oberen Ende anders, als man vermuten würde — es lohnt sich, den Wert nachzumessen statt anzunehmen. Gemessen an einem 256 mal 256 Pixel großen Testbild dieser Seite: bei der Standardstufe 82 kamen 73.647 von 262.144 Werten verändert zurück, im schlimmsten Fall um 21 Stufen. Bei 100 waren es 334 Werte, keiner mehr als um eine Stufe.

Das ist nahezu verlustfrei, nicht bitgenau — für ein Archiv ein wichtiger Unterschied, für ein einfaches Beweisfoto belanglos. In der Praxis heißt das: bei 82 bleiben für alles, was nur betrachtet wird, bei 100 für alles, was später noch einmal neu kodiert wird, und keinesfalls das Ergebnis in einem Katalogeintrag als verlustfreie Kopie beschreiben. Der eigentliche verlustfreie Modus des zugrunde liegenden Kodierers steckt in der Bibliothek und wird von diesem Konverter nicht angeboten.

Sehr viele TIFF-Dateien liegen mit sechzehn Bit vor — das ist überhaupt der Sinn, in TIFF zu scannen, weil es einem Scan Spielraum für spätere Gradations- und Belichtungskorrekturen gibt. Der hier verwendete Leser dekodiert das korrekt und gibt danach acht Bit je Kanal weiter, indem er das höherwertige Byte je Wert behält. Gemessen an einer 16-Bit-Graustufen-TIFF-Datei: ein gespeicherter Wert von 30.000 kommt als 117 an.

An einem fertigen Bild ist das für niemanden zu sehen, weil ein Bildschirm ohnehin nur acht Bit zeigt. Am Bearbeitungsmaster ist es der ganze Unterschied — genau der Spielraum, der eine kräftige Gradationskurve ohne Bänderung überstehen würde, ist verschwunden, und eine spätere Korrektur am 8-Bit-Ergebnis bändert sichtbar. Wer bewusst mit sechzehn Bit gescannt hat, verliert diese Entscheidung auf dieser Seite.

Ein TIFF aus einer Druckvorstufe ist oft CMYK mit angehängtem ICC-Profil, und genau diese Kombination macht es druckfähig. Der Leser rechnet CMYK nach einer festen Formel statt über das eingebettete Profil in Bildschirmfarbe um — das Ergebnis ist erkennbar dasselbe Bild in leicht verschobener Farbe, meist flach in den tiefen Schatten und etwas kühler, als das Profil ausgeglichen hätte.

Das Profil selbst reist ebenfalls nicht mit. Jede Bildumwandlung auf dieser Seite dekodiert zu rohen Pixeln und kodiert neu, ICC, EXIF, XMP, IPTC und ein eventueller GPS-Block entfallen also ausnahmslos, ohne dass eine Einstellung das ändern könnte. Für eine Druckvorlage ist das ein echter Verlust und der zweite Grund, diese Umwandlung nicht als Archivmigration zu behandeln. Für ein Bild am Bildschirm kostet es nichts.

TIFF trägt mehrere Bilder je Datei, und Dokumentenscanner nutzen das ständig. JPEG XL kennt in dieser Ausgabe nur eines. Der Leser nimmt die erste Seite und hört auf, ohne Fehlermeldung und ohne Hinweis auf der Oberfläche, dass danach noch etwas kam.

Das ist der Punkt, an dem diese Umwandlung eine ganze Sammlung leise falsch behandeln kann, und der sich vor einem Stapellauf zu prüfen lohnt, nicht danach. Stammen die TIFF-Dateien aus einem Dokumentenscanner oder einem Fax-Gateway, ist mit mehreren Seiten zu rechnen — ein paar davon vorher öffnen. Das Aufteilen ist mit ImageMagick eine Zeile Code oder in IrfanView ein Menüpunkt — TIFF zu PDF ist hier keine Abkürzung, denn auch dort kommt nur die erste Seite an.

Sehr viel kleiner, weil der Ausgangspunkt unkomprimiert ist. Die eigenen Beispieldateien dieser Seite sind bei 480 mal 320 Pixeln jedes Mal 615.400 Byte als TIFF; als JXL bei Standardqualität sind es 7.240 Byte für das Foto, 13.252 für die dokumentähnliche Szene und 5.016 für die flache Grafik.

Der fotografische Wert ist der interessante: 7.240 Byte ist der kleinste unter allen Formaten in diesem Vergleich, unter WebPs 14.700 und AVIFs 17.599. JPEG XL ist bei durchgehendem Tonwert und dieser Qualitätsstufe tatsächlich der stärkste der drei Kodierer — wäre die Byteanzahl die einzige Frage, gewänne es. Sie ist nie die einzige Frage, wie der nächste Abschnitt zeigt.

Hier verliert JPEG XL, und das macht das Format zu einer Nischenwahl statt zu einer aktuellen. Die Browserunterstützung ist teilweise statt durchgängig, ein .jxl gehört also nicht ohne Rücksprache auf eine Webseite oder als E-Mail-Anhang. GIMP und ImageMagick öffnen es problemlos, Photoshop braucht ein Plug-in, ein großer Teil gewöhnlicher Software zeigt schlicht ein Symbol für unbekannte Dateien.

Das lässt zwei ehrliche Anwendungsfälle übrig. Der erste ist ein geschlossener Workflow — die eigenen Werkzeuge, der eigene Speicher, eine Pipeline, die das Format ausdrücklich verlangt hat. Der zweite ist bewusstes Experimentieren, mit dem Original sicher an anderer Stelle aufbewahrt. Alles, was eine fremde Person öffnen soll, gehört besser als WebP, JPG oder PNG dorthin.

War das Ziel eine kleinere, aber exakte Archivkopie, ist TIFF zu PNG die ehrlichere Idee: PNG ist innerhalb von acht Bit verlustfrei, jede Software liest es, und bei flachem gescanntem Inhalt ist es oft sogar kleiner als eine hochwertige verlustbehaftete Datei. Sechzehn Bit rettet auch PNG nicht — das tut hier nichts —, aber es verliert sonst nichts zusätzlich.

War das Ziel eine Veröffentlichung, funktioniert TIFF zu WebP in jedem Browser, und TIFF zu AVIF ist bei flachem gescanntem Material kleiner und hebt die Pixelgrenze an. Sollte die Datei an eine Person gehen, sind TIFF zu PDF oder TIFF zu JPG das erwartete Format. Und ging es tatsächlich um ein Archivmaster, bleibt die unbequeme, aber richtige Antwort: das bereits vorhandene TIFF ist das Archivmaster und sollte es bleiben.

Eine belastbare Migration von TIFF-Beständen auf ein neues Zielformat bräuchte einen verlustfreien Kodierer, volle Bittiefe und ein mitgeführtes Farbprofil — alles Anforderungen, die eine dedizierte Werkzeugkette und in der Regel eine Fachabteilung mit Erfahrung in digitaler Langzeitarchivierung verlangen, keinen Browser-Konverter.

Diese Seite ersetzt diese Entscheidung nicht und will es auch nicht. Sie ist der richtige Ort für ein einzelnes, kleines Ableitungsbild aus einem Master, den es weiterhin gibt — nicht der Ort, an dem eine Institution ihre Archivstrategie festlegt.

utif2 dekodiert das TIFF, libjxl als WebAssembly schreibt das JXL, beide werden nur geladen, wenn tatsächlich eine passende Datei abgelegt wird. Nichts an der Datei geht über das Netz — der eigentliche Grund, warum sich diese Seite auch für noch nicht veröffentlichtes oder eingeschränktes Material eignet. Die freie Grenze liegt bei 100 MB je Datei, etwa ein bei 600 dpi unkomprimiert gescanntes DIN-A4-Farbblatt.

Auch Stapel funktionieren: Ordner ablegen, jede Datei mit eigener Fortschrittszeile, am Ende ein ZIP abholen. Die JXL-Kodierung ist nicht so langsam wie AVIF, aber auch nicht sofort fertig — ein größerer Lauf ist es wert, gestartet und dann liegen gelassen zu werden. Der Kodierer wird einmal geladen und für den Rest des Stapels wiederverwendet.