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

[Luis Ibanez]

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
>