[Dcmlib] gdcm proposal

[Jean-Pierre ROUX]

At 10:21 -0400 26/04/05, Mathieu Malaterre wrote:

[...]

>    Sinon dans les commentaires en vrac, je continue a donner un role
>different a /l'image DICOM/. Pour moi on peut parfaitement avoir un
>header avec PixelSize=12, Spacing=0,0 et pourtant l'image gdcm.Image
>doit etre construite correctement. Ainsi on peut faire PrintDocument et
>montrer les valeurs effectivement lues, et aussi bien plus tard sauver
>l'image correctement. L'idee serait que gdcm.Writer ecrive un
>dictionaire dont les valeurs se baserait sur gdcm.Image (et ecraserait
>celle de l'input). Je fais reference a l'horeur qui est faite en ce
>moment dans gdcm, si une image est codee sur 12 bits juste avant de
>l'ecrire on change 12 -> 16 ... ce qui veut dire que PrintDocument est
>dependant de l'ordre des actions au moment de l'ecriture.

J'ai l'impression que decris la situation  'gdcm-Juillet 2004' ...
L'ecriture d'un fichier provoquait'en douce' la modif de certains 
champs (comme ce que tu décrits), ce qui fait qu'effectivement un 
Print() n'aurait pas eu le même output avant et pares l'ecrire du 
fichier.


Ce n'est plus le cas actuellement, et j'ai l'impression que le 
'dictionaire dont les valeurs se baseraient sur gdcm.Image (et 
ecraseraient celles de l'input)', il y a deja le 'Archive' qu'a ecrit 
Benoit il y a plusieurs mois, qui fait ca.
Me trompe-je?


>    J'ai essayer d'avoir un reader/writer ala VTK, mais c'est aussi base
>sur le principe de ifstream/ofstream. Je fais donc le choix de dupliquer
>le header DICOM... ou alors il faudrait faire un Writer astucieux qui au
>moment d'ecrire valeur par valeur verifierais qu'il n'ecrive pas une betise.
>
>    J'introduis aussi la notion de gdcm.Validator ou par exemple on
>verifierais la VM des elements et autres DICOMeries.

J'avais proposé, en son temps, de faire un 'Check Header'qu'on aurait 
lancé juste avant d'écrire, et puis laissé tomber l'idée :
Si, lors du Test Write Dicom (ou l'on prend tous les champs, un par 
un, pour faire un nouveau 'gdcm::Document'), on trouve une VM qui 
n'est pas bonne, que fait-on? On refuse d'écrire le fichier, alors 
qu'il aurait été la copie conforme d'un fichier Siemens, par exemple?

Quant aux champs de type 1, 1C, 2, 2C, 3, vu que leur type varie 
selon la modalité (et que les constructeurs ne le respectent pas), ca 
ferait de la programmation kilometrique, pour, probablement pas 
grand-chose.

JPRx

>
>    Merci de me faire part de vos commentaires.
>
>Mathieu
>Ps: y'a beaucoup de choses a dire mais j'ai peur de faire un mail trop
>long et personne ne le lirait...enfin bon je verrai bien les reactions
>et en fonction je serais + prolix
>_______________________________________________
>Dcmlib mailing list
>Dcmlib at creatis.insa-lyon.fr
>http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib

  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