Structure d'une image bitmap .bmp

En particulier pour ygeronimi:

Citation :

Les informations générales

Les informations générales commencent avec le début du fichier, c'est à dire de l'octet 0 et s'achèvent à l'octet 10.
Voici ces informations :

Offset Longueur Signification
(position) (en octets)
0 2 Contient normalement BM pour confirmer que l'image est bien un bitmap
2 4 Taille du fichier, sans la partie d'en-tête
6 2 Réservé. Normalement à zéro (0)
8 2 Réservé. Normalement à zéro (0)
10 4 Offset à partir duquel commencent les données.

Hormis la confirmation du type d'image (Offset 0), ces informations sont rarement utilées. On passe généralement directement aux informations d'en-tête.

Les informations d'en-tête

Ces informations suivent directement les informations générales. Elles commencent donc au 14ème octet. Elles donnent des renseignements sur l'image proprement dite : largeur, hauteur, nombres de couleurs...

Offset Longueur Signification
(position) (en octets)
14 4 Taille des information d'en-tête, soit 40, soit 12
18 4 Largeur de l'image, en pixels
22 4 Hauteur de l'image, en pixels
26 2 Nombre de plan, doit être à 1
28 2 Nombre de bits par pixels. Les valeurs peuvent être 1, 4, 8 ou 24
30 4 Compression, doit normalement être à zéro. Sinon, c'est une image RLE
34 4 Taille de l'image, en octets
38 4 Largeur de l'image, dans une autre unité
42 4 Hauteur de l'image, dans une autre unité
46 4 Nombre de couleurs utilisées par l'image. Si 0, alors toutes les couleurs
sont utilisées.
50 4 Nombre de couleurs importantes. Si 0, alors toutes les couleurs sont
importantes.

La palette

La palette représente les couleurs utilisées par l'image. Elles sont codées en RGB : Red, Green et Blue. Selon les valeurs de ces composantes, on obtient différentes couleurs. Chaque composante peut varier de 0 à 255.
Attention! Pour les fichiers bitmap 24 bits, il n'y a pas de palette!
Voici comment obtenir ces couleurs :

Offset Longueur Signification
(position) (en octets)
14 + Taille de l'en-tête 1 Intensité du Bleu de la couleur 0
14 + Taille de l'en-tête + 1 1 Intensité du Vert de la couleur 0
14 + Taille de l'en-tête + 2 1 Intensité du Rouge de la couleur 0
14 + Taille de l'en-tête + 3 1 Inutilisé. Doit être à zéro.
14 + Taille de l'en-tête + 4 1 Intensité du Bleu de la couleur 1
... ... ...

Les données

Les données représentent l'index de la couleur de chaque pixel de l'image.
Elles commencent dans le coin inférieur gauche de l'image. Chaque donnée de plus est un pixel vers la droite.
Ensuite, tout dépend du nombre de bits par pixels de l'image :

Bits par pixels Représentation

1 (monochrome) 8 pixels (horizontaux) sont représentés dans un octet.
Chaque bit de cet octet représente la couleur: 0 pour noir 1 pour blanc.
4 (16 couleurs) Un octet représente 2 pixels de l'image. Les 4 bits de poids fort représentent la couleur du 1er pixel, et les 4 bits de poids faible la couleur du 2ème pixel.
8 (256 couleurs) Le plus simple. Chaque octet représente la couleur d'un pixel.
24 (16777216 couleurs) Comme dit plus haut, pour ce type d'image, il n'y a pas de palette. Chaque pixel est représenté par 3 octets. Chacun de ces 3 octets correspond à l'intensité d'une des 3 composantes RGB du pixel.

Toutes ces informations sont facilement accessible à l'aide des instructions Panoramic pour fichiers binaires.
(PS: j'avais mis quelques tabulations, mais elles ont été bouffées par le forum).

Merci JL35 à mettre dans notre BDD infos utiles

Merci Jicehel (c'est la suite des merci de merci), la présentation n'est pas ce que j'avais prévu, mais le forum a tout fichu en l'air avec mon copier/coller).
J'ai édité pour que ce soit plus lisible mais ce n'est pas satisfaisant, je ne sais pas faire de tabulations.

jusque là tout va bien, mais

si j'ouvre un fichier par "filebin_open_write" puis je lis chaque octet par un boucle :

Code:

filebin_open_write N,File$
  for x%=1 to filebin_size(N)
      filebin_read N,Octet%
      item_add memo N,str$(Octet%)
  Next x%
filebin_close

j'obtiens des valeurs. Comment les traduires en texte pour les infos ?

Regarde les codes qu'à publié Nardo récemment, c'est exactement ça ...

je n'arrive pas à retrouver le bon post,

dans un il parle de Intel ( je vois pas de correspondance )
dans les autes ( récents ) je ne vois pas de traduction...

Ça dépend de ce que tu recherches, mais par exemple tu veux lire une valeur numérique. elle peut être codée sur 1 octet, 2 octets, 4 octets etc, mais ça il faut le savoir à l'avance, on ne peut pas l'inventer ni le savoir rien qu'en regardant le fichier, c'est une convention d'origine.
Sur 1 octet on peut mettre une valeur entre 0 et 255, sur 2 octets 0 à 65535, sur 3 octets 0 à 16777215 etc.
Si par exemple une valeur est codée sur 4 octets, chaque octet pèse 256 fois plus que l'octet précédent (c'est aussi une convention).

Si on revient à la lecture des dimensions de l'image en pixels, largeur et hauteur, qui se trouvent à partir de l'octet 18 du fichier, et qui sont codées sur 4 octets (donc la longueur 4 octets et la hauteur les 4 octets suivants), il faut écrire:

Code:

    FILEBIN_POSITION 1, 18: ' Positionnement dans le fichier, pour la lecture
    FOR ii% = 1 TO 8: FILEBIN_READ 1, v%(ii%): NEXT ii%: ' Lecture des 8 octets d'un coup
    wi% = v%(1) + 256*v%(2) + 256*256*v%(3) + 256*256*256*v%(4): ' largeur (les 4 premiers)
    hi% = v%(5) + 256*v%(6) + 256*256*v%(7) + 256*256*256*v%(8): ' hauteur (les 4 suivants)

Tu remarqueras les multiplications par 256, pour tenir compte du poids de chaque octet.

PS on s'est croisés...

Juste une petite remarque, pour compliquer un peu les choses
Il y a deux types de codage des valeurs en mémoire, comme si ce n'était pas assez compliqué comme ça, les poids faibles en premier (codage Intel, ou Little Indian) ou les poids forts en premier (codage Motorola, Big Indian).
Pour nous, sous Windows, c'est Little Indian, c'est à dire poids faibles d'abord (comme ci-dessus).

D'où la proposition de Nardo d'avoir le paramètre pour pouvoir lire directement la valeur sans avoir à remettre dans le bon ordre et d'appliquer les multiplication par 256

j'avais réussi à décripter les deux premiers qui sont des lettres et correspondent aux valeurs des codes touches du clavier.

mais là tu viens d'éclairer ma lanterne...

Sur l'image que j'ai pris pour exemple de travail, la taille est simple puisque inferieur à 256 pixels que ce soit en hauteur ou largeur donc elle est dans le premier octet dédié mais pour plus grand j'aurai été embêté...

après je cherchais un truc sur deux octets mais avec deux valeurs qui n'avaient aucun sens pour moi...
mais avec ton explication... je comprends mieux...

merci pour toutes ces explications JL35


Edit : Je pense que ce post pourrait être gardé dans les tutoriels...

@Jicehel
Oui, c'est intéressant si on a beaucoup de lectures à faire, mais là c'est une seule fois (dans le s/p), et c'est l'ordinateur qui fait le boulot désagréable...

@ygeronimi
Après tout le binaire (ou sa traduction hexa) est le b a ba de l'informatique, c'est comme ça que tout fini, c'est pour ça qu'il est intéressant de pouvoir le lire, pour n'importe quel fichier, ne serait-ce que par curiosité.

Pour les dimensions d'image bmp, sur 4 octets ils ont prévu large, avec 3 octets on arrive déjà à plus de 16 millions de pixels en largeur ou hauteur... imagine le picture correspondant...

Ben....pour retapisser ma chambre çà risque d'être juste...



Ps : une fois que j'aurai gagné l'euro millions


Edit: Une pause s'impose, je suis en surchauffe

Dans le cas de mon exemple l'octet 29 (dans mon list je suis obligé de commencer à 1 et pas 0)
qui doit me donner le nombre de bits par pixel a 32 pour valeur alors que dans le texte de JL35 cela devrait être 1,4,8 ou 24.

est ce normal ?


Apparemment oui ! il s'agirait d'un format bitmap gérant la transparence donc cela devrait
donner un codage sur 4 octets par pixel R,G,B,Alpha. Alpha, le canal de transparence.

Bonjour,

Juste un petit "+" concernant le bout de code de JL35 :

Code:

FILEBIN_POSITION 1, 18
FOR ii% = 1 TO 8: FILEBIN_READ 1, v%(ii%): NEXT ii%: ' Lecture des 8 octets d'un coup
wi% = v%(1) + 256*v%(2) + 256*256*v%(3) + 256*256*256*v%(4): ' largeur (les 4 premiers)
hi% = v%(5) + 256*v%(6) + 256*256*v%(7) + 256*256*256*v%(8): ' hauteur (les 4 suivants)

Il existe une fonction auquel on ne pense pas souvent:

Code:

FILEBIN_POSITION 1, 18: FILEBIN_BLOCK_READ 1,8,v%(1)
FOR i=4 TO 1 STEP -1:wi%=(wi%*256)+v%(i) : hi%=(hi%*256)+v%(4+i): NEXT i

Merci Jack pour cette commande !

Bien vu Nardo, ça c'est la classe !

c'est vrai, je n'y avais pas pensé, 2 lignes de gagnées, et c'est beaucoup plus élégant que mes multiplications par 256, j'aime bien.
merci et bravo !

PS il vaut mieux quand même avant initialiser wi% et hi% à zéro.

Code:

FILEBIN_POSITION 1, 18: FILEBIN_BLOCK_READ 1,8,v%(1): wi% = 0: hi% = 0
FOR ii%=4 TO 1 STEP -1:wi%=(wi%*256)+v%(ii%) : hi%=(hi%*256)+v%(4+ii%): NEXT ii%

De rien JL...
Elle est d'autant plus intéressante car c'est une des rares commande qui nécessite un tableau en paramètre...

Ou ai je créé mon bug ?...



PS : les initialisations des variables n'y sont pour rien, je les ai enlever et c'est pareil...

C'est normal. Regarde la doc:

Si tu regardes la 8ème ligne des conditions d'erreur, tu as ton explication.

mon tableau est déclaré v%(8 )

V%()>=P+C-1 = V%(8 ) >=1+8-1


Edit : erreur dans la doc, v%() doit être > P+C-1

Non, la doc est bonne. Dans ton cas:
P=1 C=8 P+C+1=10
Ton tableau est dimensioné à 8, ce qui est inférieur à 10 ! D'où l'erreur.

regarde bien,

c'est écrit P+C-1 pas +1

en plus je lui demande de lire 2 block de 4 octet donc 8 octets
mon tableau a 9 place avec le v%(0)....