[Insight-users] An implementation question in ITK

[Hua-mei Chen]

Dear Luis,

         Thank you so much for your quick and detailed response. But I still
have a doubt. I appreciate that you pointed out, " there is a difference
between computing the gradient of the moving image in the coordinate system
of the moving image, and then mapping that back to the coordinate system of
the fixed image,  and mapping the
moving image to the coordinate system of the fixed image and then computing
the gradient with respect to the coordinate system of the fixed image". I
believe the code I came cross with belongs to the latter case. But, when the
gradient with respect to the coordinate system of the fixed image is
obtained and an increment (update) of the deformation field calculated
accordingly, how is the increment (update) combined to the original
deformation? This is what perplexed me a lot. Simply adding it back to the
original deformation field sounds not quite right to me. Please give me some
guidance. Thank you.

Sincerely,

Hua-mei Chen


On Wed, Jun 3, 2009 at 10:15 PM, Luis Ibanez <luis.ibanez at kitware.com>wrote:

>
> Hi Hua,
>
>
> 1) In the case of the MeanSquaresImageMetric,
>   the Gradient of the moving image is interpolated using
>   NearestNeighborhood interpolation.
>
>   See lines: 210-217 of
>
>   Insight/Code/Algorithms/itkMeanSquaresImageToImageMetric.txx
>
>
> 2) In the case of the SymmetricForcesDemonsRegistration
>   the gradient of the moving image is computed *after*
>   mapping the moving image to the coordinate system of
>   the fixed image.
>
>   See lines: 188-220 of
>
>    Insight/Code/Algorithms/
>      itkSymmetricForcesDemonsRegistrationFunction.txx
>
>   Note that in this case, this is done "on-demand",
>   that is, on a pixel-by-pixel basis.
>
>
>
> 3) In the case of the
>   itkFastSymmetricForcesDemonsRegistrationFunction
>
>   The gradient is also computed by finite differences
>   *after* mapping the moving image to the coordinate
>   system of the fixed image, but this time is not done
>   on-demand, but the entire moving image is warped
>   first, and the resulting warped image is used for
>   computing the gradient.
>
>   See lines: 196  and  151-157  of
>
>
>    Insight/Code/Algorithms/
>      itkFastSymmetricForcesDemonsRegistrationFunction.txx
>
>    Note that there is a difference between computing the
>    gradient of the moving image in the coordinate system
>    of the moving image, and then mapping that back to the
>    coordinate system of the fixed image,  and mapping the
>    moving image to the coordinate system of the fixed image
>    and then computing the gradient with respect to the
>    coordinate system of the fixed image.
>
>
>
>
>   Regards,
>
>
>       Luis
>
>
>
> ---------------------
>
> Hua-mei Chen wrote:
>
>> Sorry. I forgot to change the subject of my previous email. Here I re-send
>> it again.
>>
>> ====================================================================
>>
>> Dear ITK Users and Developers,
>>
>>        In deformable image registration, it is very common to find the
>> image gradient at non-grid positions. For example, to obtain the driving
>> force by taking the derivative of SSD similarity measure. I am wondering how
>> this procedure is implemented in ITK. I used to construct a continuous image
>> based on Bspline model and then find the derivitive at non-grid positions.
>> However, I recently found a MATLAB code which resamples the image based on
>> the current deformation field and then find the gradient at the resampled
>> image. In this way, there is no need to find the gradient at non-grid
>> positions. Afterwards, the gradient information is used to construct the
>> update of the deformation field and the new deformation field is obtained by
>> ADDING the update to the original deformation field. Is this a common
>> practice to implement deformable image registration algorithms like demons,
>> fluid, and FFD in ITK? Any response is appreciated.
>>
>> Chen
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090603/b179d657/attachment-0001.htm>