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

[Bill Lorensen]

The user should not have to workaround the problem. The old code
should still work.

On Fri, Dec 11, 2009 at 10:34 AM, kent williams
<norman-k-williams at uiowa.edu> wrote:
>
> 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
>
> _______________________________________________
> 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
>