Convertir WebP en AVIF

WebP est sorti de Google en 2010, dérivé du VP8 vidéo. AVIF est sorti de l’Alliance for Open Media en 2019, dérivé de l’AV1 intra-image. Les deux sont des formats d’image avec perte, tous deux liés à un codec vidéo, tous deux gratuits et sans brevet, tous deux plus efficaces que le JPEG. La migration entre les deux est la question « pourquoi changer » et la réponse est presque toujours « un site ou un outil l’a exigé ».

Pour les pipelines modernes qui ont explicitement migré vers AVIF, la conversion sert le temps que la migration amont — chez les fournisseurs de contenu, les CDN, les outils de design — rende la conversion inutile. Pour un cas isolé où l’AVIF est le format requis et le WebP est ce que vous avez, c’est une conversion honnête qui sort ce qui est attendu.

À qualité visible égale, un fichier AVIF pèse en général 20 à 30 pour cent de moins qu’un WebP, et 30 à 50 pour cent de moins qu’un JPEG. La différence vient de l’AV1, qui est un codec plus récent avec des outils de prédiction plus performants et un meilleur compromis débit-distorsion sur les images photographiques.

C’est ce que la conversion vous achète : un fichier plus petit pour la même qualité perçue. Pour un site qui sert des milliers d’images, c’est un gain de bande passante substantiel. Pour un fichier isolé qui va voyager une fois, c’est aussi un gain, mais un gain d’une seule fois et qui ne se capitalise pas. La migration est intéressante quand le pipeline aval a déjà adopté l’AVIF, et neutre quand il ne l’a pas fait et qu’une re-conversion attend de toute façon.

Les deux formats portent un canal alpha en première classe, et la conversion préserve la transparence d’un WebP transparent vers un AVIF transparent sans l’aplatir. Un logo avec un fond transparent, une photo de produit détourée, un pictogramme avec une ombre douce arrivent en AVIF exactement comme ils étaient.

C’est l’une des raisons pour lesquelles l’AVIF est un bon remplaçant du WebP pour les assets UI et les éléments d’interface : la transparence est aussi bien supportée, et la taille du fichier est plus petite pour une qualité perçue identique. Pour un format qui ne supporte pas l’alpha — JPG, par exemple —, la conversion perdrait la transparence, et c’est explicite sur la page de cette conversion-là. Ici, elle survit.

AVIF supporte l’espace colorimétrique Rec. 2020 et le HDR, là où WebP supporte jusqu’à Rec. 709 et le SDR. Une photo prise avec un téléphone récent qui produit du HDR arrive en AVIF avec sa large gamme dynamique préservée, et en WebP avec une gamme tronquée.

Pour une capture d’écran, la différence est invisible : un écran d’ordinateur est en SDR. Pour une photographie qui a été capturée en HDR, c’est important, et l’AVIF est le format qui transporte la large gamme sans la réduire. La conversion préserve ce qui est dans la source, et si le WebP avait déjà réduit la palette, l’AVIF écrit par cette conversion ne la ré-étend pas — ce qui se perd à l’encodage ne se récupère pas au transcodage.

AVIF a un support logiciel étroit, et c’est l’angle à vérifier avant de convertir. Chrome et Edge le lisent depuis 2020 environ, Firefox depuis 2021, Safari depuis la version 16 de 2022. macOS l’a ajouté dans Ventura en 2022. Les navigateurs d’images, les visionneuses, les outils de retouche : support variable, et l’âge du logiciel qui lira le fichier est ce qui décide.

Pour un site web moderne servi à un navigateur récent, c’est sans problème. Pour un téléchargement destiné à être ouvert dans une visionneuse d’images ou un client de messagerie, c’est un pari, et le pari est perdant contre le WebP. La destination doit être capable d’ouvrir l’AVIF avant que la conversion serve à quelque chose ; pour une cible qui ne peut pas, gardez le WebP ou convertissez en JPG.

Le mode sans perte d’AVIF existe mais n’est pas ce que cette conversion utilise. La sortie est avec perte à la qualité standard, et c’est une seconde génération de compression sur une image qui a déjà été compressée une fois. La qualité visible s’améliore en général, parce que l’AV1 intra est meilleur que le VP8 intra, mais la compression est toujours avec perte, et deux passages avec perte successifs sont ce qu’une chaîne de retouche soignée évite.

Pour un asset qui doit être retravaillé par la suite, partez de la source originale plutôt que du WebP déjà compressé. Pour un asset terminé qui doit être stocké ou livré, le WebP vers AVIF est une conversion raisonnable et la perte supplémentaire est en général invisible au réglage par défaut.

EXIF, GPS, XMP, IPTC et le profil ICC sont tous deux perdus dans la conversion, parce que les pixels sont décodés puis ré-encodés sans que rien de ce qui les accompagnait traverse. Un WebP qui portait des coordonnées GPS les perd, et c’est explicite dans le code source : c’est par construction, et il n’y a pas d’option pour l’éviter.

Pour une image sans métadonnées — une capture d’écran, un asset UI, un pictogramme — c’est sans importance. Pour une photographie prise avec un téléphone et qui portait des informations de localisation, c’est une perte réelle, et le bon outil est la page de suppression des métadonnées sur le WebP source si la destination ne doit rien recevoir, ou de garder le WebP si elle doit recevoir les métadonnées.

Déposez jusqu’à cent WebP en une seule passe, et chacun sort en AVIF avec sa propre progression. Quand plus d’un est terminé, l’ensemble est disponible en ZIP. C’est le cas ordinaire d’une migration de site où des dizaines ou des centaines d’images doivent basculer d’un format à l’autre.

Comme rien n’est téléversé, un lot ne coûte pas de bande passante et ne heurte aucun quota quotidien. La contrainte est ce que votre machine veut bien faire d’un coup, et sur une machine ancienne quelques centaines de grandes images peuvent demander de procéder par paquets de cinquante. La conversion est entièrement locale, et c’est ce qui rend la migration possible sans dépendance à un service tiers.

Les deux formats supportent l’animation, et la conversion préserve le mouvement plutôt que de figer la première image. Un WebP animé devient un AVIF animé avec la même durée totale, la même fréquence d’images, et la même séquence de frames dans le même ordre.

C’est utile pour les assets UI animés, les bannières publicitaires, les avatars qui s’animent en boucle. Pour un asset qui doit animer ailleurs, c’est presque toujours mieux que de tomber sur la première image. Pour un asset où l’animation a été perdue quelque part en amont, c’est ce qui sort, et l’avertissement vaut la peine d’être cherché dans la chaîne d’outillage qui a produit le WebP.

Le navigateur décode le WebP avec les codecs qu’il a déjà, encode l’AVIF avec @jsquash/avif chargé à la demande, et le résultat est écrit dans le même onglet. Aucun octet de l’image n’est envoyé à un serveur, et la conversion n’a pas de compte à reconnaître ni de quota à dépenser.

Pour un site qui doit migrer ses images d’un format à l’autre, c’est un point qui n’est pas anodin. Une migration typique concerne des centaines ou des milliers d’images, parfois plusieurs gigaoctets au total, et le téléchargement d’un service web tiers est une dépendance que peu d’équipes sont prêtes à assumer. La conversion locale règle la question à la racine, et la vérification se fait dans l’onglet réseau des outils de développement pendant qu’une conversion tourne.