Hi, Ivan, That's a good suggestion. It's good to see that OSG integerate with ITK. I'm now doing some research to integerate VTK and OSG. Hope integration ITK with OSG will make things easier. Of course, it's no use to only use a DICOM loader in OSG but the other part. I hope OSG will go farther in medical area!
Regards Hesicong 2008/8/28 Iván Macía <[EMAIL PROTECTED]> > Sorry, forgot to send some relevant links > > http://www.itk.org/Doxygen/html/classitk_1_1GDCMImageIO.html > http://www.itk.org/Doxygen/html/classitk_1_1ImageFileReader.html > http://www.itk.org/Doxygen/html/classitk_1_1ImageSeriesReader.html > http://www.itk.org/Doxygen/html/classitk_1_1GDCMSeriesFileNames.html > > > -----Mensaje original----- > De: Iván Macía [mailto:[EMAIL PROTECTED] > Enviado el: jueves, 28 de agosto de 2008 12:37 > Para: 'OpenSceneGraph Users' > Asunto: RE: [osg-users] About the DICOM loader > > 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 > > osg-users@lists.openscenegraph.org > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
