BMP in AVIF umwandeln

AVIF ist, strukturell betrachtet, ein einzelnes Bild aus dem Videocodec AV1 in einer eigenen Verpackung. Es erbt damit die Kompressionsarbeit eines modernen Videocodecs, und genau das erklärt, warum ein Foto als AVIF meist kleiner ausfällt als dieselbe Aufnahme als WebP oder JPEG bei vergleichbar sichtbarer Qualität.

Für eine unkomprimierte Bitmap ist das ein großer Sprung. Eine BMP-Datei speichert jeden Bildpunkt roh, ohne jede Kompression — AVIF baut genau diese Redundanz ab. Der Größenunterschied zwischen Ausgangs- und Zieldatei ist deshalb bei dieser Kombination besonders auffällig, weit deutlicher als bei einem bereits komprimierten JPG als Quelle.

AVIF kann zwölf Bit pro Kanal und weite Farbräume beschreiben — genau die Eigenschaften, die den Container für HDR-Fotografie interessant machen. Eine BMP-Datei hat davon nichts: Sie speichert acht Bit pro Kanal in einfachem RGB, ohne Farbprofil.

Der zusätzliche Spielraum im AVIF-Container bleibt also leer, und der einzige Gewinn dieser Umwandlung ist die Kompression selbst. Das ist ein echter Vorteil, aber es lohnt sich zu wissen, dass es der einzige bleibt — ein Format erfindet keine Information, die in der Quelle nie enthalten war. Wer wirklich zwölf Bit und weiten Farbraum nutzen will, braucht eine Quelle, die diese Werte überhaupt aufgezeichnet hat, etwa ein RAW-Foto direkt aus der Kamera statt einer Bitmap, die selbst schon aus acht Bit besteht.

Die Kodierung läuft als WebAssembly direkt im Browser-Tab, auf dem Prozessor des eigenen Geräts. Kein Server übernimmt die Arbeit, was zugleich der Grund dafür ist, dass nichts hochgeladen wird — und der Grund, warum ein großes Bild spürbar länger braucht als bei WebP oder JPEG. Dieselbe Kodierung auf einem fremden Server würde nicht schneller laufen, sie würde nur auf einem fremden Prozessor stattfinden, und die Bitmap müsste zuerst dorthin übertragen werden.

Die Standardqualität liegt bei 82, derselbe Wert, den auch WebP und JPEG hier voreingestellt bekommen. Für eine einzelne Bitmap ist das ein Warten von wenigen Sekunden; für einen ganzen Ordner voller Scans wird daraus eine Pause, in der man besser etwas anderes tut. Wichtig dabei: Der Zahlenwert 82 ist keine über Formate hinweg vergleichbare Prozentzahl, sondern eine Einstellung des jeweiligen Encoders — 82 in AVIF und 82 in JPEG bedeuten unterschiedlich viel Verlust und unterschiedliche Dateigrößen.

Wer eine Website für ein Publikum außerhalb der Großstädte betreibt, kennt das Problem: Viele Anschlüsse in ländlichen Regionen Deutschlands liegen bei einer Bandbreite, die eine unnötig große Bilddatei sofort spürbar macht, während sie in der Stadt kaum auffällt. Jedes eingesparte Kilobyte pro Bild zählt hier doppelt.

Genau dafür ist AVIF gedacht, wenn die Ladezeit ein echtes Kriterium ist — für den Handwerksbetrieb mit Referenzfotos, den Verein mit einer Bildergalerie, den Blog mit vielen Screenshots. Die kleinste Datei ist an dieser Stelle kein Nice-to-have, sondern der Unterschied zwischen einer Seite, die lädt, und einer, bei der jemand vorher abbricht. Google zieht die Ladezeit inzwischen als Rankingfaktor heran, was diesen Effekt zusätzlich verstärkt: Eine Seite, die auf schlechten Verbindungen langsam lädt, wird nicht nur von Besuchern seltener zu Ende gesehen, sie wird auch schlechter gefunden.

AVIF trägt einen Alphakanal, und nichts in dieser Umwandlung flacht das Bild ab oder fragt nach einer Hintergrundfarbe. Eine 32-Bit-Bitmap mit durchsichtigen Bereichen behält sie also.

In der Praxis betrifft das die wenigsten Dateien: Die meisten BMP-Dateien sind 24-Bit ohne Alphakanal, weil das Format historisch aus einer Zeit vor konsequenter Transparenzunterstützung stammt. Wo nichts durchsichtig war, bleibt auch im AVIF nichts durchsichtig.

Aktuelle Desktop- und Mobilbrowser zeigen AVIF anstandslos an. Ältere Geräte, manche eingebetteten Browser in Apps und ein Teil der E-Mail-Programme tun das nicht — das ist der Preis der Effizienz. Wie groß dieser Anteil tatsächlich ist, hängt stark vom eigenen Publikum ab; eine Vereinsseite mit überwiegend jüngerem Publikum trifft die Lücke seltener als eine Seite, die auch auf älteren Firmenrechnern oder Tablets betrachtet wird.

Als Anhang oder als Datei, die man weitergibt, ist AVIF deshalb eine schlechte Wahl: Dass es auf dem eigenen Rechner öffnet, sagt wenig darüber, ob es beim Empfänger auch tut. Für eine Website, die selbst entscheidet, was sie ausliefert, ist die Einschränkung dagegen unproblematisch.

Das picture-Element löst die Kompatibilitätslücke sauber: mehrere Quellen in einer Reihenfolge, jede mit ihrem Typ, und der Browser nimmt die erste, die er versteht. AVIF zuerst, WebP danach, JPEG als letzte Sicherung — jeder Besucher bekommt die kleinste Datei, die sein Browser tatsächlich darstellen kann.

Das bedeutet, dieselbe Bitmap zweimal umzuwandeln, einmal zu AVIF und einmal zu WebP. Beide sollten aus der Bitmap selbst entstehen und nicht auseinander — jeder verlustbehaftete Encoder trifft eigene Entscheidungen darüber, was verworfen wird, und ein AVIF aus einem bereits komprimierten WebP trägt beide Verluste, ohne dafür kleiner zu werden. Wer diese Reihenfolge einmal falsch macht, sieht das Ergebnis meist erst bei genauem Hinsehen: kleine, wolkige Artefakte, die weder zu AVIF noch zu WebP allein passen, sondern nur zur Kombination beider Verfahren.

Wenn zum Publikum ältere Geräte gehören. Wenn das Bild so klein ist, dass der Unterschied ein paar Kilobyte ausmacht. Wenn es sich um flache Grafik mit harten Kanten handelt, bei der AVIFs Vorteil schrumpft und sich gelegentlich sogar umkehrt. Und wenn hunderte Dateien anstehen und die Kodierzeit der eigentliche Engpass ist.

AVIF verdient seinen Aufwand bei großen fotografischen Bildern für ein modernes Publikum über ein picture-Element. Das ist ein bestimmter Fall, kein Standardfall — eine Seite, die etwas anderes behauptete, würde das neuere Format verkaufen, statt es zu beschreiben. Der Test, der es klärt, kostet eine Minute: eine typische Bitmap in beide Formate umwandeln, die zwei Dateigrößen nebeneinanderlegen und entscheiden, ob der Unterschied eine zweite Kodierung und einen Fallback im Markup rechtfertigt. Manchmal ist die Antwort eindeutig ja, oft ebenso eindeutig nein.

Eine maximale Breite senkt Dateigröße und Kodierzeit gemeinsam, weil beide von der Pixelzahl abhängen und nicht von der Breite allein: Eine halbierte Breite entfernt drei Viertel der Pixel, die der Encoder verarbeiten muss.

Als Faustregel gilt die Breite, in der das Bild jemals angezeigt wird, verdoppelt für hochauflösende Bildschirme. Ein 4000 mal 3000 Pixel großer Scan, auf 2000 mal 1500 verkleinert, ist auf fast jeder Seite immer noch größer als nötig — und die AVIF-Kodierung ist dabei ungefähr viermal schneller fertig.

Der ganze Ordner lässt sich auf einmal ablegen; jede Datei wird einzeln im eigenen Browser umgewandelt, behält ihren Namen mit getauschter Endung, und der Satz kommt als eine einzige ZIP-Datei zurück. Die Obergrenze liegt bei 100 MB pro Datei, was etwa 33 Megapixeln einer unkomprimierten Bitmap entspricht.

Da die Dateien nacheinander verarbeitet werden, bestimmt die größte Datei die Gesamtdauer überproportional mit. Wer vorher die offensichtlich zu großen Scans aussortiert und verkleinert, gewinnt mehr Zeit als durch jede andere Einstellung auf dieser Seite. Bei vierzig oder fünfzig Dateien lohnt es sich, den Ordner vorher kurz nach Dateigröße zu sortieren und die auffälligen Ausreißer getrennt zu behandeln, statt den ganzen Stapel gleich zu behandeln, als bestünde er aus lauter ähnlich großen Bildern.

AVIF ist ein Zustellformat, und diese Umwandlung ist verlustbehaftet. Was herauskommt, ist auf den Zielort zugeschnitten — es gibt keinen Weg zurück zu den Bildpunkten, die die Bitmap ursprünglich enthielt.

Ist die BMP-Datei die einzige Kopie, lohnt es sich, sie aufzuheben oder zuerst verlustfrei in PNG umzuwandeln, was nur einen Bruchteil des Speicherplatzes kostet. Das AVIF entsteht dann bei jedem neuen Zielort erneut aus dem Original, statt ein bereits verlustbehaftetes Zustellformat noch einmal zu kodieren. Diese Reihenfolge kostet beim ersten Mal etwas mehr Aufwand, erspart aber jedes Mal, wenn sich später eine Anforderung ändert — ein neues Zielformat, eine andere Zielgröße —, das erneute Suchen nach der ursprünglichen Quelle.

Dekodierung und AV1-Kodierung laufen beide im Browser-Tab auf dem eigenen Prozessor. Es gibt keine Warteschlange, kein Konto und keine Obergrenze, die aus Serverkapazität begründet wäre — die praktische Grenze ist der Arbeitsspeicher des eigenen Geräts.

Für Referenzfotos, interne Screenshots oder Scans, die niemand außerhalb der eigenen Organisation sehen soll, ist das mehr als eine Formalität. Der Netzwerk-Tab des Browsers zeigt während der Umwandlung, dass keine Anfrage die Bitmap irgendwohin trägt — dieselbe Prüfung lässt sich auch mit getrennter Internetverbindung wiederholen, und die Umwandlung läuft trotzdem unverändert weiter, weil sie nie auf eine Verbindung angewiesen war.