HEIF in WebP umwandeln

Ein deutsches CMS wie TYPO3 prüft Uploads gegen eine feste Liste erlaubter Dateitypen, und HEIF steht dort so gut wie nie drauf. Das wirkt willkürlich, bis man bedenkt, was das System als Nächstes tun müsste: eine Miniaturansicht erzeugen, mehrere responsive Größen ausgeben, eine Vorschau im Editor anzeigen. Bei einem Format, dessen Browser-Unterstützung nur teilweise vorhanden ist, kann es das nicht zuverlässig, und die sicherste Reaktion ist, die Datei abzulehnen.

Damit landet die Umwandlung bei dir statt beim System, und vor dem Hochladen zu konvertieren ist besser als danach. Du bestimmst Maße und Qualität selbst; ein automatischer Neuencoder des CMS, sofern vorhanden, arbeitet sonst mit dem, was du ihm gibst.

Google hat WebP 2010 veröffentlicht, inzwischen ist es als RFC 9649 standardisiert. Was es für diese Aufgabe zur Standardwahl macht, ist nicht raffinierte Kompression, sondern Reichweite: Es ist eines der wenigen Bildformate in diesem Register, dessen Browser-Unterstützung als vollständig statt modern oder teilweise geführt wird — eine einzige Datei funktioniert für jeden Besucher, ohne Rückfalloption.

Es bringt außerdem die zwei Dinge mit, die ein Ausgabeformat braucht und die JPG fehlen: einen Alphakanal und eine bessere Kompression bei gleicher sichtbarer Qualität. Für eine Seite, die auf dem Handy über eine langsame Verbindung laden soll, sind das genau die zwei Stellschrauben, die zählen, ohne dass irgendjemand über Content-Typen verhandeln muss.

Der Standardwert ist 82 auf einer Skala von 1 bis 100. Für Fotos auf einer Webseite ist das ein guter Punkt: Detail bleibt bei der Größe erhalten, in der ein Browser sie tatsächlich anzeigt, und die Datei ist ein Bruchteil dessen, was eine verlustfreie Kopie kosten würde. Werte in den Sechzigern sparen echte Byte, zeigen sich dann aber an Kanten und in flächigen Bereichen.

Zu bedenken ist, dass dies bereits die zweite Kompression ist, die das Bild durchläuft. Die Kamera hat es zu HEIF komprimiert, und diese Umwandlung komprimiert das, was daraus hervorgegangen ist. Ein einzelner weiterer Durchgang bei 82 fällt niemandem auf — ein Grund mehr, jedes Mal aus dem HEIF-Original neu zu konvertieren, statt ein bereits erzeugtes WebP erneut zu komprimieren.

WebP kann kein Bild beschreiben, das auf einer Seite länger als 16.383 Pixel ist. Das ist eine Eigenschaft des Formats, keine dieses Konverters, und keine Einstellung umgeht sie. Ein Foto mit zwölf oder achtundvierzig Megapixeln liegt in beide Richtungen weit darunter, für normale Aufnahmen kommt die Grenze also nie ins Spiel.

Was tatsächlich vorkommt, ist ein Panorama. Der Panoramamodus des Handys näht ein sehr breites, niedriges Bild zusammen, und solche Aufnahmen überschreiten regelmäßig sechzehntausend Pixel in der Breite. Für diesen Fall vor der Umwandlung eine maximale Breite setzen — was ohnehin sinnvoll wäre, weil keine Webseite ein Bild in dieser Breite darstellt.

Das Feld für die maximale Breite ist die wertvollste Einstellung auf dieser Seite für den Webeinsatz. Ein 4.032-Pixel-Foto auf 1.600 Pixel zu reduzieren, verringert die Datenmenge, mit der der Encoder überhaupt arbeitet, auf ungefähr ein Sechstel — und 1.600 ist für ein Inhaltsbild auf einer Desktop-Seite bereits großzügig bemessen.

Ein Foto in voller Auflösung auszuliefern und den Browser herunterskalieren zu lassen, ist der häufigste Fehler bei der Seitengröße überhaupt: Der Besucher bezahlt für jedes einzelne dieser Pixel und sieht davon vielleicht ein Fünftel. Werden mehrere Größen für ein responsives Set gebraucht, das HEIF mehrfach mit unterschiedlichen Breiten konvertieren, statt das WebP nachträglich zu verkleinern.

Beide Formate haben einen Alphakanal, ein Bild mit freigestelltem Hintergrund kommt also mit intakter Transparenz an und lässt sich auf einen farbigen Seitenbereich legen, ohne dass ein weißer Kasten drumherum entsteht.

Beide Formate unterstützen auch Animation, und dieser Teil kommt nicht mit herüber. Der Dekoder nimmt nur das primäre Bild aus dem HEIF-Behälter, der Encoder schreibt genau ein Standbild — ein Mehrbild-HEIF wird also zu einem einzigen Bild. Soll die Bewegung erhalten bleiben, ist dies nicht das passende Ziel dafür.

Das hier geschriebene WebP enthält kein EXIF und kein XMP. Nichts wurde gezielt herausgefiltert — die Umwandlung dekodiert das Bild zu rohen Pixeln und schreibt es neu, und für Metadaten gibt es auf diesem Weg keinen Platz.

Auf einer Seite über Veröffentlichung ist das der wichtigste einzelne Punkt. Ein Handyfoto trägt regelmäßig Breiten- und Längengrad mit Genauigkeit auf Hausnummernniveau, und ein Shopartikel oder Blogbeitrag mit diesen Daten veröffentlicht damit, wo der Fotograf wohnt — ein Datenschutzpunkt, der bei einer Veröffentlichung nach deutschem Verständnis besonders schwer wiegt. Manche Plattformen entfernen das beim Upload, manche nicht; vorher zu konvertieren macht diese Unterscheidung überflüssig.

AVIF komprimiert dasselbe Bild bei gleicher sichtbarer Qualität kleiner, und seine Browser-Unterstützung ist neuer als die von WebP, statt vollständig zu sein. Das ist der ganze Vergleich, und er entscheidet sich daran, wie die eigene Seite Bilder ausliefert.

Wird eine Datei hochgeladen und an alle ausgeliefert, ist WebP die Antwort — keine Aushandlung, keine Rückfalloption, nichts zu testen. Kann die Auslieferungsschicht AVIF an Browser ausgeben, die es melden, und WebP an den Rest, lohnt sich der zusätzliche Schritt, dafür gibt es eine eigene Seite. AVIF allein als einziges Format zu wählen, nur weil es neuer ist, ist der sicherste Weg zu einem kaputten Bild bei manchen Besuchern.

Sowohl der HEIF-Dekoder als auch der WebP-Encoder laufen im Browser-Tab, auf dem eigenen Prozessor. Es gibt keinen Upload, keine Warteschlange, kein Konto, und die Datei existiert nie auf einem fremden Server — bei noch nicht veröffentlichten Produktfotos oder Aufnahmen von Personen, die noch nichts zugestimmt haben, ist das der entscheidende Unterschied.

Die kostenlose Stufe nimmt bis zu 100 MB pro Datei, was kein Handyfoto erreicht. Ein ganzer Ordner läuft in einem Durchgang mit jeweils eigener Fortschrittszeile, und sobald zwei Dateien fertig sind, erscheint ein „Alles als ZIP"-Button — dreißig Bilder für eine Galerie vorzubereiten ist damit ein Download statt dreißig.

Das HEIF behalten. Es ist die qualitativ beste Kopie, die vorhanden ist, es ist zugleich die kleinste, und jede künftige Größe oder jedes künftige Format sollte daraus entstehen und nicht aus dem bereits veröffentlichten WebP.

Einen Rückweg gibt es ohnehin nicht: Diese Website kann HEIF lesen und nicht schreiben, weil der dafür nötige Encoder unter einer Lizenz steht, die eine statische Website nicht erfüllen kann. Das WebP ist also die Ableitung, das HEIF das Original — und so lohnt es sich auch abzulegen, statt die Datei zu löschen, die sich nicht neu erzeugen lässt.

WebP ist unter den Ausgabeformaten ungewöhnlich, weil es zwei getrennte Modi kennt: einen verlustbehafteten, der auf videoartiger Kompression aufbaut, und einen verlustfreien, der eher PNG ähnelt. Das Register führt das Format als grundsätzlich verlustfrei-fähig, und es lohnt sich zu wissen, welchen der beiden man tatsächlich bekommt.

Diese Umwandlung schreibt den verlustbehafteten Modus, bei der gesetzten Qualitätsstufe. Für ein Foto ist das die klar richtige Wahl — verlustfreies WebP eines Kamerabilds ist mehrfach so groß und gewinnt nichts zurück, weil das HEIF bereits verworfen hat, was es verworfen hat, lange bevor diese Seite ins Spiel kommt. Wird ausdrücklich eine verlustfreie Kopie eines HEIF gebraucht, ist PNG der ehrliche Weg dazu.