[Dcmlib] gdcmWriter, VtkGdcmWriter, ItkGdcmWriter

[Jean-Pierre ROUX]

Bonjour.

C'est clair qu'on est en train de faire 3 fois ma meme chose ...

Mathieu avait raison quand il disait que toutes les finasseries 
devaient etre faites au niveau de gdcm.

Champs obigatoires :
C'est sportif, car ils dependent de la modalite.
Ex : Image Position Patient est ogligatoire pour les images IRM, et 
n'a aucun sens pour une image Rayons X, une image Ultrasons, etc
Si on veut faire qq chose qui ne fasse pas tousser dicom3tools, il 
faudra prendre la doc Dicom de reference, et faire une GROSSE 
fonction (qui unifiera
CheckMandatoryEntries et InitializeDefault ?)

Reste a definir precisement ce qu'on laisse a l'utilisateur le soin 
de faire, ce qu'on lui interdit de faire.
Et a quel moment.
Et pour quoi faire.

3 cas, a mon avis :

- L'utilisateur a un tableau de pixels, qu'il a créé a partir de 
rien, et veut faire une 'vraie' image Dicom.
- L'utilisateur a une image ACR-Nema ou une image Dicom non conforme 
et veut la normaliser
- L'utilisateur a un ensemble d'images, et veut creer de nouvelles 
'Series', contenant, par exemple des images parametriques, et ajouter 
ces 'Series' a  l'examen (Study) d'ou proviennent les images source, 
ayant servi a faire les images parametriques.
Il faudra alors qu'on decide quelle latitude on lui laisse pour les UID.
vraisemblablement :
. UID de l'image : on le cree sans lui permettre d'intervenir.
. UID de la Serie: il faudrait lui permettre de le conserver d'une 
image a l'autre, s'il veut creer une nouvelle serie -mais pas de 
rajouter des images a une 'Serie du constructeur' (?)-
. UID de l'examen: on devrait pouvoir lui permettre de le conserver 
d'une image a l'autre, et également de reutiliser le Study UID d'une 
'image constructeur'.

Une alternative a ca est de considerer qu'il est conscient de ce 
qu'il fait, et de le laisser se debrouiller tout seul.

Autre chose :
Dans ce que j'avais ecrit, et que Benoit a eu raison de commenter 
out, car on ne s'etait pas mis d'accord sur l'endroit ou etait geres 
les UID, et donc ca petait la test suite, je considerais que 
l'utilisateur *savait* les champs auxquels il devait affecter une 
valeur (P.ex : Nom Patient, ID Patient, nom medecin, etc), et, s'il 
ne l'avait pas fait, la methode CheckMandatoryEntries, juste avant 
d'ecrire l'image, rajoutait (et poussait dans l'archive) les champs 
obligatoires qui manquaient (et les virait apres l'ecriture), de 
telle sorte que l'utilisateur ne 'voit' dans les Entries de son image 
que ce qu'il a lui meme mis (et dont les valeurs etaient 
naturellement conservees).

Un autre solution serait de mettre a sa disposition une methode 
InitializeMandatoryEntries(modality)  qui construise un gdcm::File 
avec les entries obligatoires pour cette modality et laisser a 
l'utilisateur le soin de les remplir.

Ya plu ka se decider...

JPRx




  Jean-Pierre ROUX
  UMR CNRS 5515-CREATIS
  Laboratoire de Radiologie Experimentale
  Hopital Cardiologique
  28 Avenue du Doyen LEPINE
  B.P. Lyon-Montchat
  69394 Lyon Cedex 03

  Tel      : (+33) 04 72 35 74 12
  Fax      : (+33) 04 72 68 49 16
  URL      : http://www.creatis.univ-lyon1.fr
  e-mail   : jpr at creatis.univ-lyon1.fr