[Dcmlib] converting itk,vtk or any other 3D images into dicom.

[Jean-Pierre ROUX]

At 17:34 -0500 8/11/04, Mathieu Malaterre wrote:
>Jean-Michel,
>
>	Enorme ! J'adore le patch, beau boulot !
>
>	Juste parce que je suis quelqu'un de complique' je ne vais 
>pas l'appliquer directement. Depuis un moment me trotte dans la tete 
>cette idee de generation de methode base'e sur le dictionnaire. Je 
>vais essaye de le mettre en place.
>
>	Sinon au passage, pourquoi tu utilises 
>ReplaceOrCreateByNumber et pas ReplaceOrCreateByName. Est-ce qu'il y 
>a eu un probleme en particulier ?



--> ReplaceOrCreateByName ne doit pas exister pour le moment.
--> les methodes xxxByName sont un peu dangereuses car, clairement, 
il n'est dit nulle part que le 'name' est un identifiant dans le 
Dicom Directory.

Bien au contraire, a cause dee ensembles de Dicom Groups 60xx et 
50xx, qui comportent donc chacun potentiellement 255 Groups (même 
s'il n'y en a que 8 présents dans la version actuelle de dicomV3.dic) 
montre qu'il y a 255 synonymes .
De plus, quelques autres Dicom Elements 'isolés' (Raws, Columns, etc) 
ont le même nom.

xxxByName va chercher dans une H Table (std::map) qui pointe sur le 
Dicom Dictionary 'le' nom, en déduit le tag (GroupNumber, 
ElementNumber), et appelle ensuite xxxByNumber sur le Header...
Pas de manière simple (ni compliquée, d'ailleurs) de gérer les 
synonymes, car il peut, de plus y avoir *dans un Header* donné (et 
pas seulement dans de Dicom Dictionary), plusieurs groups de 
l'ensemble 60xx -une image de gdcmData a cette particularité-

De plus, d'une année sur l'autre, une dizaine -au moins- de Dicom 
Elements changent de nom (tout le monde -?- se souvient de "Patient 
Name" qui, devenu "Patient's Name", cassait la test suite de gdcm)

On pourrait attendre pour voir si le group de réflexion DICOM sur 
l'API a une opinion sur la question, mais la sagesse serait de ne 
*jamais* utiliser les xxxByName.
Voila ...

Jean-Pierre Roux


>
>	Au fait comment tu as eu le warning:
>
>return (float) atof( strSliceThickness.c_str() );
>       ^^^^^^
>
>	Il n'apparait sur aucune machine, ici ?
>
>
>Mathieu
>
>
>
>jean-michel.rouet at philips.com wrote:
>>Hello everybody,
>>
>>bon j'en suis a une version a peu pres corecte (a mon avis) de mon writer.
>>J'ai du changer quelques petites choses dans gdcm pour que ca 
>>fonctionne bien, mais rassurez vous, rien de bien méchant.
>>
>>Dans le principe:
>>+ J'ai utilisé le constructeur par défaut, celui qui ne prend aucun 
>>argument, de gdcm::Header. Ma version initialise les principaux 
>>tags utiles.
>>+ J'ai rajouté quelques setters pour positionner des tags tels que 
>>PatientName, image position, etc.
>>+ J'ai initialisé quelques membres pour eviter quelques warning de 
>>Purify dans:
>>       gdcmDocEntry (ReadLength, Usable,Length et PrintLevel)
>>       gdcmDocument (SwapCode, Filetype)
>>+ J'ai rajouté quelques barricades autour de Document::OpenFile(), 
>>quand justement il n'y a pas de fichier a ouvrir
>>+ Quelques petites choses pour eviter des warnings de visual 
>>(variable i dans gdcmSQItem.cxx ligne 109, 123)
>>
>>
>>Voila donc le patch contre la version courante de cvs. (gdcm.patch)
>>
>>Et un petit programme d'exemple qui utilise itk pour lire une image 
>>3D en entrée, et qui sauve ensuite le dicom sous forme d'une série 
>>de fichier dans un répertoire. (volume2dcm.cxx)
>>
>>Je mets le tout dans un zip...
>>
>>
>
>
>
>_______________________________________________
>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