[Insight-users] Re: Mattes MI & 1+1 ES optimizer = overlap exception

[Luis Ibanez]

Hi Christos,


1) The criteria for evaluating how much overlap is needed
    between fixed and moving images is different among the
    Viola-Wells and the Mattes implementations of Mutual
    Information in ITK. That may explain why the program
    was at least performing the first iteration when using
    the VW metric.


2) The MIRegistrator.cxx is actually initializing the
    transform in lines 79-80, when it fills the array
    of m_InitialParameters. This is equivalent to set
    the Affine transform to SetIdentity().


3) That's fine. Actually this application does the origin
    and image centered correction for you. This is for
    historical reasons. The CenteredAffineTransform wasn't
    available at the time this application was written.

4) There is no initializer for the AffineTransform.
    The Initializer was introduced specifically for
    taking care of the center of rotation issue. You
    can just invoke SetIdentity() in the transform before
    you get its parameters. Or use similar method to the
    one in (2).

5) MI is very noisy. That part of its stochastic nature.
    If you think about it, you are using only 50 points
    in order to registers images with millions of pixels.

    Now that, if your metric plot is much noiser that the
    ones shown in the SoftwareGuide, then you are in serious
    trouble, since a gradient descent optimizer will not be
    able to walk with some purpose in the metric lanscape.

    The stochastic nature of MI is what makes it a natural
    target for Evolutionary algorithms instead of
    gradient-descent like algorithms.



FYI
The plots in the SoftwareGuide are not averaged.


Note that there is some negative feedback here, for example
if your transform was jumping all over the place, that
certainly didn't help the metric to provide a continuous
plot. At the same time, if the metric is changing rapidly
from one iteration to the next, that will induce very unstable
transforms too. This may also be an idication that your step
length or learing rates are too high and that you are tryinig
to jump too far along the direction of the gradient.



Things that you can do for getting smoother metrics are:

A) Smooth the images before passing them into the
    registration process.

B) Intensity windowing them in order to focus on the
    intensity range that you think will contribute the
    best to the alignment of the images.



   Regards,



      Luis



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

> 
> Dear luis
> 
> 
> i thought i was initializing the transform, anyway maybe in an older 
> version!
> 
> 1. the odd thing is that with the MI image 2 image metric and the 
> gradient descent i was getting results... I just want to check the 
> Mattes metric too)
> 2. well it seems the MIMRegistrator.txx in MultiResMIRegistration 
> application does not initialize the transform too
> ( i am just pointing this out incase you would like to make any changes)
> 3. as i pointed out i dont use the CenteredAffineTransform because I use 
> the MultiResMIRegistration application
> 
> in the MIMApplicationBase.txx you find the following lines of code:
> 
> -----------------------MIMApplicationBase.txx----------------------------
> /***************************
> * Compute overall transform
> ***************************/
> // compose the preprocess and registration transforms
> m_Transform->SetIdentity();
> m_Transform->Compose( m_Preprocessor->GetPostTransform(), true );
> m_Transform->Compose( m_Registrator->GetAffineTransform(), true );
> m_Transform->Compose( m_Preprocessor->GetPreTransform(), true );
> 
> 
> 
> -----------------------MIMApplicationBase.txx (section end) 
> ----------------------------
> 
> where the GetPreTransform()
> returns a transform from the MIMPreprocessor.txx which all it does is to 
> center the images :
> 
> -----------------------MIMPreprocessor.txx----------------------------
> typename AffineTransformType::MatrixType matrix;
> typename AffineTransformType::OffsetType offset;
> 
> typename CentererType::Pointer centerer;
> typename NormalizerType::Pointer normalizer;
> typename PermuterType::Pointer permuter;
> typename FlipperType::Pointer flipper;
> 
> // Process the fixed image
> centerer = CentererType::New();
> normalizer = NormalizerType::New();
> 
> centerer->CenterImageOn();
> centerer->SetInput( m_InputFixedImage );
> 
> normalizer->SetInput( centerer->GetOutput() );
> normalizer->Update();
> m_OutputFixedImage = normalizer->GetOutput();
> 
> m_PreTransform->SetIdentity();
> 
> -----------------------MIMPreprocessor.txx (section end) 
> ----------------------------
> 
> i saw that the centered affine transform has 
> CenteredAffineTransformInitializer class
> is cant find something similar with the Affine Transform...
> 
> 
> 4. could you please tell me how should i initialize my affine transform 
> ( i could try to have a CenteredAffine again but this would render the 
> existence of the Preprocessor class as
> excessive and unuseful.. ( i think! ) ... should i give it a try just 
> because of the fact that the Centered Affine has an initializer? )
> (i ll try also to *guess* the values with the method you ve described
> 
> 5. and finaly something else...
> i ve tried the MI image 2 image metric with the gradient descent 
> optimizer and registered an MRI volume against an Optical Tomography 
> volume.
> The registration was close to the optimum however the graph of 
> iterations - metric values was very noisy.
> When i say noisy is that the final metric value was something like 2 or 
> 3 points bigger (well this is not the greates maximization ever...)
> than the first and throughout the graph the metric values change 
> drasticaly from negative to positive... however as i said
> the moving Image has undertaken substantial deformation (affine) to 
> match the fixed one...
> 
> is this normal? the plots you have in the itk guide are somehow 
> averaged? for example 2000 iterations find average of the first 50 then 
> next then next etc..?
> 
> 
> I really look forward to get some advices for 4 and 5, the first 3 are 
> just observations!
> thanks again and sorry for the multiple emails!
> christos
> 
> 
>>
>>
>> B) About the exception you are getting:
>>
>> " Too many samples map outside moving
>> image buffer: 50703 / 360448 "
>>
>> It means that the Affine transform that maps the moving
>> image is not generating enough overlap with the fixed
>> image.
>>
>>
>> I couldn't find in your code, where you are initializing
>> the AffineTransform. I would have expected something like:
>>
>> m_AffineTransform->SetIdentity();
>>
>> (maybe I missed it...)
>>
>>
>> Even better than that, I would strongly suggest you to use
>> the CenteredAffineTransform and the CenteredTransformInitializer.
>>
>> This initializer will take care of matching the image centers,
>> by taking into account their respective origin, pixel spacing
>> and number of pixels along every dimension.
>>
>>
>> The fact that you are not even getting the first GetValue()
>> result, lead us to suspect that you simply have a poor initialized
>> transform. Note that Identity is not neecesarily a good
>> initialization. It depends on the origin and pixel spacing of
>> both of your images. A fundamental exercise that you should
>> perform before even starting your registration is to draw in
>> a piece of paper the physical extent of both images in a common
>> coordinate system. This will give you a clear idea of what
>> your initialization should be for the transform. This is illustrated
>> multiple times in the "resampling" section of the SoftwareGuide.
>>
>>
>> A similar effect can be obtained by simply taking a resample
>> image filter, feeding it with an itk::IdentityTransform and
>> mapping the Moving image into the Fixed image space. That
>> will give you a clear view of the current spatial relationship
>> between the two images.
>>
>>
> 
>