[Insight-developers] itkGradientImageFilter class & misc.

Damion Shelton dmsst59+@pitt.edu
Fri, 18 May 2001 16:25:44 -0400


I'd like some input on the following idea for a subclass of
itkImageToImageFilter called itkGradientImageFilter. We think that
itkGradientImageFilter has the following characteristics:

1) templated over input image type, but not over output image type
2) output image is of the same dimensionality as the input type (n), but the
pixels are n+1 dimensional vectors of doubles
3) positions 0 to n-1 of the vector are the normalized gradient components,
and position n is the gradient magnitude

The exact implementation of GenerateData() would be up to the derived class;
itkGradientImageFilter is a largely virtual class intended to standardize
how gradient information is handled.

In trying to decide how this might fit into the larger structure of image
filters, I ran across the GradientMagnitudeImageFilter class. The name
sounds "general" but as far I can tell is actually a specific gradient
strategy rather than a generalized base class. Aside from this class, is
there any other existing code that worries about gradient

Finally, on a separate topic, it was suggested last week that the
SpatialFunctionImageEvaluatorFilter (which I'm probably going to rename to
SpatialFunctionEvaluatorImageFilter for clarity) also be implemented as
SpatialFunctionEvaluatorImageSource. I've been thinking that there are many
algorithms which might need to be implemented in a similar fashion:

1) as a filter - receive a unique input image, produce a unique output image
2) as a source - produce a unique output image from thin air
3) as an operator (function??) - operate on an existing unique input image
(but produce no output)

All three of these types are already present in ITK, but I'm wondering if
there isn't some way to avoid having to rewrite code when in reality the
changes are pretty minor. I suppose that since creation of a unique image is
not necessarily guaranteed by the FilterImageToImage::GenerateData()
function, one could conceivably return a pointer under GetOutput() which is
in reality the same pointer that was passed to it (i.e. the output is the
"operated on" input) but this could lead to problems with intent - sometimes
a unique output image is desired, sometimes not.

Any thoughts?