[Insight-developers] Image Adaptors

[Luis Ibanez]

Hi,




Joshua Cates wrote:
> Hello,
>
> 1. In order for an algorithm to support the ImageAdaptor class, is calling
> Get/Set on the ImageIterator required for pixel-level access?

Yes, that's the current way to support ImageAdaptors.


> Is there a way to overload ImageIterator::operator* instead so that the
> calls to
> Get/Set are transparent?  This is a critical issue because it dictates the
> standard method for pixel access in all image filtering algorithms
> everywhere in the toolkit.

It could probably be done, but that will require some get arounds to
make it look as  *iterator.  The problem is that adaptors just simulate
 the expected pixel type, and they do so by using a temp variable.
At this level it is important to know if the access if for reading or
writing (Get/Set)

The call "*iterator " does not allows to know if the pixels is being
accessed for reading or writing.

T a = *iterator;
*iterator = a;

and both operations are quite different because the DataAccessor
that really performs the conversion have two methods, one for
Set() and another for Get().

On way to get the *iterator appearance could be to make *iterator return
a type X, on which operator=() is overloaded.  Somehow similar to what
Brad
did for list access on the Array class.


> 2. How widespread is the support for and use of image adaptors in the
> toolkit?

It is not everywhere, in fact it depends on which type of iterator is
used
on a particular filter.


> Currently, it looks like only itkImageIteratorWithIndex and its
> subclasses support it.

That's correct, only the filters that use iterators derived from
ImageIteratorWithIndex support ImageAdaptors. and that's also the
reason for the difference in API between ImageIteratorWithIndex
(templated over the image type) and ImageIterator (templated over pixel
type and dimension).




Luis