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
