Discussion :

[micdie]

Bonjour,

je crée un programme de fractale de Mandelbrot. Ce programme ce compose notamment d'un module de creation de l'image sous format.bmp.
Le probleme que je rencontre est le suivant:

1) j'ai un fichier binaire resultats.dat composé exclusivement de valeur int (les deux premières correspondent à la largueur et hauteur de l'image, ici 800 x 600)
2) je lis ce fichier int après int et à chaque valeur je fait correspondre une valeur de couleur sous trois octets (24 bits).
3) lorsque je visionne l'image celle-ci ne correspond pas aux valeurs que je peux observer dans mon fichier resultats.dat. Par exemple la dernière ligne est composée exclusivement de valeur 0 => je devrais avoir uniquement des pixels de couleur jaune, ce qui n'est pas le cas. De plus l'image ne me semble pas complète.

Ma conclusion est que je définit mal le header du fichier .bmp mais je ne vois pas où.

Pouvez-vous m'aider?

mon code:

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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
int creeimage(char *mybmp)
{
	int i=0;
	int j=0;
	int taille_fich=0;
	int data=0;
	int larg=0;
	int haut=0;
	entfichier entetfich;
	entimage entetimag;
	mapalet palette[NMAX+1];
	FILE *fdbmp; /* fd pour le fichier .bmp */
	FILE *fdres; /* fd pour le fichier resultats.dat */
 
		/* Ouverture fichier resultats.dat en lecture */
 
	if ((fdres=fopen(MYDATA_FILE,"r"))==NULL)
	{
		fprintf(stderr,"Erreur d'ouverture file descriptor res\n");
	}
 
	/* Lecture du fichier resulats.dat et conversion en valeur RGB suivant palette */
 
	/* On s'assure que l'on est au debut du fichier */
 
	rewind(fdres);
 
	/* On récupère les informations de resolution de l'image */
 
	fread(&larg,sizeof(int),1,fdres);
	fread(&haut,sizeof(int),1,fdres);
 
	/* On calcule la taille du fichier en octets */
 
	taille_fich=54+(larg*haut*PROFON)/8;
 
	/* Definition de l'entete du fichier sur 14 octets */
 
	entetfich.type[0]=66;
	entetfich.type[1]=77;
	entetfich.taille=taille_fich;
//	entetfich.taille=5769858;
	entetfich.reserv1=0;
	entetfich.reserv2=0;
	entetfich.offset=105; /* taille entetfich + entetimag + palette */
 
	/* Definition de l'entete de l'image sur 40 octets */	
 
	entetimag.taille=40;
	entetimag.largeur=800;
	entetimag.hauteur=-600;
	entetimag.nbreplan=1;
	entetimag.prof=24;
	entetimag.compress=0;
	entetimag.tailleimage=1440000;
	entetimag.resol_horiz=1500;
	entetimag.resol_vert=1500;
	entetimag.nbrcouleurs=51;
	entetimag.nbrcoulimp=0;
 
 
	/* Definition de la palette de couleur */
 
	/* Elements appartenant à l'ensemble */
 
	palette[NMAX].rg=0; 
	palette[NMAX].vt=0;
	palette[NMAX].bl=0;
	palette[NMAX].resrv=0;
 
	/* Elements proche de l'ensemble */
 
	for (i=1;i < ((NMAX)/2);i++)
	{
		palette[i].rg=127;
		palette[i].vt=255;
		palette[i].bl=255-(i*5);
		palette[i].resrv=0;
	}
 
	/* Elements eloignes de l'ensemble */
 
	for (i=((NMAX)/2)+1;i < NMAX-1;i++)
	{
		palette[i].rg=127+2;
		palette[i].vt=255-(j*5);
		palette[i].bl=0;
		palette[i].resrv=0;
	}
 
	/* Elements n'appartenant pas à l'ensemble */
 
	palette[0].rg=255; 
	palette[0].vt=255;
	palette[0].bl=0;
	palette[0].resrv=0;
 
	/* Creation et ouverture du fichier en mode binaire */
 
	if ((fdbmp=fopen(mybmp,"wb"))==NULL)
	{
		fprintf(stderr,"Erreur d'ouverture file descriptor bmp\n");
	}
 
	/* Ecriture de l'entete du fichier */
 
	fwrite(&entetfich.type[0],sizeof(char),1,fdbmp);
	fwrite(&entetfich.type[1],sizeof(char),1,fdbmp);
	fwrite(&entetfich.taille,sizeof(int),1,fdbmp);
	fwrite(&entetfich.reserv1,sizeof(short int),1,fdbmp);
	fwrite(&entetfich.reserv2,sizeof(short int),1,fdbmp);
	fwrite(&entetfich.offset,sizeof(int),1,fdbmp);
 
	/* Ecriture de l'entete de l'image */
 
	fwrite(&entetimag.taille,sizeof(int),1,fdbmp);
	fwrite(&entetimag.largeur,sizeof(int),1,fdbmp);
	fwrite(&entetimag.hauteur,sizeof(int),1,fdbmp);
	fwrite(&entetimag.nbreplan,sizeof(short int),1,fdbmp);
	fwrite(&entetimag.prof,sizeof(short int),1,fdbmp);
	fwrite(&entetimag.compress,sizeof(int),1,fdbmp);
	fwrite(&entetimag.tailleimage,sizeof(int),1,fdbmp);
	fwrite(&entetimag.resol_horiz,sizeof(int),1,fdbmp);
	fwrite(&entetimag.resol_vert,sizeof(int),1,fdbmp);
	fwrite(&entetimag.nbrcouleurs,sizeof(int),1,fdbmp);
	fwrite(&entetimag.nbrcoulimp,sizeof(int),1,fdbmp);
 
	/* Ecriture de la palette de couleur */
 
	for (i=0;i<NMAX;i++)
	{
		fwrite(&palette[i],sizeof(int),1,fdbmp);
	}
 
	/* On recupere une a une les donnees du fichier resultat pour chaque ligne */
	i=0;
	while(!feof(fdres))
	{
		i++;
		for (j=0;j<larg;j++)
		{
			fread(&data,sizeof(int),1,fdres);
 
			/* Ecriture des valeurs en RGB pour chaque points */
 
			fwrite(&palette[data].rg,sizeof(int),1,fdbmp);
			fwrite(&palette[data].vt,sizeof(int),1,fdbmp);
			fwrite(&palette[data].bl,sizeof(int),1,fdbmp);
			fprintf(stderr,"j %d data %d ",j,data);
		}
		fprintf(stderr,"iteration %d\n",i);
	}
 
	/* Fermeture du fichier */
 
	fclose(fdbmp);
	return 0;
}

L'image que je reçoit en fichier attaché.

[Emmanuel Delahaye]

je crée un programme de fractale de Mandelbrot. Ce programme ce compose notamment d'un module de creation de l'image sous format.bmp.
Le probleme que je rencontre est le suivant:

1) j'ai un fichier binaire resultats.dat composé exclusivement de valeur int (les deux premières correspondent à la largueur et hauteur de l'image, ici 800 x 600)
2) je lis ce fichier int après int et à chaque valeur je fait correspondre une valeur de couleur sous trois octets (24 bits).
3) lorsque je visionne l'image celle-ci ne correspond pas aux valeurs que je peux observer dans mon fichier resultats.dat. Par exemple la dernière ligne est composée exclusivement de valeur 0 => je devrais avoir uniquement des pixels de couleur jaune, ce qui n'est pas le cas. De plus l'image ne me semble pas complète.

Pour le moment, je n'ai pas lu ton code, mais le format des BMP est très précis et doit être suivi à la lettre. Comme c'est un format binaire, il n'est évidemment pas question d'enregistrer directement une structure, dont la représentation mémoire peut changer d'une réglage de compilateur à l'autre. Il faut être indépendant et ne travailler qu'au niveau octet en suivant la spécification BMP à la lettre.

Avant de me plonger dans le code, est-ce bien le cas ?

[Médinoc]

Je ne connais pas les structures entfichier et entimage. Elles ne sont spécifiées ni dans les standards, ni dans l'API Windows (qui gère les bitmaps nativement) qui possède BITMAPFILEHEADER et BITMAPINFOHEADER...

[micdie]

Emmanuel,

oui je travaille au biveau des octets => fichier binaire, instruction fwrite (*buff,sizeof(),nbre,*FILE);

pour médinoc:

voici les structures que jai déclrarée dans un fichier entetes:

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
typedef struct
{
	char type[2]; /* 2 octets */
	int taille; /* 4 octets */
	short int reserv1; /* 2 octets */
	short int reserv2; /* 2 octets */
	int offset; /* 4 octets */
} entfichier;
 
typedef struct
{
	int taille; /* 4 octets - windows=28 */ 
    int largeur; /* 4 octets */
    int hauteur; /* 4 octets */
    short int nbreplan; /* 2 octets - toujours 1 */
    short int prof; /* 2 octets */
    int compress; /* 4 octets - 0 si non compressé - 3 si palette */
    int tailleimage; /* 4 octets */
    int resol_horiz; /* 4 octets c'est-à-dire le nombre de pixels par mètre horizontalement */
    int resol_vert; /* 4 octets c'est-à-dire le nombre de pixels par mètre verticalement */
    int nbrcouleurs; /* 4 octets */
    int nbrcoulimp; /* 4 octets Ce champ peut être égal à 0 lorsque chaque couleur a son importance. */
} entimage;
 
typedef struct
{
	char rg; /* composante rouge - un octet */
	char vt; /* composante verte - un octet */
	char bl; /* composante bleue - un octet */	
	char resrv; /* un octet */ 
} mapalet;

[micdie]

Pour information je travaille sous Fedora Core 5 avec le compilateur gcc 4.1.1

Dans la documentation windows, il parle notamment d'une constante BI_BITFIELDS pour la valeur de compression, mais cette constante nest pas reconnue par mon systeme => j'ai créer les différentes structures décritent dans ma précédente réponse.

[Médinoc]

Code :

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

1
2
	char type[2]; /* 2 octets */
	int taille; /* 4 octets */

Une structure BITMAPFILEHEADER est en packed(2), tu dois refléter cela dans ton fichier d'en-tête.
Regarde si tu ne disposes pas de headers <pshpack2.h> et <poppack.h> avec ton GCC. Si oui, utilise-les, l'application sera compatible avec Visual. Si non, il te restera l'__attribute__ correspondant...

[Emmanuel Delahaye]

oui je travaille au biveau des octets => fichier binaire, instruction fwrite (*buff,sizeof(),nbre,*FILE);

OK, mais ça :

voici les structures que jai déclrarée dans un fichier entetes:

Code :

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

1
2
3
4
5
6
7
8
typedef struct
{
	char type[2]; /* 2 octets */
	int taille; /* 4 octets */
	short int reserv1; /* 2 octets */
	short int reserv2; /* 2 octets */
	int offset; /* 4 octets */
} entfichier;

C'est exactement le genre de choses que je voulais pas voir.

Une structure C ne sait pas faire de mapping de façon portable. Les tailles que tu indiques ne sont pas garanties par le langage. et je ne parle pas des questions de padding et d'endianness.

Que tu utilises une structure en interne pur organiser tes données, aucun problème. Mais pas pour générer une l'image binaire d'une structure définie en dur comme un entête de fichier binaire.

Soit, comme le propose Médinoc, tu utilises des structures prédéfinies par Windows et qui sont censées générer le bon mapping (probablement la meilleur solution sous Windows, mais non portable),

soit tu écris toi même les bytes un par un séquentiellement dans le fichier (ou dans un tableau de unsigned char, puis en bloc dans le fichier, c'est pareil), et le code est portable.

[micdie]

OK merci pour votre aide.

<pshpack2.h> et <poppack.h> ne sont apparament pas disponible avec gcc.

Je travaille ce soir sur l'ecriture des header bytes par bytes.

Une structure C ne sait pas faire de mapping de façon portable. Les tailles que tu indiques ne sont pas garanties par le langage.

Question: j'ai testé dans une version précédente la taille d'un int, d'un short int ainsi que d'un char, il était respectivement de 4, 2 et 1 sur mon système. Pour la portabilité, cela peux effectivement poser problème mais sur mon système en quoi ai-je une corruption de mes header BMP?



Bonne soirée

[Médinoc]

un mot: alignement...

[Emmanuel Delahaye]

Question: j'ai testé dans une version précédente la taille d'un int, d'un short int ainsi que d'un char, il était respectivement de 4, 2 et 1 sur mon système. Pour la portabilité, cela peux effectivement poser problème mais sur mon système en quoi ai-je une corruption de mes header BMP?

On a pas à se poser ce genre de question si on choisit dès le début d'écrire du code portable...

Pour répondre à ta question, il y a beaucoup de facteurs qui peuvent jouer.

• La taille réelle des objets (ça semble réglé)
• L'endianess (représentation des valeurs numériques dans les objets d'une taille supérieure à 1)
• La phase la lune
• Le padding (espace 'vide' d'alignement entre les champs de la structure ou à la fin).

[micdie]

Medinoc,

je ne te suis pas, peux-tu expliquer s'il te plait.

Merci

[Emmanuel Delahaye]

Medinoc,

je ne te suis pas, peux-tu expliquer s'il te plait.

Padding. C'est pas une FAQ ?

[micdie]

Merci,

j'ai appris quelque chose de nouveaux pour moi.

Bonne soirée