Convertir AVIF en WebP

Quelque chose dans votre chaîne d’outils accepte WebP et n’a jamais entendu parler d’AVIF. C’est la raison, et c’en est une vraie : un thème WordPress, un outil de dépôt de CMS avec une liste MIME codée en dur, un cahier des charges publicitaire écrit en 2021, une chaîne d’actifs d’application mobile, un plugin de générateur de site statique qui redimensionne ce qu’il reconnaît et laisse passer le reste intact. WebP est livré depuis 2010 et AVIF depuis 2019, et neuf ans est à peu près le retard moyen d’un logiciel de traitement d’images.

Si c’est votre situation, cette page est la solution et le coût est faible. Si ce n’est pas le cas — si la raison est la conviction que WebP est plus sûr, mieux supporté ou plus standard — alors lisez la section suivante avant de convertir, parce que vous paieriez un passage avec pertes et quelques octets supplémentaires pour rien du tout. Le test est facile à appliquer : nommez le logiciel précis qui a rejeté l’AVIF. Si vous ne le pouvez pas, la conversion n’est probablement pas ce qu’il vous faut.

Tous les navigateurs actuels lisent les deux formats. C’est l’idée fausse la plus courante à propos de cette conversion, et elle vient des années où elle était vraie : la prise en charge d’AVIF est arrivée plusieurs années après celle de WebP, donc beaucoup de conseils écrits entre les deux sont encore en ligne et disent encore que WebP est le choix moderne sûr.

Aucun n’est sûr hors d’un navigateur. Envoyez un WebP par courriel et envoyez un AVIF par courriel et vous avez exactement le même problème — les visualiseurs d’image, les galeries de téléphone plus anciennes, les clients de messagerie et les services d’impression sont irréguliers sur les deux. Si le fichier doit survivre au contact du logiciel de quelqu’un d’autre plutôt que du navigateur de quelqu’un d’autre, la conversion honnête est en JPG ou PNG, et non latérale entre deux formats web. Le face à face entre les deux — où chacun gagne réellement, et ce que coûte l’encodage — est exposé sur la page de comparaison WebP et AVIF de ce site, qui est la page à lire si vous êtes encore en train de choisir plutôt que de convertir.

Les deux sont des images fixes d’un codec vidéo : WebP est une image de VP8, publié par Google en 2010 ; AVIF est une image d’AV1, publié par l’Alliance for Open Media en 2019. Convertir entre les deux veut dire décoder un encodage avec pertes et en produire un autre avec un modèle plus ancien et différent de ce qui compte dans une image.

Le second encodeur ne peut pas savoir ce que le premier a écarté, donc il traite les dégradés lissés et la texture aplatie d’AVIF comme s’ils étaient la scène d’origine et les compresse à nouveau. Le dommage à la qualité par défaut de 82 est modeste et il n’est pas nul. Là où il apparaît en premier, c’est le matériau où AVIF est meilleur et VP8 plus faible : les ciels, les dégradés, les détails d’ombre et les grandes zones plates qu’AVIF avait gardés propres et que WebP va bander.

C’est la limite stricte que les gens rencontrent sans s’y attendre. Un WebP ne peut pas faire plus de 16 383 pixels de large ou de haut — c’est une propriété du format, et non d’un encodeur particulier — alors qu’un AVIF peut atteindre 65 536 d’un côté. Aller d’AVIF à WebP est donc la seule direction ici où la cible peut être trop petite pour contenir la source.

Ce n’est pas une limite abstraite. Un panorama assemblé, une carte scannée, une longue capture d’écran d’une page entière ou une image de produit en tuiles peuvent toutes dépasser 16 383 pixels confortablement. Si la vôtre le fait, réglez le contrôle de largeur maximale avant de convertir, ce qui redimensionne dans la même passe que l’encodage. Redimensionner délibérément est bien meilleur que de découvrir le plafond au moment où le fichier est nécessaire, et c’est l’un des rares cas du site où le format cible, plutôt que la source, est ce qui limite l’image.

AVIF peut décrire jusqu’à douze bits par canal et des espaces colorimétriques étendus. WebP est à huit bits dans un gamut standard, et c’est un plafond dans la spécification plutôt qu’un réglage. Tout ce que l’AVIF portait au-dessus de huit bits n’arrive pas.

Pour des images venues d’une page web, cela ne change rien, parce qu’elles étaient à huit bits quand elles ont été servies. Cela compte pour un AVIF exporté depuis un appareil photo moderne ou une chaîne d’édition, où la précision supplémentaire était la raison pour laquelle AVIF avait été choisi : le convertir en WebP jette précisément la propriété pour laquelle le format avait été retenu. Dans ce cas, la conversion est une rétrogradation avec un but, et il vaut la peine d’être sûr que le but est réel avant qu’une bibliothèque entière n’y passe, puisque rien ne récupère la précision ensuite.

Sur du contenu photographique AVIF est typiquement 20 à 30 pour cent plus petit qu’un WebP comparable, donc le résultat habituel de cette conversion est un fichier plus gros. Si vous convertissez parce qu’une étape de build a besoin de WebP, c’est un coût de poids de page à connaître et à peser contre ce que cette étape de build vous apporte.

Sur du graphisme d’interface plat, des icônes, des captures d’écran et du trait, l’ordre s’inverse, et un WebP peut sortir plus petit que l’AVIF dont il vient. Cela est mesuré sur la page de comparaison WebP et AVIF de ce site, où AVIF était deux fois plus petit sur une photo et notablement plus grand sur de la couleur plate aux bords nets. Convertissez deux ou trois fichiers représentatifs à vous et comparez les nombres d’octets avant de décider quoi que ce soit sur une bibliothèque entière.

L’encodage lent est le mode d’échec que le registre liste contre AVIF, et c’est la différence pratique entre les deux. AV1 cherche beaucoup plus de structure qu’il peut décrire de façon compacte que VP8 — souvent d’un ordre de grandeur plus long pour la même image — ce qui explique les fichiers plus petits et pourquoi un grand AVIF peut prendre plusieurs secondes même sur une machine rapide.

Sur cette page vous obtenez la moitié économique de cet échange. Décoder un AVIF est rapide et encoder un WebP est rapide, donc un lot de quelques centaines d’images se termine dans le temps qu’il faudrait pour encoder un seul AVIF. Pour quiconque convertit une bibliothèque plutôt qu’un seul fichier, c’est la direction de conversion qui est confortable à lancer dans un navigateur — l’inverse, transformer un dossier de WebP en AVIF, est celle qui rend le ventilateur d’un ordinateur portable audible.

Les deux formats peuvent porter de l’animation — AVIF par ses séquences AV1, WebP depuis qu’il a gagné la prise en charge de l’animation — donc en principe un AVIF animé pourrait devenir un WebP animé. Ce convertisseur ne le fait pas. Il décode une image et écrit une image, donc ce que vous obtenez en retour est un WebP fixe de la première image.

C’est dit ici plutôt que découvert après, parce qu’un convertisseur qui laisse silencieusement tomber neuf dixièmes d’un fichier est la défaillance que ce site s’attache à ne pas commettre. Si ce que vous avez bouge réellement et doit continuer à bouger, aucun de ces formats n’est la réponse et cette page non plus : un MP4 produit à partir de ce qui a créé l’animation est plus petit que tout format d’image animée pour le même contenu et passe partout.

La transparence survit. Les deux formats portent un vrai canal alpha, donc les détourages, les bords doux et les superpositions semi-transparentes passent avec la même précision qu’ils avaient, et aucune couleur de fond n’a à être choisie. C’est l’une des rares choses de la paire qui ne coûte rien.

Une asymétrie mérite d’être connue : le mode sans perte de WebP est excellent et largement supporté par les outils, alors que celui d’AVIF existe et est moins bien géré. Cette page encode un WebP avec pertes, parce que c’est ce que le contrôle de qualité veut dire et parce qu’un AVIF est presque toujours déjà avec pertes — écrire un WebP sans perte d’une image avec pertes produit un fichier bien plus gros qui n’est pas plus fidèle à la scène d’origine. Si vous avez besoin d’une copie de travail véritablement sans perte, PNG est la cible à utiliser.

Si les images sont pour vos propres pages, convertir en s’éloignant d’AVIF est rarement la bonne réponse structurelle. Un élément picture avec une source AVIF en premier, une source WebP en deuxième et un repli JPG en dessous permet à chaque navigateur de prendre le meilleur fichier qu’il sait lire, n’a besoin d’aucune détection ni d’aucune maintenance, et signifie que personne n’a à choisir.

La raison de convertir plutôt, c’est que quelque chose au milieu ne peut pas être amené à émettre deux fichiers. C’est assez courant — beaucoup de plateformes acceptent une seule image par actif — et c’est une vraie contrainte plutôt qu’un manque de courage. Là où cela s’applique, convertissez, gardez l’AVIF, et revenez quand la plateforme aura rattrapé son retard. Tout cela tourne dans votre navigateur ici, donc relancer le lot plus tard ne coûte rien d’autre que du temps.