[Dcmlib] Header vs File

[Jean-Pierre Roux]

Mathieu Malaterre wrote:

>>Les noms gdcmFile et gdcmHeader ne sont probablement pas tres clairs, 
>>mais on n'avait rien trouvé de mieux.
>>
>>Cette décomposition vient de ce que parfois les utilisateurs veulent 
>>seulement connaitre le contenu de la partie 'entete' du fichier pour, 
>>par exemple, la ranger dans une base de données (cf Theralys), ou 
>>pour savoir si le fichier courant est un File Of Interest pour leur 
>>application.
>>
>>Les méthodes qui traitent les pixels (lecture des pixels, ecriture du 
>>fichier) sont dans la classe gdcmFile.
>>Je ne maitrise pas suffisament la philosophie des Langages a Objets 
>>pour donner mon avis sur la pertinence de ce découpage.
>>(Est-ce pour éviter qu'un utilisateur qui n'est pas interessé par les 
>>methodes qui traitent les pixels n'ai accès à ces méthodes?
>>Il lui suffirait de ne pas les utiliser, et on n'a plus qu'une seule classe !)
>>
>
>Bon je reprends mon probleme particulier -je pense qu'il est suffisament generique-.
>Je lis deux repertoires DICOM (A et B), je fais un recalage, je sauvegarde le resultat du recalage en fichiers DICOM (repertoire C).
>
>Q: Comment est-ce que je fais ca avec gdcm ? 
>
>R: D'apres ce que j'ai lu, j'ai besoin de lire le repertoire A, le repertoire B, cree une image 'ITK A' et une image 'ITK B', faire mon recalage. Mais au moment d'enregistrer, je seche. D'apres les tests de gdcm (testChangeEntete), il faudrait que je relise toutes les images du repertoire A (en fait c'est les images de references, donc le spacing/origin/ etc seraient les memes), et que j'appelle SetImageData en passant un 'void *', correct ?
>

--> Mathieu :
Si tu as deleté les gdcmHeaders, effectivement, il *faudrait* les amener 
de nouveau en mémoire pour les avoir.
En général les plusieurs centaines d'entrées dans le Header, seul un 
très petit nombre est utile pour la suite.
Ex : il faudra connaitre NX, NY, image orientation, pixels spacing, etc
mais le  Patient Weight, le Refering Doctor, or a lot of stuff of that 
kind, you don't care about !
Si tu as conservé les quelques valeurs (avec leur group nbr, element 
number, VR) qui te seront necessaires, il sera possible
- de creer un gdcmHeader, vide, et de les ajouter (AddHeaderEntry), en 
respectant l'ordre <group-element>
- de creer un gdcmFile en passant de gdcmHeader au constructeur
- d'ajouter les Pixels que lui viens de 'fabriquer'
- d'écrire le tout

--> Emmanuel :
Tu m'avais dit que tu as une 'image' ne contenant que les champs 
strictement nécessaires pour qu'elle soit efilm-readable.
Pourrais-tu la commiter dans gdcmData?

--> les gdcmlibeux :
Le split entre gdcmHeader et gdcmFile ...
la dépendance était IS-A. Elle est actuellement HAS-A
Ce split a-t-il encore un interet?

>
>
>Si oui, alors j'ai deux alternatives:
>a) Lire rep A et B, refermer les images, faire le recalage, reouvrir les images A, sauvegarder C
>b) Ou Ouvrir les rep A et B, conserver un vector<gdcmFile> et au moment d'ecrire, parcourir ce vecteur et appeller SetImageData.
>
>L'avantage de b) ca m'evite de relire une n-ieme fois les image DICOM, mais j'ai un peu peur que l'empreinte memoire ne devienne enorme...
>
>Commentaires bienvenue (notemment de la part de Theralys ou si je me souviens bien vous avez tout un tas d'images ouvertes en memoire). Merci
>
>>En revanche :
>>gdcmHeader vs gdcmHeaderHelper ?
>>
>>dans la classe gdcmHeaderHelper, il y a les accesseurs 'à valeur 
>>ajoutée', qui n'ont rien à faire dans le gdcmHeader, c'est ça?
>>
>>Il reste qq accesseurs présents dans les deux classes.
>>A-t-on (ai-je) oublié de les virer lorsqu'on (nous deux) a splitté la 
>>classe gdcmHeader ?
>>D'autre part les accesseurs GetXDim, GetYDim etc, sont dans gdcmHeader.
>>(pas bcp de valeur ajoutée, mais si on décide de traiter *également* 
>>les images PAPYRUS 3.0 -DICOM Like, avec qq particularités-, il y en 
>>aura, de la valeur ajoutée)
>>Est-il judicieux de passer ces accesseurs -et qq autres- dans 
>>gdcmHeaderHelper ?
>>Si on fait ça, la classe gdcmHeader ne sera pratiquement utilisée 
>>*que* par les développeurs, et la classe gdcmHeaderHelper par les 
>>utilisateurs.
>>
>
>Exact, dans itkGDCMImageIO je n'ai utilise quasiment que gdcmHeaderHelper (ITK a besoin de connaitre le type de l'image, la taille, l'origine ... sans avoir a se farcir les details du genre: a ben y'a qu'un seul spacing mentionne dans le fichier ou pas du tout: qu'est ce que je fais ?).
>Mais de memoire l'implementation actuelle est bancale, comme j'en suis le responsable (coupable?) je regarde ca desuite.
>
>Mathieu
>Ps: En relisant mon mail je viens de tomber sur testChangeEntete, JP si tu renommes les fichiers de test est-ce que tu peux essayer un nom plus franglish ?
>
>
>_______________________________________________
>Dcmlib mailing list
>Dcmlib at creatis.insa-lyon.fr
>http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>