Basé sur l'AV1, le format d'images AVIF va apparaitre sur Firefox et Chrome
Personne n'était vraiment demandeur d'un énième nouveau format d'image, et pourtant le robinet reste toujours ouvert. L'AVIF, pour AV1 Image File Format, est logiquement l'équivalent du format vidéo AV1 pour l'image fixe. Ses premières spécifications ont été publiées en février 2019, mais son développement remonte au début de l'année précédente (lire : Un nouveau candidat à la succession du JPEG se dessine avec l'AV1).
L'AVIF est le fruit des travaux de l'Alliance for Open Media (AOMedia), qui est aussi à l'origine de l'AV1. L'idée, c'est tout simplement d'utiliser les algorithmes de compression du format vidéo pour réduire le poids des images (moitié moins lourd que le JPG) ; autre avantage, l'AVIF est open-source, pas besoin de contracter de licences pour s'en servir1.
Netflix prend en charge l'AVIF depuis la fin 2018, avant même la mise en ligne des spécifications techniques. Le service de streaming a été rapidement suivi par VLC, Gimp et d'autres logiciels. Windows supporte le format dans Windows 10 depuis une mise à jour remontant à mai 2019 (il faut cependant télécharger une extension gratuite).
Mais ce sont les navigateurs web qui décideront du succès ou de l'échec de l'AVIF. Mozilla teste le format dans Firefox depuis au moins le début de l'année, et sa prise en charge aurait dû être effective avec Firefox 76, en mai. Mais la fondation a pris du retard. Le support de l'AVIF est toujours expérimental ; il pourrait être proposé à tous les utilisateurs fin août, avec Firefox 80.
Chrome aussi est sur le pont, avec une prise en charge qui interviendra le mois prochain avec la version 85 du navigateur. Comme des dominos, les autres butineurs basés sur Chromium tomberont à la suite : Edge, Opera, Vivaldi et Brave supporteront l'AVIF d'ici la fin de l'année.
Et pour Safari ? Difficile à dire, mais Apple fait partie de l'Alliance for Open Media depuis 2018, en compagnie de Google, Amazon, Facebook, Microsoft, Samsung, Adobe, etc.
- Images de comparaison tirées de ce papier de Netflix.
-
Comme toujours dans l'épuisante histoire des codecs, les choses sont plus compliquées : une entreprise, Sisvel, s'est mis en tête de réclamer des royalties car l'AV1 exploiterait ses brevets (lire : La guerre des codecs vidéo relancée par le MPEG-5 EVC). ↩︎
Un enieme remplacement du jpg qui ne prendra pas...
Votre article est sympa mais il manque d’informations : quel intérêt de changer de format ? Vous montrez des images sans préciser leur poids comment voulez-vous qu’on puisse juger de l’intérêt de tel ou tel format sans cette info.
En plus, dans votre exemple c’est bizarre car même la couleur est impactée par la compression ? une perte dans la définition (ou d'information pour le jpeg qui est déjà un format destructif) oui, mais un changement de couleur ? c’est limite non ?
En fait, il manque dans votre article l’image d’origine non compressée pour pouvoir juger !
@TheUMan
Il faut surtout que ton navigateur ou l’appli sache interpréter le format sinon ça sera bizarre. C’est pareil avec le webp qui peut paraître très fade quand pas supporté mais environ 50% plus léger qu’un jpg.
Perso je trouve qu’il y a trop de prétendants et qu’aucun ne perce réellement.
@TheUMan
À un niveau de compression élevé (typiquement donc sur internet, où la bande passante est cruciale), le JPEG impacte la précision des couleurs et affiche des artefacts de compression. Si tu as déjà travaillé sur des images dont les couleurs sont précises (notamment sur un espace colorimétrique étendu style P3 – et ça sera encore plus visible quand on arrivera au rec.2020 et au prophoto), tu peux constater très rapidement sur un bon écran (sans aller sur des moniteurs professionnels) que la compression JPEG altère bel et bien les couleurs (et va piocher dans une couleur avoisinante, ce qui ne va pas devenir immonde mais clairement pas celle voulue).
Pour les exemples montrés, il manque un élément concret qui est l’algorithme de compression (car il y a plusieurs méthodes de compression jpeg) et souvent dans des comparatifs, on utilise de vieux algorithmes pas très performants pour accentuer la différence.
Cela dit, dans ces cas de compression extrême, l’AV1 (et son pendant « statique ») sont réellement plus performants, l’AV1 s’arrange avec la réalité pour recréer des données manquantes et permet donc d’éviter le moirage et le « macroblocking » (les gros carrés moches), qui sont totalement visibles sans avoir l’image de référence.
Sur de la vidéo, l’AV1 n’est pas très fidèle, ce n’est pas son but, mais il permet de ne pas montrer la compression en « redessinant » les lignes, les dégradés… et le résultat est vraiment bluffant, sans l’image de référence on ne se rend pas compte de la compression. Par contre, ce n’est pas une fidélité à toute épreuve et c’est important de garder ça à l’esprit : l’AV1 reste un format destiné aux situations extrêmes (que l’on rencontre au quotidien sur internet jusque sur les vidéos YouTube au débit totalement inadapté à la résolution restituée), et dans ces cas précis, le jpeg tout comme le h264/h265/vp9 sont inadaptés.
Par contre (dans l’état actuel du codec), l’AV1 n’apporte aucun bénéfice lorsqu’il s’agit de fichiers avec une compression faible, et pire, son mode de fonctionnement gomme les aspérités (tel un réducteur de bruit très agressif) et quand par exemple il est en présence de grain pellicule, le supprime et en applique un faux pour donner l’impression de grain. C’est un format de compression qui est plus pertinent que ses « concurrents » dans certaines situations, et inadapté (voire moins performant) dans d’autres.
En tout cas, il semble difficile de remettre en question l’apport de l’AV1 pour de la vidéo ou de l’image fixe très compressée par rapport aux formats actuels (h264, h265, vp9, jpeg), qui sont omniprésents sur internet. On gagne en précision des contours, on perd en crénelage (pixelisation), en moirage (les halos sur un dégradé), et tout ça sur des fichiers encore plus compressés (donc moins lourds). C’est une avancée non négligeable.
@Yohmi
merci.
@Yohmi
Top ! Un commentaire beaucoup plus intéressant que l’article qu’il commente, c’est rare !
@TheUMan
Je suis d'accord, l'article ne creuse pas du tout le sujet. Merci d'ailleurs à @Yohmi pour ses explications 👍🏻
Dommage qu'on n'ait pas le poids des photos exemple dans l'article.
Et qu'en est-il de la différence avec le format de Google webP ?
Tu as des exemples ici : https://webp-test-1500.b-cdn.net
Deux encodeurs JPEG, WebP et AVIF. Les images sont encodées de manière à avoir un SSIM à peu près équivalent entre chaque version. cjpeg sert de poids de référence.
P.S. : l'image Kodim 22 est celle de la grange qu'on peut voir dans l'article.
C'est un sujet qui m'intéresse au plus haut point car j'ai besoin de comprimer le mieux possible mes mages pour les incorporer dans mes softs pour android, afin de ne pas dépasser la limite de 100 Mo imposée par google.
Quand on a des milliers de photos dans le même soft, la moindre amélioration de qualité entre 2 codecs peut faire la différence.
Problème : j'ai essayé tout ce qui se fait de neuf et je peux assurer que je n'ai jamais trouvé mieux que le jpeg, même et surtout pour des taux de compression élevés.
À chaque fois le nouveau "remplaçant" promet monts et merveilles, et à chaque fois c'est très médiocre.
Si seulement ça existait, ce format miracle !
Il arrive et s'appelle JPEG XL. https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs
Gros avantage : ça n'est pas un format dérivé d'un format vidéo, ce qui évite les problèmes typiques de lissage (ou "d'aspect plastique") de WebP et, dans une moindre mesure, d'AVIF.
Il n'a pas les problèmes de blocking et de ringing de JPEG. Il permet le chargement progressif. Il permet le lossless. Il est très rapide à encoder/décoder. Et j'en passe.
Chose excellente : il est permet aussi de réduire le poids des JPEG existants d'environ 20%, sans aucune altération visuelle. Tu peux voir facilement tester le gain avec tes images sur https://brunsli.dev (qui encode directement dans le navigateur).
Pour des tests plus poussés, il faut compiler https://github.com/google/brunsli (qui permet le réencodage en JPEG XL, mais aussi le décodage des JPEG XL produits en JPEG).
Donc même si tu n'aimais pas le rendu du "vrai" JPEG XL qui permet des gains plus importants, tu pourrais très bien utiliser ton encodeur actuel JPEG, ne faire qu'un passage à JPEG XL sans altération, et gagner quand même 20%.
Merci je vais regarder ça.