[Insight-developers] in place filters

[Henning Meyer]

A mean a filter,which can be statically inlined in the accessor
methods (iterators) by the compiler. Like a BinaryNotImageFilter,
which has the effect of applying the ! inside the iterator itself.
This could at least be used for all pixel-wise filters.

I hope I made it clearer...

Henning

2006/7/13, Miller, James V (GE, Research) <millerjv at crd.ge.com>:
> I guess I don't understand what you are asking for.  Perhaps, you
> are referring to streaming the processing.  Many ITK filters support
> streaming.  If you place a StreamingImageFilter near the end of your
> pipeline, then you tell the pipeline to divide the problem up into
> N blocks, and the pipeline will execute N times, each execution
> generating a piece of the final output.
>
> Is this what you are looking for?  In not, perhaps could expand
> on the solution you are looking for.
>
> Jim
>
> -----Original Message-----
> From: Henning Meyer [mailto:tutmann at gmail.com]
> Sent: Thursday, July 13, 2006 10:39 AM
> To: Miller, James V (GE, Research)
> Cc: insight-developers at public.kitware.com
> Subject: Re: [Insight-developers] in place filters
>
>
> 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
> >
>