[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