[Insight-developers] Question regardingitk::SymmetricDemonsForceRegistrationFunction::ComputeUpdate()

[Miller, James V (Research)]

Torsten, 

You are quite right.  I was not taking account the dt aspect.

(Now I will try to save myself.  No real reason for doing this other than I spent 
the last 8 hours in a meeting and I am looking for some fun.)

The Function actually knows the dt.  In fact, it is responsible for determining 
the dt.

And in the case of the Demons functions, I think the dt in by default 1.

(The reason I know this is because when I added the LevelSetMotion technique, 
I had to figure out how to get it to calculate the appropriate dt and specify 
that dt to the FiniteDifference framework.)

Back to the symmetric case, the function does not know whether the deformation
field is smoothed prior to being applied, after being applied, or not at all.
So maybe it makes more sense for the symmetric case to calculate the 
SumOfSquaredDifferences in the manner as the non-symmetric case.

Jim



-----Original Message-----
From: Torsten Rohlfing [mailto:torsten at synapse.sri.com]
Sent: Friday, May 06, 2005 11:37 AM
To: Miller, James V (Research)
Cc: insight-developers at itk.org
Subject: Re: [Insight-developers] Question
regardingitk::SymmetricDemonsForceRegistrationFunction::ComputeUpdate()



Jim:

Thanks for the explanation. I can almost see your point, except that I 
disagree with this statement:

>The symmetric case calculates the SumOfSquaredDifference as the 
>difference between the fixed and moving image using the deformation
>field calculated by the CURRENT iteration, i.e. the SumOfSquaredDifferences
>AFTER the new update field is calculate.
>
>So, the SumOfSquaredDifference in the non-symmetric case is the alignment
>error at the beginning of an iteration, whereas for the symmetric case, it is 
>the alignment error at the end of an iteration.
>  
>
As I mentioned earlier, the registration function does not actually know 
(or have control over) how much of the computed update is actually 
applied (see time step parameter "dt" to ApplyUpdate), and whether the 
update or the resulting deformation field is smoothed. So what I've been 
seeing here when I played around with things was that the symmetric 
force actually produced oscillating values, even though the actual 
metric was actually decreasing monotonically. That's because the 
registration function in general applies too aggressive an update 
internally, so it overshoots.

Again, thanks for your comments!
  Torsten