[Insight-users] Re: MultiResMIRegistration

[Luis Ibanez]

Hi Christos,

Isn't it fun to find good
parameters for registration ?     :-)


----

About your questions:

0)  As you pointed out, the factor is
     a "suggestion". The relative scaling
     between the translations and rotation
     also allows you to control how fast to
     advance in rotation with respect to
     how much to advance in translations.

     Depending on the predominant type of
     mis-registration present in your images,
     different range of factors may me more
     convenient.

     The suggestion is simply a reasonable
     parameter from which you can start the
     fascinating process of fine tunning the
     values for your specific types of images.


A)  There is not an inherent problem with the
     MIMApplicationBase.txx way of computing the
     scaling parameters. This values is a reasonable
     first guess. You may use double of it, or half
     of it and still be able to tune other registration
     parameters in order to make the optimizer converge.


B)  I don't see why you suggest to make the scaling
     equal to  "131748". it seems that you forget the
     sqrt() from your own computation, where you found
     that the scaling should be around 363.


C)  Code doesn't simple work or not work by itself.
     (Algorithms + Parameter) work for particular input
     Data. You will find images for with the 10X magic
     factor will not work, and you certanly will find
     images for which the 1X factor will not work either.

     The notion of "optimal methods" is only applicable
     to the illusory world of "Paper Publishing". Here
     in the real world, we have are subject to observe
     and adapt.


D)  People must play with the parameter scaling, with
     the number of iterations, with the learning rate,
     with the tolerance parameters, with the pre-smoothing
     of the images...

     You may find recomendations for good initial values,
     and after that you must undertand the effect that
     all other parameters have on the optimization process,
     so you can tune their values in order to get better
     results.  There is no magic in registration (or
     segmentation).  The values that you see are just like
     the speed limit in a highway: You better try to keep
     this value, but if you want to survive, sometimes you
     must go faster, sometimes you must go slower.


E)  Mutual Information may be quite counter-intuitive when
     you apply it to trivial data, like the binary images
     that you mention.  What you are asking to minimize is
     the sparseness of the joint histogram. The optimizer
     may end up selecting any transform parameters that lead
     to such minimization. That includes to put all the white
     of the square over all the black of the rectangle and
     viceversa, since in this case you get a diagonal histogram.
     And, although most people would consider that solution a
     dramatic failure of the registration, well, that's just
     a valid result for minimzing Mutual Information.


F)  Good test for the algorithm are the images generated on
     the fly in the Testing/Code/Algorithm subdirectory.
     you will find that most of the Multi-Modality registration
     methods use an image with a Gaussian hill in which a pointy
     spike is added in the center.

     The joint histogram will certainly look like Dirac deltas
     if you apply them to binary images. If you want gradation
     in the histogram you must then provide gradation in the
     gray levels of the input images.

     If you want realistic medical images, simply use the
     BrainWeb images in the ITK ftp Data directory.

     Could you please post the plot that you are obtaining
     for the MI metric with respect to iterations and post
     also the paramters of the transform that you get for
     each iteration ?

     Your description of the plot as a Diract delta is so
     suspicious that it leads to think that something
     fundamentlly wrong may be happening in your
     configuration of the registration problem.


G)  The Derivative values of the Metric returned by the
     GetValueAndDerivative() method will certainly not
     match the derivatives that you may estimate from
     applying finite differences between consecutive
     evaluations of the Metric. What the quoted comment
     means is that before you get too involved judging
     the behavior of the Metric versus number of iterations,
     you must put the iterations in the context of where
     in the parametric space is the optimizer moving.

     That is, a Metric may be called noisy if it produce
     very different results as you move "smoothly and
     continuously" along the parametric space.  However,
     any Metric, will display a noisy pattern when plotted
     against the number of iterations if between every
     iterations the parameters array is jumping long distances
     in the parametric space. E.g. simply arrange a rigid
     transform to rotate by increments of 77 degrees between
     iterations and you would get an apparent noisy Metric plot,
     no matter how smooth the Metric is in reality.


--

If you are still reading...
and still want some fraternal advice,
here is some:

              "Start Simple and
               advance at small increments"

Don't start by looking at the demos in InsightApplications.
This is like trying to understand mechanics by going directly
into a modern diesel engine.

Instead, get familiar with the basic examples in

             Insight/Examples/Registration

Start with the simple ones, those using translation transform,
simple optimizers and simple metrics. Then gain confidence
progressively.

Use them with the images and parameters that are suggested  in
the SoftwareGuide, then perturbe the parameters and get familiar
with the effects of the perturbation. In that way you will
recognize such effects later in more complex situation.

Things as simple as the step length of a gradient descent
optimizer can make a whole difference in succeding or failing
in a registration process. See for example the plots in the
Registration Course:

    http://www.cs.rpi.edu/courses/spring04/imagereg/

In particular in lecture 9:

http://www.cs.rpi.edu/courses/spring04/imagereg/lecture09.ppt




Regards,



    Luis




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

> 
> Dear Luis
> 
> according to a previous suggestion of yours the translation scale in 
> registration of volumes, using ITK should be equal to the following:
> 
> 1.0 / 10 * sqrt(x^2+y^2+z^2) where 10 is a "magic factor"
> and x,y,z are the dimensions of the volume with the largest dimensions
> 
> i have the following two implementation/testing questions regarding the 
> above:
> 
> In MultiResMIRegistration/MIMApplicationBase.txx
> at the end of the .txx file we can find the following lines of code:
> 
>  double scale = 1.0 / vnl_math_sqr( m_Parser->GetTranslationScale() 
> );               m_Registrator->SetTranslationScale( scale );
> 
> 1.first of all the "magic factor" 10x is missing
> 2.from the sample inputs found in the application i would quote for 
> example the SampleInputs/PracPETToPD.txt where the max dimensions are 
> 256x256x26 (the second is 128x128x15)
> 
> however in this sample input file the choice of the translation scale is 
> "320"
> well 256^2+256^2+256^2 = 131748
> and its square root is 362.9711
> its almost like doing sqrt(sqrt(256^2+256^2+26^2))
> 
> 
> anyway the 3 parameters of the transformation matrix which represent 
> translations are set to "scale" as calculated above
> 
> A. is there a problem with MIMApplicationBase.txx way of calculating the 
> scale?
> B. what happens with the sample inputs examples? the input is 320 
> however shouldn't be 131748?
> C. how these examples worked in the first place if there is a problem in 
> the above
> D. well generaly should people play with the translation scale or should 
> it be fixed always to 1.0 / 10 * sqrt(x^2+y^2+z^2) ?
> 
> ---------
> 
> and something else
> 
> well i ve tried the application already in medical data and has given me 
> some good results however i need to test it for simpler examples.
> 
> i ve tried to register a binary cube against a binary paralelogram 
> (background 0, shape (filled) - not just the shell) 255) however the 
> results are almost there
> the cube deforms to something like a sheared paralelogram.
> 
> the above is not a multi-modal registration but the algorithm should be 
> able to cope with it with any choice of optimizer and metric 
> implementation (viola or mattes)
> i ve also tried to "simulate" multi-modality by applying different 
> smoothing-filters to the shapes but i could not get any better results.
> 
> E. could you suggest me some simple tests that i can test the algorithm on?
> F. as you ve told me the mutual info metrics are very noisy. Well they 
> are noisy and most of the time they look like very very dense 
> dirac-functions (even in tests i did on medical data - which worked 
> well). what i plot is the metric->GetValue() vector against iterations.
> 
> is there something else that i could do so i would see the expected 
> curve? i mean for my medical tests - which worked ok,the curve should 
> have looked like an ROC curve (maximization of MI metric) but it looks 
> like dirac, so i cannot really use it to optimize my parameters.
> 
> a recent answer of yours in the above was:
> "Note that you should differentiate if the metric plots are
> noisy because the metric itself is noisy in the parametric
> space or because the path that the optimizer is walking is
> so random that the metric picks values from very different
> locations and therefore generates and uncorrelated pattern
> when you plot metric values versus iterations."
> 
> do you mean the derivative values returned by the 
> getValueAndDerivative() method of the metric?
> 
> 
> sorry for the long post
> thanks again
> christos
> 
> 
> 
> 
> 
> 
>