[Insight-developers] backward compatibility issue with new streaming support
M.Staring at lumc.nl
M.Staring at lumc.nl
Fri Dec 11 11:15:20 EST 2009
We have an abstract image type that does not need to know at compile-time the image type and dimension. We can delay the decision of the specific image type till after the reading. So, the reader itself is non-templated. We are using the ITK IO to get the meta information and the pixel buffer. We do all the ReadImageInformation(), GetComponentType(), and GetNumberOfComponent(), but now we apparantly additionally need to do SetIORegion().
But anyway, the discussion is not how our reading framework is designed, but that there was a change in behaviour. I just wanted to report that.
What is important for us to know is, if we add the following lines to our code:
---------------------------------------
const unsigned nrOfDimensions = m_itkImageIO->GetNumberOfDimensions();
itk::ImageIORegion ioRegion(nrOfDimensions);
for(unsigned int i=0; i < nrOfDimensions; ++i)
ioRegion.SetSize(i, m_itkImageIO->GetDimensions(i));
m_itkImageIO->SetIORegion(ioRegion);
---------------------------------------
if that is the correct use of ITK image IO ?
I don't mind changing our code a little bit, but I want to change it in a correct fashion.
Marius
> -----Original Message-----
> From: insight-developers-bounces at itk.org
> [mailto:insight-developers-bounces at itk.org] On Behalf Of kent williams
> Sent: vrijdag 11 december 2009 16:44
> To: Bill Lorensen
> Cc: ITK
> Subject: Re: [Insight-developers] backward compatibility
> issue with new streaming support
>
> 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
> >>
>
> _______________________________________________
> 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