[Insight-developers] in place filters
Luis Ibanez
luis.ibanez at kitware.com
Mon Jul 24 13:54:52 EDT 2006
Hi Henning,
Unfortunately, the fact that ImageAdaptor can now work with
Interpolators doesn't imply that they can also be used with
Neighborhood iterators.
I was wrong on my assumption that the Interpolators were using
Neighborhood iterators internally. They seem to be addressing
the pixels by constructing their indices locally.
They cannot support multiple input images at this point either.
The fundamental reason why these operations are not available
is that the ImageAdaptors make its magic via the PixelAccessor
and the PixelAccessor never gets to know the index of the pixel
it is accessing. That is, the pixel accessor works simply as a
look-up table between the values of the input image and those
of the pretended image.
You may want to experiment modifying the API of the PixelAccessor
by adding the pixel index to its call. In this way the PixelAccesor
cout be able to perform smarter operations, even including neighbor
access.
Please let us know what you find,
Thanks
Luis
----------------------
Henning Meyer wrote:
> 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
>> >
>> >
>>
>>
>>
>
>
More information about the Insight-developers
mailing list