[Dcmlib] gdcmHeaderHelper

[Mathieu Malaterre]

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.


Remarques/suggestions/critiques bienvenues,

mathieu
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testHelper.cxx
URL: <http://www.creatis.insa-lyon.fr/pipermail/dcmlib/attachments/20030721/8a501ad6/attachment.cxx>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gdcmHeaderHelper.h
URL: <http://www.creatis.insa-lyon.fr/pipermail/dcmlib/attachments/20030721/8a501ad6/attachment.h>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gdcmHeaderHelper.cxx
URL: <http://www.creatis.insa-lyon.fr/pipermail/dcmlib/attachments/20030721/8a501ad6/attachment-0001.cxx>