Hi Ivan, Thanks for the update.
On the OSG side I've written a DCMTK based OSG dicom loader, it's still not finished as I keep encountering dicom files that break the assumptions made in the plugin about the nature of dicom files - it is a bit of long haul trying to get my head around all the different forms and how to fit them into a standard osg::Image. A port to using GDCM 2.x probably won't be too difficult. Robert. On Wed, Oct 1, 2008 at 5:02 PM, Iván Macía <[EMAIL PROTECTED]> wrote: > Hi Robert, > > To update the info on the topic, it seems that ITK is starting to support > GDCM 2.x. It is in the ITK CVS at a very preliminary stage yet (they say not > to use it yet but for experimentation) but has not been merged yet as it > does not compile with VS6. They are even thinking on dropping support for > VS6 and VS7.0 compilers. > > ITK must be configured with ITK_USE_SYSTEM_GDCM -> ON and GDCM_DIR to > whatever path of the GDCM 2.x. > > Best regards > > Ivan > > -----Mensaje original----- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] En nombre de Robert > Osfield > Enviado el: jueves, 28 de agosto de 2008 17:46 > Para: OpenSceneGraph Users > Asunto: Re: [osg-users] About the DICOM loader > > Thanks for extra links and info Ivan. I've download 2.0.8 and compile > and check it out. > > On Thu, Aug 28, 2008 at 4:27 PM, Ivan Macia <[EMAIL PROTECTED]> wrote: >> Hi Robert, >> >> There are two major versions of GDCM, 1.x (current version 1.3.1 or so) > and >> 2.x (currently 2.0.8). They are not compatible. GDCM 2.x seems to be much >> faster parsing and also covers some parts of the protocol outside the > scope >> of the image representation. Both seem to be currently developed in >> parallel. I ignore if there are future plans to abandon the 1.x branch. >> >> This is GDCM 1.x >> http://www.creatis.insa-lyon.fr/Public/Gdcm/html.user/index.html >> >> More info on GDCM 2.0 here >> http://gdcm.sourceforge.net/wiki/index.php/GDCM_Release_2.0 >> http://gdcm.sourceforge.net/2.0/html/classes.html >> >> The notes on GDCM homepage say that ITK currently uses GDCM 1.2.x. Also > they >> suggest to use GDCM 2.x for new developments >> http://www.creatis.insa-lyon.fr/Public/Gdcm/ >> >> I ignore the plans of ITK development team about this but probably the > best >> person to contact is Mathieu Malaterre as he developed the ITK GDCM > classes. >> >> On the other hand, nothing prevents to make the DICOM plugin for OSG using >> GDCM 2.x even if ITK is using GDCM 1.x. If OSG was to connect with an ITK >> pipeline, then users will use ITK GDCM readers at the beginning of the ITK >> pipeline. Otherwise, they could use an hypothetical OSG GDCM 2-based DICOM >> plugin to read for example a volume and render it. Just an idea, but I > think >> more info about this is necessary. >> >> Best regards >> >> Ivan >> >> >> >> 2008/8/28 Robert Osfield <[EMAIL PROTECTED]> >>> >>> 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 >> >> >> _______________________________________________ >> 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
