Hello all,

I am currently trying to register a confocal stack of just over half a brain (http://imgur.com/a/W8iCc#0) to a full and complete reference brain (http://imgur.com/a/W8iCc#1). Attempting to register the images as-is gives a reasonable result, but there are quite a number of imperfections, many of which have large deformation errors. As such, I thought I'd try to 'help' the process by removing some of the more problematic areas that we're not interested in (http://imgur.com/a/W8iCc#2 and http://imgur.com/a/W8iCc#3) by simply deleting regions in ImageJ (i.e. setting the pixel values to 0). However, this obviously creates sharp edges at the boundaries between the original image data and the regions that I've removed, and this seems to drastically mess-up the registration process, to the point where reformatted images are empty.

Is there any way to pass a mask into the registration procedure, or an alternative that would have the same effect? If not, would I be best off adding Gaussian noise, centred on the average background level of the original image, to the edited images to try and reduce this problem?

Thanks,
Ashley

Hi Ashley -

CMTK's registration tools allow you to designate one value in your image as "padding" marker. The relevant paremeters for registration(x) and warp(x) are "--pad-ref VAL" for the reference (fixed) image and "--pad-flt VAL" for the floating (moving) image. In either case, "VAL" is a value to be considered as "missing" data rather than as a data value itself.

In images stored as floating points, infinite values ("Inf") are always considered "missing."

The effect of using padding is that the pixels with the given passing value are truly excluded from all computations, i.e., they do not go into any interpolations (when used in the floating image) and they are removed from the set of pixel pairs considered for similarity computation (when used in the fixed image).

As for selecting the padding value for a given image, it is usually a good option to simply use "-1", assuming your images don't have any negative values to begin with. (If your image is already the result of, say, a cubic spline or sinc interpolation, then you may have introduced negative values that way, so beware).

Now here's the problem though - using padding to exclude image regions *may* improve your registrations, but it is by no means guaranteed to. It usually works rather well with linear (affine, rigid) registration, but in my experience doesn't help much when used in nonlinear registration. The problem is that by excluding data, you create opportunities for the registration algorithm to make "inconvenient" data disappear by moving it into areas mapped to/from padded pixels. Unfortunately, the registration appears to consider essentially all data "inconvenient", so often things simply disappear altogether.

Further notes - other CMTK tools also support padding, e.g., "convertx" will fill masked-out areas with the padding value ("--set-padding VAL"), and there are also two threshold-to-padding operations. Likewise, "reformatx" allows you to use padding in both the floating image ("--pad-floating") and, separately, in the output image ("--pad-out").

Hope this helps.

Best,
  Torsten

One more thing - when using padding in registration, try using it for only the fixed, only the moving, and both images, to the degree that this makes sense in your application. Sometimes one option works rather much better than the others (using padding in both images is probably the least likely to work).

TR

Thanks, Torsten, that did the trick — the reformatted images are no longer empty. However, as you said, the registration isn't improved much.

Actually, one more thought on this...

It is usually better to use padding in the reference than in the floating image. That's because then the number of padded pixels and their relative weights do not change dependent on the transformation between the images.

When you compute a nonrigid transformation, you don't usually have a choice what image to select as the fixed image, but if/when you are computing an affine or rigid transformation, you can select its direction to work well with padding, then later use its inverse for reslicing etc. (Better to do this with "registrationx" rather than "registration" because by default the latter will switch reference and floating image to optimize speed.)

TR