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

Wed Jul 16 10:01:12 EDT 2008

Luis,

You assumption that the initial transform is null is not always true.  In
many cases the demons algorithms is just one component of a multi-algorithm
registration framework.

====
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 :-) ).

====

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.

Thanks,
Hans
-- 
Hans J. Johnson, Ph.D.
Hans-johnson at uiowa.edu

278 GH
The University of Iowa
Iowa City, IA 52241
(319) 353 8587

> From: Luis Ibanez <luis.ibanez at kitware.com>
> Date: Wed, 16 Jul 2008 09:25:44 -0400
> To: Tom Vercauteren <tom.vercauteren at m4x.org>
> Cc: ITK <insight-developers at itk.org>
> Subject: Re: [Insight-developers] Unit tests - Smoothing difference between
> standard and diffeomorphic demonsg
> 
> 
> 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.
>> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers

Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.