[Dcmlib] gdcmHeaderHelper

[Benoit Regrain]

----- Original Message -----
From: "Mathieu Malaterre" <Mathieu.Malaterre at creatis.insa-lyon.fr>
To: "Benoit Regrain" <benoit.regrain at creatis.insa-lyon.fr>
Cc: <dcmlib at creatis.insa-lyon.fr>
Sent: Tuesday, July 22, 2003 9:47 AM
Subject: Re: [Dcmlib] gdcmHeaderHelper


> Benoit Regrain wrote:
> > Hello,
> >
> > Tout d'abord, j'ai du mal a saisir l'intérêt réel de ces classes...
> > C'est un peu noyé dans toutes les explications que tu donnes.
> > Qu'apportent-elles de + exactement ?
>
> L'exemple de GetZOrigin n'etait peut etre pas assez parlant.
>
> Ce que je veux rajouter c'est un ensemble de méthodes pour manipuler des
> images dicom, par exemple :
>
> - les classer car le nom de fichier ne le permet pas
>
> - mettre en place des algorithmes avec des solutions de secours, qd une
> valeur n'est pas trouvée (ex: GetXOrigin, l'Image Position est
> 0x0020,0x0032 pour une dicomV3, mais 0x0020,0x0030 pour une ACR-NEMA)
>
> - Des algo + robuste (ex: GetYSpacing, si tu fais scanf(%f\\%f) pour
> recuperer le spacing tu peux avoir des surprises...)
Ok, c'est tres clair maintenant. Merci.
C'est vrai que ca peut etre tres utile et interessant de construire les
choses ainsi.
Mais ce serait pas mieux d'avoir une structure du type 'Strategy pattern' ?
et permettre
à l'utilisateur de configurer son choix de recherche des valeurs ? (enfin si
tout ca est possible)

En résumé, ta class HelperHeader ne contiendrait qu'une interface sur des
stratégies à appliquer.
(en gardant je pense les méthodes GetYSpacing... qui appelerait la stratégie
concernée). On pourrait
meme penser à quelque chose d'encore plus général (mais c'est à réfléchir)

Note sur le Strategy Pattern :
 Définition d'une famille d'algorithmes, chacun encapsulé dans un objet et
possédant la même interface.

  Class Strategy
     virtual AlgrithmInterface() = 0

  Class ConcreteStrategyA : public Strategy
     virtual AlgrithmInterface() {...}

  Class ConcreteStrategyB : public Strategy
     virtual AlgrithmInterface() {...}

  Class ConcreteStrategyC : public Strategy
     virtual AlgrithmInterface() {...}

> >
> > Ensuite, si tu pense concerver des données d'entête dans le
> > vtkGdcmReader grace à cette méthode, as tu parlé avec Eric
> > des problèmes concernant la place mémoire qui pouvait être occupée ?
> > (notamment si 500 fichiers sont chargés). Cela peut conduire a sa
> > saturation.
>
> Merci de soulever le problème ! J'avais aussi l'idée que l'on pouvait
> etre capable de lire :
> - l'entete dicom seulement
> - l'entete dicom *ET* l'image dicom
> - seulement l'image dicom
>
> Ainsi ca simplifierait la vie de vtkGdcmReader, comme tu l'as dis cette
> classe n'a pas besoin de retenir des infos dicom. C'est une classe pour
> faire de la visu ! Elle n'est pas sensée savoir que ce sont des fichiers
> dicom qui sont a l'origine du volume 3D.
En fait, si ! Le but du vtkGdcmReader est de charger une image ou un
volume d'images à partir de fichier DICOM posés sur le disque. Et je n'ai
pas dit que le vtkGdcmReader n'a pas besoin de retenir les informations.
Ca pourrait meme être très utile dans certains cas... au lieu de charger une
fois l'image par vtk (header + data) et une autre fois dans le programme
(header)
pour des traitements sur les informations complémentaires à l'image.

Mais le problème, c'est la pérénité de ces donnéees. Si elles restent toutes
en
mémoire, meme celles dont on a pas besoin, on pourrait rapidement avoir
une saturation de la mémoire, ce qui n'est pas souhaitable.
Et choisir quelles données garder, c'est difficile... comment savoir ce qui
est vraiment utile pour nous de ce qui ne l'est pas ?


> Je vais voir comment partager entre des méthodes qui travaillent sur
> l'entete et des méthodes qui constuisent un volume
Si t'arrive à une meilleure structure, c'est toujours intéressant. surtout
en
séparant header et data (mais en gardant néanmoins un lien non obligatoire)
N'hésite pas a nous en faire part quand t'as de nouvelles idées, pour en
discuter et voir les + et les -.

Benoit