JXL in ICO umwandeln

TYPO3, das in Deutschland entstandene Open-Source-CMS, ist bei vielen Behörden, Kanzleien und mittelständischen Unternehmen im deutschsprachigen Raum im Einsatz, und im Einrichtungsassistenten fragt es an einer Stelle explizit nach einem Favicon im ICO-Format — nicht nach einem PNG, nicht nach einem SVG. Eine Design-Agentur, die ihre Bildbibliothek konsequent als JPEG XL pflegt, weil es kleiner ist und höhere Farbtiefe erlaubt, muss für dieses eine Feld trotzdem zum ältesten Format im ganzen Projekt zurück.

Diese Umwandlung schließt genau diese Lücke: aus dem Master ein ICO mit den gängigen Größen 48, 32 und 16 Pixel in einer Datei, ohne dass irgendwo im Prozess eine zweite Bildquelle gepflegt werden muss.

JPEG-XL-Unterstützung in Browsern gilt als teilweise, nicht als flächendeckend, und das ist oft genau der Grund, warum überhaupt nach dieser Seite gesucht wird: Die Datei zeigt im Tab nichts an, öffnet sich nicht aus dem Dateimanager und erzeugt bestenfalls einen Download-Dialog.

Der hier verwendete Decoder ist ein WebAssembly-Modul, das die Seite selbst lädt und ausführt — die Meinung des eigenen Browsers zu JPEG XL spielt dabei keine Rolle. Eine Datei, die im Browser leer erscheint, wandelt sich hier trotzdem einwandfrei um, was sich auch dazu nutzen lässt, überhaupt erst zu prüfen, was in einer erhaltenen .jxl-Datei steckt.

Unabhängig von der Quelle wird zuerst so skaliert, dass die längere Kante 256 Pixel misst. Das ist die Grenze des Formats, keine Voreinstellung: Jede Größenangabe in einem ICO-Verzeichniseintrag steht in einem einzelnen Byte, und 256 wird als Null geschrieben, weil die Zahl selbst nicht hineinpasst. Die tatsächlich geschriebenen Größen — mit der Standardeinstellung 48, 32 und 16 — kommen von diesem verkleinerten Bild, jede zentriert quadriert und als eigenes PNG gespeichert.

Für einen Master ist das eine sehr deutliche Reduktion, und sie verschiebt, wo die Sorgfalt hingehört. Nichts oberhalb von 256 Pixeln trägt zum Ergebnis bei, ein 6.000-Pixel-Original ist also kein besserer Ausgangspunkt als eines mit 600 Pixeln. Entscheidend ist der Ausschnitt, nicht die Ausgangsauflösung.

JPEG XL speichert Transparenz als echten Kanal mit jedem Zwischenwert, und das PNG innerhalb der ICO-Datei speichert denselben Kanal weiter. Ein Logo mit weicher Kante, ein ausgeblendeter Schatten oder ein mit Feder gezeichneter Strich überstehen die Umwandlung mit genau diesen Kanten.

Das ist der praktische Unterschied zu einer älteren Quelle mit nur einer transparenten Farbe: Dort bekommt das Icon einen harten, gezackten Umriss, der vor hellem wie vor dunklem Browser-Theme falsch wirkt, und keine Einstellung behebt das. Ein Master mit echtem Alpha komponiert dagegen korrekt über jeden Hintergrund.

Ein Master zeigt meist die volle Komposition — das ganze Signet, oder ein Bild mit Raum um das eigentliche Motiv. Ein Icon wird in einem 16- oder 32-Pixel-Kasten betrachtet, und bei dieser Größe wirkt eine vollständige Komposition nur wie ein Fleck, egal wie gut die Quelle war.

Zuerst hart und quadratisch zuschneiden: das Symbol oder das Monogramm nehmen, zentrieren, einen kleinen Rand lassen. Ein nicht quadratischer Master wird nicht abgelehnt — er wird mittig auf das Quadrat gesetzt, mit Transparenz an den Seiten —, aber dann verteilt sich das Motiv nur über einen Teil eines ohnehin winzigen Icons. Das ist eine Design-Entscheidung, die keine Umwandlung abnehmen kann.

JPEG XL kann bis zu 32 Bit je Kanal und weiten Farbraum halten. Das PNG innerhalb einer ICO-Datei hat acht Bit je Kanal, und die Browser, die es zeichnen, wenden in der Praxis kein Farbmanagement darauf an.

Diese Reduktion fällt normalerweise nicht auf und gelegentlich doch. Eine in weitem Farbraum definierte Markenfarbe — ein gesättigtes Orange oder Grün außerhalb von sRGB — verschiebt sich beim Schreiben in ein Icon leicht, und je nach Betriebssystem noch einmal anders. Ist die Markenfarbe vertraglich festgelegt, lohnt sich ein Abgleich des fertigen Icons gegen die Spezifikation statt der Annahme, sie sei unverändert übernommen worden.

Ein ICO wurde dafür entworfen, mehrere Bilder zu tragen — 16 Pixel für eine Liste, 32 für den Desktop, 256 für eine Vorschau —, damit das System die passende wählt, statt zu skalieren. Die Größenauswahl auf dieser Seite entscheidet, welche das sind. Die Voreinstellung schreibt die klassischen drei Favicon-Größen, „Alle gängigen Größen" schreibt sechs — das Set, das eine Windows-Ressource für eine Anwendung erwartet.

Was diese Einstellung nicht leisten kann, ist Neuzeichnen. Jede Größe ist der Master, gefiltert auf diese Größe reduziert — die 16-Pixel-Version ist also eine kleine Fassung derselben Zeichnung, keine vereinfachte mit auf das Pixelraster geschnittenen Linien. Für ein Favicon reicht das. Für eine Anwendung mit feinem Detail bleibt als letzter Schritt, die 16-Pixel-Version von Hand zu vereinfachen und in einem Icon-Editor auszutauschen.

Favicons sind der Fall, dem die meisten begegnen, aber ICO ist älter als das Web und wird bis heute von Windows für Verknüpfungen, Programmressourcen, Installationsprogramme und Dateityp-Zuordnungen verlangt. Ein plattformübergreifender Anwendungs-Build fragt üblicherweise nach einem ICO, einem ICNS und einem Satz PNGs — diese Seite deckt das Erste ab.

Das ist der Grund, weshalb sich die Anforderungen unterscheiden: Ein Favicon braucht die kleinen Größen, ein Anwendungs-Icon wird üblicherweise als Satz bis 256 spezifiziert, oft mit von Hand nachbearbeiteten kleinen Größen. Beides kommt aus dieser Seite, nur mit unterschiedlicher Einstellung — geht es in ein Build-Skript statt auf einen Webserver, lohnt sich vorher ein Blick, was dort erwartet wird.

Jedes Bild innerhalb der ICO-Datei ist ein PNG, und PNG ist verlustfrei — ein Regler würde sich bewegen und nichts verändern, deshalb steht hier keiner, obwohl er auf jedem verlustbehafteten Rasterziel dieser Seite zu finden ist. Die Größenauswahl ist die Einstellung, die tatsächlich entscheidet, was am Ende in der Datei landet.

Das lässt sich auch als Ehrlichkeit lesen statt als fehlende Funktion: Wo nichts zu verhandeln ist, wird auch nichts zum Verhandeln angeboten. Zwei Umwandlungen desselben JPEG-XL-Masters mit derselben Größenauswahl ergeben identische Icons.

Beide Hälften dieser Umwandlung laufen lokal: der JPEG-XL-Decoder als WebAssembly-Modul in der Seite, der Icon-Behälter als JavaScript daneben. Keine Anfrage trägt die Datei fort, es gibt kein Konto, und nichts wird gespeichert.

Für dieses Paar ist das mehr als ein Prinzip. Ein Master ist die Version mit den flachgelegten Ebenen, aber ohne sonstigen Verzicht — volle Auflösung, unangetastete Farbe, mitunter noch mit Metadaten —, und genau das ist die letzte Datei, die man für ein 4-KB-Icon einem fremden Konverter geben sollte.