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

[Matthew McCormick (thewtex)]

On Thu, Jun 17, 2010 at 1:40 PM, Karthik Krishnan <
karthik.krishnan at kitware.com> wrote:

> 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 think it is better to only have a single GetSigma() that returns a
SigmaArrayType.  Otherwise, if different values are set, then only only one
Sigma value is returned, and a logical error can occur transparently.  In my
opinion, there should only be one Get* method that returns the most complex
type.

Matt



>
> 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
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20100618/77750894/attachment.htm>