[Insight-users] LevelSetMotionRegistration

Miller, James V (Research) millerjv at crd.ge.com
Fri Apr 29 12:04:13 EDT 2005


Martin, 

Yes.  If the pixel spacing is very anisotropic, this could sample 
strangley in the dimensions that have small spacing.  Looking at it
I don't really see a reason why it couldn't step using the actual
pixel sizes of the moving image. So there is not real good reason
for what it is doing right now.  I think I did this so that the 
method would step approximately "one voxel". Looking back, this is 
just bogus.  I checked in a fix so that the derivatives are calculated
by steping by the pixel spacing in each direction.

The FIXME sentence is refering to the derivatives in the moving 
image are in a distorted reference frame from the derivatives in 
the fixed image.  To relate information from the derivatives in 
the two images, we should really take into account the current
deformation field (via it Jacobian).  We can do this implictly, 
if we select the sample positions for the finite difference from 
the fixed image (point +- 1 pixel), map those points through the 
deformation field, and then sample the moving image at those points.

For example, to evaluate the derivative, we need M(x+dx) and M(x-dx). 
Currently, we just sample the moving image at these points.  To have 
this derivative calculated in the Fixed image coordinate frame, we need 
to use M(D(x+dx)) and M(D(x-dx)) where D is the deformation map that 
takes the point x+dx in the fixed image to the appropriate point in 
the moving image. This is essentially what the SymmetricForcesDemons
function does.

Jim



-----Original Message-----
From: insight-users-bounces at itk.org
[mailto:insight-users-bounces at itk.org]On Behalf Of Martin Urschler
Sent: Friday, April 29, 2005 9:25 AM
To: insight-users at itk.org
Subject: [Insight-users] LevelSetMotionRegistration


hello,

i'm currently looking through the code for the LevelSetMotionRegistration


there is something that i don't understand in 
LevelSetMotionRegistrationFunction

the calculation of the finite differences in the computeUpdate method 
uses the member m_MovingPixelSize to determine the delta_x, delta_y, 
delta_z (which are all the same in the end)

now this value is calculated as
m_movingPixelValue = sqrt( movingImageSpacingX^2 + movingImageSpacingY^2 
+ movingImageSpacingZ^2 ) in the method InitializeIteration

as i understand it, this means that for the finite difference 
calculations voxels which are comparatively far away from the central 
value might be used (depending on the spacing)... imagine voxel spacings 
of 2.0mm in each direction respectively, then the m_movingPixelValue 
would be sqrt( 12 ), meaning that the finite difference approximation 
does not take an interpolated value near the neighbor voxel (x+1,y,z) 
but nearly at voxel (x+2,y,z)

what is the reason for that?

further, what does the FIXXME sentence
'Do we need to structure the gradient calculation to take into account 
the Jacobian of the deformation field?' mean

thanks,
Martin

_______________________________________________
Insight-users mailing list
Insight-users at itk.org
http://www.itk.org/mailman/listinfo/insight-users


More information about the Insight-users mailing list