[Insight-developers] in place filters

[Henning Meyer]

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
>