BMP in WebP umwandeln

Wer eine Kommunal- oder Landesverwaltung digitalisiert, stößt regelmäßig auf dasselbe Bild: Ein Fachverfahren aus den frühen 2000er-Jahren, oft noch unter Windows XP oder Windows 7 im Einsatz, liefert seine Screenshots und Formularabbildungen als BMP, weil die eingebaute Druckbildschirm-Funktion des Systems nichts anderes kennt. Diese Dateien landen dann unverändert auf der öffentlichen Website — als Anleitung, als Formularvorschau, als Ausschnitt aus einer alten Verfahrensdokumentation.

Genau dort wird es zum Problem, sobald die Seite nach BITV 2.0 und EN 301 549 geprüft wird: Eine 1920 mal 1080 Pixel große Bitmap wiegt 6,2 MB, egal was sie zeigt, weil das Format grundsätzlich drei Bytes je Pixel schreibt und nichts davon komprimiert. Auf einer Seite, die ohnehin schon knapp an den Ladezeit-Vorgaben der Barrierefreiheitsprüfung liegt, ist ein solcher Screenshot allein oft der entscheidende Ausschlag.

Der Ladezeit-Unterschied ist kein Randthema der Umwandlung, sondern ihr eigentlicher Zweck. WebP setzt genau dort an, wo Bitmaps am meisten verschwenden: Bits werden nur dort investiert, wo tatsächlich Bilddetail vorhanden ist, nicht gleichmäßig über die ganze Fläche verteilt. Ein Screenshot mit großen einfarbigen Flächen — bei Formularmasken und Verwaltungssoftware eher die Regel als die Ausnahme — profitiert davon besonders stark.

Das betrifft auch die Messung selbst: Steht der Screenshot weit oben auf der Seite, ist er häufig genau das Element, an dem der Largest-Contentful-Paint-Wert gemessen wird. Eine Umwandlung, die aus 6,2 MB wenige hundert Kilobyte macht, entscheidet in solchen Fällen nicht über Kosmetik, sondern über einen bestandenen oder nicht bestandenen Prüfpunkt.

WebP kann verlustfrei arbeiten, das Format unterstützt beide Modi. Diese Umwandlung schreibt die verlustbehaftete Variante mit Qualität 82, weil das die richtige Voreinstellung für ein Bild ist, das auf einer öffentlichen Seite ausgeliefert wird — nicht für eine Archivkopie.

Das lohnt sich klarzustellen, denn ein Fachverfahren-Screenshot mit feinem Text kann bei einer aggressiveren Kompression durchaus unscharf werden. Für ein Foto ist Qualität 82 kaum sichtbar; für eine Bildschirmabbildung mit kleiner Schrift lohnt sich eine Prüfung des Ergebnisses am eigenen Bildschirm, bevor die Datei live geschaltet wird.

Manche 32-Bit-BMP-Dateien aus älteren Windows-Werkzeugen tragen einen Alphakanal — etwa ein Logo oder ein Bedienelement, das mit einem älteren Grafikprogramm exportiert wurde. WebP behält diesen Kanal, und zwar auch in seinem verlustbehafteten Modus, was ungewöhnlich ist und der Hauptgrund ist, WebP hier JPEG vorzuziehen.

Für die meisten 24-Bit-Screenshots ist das ohnehin kein Thema, weil sie keinen Alphakanal besitzen. Wo er aber vorhanden ist, bewahrt WebP ihn in 256 Abstufungen statt der einzigen Ein-oder-Aus-Transparenzfarbe, die ein GIF erlauben würde — ein weicher Rand bleibt also tatsächlich weich, egal welche Hintergrundfarbe die Seite später bekommt.

Diese Grenze steht im Format selbst, nicht in diesem Konverter, und ist der einzige Fall, in dem die Umwandlung nicht bloß kleiner, sondern unmöglich wird: Keine Seite eines WebP-Bildes darf 16.383 Pixel überschreiten.

Gewöhnliche Screenshots kommen dem nicht nahe. Erreicht wird die Grenze eher bei eingescannten Formularen in hoher Auflösung oder bei zusammengesetzten Übersichtsdarstellungen aus alten Fachverfahren. Wer solche Dateien im Bestand hat, sollte die Breite vorher verkleinern oder auf PNG ausweichen, dessen eigene Obergrenze mit über zwei Milliarden Pixeln je Seite praktisch keine Rolle spielt.

WebP stammt aus dem Jahr 2010 und wurde jahrelang mit dem Hinweis auf mangelnde Unterstützung gemieden. Das ist vorbei: Das Format ist in jedem aktuellen Browser verankert, in RFC 9649 spezifiziert, und wird von gängigen Content-Management-Systemen ohne Zusatzmodul verarbeitet.

Für eine öffentliche Behördenseite mit hohen Anforderungen an Zugänglichkeit bleibt damit nur noch eine wirkliche Frage übrig — ob die verlustbehaftete Kompression für dieses konkrete Bild vertretbar ist. Für einen Formular-Screenshot ist die Antwort fast immer ja, solange die Textschärfe im Ergebnis geprüft wird.

Der häufigste Fehler bei diesem Format-Paar: Ein Screenshot wird in seiner vollen Bildschirmauflösung umgewandelt und dann in eine 600 Pixel breite Textspalte eingebettet. Der Browser lädt dann ein Vielfaches der tatsächlich sichtbaren Datenmenge und skaliert den Rest weg — daran ändert keine Kompressionseinstellung etwas.

Die maximale Breite sollte auf die tatsächliche Darstellungsgröße gesetzt werden, verdoppelt, falls das Bild auf einem hochauflösenden Bildschirm scharf bleiben soll. Die Skalierung läuft im selben Arbeitsschritt wie die restliche Umwandlung, wodurch das Bild nur einmal statt zweimal verkleinert wird.

Ein großer Teil der BMP-Dateien aus Verwaltungssoftware sind Bildschirmabbildungen mit feinem Text, und verlustbehaftete Kodierer behandeln Text schlecht — scharfe Buchstabenkanten sind genau das hochfrequente Detail, das sie zuerst opfern. Gegen JPEG spricht das deutlich, gegen WebP etwas schwächer, weil WebP scharfe Kanten bei gleicher Einstellung besser hält, aber nicht kostenlos.

Für einen Screenshot, der lesbar bleiben muss, ist die ehrliche Reihenfolge: PNG zuerst, WebP mit angehobener Qualität danach, JPEG deutlich abgeschlagen. PNG ist bei flächigen Formularmasken mit harten Kanten oft sogar die kleinere Datei, weil verlustfreie Kompression genau darin stark ist.

Für BMP sind in der Registry keine Metadaten-Container vorgesehen: kein EXIF, kein XMP, kein eingebettetes ICC-Profil. WebP könnte alle drei tragen, aber in der Quelldatei ist nichts vorhanden, das hineingeschrieben werden könnte.

Für einen Screenshot ist das unproblematisch — die Datei ist so klein wie die Pixel erlauben und trägt keine Herkunftsangabe. Bei einer aus einem farbverwalteten Arbeitsablauf stammenden Bitmap, die in einem bestimmten Farbraum interpretiert werden sollte, ist es dagegen relevant: Das WebP wird als sRGB gelesen, ohne dass irgendetwas in diesem Pfad das korrigiert.

Jede umgewandelte Datei behält ihren ursprünglichen Namen mit getauschter Endung, was einen Stapel handhabbar macht, aber die eigentliche Arbeit nicht beendet. Jeder Verweis auf die alte Datei — in einer Redaktionsseite des kommunalen Content-Management-Systems, in einer PDF-Anleitung, in einem verlinkten Formular — zeigt weiterhin auf einen Namen, der auf .bmp endet, und ein fehlendes Bild fällt auf einer öffentlichen Seite schneller auf als eine große Datei.

Die zweite Hälfte der Arbeit ist, die Bitmaps anschließend tatsächlich aus dem, was veröffentlicht wird, zu entfernen. Ein Redaktionssystem, das einen ganzen Medienordner unverändert übernimmt, liefert sonst beide Fassungen gleichzeitig aus — die Seite wird nicht kleiner, obwohl die Umwandlung längst gelaufen ist, und genau die Megabyte, die eigentlich eingespart werden sollten, werden weiterhin bei jedem Aufruf übertragen.

Ein ganzer Ordner lässt sich ablegen. Jede Bitmap wird nacheinander auf dem eigenen Rechner dekodiert und neu kodiert, behält ihren Dateinamen mit getauschter Endung, und der gesamte Satz kommt als ein ZIP zurück. Es gibt keine Warteschlange, kein Konto und keine Tagesgrenze, und die Obergrenze je Datei liegt bei 100 MB.

Dass die Umwandlung lokal läuft, zählt hier mehr als die Geschwindigkeit: Screenshots aus einem internen Fachverfahren, das personenbezogene Testdaten anzeigt, gehören nicht auf einen fremden Server, nur um sie kleinzurechnen — genau das lässt sich hier im eigenen Browser erledigen.