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

[kent williams]

Yes the existing code should work. Since it's an exposed ITK interface, it
should maintain backwards compatibility. There's no controversy about
backwards compatibility being a Very Good Thing, and worth the occasional
pain it incurs.

My response is a suggestion of an easier way to leverage ITK's I/O
infrastructure, based on my own experience with it.

At Iowa, we started using ITK for I/O in a way very similar to the one
Marius describes.  When we started using ITK I/O in the way it was designed
to be used, it allowed use to retire thousands of lines of hard-to-maintain
code.  I'm not telling him to do the same thing, or telling him not to
report backwards compatibility bugs. I'm just pointing out the advantages of
going a different direction.


On 12/11/09 9:37 AM, "Bill Lorensen" <bill.lorensen at gmail.com> wrote:

> 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
>>