[osg-users] About the DICOM loader
sicong he
Robert Osfield
On Wed, Aug 27, 2008 at 3:57 AM, sicong he <hesico...@gmail.com> 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-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
sicong he
Thanks for reply. I'm going on with the loader and if I create one,
I'll contribute it!
2008/8/27, Robert Osfield <robert....@gmail.com>:
Iván Macía
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: osg-user...@lists.openscenegraph.org
[mailto:osg-user...@lists.openscenegraph.org] 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
Iván Macía
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:ima...@vicomtech.org]
Enviado el: jueves, 28 de agosto de 2008 12:37
Para: 'OpenSceneGraph Users'
Asunto: RE: [osg-users] About the DICOM loader
Dear Hesicong, Robert,
http://www.creatis.insa-lyon.fr/Public/Gdcm/
HTH
Ivan
Hi, Robert,
sicong he
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
Robert Osfield
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.
Ivan Macia
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
Robert Osfield
and check it out.
Iván Macía
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: osg-user...@lists.openscenegraph.org
[mailto:osg-user...@lists.openscenegraph.org] En nombre de Robert
Osfield
Enviado el: jueves, 28 de agosto de 2008 17:46
Robert Osfield
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.