[C++] Coder / Décoder un fichier Bitmap

doccpu · 13/09/2006, 11h42

Bonjour,

J'aimerais savoir ou je peux trouver une documentaion sur la manière de coder / decoder un fichier bitmap normal (non RLE) ?

Ce qui m'interesse surtout c'est le codage des données à partir de l'adresse 0x36(hexa). J'ai la version 24 bit(16MCouleurs) et la version 1 bit (N & B), mais impossible de trouver/comprendre les codage 4bits(16Couleurs) et 8bits(256Couleurs).

merci d'avance...

**Médinoc** · 13/09/2006, 11h54

Renseigne-toi sur les structures BITMAPINFO et BITMAPINFOHEADER : Elles contiennent les informations sur le bitmap en mémoire et dans le fichier (dans le fichier, elles sont précédées de la structure BITMAPFILEHEADER).

En bitmap 1, 4 et 8 bits, la structure BITMAPINFO est composée d'une structure BITMAPINFOHEADER et de (géralement) 2^n structures RGBQUAD indiquant la palette de couleurs. Le tout est suivi des "Bitmap Bits", les données de l'image elle-même.

Note: J'ai déjà vu un programme qui enregistrait mal l'offset dans la BITMAPFILEHEADER. Généralement, les Bitmap Bits se trouvent immédiatement après la BITMAPINFO.

doccpu · 13/09/2006, 12h17

Envoyé par Médinoc

En bitmap 1, 4 et 8 bits, la structure BITMAPINFO est composée d'une structure BITMAPINFOHEADER et de (géralement) 2^n structures RGBQUAD indiquant la palette de couleurs.

Je n'utilise pas les structure windows BitmapInfo et RGBQuad (pour le moment en tout cas) mais ta phrase vas m'etre utile quand meme.

Comme je l'ai plus ou moins clairement expliqué plus haut ce qui m'interesse c'est la facon de lire les données du mapage des pixels pour les versions 4bits et 8bits parceque je les recupere dans un "unsigned char *".

D'apres ce que tu m'a dit la pallette est codé avec des quad RVB ce qui signifie que les couleurs sont ecrite sur 4 octet (RVBX où X=0x00) sur 2^n Quartet a partir de l'adresse 0x36, merci de l'info.

Pourais tu m'expliquer comment Paint code les données en 4bits à partir de l'adresse 0x76 svp ? (en sachat que normalement si je me trompe pas le premier pixel est en bas a gauche de l'image)

**Médinoc** · 13/09/2006, 13h26

Attention: Ce n'est pas 2^n octets, c'est 2^n structures RGBQUAD (quatre octets chacune).

Le premier pixel peut être en bas en haut de l'image (mais toujours à gauche) selon le signe du champ "hauteur" (biHeight) de la BITMAPINFOHEADER.

Pour du 4bits, c'est simple: Un quartet par pixel, le quartet haut étant à gauche si je me souviens bien.
(c'est beaucoup plus simple que l'Amstrad CPC où les bits étaient entrelacés)

PS: Pour les offsets, je ne sais pas, j'utilise toujours les structures, donc sizeof()...

doccpu · 13/09/2006, 14h45

Envoyé par Médinoc

Attention: Ce n'est pas 2^n octets, c'est 2^n structures RGBQUAD (quatre octets chacune).

Desolé, j'ai corrigé !

Envoyé par Médinoc

Le premier pixel peut être en bas en haut de l'image (mais toujours à gauche) selon le signe du champ "hauteur" (biHeight) de la BITMAPINFOHEADER.

En est tu sûr ! D'apres la doc que j'ai, à l'adresse 0x22 et sur 4 octet, j'ai la valeur de la longueur en octets des données de l'image mais il n'est pas precisé qu'il y a un signe. Je voudrais bien savoir ou tu a lu ca ?

[/QUOTE]Pour du 4bits, c'est simple: Un quartet par pixel, le quartet haut étant à gauche si je me souviens bien.
(c'est beaucoup plus simple que l'Amstrad CPC où les bits étaient entrelacés)

Ben en fait je sait pas trop parce que moi j'ai un fichier Paint qui contien ca (BigEndian (intel)) :

0x00:
424D = "BM"
0x02:
86000000 = FileLength
0000 = (reservé) = 0
0000 = (reservé) = 0
76000000 = Depart des données = 118
28000000 = taille du header INFO
10000000 = Largeur = 16
02000000 = Hauteur = 2
0100 = Color Planes = 1
0400 = Bit / pixel = 4 (16 couleurs)
00000000 = Compression = 0 (RGB)
10000000 = picture size = 16
00000000 = HResolution (inutilisé) = 0
00000000 = VResolution (inutilisé) = 0
00000000 = number of color used (inutilisé) = 0
00000000 = number of important color (inutilisé) = 0
0x36 : // debut de la palette
00000000 = Noir
00008000
00800000
00808000
80000000
80008000
80800000
80808000 = Gris Foncé
C0C0C000 = Gris clair
0000FF00 = Rouge
00FF0000 = Vert
00FFFF00 = Jaune
FF000000 = Bleu
FF00FF00 = Magenta
FFFF0000 = Cyan
FFFFFF00 = Blanc

0x78: // données du mapage bitmap c'est la que je pige pas trop : A quoi correspond CA 90 (11001010 10010000)
CA90000000000000 // <- 2eme ligne ?
FFFFFFFFFFFFFFFF // <- 1ere ligne ?

mon image bmp a 2 lignes x 16 colones ( origine : Coin Haut Gauche ) :
Ligne 1 : 16 pixels blanc,
Ligne 2 : 1 pixel bleu, 1 pixel vert, 1 pixel rouge, et 13 pixel noir

PS:
CA = 202
90 = 144

**Médinoc** · 13/09/2006, 16h02

C'est la hauteur de l'image qui est signée, pas la taille en octets...
Ici, la taille est positive, le bitmap va donc de bas en haut (la ligne du bas en premier).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
BITMAPFILEHEADER (14 octets):
0x00:	bfType      = 424D           = "BM"
0x02:	bfSize      = 86000000 (134) = FileLength
	bfReserved1 = 0000           = (reservé)
	bfReserved2 = 0000           = (reservé)
	bfOffBits   = 76000000 (118) = Depart des données
 
BITMAPINFOHEADER (40 octets):
0x0E:	biSize          = 28000000  (40) = taille de la BITMAPINFOHEADER
	biWidth         = 10000000  (16) = Largeur (signé mais >0)
	biHeight        = 02000000   (2) = Hauteur (signé, détermine le sens du bitmap)
	biPlanes        = 0100       (1) = Planes (toujours 1)
	biBitCount      = 0400       (4) = Bit / pixel (ici, 16 couleurs)
	biCompression   = 00000000   (0) = Compression (0 = BI_RGB)
	biSizeImage     = 10000000  (16) = taille de l'image en octets (peut être 0)
	biXPelsPerMeter = 00000000   (0) = HResolution (réglé par les scanners)
	biYPelsPerMeter = 00000000   (0) = VResolution (réglé par les scanners)
	biClrUsed       = 00000000   (0) = number of color used (0 = maximum)
	biClrImportant  = 00000000   (0) = number of important color (inutilisé)
 
Suivent 16 structures RGBQUAD Bleu-Vert-Rouge (64 octets).
0x36:	00000000 (#000000) =  0-Noir
	00008000 (#800000) =  1-Rouge foncé
	00800000 (#008000) =  2-Vert foncé
	00808000 (#808000) =  3-Marron
	80000000 (#000080) =  4-Bleu foncé
	80008000 (#800080) =  5-Magenta foncé
	80800000 (#008080) =  6-Cyan foncé
	80808000 (#808080) =  7-Gris Foncé
	C0C0C000 (#C0C0C0) =  8-Gris clair
	0000FF00 (#FF0000) =  9-Rouge
	00FF0000 (#00FF00) = 10-Vert
	00FFFF00 (#FFFF00) = 11-Jaune
	FF000000 (#0000FF) = 12-Bleu
	FF00FF00 (#FF00FF) = 13-Magenta
	FFFF0000 (#00FFFF) = 14-Cyan
	FFFFFF00 (#FFFFFF) = 15-Blanc
 
Suivent les données du bitmap:
0x76:	CA = Couleur 12 (bleu), couleur 10 (vert)
0x77:	  90 = Couleur 9 (rouge), couleur 0 (noir)
0x78:	    000000000000 = couleur 0 (noir)
0x7E:	FFFFFFFFFFFFFFFF = couleur 15 (blanc)

doccpu · 13/09/2006, 16h20

Envoyé par Médinoc

C'est la hauteur de l'image qui est signée, pas la taille en octets...
Ici, la taille est positive, le bitmap va donc de bas en haut (la ligne du bas en premier).

Si tu le dit, mais j'ai pas encore vu le cas. Je le verais surement à l'occasion !

Envoyé par Médinoc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
[...]
biXPelsPerMeter = 00000000   (0) = HResolution (réglé par les scanners)
	biYPelsPerMeter = 00000000   (0) = VResolution (réglé par les scanners)
 
	biClrUsed       = 00000000   (0) = number of color used (0 = maximum)
[...]
Suivent les données du bitmap:
0x76:	CA = Couleur 12 (bleu), couleur 10 (vert)
0x77:	  90 = Couleur 9 (rouge), couleur 0 (noir)
0x78:	    000000000000 = couleur 0 (noir)
0x7E:	FFFFFFFFFFFFFFFF = couleur 15 (blanc)

(J'ai gardé que les truc interessant pour moi)

Je me disait bien que ca devais fonctionner avec un truc comme ca mais j'arrivais pas a metre le doigt dessus !

Merci du tuyaud !

J'imagine que c'est la meme chose pour du 8 bit avec des valeurs d'index codé sur 8 bit non ? (00 = 1ere couleur à 0x36, et FF dernierre couleur indexé avant le debut des données)

**Médinoc** · 13/09/2006, 16h26

Envoyé par doccpu

Si tu le dit, mais j'ai pas encore vu le cas. Je le verais surement à l'occasion !

En fait, j'ignore si ça peut être le cas dans un bitmap sauvegardé sur le disque. Mais c'est le cas en mémoire dans certains programmes qui écrivent directement dans la mémoire d'un bitmap.

Envoyé par doccpu

J'imagine que c'est la meme chose pour du 8 bit avec des valeurs d'index codé sur 8 bit non ? (00 = 1ere couleur à 0x36, et FF dernierre couleur indexé avant le debut des données)

Oui, c'est ça.

doccpu · 13/09/2006, 16h29

nikel chrome ! merci pour tout !

**Médinoc** · 13/09/2006, 17h12

Note: Les couleurs dans ta palette ne semble pas être les couleurs standard 16 bits.

Normalement, les couleurs standard CGA sont dans cet ordre (celui défini par les couleurs de console dans wincon.h) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
0-Noir,        1-Bleu foncé,    2-Vert foncé, 3-Cyan foncé,
4-Rouge foncé, 5-Magenta foncé, 6-Marron,     7-Gris clair,
8-Gris foncé,  9-Bleu,          A-Vert,       B-Cyan,
C-Rouge,       D-Magenta,       E-Jaune,      F-Blanc.

http://en.wikipedia.org/wiki/List_of...tes#4-bit_RGBI

doccpu · 13/09/2006, 17h21

Alors vas te plaindre a microsoft (j'utilise Paint sous XP)

doccpu · 14/09/2006, 19h01

Envoyé par Médinoc

biSizeImage = 10000000 (16) = taille de l'image en octets (peut être 0)

Erreur : ne peut etre inferieur a 4

Taille mini d'une image 1x1 pixel

meme codé sur 1 bit soit sur le premier octet : 80(blanc), 00(noir)
le format des données de l'image doivent etre alignés sur 32 bit donc le fichier doit avoir au minimum 4 octets : 80 00 00 00(blanc), 00 00 00 00(noir)

**Médinoc** · 15/09/2006, 09h53

Envoyé par [URL=http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmaps_1rw2.asp]MSDN[/URL]

biSizeImage

Specifies the size, in bytes, of the image. This may be set to zero for BI_RGB bitmaps.

Avant de dire que je fais une erreur, vérifie tes sources...

Je ne fais jamais d'erreur.

doccpu · 15/09/2006, 10h06

Envoyé par Médinoc

Avant de dire que je fais une erreur, vérifie tes sources...

Je ne fais jamais d'erreur.

BI_RGB s'applique a biCompression !
(sans vouloir contester ton immence génie, et la perfection de tes remarques)

biSizeImage definit la taille des données en octets du champs de pixel qui ne peut etre inferieur a 4. c'est vrais que sur ce coup la MSDN a fait une grosse erreur ! Si tu ne me crois pas crée un fichier bitmap de 1*1 en monochome et enregistre le ! ouvre le avec un editeur hexa et tu vera !

biCompression
Specifies the type of compression for a compressed bottom-up bitmap (top-down DIBs cannot be compressed). This member can be one of the following values. Value Description
BI_RGB An uncompressed format.
BI_RLE8 A run-length encoded (RLE) format for bitmaps with 8 bpp. The compression format is a 2-byte format consisting of a count byte followed by a byte containing a color index. For more information, see Bitmap Compression.
BI_RLE4 An RLE format for bitmaps with 4 bpp. The compression format is a 2-byte format consisting of a count byte followed by two word-length color indexes. For more information, see Bitmap Compression.
BI_BITFIELDS Specifies that the bitmap is not compressed and that the color table consists of three DWORD color masks that specify the red, green, and blue components, respectively, of each pixel. This is valid when used with 16- and 32-bpp bitmaps.
BI_JPEG Windows 98/Me, Windows 2000/XP: Indicates that the image is a JPEG image.
BI_PNG Windows 98/Me, Windows 2000/XP: Indicates that the image is a PNG image.

biSizeImage
Specifies the size, in bytes, of the image. This may be set to zero for BI_RGB bitmaps.

**Médinoc** · 15/09/2006, 10h19

Le problème n'est pas dans la taille de l'image en pixels.
Le problème, c'est que le champ "taille en octets" peut être zéro pour un bitmap non-compressé. Bien sûr, la véritable taille de l'image n'est pas nulle, mais elle est déductible des autres paramètres...

Au passage, ton bitmap est un BI_RGB, donc normalement, si tu l'ouvres avec un éditeur hexa et que tu remplaces la taille par zéro, tu devrais quand même pouvoir l'ouvrir avec un bon éditeur d'image...

PS: Je viens de tester avec un bitmap exactement comme le tien.
J'ai mis la taille à zéro, résultat: Paint peut l'ouvrir, mais l'aperçu Windows foire.

Donc oui, la taille peut être zéro et c'est censé marcher.

doccpu · 20/09/2006, 11h28

Envoyé par Médinoc

PS: Je viens de tester avec un bitmap exactement comme le tien.
J'ai mis la taille à zéro, résultat: Paint peut l'ouvrir, mais l'aperçu Windows foire.

Donc oui, la taille peut être zéro et c'est censé marcher.

Peut etre mais sa marche pas !

**Médinoc** · 20/09/2006, 12h47

Mais comme c'est documenté ainsi, sur un programme qui restecte le format, ça doit marcher.
Un programme qui foire là-dessus est un programme buggué.

(tu te rends compte, on a réussi à transformer un sujet simple en troll, à deux!)

doccpu · 20/09/2006, 14h34

Envoyé par Médinoc

Mais comme c'est documenté ainsi, sur un programme qui restecte le format, ça doit marcher.
Un programme qui foire là-dessus est un programme buggué.

(tu te rends compte, on a réussi à transformer un sujet simple en troll, à deux!)

En effet paint a planté 2 fois de suite le meme jour, mais maintenant j'arrive plus a le faire replanter !

(A bas M$)
Par contre GIMP 2 lui gère ce genre de fichiers parfaitement

(et vive le GNU/GPL)

C'est clair si nous arretions un peu ? parce que je commence a avoir ma boite aux lettres un peu pleine, qu'en dit tu?

mat.M · 20/09/2006, 15h34

Envoyé par Médinoc

Le premier pixel peut être en bas en haut de l'image (mais toujours à gauche) selon le signe du champ "hauteur" (biHeight) de la BITMAPINFOHEADER.

Je crois que les BMP sont lues de bas-en-haut contrairement aux PCX par exemple

(c'est beaucoup plus simple que l'Amstrad CPC où les bits étaient entrelacés

Technique classique d'utilisation des registres de cartes .
Le mode X en assembleur c'était pareil

**Médinoc** · 20/09/2006, 16h38

En fait, j'ignore si un BMP peut aller de haut en bas sur le disque.
En tout cas, en mémoire, les deux cas existent (lorsqu'on crée un bitmap à partir d'un BITMAPINFOHEADER, on peut y mettre une hauteur négative pour qu'il aille de haut en bas)...

Et sur Amstrad, le pire n'était pas les bits entrelacés: C'était les lignes entrelacées

(il y a avait ça aussi sur certains modes des PC?).

[C++] Coder / Décoder un fichier Bitmap

C++

Discussions similaires

Partager

Partager