[Dcmlib] ITK + GDCM
Jean-Pierre ROUX
jean-pierre.roux at creatis.insa-lyon.fr
Thu Apr 29 00:31:31 CEST 2004
>Hop,
>
> Ca y est GDCM est dans ITK(*), donc j'espere que vous aurez
>une plus grande audience. Si vous avez des problemes pour utilisez
>itkGDCM faites moi signe.
>
> Pour l'instant il n'y que la lecture, j'ai besoin de parler
>avec JP pour le probleme de l'ecriture. D'apres les tests dans gdcm
>il m'apparait qu'il faut un gdcmFile initial pour pouvoir ecrire une
>image dicom. J'aimerais n'avoir besoin que d'un gdcmHeader ? JP
>est-ce possible ?
Les noms gdcmFile et gdcmHeader ne sont probablement pas tres clairs,
mais on n'avait rien trouvé de mieux.
Cette décomposition vient de ce que parfois les utilisateurs veulent
seulement connaitre le contenu de la partie 'entete' du fichier pour,
par exemple, la ranger dans une base de données (cf Theralys), ou
pour savoir si le fichier courant est un File Of Interest pour leur
application.
Les méthodes qui traitent les pixels (lecture des pixels, ecriture du
fichier) sont dans la classe gdcmFile.
Je ne maitrise pas suffisament la philosophie des Langages a Objets
pour donner mon avis sur la pertinence de ce découpage.
(Est-ce pour éviter qu'un utilisateur qui n'est pas interessé par les
methodes qui traitent les pixels n'ai accès à ces méthodes?
Il lui suffirait de ne pas les utiliser, et on n'a plus qu'une seule classe !)
Bon.
Faut voir avec les spécialistes (Eric, Benoit, Emmanuel).
En revanche :
gdcmHeader vs gdcmHeaderHelper ?
dans la classe gdcmHeaderHelper, il y a les accesseurs 'à valeur
ajoutée', qui n'ont rien à faire dans le gdcmHeader, c'est ça?
Il reste qq accesseurs présents dans les deux classes.
A-t-on (ai-je) oublié de les virer lorsqu'on (nous deux) a splitté la
classe gdcmHeader ?
D'autre part les accesseurs GetXDim, GetYDim etc, sont dans gdcmHeader.
(pas bcp de valeur ajoutée, mais si on décide de traiter *également*
les images PAPYRUS 3.0 -DICOM Like, avec qq particularités-, il y en
aura, de la valeur ajoutée)
Est-il judicieux de passer ces accesseurs -et qq autres- dans
gdcmHeaderHelper ?
Si on fait ça, la classe gdcmHeader ne sera pratiquement utilisée
*que* par les développeurs, et la classe gdcmHeaderHelper par les
utilisateurs.
Je ne vois pas d'objection philosophique à ça, mais vu que je ne
maitrise ...( etc, voir plus haut), je préfère poser la question.
JPRx
>
> Sinon dans les prochains changements j'aimerais enlever les
>itkGDCM::GetRescaleSlope + RescaleIntercept, et faire le rescale en
>interne. Ca releve de itkGDCM et non de gdcm pour ce travail.
>
>@+
>Mathieu
>Ps: dans les details, j'ai choisit GDCM plutot que gdcm, mais je
>peux changer le nom s'il faut. s'il manque des references je les
>ajouterais volontier pour l'instant il n'y a que la page de GDCM:
>
> http://www.creatis.insa-lyon.fr/Public/Gdcm/
>
>dans le fichier header
>
>(*)
>$ cvs ci /tmp/Insight
>Checking in CMakeLists.txt;
>/cvsroot/Insight/Insight/CMakeLists.txt,v <-- CMakeLists.txt
>new revision: 1.172; previous revision: 1.171
>done
>RCS file: /cvsroot/Insight/Insight/CMake/FindGDCM.cmake,v
>done
>Checking in CMake/FindGDCM.cmake;
>/cvsroot/Insight/Insight/CMake/FindGDCM.cmake,v <-- FindGDCM.cmake
>initial revision: 1.1
>done
>Checking in Code/IO/CMakeLists.txt;
>/cvsroot/Insight/Insight/Code/IO/CMakeLists.txt,v <-- CMakeLists.txt
>new revision: 1.48; previous revision: 1.47
>done
>RCS file: /cvsroot/Insight/Insight/Code/IO/itkGDCMImageIO.cxx,v
>done
>Checking in Code/IO/itkGDCMImageIO.cxx;
>/cvsroot/Insight/Insight/Code/IO/itkGDCMImageIO.cxx,v <-- itkGDCMImageIO.cxx
>initial revision: 1.1
>done
>RCS file: /cvsroot/Insight/Insight/Code/IO/itkGDCMImageIO.h,v
>done
>Checking in Code/IO/itkGDCMImageIO.h;
>/cvsroot/Insight/Insight/Code/IO/itkGDCMImageIO.h,v <-- itkGDCMImageIO.h
>initial revision: 1.1
>done
>
>
>_______________________________________________
>Dcmlib mailing list
>Dcmlib at creatis.insa-lyon.fr
>http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
Jean-Pierre ROUX
UMR CNRS 5515-CREATIS
Laboratoire de Radiologie Experimentale
Hopital Cardiologique
28 Avenue du Doyen LEPINE
B.P. Lyon-Montchat
69394 Lyon Cedex 03
Tel : (+33) 04 72 35 74 12
Fax : (+33) 04 72 68 49 16
URL : http://www.creatis.univ-lyon1.fr
e-mail : jpr at univ-lyon1.fr
More information about the Dcmlib
mailing list