Convertir ICO en BMP

Tous deux viennent de Microsoft et ils ont été conçus ensemble. Le format d’icône original n’emballait pas d’image séparée du tout : chaque entrée tenait un en-tête de bitmap suivi de données de couleur et d’un masque d’un bit disant quels pixels laisser tranquilles. Un ICO était, très littéralement, des bitmaps dans un répertoire avec un pochoir attaché.

Les deux ont ensuite divergé. Les icônes ont gagné un véritable canal alpha de huit bits avec Windows XP et la capacité de porter une charge utile PNG avec Vista, ce qu’utilisent les fichiers d’icônes modernes pour leurs grandes entrées. Le bitmap écrit par ce convertisseur est la base 24 bits, qui n’a jamais gagné ni l’un ni l’autre. Convertir l’un en l’autre est donc un pas en arrière en capacité, entrepris parce que quelque chose à l’autre bout en a besoin.

L’encodeur écrit 24 bits par pixel : huit de bleu, huit de vert, huit de rouge, et rien d’autre. Il existe une variante d’en-tête BMP qui définit un canal alpha, et des fichiers qui l’utilisent existent, mais presque rien ne le lit de façon fiable — ce qui est exactement le problème de fiabilité que BMP est en général choisi pour éviter.

Donc la transparence doit aller quelque part avant que l’encodeur tourne, et le réglage de fond décide où. Le blanc est la valeur par défaut. Choisissez la couleur de la surface sur laquelle le bitmap sera dessiné : un fond de bannière d’installateur, la couleur de panneau sur un affichage embarqué. Sur une icône de test avec des coins transparents le résultat lisait 255,255,255 dans le coin, ce qui est correct et est aussi la mauvaise réponse si le panneau est gris foncé.

Ce n’est pas un défaut et c’est toute la raison pour laquelle BMP existe. Chaque pixel occupe exactement trois octets quoi qu’il contienne, donc la taille du fichier est arithmétique plutôt qu’un résultat : largeur fois trois, arrondie à un multiple de quatre, fois hauteur, plus 54 octets d’en-tête.

Pour un carré de 256 pixels cela fait 768 octets par ligne et 196 608 octets de pixels, donnant 196 662 au total. Mesuré contre l’icône de test de 8 471 octets dont il venait, le bitmap fait plus de vingt-trois fois la taille. Si la destination a une limite de taille, faites cette multiplication avant de convertir plutôt qu’après.

Le plus grand dans le fichier. Le décodage est fait par le lecteur d’icônes de votre navigateur, qui retourne la plus grande entrée du répertoire — 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 dessin à 256 pixels est sorti à chaque fois.

Les entrées plus petites ne sont écrites nulle part et il n’y a aucun réglage qui les atteigne. Si le logiciel que vous alimentez veut un bitmap de 32 pixels et que l’icône tient une entrée à 32 pixels, un éditeur d’icônes tel que GIMP exportera ce calque directement, ce qui est un meilleur résultat que de réduire la version à 256 pixels.

Deux détails qu’il vaut la peine de connaître si vous lisez les octets plutôt que d’ouvrir le fichier. BMP stocke ses lignes depuis le bas de l’image vers le haut, et il stocke chaque pixel comme bleu, puis vert, puis rouge. Les deux sont dans la spécification et les deux surprennent régulièrement quelqu’un qui en parse un pour la première fois.

Chaque ligne est aussi complétée à un multiple de quatre octets, ce qui importe aux largeurs impaires : un bitmap de 33 pixels de large a 99 octets de couleur par ligne et un octet de remplissage, ce qui fait la ligne stockée 100. À 256 pixels la ligne fait 768 octets et aucun remplissage n’est nécessaire, ce qui est une raison pour laquelle les bitmaps de taille d’icône sont faciles à manipuler à la main.

Parce qu’en lire un ne demande aucun décodeur. Un microcontrôleur pilotant un petit affichage peut copier des octets d’un fichier dans un tampon d’image avec une boucle et un décalage d’en-tête ; ajouter un décodeur PNG à ce micrologiciel veut dire ajouter un décompresseur, un allocateur de mémoire et un parseur de chunks à un appareil qui peut avoir 32 Ko de RAM.

Le même raisonnement s’applique aux ressources d’installateur, aux anciens contrôles Windows qui chargent les ressources par les propres fonctions bitmap de la plateforme, et aux montages de test qui veulent comparer des images octet par octet sans codec en travers. Dans tous ces cas, la prévisibilité vaut bien plus que la taille.

Les deux formats sont sans perte, et ce chemin n’a aucun réglage de qualité parce qu’il n’y a rien à échanger. Chaque pixel qui survit à l’aplatissement est bit pour bit ce que l’icône stockait, donc convertir le même fichier deux fois donne une sortie identique et il n’y a aucune perte de génération à craindre s’il repasse par l’étape plus tard.

Les deux choses qui sont véritablement perdues sont le canal alpha, remplacé par la couleur de fond, et les autres entrées du conteneur. Aucune n’est récupérable à partir du bitmap ensuite, ce qui est l’argument pour garder le fichier ICO original plutôt que de le remplacer.

Si la destination est un logiciel moderne avec une préférence déclarée plutôt qu’une exigence ferme, un PNG est plus petit de deux ordres de grandeur et garde la transparence. La même icône de test faisait 1 737 octets en PNG contre 196 662 en bitmap — une différence assez grande pour valoir un courriel demandant si BMP est véritablement exigé.

Là où la réponse est oui — micrologiciel, un script d’installateur, un montage avec une comparaison au niveau de l’octet — le bitmap est correct et la taille est le prix d’être lisible sans décodeur. Dites cela dans le message de commit, parce qu’un fichier de 200 Ko pour une petite icône ressemble à une erreur à celui qui l’examinera ensuite.

Déposez le jeu entier. Chaque fichier est décodé, aplati sur la même couleur de fond et écrit séparément, le tout retourné en ZIP. Un fond partagé à travers le lot est en général ce dont ces destinations ont besoin, puisque les images sont compositées sur une seule surface.

Vérifiez les dimensions du résultat plutôt que d’assumer qu’elles correspondent. Les jeux d’icônes accumulés au fil des années mélangent des entrées qui atteignent 256 pixels avec celles qui s’arrêtent à 32, et les bitmaps héritent cette dispersion — avec un facteur de soixante-quatre entre les tailles de fichier aux deux extrêmes.