Convertir BMP en WebP

Un bitmap de 1920 par 1080 fait 6,2 Mo, et il fait 6,2 Mo que ce soit une photographie ou une bannière plate, parce que le format écrit trois octets par pixel et n’en compresse aucun. Mettez cela sur une page et c’est la page : tout le reste — le HTML, le CSS, les polices, les scripts — est une erreur d’arrondi à côté.

Le WebP a été conçu exactement pour cette place dans une page. Il dépense des bits là où il y a du détail et rien là où il n’y en a pas, et c’est pourquoi la même image arrive en dizaines ou centaines de kilooctets au lieu de mégaoctets. La conversion n’est pas une optimisation à la marge ; c’est la différence entre une page qui charge sur un téléphone et une qui ne charge pas. C’est aussi la différence entre une mesure de Largest Contentful Paint qui passe et une qui ne peut pas, puisque sur une page avec une image en haut, l’image est ce que la mesure chronomètre.

Le WebP peut être sans perte — le format porte les deux modes, et c’est l’une des raisons pour lesquelles il existe. L’encodeur sur cette page écrit la variante avec perte, à la qualité 82 par défaut, parce que c’est ce que devrait être une image publiée.

Cela mérite d’être clair, parce que cela veut dire que cette conversion n’est pas réversible. Si ce que vous vouliez vraiment était une copie exacte du bitmap dans un conteneur plus petit, c’est la mauvaise page et le PNG est la bonne. Si l’image part sur un site web, le lossy est la bonne réponse et le nombre de qualité est la seule chose à laquelle penser — et 82 est assez haut pour que la plupart des gens ne fassent pas la différence entre le résultat et la source à taille normale. L’endroit où dépenser son attention n’est pas le curseur mais les dimensions, qui sont deux sections plus bas et comptent bien davantage.

Le WebP porte un canal alpha, et il en porte un aussi en mode avec perte — ce qui est inhabituel, et la plus forte raison de le choisir plutôt que le JPEG pour cette source. Rien dans cette conversion n’aplatit l’image ou ne vous demande une couleur de fond, parce que rien n’a besoin de le faire.

La plupart des fichiers BMP sont en 24 bits et n’ont pas d’alpha à préserver, donc pour eux le point est sans objet. Mais les variantes 32 bits en portent un, et un logo ou un élément d’interface exporté par un vieux outil Windows est exactement le type de fichier qui en a un. Envoyé en JPEG, cette transparence devient blanc — et sur ce site, sans même le choix de quel blanc. Envoyé en WebP, elle reste transparence, à 256 niveaux plutôt qu’à la valeur unique tout-ou-rien que donnerait un GIF, donc un bord anti-crénelé se fond encore correctement sur ce que la page met derrière.

C’est une limite dure du format plutôt qu’une limite de ce convertisseur, et c’est la seule chose qui peut rendre la conversion impossible plutôt que simplement avec perte. Aucune dimension d’un WebP ne peut dépasser 16 383 pixels.

Les images ordinaires en sont très loin — une photographie de 4 000 par 3 000 a beaucoup de marge. Ce qui l’atteint, c’est ce qui arrive en BMP : une grande numérisation haute résolution, un panorama assemblé, une sortie d’un instrument scientifique qui produit une bande très large. Si votre bitmap est l’un de ceux-là, réduisez d’abord la largeur ou utilisez le PNG, dont le plafond propre est au-delà de deux milliards de pixels par côté et donc théorique. Cela vaut la peine de vérifier les dimensions avant de convertir un lot, parce qu’un seul fichier qui ne peut pas devenir un WebP est un résultat bien plus déroutant qu’un fichier qui sort plus gros que prévu.

Le WebP est sorti de Google en 2010 et a passé sa première décennie avec un astérisque à côté. Cela a pris fin : il est dans chaque navigateur actuel, spécifié dans la RFC 9649, et les outils de design et de contenu le lisent comme une évidence.

Ce qui change la décision sur cette page. Il ne s’agit plus de savoir si l’audience pourra voir l’image — il s’agit seulement de savoir si le lossy est acceptable pour cette image en particulier. C’est une question bien plus facile, et pour tout ce qui est publié la réponse est en général oui. Le registre donne au WebP la même valeur de support navigateur qu’au JPEG et au PNG : complet. L’AVIF, l’alternative plus récente, est encore marqué « moderne », et ce seul mot est la différence pratique entre les deux quand on choisit quoi livrer sans solution de repli.

L’erreur la plus fréquente dans cette direction est de convertir un bitmap à ses dimensions d’origine et de le mettre dans une colonne de 600 pixels. Le navigateur télécharge alors plusieurs fois la donnée qu’il peut afficher et met le reste à l’échelle, et aucun réglage de codec ne le récupère.

Réglez la largeur maximale à la largeur la plus grande à laquelle l’image sera jamais affichée, doublée si elle doit rester nette sur un écran haute densité. Le redimensionnement se fait dans la même passe de canvas que tout le reste ici, donc l’image est mise à l’échelle une seule fois plutôt que deux, et l’économie est proportionnelle au nombre de pixels plutôt qu’à la largeur — diviser la largeur par deux retire les trois quarts de la donnée.

Une grande part des fichiers BMP sont des captures d’écran, et les encodeurs lossy traitent mal le texte — les bords durs du caractère sont exactement le contenu haute fréquence qu’ils sont construits à jeter. C’est un argument fort contre le JPEG pour ce matériau et un plus faible contre le WebP, qui gère mieux les frontières nettes au même réglage mais ne les rend pas gratuites.

Pour une capture d’écran qui doit rester lisible, le classement honnête est PNG d’abord, puis WebP à qualité augmentée, puis JPEG loin derrière. Le PNG sera souvent le fichier le plus petit aussi, puisque les aplats et les bords durs sont ce que la compression sans perte fait le mieux et ce que la compression lossy fait le pire — donc sur ce matériau le compromis habituel ne s’applique même pas. Pour une photographie, WebP à 82 sans ajustement est la bonne réponse et le classement n’importe pas.

Le registre n’enregistre aucun conteneur de métadonnées pour le BMP : pas d’EXIF, pas de XMP, pas de profil ICC embarqué. Le WebP peut porter les trois, et il n’y a rien dans la source pour les remplir.

Pour une image web, c’est en majorité commode — le fichier est aussi petit que les pixels le permettent et ne porte rien qui identifie d’où il vient. Cela compte si le bitmap sortait d’une chaîne à couleurs gérées et devait être interprété dans un espace particulier, parce que le WebP sera lu comme sRGB et rien sur ce chemin ne dit autre chose.

Déposez le dossier. Chaque bitmap est décodé et ré-encodé à tour de rôle sur votre propre machine, garde son nom de fichier avec l’extension changée, et l’ensemble revient dans un seul ZIP. Il n’y a pas de file, pas de compte et pas de quota journalier, et le plafond par fichier est 100 Mo.

Le faire localement compte ici plus que la vitesse. Les images d’un site qui n’a pas encore été lancé, les photos de produit sous embargo, les captures d’un outil interne — tout cela serait sinon remis à un tiers en échange d’une passe de compression que vous pouvez faire vous-même.

Chaque fichier converti garde son nom d’origine avec l’extension changée, ce qui rend un lot utilisable mais est aussi là où le travail n’est pas fini. Chaque référence à l’ancien fichier — dans un modèle, dans une feuille de style, dans une entrée de contenu, dans un manifeste — pointe encore sur un nom se terminant en .bmp, et une image manquante est un échec plus visible qu’une image trop grosse.

L’autre moitié est de se rappeler de retirer les bitmaps de tout ce qui sera déployé. Une build qui copie un répertoire d’actifs en bloc livrera les deux copies, ce qui veut dire que le dépôt grossit, le déploiement grossit, et les mégaoctets que cette conversion devait supprimer sont toujours transférés quelque part. Convertissez, mettez les références à jour, supprimez les originaux du projet, et gardez les bitmaps en dehors s’ils sont les seuls maîtres que vous avez.