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

[Mathieu Malaterre]

> Maintenant que Jean-Michel Rouet a fort gentiment essuye' les platres pour
> nous, et que Mathieu a aussi un peu souffert en voulant ecrire des

tu veux dire 'beaucoup' faut pas oublier que j'ai integre gdcm dans ITK :P

> images, je pense (comme JPR, mais a plus court terme) qu'il est en effet
> assez urgent de parler de l'API.

ok

> Je pense paticulierement aux points suivants qu'il faudrait clarifier:
>   1/ l'acces au tag
>   2/ distinction des operations de modification/creation d'un tag
>   3/ definition du mode d'ecriture.

Avant meme de commencer je suis toujours surpris de voir des reponses 
sans avoir vu passer les questions dans les groupes comme 
comp.protocols.dicom, sans avoir analyser les sources de dcmtk, osirix ...

> Avant de lancer le[s] troll[s], je cite l'extrait suivant du commentaire
> doxygen de la definition de TagKey (typedef) dans src/Common.h:
[ snip ]
> Bref, la representation interne a gdcm d'une clef de tag (appele' pompeusement
> clef generalise'e) est un string de la forme:  
>   - 0028|1201 pour un tag "a plat" (pas dans une sequence).
>   - 0004|1220/2#0008|0082/0#0008|0090... pour un tag de sequence

Ca dois etre une question stupide. Mais pourquoi ne pas faire une notion 
de namespace. 0028|1201 serait dans le namespace 'root'. Et ensuite ont 
pourrait avoir 0028|1201 dans la SQ 'SQ1', puir 0028|1201 dans 'SQ34' ...
Je suis un peu contre le fait de construire des chaines de caracteres 
complique'e.

>    Question 1a/:
>        D'ou la question: ne devrait-on purement et simplement supprimer
>                          l'acces au tag par nom ?

Je suis pour. Ca permettra en plus de reduire le nom de la methode 
'Get*ByNumber' devient 'Get*'

>    Question 1b/:
>          - DictEntry::TranslateToKey(group,element) )
>          - et une version a ecrire pour la clef generalise'e

cf au dessus. Je trouve la version 'a la volee' plus flexible. Et en 
interne dans GDCM, on utilise que group/element. Donc le surcout ne sera 
que pour l'utilisateur final.

>    Question 1c/:
>       les sequences "collapsables" a la e-Film: c'est une demande

houla je comprends deja plus...

> ######################
> Point 2/ distinction des operations de modification/creation d'un tag
>       Actuellement nous offrons ReplaceOrCreateByNumber(). Il serait bon,

J'ai toujours haie cette methode. Je suis incapadle de taper plus de 
trois caracteres sans me tromper, donc imaginer avec un nom de methode 
aussi long. Dans aucune structure stl je ne vois d'equivalent. Pour il a 
trois choses: Set/ Get/ Insert:
- Set(i, val), on met la valeur val a la position i. Si i n'existe pas 
le prog seg fault, tant pis pour nous.
- Get(i), retourne la valeur val a la position i
- Insert(i, val), comme set. Mais si i n'existe pas alors on le cree.

ReplaceOrCreateByNumber n'a de sense que parce qu'on manipule en interne 
des pointeurs 'raw'. Il faut s'en cesse verifier qu'il n'est pas nulle. 
Je suis convaincu qu'on ne perdrait rien s'il on utilisait les objets 
directement plutot qu'un pointeur...

> 
> ######################
> Point 3/ definition du mode d'ecriture.
>      Mathieu a deja propose' que l'API soit VTK-like. Il faudrait donc

Je vais qd meme pas etre d'avis contraire :)
Sinon comme j'ai dis precedemment j'aimerais differencier input/output 
(ifstream/ofstream).
Ex concret, Jean Michel proposait une methode qui remplit avec des 
valeurs pas defaut certains champ (equivalent de l'image template de 
theralys). Je pose la question qu'est ce qu'une methode fais qd on ne 
fais que lire des images DICOM.

Meme si ca fais tres VTK, ITK je pense que c'est pas mal de differencier 
les reader des writers.

Inversement un writer n'a pas a connaitre d'heuristique pour determiner 
l'endianness d'un fichier (c'est le probleme d'un reader).

> 
> Si apres une telle incontinence verbale, y'a pas de commentaire, c'est a
> se flinguer...

J'aurais fais de mon mieux :)

Mathieu