Lecture de fichiers binaires [résolu]

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : Lecture de fichiers binaires [résolu]

Mourfizbak

Bonjour à tous,

Je dispose de fichiers binaires volumineux (1,1 Go) représentant des images, que je traite ensuite en passant par de l'allocation dynamique. Chaque pixel est codé sur deux octets.
Dans le cas présent la valeur de mes pixels ne dépasse pas 20, or j'obtiens des valeurs totalement fantaisistes (65 536, 65 538, 131 072...).

Ces fichiers binaires sont noté subsino1.s, subsino2.s,..., subsino5.s.
Ce que je ne comprends pas c'est qu'après traitement, je lis ces fichiers avec un logiciel de traitement d'image (ImageJ) et les pixels de forte valeur ont disparus !

Voici le bout de code incriminé, où sz_subsino désigne la taille (en octet) d'une image subsino :

Code :

FILE* subsino1 = NULL ;
FILE* subsino2 = NULL ;
FILE* subsino3 = NULL ;
FILE* subsino4 = NULL ;
FILE* subsino5 = NULL ;
int *tab_subsino1;
int *tab_subsino2;
int *tab_subsino3;
int *tab_subsino4;
int *tab_subsino5;
subsino1=fopen("subsino1.s","rb" ) ;
fseek(subsino1, 0L, SEEK_SET);
tab_subsino1 = malloc(sz_subsino);
tab_subsinoboot1 = malloc(sz_subsino);
test_fread = fread (tab_subsino1, 2, sz_subsino, subsino1);
fclose(subsino1);
if (tab_subsino1 == NULL || tab_subsinoboot1 == NULL || test_fread == 0)
{
printf("Echec de l'allocation mémoire" );
exit(0);
}
/* répété pour les 5 images notées subsino1,...,subsino5) */
/* Je teste ensuite si la valeur 65 536 est présente dans le subsino (ce qui n'est pas le cas car physiquement impossible) */
for(i=0 ; i<5000000 ; i++){
if(tab_subsino1[i/sizeof(int)]==65536){
printf("Erreur 65536 : %lu\n",i/sizeof(int));
printf("subsino1 = %d, subsino2 = %d, subsino3 = %d, subsino4 = %d, subsino5 = %d\n",tab_subsino1[i/sizeof(int)],tab_subsino2[i/sizeof(int)],tab_subsino3[i/sizeof(int)],tab_subsino4[i/sizeof(int)],tab_subsino5[i/sizeof(int)]);
exit(0);
}
}

Et voici ce que me donne le compilateur (GNU GCC) ;

Erreur 65536 : 68
subsino1 = 65536, subsino2 = 0, subsino3 = 0, subsino4 = 0, subsino5 = 0

Il me semble que fread lit les valeurs "à l'envers", le problème pourrait-il venir de là ?

Merci d'avance !

Mouarfizbak

Message édité par Mourfizbak le 14-03-2012 à 10:24:58

---------------
Dans le doute, reboot, et si ça rate, formate !

Publicité

edwoud

⭐ shériff de l'espace

Un int c'est sur 32 bits (à moins que tu codes encore sous msdos ou windows 95...)

Il faut que tu déclares tes tableaux comme short int pour avoir des valeurs 16 bits. De plus, vu que ce sont des pixels avec des valeurs exclusivement positives, il faut que tu déclares unsigned short int.

ps: après une ouverture de fichier, le fseek en 0 est inutile.

Message édité par edwoud le 12-03-2012 à 13:49:25

Mourfizbak

Merci pour l'info !Du coup j'ai passé tous les tableaux en unsigned short int, mais maintenant mes fichiers après traitement sont a moitié vide (8694 images, vide à partir de l'image 4347).
Du coup je suis perdu.

Sizeof(int) me renvoit 4 (ouf !), mais dans mes fichiers chaque pixel est codé sur deux octets.

De plus, le traitement des mes fichiers m'oblige à les parcourir ligne par ligne.

Code :

while(l < sz_subsino/sizeof(unsigned short int)) {
nb_al=genrand_real2()*nb_ss_originaux+1 ;
switch(nb_al) {
case 1: tab_subsinotempo = tab_subsino1; break;
case 2: tab_subsinotempo = tab_subsino2; break;
case 3: tab_subsinotempo = tab_subsino3; break;
case 4: tab_subsinotempo = tab_subsino4; break;
case 5: tab_subsinotempo = tab_subsino5; break;
}
memcpy(tab_subsinoboot5+l, tab_subsinotempo+l, 400*sizeof(unsigned short int));
l = l + 800;
}

Normalement, le while(l < sz_subsino/sizeof(unsigned short int)) est correct puisque sz_subsino est compté en octets alors que les pointeurs pointent sur des entiers de taille sizeof(unsigned short int) octets, mais qu'en est-il de l'incrémentation de l pour chaque ligne (l = l + 800), exprimé en octets (si je ne me trompe pas) ?

Message édité par Mourfizbak le 12-03-2012 à 15:40:27

---------------
Dans le doute, reboot, et si ça rate, formate !

edwoud

⭐ shériff de l'espace

Dans ce cas, attention car tu lis potentiellement deux fois trop de données!

Code :

fread (tab_subsino1, 2, sz_subsino, subsino1);

Tu vas lire 2*sz_subsino octets or tu me disais que sz_subsino était la taille en octets du fichier

Pour ta boucle, l'erreur est sur ton compteur

Tu avances de 800 en 800 parce que tu copies de 800 en 800 mais tu compares à la taille/sizeof(short int) qui est deux fois moindre.

Enlève la division de ta comparaison et le code sera correct

Code :

while(l < sz_subsino)

Message édité par edwoud le 12-03-2012 à 15:56:47

Mourfizbak

Ca ne fonctionne toujours pas...

Bon, je dois pouvoir débuguer tout seul mais il me manque des infos que je n'arrive pas à obtenir :

Mes fichiers binaires subsinoX.s codent chaque pixel sur deux octets, et chaque ligne sur 400 pixels (donc sur 800 octets).
Mes tableaux dynamiques sont maintenant en unsigned short int, qui code également chaque valeur sur deux octets.

Du coup, avec :

Code :

test_fread = fread (tab_subsino1, 2, sz_subsino/sizeof(unsigned short int), subsino1);

je range dans tab_subsino toutes les données sur 2 octets, je me déplace donc dans ce fichier tous les deux octets pour lire les pixels. tab_subsino[1] me renvoit donc une valeur du pixel1 etc..

En suivant cette même logique :

Code :

while(l < sz_subsino) {
nb_al=genrand_real2()*nb_ss_originaux+1 ;
switch(nb_al) { // choix aléatoire du sous-sinogramme original dans lequel on prend la ligne
case 1: tab_subsinotempo = tab_subsino1; break;
case 2: tab_subsinotempo = tab_subsino2; break;
case 3: tab_subsinotempo = tab_subsino3; break;
case 4: tab_subsinotempo = tab_subsino4; break;
case 5: tab_subsinotempo = tab_subsino5; break;
} // switch
memcpy(tab_subsinoboot1+l, tab_subsinotempo+l, 400*sizeof(unsigned short int));
l = l + 800;

Mes questions :

- D'un point de vue utilisation et parcours des fichiers, quelle est la différence entre :

Code :

test_fread = fread (tab_subsino1, 1, sz_subsino1, subsino1);

Code :

test_fread = fread (tab_subsino1, 2, sz_subsino/sizeof(unsigned short int), subsino1);

- La variable l de déplace-t-elle suivant les octets ou suivant des entiers (ce qui implique while(l < sz_subsino/sizeof(unsigned short int)), une copie de seulement 400 données dans le memcpy et un l = l + 400; à la fin).
J'ai tenté les deux méthodes, et soit je ne copie qu'une ligne sur deux, soit je copie trop de données...

Si vous avez une idée, je suis preneur !

Merci d'avance

Message cité 1 fois
Message édité par Mourfizbak le 13-03-2012 à 11:29:52

---------------
Dans le doute, reboot, et si ça rate, formate !

gilou

Modérateur
Modzilla

l se déplace suivant les octets, ce qu'une simple vérification sur le type de memcpy t'aurait indiqué:
void *memcpy (void *dest, const void *src, size_t n);
src et dest y sont vus comme des adresses mémoires et non pas comme des pointeurs sur un type particulier de données (auquel cas, les additions src+l et dest+l auraient tenu compte de la taille des données pointées).

Citation :

D'un point de vue utilisation et parcours des fichiers, quelle est la différence entre :

Concrètement, aucune.
test_fread = fread (tab_subsino1, 1, sz_subsino1, subsino1);
est sans doute l'idiome le plus courant pour lire tout un fichier d'un coup.
par contre, ça a de l'intérêt quand tu as une lecture bufferisée style
typedef mydatatype ...;
mydatatype mybuffer[mybuffersize];
while(...) {
fread (mybuffer, sizeof(mydatatype), mybuffersize, file);
...
}
A+,

Message édité par gilou le 13-03-2012 à 11:47:13

---------------
There's more than what can be linked! -- Iyashikei Anime Forever! -- AngularJS c'est un framework d'engulé! --

Mourfizbak

Citation :

l se déplace suivant les octets

Ouf, me voila rassuré, je me déplace bien comme je le pensais.

Citation :

Concrètement, aucune.
test_fread = fread (tab_subsino1, 1, sz_subsino1, subsino1);
est sans doute l'idiome le plus courant pour lire tout un fichier d'un coup.

Voila qui répond à une grande interrogation fondamentale qui m'intrigue depuis un petit moment !

Du coup, tab_subsino1[1] (qui est formaté en unsigned short int) me donne donc le premier pixel, lui-même codé sous forme d'unsigned short int (donc sur deux octets). Ces deux octets sont donc rigoureusement identiques aux deux premiers octets présents dans le fichier binaire subsino1.s. tab_subsino1[2] = tabsubsino1[1] + 2 pointent donc vers la même valeur ?

(j'ai tenté d'appliquer ce que j'ai appris sur ce forum mais mon fichier final n'a qu'une ligne sur deux de remplie et tab_sinoboot(sz_subsino) me donne une" segmentation fault", donc j'essaye de comprendre le pourquoi du comment...).

Encore une fois, merci d'avance pour votre patience

---------------
Dans le doute, reboot, et si ça rate, formate !

gilou

Modérateur
Modzilla

Citation :

tab_subsino1[2] = tabsubsino1[1] + 2

Pas du tout:
tabsubsino1[1] c'est un short int, donc la, tu fais une addition entre un short int et l'entier 2
Par contre, &(tab_subsino1[2]) = &(tabsubsino1[1]) + 2
car:
&(tab_subsino1[2]) = tab_subsino1 + 2*sizeof(unsigned short) = tab_subsino1 + 4 // en c, pour un tableau, tab_subsino1 représente &(tab_subsino1[0]) dans les expressions d'adresse
&(tabsubsino1[1]) + 2 = tab_subsino1 + 1*sizeof(unsigned short) + 2 = tab_subsino1 + 2 + 2 = tab_subsino1 + 4
A+,

Message édité par gilou le 13-03-2012 à 13:16:38

---------------
There's more than what can be linked! -- Iyashikei Anime Forever! -- AngularJS c'est un framework d'engulé! --

edwoud

⭐ shériff de l'espace

Mourfizbak a écrit :

Ca ne fonctionne toujours pas...
Mes questions :

- D'un point de vue utilisation et parcours des fichiers, quelle est la différence entre :

Code :

test_fread = fread (tab_subsino1, 1, sz_subsino1, subsino1);

Code :

test_fread = fread (tab_subsino1, 2, sz_subsino/sizeof(unsigned short int), subsino1);

Bon, ton problème, c'est que tu mélanges un peu tout dans ton code. Je viens de voir l'ensemble à l'instant.

Il faut commencer par choisir ton référentiel.

Soit tu joues avec la taille en octets de l'ensemble, soit tu joues avec le nombre d'éléments.

Là, l'incohérence de ton code, c'est que tu te balades avec des octets mais que pour ton memcpy, l'addition pointeur+int n'est pas en octets, mais en taille d'éléments!

Code :

memcpy(tab_subsinoboot1+l, tab_subsinotempo+l, 400*sizeof(unsigned short int));

Donc soit tu travailles en octets comme ci-dessous

Code :

memcpy(((char*)tab_subsinoboot1)+l, ((char*)tab_subsinotempo)+l, 800 );

soit tu travailles en éléments, à partir de ton L en octets

Code :

memcpy(tab_subsinoboot1+l/sizeof(unsigned short int), tab_subsinotempo+l/sizeof(unsigned short int), 400*sizeof(unsigned short int));

Le problème, c'est que ton l ce sont des octets mais tes pointeurs sont unsigned short, donc chaque incrémentation augmente de deux octets, et ainsi de suite

Message édité par edwoud le 13-03-2012 à 15:15:18

Mourfizbak

Merci pour ces précisions !Cela fait deux jours que je tripatouille tout ça, sans parvenir à mes fins...

J'ai tenté de travailler sur les éléments avec l en octets, puis uniquement avec des octets, rien ne fonctionne correctement.

Peux-tu développer

Citation :

Le problème, c'est que ton l ce sont des octets mais tes pointeurs sont unsigned short, donc chaque incrémentation augmente de deux octets, et ainsi de suite

?

[edit] Je crois que j'ai compris. Quoique je fasse, si j'incrémente d'une unité les tab_subsinoX et consors, l'incrémentation vaut deux octets, autrement dit un pixel.

J'ai repris le code, mais je suppose que je suis obligé de travailler avec les éléments et non les octets, sans quoi je me retrouve à faire des tab_subsinoboot1+l/sizeof(unsigned short int), ce qui peut-être problématique avec l = 1 par exemple...
Ce qui donnerai du coup :

Code :

while(l < sz_subsino/sizeof(unsigned short int)) {
nb_al=genrand_real2()*nb_ss_originaux+1 ;
switch(nb_al) {
case 1: tab_subsinotempo = tab_subsino1; break;
case 2: tab_subsinotempo = tab_subsino2; break;
case 3: tab_subsinotempo = tab_subsino3; break;
case 4: tab_subsinotempo = tab_subsino4; break;
case 5: tab_subsinotempo = tab_subsino5; break;
}
memcpy(((char*)tab_subsinoboot1)+l, ((char*)tab_subsinotempo)+l, 400*sizeof(unsigned short int));
l = l + 400;
}
/* ( ... ) */
for (k = 0 ; k < sz_subsino/sizeof(unsigned short int); k++) {
tab_sinoboot[k] = tab_subsinoboot1[k] + tab_subsinoboot2[k] + tab_subsinoboot3[k] + tab_subsinoboot4[k] + tab_subsinoboot5[k]; /*somme pixel par pixel (dans la RAM) via les pointeurs sur les tableaux 2D des sinogrammes*/
}
fwrite(tab_sinoboot, 1, sz_subsino, sino); /*ecriture de sz_subsino éléments de taille 1 du tableau tab_sino vers le fichier binaire du sinogramme bootstrap complet sino.*/
fclose(sino);

Ce n'est toujours pas correct, je suis vraiment dans l'impasse...

Merci !

Message cité 1 fois
Message édité par Mourfizbak le 13-03-2012 à 16:21:23

---------------
Dans le doute, reboot, et si ça rate, formate !

Publicité

edwoud

⭐ shériff de l'espace

Mourfizbak a écrit :

Citation :

Le problème, c'est que ton l ce sont des octets mais tes pointeurs sont unsigned short, donc chaque incrémentation augmente de deux octets, et ainsi de suite

Code :

while(
) {
nb_al=genrand_real2()*nb_ss_originaux+1 ;
switch(nb_al) {
case 1: tab_subsinotempo = tab_subsino1; break;
case 2: tab_subsinotempo = tab_subsino2; break;
case 3: tab_subsinotempo = tab_subsino3; break;
case 4: tab_subsinotempo = tab_subsino4; break;
case 5: tab_subsinotempo = tab_subsino5; break;
}
memcpy(((char*)tab_subsinoboot1)+l, ((char*)tab_subsinotempo)+l, 400*sizeof(unsigned short int));
l = l + 400;
}
/* ( ... ) */
for (k = 0 ; k < sz_subsino/sizeof(unsigned short int); k++) {
tab_sinoboot[k] = tab_subsinoboot1[k] + tab_subsinoboot2[k] + tab_subsinoboot3[k] + tab_subsinoboot4[k] + tab_subsinoboot5[k]; /*somme pixel par pixel (dans la RAM) via les pointeurs sur les tableaux 2D des sinogrammes*/
}
fwrite(tab_sinoboot, 1, sz_subsino, sino); /*ecriture de sz_subsino éléments de taille 1 du tableau tab_sino vers le fichier binaire du sinogramme bootstrap complet sino.*/
fclose(sino);

Ce n'est toujours pas correct, je suis vraiment dans l'impasse...

Merci !

tu continues à mélanger.

l < sz_subsino/sizeof(unsigned short int) ici l est comparé à un nombre d'éléments (400)

memcpy(((char*)tab_subsinoboot1)+l, ((char*)tab_subsinotempo)+l, 400*sizeof(unsigned short int)); ici l est un nombre d'octets

Je t'avais dit de ne modifier que le memcpy. là, t'as modifié le memcpy, ta comparaison et ton addition qui était à 800 est passée à 400, du coup

tu inverses la confusion, mais c'est toujours pas en accord.

Donc soit tu compares à des octets, tu fais ton memcpy en octets et ton addition (800) en octets

soit tu compares à des éléments (/sizeof), tu fais ton memcpy en éléments et ton addition en éléments

mais pas un mélange des deux.

Message édité par edwoud le 13-03-2012 à 20:26:26

gilou

Modérateur
Modzilla

Bon, j'étais pas la cet aprem.
La dernière fois, je t'avais donné ce code:

Code :

l=0 ;
while(l < sz_subsino/sizeof(int)) {
nb_al=genrand_real2()*nb_ss_originaux+1 ; /*printf("%d\n",nb_al)*/
switch(nb_al) {
case 1: memcpy(tab_subsinoboot2+l, tab_subsino1+l, 800*sizeof(int)); break;
case 2: memcpy(tab_subsinoboot2+l, tab_subsino2+l, 800*sizeof(int)); break;
case 3: memcpy(tab_subsinoboot2+l, tab_subsino3+l, 800*sizeof(int)); break;
case 4: memcpy(tab_subsinoboot2+l, tab_subsino4+l, 800*sizeof(int)); break;
case 5: memcpy(tab_subsinoboot2+l, tab_subsino5+l, 800*sizeof(int)); break;
}
l += 800;
} // while

Ou il était supposé
1) que tes pixels étaient codés comme des ints
2) que tu avais 800 pixels par ligne
C'était pas dur d'adapter a un cas de pixels codé comme des unsigned short int:

Code :

l=0 ;
while(l < sz_subsino/sizeof(unsigned short int)) {
nb_al=genrand_real2()*nb_ss_originaux+1 ; /*printf("%d\n",nb_al)*/
switch(nb_al) {
case 1: memcpy(tab_subsinoboot2+l, tab_subsino1+l, 800*sizeof(unsigned short int)); break;
case 2: memcpy(tab_subsinoboot2+l, tab_subsino2+l, 800*sizeof(unsigned short int)); break;
case 3: memcpy(tab_subsinoboot2+l, tab_subsino3+l, 800*sizeof(unsigned short int)); break;
case 4: memcpy(tab_subsinoboot2+l, tab_subsino4+l, 800*sizeof(unsigned short int)); break;
case 5: memcpy(tab_subsinoboot2+l, tab_subsino5+l, 800*sizeof(unsigned short int)); break;
}
l += 800;
} // while

Si ça ça colle pas, c'est que ton pb est ailleurs.

Tu as bien redéclaré tes tableaux comme il faut?
unsigned short int *tab_subsino1;
...
unsigned short int *tab_sinoboot;
parce que sinon...

A+,

Message édité par gilou le 13-03-2012 à 21:19:11

---------------
There's more than what can be linked! -- Iyashikei Anime Forever! -- AngularJS c'est un framework d'engulé! --

Mourfizbak

Citation :

Ou il était supposé
1) que tes pixels étaient codés comme des ints
2) que tu avais 800 pixels par ligne

Il est là le problème. Je n'ai pas fais attention à ça, mes lignes font 400 pixels et non 800 !Et je pense que toutes les erreurs que j'ai viennent (ou plutôt venaient) de là :pfff:

Citation :

Tu as bien redéclaré tes tableaux comme il faut?
unsigned short int *tab_subsino1;
...
unsigned short int *tab_sinoboot;
parce que sinon...

Oui pas de soucis

Citation :

tu continues à mélanger.

l < sz_subsino/sizeof(unsigned short int) ici l est comparé à un nombre d'éléments (400)

memcpy(((char*)tab_subsinoboot1)+l, ((char*)tab_subsinotempo)+l, 400*sizeof(unsigned short int)); ici l est un nombre d'octets

Je t'avais dit de ne modifier que le memcpy. là, t'as modifié le memcpy, ta comparaison et ton addition qui était à 800 est passée à 400, du coup

tu inverses la confusion, mais c'est toujours pas en accord.

Donc soit tu compares à des octets, tu fais ton memcpy en octets et ton addition (800) en octets

soit tu compares à des éléments (/sizeof), tu fais ton memcpy en éléments et ton addition en éléments

mais pas un mélange des deux.

Ce coup-ci j'ai compris, la nuit a porté conseil.
Je viens de corriger le code et de lancer une batterie de vérifications, tout semble fonctionner à merveille.

Merci encore pour votre patience edwoud et gilou, j'aurais pu passer encore une semaine sur ce problème

---------------
Dans le doute, reboot, et si ça rate, formate !

gilou

Modérateur
Modzilla

Les perfs en vraie grandeur sont bonnes maintenant?
A+,

Message édité par gilou le 14-03-2012 à 12:52:37

---------------
There's more than what can be linked! -- Iyashikei Anime Forever! -- AngularJS c'est un framework d'engulé! --

Mourfizbak

Citation :

Les perfs en vraie grandeur sont bonnes maintenant?
A+,

Les fichiers finaux font (enfin !) la bonne taille une fois compressés avec le logiciel constructeur, tous les paramètres de l'image possèdent (a priori) les bonnes caractéristiques, et le temps d'exécution du programme (par rapport au premier post du premier topic sur lequel tu m'avais beaucoup aidé) a été divisé par plus de 30...
Donc je dirais que oui, les perfs en vraie grandeur sont bonnes !

Message édité par Mourfizbak le 14-03-2012 à 18:01:15

---------------
Dans le doute, reboot, et si ça rate, formate !

FORUM HardWare.fr

Programmation

Lecture de fichiers binaires [résolu]

Sujets relatifs
accès aux répertoires, fichiers en fonction du statut de l'utilisateur	fusion de pls fichiers xls
pb liste chainée et lecture de fichier C	Parcours de 2 fichiers
Lecture de gros fichiers CSV sur Android	Compilation parser XML pour intégration à un code C
Problème de lecture du CSS sous IE	Souci de fichiers introuvables
cherche logiciel de consultation de fichiers multiformats
Plus de sujets relatifs à : Lecture de fichiers binaires [résolu]

Page générée en 0.150 secondes