Convertir HEIF en BMP

Le BMP est un format hérité et cette page ne va pas prétendre le contraire. Il n’a pas de compression qui vaille le nom, pas de métadonnées, et aucun avantage sur le PNG sur un axe dont une personne se soucierait. Microsoft l’a publié en 1987, l’en-tête de 40 octets que cette page écrit est arrivé avec Windows 3.0 en 1990, et le monde est passé à autre chose.

Ce qui le maintient en vie, c’est un logiciel qui ne l’a jamais fait. Des panneaux de contrôle d’instruments, des afficheurs de kiosques, des chargeurs d’images de micrologiciel, des outils internes compilés une fois en 2003 et jamais retouchés : ceux-là lisent un bitmap parce qu’un bitmap est trivial à analyser sans aucune bibliothèque. Si c’est votre situation, le BMP n’est pas un mauvais choix, c’est le seul, et tout ce qui suit porte sur l’obtention des bons octets.

Un en-tête de fichier de 14 octets commençant par les deux caractères BM, puis un BITMAPINFOHEADER de 40 octets déclarant un plan de couleur et 24 bits par pixel, puis les données de pixels. Trois octets par pixel dans l’ordre bleu-vert-rouge, qui est l’ordre demandé par la spécification et non une erreur. Les lignes sont stockées de bas en haut, ce qui est aussi la spécification.

Chaque ligne est alignée sur un multiple de quatre octets. Pour une largeur de 4 032, cela fait 12 096 octets sans remplissage nécessaire ; pour une largeur de 4 031, cela fait 12 093 octets plus trois octets de remplissage. Un analyseur qui suppose que les lignes sont contiguës lira chaque ligne après la première décalée, ce qui est l’échec classique quand quelqu’un écrit son propre chargeur BMP.

Parce que rien n’est compressé, vous pouvez calculer la sortie avant de convertir : la longueur de ligne alignée fois la hauteur, plus 54 octets d’en-tête. Une photographie de douze mégapixels en 4 032 par 3 024 revient à 36 578 304 octets de données de pixels — environ 36,6 Mo — depuis un HEIF qui en faisait probablement deux ou trois.

Un facteur quinze environ est le résultat normal, et c’est la raison pour laquelle le champ de largeur maximale compte ici plus que sur presque toute autre paire. Si le logiciel que vous alimentez affiche l’image à 1 024 pixels de large, convertir à 1 024 de large lui donne ce dont il a besoin en environ 3 Mo au lieu de 36.

L’encodeur produit des pixels 24 bits, donc il n’y a pas de place pour la transparence. Tout ce qui est transparent dans la source est d’abord aplati, et seulement ensuite encodé, et sur quoi il est aplati est la couleur de fond au-dessus de la zone de dépôt. Elle commence au blanc ; le contrôle a été étendu aux sources HEIC et HEIF en août 2026, n’étant auparavant proposé que depuis PNG, WebP et les autres formats que le site s’attendait à voir porter de l’alpha.

Pour une photographie, qui est ce qu’un fichier .heif contient presque toujours, il n’y a rien à aplatir et le point est académique. Cela compte si la source est un graphisme exporté avec un détourage, et dans ce cas le PNG garde la transparence et le BMP ne le peut pas.

Chaque pixel que le décodeur HEIF a produit est écrit dans le BMP littéralement, donc cette direction n’ajoute aucun artefact de compression propre. En ce sens étroit c’est une conversion sans perte et le fichier est un enregistrement fidèle du décodage.

Cela n’annule rien. L’appareil photo a compressé la photographie quand il a écrit le HEIF, et ces décisions sont inscrites dans les pixels que le décodeur remet. Un bitmap de 36 Mo d’une photographie de 2 Mo contient exactement autant d’image que les 2 Mo en contenaient, stockée bien moins astucieusement.

Le HEIF est spécifié à dix bits par canal et peut porter une couleur étendue. Un BMP 24 bits contient huit bits par canal et n’a aucune notion d’espace colorimétrique — il n’y a nulle part dans l’en-tête pour dire ce que les nombres veulent dire.

Donc la conversion tronque, et le logiciel destinataire interprétera les valeurs comme du sRGB ordinaire parce que c’est la seule valeur par défaut raisonnable. Pour le genre de programme qui exige un BMP c’est invariablement correct ; cela vaut la peine d’être su seulement si l’image est une mesure calibrée plutôt qu’une photographie.

Le BMP ne contient pas d’EXIF, pas d’horodatage, pas de modèle d’appareil et pas de coordonnées GPS. Deux raisons distinctes y convergent : la conversion décode en pixels bruts et ré-encode, ce qu’aucun bloc de métadonnées ne survit, et le format n’a essentiellement nulle part où en stocker même s’il le faisait.

C’est parfois tout l’intérêt. Alimenter une image dans un système qui va la stocker, l’indexer ou l’afficher publiquement, un bitmap est à peu près le conteneur inerte qui existe — des pixels, des dimensions, et rien qui identifie le photographe ou le lieu.

Tout, et c’est la seule vraie force du format. Microsoft Paint, GIMP et IrfanView l’ouvrent tous, chaque API Windows depuis le début l’a compris, et les navigateurs l’affichent — le BMP est l’un des rares formats ici dont le support navigateur est enregistré comme complet, ce qui rend la vérification de la sortie aussi simple que l’ouvrir dans un onglet.

Cette vérification vaut la peine d’être faite une fois par lot. Si une image apparaît à l’envers ou avec ses couleurs inversées dans un logiciel personnalisé que vous alimentez, la cause est presque toujours un lecteur qui suppose des lignes de haut en bas ou l’ordre RVB, et le fichier est correct.

Le décodeur et l’encodeur de bitmap tournent tous deux dans l’onglet du navigateur, donc aucune photographie n’est téléversée et rien n’est mis en file. C’est un point pratique pour les lecteurs à qui cette page s’adresse, dont les fichiers sont fréquemment des images d’une chaîne de production, d’un dossier patient, d’un levé de site ou d’autre chose qui n’est pas censé quitter le bâtiment.

Le niveau gratuit accepte les entrées jusqu’à 100 Mo, ce qu’aucun HEIF ne mettra à l’épreuve ; les sorties sont la moitié large ici. Un dossier se convertit avec une ligne de progression par fichier, et un bouton « tout en ZIP » apparaît une fois que deux sont terminés — qui vaut la peine d’être utilisé, puisque les bitmaps non compressés se compriment bien à l’intérieur d’un ZIP.

Le PNG est sans perte aussi, donc il ne jette rien qu’un bitmap aurait gardé, et il fait une fraction de la taille — la même photographie de douze mégapixels qui devient 36,6 Mo ici arrive en général sous 20 Mo en PNG et souvent bien en dessous. Il porte aussi un canal alpha et une somme de contrôle sur chaque chunk, donc un fichier tronqué est détecté plutôt qu’affiché silencieusement avec des ordures en bas.

Les deux choses que le BMP a et que le PNG n’a pas sont les raisons d’être sur cette page : la disposition des pixels est fixée et trivialement analysable sans aucune décompression, et tout logiciel de tout âge l’accepte. Si votre système destinataire est une application moderne qui se trouve simplement avoir BMP dans sa boîte de dialogue de fichier, le PNG est le meilleur fichier. Si c’est une machine, une image de micrologiciel ou un programme compilé il y a deux décennies, restez ici.