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

[Karthik Krishnan]

Matt:

We can't do that in the interest of Backward compatibility.

BTW, I have committed this late last night.

Thanks
--
karthik

On Fri, Jun 18, 2010 at 10:35 PM, Matthew McCormick (thewtex) <
matt at mmmccormick.com> wrote:

>
>
> 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/bc447a3b/attachment.htm>