[Dcmlib] gdcm proposal

Wed Apr 27 11:02:01 CEST 2005

Hi,

Attention, le mail est long ;-p

----- Original Message ----- 
From: "Mathieu Malaterre" <mathieu.malaterre at kitware.com>
To: "Mailing list gdcm" <dcmlib at creatis.insa-lyon.fr>
Sent: Tuesday, April 26, 2005 4:21 PM
Subject: [Dcmlib] gdcm proposal

>     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.

Dans le gdcm::FileHelper, les choses sont faites proprement, ce qui veut
dire que le Document d'origine n'est pas modifié. Il semble par contre
que le gdcm::File fasse des 'saloperies' que je n'avais pas vues...
Ca serait en effet a corriger pour la version courante de gdcm.
Par contre je n'ai pas compris : tu veux que ton gdcm.Writer modifie
définitivement le gdcm.Document passé en entrée ? ou que la modification
soit juste temporaire (le temps de l'écriture du fichier) ?

>     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.

Ca me plait beaucoup ca. Ce n'etait pas possible il y a plus de 6 mois dû
à la complexité interne de gdcm. J'y avais déjà pensé, mais c'était 
infaisable.
La dessus, je suis 100% d'accord.

--------------------------------------------------------------------------
Maintenant voici mes remarques :
 - le File (dérivé du Document) fait déjà une bonne partie de ce que tu
veux faire. Je pense qu'en effet, il est bien de garder cette structure qui
convient parfaitement.

 - le DicomDir (dérivé de Document), tu n'en parles pas. Etant donné
qu'il n'a pas besoin de la complexité interne du Document, garde-t-on
cette dérivation ? (elle est à l'heure actuelle utile car le Document 
contient
toute la partie Reader/Writer, mais je pense qu'on peut s'en abstraire
pour la structure que tu proposes).

 - Dans la création d'un Element du Document... comment on
différencie les ValEntry, BinEntry et SeqEntry ? A l'heure actuelle,
on fait cette différenciation à la création de l'élément en fonction de son 
VR.
De plus, un Element (ou DocEntry à l'heure actuelle) est rataché à un 
DictEntry.
Tu fais ce rattachement à quel moment ? De plus lorsque le dictionnaire 
publique
ne contient pas le tuple (group, element, VR) il en crée un nouveau 
sauvegardé
dans une zone tampon... garde-t-on cela qui n'est pas tres propre ? ou 
place-t-on
le VR de l'Element dans l'Element ? Ce qui nous donnerait :

newel = gdcm.Element("OB")    // La VR est affecté au moment de la création 
de l'objet
newel.Set(0x1234,0x5678)       // On va rechercher le DictEntry 
correspondant... mais dans quel Dict ?
newel.SetValue("foobar")          // Et pour une valeur binaire ou une 
séquence, que fait-on ?

Mais ceci ne résoudrait pas le problème de création de l'élément en fonction 
de sa VR.
Car avec ce choix, l'utilisateur peut créer un Element de VR "SQ" et mettre 
des données
textuelles dedans. Une solution serait de mettre le constructeur en 
protected
et d'avoir un New avec une création de l'objet en fonction de la VR...

 - Concernant l'écriture des series, tu considères avoir en entrée une liste 
de Document
ou un seul Document contenant une image 3D ? Pour moi, la liste de Document
et nettement plus adaptée car d'un Document à l'autre, de nombreux champs de
l'entete peuvent varier.

 - Une question qui ne peut se déduire du code python : la création des 
objets
se ferait par quelle méthode ? une méthode New comme en VTK, ou un new
habituel comme on fait actuellement ?

 - Concernant les Series, tu fais un SerieReader... qui remplacerait 
surement
le SerieHelper actuel... je ne suis pas sur qu'il s'agisse d'une bonne 
solution
(d'après ce que j'ai compris de l'intérêt du SerieHelper). Le SerieHelper a 
pour
but d'ordonner les différents fichiers d'une meme série. Or l'utilisateur 
pourrait
très bien vouloir lire ses différents fichiers d'une part, puis les trier... 
or s'il passe
dans un SerieReader, il va de nouveau relire ces fichiers. Il serait mieux 
d'avoir
un SerieOrder qui prend en entrée une liste de Document (donc les fichiers 
sont
déjà lus) et ce process ne ferai qu'ordonner cette liste (suivant les 
critères actuels
du SerieHelper).

 - Pour la classe Image, je n'ai pas très bien compris comment elle 
fonctionne.
A-t-elle une sortie ? et quel type de sortie ? ... simplement un tableau de 
données comme
le fait le FileHelper actuel lorsque tu appelle la méthode GetImage ?
Et lorsque l'utilisateur demande un sous-volume englobant le volume 
précédement lu,
réutilise-t-on le volume précédemment lu ?

image = gdcm.Image()
image.SetInput( reader.GetOutput())
image.SetSubVolume(512,512,1,3)  # SetVOI / SetExtent
image.Construct()
image.SetSubVolume(512,512,0,10)  # SetVOI / SetExtent englobant le VOI 
precedent.
image.Construct()

 - Pour l'ecriture des images créées from scratch. Comment cela se 
passerait-il ?
Tu as dit que l'Image replacerait les champs du Document, ce qui veut dire 
qu'il
faut passer à la fois une Image et un Document au Writer ? Sur ce point, je 
crois qu'il
manque un exemple d'utilisation. J'ai aussi beaucoup de mal à voir ce que tu 
appelles
Image...

--------------------------------------------------------------------------

Voila, les remarques sont finies. Certaines rentrent déjà dans 
l'implémentation, j'espere
donc que je ne les pose pas trop tot. Je crois sinon que j'ai fait le tour 
du sujet.
Sinon, moi aussi je ne vais pas avoir beaucoup de temps à investir dans le 
développement
de cette nouvelle mouture de gdcm... mais ce sera un problème à voir 
lorsqu'on aura
défini la structure finale de gdcm !
Je pense que cette fois ci, il ne faut pas commencer à développer avant 
d'avoir la structure
finale de la librairie et d'avoir vérifié que les exemples créés conviennent 
à tout ce
dont on a besoin.

Désolé pour la longueur du mail. J'ai essayé d'etre le plus constructif 
possible, et
ca prend de la place. J'espere que vous serez arrivé jusqu'ici

Benoit

PS : Mathieu, tes exemples sont une très bonne idée. Je pense qu'il faut 
continuer à les
faire et les compléter au fur et à mesure... afin d'avoir l'utilisation 
complète et finale
de la librairie.