[Dcmlib] gdcmHeaderHelper

[Mathieu Malaterre]

Benoit Regrain wrote:
> Hello,
> 
> Tout d'abord, j'ai du mal a saisir l'intérêt réel de ces classes...
> C'est un peu noyé dans toutes les explications que tu donnes.
> Qu'apportent-elles de + exactement ?

L'exemple de GetZOrigin n'etait peut etre pas assez parlant.

Ce que je veux rajouter c'est un ensemble de méthodes pour manipuler des 
images dicom, par exemple :

- les classer car le nom de fichier ne le permet pas

- mettre en place des algorithmes avec des solutions de secours, qd une 
valeur n'est pas trouvée (ex: GetXOrigin, l'Image Position est 
0x0020,0x0032 pour une dicomV3, mais 0x0020,0x0030 pour une ACR-NEMA)

- Des algo + robuste (ex: GetYSpacing, si tu fais scanf(%f\\%f) pour 
recuperer le spacing tu peux avoir des surprises...)

...


> 
> Ensuite, si tu pense concerver des données d'entête dans le
> vtkGdcmReader grace à cette méthode, as tu parlé avec Eric
> des problèmes concernant la place mémoire qui pouvait être occupée ?
> (notamment si 500 fichiers sont chargés). Cela peut conduire a sa
> saturation.

Merci de soulever le problème ! J'avais aussi l'idée que l'on pouvait 
etre capable de lire :
- l'entete dicom seulement
- l'entete dicom *ET* l'image dicom
- seulement l'image dicom

Ainsi ca simplifierait la vie de vtkGdcmReader, comme tu l'as dis cette 
classe n'a pas besoin de retenir des infos dicom. C'est une classe pour 
faire de la visu ! Elle n'est pas sensée savoir que ce sont des fichiers 
dicom qui sont a l'origine du volume 3D.

Je vais voir comment partager entre des méthodes qui travaillent sur 
l'entete et des méthodes qui constuisent un volume

Voila, j'espere avoir ete + clair avec ces exemples,
mathieu

Ps: les commentaires/suggestions/critiques sont tjrs les bienvenue.


> 
> Benoit
> 
> ----- Original Message -----
> From: "Mathieu Malaterre" <Mathieu.Malaterre at creatis.insa-lyon.fr>
> To: <dcmlib at creatis.insa-lyon.fr>
> Sent: Monday, July 21, 2003 6:29 PM
> Subject: [Dcmlib] gdcmHeaderHelper
> 
> 
> 
>>Salut les gdcm-hackers,
>>
>>Suite à différents courriels (attention: ne plus utiliser email!) avec
>>Eric, je voulais un peu changer l'approche à gdcmHeader, et essayer
>>d'englober les heuristiques dicomesque dans une classe à part.
>>
>>Je joins donc au mail 3 fichiers:
>>
>>  - gdcmHeaderHelper.h
>>  - gdcmHeaderHelper.cxx
>>  - testHelper.cxx
>>
>>Le but principal de la classe gdcmHeaderHelper est *d'interpreter* les
>>résultats fournis par gdcmHeader.
>>Tandis que gdcmSerieHeaderHelper permet de stocker une liste d'images
>>dicom et de pouvoir récuperer les infos dans le but -secret- de
>>construire un volume 3D.
>>
>>Ainsi, je vois d'un coté:
>>- gdcmHeader, qui permet l'accès brute aux données,
>>
>>- gdcmHeaderHelper, qui interprete les données lues, remplace -le cas
>>échéant- par des données par défaut et est capable d'aller chercher
>>l'info dans le dict de gdcmHeader à différent endroit.
>>
>>Ex typique: gdcmHeaderHelper::GetZOrigin
>>On cherche l'origine de l'image d'abord dans:
>>- Image Position Patient
>>- Image Position (RET)
>>- Slice Location
>>- Location
>>- Sinon retourne 0.
>>
>>Vous l'aurez remarqué bcp des méthodes de cette classe proviennent de
>>gdcmHeader (introduites par jpr). Ces méthodes étaient là mais n'avaient
>>pas vraiment -AMHA- leur place ici.
>>
>>
>>Ajout réel:
>>
>>gdcmHeaderHelper::GetImageOrientationPatient -> angle d'acquisition (ce
>>sont de cosinus).
>>
>>gdcmHeaderHelper::GetImageNumber -> pour +tard, selon comment l'on veut
>>classer les images
>>
>>gdcmHeaderHelper::GetModality -> retourne le type de modalité (d'apres
>>un enum)
>>
>>gdcmSerieHeaderHelper::OrderGdcmFileList -> algo de classement de
>>fichiers dicom (pour l'instant se base sur l'IPP et l'IOP des patients).
>>
>>
>>Dans la TODO liste:
>>
>>- Certaines image dicom ont les plans RGB séparés, gdcmHeader récupére
>>les infos brute et gdcmHeaderHelper réordonnes les données pour
>>permettre le transfert à VTK ou d'autres soft,
>>
>>- Rendre +robuste l'algo d'ordonnancement d'un stack d'image dicom,
>>
>>- gdcmSerieHeaderHelper::AddFile(Name) devraient etre + intelligente ->
>>s'inspirer de vtkGdcm::CheckCoherence,
>>
>>- AddDirectory à implémenter.
>>
>>
>>
>>En principal défaut: je n'ai pas trouvé de solution viable à la
>>différence entre un dicom multiframe et une liste de fichier dicom...le
>>developpeur doit faire la différence.
>>
> 
> 
> 


-- 
Mathieu Malaterre
CREATIS
28 Avenue du Doyen LEPINE
B.P. Lyon-Montchat
69394 Lyon Cedex 03
http://www.creatis.insa-lyon.fr/~malaterre/