[Insight-developers] in place filters

[Miller, James V (GE, Research)]

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