[Insight-users] Small problems with FastSymmetricForcesDemonsRegistrationFunction

[Tom Vercauteren]

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