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

[Hans Johnson]

Luis,

The post doc, Yong Qiang Zhao is updating our (2 year old) thirion demons
application to be a super-set of the diffeomorphic demons programs submitted
by Tom to the insight journal. We have already made command line changes so
that all the command line options present in the insight journal version are
respected in the "expanded" version that we are working on  (THANKS JIM for
the GenerateCLP aliases!).

Our hope is that this expanded version can be a drop in replacement to the
reference diffeomorphic version from insight journal, and would provide
exactly the same results.  This expanded version will be made available on
NITRC, and would act as a Slicer3 module.

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:28:47 -0400
> To: Johnson Hans <hans-johnson at uiowa.edu>
> Cc: Tom Vercauteren <tom.vercauteren at m4x.org>, ITK
> <insight-developers at itk.org>
> Subject: Re: [Insight-developers] Unit tests - Smoothing difference between
> standard and diffeomorphic demons
> 
> 
> 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
>> 
>> 
>> 
>> 



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.