GIF in BMP umwandeln

Diese beiden Formate liegen nur drei Jahre auseinander — 1987 und 1990 — und lösen dasselbe Problem in entgegengesetzter Richtung. Ein GIF speichert für jedes Pixel einen Index in eine Palette mit höchstens 256 Einträgen, also ein Byte, bevor die LZW-Kompression noch einmal komprimiert. Das hier geschriebene Bitmap speichert für jedes Pixel ein vollständiges Blau-Grün-Rot-Tripel, unkomprimiert.

Das Wachstum entsteht also aus zwei Faktoren gleichzeitig: drei Byte statt einem, und keine der LZW-Ersparnisse, die das GIF überhaupt klein gemacht haben. Eine 40-KB-GIF-Datei wird routinemäßig eine zehnmal so große Bitmap-Datei, und auf flächigem Design mit langen Läufen identischer Farbe — genau dem Material, das GIF am besten komprimiert — fällt das Verhältnis noch ungünstiger aus.

Die Rechnung ist kurz und ohne Schätzung. Breite mal drei ergibt die Byte in einer Zeile, das Ergebnis auf das nächste Vielfache von vier aufrunden, mit der Höhe multiplizieren, 54 Byte Header addieren. Ein 480 mal 270 Pixel großes GIF ergibt 1.440 Byte pro Zeile ohne Rundung, 388.800 Byte an Pixeln und insgesamt 388.854 Byte.

An der Quelle ändert sich an dieser Zahl nichts. Dasselbe 480-mal-270-Bitmap entsteht aus einem stark gedithertem Foto genauso wie aus einem einfarbigen roten Rechteck, weil das Format jedes Pixel in beiden Fällen wörtlich speichert. Genau diese Vorhersagbarkeit ist der Grund, warum Hardware Bitmaps verlangt: Firmware, die eines liest, kann ihren Puffer allein aus dem Header dimensionieren.

Zwei Eigenheiten dieses Bitmaps sehen wie Fehler aus und sind keine. Die Zeilen sind von unten nach oben gespeichert, und die Kanäle innerhalb jedes Pixels sind in der Reihenfolge Blau, Grün, Rot statt umgekehrt angeordnet. Beides steht in der ursprünglichen Spezifikation und ist genau das, was ein BMP-Leser erwartet.

Die dritte Eigenheit ist die Auffüllung: Jede Zeile wird auf ein Vielfaches von vier Byte aufgefüllt, sodass ein 101 Pixel breites Bild 303 Byte Pixeldaten gefolgt von einem Byte Nichts schreibt, also 304 Byte pro Zeile. Code, der eine Bitmap-Zeile schlicht mit Breite mal drei berechnet, erzeugt ein Bild, das diagonal verschert — der häufigste Fehler in einem selbstgeschriebenen BMP-Leser.

BMP kennt genau ein Bild. Es hat kein Konzept für eine Sequenz, eine Verzögerung oder eine Schleife, sodass ein animiertes GIF hier zu dem Einzelbild wird, mit dem es beginnt — der Rest wird verworfen, und die Registry nennt das ausdrücklich als Hinweis statt es dem Zufall zu überlassen.

Für die Ziele, die BMP-Dateien verlangen, ist das selten ein Problem, weil ein Gerät, das nach einem BMP fragt, per Definition ein Standbild will. Es lohnt sich trotzdem zu prüfen, ob das erste Bild tatsächlich das gewünschte ist: Manche GIFs beginnen mit einem leeren Bild oder einer Titelkarte, bevor der eigentliche Inhalt startet.

Es wäre naheliegend zu erwarten, dass ein Bild mit nur 256 verschiedenen Farben eine kleine Datei ergibt, und bei einem palettenbasierten Format wäre das auch so. Die BMP-Spezifikation erlaubt genau das — ein 8-Bit-BMP mit Farbtabelle, das fast perfekt zu einem GIF passen würde.

Dieser Konverter schreibt so eines nicht. Jedes hier erzeugte Bitmap ist 24-Bit, sodass ein GIF mit sechs Farben genauso viele Byte kostet wie ein Foto derselben Abmessungen. Verlangt das Zielgerät ausdrücklich ein 8-Bit-paletten-BMP statt bloß ein BMP zu akzeptieren, erfüllt diese Datei das nicht — das lässt sich vorab klären, statt es an der Ablehnung des Geräts zu bemerken.

Ein GIF kann einen Paletteneintrag als transparent kennzeichnen. Das hier geschriebene Bitmap hat überhaupt keinen Alphakanal — 24 Bit, drei Kanäle, kein Platz übrig —, also müssen diese Pixel vor dem Kodieren einen tatsächlichen Farbwert bekommen.

Die Hintergrundfarbe-Option bestimmt diesen Wert und ist standardmäßig Weiß. Bei Hardware zahlt sich eine bewusste Wahl aus: Ein Symbol für ein Display mit dunkler Oberfläche gehört auf Schwarz geflächt, nicht auf Weiß mit einer nachträglichen Invertierung. Erwartet ein System einen bestimmten Chroma-Key, sollte die Option genau auf diese Farbe gesetzt werden, statt darauf zu vertrauen, dass ein späterer Schritt sie findet.

Diese Umwandlung hat keinen Qualitätsregler und könnte auch keinen haben: Unkomprimiert bedeutet unkomprimiert, es gibt nichts zum Abwägen. Der einzige Hebel ist die maximale Breite, die das Bild vor dem Schreiben der Pixel verkleinert und die Dateigröße dadurch quadratisch verändert.

Die Breite zu halbieren viertelt das Bitmap. Das ist meist die richtige Wahl, wenn das Ziel ohnehin ein kleines Display ist — ein 128 Pixel breites Panel gewinnt nichts von einer 640 Pixel breiten Quelle, und eine Skalierung hier statt in der Firmware bedeutet, dass das Gerät den größeren Puffer erst gar nicht vorhalten muss.

Jede Rasterumwandlung hier entfernt Metadaten unbedingt auf dem Weg, und auf diesem Paar hat diese Regel wenig zu tun. Ein GIF hat keinen EXIF-Block, kein Kameramodell, keine GPS-Koordinaten; das Meiste, was es üblicherweise trägt, ist eine Kommentar-Erweiterung und eine Anwendungs-Erweiterung des schreibenden Programms.

Für all das gibt es im Bitmap-Format ohnehin keinen Platz. Sein Header beschreibt Abmessungen, Bittiefe und wenig mehr, also kommen Pixel und Geometrie an, sonst nichts. Stammt das GIF aus einem Bildschirmrekorder, der seinen Namen in einen Kommentarblock geschrieben hat, reist dieser Name nicht mit.

Das GIF wird von der eingebauten Bildunterstützung des Browsers dekodiert, und Header und Pixelzeilen des Bitmaps werden in JavaScript im selben Tab geschrieben. Es gibt keinen Server im Ablauf, keinen Upload und kein Konto, und die Datei ist verschwunden, sobald der Tab geschlossen wird.

Das zählt bei diesem Paar mehr, als es klingt, weil das, was Menschen zu BMP konvertieren, oft internes Material ist: eine Grafik für ein Bedienfeld, ein Produktetikett, der Startbildschirm eines Messgeräts. Nichts davon muss durch fremde Infrastruktur laufen, um Bitmap zu werden.