[Insight-users] FW: Problem with Demons Variant Deformable Registration

[Torsten Rohlfing]

Hi --

You're welcome :)

Here's what Tom Vercauteren sent to me and the ITK mailing list in 2006
about problems with my fast symmetric forces implementation:

> Hi all,
>
> I have been trying to use the
> FastSymmetricForcesDemonsRegistrationFunction in conjunction with the
> SymmetricForcesDemonsFilter to make a FastSymmetricForcesDemonsFilter.
>
> With this finite difference function, the unit test (modification of
> SymmetricForcesDemonsFilterTest to use the
> FastSymmetricForcesDemonsFilter) does not pass. This has already been
> reported to the insight-user list but AFAIK, no fix was provided:
> http://public.kitware.com/pipermail/insight-users/2005-October/015161.html
>
>
> By modifying the FastSymmetricForcesDemonsRegistrationFunction a
> little, I think I found 2 problems. I hope the information below will
> help other people as well.
>
> 1) As mentioned in the documentation, in the fast function, speed is
> improved by keeping a deformed copy of the moving image for gradient
> evaluation. The problem is that the deformed copy is of the same type
> as the moving image. So if the moving image pixel type is an integer
> type (as in the unit test), the gradients will show very large round
> off errors.
> One solution is to keep a floating point image for the deformed copy
> of the moving image, another would be to let let the user be aware
> that the moving image pixel type has to be a floating point type (in
> the documentation and with concept checking).
>
> 2) The function
> SymmetricForcesDemonsRegistrationFilter::InitializeIteration() calls
> this->GetDifferenceFunction()->InitializeIteration() and then
> this->SmoothDeformationField() whereas it should call
> this->SmoothDeformationField() first and then the rest. The fast
> version indeed needs to smoothed deformation field to precompute the
> deformed copy of the moving image during the call to
> this->GetDifferenceFunction()->InitializeIteration(). Changing this
> order does not change anything to the slow version.
>
>
> Best regards,
> Tom Vercauteren 

This is basically what I was referring to.

As for your question: I am not sufficiently familiar with Tom's code to
tell you why it might be slower (did you turn off the diffeomorphic
enforcement?). Fundamentally, the issues Tom pointed out about my code
should not preclude a fix that makes it correct but keeps it almost as
fast. So my gut feeling is that one should be able to get the best of
both, but I am not sure.

Maybe you could ask Tom -- he is the one who knows both my and his own
code best.

Regards,
  Torsten

Nithiananthan, Sajendra wrote:
> Torsten,
>
> Thanks for the response and pointing me to Tom's implementation.
> You mentioned there are known problems with the existing implementation,
> could you point me to the mailing list posts about them? I am not sure if I
> found them all during my search.
> I did try Tom's implementation of the fast symmetric force thanks to your
> suggestion. It worked well, but didn't "converge" in quite as few
> implementations as the  symmetric forces or fast symmetric forces code that
> ships with ITK (3.2). But it isn't painfully slow like the former, or have
> the problems I mentioned previously in the latter. If it is possible to get
> the best of both worlds I would want to investigate it, or is the fast
> symmetric implementation that ships with ITK a lost cause? Has anyone else
> had any experience using it?
>
> Thanks,
> Sajendra 
>
>
>   
>> -----Original Message-----
>> From: Torsten Rohlfing [mailto:torsten at synapse.sri.com]
>> Hi Sajendra --
>>
>> There are some known problems with the fast symmetric demons 
>> forces code 
>> currently in ITK. These have been discussed on the mailing list, but 
>> were never resolved.
>>
>> Here's an idea though: Tom Vercauteren of INRIA has provided a vastly 
>> improved variant of the demons algorithm, including among 
>> other features 
>> also a working fast symmetric forces implementation. I 
>> believe his code 
>> is currently in the Review/ directory of the ITK source tree. In any 
>> case, you can also get his original implementation from the 
>> InsightJournal website:
>>
>>  
>> http://insight-journal.org/InsightJournalManager/view_publicat
>> ion.php?back=search.php%3Ftexte%3Dvercauteren&pubid=154
>>
>> My suggestion would be for you to give Tom's code a try. 
>> Maybe that will 
>> solve your problems.
>>
>> Best,
>>   Torsten
>>
>> -- 
>> Torsten Rohlfing, PhD          SRI International, Neuroscience Program
>>  Research Scientist             333 Ravenswood Ave, Menlo 
>> Park, CA 94025
>>   Phone: ++1 (650) 859-3379      Fax: ++1 (650) 859-2743
>>    torsten at synapse.sri.com        http://www.stanford.edu/~rohlfing/
>>
>>      "Though this be madness, yet there is a method in't"
>>     
>
> This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization.
>   


-- 
Torsten Rohlfing, PhD          SRI International, Neuroscience Program
Research Scientist             333 Ravenswood Ave, Menlo Park, CA 94025
  Phone: ++1 (650) 859-3379      Fax: ++1 (650) 859-2743
   torsten at synapse.sri.com        http://www.stanford.edu/~rohlfing/

     "Though this be madness, yet there is a method in't"