Hi Ivan, Many thanks for info about GDCM. Just downloaded and built it - no problems. Nice to see CMake in action in both ITK and GDCM.
Do you have any ideas when GDCM 2.0 might be out? Another question for the ITK community would be their own plans for moving for to later versions of GDCM. It'd be good to keep in sync otherwise one might end up with multiple versions of GDCM needing to be installed. On the ITK integration front, I expect this should be relatively straight forward to implement - the key is just extract the imagery as an osg::Image, then all the standard OSG texturing would be able to used. My initial dicom loader based ITK has code for doing this already, it's not general purpose enough yet, but at least a step in this direction. Robert. On Thu, Aug 28, 2008 at 11:36 AM, Iván Macía <[EMAIL PROTECTED]> wrote: > Dear Hesicong, Robert, > > I have some experience using ITK. ITK relies now on GDCM library to read > DICOM files. > > http://www.creatis.insa-lyon.fr/Public/Gdcm/ > > GDCM focuses on the part of the DICOM protocol related to the image format > and representation whereas DCMTK covers most of the standard which includes > transmission, services such as query/retrieve, storage etc. In my opinion > GDCM would be simpler and easier to use in this kind of application. > > The itk::ImageFileReader relies on pluggable factories. When the DICOM > format is detected by the reader the itk::GDCMImageIO object is used which > actually uses GDCM code. > > DICOM series (consisting of several DICOM files) are read somehow a bit > differently by generating a series of file names (itk::GDCMSeriesFileNames) > that are then passed to itk::ImageSeriesReader but in the end they also use > GDCMImageIO. > > Note that ITK does not use GDCM 2.x which is a major rework from GDCM 1.x > which is the one used by ITK. > > You may want to have a look at this before deciding which DICOM library to > use. > > It would be really nice to be able to use the ITK pipeline together with an > OSG based volume visualization. > > HTH > > Ivan > > > -----Mensaje original----- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] En nombre de sicong he > Enviado el: jueves, 28 de agosto de 2008 6:22 > Para: OpenSceneGraph Users > Asunto: Re: [osg-users] About the DICOM loader > > Hi, Robert, > Thanks for reply. I'm going on with the loader and if I create one, > I'll contribute it! > > 2008/8/27, Robert Osfield <[EMAIL PROTECTED]>: >> Hi Hesicong, >> >> On Wed, Aug 27, 2008 at 3:57 AM, sicong he <[EMAIL PROTECTED]> wrote: >>> I just get the lastest version from SVN and see the DICOM loader is >>> implemented. A lot of changes has made to osgVolume example, so is there > a >>> schedual developping the volume rendering node for OSG? >> >> I don't development schedule has not been set yet. The work check in >> so far is just preliminary exploratory work. >> >> My main task right now is completing VirtualPlanetBuilder to get to >> its 1.0, once this is done, I'll be returning near fulltime to volume >> rendering and related tasks. >> >>> I've also noticed that DICOM loader require ITK. I use ITK rencently to > do >>> segmentation. It's not easy to compile the huge ITK source code which >>> needs also need some other relative software. We need only the DICOM >>> loader >>> though. >>> And as I know the ITK dicom loader is not very powerful and some DICOM >>> format can't be read by the loader. >> >> I understand the limitations of the ITK dicom loader, the image >> process capabilities of ITK are what will be most valuable. I'm >> learning about ITK and it capabilities and the the ITK dicom loader >> naturally fell out of this work. >> >> It's my plan to offer an easy route between osgVolume and ITK so one >> can put together an image processing pipeline without a great deal of >> work at our end. >> >>> I suggest to use a more powerful, more offical DICOM toolkit---- DCMTK. >>> You >>> can get it from http://dicom.offis.de/dcmtk.php.en. It's cross-platform, >>> focus on DICOM format, easy to compile and very powerful. I use this >>> package >>> to do my DICOM reader front-end of my project. It could be another >>> solution >>> of our OSG DICOM plugin. >> >> I have download and compiled DCMTK, but haven't yet attempted to >> create a plugin for it. It's just another API to learn, so I'm taking >> them on one by one. >> >> My thought was to have a couple of dicom loader options, depending >> upon what dependencies you had installed. CMake allows to check for >> the various dependencies and choose which to compile. >> >> If you already have a dicom loader written feel free to contribute it :-) >> >> Robert. >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
