[Insight-users] providing alternate image store

Mathieu Malaterre mathieu.malaterre at gmail.com
Thu Aug 6 04:02:55 EDT 2009


Hi Neal,

  See my comments interlaced.

On Thu, Aug 6, 2009 at 4:47 AM, Neal Sidhwaney<nealsid at gmail.com> wrote:
> Hi,
> I'd like to use ITK to process DICOM images.    I've got the toolkit
> building and played around with the DICOM samples to analyze some image
> series and it's very well documented and I had little to no issues getting
> up and running.

You have no idea how pleasant this sound to me :)

> However, my eventual scenarios involve DICOM images are not stored on disk,
> but in a custom data store.  For conversational purposes, assume it's a SQL
> Database and they are stored as BLOBS(although it's really not, but the
> constraints of not being able to use streams or an OS I/O api is still
> there).  I'd like to avoid having to do unnecessary reads & writes to the
> filesystem in order to pass ifstreams or filenames to the ITK API.
> I thought I could accomplish this using a subclass of itkGDCMImageIOthat
> leveraged the same helper classes that itkGDCMImageIO does.  However, the
> itkGDCMImageIO class calls into the gdcm library for processing DICOM
> images.  At least in this case, it does not pass pointers, but filenames
> around.  I am not sure if subclassing the GDCM library is the way to go
> here.
> Can anyone recommend some pointers on what the best way to accomplish this
> is? If it's been discussed recently, sorry - I dug around the archives and
> the code quite a bit before coming to the mailing list.

I think I'll repeat my previous post, but ITK mechanism is split into
-basically- two classes: itk::ImageFileReader and the actual
itk::*ImageIO, in our case this is itk::GDCMImageIO.
So what you actually want to do is:

1. Write a itk::ImageStreamReader, which takes as input an already
opened *stream (a subclass of std::istream in this case), and all it
does simply pass this open istream to gdcm.
2. Make sure you use GDCM 2.x, since it provide a full *stream
interface, and not only a pseudo FILE* interface as in the old GDCM
1.x (currently shipped as default DICOM lib).
3. When you configure ITK, use 'SYSTEM_GDCM' and point to your
installed GDCM 2.x installation tree (it will search for a
GDCMConfig.cmake file).

More info:
GDCM 2.x:
* http://gdcm.sourceforge.net/

Latest release:
* http://sourceforge.net/apps/mediawiki/gdcm/index.php?title=GDCM_Release_2.0#GDCM_2.0.12_.282008.2F06.2F12.29

gdcm::Reader::SetStream:
* http://gdcm.sourceforge.net/html/classgdcm_1_1Reader.html#2fdbf80e6dedc1f3a127a68d6ab11341


As a crude hack, simply instanciate a gdcm::ImageReader, pass in the
subclass of istream via its SetStream() interface, and check that you
can at least read from your memory stream.

For question on gdcm 2.x, I'd suggest you use the GDCM 2.x ML:
* http://sourceforge.net/apps/mediawiki/gdcm/index.php?title=General_questions#Where_are_the_GDCM_mailing_lists_.3F

Good luck,
-- 
Mathieu
http://mathieumalaterre.com


More information about the Insight-users mailing list