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

Tom Vercauteren tom.vercauteren at m4x.org
Wed Jul 16 04:51:11 EDT 2008


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.


More information about the Insight-developers mailing list