Hi Torsten and Gregory
 
I have a question about setting the maximum optimizer step size  (e or ---max-stepsize, for registration and registrationx respectively):
 
1) even though I set this value to 53 (units of my images are um), I find some bad registrations where the image moves more than that (mostly in X or Y). so I was wondering if I am missing something on what this variable means? and how to really set the upper limit for XYZ translation?
 
Thanks
 
Diego

Dear Diego,

registration(x) are the affine/rigid registration command line tools. These are only being used to calculate the initial affine registration for your brains. It is important that this initial registration is good, so that the nonrigid step has a good starting point, but is probably not a big issue for you. You can check by reformatting the initial affine image (munger with switch -l a will do this).

It is most likely the second registration step (warp) where you may need to adjust the spatial scale. You can do this by controlling two kinds of factor:

--grid-spacing , -g Control point grid spacing

--exploration , -e Search space exploration (initial step size)

(and possibly other related optimisation parameters).

The larger the grid spacing, the larger the non-rigid displacements that are allowed. The larger the exploration, the the larger the initial step size. exploration should usually be less than half the grid spacing. You could potentially increase the initial grid spacing for your images. If you are using munger they default to 40 and 16, respectively. You could perhaps double these from what you say.

Best,

Greg.

Hi Greg
 
Sorry I was not that specific. I am referring to just the affine/rigid registration (so the functions: registration(x)). if I set the exploration to a given 'k' value, it means that the translation in X, Y or Z explored is just equal or less than k right?. if so, I am puzzle why some affine registrations could allow an absolute translation greater than 'k'.
 
Diego

The maximum step size is the largest individual step during optimisation but many steps can be taken. Furthermore constraining the absolute displacement does not seem an obvious thing to do in affine transformation (where e.g. rotation can introduce very large displacements). The absolute displacement makes much more sense for the non-rigid step.

Have you tried reformatting the image after the initial affine in your problem cases? Is it clearly wrong? If so you should maybe think about other ways to set up the initial affine manually e.g. via some kind of landmarks or surface-based registration.

I see, It make sense now why I can get displacements greater than the exploration value.
 
I looked at the reformatted images and yes they are just bad (either a bad scaling or have a very high X, Y or Z displacement from the reference image).
 
Out of curiosity, I tried running the affine with either registration or registrationx for all my floating images (keeping all the parameters constant). When using either registration(x), I get some brains with bad registrations, however the instances where a bad registration happened with either function do not overlap, letting me choose the good ones from either.

That�s interesting. Torsten will have to comment on the differences between the registration and registrationx default parameters. I don�t believe they are doing anything different under the hood.

Actually, registration and registrationx *are* doing slightly different things under the hood. That's why the no-x version never disappeared as had I originally intended.

In short, the x-version was a more mathematically "correct" implementation of the multi-resolution algorithm. The original, non-x implementation had taken a number of shortcuts to speed things up when CPUs were still fairly slow. As an example, it would precompute histogram indexes from all pixel intensities (mostly for use with entropy-based metrics such as Mutual Information, but also used otherwise). It would then do interpolations on these indexes, rather than on the original intensities, thus saving the floating point operations that would have been needed to convert interpolated intensities to histogram indexes over and over.

Now, the x-version did away with all these shortcuts in the hope that it would deliver more precise results. Unfortunately, it turned out that it lost some robustness in the process, presumably because the aforementioned shortcuts had the side effect of smoothing the optimization problem and getting rid of some local minima.

So it's not unexpected that the two versions would give different results, with each better in some cases that the other, since that's exactly why there are still two versions in the first place.

All this pretty much applies analogously to warp and warpx.

I have a feeling none of this really helps anyone, but I am glad we finally got to talk about all this :)

Torsten

As a side note, you could also try using different initialization for the iterative registration.

In registrationx, look at the "--init" command line option.

For registration, you could use the make_initial_affine tool to create an initial transformation, which registration would then either take directly as an argument instead of the two images, or using the --initxform option.

Torsten

Hi
 
I tried the different initial affine types, and the fov-based one performs better for my dataset.
 
I see, so they actually do things differently. I guess I will just keep trying both and selecting the best one from each.
 
Thanks
 
Diego