[Insight-developers] in place filters
Miller, James V (GE, Research)
millerjv at crd.ge.com
Mon Jul 24 12:34:12 EDT 2006
Henning,
Have you looked at ImageFunctions? They can be implemented with neighborhoods to
evaluate a function of over a neighborhood of a pixel. You could walk an iterator
around an image and evaluate the image function at each pixel. Code/Common/itkMedianImageFunction.txx
is an example of an image function that evaluates over a neighborhood.
Using ImageFunctions is not as transparent as ImageAdaptors. However, you can
evaluate the ImageFunction as subpixel locations.
Jim
-----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: Monday, July 24, 2006 2:22 AM
To: Luis Ibanez
Cc: insight-developers at public.kitware.com
Subject: Re: [Insight-developers] in place filters
Hello Luis,
if Bug #3252 has been fixed and ImageAdaptor are now working with
LinearInterpolators does that mean that Neighborhood iterators work
with ImageAdaptors?
What about ImageAdaptors with multiple inputs? And still...when an
iterator can Access neighborhoods why can't it access an image as an
image of a different resolution (e.g. a times2Accessor, with just
expands the current image in each dimension by a factor of two). On
the other hand I would love to have an ImageBlockAccessor, which has
an OutputImageRegion and an InputImage which might not correspond to
the OutputImageRegion - missing pixels are replaced be ReplaceValue
and surplus pixels are hidden.
Might that be possible?
Henning
2006/7/18, Luis Ibanez <luis.ibanez at kitware.com>:
>
> Hi Henning,
>
> We could probably create ImageAdaptors capable of simulating
> *smaller* images, but never larger images.
>
> Image adaptors are implemented using a Generic Programming
> mechanism called "Accessors". This is tightly integrated with
> the Image Iterators and for performance conflicts it is not
> supported in neighborhood iterators.
>
> We found difficult to implement the use of neighborhood
> accessors in such a way that filters that do not use
> Image Adaptors do not have to pay any performace penalty
> for it.
>
> That being said, we will be happy to reconsider this implementation
> if you find a clever mechanism for extending the ImageAccessor
> for neighborhood operations.
>
> If you want to take a look at the relavant pieces of code,
> a good place to start is the itkImage class itself, in line 115,
> 268-269 and 272-273.
>
> Then you may want to look at the base classes of the ImageIterators,
> such as the itkImageRegionConstIterator.h, and you will find where
> the PixelAccessor is used.
>
>
>
>
> Regards,
>
>
>
> Luis
>
>
>
> ---------------------
> Henning Meyer wrote:
> > 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
> >> >
> >> >
> >>
> >>
> >>
> > _______________________________________________
> > 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
More information about the Insight-developers
mailing list