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

Thu Mar 5 09:52:02 EST 2009

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.

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

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.

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