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

[Luis Ibanez]

Hi Hans,

Yeap, that sounds reasonable.

Now that we have an explanation of why the test would behave
differently, it makes more sense to adapt the test to the
actual behavior of the new class.

We should consider that in the future, users will probably
experiment with switching these classes in their applications,
and therefore we should explain in the documentation, what
are the differences in behavior that they should expect when
replacing the current Demons with the Diffeomorphic one.



     Luis



-----------------------
Johnson, Hans wrote:
> 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
> 
> 
> 
>