[Insight-developers] backward compatibility issue with new streaming support

kent williams norman-k-williams at uiowa.edu
Fri Dec 11 10:34:29 EST 2009


Honestly the easiest way to do this is to go ahead and use
itk::ImageFileReader, and then call GetBufferPointer on the returned image
to get a handle on the voxel data.

If you're worried about copying buffers from the itk::Image to your image
objects, as long as you keep a smart pointer to the image around, you can
use the returned pointer from GetBufferPointer to access voxels.

If your image type supports multiple pixel types at runtime -- which isn't
unusual -- this complicates matters. There you have to instantiate an
instance fo the correct itk::ImageIO class, set the filename, call
itk::ImageIOBase::ReadImageInformation(), call
itk::ImageIOBase::GetComponentType(), and
itk::ImageIOBase::GetNumberOfComponents(),  and instantate a reader with the
proper ImageType to read the image.

Of course, if your application knows ahead of time that only one image type
is going to be used internally, then it gets much simpler -- you just use an
itk::Image type with a single instance of the itk::ImageFileReader.  Then
ITK will do the pixel conversion from whatever pixel type the images read
have on disk.

Or you could simplify your life immensely and re-archittect your lkebImage
to derive from itk::Image, and then re-implement the lkebImage methods in
terms of the corresponding itk::Image methods.  That might seem like an
annoyance, but really, how many different ways are there to represent an
image, or the information about it?

I have worked with an application with it's own Image class, so I've gone
through all of the issues above.  The fact is that using the ITK I/O
Mechanism gives you everything you need without requiring very much
overhead.  

If you're using the itk::ImageIO classes directly you're re-inventing the
wheel, and putting yourself in the position of recapitulating many
man-months of effort that have gone into designing, building and testing the
ITK I/O system.

If you have any further questions on how to go about using ITK ImageIO, feel
free to ask, as I've put a few man months into it myself ;-)

On 12/11/09 9:00 AM, "M.Staring at lumc.nl" <M.Staring at lumc.nl> wrote:

> Dear developers,
> 
> In our institute (LKEB) we sometimes use the ITK image IO classes
> without using the itk::ImageFileReader. (This way we can e.g. directly
> read in the data buffer into our own image type: lkebImage.)
> 
> We recently updated the underlying ITK to a more recent version, and
> found out that it did not work anymore. The reason it does not work are
> the changes that were made to support streaming. A new member m_IORegion
> was added to the class ImageIOBase; it's constructor initializes that
> member to a 2D region of size [0 0]. The framework now expects that this
> m_IORegion is set externally, which in the ITK is done in the
> ImageFileReader (line 389 of the txx). However, we do not use the
> ImageFileReader and therefore our code breaks.
> 
> To fix this issue I would expect that the m_IORegion is by default set
> to the largest possible region (or the requested region) and not to size
> 0. I'm not sure if it is the best place to fix this, but this could be
> fixed by adapting the Read() or ReadImageInformation()-functions of all
> ImageIO's that support streaming. For example MetaImageIO::Read() could
> check if m_IORegion was manually set, and if not set it to the requested
> region. Something like:
> 
> if ( !m_IORegionManuallySet ) // or: if ( m_IORegion.GetSize() == 0 )
> {
>   m_IORegion = m_RequestedRegion; // or: m_IORegion =
> m_LargestPossibleRegion;
> }
> 
> and then proceed ...
> 
> What do you think ?
> 
> Regards,
> 
> Marius
> 
> 
> Marius Staring, PhD
> Division of Image Processing (LKEB)
> Department of Radiology
> Leiden University Medical Center
> PO Box 9600, 2300 RC Leiden, The Netherlands
> phone: +31 (0)71 526 1106, fax: +31 (0)71 526 6801
> m.staring at lumc.nl
>  
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.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-developers



More information about the Insight-developers mailing list