[Dcmlib] gdcmHeaderHelper

[Benoit Regrain]

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 ?

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.

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