[Dcmlib] Proposal: questions suite : Overlays

[Jean-Pierre Roux]

Mathieu Malaterre wrote:

[...]

>  Par exemple on a l'air de converger vers l'idee de parser multiple. 
> On a donc le cas de l'utilisateur qui veut a la fois l'image et 
> l'overlay:


==> Vu que personne n'a JAMAIS vu une image avec des overlays, je sens 
qu'on va en parler avec competence...

>
> ======================
> Reader reader()
> reader.SetFileName();
> Document doc = reader.GetOutput()
>
==> Ca, c'est l'ancien constructeur de gdcm::Document, n'est ce pas?
==> Il y a aura la possibilite de dire, juste avant, si on veut ou non 
charger les Shadow groups et les Sequences ?

> ImageLoader il()
> il.SetInput( doc )
> print il.GetOutput()
>
==> Il faudrait egalement prevoir la lecture  :
==> 'frame by frame', en rendant la main a l'utilisateur apres chaque frame
==> 'from frame to frame' (on ne lit que les 'Frames Of Interest')
==> sinon, on ne s'en sortira pas plus que maintenant lorsqu'on aura a 
faire a des images de 2000 frames, 1000x1000
(elles existent deja)

 ==>On devra pouvoir dire si on charge les 'Palette Color' en 'niveau de 
gris' + Palette, ou si on la tranforme directement en RGB?
==> ou bien est-ce une operation qu'on fait après ?

> OverlayLoader ol()
> ol.SetInput( doc )
> print ol.GetOutput()

==> Ca  ramenera lequel d'overlay?
==>  peut y en avoir autant qu'on veut, sur une image :
(ils sont decrits, soit dans les groupes 6000 et suivants, et la , par 
nature, il ne peut y en avoir plus de 16, soit dans la Sequence, et la , 
on en met autant qu'on veut)

>
> ======================
>
> Document ne doit contenir que le mimimum d'information, ie il n'a pas 
> lu/pas charge les donnes binaires no de l'image ni de l'overlay. En 
> revanche il a (??) un offset pour chacun d'eux.

==> Un offset pour chacun des Overlays, oui.

> Meme chose les appel ImageLoader et OverlayLoader sont tres similaires, 

==> Pour lire un Overlay (ou une Curve), c'est fseek + fread.
==> Grace au diable, ils n'ont pas prévu de les compresser ....

> il faut donc eviter de dupliquer du code. C'est ces fonctions que 
> j'aimerais specifier. A ton avis est-ce que le fait de faire une bonne 
> relation d'heritage permettra justement de partager le code commun de 
> facon trivial...
>
>
>> Par contre, il n'y pas que des opérations au niveau fichier. Il y a 
>> aussi des
>> opérations au niveau Entry et données interprétées (comment les 
>> pixels d'une image)
>
>
> Ben finalement ca resume bien mon probleme. Je vois deux choses dans 
> gdcm:
> - le parser pur

==> c'est gdcm::Document moins les piteries qu'on fait avec les 'int' 
pour les transformer en 'gdcm::string' ?

> - l'interpreteur de donnees

==> c'est une partie de gdcm::FileHelper, + integration de choses qui se 
trouvent dans gdcm/Example ?

JPRx

>
>