Greetings,

In our lab, we have been registering brain images for about one year. We follow the published protocols, but still there is natural variation in the quality of results from one attempt to the next.

Usually, we are able to identify accurately ahead of time whether a brain's registration will succeed. If the brain is damaged or rotated, or if the image contains excessive noise, or is very dim, then the registration fails, as expected.

However, sometimes a brain image of relatively poor quality yields a good result, and other times, a brain that seems of reasonable quality fails the registration. For brevity, perhaps one could call them "US" and "UF" for short (unlikely success or failure), and UFs interest me the most because they suggest there are problems with some of our images that we are overlooking.

Based on your experience, which characteristics of the image might be the most important to determine the outcome of the registration?

To help clarify my remarks above, I attached three images: one US, and two UFs. Looking at these, my first thought is that the UFs might not include enough blank slices at the start of the stack before the antenna lobes begin, but I am not sure. I would be curious to hear your opinions and viewpoints, and many thanks.

Update: as the original stacks are too large to include in the post, I am including projections instead. Please let me know if you would prefer to see the stacks, and I will send them to you privately (e.g., via email).

Find attached the second UF. Interestingly, although the entire projection appears washed out, each slice individually in the stack doesn't have that appearance.

Please find attached the example of an unexpected success, which I thought would fail on the basis of insufficient texture and contrast. I am not able to explain the grid-like artifacts running across the image.

I would try to check the parameters of the affine step in each case. Do they look reasonable? Also beware of things like flips in the Z axis slice order.

In my experience an initial failure to get the "pose" correct is the most common cause of failure for otherwise reasonable quality images. You can check if this by looking at the translation/rotation/scale etc parameters in the `registration` output file. You can get round this by providing an initial affine registration that roughly aligns things. If you have very standardised images it may be possible to provide a standard initialisation procedure which is more robust than the default. All the best, Greg.

Thank you for your reply, and I am sorry for the delay on my part. We looked at the commands used for the affine registration, and found that adding the "--auto-multi-levels 4" option seems to have helped increase the success rate.

So far, we haven't experimented with the idea of using a preloaded affine registration, but it sounds useful as a way also of reducing computation time, since most of our images are consistent in size. Does it just mean that we would re-use a registration from one of the successful jobs (perhaps after scaling/rotating/cropping the image in advance to ensure some level of consistency)?

If your images have consistent rotation scale etc you can reuse an existing registration. However if e.g. the rotation can vary then you may need to compute that but it might be quite efficient to do so if you know e.g. that brains are always mounted on their posterior surface with 360 degrees around the Z axis but say only +/-15 around the X axis (chin up or chin down). We used two strategies for initial registrations a Hough transform implemented in Amira. This was very handy but sadly I'm not sure it ever made it out of the Academic version from the Zuse Institute in Berlin. Or surface based mesh transforms in Amira. There are many other surface mesh registrations you could potentially use. So a fancy pipeline might do a marching cubes on a heavily downsampled version of the image. Other ideas would be identifying the plane of symmetry and then using that to define +/- 180 the rotation around the Z axis. You can use the mat2dof tool to convert a general affine transform into CMTK's format.

All the best, Greg.