[Insight-developers] Variable sigma along each axis in itk::SmoothingRecursiveGaussianImageFilter

Karthik Krishnan karthik.krishnan at kitware.com
Thu Jun 17 14:40:28 EDT 2010


On Thu, Jun 17, 2010 at 11:35 PM, Bradley Lowekamp
<blowekamp at mail.nih.gov>wrote:

>
> In general I think this is a good idea. However looking at the convention
> for the DiscreteGaussianImageFilter, I see that it uses methods overloading
> to have the following functions:
> virtual void SetVarriance( ArrayType _arg );
> void SetVariance (const typename ArrayType::ValueType v);
> void SetVariance (const double *v);
> void SetVariance (const float *v);
>
> with only one get method:
> virtual ArrayType GetVariance( void ) const;
>
> However looking at all the other recursive Gaussian filters (not
> compressive list):
> GradientMagnitudeRecursiveGaussianImageFilter
> RecursiveGaussianImageFilter
>

Please knock this one off the list. This is the separable filter applied in
one direction and hence will take in a scalar.

GradientRecursiveGaussianImageFilter
> HessianRecursiveGaussianImageFilter
> SmoothingRecursiveGaussianImageFilter
> LaplacianRecursiveGaussianImageFilter.h
>
> They currently seem to follow the convention of just:
> void SetSigma( RealType sigma );
> RealType GetSigma( void );
>
> 1) While there is not consistency between the Discrete and Recursive
> filters they currently are consistent amongst themselves. If array methods
> are added to one recursive filter, they should be added to them all to
> maintain the same interface.
>

Agreed. I may consider making a pass through all, but its more than I'd like
to sign up for :)


> 2) More often then not I believe function overloading with different
> parameters is used to set the array in this type of situation. Again a
> constant interface is good.
>

Yes, as you've already mentioned in (3), one can't overload the return type
or get rid of the existing one in the interest of BCP. Hence the dual
methods, with matching Set/Get.

  Set/GetSigma
  Set/GetSigmaArray

I'd be happy to go with any other recommendation.


> 3) Due to not being able to overload return methods, I don't think we can
> get a good interface with the Get methods...
>

Thanks
--
karthik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20100618/af8dfdc8/attachment.htm>


More information about the Insight-developers mailing list