[Insight-developers] Multi-resolution pyramid and multi-resolution PDE deformable registration small issues

[Gaëtan Lehmann]

Hi,

Le 5 mars 09 à 14:11, Stephen Aylward a écrit :

> How about making this an option?
>
> The default behavior can be unchanged (heck, could even throw a
> deprecated flag and explain why).   If the option is set then the
> deprecated flag isn't thrown and you get the behaviour you'd like.

By throwing a deprecated flag, do you mean printing a warning on  
std::cerr?
If yes, it doesn't seem to be a good option for me, because the option  
becomes mandatory, so it's not an option anymore.
We should try to give quite good default values, to make the user  
experience as good as possible. For me, a default value which produce  
a warning in all the cases is not a good default value.

About filters behavior, I think we'll have to talk about breaking  
backward compatibility one of these days, to have more consistent  
behavior in the toolkit, better default values, or simply to include  
refactored classes. I think I can build a quite long list of changes  
to make, and I'm sure most of us have lot of ideas of things to  
enhance. A few ones which come to mind:
* the binary or label images definition, largely inconsistent in the  
toolkit, as well as the default values for the foreground or the  
background in those images
* the default behavior of the distance map filters, which is in favour  
of efficiency currently rather than quality, and thus produce a  
squared distance without using the spacing by default - it can be  
quite confusing for the new comers
* Grayscale/Binary prefix inconsistencies in filter names
* the new statistics framework. I can be wrong, but I wouldn't be much  
surprised if the integration was not made yet because it's quite  
difficult to do without breaking backward compatibility
* all the code managed by cmake options

Major library revisions are made for breaking the API. We should use  
that from time to time.
ITK is 10 years old - maybe 2009 is a good year to break backward  
compatibility :-)

Regards,

Gaëtan


>
>
> Option should be controlled by a member function (NOT a cmake option).
>  Perhaps something like: AlwaysSmoothOutput or OverSmoothOutput or
> some such...
>
> s
>
> On Thu, Mar 5, 2009 at 4:12 AM, Tom Vercauteren <tom.vercauteren at m4x.org 
> > wrote:
>> Hi all,
>>
>> I just saw a few weird things in some multi-resolution objects.
>>
>> First of all, the MultiResolutionPyramidImageFilter will always
>> produce a blurred image even with an all one schedule. This is  
>> because
>> the input it always smoothed to produce the output. If the schedule  
>> at
>> a given level is all one, the sigma of the Gaussian will be 0.5.
>>
>> This case is better handled in
>> RecursiveMultiResolutionPyramidImageFilter. In that class, if the
>> schedule is all one, the output will only be a casted version of the
>> input. This makes more sense to me.
>>
>> Would anyone mind if I changed the behavior of
>> MultiResolutionPyramidImageFilter to perform the same operation as
>> RecursiveMultiResolutionPyramidImageFilter in the case of all one
>> schedule?
>>
>>
>> Also it seems that RecursiveMultiResolutionPyramidImageFilter should
>> be the default image pyramid class for most applications. It is more
>> efficient than MultiResolutionPyramidImageFilter when the schedule is
>> downward divisible and falls back to  
>> MultiResolutionPyramidImageFilter
>> when it is not.
>>
>> Would anyone mind if I changed the default image pyramid filter in
>> MultiResolutionPDEDeformableRegistration to be
>> RecursiveMultiResolutionPyramidImageFilter instead of
>> MultiResolutionPyramidImageFilter?
>>
>> Regards,
>> Tom
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.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
>>
>
>
>
> -- 
> Stephen R. Aylward, Ph.D.
> Chief Medical Scientist
> Kitware, Inc. - North Carolina Office
> http://www.kitware.com
> (518) 371-3971 x300
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.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

-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.mandriva.org
http://www.itk.org  http://www.clavier-dvorak.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090305/530fe326/attachment.pgp>