ICO in PNG umwandeln

Wer für ein Wiki, eine interne Confluence-Seite oder eine README-Datei ein Firmenlogo braucht und feststellt, dass irgendwo im Projekt nur noch eine favicon.ico existiert, steht vor genau diesem Problem. Die Originalvorlage ist verschollen, aber das Icon liegt seit Jahren im Projektordner oder auf einem alten Server.

Dieselbe Situation trifft Entwickler, die bei einer Konkurrenzanalyse ein Favicon von einer fremden Website heruntergeladen haben und es als gewöhnliches Bild in der Dokumentation ablegen wollen. In beiden Fällen geht es nicht darum, ein Icon zu bauen, sondern eins wieder zu einem normalen Bild zu machen.

Das sagen die wenigsten Konverter deutlich: Ein ICO ist kein Bild, sondern ein kleines Verzeichnis mit mehreren Bildern darin, jedes in einer anderen Größe, damit Windows in einer vollen Taskleiste eine scharfe 16-Pixel-Version zeigen kann und auf dem Desktop eine scharfe 256-Pixel-Version, ohne eine der beiden zu skalieren. Ein gut gepflegtes Anwendungssymbol trägt oft vier bis sechs solcher Einträge.

Ein PNG hat Platz für genau ein Bild und kein Verzeichnis. Die Umwandlung ist also keine reine Umkodierung, sondern eine Auswahl gefolgt von einer Umkodierung — und alles Weitere auf dieser Seite folgt aus der Frage, welcher Eintrag gewählt wird.

Dekodiert wird durch den Browser selbst, nicht durch eine mit dieser Seite mitgelieferte Bibliothek, und jeder Browser-Icon-Decoder liefert das größte Bild im Verzeichnis zurück, unabhängig von der Reihenfolge der Einträge.

Die praktische Folge: Auswählen lässt sich nichts. Enthält die Datei ein 256-Pixel-Bild, ist das die eine Zeichnung, die ankommt; die 16-, 32- und 48-Pixel-Zeichnungen werden ohne Meldung übergangen — und das sind häufig gerade jene, in die am meisten Handarbeit floss.

Ein Icon-Eintrag speichert Breite und Höhe in je einem einzigen Byte, das bei 255 endet, wobei der Wert 0 für 256 steht. Das ist die ganze Obergrenze: Keine Icon-Datei der Welt enthält ein Bild breiter als 256 Pixel, folglich kann auch kein daraus erzeugtes PNG größer ausfallen.

Das ist wichtig, wenn jemand nach einem Logo gefragt hat. Eine Icon-Datei ist kein Quellmaterial, und ein 256-Pixel-PNG auf einer Folie in voller Breite platziert oder in irgendeiner Größe gedruckt wirkt weich. Soll das PNG für mehr als ein Vorschaubild dienen, lohnt sich die Suche nach der ursprünglichen Vorlage — die Icon-Datei wurde daraus erzeugt, nicht umgekehrt.

Beide Formate tragen einen vollwertigen Achtbit-Alphakanal, ein rundes Icon, ein Ausschnitt-Symbol oder ein weicher Schlagschatten kommen im PNG also genau so an, wie sie gezeichnet wurden. Es gibt keine Hintergrundfarbe zu wählen und keinen weißen Rahmen nachträglich zurechtzuschneiden.

Das ist der Grund, warum PNG hierfür das richtige Ziel ist und JPG nicht. Soll das Icon irgendwo auf farbigem Grund liegen — ein dunkles Dokumentationsthema, eine Präsentationsfolie, ein Raster im App-Store —, ist der Alphakanal der ganze Sinn dieser Umwandlung.

Beide Enden sind verlustfrei. Das Icon wird zu rohen Pixeln dekodiert, und genau diese Werte werden ins PNG geschrieben, es gibt also keine Qualitätseinstellung, die falsch stehen könnte, und keinen Generationsverlust, würde dieselbe Datei zweimal umgewandelt. Verändert wird die Verpackung, nicht das Bild.

Das PNG durchläuft danach oxipng, das üblicherweise einen großen Teil dessen entfernt, was ein einfacher Encoder mitschreiben würde, ohne einen einzigen Pixel anzurühren — das Ergebnis wird dadurch häufig sogar kleiner als das ursprüngliche Icon, weil dieses mehrere Kopien derselben Zeichnung trug und das PNG nur eine.

Ist genau die kleine Zeichnung das Ziel, liefert diese Seite sie nicht, und kein über einen Browser-Decoder laufender Konverter kann das. Die kleinen Größen in einem sauber gemachten Icon sind keine verkleinerten Kopien, sondern eigenständig gezeichnet, mit auf ganze Pixel eingerasteten Linien und weggelassenem Detail, damit die Marke bei dieser Größe lesbar bleibt.

Das passende Werkzeug ist ein Icon-Editor. GIMP öffnet ein ICO und zeigt jeden Eintrag als eigene Ebene, exportierbar einzeln, ohne Kosten.

Von einer Website heruntergeladene Favicons sind oft deutlich kleiner, als die Obergrenze vermuten lässt. Eine vor Jahren angelegte Datei enthält häufig nur ein 16-Pixel-Bild, manchmal ein 16 und ein 32. Der 256-Pixel-Eintrag wurde erst üblich, als Browser und Betriebssysteme ihn für größere Kacheln zu nutzen begannen.

Ein solches Icon liefert dann eben ein 16-Pixel-PNG, korrekt und für fast alles außer einem Favicon unbrauchbar. Das ist kein Fehler der Umwandlung — die Zeichnung in größerer Auflösung wurde nie gespeichert. Wer eine größere Version braucht, muss anderswo suchen.

Moderne Favicon-Auszeichnung akzeptiert PNG direkt, und die meisten Websites deklarieren heute ein 32-Pixel-PNG, ein 180-Pixel apple-touch-icon und daneben ein SVG. Ging es beim Umwandeln um eine solche Modernisierung, ist das hier erzeugte PNG die richtige Ausgangsdatei, sofern die Quelle einen ausreichend großen Eintrag enthielt.

Für ein natives App-Symbol verlangt die Plattform exakte Pixelmaße, und ein 256-Pixel-PNG kann ein 512- oder 1024-Pixel-Feld nicht ehrlich füllen. Wo eine Plattform das fordert, ist die Icon-Datei der falsche Ausgangspunkt — dort gehört das Vektorformat oder die Vorlage in voller Auflösung hin.

Beide Formate sind aus einem Icon erreichbar, aber sie beantworten unterschiedliche Fragen. JPG hat keinen Alphakanal und muss die transparenten Ecken mit einer Farbe füllen, PNG behält sie unverändert. Für ein Logo, das später auf unterschiedlichem Hintergrund liegen soll, ist damit eigentlich schon entschieden.

Der einzige Fall, in dem trotzdem JPG sinnvoller ist, ist ein Ziel, das ausdrücklich keine Transparenz verarbeiten kann oder eine feste Dateigröße verlangt, die PNG nicht zuverlässig einhält. Für ein Wiki, eine README-Datei oder eine Dokumentation ist das praktisch nie der Fall.

Den ganzen Bestand ablegen genügt. Jedes Icon wird einzeln dekodiert und geschrieben, die Ergebnisse kommen gemeinsam als ZIP zurück — der übliche Fall, wenn jemand ein Verzeichnis von Anwendungssymbolen erbt und jedes davon als Bild für eine Dokumentationsseite oder eine Bestandsliste braucht.

Weil die Arbeit im Browser läuft, gibt es keine Warteschlange und keinen Upload pro Datei, die zehnte wird genauso behandelt wie die erste. Dateien mit nur einem kleinen Eintrag liefern kleine PNGs — die Maße im ZIP lohnt sich zu prüfen, statt Einheitlichkeit vorauszusetzen, denn gemischte Icon-Sets sind fast nie einheitlich.

Der Browser dekodiert das Icon, dieselbe Seite kodiert das PNG, und keiner dieser Schritte schickt etwas an einen Server. Bei einem internen Wiki, das noch nicht öffentlich ist, oder bei Marken, deren Nutzung noch nicht final geklärt ist, ist das kein Nebeneffekt, sondern der eigentliche Grund für diese Seite.

Es gibt kein Konto, keine Aufbewahrungsfrist und keine Serverkopie, nach der später gefragt werden müsste — die Umwandlung ist mit dem Schließen des Tabs vollständig erledigt.