[Insight-developers] implicit functions / itkImageFunction

[Lydia Ng]

Here is my 2 cents worth:

The only commonality I see is that
both ImplicitFunction and ImageFunction 
has Evaluate( position ) interface.

The question is whether it is worthwhile to put
the two types of functions into a single hierarchy.

If we had to put them in a single hierarchy, 
I think the two sits side-by-side 
under a "SpatialFunction" base class.
Something like:

class SpatialFunction<TPointType, TOutputType>
{
  virtual TOutput Evaluate( TPointType& point );
};

class ImplicitFunction<VPointDimension> :
 public SpatialFunction< Point<double, VPointDimension>, double >
{
  virtual double Evaluate( PointType& point );
  virtual CoVariantVectorType EvaluateGradient( PointType& point);
};

class ImageFunction<TInputImage, TOutputType> :
public SpatialFunction<TInputImage::IndexType, TOutputType>
{
  typedef TInputImage::IndexType IndexType;
  void SetInputImage( const TInputImage *ptr );
  virtual TOutput Evaluate( IndexType& index );
};

class ContinuousImageFunction<TInputImage, TOutputType> :
public SpatialFunction< Point<double,TInputImage::ImageDimension>,
   TOutputType > >
{
  typedef Point<double,TInputImage::ImageDimension> PointType;
  void SetInputImage( const TIntputImage *ptr );
  virtual TOutput Evaluate( PointType& point );

};

This framework should have very little impact on existing code.

The questions are:
1) SpatialFunction is so light-weight is it worthwhile to
have it at all?

2) SpatialFunction adds one more layer to the virtual function
call. Does anyone know what impact it has on performance?

Cheers,
Lydia


> -----Original Message-----
> From: insight-developers-admin@public.kitware.com
> [mailto:insight-developers-admin@public.kitware.com]On Behalf 
> Of Damion
> Shelton
> Sent: Thursday, May 10, 2001 1:43 PM
> To: 'insight-Developers'
> Subject: [Insight-developers] implicit functions / itkImageFunction
> 
> 
> Hi...
> 
> I'd like some feedback on the issue of implicit function 
> behavior, in the
> context of the existing itkImageFunction class, which as 
> Vikram pointed out
> might be useful. For starters, it appears - correct me if I'm 
> wrong - that
> itkImageFunction allows you to evaluate an arbitrary function (with
> arbitrary return type) at every index position.
> 
> Right now I have three classes:
> 
> itkImplicitFunction<unsigned int VImageDimension>
> itkSphereImplicitFunction<unsigned int VImageDimension>
> itkImplicitFunctionImageEvaluatorFilter<class TInputImage, class
> TOutputImage>
> 
> itkImplicitFunction is almost identical to 
> vtkImplicitFunction - it permits
> evaluation of a function and its gradient at an arbitrary 
> position in space,
> defined by a vector of doubles. An itkImplicitFunciton 
> doesn't understand
> indices or pixels, because in the interests of generality it 
> might be nice
> to be able to evaluate generalized n-dimensional functions.
> 
> itkSphereImplicitFunction is based on its cousin in VTK, but 
> generalized to
> the n-d case. The function value is essentially a measure of 
> the distance
> from the input point to the surface of the sphere, along a 
> vector from the
> point to the sphere's center. Therefore, negative values put 
> you inside the
> sphere and positive values put you outside.
> 
> itkImplicitFunctionImageEvaluatorFilter walks an image, and like
> itkImageFunction, evaluates its internal ImplicitFunction at 
> every index
> location. The major differences are as follows:
> 
> 1) itkImplicitFunctionImageEvaluatorFilter walks an entire 
> image, evaluating
> as it goes, while the Evaluate() call in itkImageFunction 
> returns the value
> at a single specified index.
> 
> 2) itkImageFunction works on Images, while
> itkImplicitFunctionImageEvaluatorFilter will work only on 
> PhysicalImages.
> "Normal" images no longer define an origin and spacing, which 
> is required in
> order to evaluate an ImplicitFunction that exists in real 
> space, not in
> index space. For the purposes of validation, we need to work 
> in real space.
> 
> 3) itkImplicitFunctionImageEvaluatorFilter will ultimately 
> make decisions
> about how to "shade" the image based on the value of the 
> ImplicitFunction at
> a given index location. In other words, the output of
> itkImplicitFunctionImageEvaluatorFilter is itself an image, with the
> ImplicitFunction "drawn" into the image volume.
> 
> So, the question is am I doing something that is a logical 
> extension of
> itkImageFunction? I don't think so, but it's entirely 
> possible that there's
> other stuff in the class hierarchy that I've missed.
> 
> As always, thoughts are most welcome....
> 
> -Damion-
> 
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers