AVIF montre ses nerfs

L’AVIF prend enfin ses aises sur Internet : c’est quoi ce format d’image ?

Abonnez-vous pour tout dévorer et ne rien manquer.

Déjà abonné ? Se connecter

Abonnez-vous

Avec la sortie d’Edge 121, le dernier grand navigateur se dote de la compatibilité avec la AVIF. Ce format d’image, disponible officiellement depuis presque cinq ans, avait été créé pour prendre la relève du JPG. Aujourd’hui, le format peut-il accomplir sa mission ?

Il y aura bientôt dix ans, la question du remplaçant du vénérable JPEG se posait déjà. En 2015, plusieurs grandes entreprises du numérique se sont rassemblées pour travailler sur la question. Alphabet, Amazon, AMD, Apple, Cisco, Intel, Meta, Mozilla, Microsoft, Netflix ainsi que Tencent ont alors formé l’Alliance for Open Media (AOMedia).

À cette époque, la question du poids des fichiers est prégnante. Si les objectifs n’ont guère changé, les motivations ont légèrement évolué. Des fichiers de taille réduite prennent en effet moins de temps à télécharger. Le besoin en bande passante est donc moindre, tout comme l’est la consommation énergétique. Il fallait donc faire mieux que le JPEG, tout en améliorant la qualité d’image.

C’est ainsi qu’est né le format AOMedia Video 1, ou AV1.

De l’AV1 à l’AVIF

L’AV1 est un codec vidéo open source (nous y reviendrons). On peut le retrouver dans des formats conteneurs comme MP4, MKV ou même WebM. Il a été créé pour supplanter les anciens formats et se tailler la part du lion. C’est surtout vrai face aux formats MPEG, dont les licences ont toujours représenté un frein. L’utilisation d’AV1 est gratuite.

C’est de ce codec qu’est issu l’AVIF, pour AV1 Image File Format. Plus précisément, il en reprend les algorithmes de compression, tout en s’inspirant du HEIF pour d’autres aspects, notamment en matière de structure du fichier et du stockage des informations, dont les métadonnées.

Un mot d’ailleurs sur le HEIF (High Efficiency Image File Format). Il s’agit d’un conteneur dans lequel on stocke ce que l’on veut. Ce format a été popularisé par Apple qui s’en sert depuis des années sur iOS et macOS. Les photos prises par l’iPhone l’utilisent par défaut. Apple utilise les codecs HEIC pour les photos et HEVC (H.265) pour les vidéos.

Le jeu du chat et de la souris sur l’accélération matérielle AV1

Profitons de l'occasion pour aborder l’accélération matérielle de l’AV1, qui se répand enfin dans les ordinateurs. Les cartes graphiques Radeon d’AMD (RDNA2), GeForce de NVIDIA (Série 30) et Alchemist d’Intel le proposent depuis plusieurs années. On retrouve aussi de l’accélération dans les CPU AMD (Zen 3+) et Intel avec partie graphique intégrée (Core de 11e génération).

Chez Apple, l’attente aura été bien plus longue puisque seules les puces M3 pour les MacBook et A17 Pro pour l’iPhone 15 Pro seulement (pas l’iPhone 15 qui est en A16 Bionic, comme le 14 Pro) proposent une accélération matérielle du décodage AV1.

Chez les fabricants de SoC, c’est un peu la loterie, comme on peut le voir sur le récapitulatif maintenu à jour par Vivien Guéant sur Lafibre.info. Le haut de gamme chez Qualcomm en profite (comme les Snapdragon X Elite et 8 Gen 2/3), mais pas encore les gammes d’en dessous. MediaTek Google et Samsung semblent être de bien meilleurs élèves. Le Tensor G3 des Pixel 8 et le Snapdragon X Elite proposent même une accélération du codage AV1, en plus du décodage.

On regrette par contre l’absence d’accélération sur le Raspberry Pi 5.

Ce que permet l’AVIF

Si on le compare au JPEG, AVIF est clairement un format beaucoup plus moderne. D’une part, il supporte plusieurs espaces de couleur, dont le SDR classique bien sûr, ainsi que le HDR. L’indication de l’espace peut se faire par profil CICP ou ICC.

D’autre part, il prend en charge les profondeurs de couleur de 8, 10 et 12 bits, ainsi que les sous-échantillonnages 4:2:0, 4:2:2 et 4:4:4. Des informations de zones transparentes peuvent en outre être stockées dans un canal alpha (comme le PNG par exemple), et l’AVIF peut servir à enregistrer des séquences animées (comme les GIF).

Il possède deux modes de compression : l’un avec perte, l’autre sans. Cela signifie dans le premier cas que des informations sont perdues, mais pas dans le second. Cette possibilité de choisir donne une souplesse selon la finalité recherchée. Si l’on souhaite par exemple réduire autant que possible le poids d’une image pour illustrer un article et que la différence visuelle est pratiquement invisible, on peut choisir la compression avec perte. À l’inverse, si la qualité prime, on prendra celle sans perte, au prix d'un poids beaucoup plus important.

En matière de compression, le format AVIF fait à peu près jeu égal avec son concurrent direct, le HEIF. Avec des paramètres par défaut, le gain de place est d’environ 50 % par rapport au JPEG, et presque 80 % par rapport aux GIF pour les séquences animées. Il est également meilleur que le webp, largement popularisé par Google (nous y reviendrons). Des constructeurs d’appareils photo, dont Canon et Sony, ont suivi le mouvement.

Pour comparer la qualité entre deux images compressées différemment, on peut se rendre sur plusieurs sites permettant de se faire une bonne idée, comme Squoosh ou ce billet de Jake Archibald.

Enfin, l’AVIF peut stocker de nombreuses informations dans les métadonnées, dont une miniature, qui peut être d’ailleurs une séquence animée. On peut y trouver aussi des informations d’orientation, d’autres sur le recadrage, une carte pour la profondeur, des données sur les multiples expositions, etc.

Licence : l’argument de poids de l’AVIF

L’un des plus gros arguments de l’AVIF est hérité de l’AV1 : il est open source. Son utilisation est gratuite et n’est soumise à aucune redevance (royalties).

C’est une différence de taille avec de nombreux codecs et formats de fichiers utilisés aujourd’hui. Le HEIF par exemple, qu’utilise Apple, provient du Moving Picture Experts Group (MPEG). Comme pratiquement tous les formats et codecs provenant du groupe, tout logiciel utilisant des capacités liées doit passer par la case des redevances.

Ce n'est justement pas le cas de l'AVIF, comme d'autres codecs open source, à l'instar de l'OpenH264, du Xvid ou du FLAC.

Support actuel d’AVIF et arrivée d’Edge 121

Aujourd’hui, le format AVIF est supporté par de très nombreux produits. En fait, pratiquement tous. La plupart du temps, c’est le système d’exploitation qui s’en occupe pour les besoins quotidiens, comme l’ouverture d’images dans les visionneuses. Tous les logiciels de retouche le prennent également en charge.

Les prestataires et autres technologies de développement s’y sont mis également. Cloudflare le prend en charge par exemple depuis octobre 2020, PHP dans sa version 8.1 via l’extension GD, Wordpress via de nombreuses extensions aussi, et ainsi de suite.

En ce qui concerne les navigateurs, c’est aussi le cas depuis longtemps. En tout cas pour la grande majorité. Google l’a par exemple ajouté à Chrome dans sa version 85 en août 2020. WebKit, au sein de Safari, s’en est doté en mars 2021. Pour Firefox, ce fut dans la mouture 93 en octobre 2021. Le seul grand absent dans la liste était Edge.

C’est un cas étrange, sur lequel Microsoft ne s’est pas vraiment expliqué. Le support d’AVIF a en effet été intégré dans Windows 10 avec la mise à jour 19H1, donc dans la première moitié de 2019. Ce support est depuis entretenu via l’AV1 Video Extension du Microsoft Store.

Pourtant, Edge ne le prend en charge que depuis sa version 121, arrivée… la semaine dernière. On peut cependant formuler une hypothèse : Microsoft a été l’un des promoteurs du HEVC. L’entreprise a peut-être fait de la résistance jusqu’à présent.

Sur mobile, le déploiement d’Edge 121 est en cours (depuis le 29 janvier) et peut prendre quelques jours pour atteindre l’ensemble des terminaux. Si notre navigateur n’est pas compatible et qu’un site utilise une image au format AVIF (sans fallback vers un autre format), alors elle ne s’affichera pas dans le navigateur.

L’un dans l’autre, c’est le dernier verrou significatif qui saute pour le web, comme on peut le voir sur le site CanIUse. La question est de savoir maintenant si l’AVIF va prendre son envol.

Où en est l’AVIF ?

Si l’on en croit l’Alliance for Open Media, tout va très bien. Dans un billet de blog datant de novembre, elle vante un support omniprésent de l’AVIF et une explosion de son utilisation. Qu’en est-il ?

Difficile de savoir avec précision, mais il est clair que l’immense majorité des sites se servent aujourd’hui d’images aux formats JPEG, PNG et WebP. Quelques sites, notamment de distributions de photos, se servent d’AVIF, comme Unsplash.

Actuellement, l’AVIF fait face à deux types de difficultés pour réussir sa mission. La première est le poids des habitudes : le JPEG reste très présent et garde la faveur de nombreux producteurs de contenus web. Quand la qualité visuelle n’est pas primordiale, les outils utilisés depuis toujours produisent de petits fichiers.

L’autre grande barrière est la multiplicité des formats. L’AVIF n’est pas le seul à vouloir prendre la relève du JPEG. HEIF a été conçu dans cette optique, de même que WebP. Or, ce dernier est promu par Google, qui l’utilise sur tous ses sites. C’est le format d’image par défaut du géant pour tout ce qui touche au web (d’où le nom). Là encore, avec des bénéfices de poids à qualité équivalente, ou de qualité à taille équivalente.

Ce qui n’empêche pas AVIF d’être bel et bien présent. Par exemple, Netflix s’en sert pour les images de son interface, y compris les miniatures des films. Mais il n’est guère présent sur le web. Sur le site W3techs.com, on peut voir qu’à peine 0,1 % des sites s’en servent aujourd’hui. Dans un autre diagramme, un constat intéressant cependant : même s’il est peu utilisé, il l’est davantage sur des sites à fort trafic, comme canva.com.

Commentaires (45)


un format opensource qui peut remplacer à la fois le jpeg et le gif pour des gains de place assez impressionnants ? J'y vois que des avantages :)
Pareil. Je ne connaissais pas, et je vais en faire la promotion, surtout maintenant que plus rien ne le "bloque".
Perso je préfère JPEG-XL.
Il est plus récent et semble plus efficace que AVIF.
En plus il a la bonne idée d’être rétro compatible :yes: en plus de pouvoir recompresser sans perte les JPG classiques.
Il est malheureusement moins rependu et google la rétrogradé en tant que plugin pour Chrome :craint:

Mimoza

Perso je préfère JPEG-XL.
Il est plus récent et semble plus efficace que AVIF.
En plus il a la bonne idée d’être rétro compatible :yes: en plus de pouvoir recompresser sans perte les JPG classiques.
Il est malheureusement moins rependu et google la rétrogradé en tant que plugin pour Chrome :craint:
Voir le bug https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 l'un des plus populaires.

Une demande a été faite pour le ré-intégrer https://bugs.chromium.org/p/chromium/issues/detail?id=1451807

Google fait la sourde oreille, avec des arguments… décevants.

Oui, le gros avantage du JPEG-XL, c'est que sa taille d'image n'est pas contrainte, contrairement à AVIF, qui doit faire des tuiles, et ça implique des effets de décodage sur les bords des tuiles.

Glandos

Voir le bug https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 l'un des plus populaires.

Une demande a été faite pour le ré-intégrer https://bugs.chromium.org/p/chromium/issues/detail?id=1451807

Google fait la sourde oreille, avec des arguments… décevants.

Oui, le gros avantage du JPEG-XL, c'est que sa taille d'image n'est pas contrainte, contrairement à AVIF, qui doit faire des tuiles, et ça implique des effets de décodage sur les bords des tuiles.
Pour ceux qui aiment Jpeg XL, vous pouvez aller voter pour l'intégration dans les navigateurs (pour ceux qui ont un compte GitHub): https://github.com/web-platform-tests/interop/issues/430

Et si vous lisez les commentaires, y'a pleins d'infos sur le format...

Ah et un lien vers un article accusant Google de bloquer sans bonnes raisons: https://www.techspot.com/news/101764-google-once-again-accused-snubbing-jpeg-xl-image.html
Modifié le 06/02/2024 à 15h41

cosmocat

Pour ceux qui aiment Jpeg XL, vous pouvez aller voter pour l'intégration dans les navigateurs (pour ceux qui ont un compte GitHub): https://github.com/web-platform-tests/interop/issues/430

Et si vous lisez les commentaires, y'a pleins d'infos sur le format...

Ah et un lien vers un article accusant Google de bloquer sans bonnes raisons: https://www.techspot.com/news/101764-google-once-again-accused-snubbing-jpeg-xl-image.html
Malheureusement le ticket github que tu point à été cloturé :(
HDR, SDR, CICP, ICC, HEIF etc ... Moi j'ai rien compris.
C’est la foire !
Je ne comprends pas trop pourquoi il n'est pas plus comparé au webp, qui me parait être le concurrent le plus direct (licence open-source, animation, avec / sans perte, ratio supérieur en général à ceux de JPEG, ...). On doit se contenter d'un léger "Il est également meilleur que le webp" en parlant de la compression.

Et le webp existe depuis 14 ans maintenant.

Et j'ai un sentiment mitigé, à la lecture de l'article, dont la première lecture me laisse un amalgame entre le format AVIF (qui est un conteneur si j'ai bien compris) et le format AV1 (qui est le codec). Parfois, j'ai l'impression que l'on parle des avantages de l'AVIF alors qu'en réalité, on parle des avantages du codec et inversement. Exemple :
Ce n’est justement pas le cas de l’AVIF, comme d’autres codecs open source, à l’instar de l’OpenH264, du Xvid ou du FLAC.

En matière de compression, le format AVIF fait à peu près jeu égal avec son concurrent direct, le HEIF


Cela n'enlève rien au fait que l'article est intéressant, mais du coup, ne connaissant pas l'AVIF, je suis perdu !
Modifié le 02/02/2024 à 11h52
D'ailleurs, à la lecture du premier paragraphe sur Wikipédia
Le format de fichier image AV1 Image File Format (AVIF) est un format ouvert de fichier image permettant de sauvegarder des images ou séquences d'images au format compressé avec le format AV1 HEIF. Il est développé par le consortium Alliance for Open Media. Il concurrence le format HEIC qui utilise le même format de conteneur, conçu à partir de ISOBMFF (en), mais HEVC pour la compression.


On y dit que AVIF est un AV1 HEIF. Donc du HEIF avec comme CODEC AV1. Du coup, c'est un cas particulier de HEIF. HEIC n'est pas décrit comme un codec, mais comme le "concurrent" de l'AVIF car est un HEVC HEIF.

Bref, du coup, avec tous ces acronymes dans tous les sens et qui se ressemblent, je suis largué :aie:
Je ne comprends pas trop pourquoi il n'est pas plus comparé au webp


Car ils ne boxent pas dand la même catégorie. Je t'encourage à regarder l'infographie "Battle of the codecs" en bas de cette page:

https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg

Résumé: pour des contraintes de bande passante forte, avif c'est mieux et pour tout le reste, jxl. Donc si il ne devrait y avoir qu'un seul format utilisé, ça serait le jxl.
Modifié le 02/02/2024 à 14h01

cosmocat

Je ne comprends pas trop pourquoi il n'est pas plus comparé au webp


Car ils ne boxent pas dand la même catégorie. Je t'encourage à regarder l'infographie "Battle of the codecs" en bas de cette page:

https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg

Résumé: pour des contraintes de bande passante forte, avif c'est mieux et pour tout le reste, jxl. Donc si il ne devrait y avoir qu'un seul format utilisé, ça serait le jxl.
C'est justement ce genre de chose qui manque à l'article je trouve. Merci pour le lien !

cosmocat

Je ne comprends pas trop pourquoi il n'est pas plus comparé au webp


Car ils ne boxent pas dand la même catégorie. Je t'encourage à regarder l'infographie "Battle of the codecs" en bas de cette page:

https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg

Résumé: pour des contraintes de bande passante forte, avif c'est mieux et pour tout le reste, jxl. Donc si il ne devrait y avoir qu'un seul format utilisé, ça serait le jxl.
Merci pour le lien de l'article qui est très détaillé et instructif !

sylvaing

Merci pour le lien de l'article qui est très détaillé et instructif !
Je trouve aussi l'article très intéressant et je suis assez convaincu par le jxl.

Il faut savoir que cloudinary est impliqué dans le jxl (donc peut-être pas totalement objectifs - tout comme Google est partial vis-à-vis du webp ;)

https://cloudinary.com/blog/samsung-now-supports-dng-1-7-including-jpeg-xl
Jon, he’s the senior image researcher at Cloudinary (...) and is one the co-creators of the JPEG XL image format.

Oliverpool

Je trouve aussi l'article très intéressant et je suis assez convaincu par le jxl.

Il faut savoir que cloudinary est impliqué dans le jxl (donc peut-être pas totalement objectifs - tout comme Google est partial vis-à-vis du webp ;)

https://cloudinary.com/blog/samsung-now-supports-dng-1-7-including-jpeg-xl
Jon, he’s the senior image researcher at Cloudinary (...) and is one the co-creators of the JPEG XL image format.
Un nouvel super article de la part de Cloudinary.com avec un comparatif vraiment détaillé à l'occasion de la sorte de la v0.10 de jxl

https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front

on y apprend plein de trucs assez intéressants (je conseille fortement la lecture) :
* v0.10 ameliore la vitesse d'encodage et réduit l'utilisation mémoire (surtout en sans perte)
* confirmation que jxl est le meilleur format dans tous les cas (sauf 1 cas d'utilisation de niche pour avif) en vitesse, compression et fonctionnalités.
* Google pour vendre son avantage du webp vente un gain vis à vis du jpeg mais n'a pas utilisé le meilleur encodeur pour la comparaison et utilise aussi une métrique dépréciée qui fausse l'interprétation.
* (et surtout un truc qui m'a troué) un nouvel encodeur "jpegli" a été écrit par l'équipe jxl de Google en utilisant des avancées de jxl qui produit des jpeg de plus petite taille et plus rapidement que webp (en lossless évidemment). Donc le webp pert tout intérêt pour faire du lossy, il vaut mieux faire du bon vieux jpg avec ce nouvel encoder:

"More recently, the JPEG XL team at Google has built yet another JPEG encoder, jpegli, which is both faster and better than even mozjpeg. It is based on lessons learned from guetzli and libjxl, and offers a very attractive trade-off: it is very fast, compresses better than WebP and even high-speed AVIF, while still producing good old JPEG files that are supported everywhere."

Mon ressenti du seul point négatif de jxl: (peut-être) difficile de déterminer les bons paramètres d'encodage suivant l'utilisation cible.
Modifié le 23/03/2024 à 08h22

Historique des modifications :

Posté le 03/03/2024 à 00h23


Un nouvel super article de la part de Cloudinary.com avec un comparatif vraiment détaillé à l'occasion de la sorte de la v0.10 de jxl

https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front

on y apprend plein de trucs assez intéressants (je conseille fortement la lecture) :
* v0.10 ameliore la vitesse d'encodage et réduit l'utilisation mémoire (surtout en sans perte)
* confirmation que jxl est le meilleur format dans tous les cas (sauf 1 cas d'utilisation de niche pour avif) en vitesse, compression et fonctionnalités.
* Google pour vendre son avantage du webp vente un gain vis à vis du jpeg mais n'a pas utilisé le meilleur encodeur pour la comparaison et utilise aussi une métrique dépréciée qui fausse l'interprétation.
* (et surtout un truc qui m'a troué) un nouvel encodeur "jpegli" a été écrit par l'équipe jxl de Google en utilisant des avancées de jxl qui produit des jpeg de plus petite taille et plus rapidement que webp (en lossless évidemment). Donc le webp pert tout intérêt pour le lossless, il vaut mieux faire du bon vieux jpg avec ce nouvel encoder:

"More recently, the JPEG XL team at Google has built yet another JPEG encoder, jpegli, which is both faster and better than even mozjpeg. It is based on lessons learned from guetzli and libjxl, and offers a very attractive trade-off: it is very fast, compresses better than WebP and even high-speed AVIF, while still producing good old JPEG files that are supported everywhere."

Mon ressenti du seul point négatif de jxl: (peut-être) difficile de déterminer les bons paramètres d'encodage suivant l'utilisation cible.

cosmocat

Je ne comprends pas trop pourquoi il n'est pas plus comparé au webp


Car ils ne boxent pas dand la même catégorie. Je t'encourage à regarder l'infographie "Battle of the codecs" en bas de cette page:

https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg

Résumé: pour des contraintes de bande passante forte, avif c'est mieux et pour tout le reste, jxl. Donc si il ne devrait y avoir qu'un seul format utilisé, ça serait le jxl.
Si l'AVIF est bien le successeur du WebP, qu'est que vient faire le WebP2 dans toutes ces histoires (dont la dernière entrée date d'il y a ... 4 jours seulement)? avec pour intitulé:

"Webp2: experimental successor of the WebP image format"

Webp2

Merci à Cosmocat pour l'article sur cloudinary qui parle entre autre du WebP2 que je ne connaissais pas du tout.

:yes::incline:

NB: oui moi aussi j'étais un fan les mercredis en fin d'après-midi même si Cobra est et sera toujours indétrônable.
Modifié le 02/02/2024 à 21h09

Erwan123

Si l'AVIF est bien le successeur du WebP, qu'est que vient faire le WebP2 dans toutes ces histoires (dont la dernière entrée date d'il y a ... 4 jours seulement)? avec pour intitulé:

"Webp2: experimental successor of the WebP image format"

Webp2

Merci à Cosmocat pour l'article sur cloudinary qui parle entre autre du WebP2 que je ne connaissais pas du tout.

:yes::incline:

NB: oui moi aussi j'étais un fan les mercredis en fin d'après-midi même si Cobra est et sera toujours indétrônable.
Faut lire la suite :
WebP 2 is an experimental image codec based on WebP. WebP 2 will not be released as an image format but is used as a playground for image compression experiments.

Cqoicebordel

Faut lire la suite :
WebP 2 is an experimental image codec based on WebP. WebP 2 will not be released as an image format but is used as a playground for image compression experiments.
Bon, pas compris le sens de mon commentaire, et bien sûr j'avais lu tout l'article dont cette ligne.

Ma question était plutôt, vu que Google a participé à l'AV1 et donc à l'AVIF, qui sont les descendants du WebM (VP9) et du WebP, pourquoi essayer de faire renaître un WebP2 maintenant quand l'AVIF n'en est juste qu'à ses premiers balbutiements ? :ooo:

C'est plus clair là ? :D
Modifié le 03/02/2024 à 01h48

Erwan123

Bon, pas compris le sens de mon commentaire, et bien sûr j'avais lu tout l'article dont cette ligne.

Ma question était plutôt, vu que Google a participé à l'AV1 et donc à l'AVIF, qui sont les descendants du WebM (VP9) et du WebP, pourquoi essayer de faire renaître un WebP2 maintenant quand l'AVIF n'en est juste qu'à ses premiers balbutiements ? :ooo:

C'est plus clair là ? :D
Parce que c'est pas le cas.
Le but ici est de tester pleins de choses pour pouvoir faire évoluer la lib WebM : on peut faire évoluer la lib sans changer le format binaire, et donc être rétrocompatible.
Bref, c'est pas un nouveau format d'image, c'est juste destiné à faire des tests.

Cqoicebordel

Parce que c'est pas le cas.
Le but ici est de tester pleins de choses pour pouvoir faire évoluer la lib WebM : on peut faire évoluer la lib sans changer le format binaire, et donc être rétrocompatible.
Bref, c'est pas un nouveau format d'image, c'est juste destiné à faire des tests.
Ok ! :yes: It was just a bit confusing ... pretty confusing actually. :fou:
Une bonne comparaison ici : https://jakearchibald.com/2020/avif-has-landed/

benjarobin

Une bonne comparaison ici : https://jakearchibald.com/2020/avif-has-landed/
Ce lien est donné dans la news.:windu:
Alors plusieurs choses. Non, c'est pas à comparer à webp, parce que en fait, c'est son successeur :
Y'a qu'un seul grand combat, qui se décline en plusieurs sous combats : les formats à licence vs. les formats open-source.
Ainsi, le WebM était sensé être le compétiteur de H.264 (qui est payant). Google, en faisant le format s'est rendu compte que dans le format vidéo WebM, il y a des images clés (comme dans la majorité des formats vidéos), et que ces images clés sont compressées. Or, dans ce format là, la méthode de compression était pas mal, donc ils ont sortit WebP, qui n'est rien d'autre que le format des keyframes de WebM.

Après, la nouvelle génération de codecs est arrivé. HEVC (H.265) vs. AV1. Le premier payant, le second open source.
Mais ce coup ci, les deux ont décidé de faire comme pour WebP, et d'utiliser le format de leurs keyframes respectives pour faire des formats d'images, respectivement HEIC pour HEVC, et AVIF (qui est bien le format d'image) pour AV1.
(note, HEIC, c'est le codec, HEIF c'est le conteneur)

Du coup, comparer AVIF à WebP, ça a du sens uniquement dans le sens d'un changelog, pour voir comment ça a été amélioré. Mais pour comparer à la concurrence, faut regarder HEIC.

J'espère que ça éclaire le débat :)

EDIT : je m'étais planté entre HEIC et HEIF. J'ai corrigé (ça change pas grand chose, l'un est le codec, l'autre est le conteneur)
Modifié le 02/02/2024 à 16h55

Cqoicebordel

Alors plusieurs choses. Non, c'est pas à comparer à webp, parce que en fait, c'est son successeur :
Y'a qu'un seul grand combat, qui se décline en plusieurs sous combats : les formats à licence vs. les formats open-source.
Ainsi, le WebM était sensé être le compétiteur de H.264 (qui est payant). Google, en faisant le format s'est rendu compte que dans le format vidéo WebM, il y a des images clés (comme dans la majorité des formats vidéos), et que ces images clés sont compressées. Or, dans ce format là, la méthode de compression était pas mal, donc ils ont sortit WebP, qui n'est rien d'autre que le format des keyframes de WebM.

Après, la nouvelle génération de codecs est arrivé. HEVC (H.265) vs. AV1. Le premier payant, le second open source.
Mais ce coup ci, les deux ont décidé de faire comme pour WebP, et d'utiliser le format de leurs keyframes respectives pour faire des formats d'images, respectivement HEIC pour HEVC, et AVIF (qui est bien le format d'image) pour AV1.
(note, HEIC, c'est le codec, HEIF c'est le conteneur)

Du coup, comparer AVIF à WebP, ça a du sens uniquement dans le sens d'un changelog, pour voir comment ça a été amélioré. Mais pour comparer à la concurrence, faut regarder HEIC.

J'espère que ça éclaire le débat :)

EDIT : je m'étais planté entre HEIC et HEIF. J'ai corrigé (ça change pas grand chose, l'un est le codec, l'autre est le conteneur)
Très clair ! :yes::incline:
D’une part, il supporte plusieurs espaces de couleur, dont le SDR classique bien sûr, ainsi que le HDR. L’indication de l’espace peut se faire par profil CICP ou ICC.

D’autre part, il prend en charge les profondeurs de couleur de 8, 10 et 12 bits, ainsi que les sous-échantillonnages 4:2:0, 4:2:2 et 4:4:4.

Est ce que vous pourrez écrire, un jour, un article pour expliquer toute la terminologie qui entoure les images ? Si vous l'avez déjà fait et que je suis passé à côté, j'en suis désolé :incline::incline:
Modifié le 02/02/2024 à 12h18
Même chose. À chaque fois que j'ouvre une image dans GIMP et qu'il me demande si je veux conserver le profil de couleurs ou le convertir, je ne sais pas quoi mettre :transpi:
Alors version ultra courte :
Les espaces de couleurs : ça représente l'ensemble des couleurs que l'image/video peut représenter. Parce qu si on utilise du RGB classique (rouge vert bleu), sur 8 bit, ça code pleins de couleurs (24 millions), mais elles sont réparties équitablement. Or, les yeux humains ne voient pas équitablement (et voient notamment plus de verts). Au delà même de ça, les capteurs des caméras, et les écrans, peuvent représenter fidèlement qu'une partie ou différemment certaines couleurs. Du coup, on ajoute les espaces de couleurs à chaque fichier pour que l'outil affiche le plus fidèlement possible les couleurs du dit fichier.
Quelques espaces colorimétriques, autre exemple, avec une meilleure légende, et ces espaces appliqués aux télés.
CiCP ou ICC sont des formats de profils colorimétriques.

Profondeurs de couleurs : utilisation de 8, 10, ou 12 bits pour qualifier une couleurs, en utilisant RGB. Ainsi on a accès à 16 millions de couleurs (2^(3*8)), ou 1 milliard, ou 69 milliards (voir le post de sebmil pour le détail). Plus de couleurs, c'est bien, surtout quand y'a des aplats de couleurs presque unis : quand dans un film compressé, y'a un plan où on voit le ciel, on voit souvent des "bandes". C'est un signe que pas assez de couleurs ont été utilisé. Souvent, 10b suffisent à corriger pas mal de ces problèmes. Exemple

Sous-échantillonnage : ça, ça concerne le format YUV. YUV, c'est un autre format que RGB, et c'est Y=Luminance et UV=chroma (couleur voir cet exemple). Or, on s'est rendu compte que les yeux voyaient beaucoup plus un changement de lumière qu'un changement de couleurs.Donc, au lieu de passer toutes les infos de manières égalitaires (4:4:4), bien souvent, dans les images/vidéos compressées, on va mettre une valeur entière de la couleurs que pour 2 ou 4 valeurs de luma (4:2:2, 4:2:0). Ces changement peuvent se voir, mais dans une vidéo, en général, on voit pas vraiment le changement. Image d'illustration


Bien sûr ces explications sont limitées par leurs tailles. Mais ça donne un bon point de départ mental :)
Modifié le 02/02/2024 à 21h03

Cqoicebordel

Alors version ultra courte :
Les espaces de couleurs : ça représente l'ensemble des couleurs que l'image/video peut représenter. Parce qu si on utilise du RGB classique (rouge vert bleu), sur 8 bit, ça code pleins de couleurs (24 millions), mais elles sont réparties équitablement. Or, les yeux humains ne voient pas équitablement (et voient notamment plus de verts). Au delà même de ça, les capteurs des caméras, et les écrans, peuvent représenter fidèlement qu'une partie ou différemment certaines couleurs. Du coup, on ajoute les espaces de couleurs à chaque fichier pour que l'outil affiche le plus fidèlement possible les couleurs du dit fichier.
Quelques espaces colorimétriques, autre exemple, avec une meilleure légende, et ces espaces appliqués aux télés.
CiCP ou ICC sont des formats de profils colorimétriques.

Profondeurs de couleurs : utilisation de 8, 10, ou 12 bits pour qualifier une couleurs, en utilisant RGB. Ainsi on a accès à 16 millions de couleurs (2^(3*8)), ou 1 milliard, ou 69 milliards (voir le post de sebmil pour le détail). Plus de couleurs, c'est bien, surtout quand y'a des aplats de couleurs presque unis : quand dans un film compressé, y'a un plan où on voit le ciel, on voit souvent des "bandes". C'est un signe que pas assez de couleurs ont été utilisé. Souvent, 10b suffisent à corriger pas mal de ces problèmes. Exemple

Sous-échantillonnage : ça, ça concerne le format YUV. YUV, c'est un autre format que RGB, et c'est Y=Luminance et UV=chroma (couleur voir cet exemple). Or, on s'est rendu compte que les yeux voyaient beaucoup plus un changement de lumière qu'un changement de couleurs.Donc, au lieu de passer toutes les infos de manières égalitaires (4:4:4), bien souvent, dans les images/vidéos compressées, on va mettre une valeur entière de la couleurs que pour 2 ou 4 valeurs de luma (4:2:2, 4:2:0). Ces changement peuvent se voir, mais dans une vidéo, en général, on voit pas vraiment le changement. Image d'illustration


Bien sûr ces explications sont limitées par leurs tailles. Mais ça donne un bon point de départ mental :)
Merci pour la description détaillée :)
Juste une petite correction : le nombre de couleurs disponibles (en RGB) est donné par le chiffre 2 élevé au nombre total de bits disponibles:
* 8 bits par couleur = 24 bits au total => 2^24 = 16.8 millions de couleur
* 10 bits par couleur = 30 bits au total => 2 ^30 = 1 milliard de couleurs
* 12 bits par couleur = 36 bits au total => 2 ^36 = 69 milliards ce couleurs
La différence de rendu (ou les possibilités de retouche) est donc bien plus prononcée.

sebmil

Merci pour la description détaillée :)
Juste une petite correction : le nombre de couleurs disponibles (en RGB) est donné par le chiffre 2 élevé au nombre total de bits disponibles:
* 8 bits par couleur = 24 bits au total => 2^24 = 16.8 millions de couleur
* 10 bits par couleur = 30 bits au total => 2 ^30 = 1 milliard de couleurs
* 12 bits par couleur = 36 bits au total => 2 ^36 = 69 milliards ce couleurs
La différence de rendu (ou les possibilités de retouche) est donc bien plus prononcée.
Ah oui, j'ai complètement pété un cable là dessus. Merci de la correction.
Je vais corriger mon post pour que ce soit plus clair.

A noter aussi que y'a aussi potentiellement un canal alpha pour la transparence, qui multiplie le nombre de "couleurs" mais c'est accessoire.
Mais il n’est guère présent sur le web.

Et sur Next vous utilisez quel format ? Flock publie ses dessin dans ce format ?:windu:
Perso, je me poserais la question de son utilisation par les régies publicitaires, lesquelles bombardent tous les utilisateurs dépourvus d'antipubs. Ou future utilisation, maintenant qu'il est supporté par Edge 😅
Illustrer à chaud et en AVIF?
L'image qui illustre cet article est en webp, au moins pour mon firefox.
Les vignettes des articles liés en webp si c'est une illustration de Floc, jpg pour les photos
Les icones de profils jpg ou png (le fichier fourni je suppose)
Les logos en svg
Les emoji du site en gif.

Pas vu d'Avif ou de jxl, mais j'ai pas non plus regarder toute les images du site.
Dans l'illustration, Flock a oublié le meilleur format de tous les temps.

Le BMP.

On a de la bande passante, faut que ça serve bordel ! *

* Toute ressemblance avec des excuses de dev qui compensent une mauvaise optimisation par l'ajout de +24GB de RAM sur un serveur ne serait que purement fortuite et involontaire.
C'est clair que le BMP, ça envoie du lourd, du très très lourd... il boxe d'ailleurs dans la même catégorie que son petit frère audiophile, le .WAV

:D
Modifié le 02/02/2024 à 20h16
intéressant j'en avait pas entendu parler
pourriez vous faire une comparaison d'une image raw puis la passer en jpeg, webp et avif avec et sans perte pour donner une idée des ratios et de quoi on parle car si ça gagne quelques pourcent versus webp je ne pense pas qu'il sera utilisé vu que plein de site de vente en ligne ont déjà migré en webp.
Viens de tester, ce format n'est pas proposé en export depuis Photoshop... Pourquoi ? (On reste sur le trio GIF, JPEG, PNG)
Il n'est en effet juste pas implémenté, c'est "en considération", selon cette réponse le 13 septembre 2021.

Il y a des plugins qui sont disponible en attendant. Après ça n'est visible que dans l'option "Enregistrer sous..", comme le WebP.
Firefox est-il compatible AVIF ?

Édit > Oui : En octobre 2021, Mozilla Firefox 93 est publié avec le support complet d'AVIF9.

Vu sur la page Wikipedia dédiée.
Modifié le 02/02/2024 à 13h54
C'est même écrit dans l'article : "Pour Firefox, ce fut dans la mouture 93 en octobre 2021."
:windu:
On notera que l'illustration de l'article est en WebP, et les vignettes des contenus connexes en JPEG.
Ils ont pensé aux 3 utilisateurs de Edge !
On sent que la blessure de Flock était encore un peu AVIF.




Maintenant je m'en vais lire la news.
Pas mal, pas mal !! :mdr2:
Essai qui m'a refroidi: compresser une photo 75% depuis Darktable 4.2.2 (libheif1 1.16.2) sur un Ryzen 5 3600 (6 cœurs, 12 threads) prend:
- en 8 bits, en 2748x1835: 1 minute (2 min de CPU, sur 2 cœurs donc) .
- en 8 bits, en 5496x3670: 1 min 9s (8 min 20s de CPU).
- en 12 bits, en 5496x3670: 1 min 27s (10 min 10s de CPU)
- en 8 bits, en 1374x917: 27s
Pour exporter une collection de photo, il faudra compter un peu temps… Je croirais retourner à l'époque où compresser des vidéos prenait des heures.

Mise-à-jour: j'ai essayé avec avifenc (ligne de commande) et ça prend 2s environ. Peut-être que c'est l'intégration avec Darktable qui pose problème…
Modifié le 03/02/2024 à 23h20
Fermer