[Dcmlib] Proposal: questions suite

[Mathieu Malaterre]

> VTK ou ITK ont un seul type de données mise à jour avec le ExecuteData.
> Les données ont besoin d'une intégrité complète sur les données.
> Or dans Dicom, le Document se comporte comme un ensemble de données
> pouvant être considérées séparément. On peut considérer les pixels, sans 
> jamais
> s'occuper de la LUT ou inversement, on avoir une donnée (comme un nom de 
> patient
> super long... ceci est un exemple peu réel certes, mais j'en ai po 
> trouvé de meilleur pour
> l'instant) sans avoir besoin de récupérer pour autant les pixels de 
> l'image.
> 
> Je ne suis donc pas sur que l'approche VTK/ITK convienne complètement pour
> gdcm.
> 
> 
> Et il y a aussi le problème du pipeline... fait-on la meme gestion qu'en 
> VTK/ITK ?
> La aussi je me pose des questions. Il y a des + et des - à le faire. Car 
> pipeline
> implique duplication des données entre entrée et sortie (sinon, faut 
> vraiment faire
> une gestion puissante du bousin lorsqu'on modifie une Entry, les 
> caractéristiques de
> l'image, etc.


Ok t'as raison. Donc la solution des multiples loader semble la bonne.


> Vi, il semblerait bien... mais on remarque néanmoins des bases communes
> qui apparaissent déjà, comment le Document

cool :)

> C'est je crois une partie de ce que j'ai fait... où j'ai pas bien 
> compris ton
> idée...

Pour l'instant les tests/exemples sont ecris d'un point de vue dummy 
user. Alors que ce que je voudrais c'est les specif du vrai parser dicom 
interne. 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:

======================
Reader reader()
reader.SetFileName();

Document doc = reader.GetOutput()

ImageLoader il()
il.SetInput( doc )
print il.GetOutput()

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

======================

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.
Meme chose les appel ImageLoader et OverlayLoader sont tres similaires, 
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
- l'interpreter de donnees

> Moi aussi.
> Aurais tu la possibilité de venir en france pour travailler la dessus si 
> le labo t'offre le voyage ?
> (je tiens à préciser que je n'ai encore rien demandé à la direction, 
> donc il n'y pas de
> certitudes sur le payement du voyage par le labo... mais je veux déjà 
> savoir si pour toi
> ca entrerait dans le cadre de ton travail ou non).

je te reponds en prive.

Mathieu