Convertir HEIF en WebP

Les plateformes de publication valident les téléversements contre une liste, et HEIF y figure rarement. Cela semble arbitraire jusqu’à ce qu’on considère ce que la plateforme doit faire ensuite : générer une vignette, produire trois tailles réactives, et vous montrer un aperçu dans l’éditeur. Elle ne peut faire aucune de ces choses de façon fiable avec un format dont la prise en charge par les navigateurs est partielle, donc la chose la plus sûre qu’elle puisse faire est de refuser le fichier.

La conséquence, c’est que la conversion est votre travail plutôt que celui de la plateforme, et la faire avant le téléversement est mieux qu’après. Vous contrôlez les dimensions et la qualité ; le ré-encodeur automatique de la plateforme, s’il en a un, travaille à partir de ce que vous lui avez donné.

Google a publié WebP en 2010 et il est aujourd’hui normalisé comme RFC 9649. Ce qui en fait le défaut pour ce travail n’est pas l’ingéniosité de la compression mais sa couverture : c’est l’un des rares formats d’image du site dont la prise en charge par les navigateurs est enregistrée comme complète plutôt que moderne ou partielle, donc un seul fichier fonctionne pour chaque visiteur sans repli.

Il apporte aussi les deux choses dont un format de livraison a besoin et qui manquent à JPEG — un canal alpha et une meilleure compression à qualité visible égale. Pour une page qui doit charger sur un téléphone en connexion lente, ce sont les deux leviers qui comptent, et WebP a les deux sans demander à qui que ce soit de négocier des types de contenu.

La qualité est par défaut à 82 sur une échelle de 1 à 100. Pour des photos sur une page web, c’est un bon endroit où se poser : le détail survit à la taille qu’un navigateur affichera réellement, et le fichier est une fraction de ce que coûterait une copie sans perte. Descendre dans les années 60 achète de vrais octets et commence à se voir sur les bords et dans les zones plates, monter au-dessus de 90 alourdit le fichier sans bénéfice visible à l’œil.

Souvenez-vous que c’est la deuxième compression qu’a subie l’image. L’appareil l’a compressée en HEIF, et ceci compresse ce qui en est sorti. Un passage supplémentaire à 82 n’est pas quelque chose qu’un visiteur remarquera, mais c’est une raison de convertir à partir du HEIF d’origine à chaque fois plutôt que de reconvertir un WebP plus tard, parce que chaque chaîne ajoute sa propre génération d’artefacts et qu’à la troisième ou quatrième le résultat cesse d’être invisible.

WebP ne peut pas décrire une image de plus de 16 383 pixels de côté. C’est une propriété du format, pas de ce convertisseur, et aucun réglage ne le contourne. Une photo de douze ou quarante-huit mégapixels est bien en dessous dans les deux directions, donc pour les images normales la limite n’intervient jamais.

Ce qui intervient, c’est un panorama. Les modes panorama des téléphones assemblent une image très large et très courte, et celles-ci dépassent régulièrement les seize mille pixels de large. Pour l’un de ceux-là, fixez une largeur maximale avant la conversion — ce que vous vouliez probablement de toute façon, puisqu’aucune page web n’affiche une image à cette largeur.

Le champ de largeur maximale est le réglage le plus précieux de cette page pour un usage web. Réduire une photo de 4 032 pixels à 1 600 pixels coupe les données données à l’encodeur à environ un sixième avant que la compression commence, et 1 600 est déjà généreux pour une image de contenu sur une mise en page de bureau.

Servir une photo en pleine résolution et laisser le navigateur la réduire est l’erreur de poids de page la plus commune : le visiteur paie pour la totalité de ces pixels et en voit peut-être un cinquième. Si vous avez besoin de plusieurs tailles pour un jeu réactif, convertissez le HEIF plusieurs fois à des largeurs différentes plutôt que de redimensionner le WebP après coup.

Le WebP écrit ici ne contient pas d’EXIF et pas de XMP. Rien n’a été filtré ; la conversion décode l’image en pixels bruts et la réencode, et les métadonnées n’ont pas de chemin à travers cette étape, ce qui veut dire que la chose qui protégeait la vie privée du sujet est tombée en route plutôt qu’après.

Sur une page consacrée à la publication, c’est la chose la plus utile qu’elle contient. Une photo prise avec un téléphone est couramment étiquetée avec une latitude et une longitude à l’adresse près, et une annonce de marché ou un article de blog qui la porte publie le lieu où vit le photographe. Plusieurs grandes plateformes la suppriment au téléversement et plusieurs non ; convertir d’abord signifie que vous ne dépendez pas du type de plateforme auquel vous avez affaire, ce qui est la définition d’une bonne mesure par défaut.

AVIF compresse la même image plus petite à qualité visible égale, et sa prise en charge par les navigateurs est plus récente que celle de WebP plutôt qu’universelle. C’est toute la comparaison, et elle se tranche selon la façon dont votre site sert les images, parce que les deux encoders sont d’égale qualité sur la plupart des photographies et c’est la couche de distribution qui décide.

Si vous téléversez un seul fichier et qu’il est servi à tout le monde, WebP est la réponse — pas de négociation, pas de repli, rien à tester. Si votre couche de livraison peut proposer AVIF aux navigateurs qui l’annoncent et WebP aux autres, alors AVIF vaut l’étape supplémentaire et il y a une page séparée pour cette conversion. Choisir AVIF comme format unique parce qu’il est plus récent est la façon dont un visiteur se retrouve avec une image cassée, et le bénéfice de compression ne sert à rien si l’image ne s’affiche pas du tout.

Le décodeur HEIF et l’encodeur WebP tournent dans l’onglet du navigateur, sur votre propre processeur. Il n’y a pas de téléversement, pas de file d’attente et pas de compte, et le fichier n’existe jamais sur le serveur de qui que ce soit — ce qui pour des photos de produit non publiées et des photos de personnes qui n’ont rien approuvé est la différence qui compte.

Le palier gratuit accepte jusqu’à 100 Mo par fichier, ce qu’aucune photo de téléphone n’approche. Un dossier entier se convertit en une passe avec une ligne de progression chacune, et dès que deux fichiers sont terminés un bouton « tout en ZIP » apparaît, donc préparer trente images pour une galerie est un téléchargement au lieu de trente, et le téléchargement arrive plus vite qu’il ne serait parti d’un service hébergé qui aurait d’abord reçu chaque fichier.

Gardez le HEIF. C’est la copie de la meilleure qualité que vous avez, c’est la plus petite que vous avez, et chaque taille ou format futur dont vous aurez besoin doit être fabriqué à partir d’elle plutôt qu’à partir du WebP que vous avez publié.

Il n’y a pas non plus de chemin de retour : ce site sait lire HEIF et ne sait pas l’écrire, parce que l’encodeur qui le ferait est sous une licence qu’un site statique ne peut pas satisfaire. Le WebP est donc un dérivé et le HEIF est l’original, et cela vaut la peine de les classer ainsi plutôt que de supprimer celui qui ne peut pas être recréé.

WebP est inhabituel parmi les formats de livraison en ayant deux modes distincts : un mode avec perte construit sur de la compression de type vidéo, et un mode sans perte plus proche dans l’esprit de PNG. Le registre note le format comme capable de sans perte, et cela vaut la peine de savoir lequel des deux vous obtenez — le mode par défaut n’est pas celui qu’un nom générique suggère.

Cette conversion écrit le mode avec perte, au chiffre de qualité que vous fixez. Pour une photo, c’est le bon choix de loin — un WebP sans perte d’une image d’appareil photo fait plusieurs fois la taille et ne récupère rien, puisque le HEIF avait écarté ce qu’il avait écarté avant votre arrivée. Si vous avez spécifiquement besoin d’une copie sans perte d’un HEIF, PNG est la façon honnête de le demander.