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

Johnson, Hans hans-johnson at uiowa.edu
Wed Jul 16 08:47:01 EDT 2008


Luis,

If Tom's comments are correctly stated, then I agree with his arrangement of
operations.



Hans


On 7/16/08 3:51 AM, "Tom Vercauteren" <tom.vercauteren at m4x.org> 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.
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers




More information about the Insight-developers mailing list