[Dcmlib] Proposal: questions suite

[Benoit Regrain]

----- Original Message ----- 
From: "Mathieu Malaterre" <mathieu.malaterre at kitware.com>
To: "Mailing list gdcm" <dcmlib at creatis.insa-lyon.fr>
Sent: Monday, May 16, 2005 7:13 PM
Subject: [Dcmlib] Proposal: questions suite


> Salut,
>
> Je continue de me creuser la tete pour faire une approche propre dans
> gdcm 2. Et voila mes resultats:
>
> Pour ceux non familier avec le pipeline VTK/ITK on fait deux types de
> difference:
> 1. Information, ou light objet. Tout ce qui decris l'objet manipuler
> 2. Data, ou heavy data. La valeur de l'objet. Generalement la plus
> grosse partie du traitement (memoire).
>
> Apres reflexion, on peut prendre cette approche pour DICOM. Si on
> considere que l'Information c'est l'ensemble des Entry sous forme de
> chaine de caractere (Spacing, Hopital name, ...).
>
> Et les Data sont les sorties images: 7fe0, overlay, data binaire de
> taille > 4096. On doit toujours etre capable de charge l'information
> independamment des Data. Et l'information doit etre complete pour
> pouvoir interpreter correctement les Data.
>
>
> - Dans le cas d'un DICOMDIR seul. La sortie est de type information
> seulement. Pas d'image. Pour etre exact la sortie est de type MULTI
> information (plusieurs documents).
>
> - Dans le cas d'une image DICOM. La sortie est de type information, et
> image. Ou de meme: MULTI images.
>
> - Dans le cas de SerieReader. La sortie est de type: MULTI information
> et MULTI image... la ou ca se complique c'est que l'on voudrait qu'une
> seule image...

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.



> ----------------------------
>
> Comme je n'arrive pas a synthetiser tout ca. De meme je m'appercois que
> la tache est de + en + complexe. J'aimerais revoir un peu notre approche
> et diviser le travail. Pour moi finalement on veut faire pas mal de
> tache avancees du point de vue user mais on a des besoins/approches
> differentes.
> Neanmoins on devrait pouvoir s'entendre sur une chose: la couche
> interne. Dans tous les cas meme si on a des vues differentes sur les
> types de reader on doit pouvoir l'implementer facilement avec une couche
> interne robuste qui s'y prete facilement.
Vi, il semblerait bien... mais on remarque néanmoins des bases communes
qui apparaissent déjà, comment le Document


> Je propose donc d'essayer de decrire toutes les operations niveau
> fichiers DICOM dont' on aurait besoin par exemple pour ecrire
> rapidement, par exemple, la classe : ImageReader, SerieReader...
C'est je crois une partie de ce que j'ai fait... où j'ai pas bien compris 
ton
idée...
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)


> J'espere qu'on puisse s'entendre la dessus.
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).

Benoit