[Insight-users] providing alternate image store

[Neal Sidhwaney]

Hi Tom, Mathieu
Thank you for the information & pointers! Very helpful.

Neal

On Thu, Aug 6, 2009 at 1:23 AM, Tom Vercauteren
<tom.vercauteren at gmail.com>wrote:

> Hi Neal,
>
> It is not really what you are asking for but the following IJ
> submission might be a good starting point to implement Mathieu's
> proposal:
> http://hdl.handle.net/1926/1505
>
> Hope this helps,
> Tom
>
> On Thu, Aug 6, 2009 at 10:02, Mathieu
> Malaterre<mathieu.malaterre at gmail.com> wrote:
> > 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
> > _____________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.itk.org/mailman/listinfo/insight-users
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090807/4cadfce1/attachment.htm>