[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 10:33 AM
Subject: Re: [Dcmlib] gdcmHeaderHelper


> Benoit Regrain wrote:
> > 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() {...}
> >
>
> Comme je ne connais pas cette approche je vois pas bien la
> différence/avantage par rapport à un simple héritage. Est-ce que tu peux
> détailler, STP ?
(Il semble que tu puisse facilement trouver de la doc sur le net pour ce
design pattern, doc + ou - explicite)

Inconvénients : plein de classes séparées. Plein de méthodes en + pour la
configuration.
Avantages : Lorsque 2 utilisateurs créent des algorithmes sur des portions
différentes de requetes
  (par ex : GetSpacing pour l'un et le GetOrigin pour l'autre) :
  ils vont chacun dériver ta classe et ajouter leur alogorithme. Mais le
jour où l'un voudra utiliser
  l'algorithme de l'autre, il faudra qu'il copie le code dans sa classe.
  Alors qu'avec ce design pattern, il lui suffira d'ajouter la fichier de la
classe créée par l'autre dans
  son projet.


> > 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.
>
> Mon approche c'est plutot d'utiliser gdcmSerieHeaderHelper récuperer les
> infos que l'on veux pour des programmes du style DaVaW / Maracas. Puis
> *tjrs via cette classe* renvoyer un pointeur sur l'image.
>
> Il ne faut pas oublier que les données sur le disque:
> - peuvent etre du jpeg compressée
> - peuvent etre des plans RGB, plutot que des pixels RGB
>
> dans les deux cas il y a une difference entre les données physiques et
> les données utilisables. Un memcpy ne marche plus.

Mais ca, c'est gdcm qui s'en depatouille quand il charge l'image en memoire
normalement... à moins que je me trompe. J'ai pas du tout regarder le code
à ce sujet.

>
> > 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 ?
>
> Pour moi DaVaW et Maracas utilise la meme strategie: d'abord lecture de
> l'entete *puis* lecture des données. A partir du moment on l'on a créé
> le volume 3D, les données d'entete dicom n'ont plus vraiment leur utilité.
>
> *Sauf* quelques unes: fixer par le developpeur de l'application. Par ex
> dans Marcas, j'ai besoin de me souvenir si l'image que j'ai lu était une
> acquisition sagitale, et quelle type de modalité c'était. Mais ce sont
> plus des données propres à Marcas qu'à une classe de manipulation de
dicom.
Effectivement

>
> Je verais donc plutot:
>
> gdcmSerieHeaderHelper *entree
> ...
> file://on affiche les infos d'entete
>
> vtkImageImport *vtk;
> vtk->SetInput( entree->GetImage3D() ); file://seulement les données
> ...
> delete entree; file://on n'a plus besoin de l'entete
C'est une possibilité qui pourrait être ajoutée a vtkGdcmReader ou une
dérivée.
Je pense que ce serait mieux de conserver l'idée d'un vtkGdcmReader qui sait
manipuler les informations du gdcmFile pour en créer un volume VTK.
Mais l'idée de lui donner en entrée un gdcmFile (ou gdcmHeader) est
intéressante...

>
> > 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 -.
>
> Je ne vois toujours pas à quoi sert ce lien ...
> Dans le cas ou le volume 3D a été construit a partir de valeur par
> défaut renvoyé par des heuristiques, je ne vois pas pourquoi il y aurait
> un lien entre données et entete.
> De plus, le volume 3D est une interprétation des données lues (par ex
> c'est la decompression d'un fichier jpeg). Ca n'a plus vraiment de
> rapport avec l'entete dicom.
D'une part, les 2 (header & body (ou data)) vont de pair. L'un n'a aucun
sens
sans l'autre. Soit l'un a un lien vers l'autre, soit un object regroupe les
2.

Mais c'est vrai qu'une fois que tu as ton volume 3D tiré à la fois du header
et du
body, ces derniers n'ont plus d'intérêt. Mais volume3D et body ne sont pas
la meme chose.
Ton volume3D (comme le nom l'indique) possède des informations comme sa
taille, son spacing...
qui ne sont pas dans le body. Je me trompe peut etre, mais je pense que tu
mélange les 2.

Benoit