AVIF

Stichwort Bilder auf Webseiten.

Ich hatte es doch neulich mit den Bildformaten. Warum ich von JPEG, GIF und PNG (alle drei uralt und jedes mit einer Eigenschaft, die den anderen fehlt, für Bilder nimmt man JPEG, für Animationen GIF und für Graphiken PNG, weil verlustfrei und ohne Artefakte) und hin zu WebP wollte, weil das alle drei Eigenschaften in einem Bildformat vereint, bekömmlichere und weniger sichtbare Artefakte liefert und nicht immer, aber oft drastisch kleinere Dateien liefert (und damit gerade im Mobilfunkbereich oder auf dem deutschen Land mit seinen niedrigen Bandbreiten einen schnelleren Seitenaufbau ermöglicht).

Die Apple-Nutzer hatten sich ja beschwert, dass sie das dann nicht sehen können.

mozjpeg

Ein Professor hatte mich zwischendrin dafür beschimpft, dass ich über Fotografie schriebe, aber trotzdem nicht die Stärken von JPEG erkänne, es gebe doch Wunderbibliotheken, mit denen die Artefakten und so weiter wie weggeblasen seien. Und ließe sich dann mit jedem JPEG-fähigen Browser betrachten. Ich wollte es mal probieren, mag ja sein, dass es klappt, aber es war halt arg experimentell und ließ sich nicht in eine normale Build-Chain einbauen, und Exif ließ sich damit auch nicht einbetten. Ich bin ja gerne für sowas zu haben, aber dann muss es auch brauchbar und in Produktivstatus angekommen sein. Proof of Concept ist ja schön, aber nicht einsatzfähig. Und es löst das Problem nicht, dass man dann immer noch drei Formate braucht, je nach Anwendung. Und was nützt einem die schönste JPEG-Kompression, wenn man dann doch wieder GIF oder PNG braucht? Der GIF89a stammt von 1989, und beruht noch auf einer 8-Bit-Lookup-Table, ist auf 256 Farben beschränkt. War halt damals, vor 31 Jahren, Stand der Computertechnik. Beruhte auf GIF87a und stammt noch so aus der Zeit von C64 und Amiga. Das ist nichts mehr für heute. Das kann aber auch das aufgemotze JPEG nicht heilen, weil das dann eben auch keine Animationen oder Alpha-Channels hat, und sich auch mit HDR und dergleichen arg schwer tut.

Wer’s mal ausprobieren will: Siehe mozjpeg. Nach aufgeräumten Code sieht mir das nicht aus, und es hat war eine Nutzungslizenz, aber so richtig steht auch nicht drin, wem’s eigentlich gehört und wer einem die Lizenz da gibt. Gut dokumentiert ist es auch nicht. Und wenn mich der professorierte selbe noch dafür beschimpft, dass ich obige Anforderungen an ein Bildformat stelle, obwohl ich doch fast nie Animationen in meinem Blog habe, vergeht mir dann auch ziemlich die Lust.

Und wenn ich dann noch lese

MozJPEG is meant to be used as a library in graphics programs and image processing tools. We include a demo `cjpeg` tool, but it’s not intended for serious use. We encourage authors of graphics programs to use MozJPEG’s [C API](libjpeg.txt) instead.

Dann frage ich mich: Soll ich jetzt alles neu compilieren oder wie stellen die sich das vor? Dass ich Graphikprogramme noch gepatcht oder mit anderen Bibliotheken gelinkt habe, das habe ich schon ausführlich gemacht, das kann ich. Aber das habe ich eben so zwischen 1987 und 1996 gemacht, da war das Stand der Computerfrühzeit, als man das so ursprünglich erfunden hat, als es die ersten Graphikkarten gab. Und einfach so die dynamischen Libs auszutauschen, das dürfte auch problematisch sein, denn unter Ubuntu aktuell sind libjpeg.so.8.2.2 und libjpeg.so.9.4.0 hier kommt libjpeg.so.62.3.0 (gibt es als libjpeg62 zwar auch unter Ubuntu, aber wird von den normalen Tools nicht verwendet). Dass das cjpeg-Tool nicht für serious use ist, kann ich bestätigen.

Sieht für mich einfach nicht einsatzfähig aus, insbesondere dann nicht, wenn mir das als Individuallösung aufgeschwätzt werden soll und nicht Distributionsstandard wird.

Und wer das Ding fixt, wenn Fehler oder Sicherheitslöcher drin sind, man aber nicht weiß, wer dahinter steckt, ist auch unklar.

WebP

Jedenfalls ist Apple gerade dabei, neue Versionen für MacOS und iOS bzw. Safari auszurollen, und wenn sich das etwas stabilisiert, sollte webp eigentlich ohne weiteres und praktikabel einsetzbar sein, ohne die Apple-User auszusperren.

Und da das zwar noch nicht in allen Anwendungsprogrammen eingebaut, ansonsten aber schon ziemlich gut automatisierbar und in den Bildverarbeitungs-tools drin ist, werde ich das zukünftig so machen, aber erst dann, wenn ich das voll durchautomatisiert habe, das ist mir manuell noch zuviel gehuddels.

AVIF

Ein Leser hat mir deshalb den Hinweis auf diese Webseite geschickt, wwonach schon der Nachfolger von WebP, AVIF inzwischen stabil ist (WebP ist aus dem Videoformat VP8 abgeleitet, AVIF vom Nach-Nachfolger AV1). Chrome 85 hätte das schon drin, an Android und Firefox arbeiten sie, und Apple braucht vielleicht nicht wieder 10 Jahre, um den Arsch hochzukriegen.

Ich bin mir noch nicht sicher, was ich vom HTML-Tag <picture> statt <img> halten soll, ob das in allen Browsern voll unterstützt wird. Jedes Bild dann zwei- oder dreimal anzubieten, ist jetzt auch nicht so super, ich muss es erst testen.

Aber ich denke, über kurz oder lang dürfte sich dann WebP oder sogar AVIF, wenn das ausreichend besser ist, um nochmal eine Änderung zu rechtfertigen.

Wobei man bei den Vergleichen auf dieser Seite doch sieht, dass die Details deutlich verloren gehen (vor allem sichtbar am Ausschnitt). Am interessantesten erscheint mir tatsächlich AVIF, wenn man die Kompression nicht so hoch dreht wie in diesem Beispiel. Zumindest WebP hat auch einen lossless-Modus.