ICO in BMP umwandeln

In der deutschen Maschinenbau- und Automatisierungstechnik laufen viele Bedienoberflächen auf Panels von Siemens, Beckhoff oder vergleichbaren Herstellern, deren Firmware Bilder als rohe Pixelzeilen einliest statt als komprimiertes Format. Ein Symbol, das in einer SPS-Visualisierung oder einem HMI-Projekt auftauchen soll, kommt oft zuerst als ICO aus einem Icon-Editor — und muss dann in genau die Form, die das Panel versteht: ein unkomprimiertes Bitmap.

Dieselbe Anforderung taucht bei älteren Windows-Steuerelementen, bei Installer-Ressourcen und bei Testaufbauten auf, die Bilder Byte für Byte vergleichen. Gemeinsam ist all diesen Zielen, dass Vorhersagbarkeit mehr zählt als Dateigröße — und genau das liefert diese Umwandlung.

Beide Formate stammen von Microsoft und wurden zusammen entworfen. Das ursprüngliche Icon-Format wickelte gar kein eigenständiges Bild ein: Jeder Eintrag enthielt einen Bitmap-Header, gefolgt von Farbdaten und einer Ein-Bit-Maske, die sagte, welche Pixel unverändert bleiben. Ein ICO war im Grunde ein Bitmap mit Schablone, in einem Verzeichnis abgelegt.

Seitdem haben sich beide auseinanderentwickelt. Icons bekamen mit Windows XP einen echten Acht-Bit-Alphakanal und mit Vista die Möglichkeit, eine PNG-Nutzlast zu tragen, was moderne Icon-Dateien für ihre großen Einträge auch nutzen. Das hier geschriebene Bitmap ist die 24-Bit-Baseline, die keines von beidem je erhalten hat. Ein ICO in ein BMP zu wandeln ist also ein Schritt zurück in der Fähigkeit — und zwar deshalb, weil etwas am anderen Ende genau das verlangt.

Der Encoder schreibt 24 Bit pro Pixel: acht für Blau, acht für Grün, acht für Rot, sonst nichts. Es gibt eine BMP-Headervariante mit definiertem Alphakanal, und Dateien in dieser Variante existieren — nur liest so gut wie nichts sie zuverlässig, und genau dieses Zuverlässigkeitsproblem soll BMP eigentlich vermeiden.

Die Transparenz muss also irgendwohin, bevor der Encoder läuft, und die Hintergrundfarbe entscheidet, wohin. Standard ist Weiß. Sinnvoll ist die Farbe der Fläche, auf der das Bitmap später liegt — die Panel-Hintergrundfarbe einer Visualisierung, der Farbton eines Installer-Banners. An einer Testdatei mit transparenten Ecken las das Ergebnis 255,255,255 in der Ecke — korrekt, und zugleich die falsche Antwort, wenn das Panel dunkelgrau ist.

Das ist kein Mangel, sondern der ganze Sinn von BMP. Jedes Pixel belegt drei Byte, unabhängig davon, was es zeigt, die Dateigröße ist also Arithmetik statt Ergebnis: Breite mal drei, auf ein Vielfaches von vier aufgerundet, mal Höhe, plus 54 Byte Header.

Bei einem 256-Pixel-Quadrat sind das 768 Byte pro Zeile und 196.608 Byte an Pixeln, insgesamt 196.662. Gemessen an der 8.471 Byte großen Testdatei, aus der es stammt, ist das Bitmap mehr als dreiundzwanzigmal so groß. Hat die Zielsoftware eine Größenbeschränkung, lohnt sich diese Multiplikation vor der Umwandlung, nicht danach.

Die größte in der Datei. Das Dekodieren übernimmt der Icon-Leser des Browsers, und der liefert den größten Eintrag im Verzeichnis — geprüft mit einer Datei, die 16-, 32-, 48- und 256-Pixel-Zeichnungen in vier verschiedenen Farben enthielt und deren Verzeichnis in drei unterschiedlichen Reihenfolgen geschrieben wurde. Die 256-Pixel-Zeichnung kam jedes Mal heraus.

Die kleineren Einträge werden nirgends geschrieben, und keine Einstellung erreicht sie. Braucht die Zielsoftware ein 32-Pixel-Bitmap und enthält das Icon einen 32-Pixel-Eintrag, exportiert ein Icon-Editor wie GIMP diese Ebene direkt — mit einem besseren Ergebnis, als die 256-Pixel-Version herunterzuskalieren.

Zwei Details, die wichtig sind, wenn die Bytes statt der Bilddatei gelesen werden. BMP speichert seine Zeilen von unten nach oben und jedes Pixel als Blau, dann Grün, dann Rot. Beides steht in der Spezifikation, und beides überrascht beim ersten eigenen Parser-Versuch regelmäßig.

Jede Zeile wird zusätzlich auf ein Vielfaches von vier Byte aufgefüllt, was bei ungeraden Breiten auffällt: Eine 33 Pixel breite Zeile hat 99 Byte Farbdaten und ein Byte Auffüllung, gespeichert werden also 100. Bei 256 Pixeln sind es 768 Byte ohne Auffüllung — ein Grund, warum Bitmaps in Icon-Größe sich von Hand leicht nachvollziehen lassen.

Weil das Lesen keinen Decoder braucht. Ein Mikrocontroller, der ein kleines Display ansteuert, kann Bytes aus einer Datei mit einer Schleife und einem Header-Offset direkt in einen Framebuffer kopieren; ein PNG-Decoder in derselben Firmware bedeutet zusätzlich einen Entpacker, eine Speicherverwaltung und einen Chunk-Parser auf einem Gerät, das vielleicht 32 KB RAM hat.

Dieselbe Überlegung gilt für Installer-Ressourcen, für ältere Windows-Steuerelemente, die über plattformeigene Bitmap-Funktionen laden, und für Testaufbauten, die Bilder Byte für Byte vergleichen wollen, ohne dass ein Codec im Weg steht. Überall dort ist Vorhersagbarkeit deutlich mehr wert als Dateigröße.

Beide Formate sind verlustfrei, dieser Weg hat also keine Qualitätseinstellung, weil es nichts zu verhandeln gibt. Jedes Pixel, das die Einfärbung übersteht, ist Bit für Bit das, was das Icon gespeichert hatte — dieselbe Datei ein zweites Mal umzuwandeln liefert ein identisches Ergebnis, ohne dass sich ein weiterer Verlust ansammelt.

Die zwei Dinge, die tatsächlich verlorengehen, sind der Alphakanal, ersetzt durch die Hintergrundfarbe, und die übrigen Einträge im Behälter. Beides lässt sich aus dem Bitmap danach nicht mehr zurückgewinnen — ein Argument, die ursprüngliche Icon-Datei aufzuheben, statt sie zu ersetzen.

Ist das Ziel moderne Software mit einer Vorliebe statt einer harten Vorgabe, ist ein PNG um zwei Größenordnungen kleiner und behält die Transparenz. Dieselbe Testdatei war als PNG 1.737 Byte gegenüber 196.662 Byte als Bitmap — ein Unterschied, der eine Rückfrage wert ist, ob BMP wirklich zwingend nötig ist.

Fällt die Antwort auf Firmware, ein Installer-Skript oder einen Byte-Vergleich, ist das Bitmap richtig, und die Größe ist der Preis dafür, ohne Decoder lesbar zu sein. Das lohnt sich im Commit oder im Projektordner zu vermerken, denn eine 200-KB-Datei für ein kleines Symbol sieht für die nächste Person, die darüber stolpert, wie ein Versehen aus.

Den ganzen Bestand ablegen. Jede Datei wird dekodiert, auf dieselbe Hintergrundfarbe eingefärbt und einzeln geschrieben, das Gesamtergebnis kommt als ein ZIP zurück. Eine gemeinsame Hintergrundfarbe über den ganzen Stapel ist meist genau das, was diese Ziele brauchen, weil die Bilder auf dieselbe Fläche gesetzt werden.

Die Abmessungen im Ergebnis lieber prüfen als annehmen. Über Jahre gewachsene Icon-Sätze mischen Einträge mit 256 Pixeln und solche, die bei 32 aufhören, und die Bitmaps übernehmen diese Streuung — mit einem Faktor 64 zwischen den Dateigrößen an den beiden Enden.