[Dcmlib] gdcm proposal (1)
Mathieu Malaterre
mathieu.malaterre at kitware.com
Fri Apr 29 17:02:51 CEST 2005
J'ai repondu a celui la...
Benoit Regrain wrote:
> 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
> <mailto:mathieu.malaterre at kitware.com>>
> To: "Benoit Regrain" <benoit.regrain at creatis.insa-lyon.fr
> <mailto:benoit.regrain at creatis.insa-lyon.fr>>
> Cc: "Mailing list gdcm" <dcmlib at creatis.insa-lyon.fr
> <mailto: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
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
More information about the Dcmlib
mailing list