[Insight-developers] in place filters

[Henning Meyer]

Hello Luis,

thank you! Thats what I was looking for.
Is it possible to expand ImageAdapters to enable  change in image
resolution or size?
And maybe even ImageAdapters which have multiple inputs? And why
shouldn't the Accessor have access to the neighborhood pixels?

Henning

2006/7/17, Luis Ibanez <luis.ibanez at kitware.com>:
>
>
> Hi Henning,
>
>
> This is what the Image Adaptors do. They generate their input
> on the fly without having to allocate memory for it.
>
>
> Please read the ITK Software Guide
>
>          http://www.itk.org/ItkSoftwareGuide.pdf
>
>
> In particular Chapter 12: "Image Adaptors", in pdf-page 777-788
>
>
> You will find source code examples in the directory:
>
>
>           Insight/
>              Examples/
>                 DataRepresentation/
>                                 Image/
>                                   ImageAdaptors*.cxx
>
>
>
> Note that the current implementation only works for pixel-wise
> filters.
>
>
>
>      Regards,
>
>
>         Luis
>
>
>
> ====================
> Henning Meyer wrote:
> > But I meant a completely different thing. A filter, which does not
> > overwrite its input, but generates its output on the fly.
> >
> > Henning
> >
> > 2006/7/13, Miller, James V (GE, Research) <millerjv at crd.ge.com>:
> >
> >> Many ITK filters can run in place.  Those that can derive from
> >> InPlaceImageFilter
> >> (which is a subclass of ImageToImageFilter). There are two constraints
> >> for in place
> >> filtering.  First, the input and output image must be the same
> >> dimension (2D, 3D, etc.).
> >> Second, the input and output image must have the same pixel type
> >> (short, double, etc.).
> >>
> >> If these conditions are met, then the InPlace filter will manage the
> >> memory buffers so
> >> that ownership of the pixel container passes from the input image to
> >> the output image
> >> and no additional storage is allocated.  If these conditions are not
> >> met, then the
> >> InPlaceFilter falls back to behaving like an ImageToImageFilter.
> >>
> >> An InPlaceFilter must call the method AllocateOutputs() (on itself) in
> >> its GenerateData()
> >> method instead of calling Allocate() directly on the output image.
> >>
> >> Many filters are already subclasses of InPlaceImageFilter. But there
> >> are probably many
> >> filters in ITK that should be subclasses of InPlaceImageFilter that
> >> are not currently.
> >> If you identify any such filters, please let us know and we will look
> >> into making
> >> those filters run in place.
> >>
> >> /** \class InPlaceImageFilter
> >>  * \brief Base class for filters that take an image as input and
> >> overwrite that image as the output
> >>  *
> >>  * InPlaceImageFilter is the base class for all process objects whose
> >>  * output image data is constructed by overwriting the input image
> >>  * data. In other words, the output bulk data is the same block of
> >>  * memory as the input bulk data.  This filter provides the mechanisms
> >>  * for in place image processing while maintaining general pipeline
> >>  * mechanics. InPlaceImageFilters use less memory than standard
> >>  * ImageToImageFilters because the input buffer is reused as the
> >>  * output buffer.  However, this benefit does not come without a cost.
> >>  * Since the filter overwrites its input, the ownership of the bulk
> >>  * data is transitioned from the input data object to the output data
> >>  * object.  When a data object has multiple consumers with one
> >>  * of the consumers being an in place filter, the in place filter
> >>  * effectively destroys the bulk data for the data object. Upstream
> >>  * filters will then have to re-execute to regenerate the data object's
> >>  * bulk data for the remaining consumers.
> >>  *
> >>  * Since an InPlaceImageFilter reuses the input bulk data memory for the
> >>  * output bulk data memory, the input image type must match the output
> >>  * image type.  If the input and output image types are not identical,
> >>  * the filter reverts to a traditional ImageToImageFilter behaviour
> >>  * where an output image is allocated.  In place operation can also be
> >>  * controlled (when the input and output image type match) via the
> >>  * methods InPlaceOn() and InPlaceOff().
> >>  *
> >>  * Subclasses of InPlaceImageFilter must take extra care in how they
> >>  * manage memory using (and perhaps overriding) the implementations of
> >>  * ReleaseInputs() and AllocateOutputs() provided here.
> >>  *
> >>  * \ingroup ImageFilters
> >>  */
> >>
> >>
> >> -----Original Message-----
> >> From: insight-developers-bounces+millerjv=crd.ge.com at itk.org
> >> [mailto:insight-developers-bounces+millerjv=crd.ge.com at itk.org]On Behalf
> >> Of Henning Meyer
> >> Sent: Thursday, July 13, 2006 3:29 AM
> >> To: insight-developers at public.kitware.com
> >> Subject: [Insight-developers] in place filters
> >>
> >>
> >> Hello,
> >>
> >> when working with large volumes it's quite annoying that itk filters
> >> reserve an extra memory block to store the filtered image.
> >> Would'nt it be nice to have filters which work in place? This idea
> >> could be combined with the IteratorTraits idea and sparse volumes very
> >> nicely. And if used correctly filter could still be chained. However,
> >> I think one would loose the flexibility to change filters at runtime -
> >> but honestly - who is doing this anyway?
> >>
> >> Henning
> >> _______________________________________________
> >> Insight-developers mailing list
> >> Insight-developers at itk.org
> >> http://www.itk.org/mailman/listinfo/insight-developers
> >>
> > _______________________________________________
> > Insight-developers mailing list
> > Insight-developers at itk.org
> > http://www.itk.org/mailman/listinfo/insight-developers
> >
> >
>
>
>