Convertir ICO en AVIF

AVIF n’est pas un format d’image qui se trouve compresser bien ; c’est la voie intra-image du codec vidéo AV1 avec un conteneur autour. Tout ce qu’il sait bien faire suit de cela. AV1 a été construit pour prédire le contenu d’un bloc depuis ses voisins et pour écarter le détail résiduel qu’un œil en mouvement ne remarquera pas, ce qui est une stratégie extraordinairement efficace sur des photographies et sur le grain de film.

Une icône n’a ni l’un ni l’autre. C’est un petit nombre de régions plates avec des bords francs et quelques dizaines de pixels antialiasés le long de chaque bord. Il n’y a pas de texture à modéliser, pas de dégradé à prédire et très peu de résiduel à jeter — donc la machinerie qui fait gagner AVIF sur une photo n’a presque rien à faire, tandis que ses surcoûts fixes restent.

Sur une icône de test de 8 471 octets tenant quatre entrées, convertie à la qualité par défaut de 82, les résultats ont été : 1 737 octets en PNG, 1 894 en GIF, 3 054 en WebP, 3 624 en AVIF et 4 005 en JPEG. L’ordre est presque exactement l’inverse de ce que le même test sur une photo donnerait.

Ce n’est pas une différence marginale. L’AVIF fait plus du double du PNG et c’est la version avec perte. Pour un répertoire de deux cents icônes, les migrer en AVIF ajoute environ 380 kilo-octets à ce que le site livre plutôt que d’en retirer quoi que ce soit. Séparez les icônes de la migration et gardez-les en PNG.

La transparence est préservée : sur l’icône de test le pixel de coin du résultat AVIF lit 0,0,0,0. Ce n’est pas garanti pour chaque format efficace — la voie GIF sur ce site rend le même coin en noir opaque — donc si la marque est un détourage et que le format doit être AVIF, au moins cette partie fonctionne.

Cela fonctionne en codant l’alpha comme un second plan aux côtés de la couleur, effectivement une seconde petite image à l’intérieur du conteneur. Sur une photo ce surcoût se perd dans le bruit. Sur une icône de 256 pixels, où le fichier entier fait quelques kilo-octets, c’est une part visible du total et une partie de la raison pour laquelle le nombre ci-dessus est ce qu’il est.

L’encodeur AVIF est le plus gros module WebAssembly que ce site livre et le plus lent à tourner, parce qu’encoder un AVIF fixe veut dire lancer une recherche intra-image AV1. Pour un fichier c’est une pause. Pour un dossier de deux cents icônes converties d’un coup c’est une vraie attente, et c’est votre propre processeur qui le fait plutôt qu’un serveur.

Cela vaut la peine d’être pesé face au résultat en octets plutôt que séparément. Passer du vrai temps d’encodage, à chaque build, pour rendre chaque icône deux fois plus grande est un mauvais échange dans les deux directions à la fois.

Un ICO tient la même marque à plusieurs tailles et un AVIF tient une image, donc quelque chose doit choisir. Le décodeur d’icônes de votre navigateur le fait, et il retourne la plus grande entrée — vérifié en construisant un fichier avec des dessins en 16, 32, 48 et 256 pixels dans quatre couleurs différentes et en le convertissant avec le répertoire écrit dans trois ordres différents.

Le plafond est 256 pixels, fixé par le format ICO plutôt que par AVIF, qui monte jusqu’à 65 536. Donc l’entrée de l’encodeur est toujours une petite image, ce qui est la condition dans laquelle chaque format efficace performe le moins bien relativement au PNG.

AVIF peut stocker douze bits par canal et une gamut de couleur large, ce qui est l’un de ses avantages réels sur WebP et JPEG pour la photographie et pour le matériel à plage dynamique élevée. Un fichier d’icône stocke huit bits par canal dans une gamut standard et l’a toujours fait.

Donc cette capacité est disponible et inutilisée. Elle ne coûte rien directement, mais c’est un bon résumé de la paire : presque tout ce qu’AVIF fait mieux est quelque chose qu’une icône n’a pas. La seule propriété qu’il apporte qui compte ici — l’alpha — est une que le PNG avait déjà.

Chaque grand navigateur actuel décode l’AVIF, et depuis plusieurs années. C’est suffisant pour que la plupart des sites le servent directement. Il est plus récent que WebP, donc la traîne de clients qui ne peuvent pas le lire est plus longue, et la réponse habituelle est un élément picture avec une source de repli plutôt qu’un remplacement direct.

Notez ce que cela veut dire pour une icône : vous livrez maintenant deux fichiers au lieu d’un, et le repli est le PNG qui était plus petit au départ. La complexité est réelle et l’économie est négative.

Une règle générale est attrayante parce qu’elle retire une décision de chaque build futur, et les règles générales sur les formats d’image sont en général justes. C’est le cas où l’une d’elles ne l’est pas. Divisez la règle par contenu plutôt que par répertoire : les photographies et les captures d’écran vers AVIF, l’art plat et les icônes vers PNG, et écrivez la raison à côté de la règle pour que la personne suivante ne la « corrige » pas.

Si le pipeline ne peut vraiment pas exprimer deux règles — certaines transformations CDN ne le peuvent pas — alors convertir les icônes est un coût défendable de l’uniformité. Sachez que c’est un coût, et sachez à peu près à quel point il est grand : quelques kilo-octets par icône, dans la mauvaise direction.

Déposez le dossier. Chaque fichier est décodé et encodé à part et les résultats reviennent en ZIP, avec un seul réglage de qualité pour tout le lot. Attendez-vous à ce que cela prenne notablement plus longtemps que le même lot en PNG ou WebP, pour la raison ci-dessus.

Les dimensions ne seront pas uniformes à moins que le jeu source ne l’ait été. Les collections d’icônes mélangent des fichiers qui portent une entrée à 256 pixels avec des fichiers qui s’arrêtent à 32, et puisque les surcoûts fixes de l’encodeur importent d’autant plus que l’image est petite, les membres à 32 pixels du jeu sont là où l’AVIF se compare le moins bien de tous.

Deux choses valent la peine d’être regardées, et aucune ne prend longtemps. La première est le compte d’octets des deux fichiers côte à côte, parce que c’est le nombre pour lequel la migration a été entreprise et c’est celui qu’on est le plus susceptible de supposer plutôt que de mesurer. La seconde est la marque elle-même à la taille où elle sera réellement affichée — pas zoomée, où les artefacts avec perte semblent alarmants et où personne ne les verra jamais, et pas en miniature, où tout a l’air correct.

Gardez le fichier ICO original dans les deux cas. C’est la seule chose qui tient encore les petites entrées dessinées à la main, c’est quelques kilo-octets, et c’est ce qu’un navigateur continuera de demander à la racine du site quel que soit ce que le build produit.