[Insight-developers] NeighborhoodFunctorImageFilter?

[Miller, James V (Research)]

Brad, 

This was the original intention of the NeighborhoodOperatorImageFilter.
(Its hard to tell from the CVS logs but the NeighborhoodOperatorImageFilter
may predate the UnaryFunctorImageFilter by a few months. But some of these 
filters may have undergone name changes.) The basic idea
of the NeighborhoodOperatorImageFilter was that one would instantiate the 
filter with the type of  operator to apply to the image and it would apply 
that operator to each pixel.

We quickly found that some of the filters that we wanted to implement, 
like the GradientMagnitudeImageFilter, didn't quite fit this mold. In 
the GradientMagnitudeImageFilter, we needed to apply N operators at
each pixel and composite the result into a final pixel value. I guess we
would have written a new NeighborhoodOperator that performed this
calculation
but it just seemed simplier (less algorithm code) to have a separate filter.

Though admittedly, we have duplication of pipeline code (which is the
section of code with the highest population of errors) and duplication of
the
"outer loop".

I suppose a NeighborhoodFunctorImageFilter could be added.  I imagine that
most of the NeighborhoodFunctors would end up calling a NeighborhoodOperator
in the end.

We could also have *ImageFilters that apply ImageFunctions over an image
(though
that may not be very efficient).

Jim



-----Orinal Message-----
From: Brad King [mailto:brad.king at kitware.com]
Sent: Friday, April 09, 2004 2:46 PM
To: Insight Developers
Subject: [Insight-developers] NeighborhoodFunctorImageFilter?


Hello,

While reading through the implementation of several filters like 
GradientMagnitudeImageFilter and NeighborhoodOperatorImageFilter, I 
noticed that the basic design of such filters follows a pattern.  They 
all have a ThreadedGenerateData that uses a face calculator and then 
uses neighborhood iterators to iterate over the faces and perform some 
calculation.

We should consider creating a general superclass template for all of 
these filters called something like NeighborhoodFunctorImageFilter.  It 
would have a signature similar to UnaryFunctorImageFilter:

template <class TInputImage, class TOutputImage, class TFunction>
class NeighborhoodFunctorImageFilter;

This one tempalte would contain logic similar to the 
NeighborhoodOperatorImageFilter, but instead of simply applying an 
operator to each neighborhood, it would invoke the functor.  Then all 
these filters could be implemented with simple subclasses that create 
the appropriate functor and instantiate this superclass template.

Comments?
-Brad

_______________________________________________
Insight-developers mailing list
Insight-developers at itk.org
http://www.itk.org/mailman/listinfo/insight-developers