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