SVG in BMP umwandeln

Deutsche Maschinenbaubetriebe stoßen auf diese Umwandlung besonders oft: Ein HMI-Panel an einer Fertigungsanlage, eine Steuerungssoftware für eine SPS oder ein Installationsprogramm für ein Industriegerät verlangt eine Bilddatei für den Startbildschirm oder das Logo in der Ecke — und die verfügbare Import-Funktion kennt genau ein Format: unkomprimiertes BMP.

Das ist kein Zeichen veralteter Technik, sondern eine bewusste Entscheidung solcher Systeme: Ein Bedienpanel mit begrenztem Speicher und ohne eigenes Betriebssystem kann eine Bitmap Byte für Byte in seinen Bildspeicher kopieren, ohne einen Decoder mitzubringen. Ein PNG würde dafür einen Entpacker, eine Speicherverwaltung und einen Chunk-Parser voraussetzen — Aufwand, den viele solcher Geräte gar nicht leisten.

Diese beiden Formate stehen an gegensätzlichen Enden. Ein SVG ist Text: eine Liste aus Pfaden, Füllungen und Transformationen, die ein Renderer in ein Bild bei jeder gewünschten Größe verwandelt — die Datei hat also keine Auflösung und keinen festen Byte-Preis. Ein BMP ist das fertig gerenderte Bild, gespeichert als reine Farbzeilen, ohne Kompression und ohne Struktur.

Genau diese Lücke ist das Thema dieser Seite. Der eine Weg ist ein Rendern — eine einmalige, dauerhafte Entscheidung über Größe, Hintergrund und Kantenglättung. Der andere Weg existiert nicht: Von einem Raster aus Bytes führt kein Pfad zurück zu den Formen, die es gezeichnet haben.

Eine width- und height-Angabe in einem SVG ist ein Vorschlag, keine feste Größe — die Zeichnung wird durch ihre viewBox definiert und lässt sich in jeder Auflösung erzeugen. Die Umwandlung muss also eine wählen, und die Skalierung ist diese Entscheidung. Voreingestellt sind 1.024 Pixel Breite, die Höhe folgt den Proportionen der Zeichnung; der Wertebereich reicht von 0,1 bis 10, also 102 bis 10.240 Pixel.

Es lohnt sich, die Zahl zu wählen, die die Zielanwendung tatsächlich verlangt, statt die größte anzubieten, denn der Preis ist hier ungewöhnlich hoch: Anders als bei PNG oder WebP hängt die Größe eines Bitmaps nicht vom Bildinhalt ab. Eine Verdopplung der Breite vervierfacht die Datei, egal ob die Zeichnung eine ganze Illustration oder eine einzelne schwarze Linie ist.

Jeder Pixel braucht drei Byte — Blau, Grün, Rot, in dieser Reihenfolge —, und jede Zeile wird auf ein Vielfaches von vier aufgefüllt. Dazu ein 54 Byte großer Header, das ist die ganze Datei. Ein 1.024-Pixel-Quadrat ergibt 3.072 Byte je Zeile und 3.145.728 Byte Bilddaten, insgesamt also 3.145.782 Byte.

Ein SVG von wenigen hundert Byte wird so bei der Voreinstellung zu rund drei Megabyte, bei Skalierung 2 zu rund zwölf. Das ist kein Mangel dieser Umwandlung, sondern was BMP ist — und der Grund, warum alles, was eine Wahl hat, ein anderes Format nimmt. Hat die Zielanwendung eine Größenbegrenzung, lohnt sich die Rechnung vor der Umwandlung, nicht danach.

Das hier geschriebene Bitmap hat 24 Bit pro Pixel und keinen vierten Kanal. Es gibt eine Header-Variante, die Alpha definiert, aber sie zu unterstützen ist genau die Art von Aufwand, die BMP normalerweise vermeiden soll — also muss die Transparenz vorher aufgelöst werden.

Die Zeichnung wird auf nichts gerendert und dann in einem einzigen Durchgang mit der Hintergrundfarbe hinterlegt, was wichtig ist: Zuerst füllen und danach skalieren würde die Füllung in die Kanten verlaufen lassen, und zuerst skalieren und danach flach machen hinterlässt einen Saum halbtransparenter Pixel, den die Füllung dann verdunkelt. Die Farbe auf den Untergrund einstellen, auf dem das Bitmap tatsächlich sitzt — Weiß ist voreingestellt und auf einem dunklen Panel falsch.

Gerendert wird von resvg, kompiliert zu WebAssembly, statt vom eigenen SVG-Renderer des Browsers, und das ist Absicht. Ein SVG an ein Canvas zu übergeben liefert, was der jeweilige Browser gerade tut: andere Textmaße, andere Filterunterstützung, sichtbar unterschiedliche Ergebnisse in Chrome und Safari für dieselbe Datei. Ein Renderer bedeutet, dass das Bitmap auf jedem Rechner, der es erzeugt, identisch ausfällt.

Das zählt hier mehr als anderswo. Ein Bitmap, das auf ein Gerät geht oder in einen Installer eingebettet wird, wird meist einmal geprüft und dann für immer vertraut, manchmal sogar Byte für Byte mit einer Referenz verglichen. Ein Rendering, das je nach Browser variiert, würde diesen Vergleich bedeutungslos machen.

SVG speichert Text als Text und verweist auf eine Schrift über ihren Namen. Ist sie nicht eingebettet, wählt der Renderer eine andere, und ein sorgfältig gesetzter Schriftzug kommt mit anderen Buchstabenformen und anderem Abstand zurück. Das ist der häufigste Grund, warum ein gerendertes SVG falsch aussieht.

Die dauerhafte Lösung gehört ins Zeichenprogramm: Text vor dem Export in Pfade umwandeln, dann werden die Buchstaben zu Formen, die nichts austauschen kann. Das macht die Datei nebenbei sicher für jedes System, das sie entgegennimmt, unabhängig davon, welche Schriften dort installiert sind.

Weil das Lesen keine Bibliothek braucht. Ein Mikrocontroller, der ein kleines Display ansteuert, kann den 54-Byte-Header überspringen und Bytes in einer Schleife direkt in einen Bildspeicher kopieren; PNG auf demselben Gerät zu unterstützen bedeutet, einen Entpacker, eine Speicherverwaltung und einen Chunk-Parser auf etwas zu bringen, das mitunter nur 32 KB RAM hat.

Dieselbe Logik gilt für Installer-Ressourcen, die über die eigenen Bitmap-Funktionen der Plattform geladen werden, ältere Windows-Steuerelemente und Testaufbauten, die Bilder ohne Codec vergleichen. In jedem Fall wird das Format wegen seiner Vorhersehbarkeit gewählt, und die Megabyte sind der Preis dafür.

Neben Industriepanels ist die zweite häufige Quelle für diese Umwandlung ein Installer: Windows-Installationsprogramme, die über die klassische Bitmap-Ressource ein Banner oder ein Logo im Setup-Assistenten zeigen, akzeptieren dort seit jeher nur BMP, weil die zugrunde liegende Windows-API genau dieses Format lädt und keinen zusätzlichen Decoder mitbringt.

Dasselbe gilt für einzelne ältere Steuerelemente in Desktop-Anwendungen, die ein Symbol über eine Bitmap-Ressource statt über eine moderne Bildbibliothek einbinden. Auch hier ist die Marke fast immer als SVG verfügbar, und der Weg dorthin ist derselbe: rendern, auf den passenden Hintergrund legen, in der von der Ressource verlangten Größe speichern.

Das Bitmap löschen und ein neues lässt sich jederzeit erzeugen. Das SVG löschen, und das Bitmap ist alles, was übrig bleibt — Bearbeitbarkeit, beliebige Auflösung und eine textdiffbare Historie in der Versionsverwaltung sind dann für immer weg. Ein Bitmap zurück in Pfade nachzuzeichnen rät nur, wo die Kanten waren, und ergibt eine andere Datei mit mehr Knoten und schlechteren Kurven.

Die Umwandlung als Export-Schritt behandeln, idealerweise einen, den der eigene Build automatisch ausführt, statt einen, den jemand von Hand macht. Braucht das Panel im nächsten Jahr eine andere Größe, aus dem Vektor neu rendern, statt ein Drei-Megabyte-Bitmap zu skalieren.

Den ganzen Ordner ablegen. Jede Datei wird mit derselben Skalierung gerendert und auf denselben Hintergrund gelegt — meist genau das, was diese Zielsysteme brauchen, denn ein Satz Panel-Grafiken, die sich beim Hintergrund uneinig sind, wirkt schlechter, als jede einzelne unperfekt zu haben.

Auf die Gesamtgröße achten: Zwanzig Zeichnungen bei Standardskalierung sind vor dem ZIP rund sechzig Megabyte Bitmap-Daten — genug, um auf einem Telefon spürbar zu bremsen und den Speicher eines kleinen Geräts zu füllen. Die Skalierung auf das zu reduzieren, was das Display tatsächlich zeigt, ist der wirksamste einzelne Schritt gegen diese Zahl.