1987: Eine Ehe von kurzer Dauer

Die Geschichte von BMP beginnt in einem Joint-Venture, das Computer-Geschichte schreiben sollte — aber nicht so, wie geplant. 1985 hatten IBM und Microsoftein gemeinsames Betriebssystem angekündigt: OS/2, der designierte Nachfolger von DOS. Beide Unternehmen entwickelten parallel an Komponenten, Microsoft brachte Kompetenz aus DOS und Windows ein, IBM lieferte das Mainframe-Erbe und die Hardware- Marktposition.

Im Dezember 1987 erschien OS/2 1.0, kurz danach im April 1988 die Version mit grafischer Oberfläche (OS/2 1.1 mit Presentation Manager). Das Bildformat für interne Grafik-Ressourcen — Icons, Systembilder, Dialog-Hintergründe — war BMP, das Bitmap-Format. Es lehnte sich am internen DIB-Format an (Device Independent Bitmap), das Microsoft schon in Windows 2.x verwendet hatte.

Die technische Einfachheit als Designprinzip

BMPs Architektur war kompromisslos einfach. Eine BMP-Datei besteht aus einem 14-Byte-Datei-Header, einem 40-Byte-Info-Header, einer optionalen Farbpalette und einer unkomprimierten Pixel-Tabelle, in der jeder Pixel byteweise gespeichert wird — typischerweise als Bottom-up (die letzte Bildzeile zuerst, eine historische Reminiszenz an damalige Grafik-Hardware).

Diese Einfachheit war das Kerndesign-Prinzip: BMP-Decoder konnten in wenigen hundert Zeilen C-Code implementiert werden, was auf der knappen Speicher-Ressource von 286er-PCs (1 MB RAM) entscheidend war. Im Vergleich: eine JPEG-Implementierung brauchte 50 mal so viel Code und vor allem dezidierte DSP-Beschleunigung, die 1987 in der PC-Welt noch nicht existierte.

1990: Windows 3.0 macht BMP zum Standard

Die OS/2-Kooperation zwischen IBM und Microsoft endete 1991 — Microsoft hatte stillschweigend an einer DOS-basierten GUI-Lösung weiterentwickelt, die im Mai 1990 als Windows 3.0 erschien. Windows 3.0 war ein durchschlagender kommerzieller Erfolg; in den ersten zwei Jahren wurden 10 Millionen Lizenzen verkauft. OS/2 hingegen blieb eine Nische und wurde bis 2001 endgültig eingestellt.

BMP wanderte mit — Microsoft nahm das Format aus der OS/2-Kooperation in Windows mit. Jedes Windows-Programm konnte BMP nativ laden und speichern; Microsoft Paint (mitgeliefert seit Windows 3.0) speicherte standardmäßig als BMP. Das Format wurde synonym mit dem Windows-Ökosystem.

Die Versionen-Komplikation

Eine Eigenheit von BMP, die wenig Aufmerksamkeit bekommt: das Format hat über die Jahrzehnte hinweg mehrere inkompatible Header-Versionen bekommen. Die Standard-Spec unterstützt heute fünf verschiedene Info-Header-Strukturen, je nach Microsoft-Release:

  • BITMAPCOREHEADER (1987, OS/2 1.0) — 12 Bytes, primitive Auflösung.
  • BITMAPINFOHEADER (1990, Windows 3.0) — 40 Bytes, der bis heute häufigste Header.
  • BITMAPV4HEADER (1996, Windows 95) — 108 Bytes, mit Farb-Profil- Informationen für ICM-Workflows.
  • BITMAPV5HEADER (2000, Windows 2000) — 124 Bytes, mit ICC-Profil- Daten-Block.

Dekoder müssen alle Varianten erkennen, was die scheinbar einfache Format-Implementierung subtil komplex macht. Eine sauber implementierte BMP-Decoder-Bibliothek ist heute eher 1500–2000 Zeilen C-Code — immer noch wenig im Vergleich zu JPEG (siehe unsere JPEG-Geschichte), aber nicht mehr trivial.

Komprimierung — die Ausnahme

BMP ist im Standardfall unkomprimiert. Es gibt aber optional zwei Komprimierungs- Modi: RLE-8 (Run-Length Encoding für 8-Bit-Palette-Bilder) und RLE-4 (für 4-Bit-Palette-Bilder). Beide sind verlustfrei, beide erlauben moderate Datei-Verkleinerung bei Bildern mit großen einfarbigen Flächen (Diagramme, UI-Screenshots), aber praktisch nutzt sie kaum eine Software. Wer einen BMP-Encoder schreibt, lässt RLE in der Regel weg.

Ein Spezialfall: Windows-Vista führte 2007 PNG-eingebettete BMPs ein — eine BMP-Datei kann seither einen PNG-Datenstrom enthalten, der per Tag als alternative Codierung markiert ist. Das wurde primär für Icon-Dateien in größeren Auflösungen genutzt, um die enormen Größen unkomprimierter 256×256-Pixel-Icons zu vermeiden.

Die Größe als Show-Stopper

BMP's strukturelle Schwäche ist die Datei-Größe. Ein 1920×1080-Foto in 24-Bit-BMP ist unkomprimiert 6,2 MB. Das gleiche Foto als JPG bei Qualität 80 ist ungefähr 400 KB — eine 15-fache Reduktion. Als WebP nochmal 25 % kleiner.

Diese Ineffizienz hat BMP aus der Web-Welt verbannt. Web-Browser unterstützen das Format zwar (Chrome, Firefox, Safari, Edge können BMP rendern), aber keine ernsthafte Website liefert BMPs aus. In der professionellen Bildverarbeitung wurde BMP durch TIFF ersetzt (siehe TIFF-Geschichte), das bessere Metadaten und größere Dateien unterstützt.

Warum BMP nicht verschwindet

Trotz aller Mängel wird BMP nicht aus der Welt verschwinden. Drei strukturelle Gründe:

  • Windows-System-APIs. Die Win32-GDI-Schnittstelle nutzt DIB/BMP als native Bitmap-Repräsentation. Jedes Windows-Programm, das ein Bild im Speicher hält, arbeitet de facto mit BMP-Strukturen.
  • Einfache Decoder-Implementierung. Embedded-Systeme, Microcontroller, Frühphase-Bootloader implementieren oft BMP, weil ein JPG-Decoder zu groß ist. Wer ein Splash-Screen auf einem 8-Bit-Microcontroller anzeigen will, nutzt BMP.
  • Verlustfreie Speicherung ohne Library-Abhängigkeit. BMP braucht weder libpng noch libjpeg noch zlib — nur ein paar hundert Zeilen Code. Das macht das Format zur ehrlichen Wahl für Custom-Builds und Sicherheits-Audits.

BMP in modernen Workflows

Auch wenn BMP nicht mehr ausgeliefert wird, taucht es in zwei modernen Anwendungsfällen regelmäßig auf. Erstens als Screenshot-Zwischenformat: viele Tools nehmen den Bildschirm-Inhalt als BMP auf und konvertieren erst danach zu PNG oder JPG. Zweitens in Spielen und Demos: BMP ist das Format der Wahl für eingebettete Assets in Indie-Games, weil die Implementierung trivial ist und keine externen Bibliotheken benötigt.

Wer ein BMP für moderne Auslieferung vorliegen hat, sollte konvertieren. Unser PNG-Komprimierer nimmt BMP-Input entgegen und liefert optimiertes PNG zurück; für Web-Auslieferung empfiehlt sich anschließend eine Konversion zu WebP, siehe unseren Formate-Vergleich.

Wann BMP die richtige Wahl ist

  • Embedded-Systeme. Wenn ein JPG-Decoder zu groß ist und keine externe Library zur Verfügung steht.
  • Splash-Screens auf Bootloadern. Verlustfrei, simpel, ohne externe Abhängigkeiten.
  • Zwischenformat in Pipelines. Bei Tools, die mehrere Verarbeitungs- Schritte zwischen Dekomprimierung und Re-Komprimierung machen wollen.
  • Windows-System-Programmierung. Wenn du direkt mit Win32-GDI arbeitest, ist BMP das native Format.

Wann BMP nicht ideal ist: Web-Auslieferung (zu groß), E-Mail-Anhänge (Verschwendung von Bandbreite), Archivierung (TIFF ist besser dokumentiert), Mobile-Workflows (kein moderner Smartphone-Workflow nutzt BMP).

Quellen

Microsoft Learn — Bitmap Storage · BITMAPINFOHEADER-API-Dokumentation · FileFormat.Info — BMP File Format · Wikipedia — BMP File Format · Microsoft — Device-Independent Bitmaps · James D. Murray & William vanRyper, „Encyclopedia of Graphics File Formats", O'Reilly 1996.