[c++] Programmation d'un logiciel d'images et gestion des fichiers

Bonjour à tous,

Je programme un logiciel de conversion d'images de deux formats différents et j'ai quelques soucis.

Je programme via Visual C++. Je crée une dll pour un logiciel d'image.
Le code ci dessous compile bien mais à l'exécution (dans le logiciel d'image), ça plante (le logiciel se ferme brutalement).

J'ai pu constater (grâce aux traces) que cela se produits à la fin de la boucle while (autrement dit quand on a lu les octets souhaité - la fin du fichier n'étant pas atteinte).

Code:

---

1 2 3 4 5 6 7

//déclaration des variables char octet; bool run = true; int numOctet = 0; string buff, image, header_dm2; int dimension, offsetArrayOffset,dataType, width, height, pixelDepth, nbOctetImage;

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

i = 1; while (i <= nbOctetImage) { //nbOctet= 8 388 608 f_in.read(&octet , 1); oct = octet; s_octet = getOctetLu(oct); image = image + s_octet; numOctet++; i++; //trace PlugIn::gResultOut << i << endl; }

---

Le problème vient de la ligne

Code:

---

1 2	f_in.read(&octet , 1);

---

En effet pour tester quand j'execute le code ci dessous ca plante:

Code:

---

f_in.read(&octet , 4000000);

---

Je comprend vraiment pas ce bug 8O







J'ai aussi un deuxième problème.
Un pixel d'image est représenté par deux octets X1X2X3X4 Y1Y2Y3Y4. Ce sont les valeur hexadécimal.

Le problèmes c'est que dans ce format la valeur de l'octet en hexadécimal est:
Y3Y4Y1Y2 X3X4X1X2 au lieu de X1X2X3X4 Y1Y2Y3Y4.
Je dois donc octet par octet traiter manuellement cela avant de calculer la valeur en décimal de Y3Y4Y1Y2 X3X4X1X2.
Le problème c'est qu'à l'execution cela va prendre beaucoup trop de temps.

Est-ce que quelqu'un aurait une idée pour résoudre cela?
J'ai aussi vaguement entendu parler de swap data sans comprendre vraiment ce que c'était. Est-ce que cela pourrait résoudre mon problème?


Merci d'avance pour votre aide,
funkyKong

Tu as oublié d'indiquer le type de f_in, mais c'est tout-à-fait normal que ça plante: Tu as de la place pour un seul octets, et tu essaies d'y en mettre 4 000 000, donc forcément, ça déborde...

Merci pour ta réponse Médonoc

Voici la déclaration de f_in:

Code:

---

1 2 3

//fichier en flux d'entrée. ifstream f_in (nomFichier,ios::binary | ios::in);

---

Cependant je ne vois pas trop le problème 8O

quand je fait:

Code:

---

1 2	f_in.read(&octet , 10);

---

ca marche parfaitement (on lit bien plus que 1 octet là)

c'est bien dans cette boucle que ca plante:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

while (i <= nbOctetImage) { //nbOctet= 8 388 608 f_in.read(&octet , 1); oct = octet; s_octet = getOctetLu(oct); image = image + s_octet; numOctet++; i++; //trace PlugIn::gResultOut << i << endl; }

---

et là on lit bien un octet par un octet


Donc je comprend pas trop :?

Citation:

---

Envoyé par Médinoc

Tu as oublié d'indiquer le type de f_in, mais c'est tout-à-fait normal que ça plante: Tu as de la place pour un seul octets, et tu essaies d'y en mettre 4 000 000, donc forcément, ça déborde...

---

ben oui forcément, ca dépend ca dépasse!!!

pour en revenir au sujet, le fait que ca ne plante pas ne veut pas dire que ca marche. ca veut juste dire que tu as du bol. et des fois on a du bol avec 10 octets, mais avec 4 miyons c'est plus du bol, il faut jouer au loto. si tu arrives a faire rentrer 4 miyons d'octets dans un seul je te felicite, tu as trouvé la methode de compression la plus efficace au monde.

Code:

---

char octet;

---

reserve de la place pour un octet.

Code:

---

char octet[1024];

---

reserve de la place pour 1024 octets.

a toi de savoir combien tu en veux (4 miyons ca ne tiendra pas dans une variable locale) mais 1 seul ce n'est pas assez d'espace.

En fait je croyait qu'a chaque fois qu'il bouclait, il allait ecraser la valeur précédente.


effectivement c'est logique. J'ai honte :?

En tout cas Merci à tout les deux ;)

En fait il faut que j'en réserve 10 000 000 de places

Sinon personne a une idée concernant mon deuxième problème (expliqué à mon premier post ci-dessus) ?

Tu sais, tu peux utiliser la fonction membre ignore() si tu veux "sauter" des octets...

Pour ton deuxième problème, es-tu sûr que ta conversion va prendre énormément de temps de calcul en plus?

Quel est la taille de tes images?
Combien en as-tu à traiter, dans quel limite de temps?

Est-ce qu'une optimisation est nécessaire?

Peut-être que ta solution est déja suffissante...

Merci je me deplace deja avec un f_in.seekg :)

Pour la contrainte de temps je dois faire ca en moins de 10s. En lisant tout d'un coup c'est faisable, mais en lisant octet par octet cela prend dans les 7h30 :?

Le problème c'est que je dois traiter chaque octet. Pour deux raison:
1) quand je lit deux octets, dans le premier format ils sont stockés en middle endian (donc quand je lis en hexa ca donne ca: Y3Y4Y2Y1 X3X4X2X1 au lieu de X1X2X3X4 Y1Y2Y3Y4). Je dois donc faire des opérations de conversion sur les bits tous les deux octet
2) il faut ensuite que je calcul la valeur décimal des deux octet qui sont représenté en hexa.

Pour la taille de l'image c'est dans la dizaine de Mo pour le moment.

Citation:

---

Pour la contrainte de temps je dois faire ca en moins de 10s. En lisant tout d'un coup c'est faisable, mais en lisant octet par octet cela prend dans les 7h30

---

7h30 pour 10 mega de données !! c'est vraiment impréssionnant.
et même les 10s ça à l'air gros pour charger un fichier.

Soit tu as un gros soucie dans ton algo, soit tu tournes sur une machine des années 60...:?
Plus sérieusement, peut-être que lire octet par octet n'est pas une bonne solution (l'OS doit être trop sollicité)

Et si tu essayais de charger entiérement le fichier dans un buffer pour ensuite y faire les traitements.

oui j'avais pensais à cela mais je sais pas si il y aura une si grande différence de temps. :?

Sinon quand je dit 10 secondes ca doit comprendre la lecture du fichier, le traitement de tous les octets et l'écriture dans un autre fichiers.

Pour l'idée du buffer je verrais demain ce qu'il en est ;)

En fait, il y a plusieurs problêmes:

- Problême de lecture du fichier.

Les streams C++ sont l'interface la plus lente. Les FILE descriptor du C ne sont guère mieux, juste un poil. Le plus rapide va dépendre de ton système (comme toujours), et s'adapter à la taille de la source (par exemple un cluster du disque).

Ce qui est sur, c'est que lire octet par octet est la pire des choses à faire... A chaque lecture, le code va faire des tests, vérifier qu'il n'y a pas à faire un accès disque, bref... tout un tas de tralala complètement inadapté à la lecture d'un tout petit fichier de 10Mo (pour info, un fichier de 10Mo se convertissait en 2 minutes entre JPG et IVUE/FlashPix par exemple sur un 486dx100 avec windows 3.1).

10Mo c'est même pas la taille mémoire occupée par le logon de windows maintenant !!! Donc: Lis *TOUT* ton fichier d'un coup. Si vraiment il n'y a pas moyen d'allouer 10Mo en mémoire, autant dire le systeme est HS.

Si vraiment tu ne peux pas (fichier > 50Mo ou 100Mo par exemple), alors lis par groupe de donnée... genre 16Mo par 16Mo.


- Problême de traitement d'image, en l'occurence remise en ordre des pixels (transformation des pixel-formats).

C'est un problême assez simple, quoique tu nous en dise pas beaucoup... Je ne connais pas beaucoup de formats d'image ou les pixels ont un endianness... A moins de travailler sur un format >32 bits. Donc ma question est... quel pixel-format as tu en entrée, et quel pixel-format veux tu en sortie ?
Les deux pixel-formats les plus utilisés sont: A_R_G_B (le plus classique) et R_G_B_A.

Là encore, le traitement s'optimise en fonction des pages de cache-data (en général 64 octets), donc, traite 64 octets par 64 octets.
Pour information, dérouler le traitement (traiter 4 pixels par 4 pixels par exemple) aide énormément (2 cycles de test à chaque boucle, 6 cycles de traitement par pixel => 32 cycles sans dérouler, 26 cycles en déroulant).

Salut,

En fait je dois convertir des fichiers en ".ser" en ".dm3". Par contre je ne connais pas les pixel formats de mes deux images (les images en .ser sont impossible à ouvrir hors éditeur héxadecimal).

Par contre il y a un autre problème dont je n'avais pas pensé hier soir. Lorsque je lit un octet il y a plein de caractères "en trop" derrière l' octet 8O.
Je récupérais donc chaque octets séparement pour pouvoir traiter ce cas:
- d'abord récupérer les deux premier caractéres (ce qui correspond à l'octet) sans les caractère en trop.
- ensuite si la valeur héxa de l'octet est inferieur à $10 alors je n'ai qu'un caractère (0 ou 1 ou 2 ou....9) au lieu d'avoir un 0 devant. Je dois donc le rajouté manuellement.
- enfin il y a un cas spécial où cette chaine "fffffff7" vient se mettre devant les deux caractères de l'octet :?

J'avais crée une méthode pour traiter ce problème mais ca m'oblige à lire le fichier octet par octet.

Euh... Comment peux-tu convertir si tu ne connais pas le format ? 8O

Je connais bien la structure des formats des images (j'ai du analyser tout cela via un éditeur hexadécimal), mais c'est juste que je n'ai aucune idée du format des pixel.

Quand je lis le fichier d'un coup, cela me prend moins de 3s.

Par contre aprés quand je veux lire le buffer octet par octet il me faut 22h (je lit 10000 octet en 8s soit 8388608 octet en 22h). C'est encore pire que par la lecture de fichier 1 octet par un octet :?
Et encore c'est sans avoir reglé le problèmes de caractères en trop et bizarre



Pour les pixel formats:
Un pixel est selon les cas soit sur 1,2,4,8 ou 16 octets (16 pour les images complexe).
Bon dans le premier cas un pixel est sur 2 octets.

Le format du pixel d'entrée (pour l'image au format .ser) est le middle endian et le format du pixel de sortie est le little endian (pour l'image au format .dm3).

Citation:

---

Je connais bien la structure des formats des images (j'ai du analyser tout cela via un éditeur hexadécimal), mais c'est juste que je n'ai aucune idée du format des pixel.

---

Tu connais la structure des images, mais pas le format des pixels...:aie:
Tes images sont composées de quoi alors ?8O

en fait qu'entend tu par format des pixel? Parce que dans mon précedent post, j'avais répondu ca :

Citation:

---

Pour les pixel formats:
Un pixel est selon les cas soit sur 1,2,4,8 ou 16 octets (16 pour les images complexe).
Bon dans le premier cas un pixel est sur 2 octets.

Le format du pixel d'entrée (pour l'image au format .ser) est le middle endian et le format du pixel de sortie est le little endian (pour l'image au format .dm3).

---

Pour les caractères en trop je pense que j'ai compris d'où ca vient. Quand je lis dans le fichier, je lis malheuresement des ascii. Je dois donc les convertir en hexadecimal via cette fonction:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// // converte un string en un string héxadécimal string string_hex(string buffer){ ostringstream oss; //initialise un string stream qui stock la sortie de std::hex   //fait une boucle caractére par caractére for (string::const_iterator i = buffer.begin(); i != buffer.end(); ++i) { oss << std::hex << static_cast<int>(*i); //stock la sortie de std::hex dans oss } return(oss.str()); } ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

---

Cette fonction doit être buggé mais où :?

Oulalalala... mais dans quoi tu t'ai embarqué!
Je commence à comprendre pourquoi ça te prends 37h pour charger une image...

Si je peux de donner un conseille, oublis les strings et la STL pour convertir tes images.

Utilise tout simplement le type char, qui est parfait pour manipuler les octets puisque sizeof(char) = 1.

Citation:

---

en fait qu'entend tu par format des pixel? Parce que dans mon précedent post, j'avais répondu ca :

---

format des pixel:

comment les composantes des couleurs sont elles organisée ?

Généralement les pixels sont codées sur 24 bit, 8 bits par composantes (Rouge, Vert ou Bleu) + 8 bits si tu gére un canal alpha pour la transparence... ce qui nous fait un maximum de 32 bits soit 4 octets.

Ensuite dans quelles ordres elles sont placées : RGBA, ARGB ...

Citation:

---

Un pixel est selon les cas soit sur 1,2,4,8 ou 16 octets (16 pour les images complexe)

---

8 ou 16 octets, ça me paraît beaucoup pour coder 1 pixel. Qu'est ce qu'on peut bien mettre dans 16 octet ?

4 floats.

Merci pour vos réponses

mais si je comprend bien en n'utilisant pas les string mais que des char je vais devoir lire octet par octet le fichier. Et comme je l'ai déja fait au tout début ca va me prendre 7h :?

Si je ne lis pas octet par octet et tout d'un coup, ranger ses 1000000 octet dans un char ce n'est pas trés pratique pour pouvoir faire des traitements aprés.

Le problème c'est que je dois pouvoir lire un octet en hexa (que je lise en char ou en string ne changera pas qu'il faudra que je fasse la conversion ascii hexa) et ensuite l'inverser (X0X1X2X3 en X2X3X0X1). Ce n'ai qu' aprés que je dois calculer sa valeur décimal.


Pour le format des pixel, cela dépend du type d'image. Je dois traiter tout type d'images.
Avant la partie data à proprement parlé, il y a tous les champs informations en hexa comme le nombre de bit par pixel (qui varie entre 1 et 16) la taille l'image, le dataTypeId, etc....

Citation:

---

4 floats.

---

:lol:

Citation:

---

mais si je comprend bien en n'utilisant pas les string mais que des char je vais devoir lire octet par octet le fichier. Et comme je l'ai déja fait au tout début ca va me prendre 7h

---

Non. Tu créer un buffer de char de la taille de ton fichier, ensuite tu charges ton fichier dedans en une seule fois, enfin tu fais tes traitements.

Code:

---

1 2 3 4 5 6 7 8

// chargement char* buffer = malloc(TAILLE_DU_FICHIER); ifstream f_in("ton_fichier_image.ser"); f_in.read(buffer, TAILLE_DU_FICHIER); f_in.close();   // traitement ...

---

Citation:

---

Le problème c'est que je dois pouvoir lire un octet en hexa (que je lise en char ou en string ne changera pas qu'il faudra que je fasse la conversion ascii hexa) et ensuite l'inverser (X0X1X2X3 en X2X3X0X1). Ce n'ai qu' aprés que je dois calculer sa valeur décimal.

---

Qu'est-ce que tu entend par "lire un octet en hexa"?
Peu importe la représentation de ton octet, tous ce que tu veux c'est pouvoir les changer de place.

Code:

---

1 2 3 4 5 6 7 8 9 10

char[4] in ; // tes 4 octets lues (depuis ton buffer) char[4] out ; // les quatres octets aprés la conversion ... // initialisation char[4] in   // conversion out[0] = in[2]; out[1] = in[3]; out[2] = in[0]; out[3] = in[1]; ...

---

Merci beaucoup pour ta réponse ;)

En fait je crois que suis obliger d'avoir les valeurs hexa. Cela pour deux raison:

1) Avant le le traitement, il y a environ 200 octets de champs informations.
C'est important de les lire dans la mesure où il me renseigne à quel octet commence la partie data, combien il y a de pixel dans l'image, quel est le data type de l'image, quel est la calibration de l'image.
Il faut donc que je compare la valeur d'un octet à la valeur d'un hexa.

Par exemple pour un octet n°xx
Si il es égale à $4849 alors le data type de l'image c'est du 2 byte par integer
Si il est égale à $4126 alors c'est du 16 byte complex.

Autre exemple un octet nous renseigne su la taille d'un champ d'information.




2) Il faut que je caclul les valeurs décimal de chaque octet du champ data afin de l'ecrire dans le fichier destination. Et ca je pense pas que ca soit possible avec les valeurs en ascii. Je pensais convertir les valeurs ascii en hexa, puis calculer la valeur décimal à partir de l'hexa.


Ah oui au fait pourquoi tu as pas fait un new au lieu du malloc 8O

Les images que tu traites ne sont pas des images points par points (formées de pixels), mais plutôt des images vectorielles, non ?

Citation:

---

2) Il faut que je caclul les valeurs décimal de chaque octet du champ data afin de l'ecrire dans le fichier destination. Et ca je pense pas que ca soit possible avec les valeurs en ascii. Je pensais convertir les valeurs ascii en hexa, puis calculer la valeur décimal à partir de l'hexa.

---

Si j'ai bien compris, tu as des valeurs binaires dans un fichier et tu veux les transcrire en chaîne de caractéres dans un autre fichier...

J'ai vraiment du mal à saisir ton problème, est-ce que tu pourrais nous montrer un exemple de ce que tu as comme données et à quel résultat du veux arriver.

Comme :
entrée : 0xA0 (un octet en hexa)
sortie : "10" (chaine de caractéres)

Citation:

---

Ah oui au fait pourquoi tu as pas fait un new au lieu du malloc

---

Désolé, j'ai mélangé avec le C.:oops: Mais le new serait plus approprié c++, en effet.

Je crois que les images que je traite sont bien des images formé de pixel (j'ai vraiment peu d'informations dessus) :?

En fait : -- cela concerne juste pour le champ data
je dois
-lire les octets data du fichiers .ser en hexa,
-remettre les octets dans le bon ordre (et cela tous les deux octets vu qu'un pixel fait 2 octets dans le cas où le data type c'est de l'integer 2)
- ensuite je peut calculer leur valeur réele (float)
- puis stoker dans le fichier de sortie dans le champs data les float (sachant qu'un pixel est sur deux octet)

Donc si je lis: "0a01" à la position i:
- d'abord je l'inverse => "010a"
-puis je calcul la valeur réele soit 26
- enfin j'ecris dans le champ data du fichier de sortie (.dm3) en float 26


Autre chose quand je lis les octets en héxa dans le fichier de départ, j'ai des caractère en trop du genre fffff1c , je dois donc traiter cela en les supprimant. Et si la valeur hexa est 0a alors étant donné que quand je lis en hexa ca m'affiche juste a, il faut que je rajoute un 0 devant.

Citation:

---

Je crois que les images que je traite sont bien des images formé de pixel (j'ai vraiment peu d'informations dessus)

---

Dans ce cas, ça va être trés trés trés trés difficile pour toi. Il n'y a pas de documentation sur ton format? Avec quel logiciel tu peux le lire? Peut-être qu'il existe un logiciel ou une librairie qui effectue déja le traitement que tu souhaite faire. Tu as fait des recherches à ce niveau?

Je ne comprend toujours pas pourquoi tu "lis en hexa".
Si tu as deux octet dans ton fichier d'origine.
1. Tu les lit dans un char buffer[2]

Code:

---

f_in.read(&buffer, 2);

---

2. Tu les inverses :

Code:

---

1 2 3

char tmp_char = buffer[0]; buffer[0] = buffer[1]; buffer[1] = tmp_char;

---

3. Tu récupére la valeur entiére des deux char en castant

Code:

---

int i = (int)(buffer);

---

4. Tu formate ton nombre en hexa : là je t'envois vers la documentation de fprintf, il y a des options de formatage pour gerer les 0 de tes hexa

Les images en .ser ne sont lisible avec aucun logiciel : le logiciel tia (emispec ) génère des fichiers en .emi et en même des .ser . Il lit les .emi mais les .ser sont pareil (pas dans le formats mais c'est une image identique - même taille). Il n'y a qu'une seul doc sur tout le web sur les .ser et aucune sur les .emi .

Je dois donc transformer les .ser en .dm3 (digital micrograph). Là aussi il y a qu'une seul doc sur le web :?


http://phyweb.physics.nus.edu.sg/~phybcb/info/index.html

Pour l'inverse je l'avais déja inverser. Pour le fprintf, je vais regarder ca mais j'aime pas trop utiliser une librairie c au lieu d'une c++

Le plus gros problème qui j'ai en fait c'est le temps de faire tous ces traitement dans le buffer. J'ai testé ca et ca prend une dizaine d'heure au lieu de 10s.

Aprés j'ai aussi ce fichus caractères spéciaux qui m'enpêche pour le moment de lire en une seul fois dans le buffer: il apparaissent aléatoirement et sans les traiter au cas par cas, quand je lis le fichiers, je vois pas comment je vais faire pour les traiter lorsque j'ai tout mis dans le buffer.

Mais en tous cas merci pour toute l'aide que tu m'a apportée

Cela ne marche pas :?

Citation:

---

3. Tu récupére la valeur entiére des deux char en castant

Code:

---

int i = (int)(buffer);

---

---

Quand je fait ca:

Code:

---

1 2 3 4 5 6

char * buff = new char[2]; buff[0] = buffer[6]; //buff[0] = 41 buff[1] = buffer[7]; //buff[1] = 22 int i = (int)(buff); PlugIn::gResultOut << i << endl; // cela m'affiche 73551936

---

c'est normale que ça ne marche pas... ou plutôt que ça ne te donne pas le résultat que tu attends.

Attention à cette ligne :

Code:

---

int i = (int)(buff);

---

buff est un pointeur !
ici, on demande de caster l'addresse stocker dans buff vers un int. Et non pas la valeur pointer par buff.

Voilà ce que l'on cherche :

Code:

---

int i = *((int*)buff);

---

d'abord on cast le pointeur buff vers un pointeur sur un int, ensuite on récupére la valeur pointée pour la stocker dans i.

Il y un autre problème: la taille d'un int est de 4 octets (sur ma machine en tout cas). Or notre buffer n'en fait que 2. Donc il y a un débordement.

Il faut que notre buffer soit de 4 octet aussi.

voici le code corigé :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

char* buff = new char[4];     buff[0] = buffer[6]; //buff[0] = 41 buff[1] = buffer[7]; //buff[1] = 22 buff[2] = 0x00; buff[3] = 0x00;     int i = *((int*)buff); cout << i << endl; // affiche 5673 ...   delete buff;

---

remarque : Il n'est pas nécessaire d'allouer buff en dynamique.

8O exacte. C'était vraiment une coquille de bas niveau.

A propos pour la lecture du fichier et le traitement des pixels ca me prend maintenant que 15s (sans l'ecriture).
J'ai compris pourquoi ca mettait 150h: à chaque pas de la boucle je fait un cout, ce qui ralentissais le tout à mort. Sans cout ca prend 15s.

Merci :P

Voilà un problème résolue ! :king: