Convertir BMP en AVIF

Un fichier AVIF est, structurellement, une image fixe de la vidéo AV1 dans un conteneur que l’Alliance for Open Media a spécifié en 2019. Il hérite du travail de compression d’un codec vidéo moderne, ce qui explique qu’il batte WebP et JPEG sur du contenu photographique à qualité visible égale.

Il en hérite aussi le coût. Le registre liste l’encodage lent comme le problème connu du format, et la chaîne ici en convient : le décodage est le pôle long pour une grande photo dans toutes les autres conversions, et pour celle-ci c’est l’encodage. Un bitmap de douze mégapixels — une image 4000 par 3000, 36 Mo en BMP — prend suffisamment de temps pour que la barre de progression fasse un vrai travail plutôt que de vous rassurer. Cette asymétrie vaut la peine d’être intégrée, parce qu’elle inverse l’intuition habituelle. Le bitmap est le fichier énorme et bon marché à lire ; l’AVIF est le minuscule fichier et coûteux à écrire.

AVIF contient douze bits par canal et décrit des espaces colorimétriques étendus. Ces deux capacités sont l’essentiel de la raison pour laquelle le format existe, et elles sont la raison pour laquelle il est le format de diffusion de la photographie HDR.

Un BMP contient huit bits par canal en RGB simple. Il n’y a pas de gamut étendu dans la source, pas de plage dynamique supplémentaire, pas de profil de couleur — le registre n’enregistre aucun conteneur de métadonnées pour BMP du tout. Donc la marge dans l’AVIF reste vide, et le seul bénéfice que vous retirez de cette conversion est la compression. C’est un vrai bénéfice ; cela vaut la peine de savoir que c’est le seul, parce qu’une grande partie de ce qui est écrit sur AVIF concerne des capacités qu’un bitmap ne peut pas atteindre. Un format n’ajoute jamais d’information : il ne peut que décrire ce qui est arrivé, et ce qui est arrivé ici est du sRGB à huit bits depuis un format que Microsoft a publié en 1987.

Il tourne en WebAssembly dans l’onglet du navigateur, sur le processeur de la machine. Il n’y a pas de serveur qui fait le travail, ce qui est la raison pour laquelle rien n’est téléversé et aussi la raison pour laquelle un lot de grands bitmaps est quelque chose que vous lancez et auquel vous revenez.

La forme pratique de la chose : une image modérée est une attente, et un dossier de quarante sorties de scanner est un café. Si c’est inacceptable et que l’audience est de toute façon large, WebP est à une page d’ici et s’encode en une fraction du temps pour un fichier qui est en général à un écart modeste de l’AVIF. Rien là-dedans n’est un défaut de la conversion — le même encodage sur un serveur prendrait un travail comparable, il utiliserait le processeur de quelqu’un d’autre et votre fichier devrait voyager pour l’atteindre. Le temps est le prix honnête pour que l’image ne quitte jamais la machine.

Le registre classe la prise en charge d’AVIF comme moderne, et ce mot fait un vrai travail à côté du « tous » qu’il donne à WebP et JPEG. Les navigateurs actuels, sur ordinateur et mobile, lisent AVIF ; les appareils plus anciens, certains navigateurs intégrés et beaucoup de logiciels de courriel ne le font pas.

Ce qui en fait un format à servir plutôt qu’à envoyer. En pièce jointe ou en fichier remis à quelqu’un d’autre, c’est un mauvais choix, et le fait qu’il s’ouvre sur votre machine dit peu de ce qu’il en sera sur la sienne. La même prudence s’applique aux outils de design et d’édition : la prise en charge y est arrivée de façon inégale, et un AVIF qu’un navigateur affiche parfaitement peut rester un fichier qu’un collègue ne peut pas placer dans un document.

Le mécanisme qui rend la lacune de prise en charge supportable est l’élément picture : plusieurs sources listées dans l’ordre, chacune avec son type, et le navigateur prend la première qu’il comprend. Mettez l’AVIF en premier, un WebP après et un JPEG en dernier, et chaque visiteur obtient le plus petit fichier que son navigateur peut réellement décoder sans qu’aucun code de détection tourne.

Cela veut dire convertir le même bitmap deux fois, et c’est la raison pour laquelle le lot de cette page est souvent lancé en parallèle de celui de la page WebP. Cela vaut la peine de le faire dans cet ordre plutôt que de convertir l’AVIF depuis le WebP : chaque encodeur avec pertes prend ses propres décisions sur ce qu’il écarte, et empiler deux d’entre eux produit un fichier qui porte les deux ensembles de pertes pour aucune économie. Encodez toujours chaque format de diffusion depuis le bitmap lui-même.

AVIF porte un canal alpha, et rien sur ce chemin n’aplatit l’image ou ne demande de couleur de fond, donc un bitmap 32 bits garde ses zones transparentes. Les fichiers 24 bits qui constituent l’essentiel de ce qui arrive ici n’en ont pas à garder.

Le contrôle de qualité est par défaut à 82, le même chiffre que toute cible avec pertes du site, et il vaut la peine de se rappeler que l’échelle appartient à l’encodeur plutôt qu’à l’image. Quatre-vingt-deux en AVIF et quatre-vingt-deux en JPEG ne sont pas la même quantité de pertes ni la même taille de fichier, donc comparer deux formats veut dire comparer les sorties, pas les réglages. AVIF a aussi tendance à échouer différemment : là où JPEG se casse en blocs et en résonance autour des bords, AVIF lisse la texture fine, ce qui est moins manifestement faux et plus facile à manquer jusqu’à ce que l’image soit à côté de l’originale.

Quand l’audience inclut de vieux appareils. Quand l’image est assez petite pour que la différence soit de quelques kilo-octets. Quand le matériau est du graphisme plat aux bords durs, où l’avantage d’AVIF se rétrécit et peut s’inverser. Et quand vous convertissez des centaines de fichiers et que le temps d’encodage est la contrainte qui compte réellement.

AVIF gagne son coût sur de grandes images photographiques servies à une audience moderne à travers un élément picture. C’est un cas précis plutôt qu’un défaut, et une page qui dirait le contraire vendrait le format le plus récent plutôt qu’elle ne le décrirait. Le test qui tranche coûte une minute : convertissez un bitmap représentatif vers les deux, mettez les deux nombres d’octets côte à côte, et décidez si la différence justifie un second encodage de chaque fichier et un repli dans le balisage. Parfois c’est manifestement le cas ; souvent ce ne l’est pas.

C’est le seul ajustement qui améliore la taille du fichier et le temps d’encodage ensemble, et il est proportionnel au nombre de pixels plutôt qu’à la largeur — diviser la largeur d’un bitmap par deux retire les trois quarts des pixels auxquels l’encodeur doit penser.

Réglez la largeur maximale à la plus grande largeur à laquelle l’image sera jamais affichée, doublée pour les écrans haute densité. Un scan 4000 par 3000 réduit à 2000 par 1500 reste plus grand que presque tous les endroits où il apparaîtra, et l’encodage AVIF de celui-ci se termine en environ un quart du temps.

Déposez tout le dossier et chaque fichier se convertit à son tour sur votre propre machine, en gardant son nom avec l’extension échangée, avec l’ensemble renvoyé en un ZIP. Le plafond est 100 Mo par fichier, ce qui représente environ 33 mégapixels de bitmap non compressé.

Planifiez le lot autour de l’encodage plutôt qu’autour du téléchargement. Les fichiers sont traités l’un après l’autre, donc le temps est à peu près la somme des encodages individuels, et les images les plus grandes le dominent — un seul bitmap de 33 mégapixels peut prendre plus de temps que trente petits. Trier les fichiers manifestement surdimensionnés et les redimensionner d’abord vaut plus que tout autre changement que vous pouvez faire à un lot ici, et c’est le seul qui améliore les sorties ainsi que l’attente.

AVIF est un format de diffusion et cette conversion est avec pertes. Ce qui en sort est dimensionné et encodé pour l’endroit où il va, et il n’y a pas de chemin de retour vers les pixels que le bitmap détenait.

Si le BMP est votre seule copie, gardez-le ou convertissez-le en PNG d’abord — cette direction-là est exacte et coûte une fraction de l’espace disque. Puis produisez l’AVIF depuis le maître à chaque fois que la destination change, plutôt que de convertir un fichier de diffusion en un autre fichier de diffusion et d’empiler les pertes d’un encodeur sur celles d’un autre.