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

Version imprimable

13/09/2006, 12h42
doccpu

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

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...
13/09/2006, 12h54
Médinoc

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.
13/09/2006, 13h17
doccpu

Citation:

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)
13/09/2006, 14h26
Médinoc

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()...
13/09/2006, 15h45
doccpu

Citation:

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é !

Citation:

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)) :

Citation:

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

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:

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)

Citation:

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 ! :?
Citation:
Envoyé par Médinoc
Code:

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 !:roll:
Merci du tuyaud ! :D ;)

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)

13/09/2006, 17h26
Médinoc

Citation:

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.

Citation:

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.
13/09/2006, 17h29
doccpu

nikel chrome ! merci pour tout !

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:

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

13/09/2006, 18h21
doccpu

Alors vas te plaindre a microsoft (j'utilise Paint sous XP) :lol:
14/09/2006, 20h01
doccpu

erratum

Citation:

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)
15/09/2006, 10h53
Médinoc

Citation:

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. :aie:
15/09/2006, 11h06
doccpu

Citation:

Envoyé par Médinoc

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

Je ne fais jamais d'erreur. :aie:

8O
BI_RGB s'applique a biCompression !
(sans vouloir contester ton immence génie, et la perfection de tes remarques)
:lol: :P :roll: 8-)

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 !

Citation:

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.
15/09/2006, 11h19
Médinoc

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.
20/09/2006, 12h28
doccpu

Citation:

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 ! :lol: 8-)
20/09/2006, 13h47
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é. 8-)

(tu te rends compte, on a réussi à transformer un sujet simple en troll, à deux!)
20/09/2006, 15h34
doccpu

Citation:

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é. 8-)

(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?
20/09/2006, 16h34
mat.M

Citation:

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

Citation:

(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
20/09/2006, 17h38
Médinoc

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 :mur: (il y a avait ça aussi sur certains modes des PC?).
21/09/2006, 18h07
mat.M

Citation:

Envoyé par Médinoc

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

Euuh la tu poses une colle :cry: ;)
21/09/2006, 18h53
Jean-Marc.Bourguet

Citation:

Envoyé par Médinoc

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

Pas que je m'en souvienne.