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 >> >> 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 > > > _______________________________________________ > 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
