[Insight-users] MultiResMIRegistration - QuaternionRigid 2 Affine (3)

[Luis Ibanez]

Hi Christos,

Registration with scaling is a particularly
difficult task. The reason is that metrics
do not necessarily behave the way you expect
when you apply a scaling transform to one
of the images.

You may want to experiment first with a
totally independent registration exercise,
using the itkScaleTransform, until you get
a feeling for the heuristics of registering
in scale.  I would suggest you to play with
any of the examples in

   Insight/Examples/Registration

replacing the transform with the
itkScaleTransform.

The first thing unnatural about scaling
registration is the fact that the parameter
space is not a vector space. In principle,
the optimizer would behave better if it
operates on the logarithm of the scales
instead of trying to optimize the scale
value directly.

Also note that optimizers need your help.
If you can guess any good initial value
for the transform, that will help the
optimizer to enter in the region of
capture of the minima. If you 'know'
that the OT image is compressed along X,
please guess a factor of this geometric
scaling in the initialization of the
transform. Rememeber that with Affine
transforms in 3D you are performing
optimization in a 12-dimensional space.
Any hint will help the optimizer there !


About your attempts with the number of samples
in the Mutual Information metric: It has been
proven both theoretically and experimentally
that the number of samples is irrelevant or
close to irrelevant. As conterinutitive as it
may sound....

So, don't bother tunning this parameter.
Instead you may want to work more on the
geometrical aspects of the problem.


Note that if your final goal is to do
deformable registration, you may find
interesting shorcuts. Although you are
encouraged to continue your familiarization
with the basic registration framework, that
will certainly help you to interpret the
more complex situations found in deformable
registration.



   Regards,


      Luis


-----------------------------
Christos Panagiotou wrote:

> Dear Luis
> 
> thanks once again for your very detailed response
> I will try and implement you suggestions as i am very interested to see 
> their results.
> 
> I would like to ask some further questions just to clarify some things:
> what i ve succeeded to implement at this point is have the volumes 
> centered and
> rotated (this is probably due to the effects of the centerer. I ve 
> "played" with the tunning parameters
> of the registration and I can see some scaling effects (it looks more 
> like isotropic scaling) however i dont seem to
> get and direction specific scaling. For example the optical volume is 
> smaller in size and narrower in the x-axis.
> After the centering of the volumes i ve tried various learning rates, 
> standard deviations, iterations and even number of samples
> (even if you suggest 50 - 80 is enough) and the registration output 
> somehow registers either the top of the skulls in both volumes (without 
> however
> expanding the x-axis of the small volume to "match" the whole extend of 
> the skull in the bigger one)
> OR it moves the smaller volume (OT) and registers the front part of the 
> head (fase) (registers the noses and the forehead :) ).
> For a better result I expect an unisotropic scaling in the x-axis so the 
> back of the OT volume would expand to fit the back of the skull in the 
> MRI volume.
> However I wouldn't want to force this x-axis scaling by myself.
> 
> Is this a problem of chosing the tunning parameters? if i dramaticaly 
> increase the number of samples would this give me a better result?
> I tried something like 1000 however i get the exception of "all points 
> mapped outside of the volume" even if i use the SAME learning
> rates, iterations, standard deviations and shrink levels with a working 
> example which differs only in the number of samples.
> 
> Anyway at this moment I would like to try and implement what you ve 
> suggested and come back with more accurate questions...
> 
> At the end of the day my goal is to achieve a deformable registration 
> between the two volumes, however I ask all these as I try to
> get familiar and have aceptable results with the affine version before i 
> move to the deformable one.
> 
> Thank you very much for your replies and your tolerance
> 
> Regards
> Christos
> 
> 
> 
> 
> 
> 
> Luis Ibanez wrote:
> 
>>
>> Hi Christos,
>>
>>
>> You are right, I overlooked the fact that you are using
>> the code of the MultiResMIRegistration application, and
>> this application already takes care of repositioning the
>> image origins. So, you don't really need the CenteredAffine
>> transform or the CenteredTransformInitializer in this case.
>>
>> If you already managed to register for translation and
>> orientation, what you can do now is to take the resulting
>> parameters of your current registration and multiply all
>> the components in the Matrix (not in the translation vector)
>> with a values representing the expected scaling.  Notice
>> that the transform is the one mapping coordinates from the
>> fixed image (MRI) to the moving image (your OT).  So you
>> probably want to multiply by a value such as 0.8 or 0.7.
>>
>> Also, in order to disable the translations you can use a
>> translation scaling vector with large values for the
>> components of the translation vector (components 10, 11
>> and 12).  You could set them to 10.0 for example.  This
>> will result in those components being attenuated during
>> the optimization cycle.
>>
>>
>> Note that you could also (in this second run), replace the
>> AffineTransform with the ScaleTransform and focus exclusively
>> in scaling the image.  For this purpose it may be more convenient
>> to use the resampled moving image resulting from the current
>> registration in which you already succeed in correcting for
>> translation and rotation.
>>
>>
>> When optimizing for scaling you have to keep in mind that
>> learning rates result in values being added to the scaling
>> parameters (not multiplied with them), so you don't want
>> to use any large step like "1.0" which in terms of scaling
>> means that you can initialize with scaling 1.0, and in the
>> next iteration try: 1.0 + 1.0 = 2.0 as scale factor, which
>> be too much of a sudden change.
>>
>>
>>
>>
>>   Regards,
>>
>>
>>
>>      Luis
>>
>>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>