[Insight-developers] No-Bug in CenteredRigid2DTransform

[Miller, James V (Research)]

> That's a great thing to do for the metrics and the transform.
> In some way, this should be the recommended first approach for
> anybody doing registration. That is, to first get a plot of the
> Image metric as function of the transform parameters, for a large
> enough range of the parameters.  Such a plot is fundamental in
> figuring out the characteristics of the cost-function to be
> optimized during registration.  Is from this plot that we could
> talk about noise, capture radius and stability. The only difficulty
> is to represent this for transform having more that three parameters
> since we deal with a high dimensional function...
> 
> 
> 

Perhaps this should be part of the "theory" book.


Given the parameters yield such a high dimensional problem, I am
attacking this a different way.  That is to just look E[metric], 
STD[metric] across a some selected subspaces of the transformation
parameters.  So for 2D, look at the E[metric] as a function of 
(tx, ty | theta is fixed), then look at the E[metric] as a function 
of (theta | tx, ty are fixed). 

I am looking the E[metric] and STD[metric] since to begin with I 
am looking at the mutual information metric and its implementation
yields a different metric value if you call it multiple times
using the same parameter settings and same images.  This is due to
the random selection of points to define the pdf of the intensities.
(I imagine the MattesMutualInformationImageToImageMetric would produce
consist values.) Since the pdf can change from call to call of the 
metric, I am running the same (transform x fixed image x moving image)
multiple times to build up the expectations and variances.

You might be able to do this closed form but this was simpler.  The
reason I bring it up is that the time to compute what you are suggesting
is not just the time to sample the parameter space but that parameter
space may have to sampled multiple times.