[Insight-users] providing alternate image store

[Tom Vercauteren]

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
>