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

Thu Mar 5 12:13:33 EST 2009

Le 5 mars 09 à 15:52, Stephen Aylward a écrit :

> Your definition of a "good" experience is not consistent with what
> most long-time users would consider good.
>
> The suggested change would affect everyone who is using a
> multiresolution pyramid in their programs.   Tests will fail (maybe
> not ones in ITK's dashboards, but other peoples tests that we'll never
> see).  Results will change in subtle ways and users won't know why.
> You'll force people to conclude the ITK is like the wild west and has
> no oversight and is not something that can be relied upon.  ITK users
> will leave and find other solutions.   ITK will wither and die.

I'm NOT suggesting to make a non backward compatible change - I only  
say that an option which is not optional is not a good idea.

>
> We'll eventually break backward compatibility, but I strongly feel
> that this is a very clear example of when not to break it.

It doesn't seem clear to me! Can you explain?

>
>
> If you're going to break backward compatibility, you need to REALLY
> break it.   Change 100s of filters, rename things, and more.  You
> don't do it slowly or subtly.   Let people know when things change -
> don't leave it as a "surprise"  - and make it a infrequent thing so
> the cost of the upgrade is born once by everyone - or people can
> choose to instead keep using the old path without fear.

I fully agree on this part :-)
There are many things to fix in ITK, which can't be fixed (easily)  
without breaking backward compatibility, or adding more and more cmake  
options. At some point, we'll have to think about breaking  
compatibility, and my feeling is that it won't be in a far future.

Maybe we should start a list on the wiki.

Gaëtan

>
>
> s
>
> On Thu, Mar 5, 2009 at 9:21 AM, Gaëtan Lehmann
> <gaetan.lehmann at jouy.inra.fr> wrote:
>>
>> 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
>>
>>
>
>
>
> -- 
> Stephen R. Aylward, Ph.D.
> Chief Medical Scientist
> Kitware, Inc. - North Carolina Office
> http://www.kitware.com
> (518) 371-3971 x300

-- 
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/b374b036/attachment.pgp>