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

[Luis Ibanez]

Hi Tom,

Thanks a lot for looking at this problem and for providing
such a detailed explanation.

I'm having trouble understanding why the order should matter.

If the initial deformation field is null (an identity), then
the initial smoothing shouldn't make any difference, isn't it ?

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.

---

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.


   Please let us know if that sounds reasonable.


      Thanks


        Luis


----------------------
Tom Vercauteren wrote:
> Hi Luis,
> 
> I finally took some time to review the circle registration tests you
> added for the diffeomorphic demons and fast symmetric demons.
> 
> I found why the standard demons algorithm was passing the circle
> registration test but my versions were not. The main difference is
> where the smoothing is done. I did this modification on purpose but
> for some reason forgot about it when we first talked about the tests.
> The explanation is below.
> 
> I have a few questions with respect to this difference:
> 1) Should we try and make the behavior more consistent between the
> different algorithms (maybe not now but for future releases)? If so
> how? Forcing current/new behavior everywhere? Adding a flag to allow
> both?
> 2) Should we document the difference? If so were?
> 3) Should we modify the unit test to be less stringent with the
> diffeomorphic demons and fast symmetric demons?
> 
> ------------
> Now the explanation.
> 
>  - Standard demons: SmoothDeformationField() is called within
> InitializeIteration() which implies the following loop:
> 
>     for i = 1:number_of_iterations
>        1) Smooth field
>        2) Compute update
>        3) Use update
> 
>  - Diffeomorphic (and fast symmetric) demons: SmoothDeformationField()
> is called within ApplyUpdate(TimeStepType dt). This implies the
> following loop:
> 
>     for i = 1:number_of_iterations
>        1) Compute update
>        2) Use update
>        3) Smooth field
> 
> 
> This means that my versions end with a smoothing. This explains the
> larger number of different pixels in the circle registration test.
> 
> I believe that my approach makes more sense since:
> 1) In a typical application, we need the final field to be rather smooth
> 2) My solution uses any initial deformation field in a manner that
> seems more consistent with what a typical user would expect: We use
> the initial deformation field to compute new demons force.
> Furthermore, in most case the initial deformation filed will come from
> a previous (smoother) registration such as an affine registration or
> another demons registration done on a downsampled image
> (multiresolution strategy).
> 
> 
> I know it is kind of late to discuss these points but unfortunately I
> only have little time to work on ITK.
> 
> Regards,
> Tom
> 
> P.S.: I have CCed the developer list has this question may interest more people.
>