[Insight-developers] itkGradientImageFilter class & misc.

[Miller, James V (CRD)]

I would separate the gradient direction from the magnitude (rather than lumping it all in one
vector). There are a few ways to do this:

1) Your filter produces an image of ScalarVectors (don't know off the top of my head whether this
class is up to date) where the scalar value is the gradient magnitude and the vector is the
normalized gradient.

2) Same as #1 but use a pixel called something like "GradientPixel" which has a scalar called
m_Magnitude and vector called m_Direction.

3) Have your filter produce just a vector of unnormalized gradients.  The user could then take the
output of this filter and run it through separate vector normalizing and vector magnitude calculating
filters. The benefit here is that if an algorithm can work directly with unnormalized gradients they
will have to pay the penalty of normalizing.  The downside is that this would be a O(3N) instead of
O(N).

4) Do #3, then write a filter that does #3 and #1 (or #2) in a composite object as a shortcut for the
user.

Jim



-----Original Message-----
From: Damion Shelton [mailto:dmsst59+@pitt.edu]
Sent: Friday, May 18, 2001 4:26 PM
To: 'insight-Developers'
Subject: [Insight-developers] itkGradientImageFilter class & misc.


Hi...

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
vectors/magnitudes?

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?

-Damion-


_______________________________________________
Insight-developers mailing list
Insight-developers@public.kitware.com
http://public.kitware.com/mailman/listinfo/insight-developers