[Dcmlib] ITK + GDCM

[Mathieu Malaterre]

> 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 ?

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 ?