Convertir WebP en BMP

BMP signifie Bitmap, et le format existe depuis Windows 2.0 en 1987. Un BMP est essentiellement la grille de pixels en mémoire, écrite dans un fichier avec un petit en-tête devant. Pas de compression significative, pas de compromis de qualité, pas d’options de palette à discuter — la même structure depuis quarante ans, et c’est précisément pour cela qu’il sert encore dans certains contextes.

La conversion qui sort un BMP depuis un WebP est une demande ciblée. La cible est un logiciel qui ne sait pas lire le WebP et qui ne sait pas non plus s’en sortir avec autre chose que du BMP, ou un contexte où l’on veut explicitement le poids et la simplicité du format non compressé. C’est ce qu’il faut savoir avant de convertir, parce que le fichier qui sort pèse beaucoup plus que ce qui est entré.

Un BMP est en gros trois octets par pixel — un pour le rouge, un pour le vert, un pour le bleu, dans cet ordre. Une photo 1 920 sur 1 080 fait un peu plus de six mégaoctets sans aucun artifice. Ajoutez l’alignement sur quatre octets par ligne, et un BMP de 2 000 sur 1 500 fait plus de neuf mégaoctets là où le WebP faisait moins d’un.

C’est la propriété qu’il faut accepter en échange de ce que le BMP offre. Pour un fichier destiné à voyager en pièce jointe, c’est presque toujours le mauvais choix, parce que les pièces jointes ont une limite de taille et la compression n’est pas négociable. Pour un fichier destiné à être lu par un logiciel particulier, c’est parfois le seul choix, et c’est l’unique raison pour laquelle cette conversion est demandée.

Le WebP peut porter un canal alpha ; le BMP peut, en théorie, porter un canal alpha sur 32 bits, mais le BMP que cette conversion écrit n’en porte pas. Le code source encode en 24 bits sans canal alpha, et toute transparence dans le WebP source est aplatie sur un fond — blanc par défaut, et modifiable par le contrôle de couleur de fond.

Si l’image est un logo avec un fond transparent, une photo de produit détourée, un pictogramme, cette conversion demande un choix : choisir une couleur de fond et accepter que les zones transparentes deviennent cette couleur, ou ne pas convertir. Pour un cas où la transparence doit être préservée, le PNG est le format à utiliser, et c’est explicite sur la page de cette conversion-là.

Le BMP est lu par tout. Chaque visionneuse d’images, chaque éditeur, chaque visionneuse Windows, chaque outil d’aperçu de pièce jointe de messagerie, chaque visionneuse de bureau Linux, chaque client FTP. C’est l’un des rares formats qui est plus largement lu qu’il n’est produit, parce que les producteurs ont migré vers des formats plus efficaces et que les lecteurs ont conservé le BMP comme compatibilité descendante.

C’est ce qui rend la conversion utile. Un WebP enregistré depuis un site web refuse de s’ouvrir dans une visionneuse ancienne ou un client de messagerie qui n’a pas suivi. Un BMP s’ouvrira. Le coût est la taille, et le gain est l’universalité. Pour un cas de compatibilité où la taille n’a pas d’importance — une icône, un petit élément d’interface — c’est un compromis acceptable.

Le BMP que cette conversion écrit n’est pas une copie parfaite du WebP, et c’est par construction de l’ensemble de la chaîne. Le WebP est avec perte à la qualité standard, et les pixels qui sortent du décodeur ne sont pas ceux qui sont entrés dans l’encodeur. Le BMP encode ces pixels sans compression supplémentaire, donc la sortie est sans perte par rapport à ce qui a été décodé, mais ce qui a été décodé était déjà dégradé.

Si l’original existe sous une meilleure forme, c’est cet original qu’il faut convertir en BMP, pas le WebP. Pour un asset qui est disponible uniquement en WebP, le BMP qui sort est le meilleur rendu possible, et il est honnête de le décrire comme un BMP du WebP et non un BMP de l’original.

Le WebP peut porter un profil ICC qui décrit l’espace colorimétrique de l’image — sRGB, Display P3, ProPhoto, ou un profil d’appareil spécifique. Le BMP n’a pas de canal pour le profil ICC, et le BMP écrit par cette conversion ne porte donc pas l’information d’espace colorimétrique.

Pour une image qui était en sRGB — la grande majorité des images web — c’est sans conséquence : un BMP sans profil est interprété comme du sRGB par tous les logiciels qui lisent du BMP, et la couleur reste correcte. Pour une image qui était dans un autre espace — un profil Adobe RGB, un gamut étendu —, la conversion peut produire un BMP qui s’affiche différemment de l’original parce que la conversion ne porte pas l’information nécessaire pour interpréter les pixels correctement. C’est explicite dans le code source et c’est par construction du format.

Le BMP n’a pas de champ EXIF, pas de bloc XMP, pas de section IPTC, pas de profil ICC, et donc rien de tout cela ne sort de la conversion. Un WebP qui portait des informations de localisation, un commentaire de photographe, un profil colorimétrique précis, les perd tous dans le BMP produit.

Pour une image qui n’avait rien à perdre — un asset UI, une capture d’écran, un pictogramme — c’est sans importance. Pour une image qui portait des métadonnées, c’est une perte réelle, et la page de suppression des métadonnées sur le WebP source est l’outil qui efface ce qui doit l’être, plutôt que la conversion qui le perd implicitement. Pour un cas où les métadonnées doivent être préservées, le BMP n’est pas le bon format de sortie.

Le BMP stocke les canaux dans l’ordre bleu-vert-rouge, là où presque tous les autres formats utilisent rouge-vert-bleu. C’est un détail d’histoire de Windows, et la conversion écrit dans l’ordre BGR parce que c’est ce que le format attend. Tous les logiciels qui lisent du BMP tiennent compte de cet ordre, donc un fichier ouvert s’affiche correctement, et c’est l’ordre qui rend un BMP identifiable par un éditeur hexadécimal : `42 4D` est la signature, et `XX GG BB` est la séquence de canaux.

Si vous manipulez le fichier en binaire et que vous réécrivez les pixels à la main, c’est l’ordre qu’il faut respecter. Pour un usage ordinaire — ouvrir, regarder, imprimer — c’est invisible et bien géré par les logiciels de lecture.

Déposez jusqu’à cent WebP ensemble, et chacun sort en BMP. Pour un lot d’icônes, de pictogrammes, de petits assets UI extraits d’un site, c’est une conversion qui revient souvent. La sortie est en BMP 24 bits sans compression, et le résultat sera sensiblement plus gros que l’entrée.

Pour un cas de ce type, c’est utile de savoir que la conversion prend quelques secondes par fichier et que le lot complet arrive en un seul ZIP. La taille totale du ZIP peut être substantielle, parce que c’est la somme de fichiers non compressés, et il faut en tenir compte pour le transport. Pour un usage local où la taille n’a pas d’importance, c’est un workflow qui marche bien, et c’est explicite dans le code source que c’est le cas d’usage ciblé par ce format de sortie.

Le navigateur décode le WebP avec les codecs qu’il a déjà et encode le BMP dans le même onglet, sans serveur, sans compte, sans quota. Aucun octet de l’image n’est téléversé, et la conversion n’adresse jamais le réseau sauf pour charger le code de l’encodeur BMP à la demande.

Pour un asset UI ou un pictogramme ce n’est pas un point critique, mais pour un fichier qui pourrait porter des métadonnées privées ou un asset de marque, c’est une garantie qui compte. Le plafond gratuit de 100 Mo par fichier est bien au-delà de toute image qui aurait sa place en BMP, et l’ensemble du calcul est local pour cette paire.