optimiser lecture fichier image

**cheho** · 28/08/2006, 15h38

Bonjour, je d�veloppe une application qui lit des images m�dicales et renvoie leurs miniatures. La taille d'une image est 3000x3000 pix. et celle de d'une ic�ne 96x96 pix. donc je lis mon fichier avec un pas d'�chantillonnage 3000/96 .Le probl�me c'est que c'est trop lent, sur un r�pertoire de 160 images 2 min. Je me demande est ce que c'est l'acc�s au disque ou je n'utilise pas les bonne fonction?
Voici 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
 
inStream = CreateFile(filePath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_FLAG_SEQUENTIAL_SCAN, NULL);
//j'ouvre mon fichier en lecture
//je lis l'entête je calcule la aille de mon image
//j'alloue de la mémoire
//...........
	// initialiser le pointeur du buffer ou on stocke les pixels lus		
		framePtr = frameBuffer;
 
		//parcourire le fichier
		for (l = 0;l < (int)nlIcon;l++)
		{			
			for (k = 0;k < (int)ncIcon; k++)
			{				
				ligne = (float)l * lpasH; 
				colonne = (float)k * lpasH;
 
				// calculer la distance de décalage
				distance = (LONG)(floorf(ligne)* (float)ncImg + floorf(colonne)) * octetsParPixel ;
				decal = distance - distance_old;
 
				// recuperer l'anciene distance
				distance_old = distance + octetsParPixel;
 
				// positionner le pointeur sur le pixel à lire
				SetFilePointer(inStream, decal, NULL, FILE_CURRENT);
 
				// lire le pixel 
				ReadFile(inStream, framePtr, octetsParPixel, &bytesRead, NULL); 
 
 
				// incrementer le pointeur du buffer
				framePtr += octetsParPixel;
 
			}
		}

**M�dinoc** · 28/08/2006, 15h48

Hum... Je ne pense pas que tu puisses vraiment faire plus rapide pour lire une image d'environ (9*oct/pix) Mo...

Si la lecture doit �tre plus rapide, peut-�tre pourrais-tu sauvegarder les miniatures ?

**Higestromm** · 28/08/2006, 22h08

Envoy� par M�dinoc

Hum... Je ne pense pas que tu puisses vraiment faire plus rapide pour lire une image d'environ (9*oct/pix) Mo...

Si la lecture doit �tre plus rapide, peut-�tre pourrais-tu sauvegarder les miniatures ?

+1

Ayant bosser dans ce domaine, seule la cr�ation de vigettes en dur te permettera de gagner sensiblement de la vitesse.

**Ti-R** · 29/08/2006, 10h15

Cela peut �tre optimis�, mais il y a toujours la limite de lecture du disque dur...

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
//parcourire le fichier
 
// Taille de l'icon
    int size_icon_w=96;
    int size_icon_h=96;
 
// Supposons que c'est 3000 la taille de ton image (mais à récupérer pendant la lecture sinon)    
    int img_size_w=3000;
    int img_size_h=3000;
    int offset_x=img_size_w/size_icon_w;
    int offset_x_end=((img_size_w-(offset_x*size_icon_w))+(((int)(img_size_h/size_icon_h))*img_size_w))* octetsParPixel;
    offset_x*=octetsParPixel;
 
    int current_offset=0;
 
		for (l = size_icon_h;l--;)
		{			
			for (k = size_icon_w;k --;)
			{				
				// positionner le pointeur sur le pixel à lire
				SetFilePointer(inStream, current_offset, NULL, FILE_CURRENT);
 
				// Décal de l'offset en x
        current_offset = offset_x;
				// lire le pixel 
				ReadFile(inStream, framePtr, octetsParPixel, &bytesRead, NULL); 
 
 
				// incrementer le pointeur du buffer
				framePtr += octetsParPixel;
 
			}
 
			// Réaligne le décalage en fin de X et ajoute le décalage en Y
      current_offset = offset_x_end;
 
		}

Bon si je me suis pas tromp� (j'ai rien test� !!!

), tu pr�calculs tout, ensuite tu te d�cales dans le fichier pour lire les bons pixels.
offset_x_end permet de "sauter" sur la prochaine ligne en tenant compte que l'image de r�duction n'est pas proportionnel.

Pour bien faire il faudrait limiter les appels de fonctions dans la boucle...
Ensuite cela devient dur de rogner.

Le mieux comme il est dit au dessus, est de tout sauvegarder dans des fichiers, pour les relire ensuite.

ps: Vivement que je trouve un job en imagerie j�adore cela

**Higestromm** · 29/08/2006, 11h05

Envoy� par Ti-R

Cela peut �tre optimis�, mais il y a toujours la limite de lecture du disque dur...

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
//parcourire le fichier
 
// Taille de l'icon
    int size_icon_w=96;
    int size_icon_h=96;
 
// Supposons que c'est 3000 la taille de ton image (mais à récupérer pendant la lecture sinon)    
    int img_size_w=3000;
    int img_size_h=3000;
    int offset_x=img_size_w/size_icon_w;
    int offset_x_end=((img_size_w-(offset_x*size_icon_w))+(((int)(img_size_h/size_icon_h))*img_size_w))* octetsParPixel;
    offset_x*=octetsParPixel;
 
    int current_offset=0;
 
		for (l = size_icon_h;l--;)
		{			
			for (k = size_icon_w;k --;)
			{				
				// positionner le pointeur sur le pixel à lire
				SetFilePointer(inStream, current_offset, NULL, FILE_CURRENT);
 
				// Décal de l'offset en x
        current_offset = offset_x;
				// lire le pixel 
				ReadFile(inStream, framePtr, octetsParPixel, &bytesRead, NULL); 
 
 
				// incrementer le pointeur du buffer
				framePtr += octetsParPixel;
 
			}
 
			// Réaligne le décalage en fin de X et ajoute le décalage en Y
      current_offset = offset_x_end;
 
		}

Bon si je me suis pas tromp� (j'ai rien test� !!!

), tu pr�calculs tout, ensuite tu te d�cales dans le fichier pour lire les bons pixels.
offset_x_end permet de "sauter" sur la prochaine ligne en tenant compte que l'image de r�duction n'est pas proportionnel.

Pour bien faire il faudrait limiter les appels de fonctions dans la boucle...
Ensuite cela devient dur de rogner.

Le mieux comme il est dit au dessus, est de tout sauvegarder dans des fichiers, pour les relire ensuite.

ps: Vivement que je trouve un job en imagerie j�adore cela

Je met en garde toute meme sur l'application. Cet exemple est certainement valable pour une lecture sur disque dur mais abslument pas pour un support sur CD ! Sur CD tu gagnera en rapidit� en lisant un grand nombre de donn�es contigue et non en sautant les pixels non lues.

**cheho** · 29/08/2006, 16h45

Je n'ai pas pr�cis� que la plupart des images sont sur le r�seau, sur des disques sur lesquels on n'a pas droits d'�criture. Alors il faut enregistrer les ic�nes sur les disques locaux des utilisateurs et � chaque fois avant d 'afficher les miniatures, v�rifier qu'il n'y a pas de changements dans le r�pertoire des originaux?

**rigobert** · 29/08/2006, 16h51

Oui.

On appelle �a un cache local.

Tous les browsers internet font �a par exemple.

**Ti-R** · 29/08/2006, 17h16

v�rifier qu'il n'y a pas de changements dans le r�pertoire des originaux?

Plusieurs techniques

- Date de cr�ation/modification du fichier
- Taille du fichier

Surement d'autres, mais pour ton cas, je ne vois pas trop d'autres solutions.

**Higestromm** · 29/08/2006, 17h19

Envoy� par Ti-R

Plusieurs techniques

- Date de cr�ation/modification du fichier
- Taille du fichier

Surement d'autres, mais pour ton cas, je ne vois pas trop d'autres solutions.

Un MD5 du ficher c'est aussi bien efficace... par contre pas moyen de savoir lequel est le plus r�cent.

**Ti-R** · 29/08/2006, 17h30

Envoy� par Higestromm

Un MD5 du ficher c'est aussi bien efficace... par contre pas moyen de savoir lequel est le plus r�cent.

Je ne l'ai pas propos�, car on le fait g�n�ralement sur une partie du fichier... sur une image en niveau de gris il faut bien "viser", si tu prends un bord g�n�ralement noir, MD5-> KO

De plus un MD5 n�cessite de lire le fichier (pas en entier) mais c'est toujours plus lent si tu dois acc�der � certaines zones de l�image. (Surtout que la taille des icones � g�n�r�e est ridicule)

Je suppose (j'ai peut �tre tord) que l'image g�n�r�e poss�de une date interne... vu que tu ne peux �crire dedans, et que tu ne peux que lire les fichiers, vu que c'est orient� professionnel, bas� sur des scanners, la date devrait �tre incluse dans le format de l'image... donc � se baser sur le nom de l�image plus sa date interne, cela devrait aller et �tre rapide.

**Higestromm** · 29/08/2006, 17h46

Envoy� par Ti-R

Je ne l'ai pas propos�, car on le fait g�n�ralement sur une partie du fichier... sur une image en niveau de gris il faut bien "viser", si tu prends un bord g�n�ralement noir, MD5-> KO

De plus un MD5 n�cessite de lire le fichier (pas en entier) mais c'est toujours plus lent si tu dois acc�der � certaines zones de l�image. (Surtout que la taille des icones � g�n�r�e est ridicule)

Je suppose (j'ai peut �tre tord) que l'image g�n�r�e poss�de une date interne... vu que tu ne peux �crire dedans, et que tu ne peux que lire les fichiers, vu que c'est orient� professionnel, bas� sur des scanners, la date devrait �tre incluse dans le format de l'image... donc � se baser sur le nom de l�image plus sa date interne, cela devrait aller et �tre rapide.

+1

J'ajouterais meme qu'il est ill�gal de modifier une image m�dicale au format DICOM (certainement le format utiliser ici) pour des raisons evidentes d'erreures m�dicales � cause d'un ptit malin. Donc dans l'absolue la date de l'image ne devrais pas avoir d'importance car jamais modifi�e.

**cheho** · 30/08/2006, 09h57

Tout d�abord merci pour vos explications et id�es. Il s�agit d'un format d�velopper chez PHILIPS nomm� FXD , DICOM c'est � SIEMENS, c'est plut�t technique, l'ent�te comporte des info concernant l'image, on va dire c'est un format interm�diaire. Ce sont des images de teste et des images comportant des d�fauts renvoy�es par les clients. Donc on ne les modifie pas, je dois juste v�rifier si l�image existe et si il y en a des nouvelles.

**Higestromm** · 30/08/2006, 17h11

Envoy� par cheho

DICOM c'est � SIEMENS

M�me si on s'�loigne du sujet, le format DICOM n'est pas du tout a Siemens, il s'agit du protocol standard en imagerie m�dicale.

Pour plus d'info regarde ici : http://medical.nema.org/

**jeroman** · 31/08/2006, 00h50

L'id�e du MD5 me parait tr�s dangereuse, car m�me s'il existe une infime chance pour que deux fichiers diff�rents aient la m�me signature, c'est quand m�me un risque.
De plus, j'ai lu, pas plus tard que cet apr�s-midi, qu'un gusse a r�ussi � "casser" le MD5. Il a trouv� le moyen de modifier des fichiers afin qu'ils soient diff�rents mais qu'ils aient la m�me signature MD5.

Enfin, tout �a pour dire que pour conna�tre la signature d'un fichier "classique", �a peut faire l'affaire. Mais concernant une image m�dicale, on ne plaisante pas avec �a. Les cons�quences peuvent �tre desastreuses si deux images sont interverties accidentellement. Style le m�decin pense regarder l'image du patient A alors qu'il s'agit de celle du patient B...

**Higestromm** · 31/08/2006, 08h23

Envoy� par jeroman

L'id�e du MD5 me parait tr�s dangereuse, car m�me s'il existe une infime chance pour que deux fichiers diff�rents aient la m�me signature, c'est quand m�me un risque.
De plus, j'ai lu, pas plus tard que cet apr�s-midi, qu'un gusse a r�ussi � "casser" le MD5. Il a trouv� le moyen de modifier des fichiers afin qu'ils soient diff�rents mais qu'ils aient la m�me signature MD5.

Enfin, tout �a pour dire que pour conna�tre la signature d'un fichier "classique", �a peut faire l'affaire. Mais concernant une image m�dicale, on ne plaisante pas avec �a. Les cons�quences peuvent �tre desastreuses si deux images sont interverties accidentellement. Style le m�decin pense regarder l'image du patient A alors qu'il s'agit de celle du patient B...

En effet. Ceci dit dans le cas d'image au format DICOM il est impossible de m�langer des images inter-patient. En effet, l'en-tete dicom est barder d'UID concernant l'imae, le patien, la serie, l'examen et j en passe. Au r�sultat, juste en prenant les images on est capable de savoir pr�cisement a qui appartiennent les photo, pour quel examen, etc...

Donc, sauf dans un cas d�lib�rer (par un cracker) de vouloir foutre le bordel, ce qui implique de modifier les ent�tes de tous les fichiers stock�s, le format en lui m�me est relativement securis�.

Conclusion : Si il y a moyen de r�cup�rer l'UID de l'image alors tu peux t'en servir. (comme tu n'est pas a la norme DICOM je ne sait pas si tu poss�de ces infos dans ton entete)

**Ti-R** · 31/08/2006, 10h46

Envoy� par jeroman

L'id�e du MD5 me parait tr�s dangereuse, car m�me s'il existe une infime chance pour que deux fichiers diff�rents aient la m�me signature, c'est quand m�me un risque.
De plus, j'ai lu, pas plus tard que cet apr�s-midi, qu'un gusse a r�ussi � "casser" le MD5. Il a trouv� le moyen de modifier des fichiers afin qu'ils soient diff�rents mais qu'ils aient la m�me signature MD5.

Enfin, tout �a pour dire que pour conna�tre la signature d'un fichier "classique", �a peut faire l'affaire. Mais concernant une image m�dicale, on ne plaisante pas avec �a. Les cons�quences peuvent �tre desastreuses si deux images sont interverties accidentellement. Style le m�decin pense regarder l'image du patient A alors qu'il s'agit de celle du patient B...

En m�me temps c'est juste pour faire un id pour rafra�chir un icon....

De plus, j'ai lu, pas plus tard que cet apr�s-midi, qu'un gusse a r�ussi � "casser" le MD5. Il a trouv� le moyen de modifier des fichiers afin qu'ils soient diff�rents mais qu'ils aient la m�me signature MD5.

Dans de cas vraiment tr�s pr�cis... il y a des collisions c'est vrai mais bon... enfin oui le MD5 n'a rien � faire ici comme je l'ai signal� plus haut

**cheho** · 15/09/2006, 13h57

Salut , j'ai fait un cache, tout semple, je sauvegarde les miniature comme des fichiers bmp dans un dossier local ensuit je v�rifie si le fichier bmp existe si oui j'affiche le bmp sinon comme avant je cr�e sa miniature. Le probl�me maintenant c'est que quand on click sur la miniature on ne peut pas afficher l'image d'origine. L'Explorer reconna�t que c'est un fichier fxd , je croix, en v�rifiant les propri�t�s c'est marquer fichier fxd mais en cliquant dessus on ne peut pas l'ouvrir dans la visionneuse de fxd. Avant �a marchait impeccable, apparamnet l'Explorer ne fait pas le lien entre l'ic�ne bmp et le fxd d'origine.

**Higestromm** · 15/09/2006, 14h14

ton probl�me me semble plus li� � une config de windows qu'as un probl�me c++... v�rifie tes associations extention / programme

optimiser lecture fichier image

C++

Discussions similaires

Partager

Partager