[Dcmlib] gdcm proposal (1)

Thu Apr 28 17:23:31 CEST 2005

1ere partie (sinon ca passait pas...)

Je crois qu'il y a eu confusion dans la compréhension de Document.
Pour moi, Document, c'est le contenu Dicom (donc une donnée qui equivaudrait
à un vtkImageData).
Pour Mathieu, il semble que c'etait plutot la partie Reader/Writer. 
Ce qui je crois amene des confusions dans les reponses aux questions.

Je crois qu'il faut commencer à donner des noms correct. Voici ce que je propose 
(je ne prefixe pas de gdcm pour ne pas alourdir les choses) :
DocEntry : comme le DocEntry actuel (contient gr|elem + VR + value)
                 dérivé en ValEntry, BinEntry, SeqEntry
SQItem : comme le SQItem actuel, données contenant une liste de DocEntry.
Document : données contenant une liste de DocEntry.
                  gère une image Dicom. Contient des méthodes facilitant l'accès aux
                  informations de l'image : taille, spacing, origin, orientation, etc.
DicomDir : données contenant une arborescence 
                 DicomDirPatient / DicomDirStudy / DicomDirSerie / DicomDirImage
                 (qui sont aussi des données dérivant de SQItem)
Image : donnée image Dicom décompressée + Document ?

Reader : traitement qui permet de lire un fichier au format Dicom
DocReader : traitement qui permet de lire un fichier Dicom contenant un Document
                       retourne un Document
                      derive de Reader
DicomDirReader : traitement qui permet de lire un fichier Dicom contenant un DicomDir
                      retourne un DicomDir
                      derive de Reader

Writer : traitement qui permet d'ecrire un fichier au format Dicom
DocWriter : traitement qui permet d'ecrire un fichier au format Dicom à partir d'un Document
DicomV3Writer : traitement qui permet d'ecrire un fichier au format DicomV3
                      prend un Document en entrée     
                      derive de DocWriter 
LibidoWriter : traitement qui permet d'ecrire un fichier au format Libido
                      prend un Document en entrée     

                      derive de DocWriter 
AcrNemaWriter : traitement qui permet d'ecrire un fichier au format ACR-NEMA
                      prend un Document en entrée     

                      derive de DocWriter 
DicomDirWriter : traitement qui permet d'ecrire un fichier au format Dicom à partir d'un DicomDir
                      prend un DicomDir en entrée     

                      derive de Writer 
DocValidator : traitement qui verifie la structure d'un Document
                      prend un Document en entrée
                      retourne du texte
DicomDirValidator : traitement qui verifie la structure d'un DicomDir
                      prend un DicomDir en entrée
                      retourne du texte
SerieOrder : traitement ordonnant une serie de Document
                     prend une liste de Document en entrée
                     retourne l'ordre de ces documents (sous quelle forme ?)
Decompress : traitement decompressant l'image d'un Document
                     prend un Document en entrée
                     retourne une Image
Document2DicomDirImage : tranforme un Document en DicomDirImage
                     prend un Document en entrée
                     retourne un DicomDirImage
DicomDirImage2Document : tranforme un DicomDirImage en Document
                     prend un DicomDirImage en entrée
                     retourne un Document

On voit donc apparaitre une dérivation comme suit (incomplète bien sur) : 
Data
 - Document 
 - DicomDir
 - Image
Process
 - Reader
    - DicomDirReader
    - DocReader
 - Writer
    - DicomDirWriter
    - DocWriter
       - DicomV3Writer
       - LibidoWriter
       - DicomV3Writer
 - Validator
    - DicomDirValidator
    - DocValidator
 - SerieOrder
 - Decompress
 - Document2DicomDirImage
 - DicomDirImage2Document

Si j'ai bien tout compris, Mathieu, on aura une séparation données traitements (comme dans VTK).
Ceci n'est bien sur qu'une ebauche, s'appuyant sur ce qui fonctionne deja et les morceaux à changer.
L'arborescence n'est pas complète, et il y a peut etre des choses fausses ou a revoir.
Mais une question se pose avec cela... on fait comme dans VTK avec un pipeline mis a jour automatiquement 
ou pas ? Comment on gere les sorties, comme en VTK avec la meme sortie a chaque fois ou avec une 
nouvelle sortie ? Et quand le traitement est détruit, qui détruit la sortie ?
Désolé de ne parler que de VTK, je ne connais pas encore ITK (mais c'est pour bientot)

Ce qui me plait pas dans ce que je viens de présenter (et vi, on peut faire des choses pas belles des 
le début...) c'est la différence entre Document et DicomDirImage... ce qui nous oblige apres a avoir
des passerelles entre les 2. Mais d'un autre coté, c'est justifiable sur le fait que les deux n'ont pas 
tout en commun... mais la question va etre : pourquoi ne pas dire qu'un DicomDirImage est un Document ?
et bien tout simplement car dans le DicomDirImage (actuel), on n'a que les champs correspondant au 
niveau image du DicomDir, le DicomDirSerie contenant les info de la serie, idem avec Study et Patient.
Or, le Document doit contenir toutes les infos de chaque niveau du DicomDir (Patient + Study + Serie + Image).
Avoir ces convertisseurs obligerait aussi a pouvoir remonter de l'Image jusqu'au Patient, ce qui n'est pas le cas
actuellement (mais rien empeche de le faire ;-) )

----- Original Message ----- 
From: "Mathieu Malaterre" <mathieu.malaterre at kitware.com>
To: "Benoit Regrain" <benoit.regrain at creatis.insa-lyon.fr>
Cc: "Mailing list gdcm" <dcmlib at creatis.insa-lyon.fr>
Sent: Wednesday, April 27, 2005 5:45 PM
Subject: Re: [Dcmlib] gdcm proposal

> 
>> 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) ?
> 
> Mon probleme est plus vaste, je voudrais un mechnisme qui interdise de 
> modifier l'input d'un filtre. Je concois parfaitement maintenant que 
> j'ai souligner le probleme on aille le deplacer ailleurs ou le cacher....
> 
> Sinon pour l'ecriture effectivement le 12 qui devient un 16 ca devrait 
> etre temporaire. Par exemple un gdcm.Validator ne pourrait pas reporter 
> que BitsStorage=12 est une faute, pourtant dans le cas present -et pour 
> lontemps- nous sommes incapable de gerer ca. Donc au moment de 
> l'ecriture gdcm.Writer fais la suite d'actions:
> 
> (version gourmande):
> - recopie du gdcm.Document dans un gdcm.Document interne
> - ensuite gdcm.Writer regarde gdcm.Image et doit determiner les valeurs 
> a changer: BitStord 12 devient 16, dans le Cas clunie, les spacing=0 
> deviennent 1 ...
> - ensuite on ecrase les anciennes UID (user request ?) par les valeurs 
> generer
> -> derniere etape on ecris le fichier.
Autre solution, utiliser ma méthode d'archivage des Entry de facon temporaire,
modifier la source, puis tout remettre en place. Mais est-ce une bonne solution ?
Pour ce qui est de la copie, cela ne risque-t-il pas de ralentir les choses ?
Ou sinon, il faudrait pouvoir faire comme dans VTK... des DeepCopy et
des ShallowCopy. Dans ce cas, il faudrait proprement gerer l'appartenance d'un Entry
par un Document... donc ajouter du reference counting... 

Benoit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.creatis.insa-lyon.fr/pipermail/dcmlib/attachments/20050428/8520a109/attachment.html>