[Insight-users] Versor3DRegistration and the masks of meanSquareMetric

[Karthik Krishnan]

Martin Urschler wrote:

> hello all,
>
> I'm using a Versor3DRegistration with a MeanSquaresMetric for an 
> iterative registration procedure.
> I'm using the output of one registration iteration to calculate a 
> misregistration region which is used in the next registration step as 
> a mask for the metric.
>
> There are two issues that I have in mind which kind of confuse me.
>
> First, the MeanSquaresMetric allows you to specify a fixedImageMask 
> and a movingImageMask. I understand the fixed mask. During metric 
> calculation one iterates over the fixed image voxels. If the physical 
> location of the fixed image voxel is inside the fixedImageMask, then 
> it will be used for the metric calculation.
> But, I don't understand the moving image mask (which I've been using 
> up to now). If you specify a moving image mask, then in the course of 
> the optimization it may well be possible that you start your 
> optimization with parameters that won't map you into the moving image 
> mask area, which would lead to an abort of the optimizer although 
> optimization may easily be possible. And even if there are a few 
> voxels that map into the movingImageMask with the initial parameters 
> the metrics derivative will be quite useless and could point you in 
> the entirely wrong direction ...
>
> So my point is in short: Is it a good thing to specify a moving image 
> mask in a registration??? Or do I misunderstand something here?
>
Here's my take on this:

Don't you think the relevance of the fixed and moving masks is 
reciprocal ? The fixed image mask should be just as relevant as the 
moving image mask. For instance, let's imagine, you've managed to 
delineate region "F" in the fixed image as relevant areas over which the 
metric should be evaluated for purposes of registration.  And/Or you've 
delineated regions "M" in the moving image.

Sure, as you pointed out, if you start off with a horrible initial 
misalignment, in the worst case, the regions don't overlap and the 
metric never gets computed.  Usually, in a registration application, if 
you've gone through the trouble of specifying relevant regions in both 
the fixed and moving image regions, you already have some idea of the 
initial transform and there is no excuse for not specifying an initial 
transform that guarantees significant overlap between the two masks.

(This will of course only happen if you've specified *both* a fixed and 
moving image mask, and not if just specify one of them. )

> If I'm right then this should somehow be documented to not use the 
> movingImageMask in a registration - since I guess it would be overkill 
> to remove the movingImageMask from the ImageToImageMetric... :-)
>
What if you were aware of relevant anatomical regions in just the moving 
image ?

>
> Second, I (still) have some problems understanding the 
> Versor3DTransform. I looked through the itk software guide and think I 
> understood the CenteredRigid2DTransform. Now my question is: Is the 
> VersorRigid3DTransform also a centered transform? I.e. if I specify an 
> initial versor, an initial translation and an initial rotation center, 
> will an optimization take into consideration the rotation center as 
> well. Or will the center of rotation stay the same during 
> optimization? The Software guide isn't clear about that (at least 
> version 2.0.2 isn't).

The VersorRigid3DOptimizer optimizes 6 paramters, (which does not 
include the center). The paramters it optimizes are the translation + 
versor. So the center of rotation will stay the same.

>
> In my application I have some registration behaviour that I don't 
> understand but it might also come from the issue mentioned above, 
> therefore I'd like to eliminate things one by one...
>
> thanks,
> Martin
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>