GIF in AVIF umwandeln

Die Website eines Sportvereins, einer Freiwilligen Feuerwehr oder eines kleinen Handwerksbetriebs wird selten neu gebaut — sie wächst über Jahre, und mit ihr bleiben die Bilder liegen, die einmal beim ersten Relaunch eingefügt wurden. Ein animiertes „Neu"-Icon, ein Vereinswappen als GIF, ein Logo-Banner aus der Zeit, als das die einzige Möglichkeit für Transparenz im Web war: Diese Dateien sind oft die ältesten Objekte auf der ganzen Seite, und niemand hat seither Grund gehabt, sie anzufassen.

Genau dort setzt eine Modernisierung an, sobald jemand die Ladezeit der Seite prüft — etwa weil eine Google-PageSpeed-Auswertung schlecht ausfällt oder die Seite auf dem Handy spürbar zäh lädt. Diese Umwandlung nimmt keine bewegten GIFs, sondern die stillen Grafiken darunter, und macht aus ihnen etwas, das ein moderner Browser mit deutlich weniger Bytes darstellt.

Ein GIF-Bild ist ein Raster aus Indizes in eine Palette mit höchstens 256 Einträgen, komprimiert mit LZW. Es enthält keine kontinuierlichen Farbtöne. Was auch immer das ursprüngliche Foto, der Verlauf oder der weiche Schatten war, wurde beim Erstellen des GIFs auf diese 256 Werte abgebildet, und diese Abbildung lässt sich nicht mehr umkehren.

Das ist wichtig, weil AVIF seinen Ruf an Fotografien erworben hat, wo es JPEG bei gleicher sichtbarer Qualität regelmäßig deutlich unterbietet. Ein altes Vereinslogo ist in diesem Sinn kein Foto, selbst wenn es eines abbildet, und die für AVIF kursierenden Zahlen übertragen sich nicht auf diese Quelle. Was hier erreichbar ist, ist begrenzt durch das, was das GIF überhaupt behalten hat.

Um Farben vorzutäuschen, die es nicht hat, verteilt ein GIF-Kodierer Pixel aus zwei verfügbaren Farben in einem abwechselnden Muster — meist Floyd-Steinberg-Dithering —, sodass das Auge sie zu einer dritten Farbe mittelt. Bei normaler Ansichtsgröße funktioniert das. Auf Pixelebene ist es ein Feld aus hochfrequentem Rauschen.

Jeder moderne Bildcodec, AVIF eingeschlossen, arbeitet, indem er jeden Block aus dem vorhergehenden vorhersagt und nur den Fehler speichert. Ein Dither-Muster lässt sich nach Konstruktion nicht vorhersagen, der Kodierer muss also echte Bytes aufwenden, um es exakt zu reproduzieren. Das Ergebnis ist der zunächst widersinnig wirkende Fall: ein AVIF, das größer ist als das GIF, aus dem es entstand, obwohl das Bild nur sechs sichtbare Farben zeigt.

Die Qualitätsregelung reicht von 1 bis 100 und steht standardmäßig auf 82 — ein sinnvoller Ausgangswert für Fotografien und eine vorsichtige Wahl für diese Quelle. Ein Bild mit 256 Farben hat weniger zu schützen, und 60 bis 65 sind bei einem umgewandelten GIF meist nicht vom Original zu unterscheiden, während sie den Dither-Aufschlag größtenteils entfernen.

Die Byte-Zahl entscheidet, nicht der Eindruck. Einmal mit der Voreinstellung umwandeln, einmal niedriger, beide gegen das GIF vergleichen — ist das AVIF nicht deutlich kleiner, steckt Dithering in der Quelle, und die Qualitätsstufe ist der Hebel dagegen. Bei wirklich flacher Grafik — einem Wappen, einer klaren Linienzeichnung, einem Vereinslogo ohne Verlauf — hält auch eine niedrige Einstellung problemlos, weil es nichts Feines gibt, das dabei beschädigt werden könnte.

Die Browserunterstützung ist hier als modern statt als universell eingetragen, ein Unterschied, der bei einer öffentlichen Vereinsseite mit echtem, breit gestreutem Publikum durchaus zählt: Aktuelle Browser lesen AVIF, und ein Teil der Besucherinnen und Besucher nutzt ältere Geräte oder Browser, die es nicht tun. Ein GIF dagegen öffnet, so unpraktisch es sonst ist, in wirklich jedem jemals gebauten Browser.

Das GIF einfach zu ersetzen, wäre für diesen Teil des Publikums ein Rückschritt, und genau dafür gibt es das `picture`-Element: AVIF als erste Quelle eintragen, PNG oder WebP als zweite, und ein normales `img`-Element als Basisfall darunter. Der Browser nimmt das erste Format, das er versteht, und niemand sieht ein kaputtes Bild — es lohnt sich, den Rückfall tatsächlich zu prüfen, weil das Fehlen genau auf der Maschine unsichtbar ist, auf der die Seite gebaut wurde.

AVIF unterstützt Animation, die Registry bestätigt das, und animierte AVIF-Dateien existieren. Diese Umwandlung erzeugt keine. Der Dekoder liefert genau ein Bild, und ein einzelnes Bild wird kodiert — ein animiertes GIF wird also zu dem Bild, mit dem es beginnt.

Für den Zweck dieser Seite ist das die richtige Entscheidung, denn hier geht es um Standbilder. Animiert das GIF tatsächlich noch — etwa ein blinkendes „Neu"-Symbol —, liegt die Ersparnis nicht in dieser Umwandlung: Ein Videocontainer mit echter Bewegungskompensation wird einen Bruchteil der Größe jedes Einzelbild-Formats erreichen, animiertes AVIF eingeschlossen, und der Video-Weg ist dann der richtige.

AVIF kann bis zu 12 Bit je Kanal speichern und einen erweiterten Farbraum tragen. Diese Fähigkeiten machen das Format zu einem guten Ziel für Fotografien von moderner Ausrüstung.

Auf ein GIF trifft davon nichts zu. Die Quelle hat 8-Bit-Palettenfarbe aus einer Tabelle mit 256 Einträgen, und sie in einen Container zu kodieren, der weit mehr fassen könnte, erzeugt keine zusätzlichen Farben — er speichert dieselbe Handvoll mit ungenutztem Spielraum. Verloren geht dabei nichts, was der eigentliche Punkt ist: Die Umwandlung ist in Sachen Farbe neutral, es geht allein um Bytes.

AVIFs bekanntes Problem in dieser Registry ist die Kodiergeschwindigkeit, und der Effekt ist nicht klein. AV1 wurde mit einem großen Suchraum entworfen, und der Standbild-Kodierer nutzt ihn vollständig — ein einzelnes mittelgroßes Bild braucht spürbar länger als dasselbe Bild als WebP oder JPEG, und diese Arbeit läuft auf dem eigenen Prozessor, nicht auf einer Serverfarm.

Für einen Ordner alter Vereinsgrafiken ist das trotzdem der richtige Tausch, weil die Kosten einmalig anfallen und die Ersparnis bei jedem Seitenaufruf wieder anfällt. Aber die Zeit sollte eingeplant werden: Ein Stapel von zweihundert alten GIFs ist eher eine Kaffeepause als ein Klick.

AVIF ist nicht automatisch die richtige Antwort für ein altes GIF. WebP kodiert deutlich schneller, wird von mehr Browsern unterstützt, und bei kleinen flachen Grafiken — genau das, was auf einer solchen Seite meist übrig ist — liegt der Größenunterschied zwischen beiden oft bei wenigen hundert Bytes.

Die grobe Faustregel: AVIF, wenn das Bild groß und fotografisch ist und die Ersparnis in Dutzenden Kilobyte gemessen wird; WebP, wenn das Bild eine kleine Grafik ist und der Gewinn eher in Kompatibilität und Kodierzeit liegt. Bei einem hartkantigen Logo mit wenigen Farben schlägt PNG häufig beide, weil verlustfreie Kompression flacher Farbflächen genau das ist, wofür PNG gebaut wurde.

AVIF trägt einen Alphakanal, und nichts in diesem Pfad flacht das Bild ab, ein transparenter Hintergrund aus dem GIF kommt also durch. AVIFs Alphakanal kennt zudem echte Abstufungen statt der einzigen Ein-oder-Aus-Transparenzfarbe, die GIF erlaubt — er kann allerdings nur wiedergeben, was das GIF tatsächlich hatte, also die hartkantige Fassung.

Für ein Vereinslogo mit glattem, transparentem Rand macht das kaum einen Unterschied zum Original. Wichtig ist nur, dass keine Hintergrundfarbe abgefragt wird und keine Einstellung nötig ist — die Transparenz kommt automatisch mit.

Der AV1-Kodierer ist ein WebAssembly-Modul, das beim ersten Gebrauch dieser Seite geladen wird und danach lokal läuft. Das Bild wird im Tab dekodiert und neu kodiert, nichts davon erreicht einen Server, es gibt kein Konto und keine Grenze außerhalb der freien 100-MB-Obergrenze je Datei.

Ein ganzer Ordner läuft auf demselben Weg und kommt gesammelt zurück. Weil die Arbeit lokal stattfindet, hängt die Geschwindigkeit vom eigenen Prozessor ab, nicht von einer Warteschlange — das macht den langsamen Kodierer erträglich, gerade wenn zwanzig Jahre alte Vereinsgrafiken einmalig aufgeräumt werden.