TIFF in GIF umwandeln

Deutsche Verwaltungen betreiben eine erstaunliche Zahl an Fachverfahren, die vor zwanzig Jahren beschafft und seither kaum angefasst wurden — die Ausschreibung war teuer, der Wartungsvertrag läuft, und niemand tauscht ein laufendes System ohne triftigen Grund. Die Liste akzeptierter Bildformate in solch einer Software wurde damals geschrieben und seitdem nicht überarbeitet, und GIF steht darauf, weil es 1987 universell lesbar war und es bis heute geblieben ist.

Wer ein eingescanntes Formular in ein solches Verwaltungsportal, ein internes Wiki oder ein altes Ticketsystem einer Sparkasse laden muss, landet deshalb hier — nicht wegen einer Vorliebe für GIF, sondern weil die Liste kurz ist und GIF der einzige noch nicht ausprobierte Eintrag darauf ist.

GIFs bekannte Grenze von 256 Farben stört das Material dieser Seite kaum. Ein Fax, ein Group-4-Scan, ein ausgefülltes Formular oder eine Strichzeichnung nutzt zwei dieser 256 Plätze — die Palette kostet also nichts, jeder Pixel kommt exakt an, und die Datei bleibt klein, weil GIFs LZW-Kompression bei langen Läufen identischer Pixel sehr gut arbeitet.

Das ist der Fall, für den diese Seite gedacht ist, und er ist häufig: schwarz-weiß ist die Standardeinstellung fast jedes Dokumentenscanners. Ein Graustufen-Scan ist fast ebenso gut, weil 256 Grautöne genau das sind, was ein 8-Bit-Graustufenbild ohnehin hat. Schwierig wird es bei Farbe und bei Rastertönen, und das plötzlich statt allmählich.

Irgendetwas muss entscheiden, welche Farben überleben, und hier ist das gifenc, das eine Palette per paarweiser Nachbarschaftsclusterung aufbaut — ein Port von PnnQuant.js — statt nach Häufigkeit. Die Palette wird aus einem reduzierten Farbraum gewählt statt aus den vollen sechzehn Millionen, was etwas Genauigkeit kostet und bei einem großen Scan mehrere Sekunden spart.

Bei durchgehenden Tonwerten sieht das Ergebnis niemandem nach gut aus, ohne offensichtlich zerstört zu sein: ein Himmel wird zu sichtbaren Stufen, Hauttöne werden fleckig, ein rastergedrucktes Original bekommt ein Moiré, das im Scan nicht vorhanden war. Bei den Beispieldateien dieser Seite ist das Foto als GIF 37.227 Byte groß gegenüber 14.700 Byte als WebP — größer und schlechter zugleich, ein klares Zeichen, dass die Zielsoftware und nicht das Bild selbst der Grund für diesen Weg ist.

GIF kennt Transparenz nur begrenzt: ein Palettenplatz kann als unsichtbar markiert werden. Der hier verwendete Kodierer markiert keinen, im Ergebnis ist also nichts transparent. Was aus den transparenten Pixeln wird, ist die Hintergrundfarbe im Bedienfeld, angewendet, bevor die Palette gebaut wird, standardmäßig Weiß.

Diese Farbe vor einem größeren Stapel auf das setzen, was hinter dem Bild im Zielsystem erscheint, lohnt sich. Ein gescanntes Logo mit Freistellung oder ein TIFF mit Alphakanal aus einem Designprogramm kommt danach auf einem Rechteck dieser Farbe an, mit einem eingefärbten Saum an der weichen Kante. Ist die Transparenz selbst wichtig, halten TIFF zu PNG und TIFF zu WebP sie beide, und TIFF zu ICO ebenfalls, wenn das Ziel ein Favicon ist.

Zwei Containereigenschaften treffen hier aufeinander, und keine ist offensichtlich. Ein TIFF kann viele Bilder tragen, der Leser hier nimmt das erste; ein GIF kann viele Einzelbilder tragen, der Schreiber hier erzeugt genau eines. Ein sechsseitiger eingescannter Vorgang wird so still zu einem einzelnen Standbild von Seite eins.

Damit entfällt auch eine Hoffnung, die manche auf diese Seite bringt: aus einem mehrseitigen TIFF wird kein animiertes GIF. Hier werden keine Einzelbilder aus Seiten zusammengesetzt, und selbst wenn, wäre eine Animation der falsche Behälter für ein Dokument. Das TIFF vorher mit ImageMagick oder IrfanView aufteilen und jede Seite einzeln wandeln ist der einzige Weg zu allen Seiten — TIFF zu PDF hilft hier nicht, weil auch dort nur die erste Seite gelesen wird.

Deutlich, weil der Ausgangspunkt unkomprimiert ist. Die Beispieldateien dieser Seite sind bei 480 mal 320 Pixeln jedes Mal 615.400 Byte groß als TIFF, und als GIF sind es 6.326 Byte für die dokumentähnliche Szene, 7.688 für die flache Grafik und 37.227 für das Foto.

Die Reihenfolge dieser drei Werte ist die eigentlich nützliche Information: GIF ist auf flachem, kantenscharfem Material — genau das, was ein gescanntes Dokument ist — am stärksten und bei durchgehenden Tonwerten am schwächsten, praktisch das Gegenteil davon, wie sich JPEG verhält. Ein altes System, das sowohl GIF als auch JPEG annimmt, wird ein Formular deshalb besser als GIF und ein Foto besser als JPG verarbeiten, und beides über denselben Weg zu schicken, ist ein leicht vermeidbarer Fehler.

So gut wie alles außer den Pixeln der ersten Seite. Sechzehn Bit je Kanal werden auf acht reduziert, bevor die Quantisierung sie auf 256 Farben insgesamt eindampft. CMYK wird nach einer festen Formel statt über das eingebettete ICC-Profil in Bildschirmfarbe umgerechnet, ein Druckscan verschiebt sich also farblich. Ebenen werden zusammengeführt. EXIF, XMP, IPTC, das ICC-Profil und ein GPS-Block entfallen, ohne dass eine Einstellung sie erhalten könnte — die Umwandlung dekodiert zu Pixeln und kodiert aus Pixeln, für den EXIF-Block bleibt dabei kein Platz.

Für die Aufgabe, für die diese Seite gedacht ist, ist keiner dieser Verluste relevant: das Zielsystem wollte ein achtbittiges Bild eines Dokuments. Relevant wird es, wenn das TIFF die einzige Kopie ist — das TIFF behalten, das GIF hochladen, das Original bleibt von der Umwandlung unberührt.

GIF speichert seine Abmessungen in sechzehn Bit, ein Bild kann also bis zu 65.535 Pixel je Kante groß sein. Das ist das Vierfache von WebPs Grenze bei 16.383 und liegt bequem über allem, was ein Dokumentenscanner erzeugt — anders als bei der WebP-Seite scheitert diese Umwandlung also nicht an einem großen Scan.

Was bei einem großen Scan trotzdem beißt, sind Arbeitsspeicher und Geduld, nicht das Format. Ein 20.000 Pixel breites Bild zu quantisieren bedeutet, mehrere hundert Millionen Pixel im Tab durchzugehen, und das entstehende GIF wird trotz der deutlichen Verkleinerung gegenüber dem TIFF noch groß genug sein, dass das Zielsystem es selbst aus Größengründen ablehnen könnte. Die Breite vorher zu reduzieren — dieselbe Bedienfläche bietet das an — ist meist die sinnvollere Wahl; ein am Bildschirm betrachtetes Dokument braucht selten mehr als 2.000 Pixel Breite.

PNG, in fast jedem Fall. TIFF zu PNG hält jeden Pixel ohne Palettengrenze, wird von allem seit den neunziger Jahren gelesen und ist bei flachem, gescanntem Inhalt oft sogar kleiner als das GIF — das dokumentähnliche Beispiel dieser Seite ist als PNG 2.608 Byte groß gegenüber 6.326 als GIF. Steht PNG auf der akzeptierten Liste, gibt es kein Argument für GIF.

Ist das Ziel eine selbst betriebene Webseite, ist TIFF zu WebP nochmals kleiner und wird überall unterstützt. Handelt es sich um ein einseitiges Dokument, das archiviert oder weitergeleitet wird, liefert TIFF zu PDF das Format, das der Empfänger erwartet — bei mehreren Seiten vorher aufteilen, denn auch diese Umwandlung nimmt nur die erste. GIF ist die richtige Antwort nur dort, wo eine Liste irgendwo genau das verlangt, und diese Seite geht davon aus, dass es genau so ist.

Die ganze Umwandlung läuft im Tab: utif2 dekodiert das TIFF, gifenc baut die Palette und schreibt das GIF, beide werden nur geladen, wenn sie tatsächlich gebraucht werden. Es wird nichts hochgeladen — wichtig, wenn die Scans Aktenvorgänge, Schriftverkehr oder etwas mit einem Namen darauf sind.

Die freie Grenze liegt bei 100 MB je Datei, etwa ein bei 600 dpi unkomprimiert gescanntes DIN-A4-Farbblatt. Auch ganze Ordner funktionieren — ablegen, jede Zeile beobachten, ein ZIP abholen — und der Quantisierungsschritt ist der langsame Teil, ein Stapel großer Farbscans dauert deshalb merklich länger als ein Stapel Schwarz-Weiß-Formulare. Ein paar Dateien zuerst zu prüfen und im Zielsystem zu testen, lohnt sich, bevor ein ganzer Ordner in ein Format geht, das niemand freiwillig wählen würde.