[Dcmlib] gdcmHeaderHelper

[Mathieu Malaterre]

Benoit Regrain wrote:
> 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() {...}
> 

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 ?


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

Je verais donc plutot:

gdcmSerieHeaderHelper *entree
...
//on affiche les infos d'entete

vtkImageImport *vtk;
vtk->SetInput( entree->GetImage3D() ); //seulement les données
...
delete entree; //on n'a plus besoin de l'entete

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

my 2cents d'euros
mathieu
> 
> Benoit
>