[Insight-developers] Unit tests - Smoothing difference between standard and diffeomorphic demons

[Tom Vercauteren]

Hi,

Here is the bug report:
http://www.itk.org/Bug/view.php?id=7351

Tom

On Thu, Jul 17, 2008 at 3:59 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>
> Hi Tom,
>
> Yeap, the additional flags sound like the right way to go.
> We will reopen the repository for changes as soon as we
> release ITK 3.8 at the end of July.
>
> You may want to file a bug entry for this issue,
> just to make sure that we don't forget about it.
>
>
>   Thanks !
>
>
>      Luis
>
>
> -----------------------
> Tom Vercauteren wrote:
>>
>> Hi Luis and Hans,
>>
>> Thanks for your feedback. I'll try and comment below.
>>
>>
>>> I can see, however, how the final smoothing may be a problem,
>>> since it is an extra smoothing after the last version of the
>>> field has been computed.
>>>
>>> This raises the interesting point that probably a better
>>> behavior of the overall algorithm will be to perform progressively
>>> less and less smoothing as the iterations progress, under the
>>> assumption that the field is converging to a stable solution,
>>> and at that point, the smoothing, more than regularizing the
>>> solution is actually perturbing it.
>>
>>
>> I don't think that the final smoothing is perturbing the results.
>> Indeed the "quality" of the registration is a trade-off between the
>> image similarity and the field regularity. The test is only measuring
>> one of these metrics.
>>
>> Concerning a progressive reduction of the smoothing, I think it is out
>> of the scope of this discussion and needs some research :)
>> Anyhow, it should at least be done in conjunction with a progressive
>> reduction of the update step length.
>>
>>
>>> The good news is that given that the new code is in the Review
>>> directory, we have the freedom to rework its API and behavior
>>> to do the right thing. Changes are acceptable at this point if
>>> we can make the case that they relate to bug fixes, and not
>>> to adding new functionality.
>>>
>>> The three options that you suggest sound very reasonable.
>>> They don't seem to be exclusive, so we could actually opt
>>> for all of them.
>>>
>>> Adding a flag to allow both behaviors in the DemonsRegistration
>>> filters (smoothing first or smoothing after), documenting the flag and
>>> its effect, and adding tests for the flag ON and flag OFF, so we
>>> exercise both types of usage. Note that then we can relax the tests
>>> cases corresponding to the 'smooth after' case.
>>>
>>> If you have some time available for making the appropriate
>>> changes inside your Demons classes, we will take care of the
>>> documentation and the additional testing. We probably shouldn't
>>> touch the current Demons class in Algorithms.
>>
>>
>>> From Hans:
>>
>>> ====
>>> With regards to when smoothing should occur, there are three indepent
>>> choices:  Smooth initial deformation field, Smooth during iterations,
>>> smooth
>>> final deformation field.  These are not exclusive operations.  If this
>>> were
>>> done, then the current Demons class in Algorithms could also be modified
>>> in
>>> a backwards compatible way so that the default behavior remain the same
>>> (That is until ITK 4.0 where we would be allowed to make default behavior
>>> changes :-) ).
>>>
>>> ====
>>
>>
>> I do agree with Hans. I could of course add the flag to my code. It
>> might however be better to do it after the 3.8 release and do it both
>> on my classes and on the current demons classes (with different
>> default behaviors to keep backwards compatibility on the current class
>> and the "nicer" behavior on the new classes).
>>
>>
>>
>>> A post-doc in our lab is currently trying to reconcile differences
>>> between
>>> the different demons implementations.  As part of this effort he will be
>>> stress testing the code quite extensively.  We will let you know if there
>>> are any problems that occur.
>>
>>
>> Great!
>>
>> Tom
>>
>