minctracc bug in lattice generation, by Alex Zijdenbos

[vfonov]

Hello all,

I stumbled across a fairly significant bug in minctracc's lattice
generation. In short, the world coordinates of the deformation field that
it generates are wrong, especially when the input volume(s) contain
non-standard direction cosines.

First of all, even when an input volume has no (standard) direction
cosines, the resulting grid file is not centered on the target volume:

verify_nodircos.png
https://docs.google.com/file/d/0B5fOtqpIs4sKOUhOVWx1NF9nazQ/edit?usp=drive_web

This is by letting minctracc generate a deformation grid with a 12mm
isotropic step size. You can see that the bounding box of the resulting
deformation grid (red) is not centered on the bounding box of the input
volume (green). The minctracc call here was simply:

minctracc -nonlinear xcorr -step 12 12 12 -iter 1 <in.mnc> <in.mnc>
<out.xfm>

i.e., the volume registered to itself.

Now, when <in.mnc> contains non-standard direction cosines and the call
above is repeated while feeding the xfm of one call, into the next call via
the -transform option:

minctracc -nonlinear xcorr -step 12 12 12 -iter 1 <in.mnc> <in.mnc> <00.xfm>
minctracc -nonlinear xcorr -step 12 12 12 -iter 1 -transform <00.xfm>
<in.mnc> <in.mnc> <01.xfm>
...

something even stranger happens:

verify_iter00.png
https://docs.google.com/file/d/0B5fOtqpIs4sKSms2MVF0d0JNTTQ/edit?usp=drive_web

verify_iter01.png
https://docs.google.com/file/d/0B5fOtqpIs4sKVUNlRkhhZ1FZMTg/edit?usp=drive_web

verify_iter02.png
https://docs.google.com/file/d/0B5fOtqpIs4sKbjViYlF0dzBkdTQ/edit?usp=drive_web

verify_iter03.png
https://docs.google.com/file/d/0B5fOtqpIs4sKckpCUEhGODB0QTQ/edit?usp=drive_web

verify_iter04.png
https://docs.google.com/file/d/0B5fOtqpIs4sKR2NvRUx1MzQtVnM/edit?usp=drive_web

The bounding box of the deformation grid drifts away, and very quickly
falls outside the data volumes - which is a big problem.

I suspect this may not have appeared as an issue yet, as the vast majority
of non-linear registrations probably happen in a standard MNI stereotaxic
space which doesn't have direction cosines; but as soon as you try to
non-linearly register native volumes (that are relatively likely to carry
non-standard direction cosines), you will be affected by this - although it
may go unnoticed, unless you actually look at the deformation fields you
are getting.

Now for fixing this - I stared a while at the code in init_lattice.c, but
had some trouble figuring out the coordinate handling there. Anybody more
familiar with that bit of code?

[andrewjanke]

From Louis:

Hi all,

On centering: The lattice volume is not supposed to be centered on the existing data volume centre. It is centred on the thresholded foreground stored within the data volume. From memory, the default threshold is 5% (or perhaps 10%) of the mean value of the dataset.

In the image you show, the green outline (which I assume to be the grid) is centred on the foreground, so this is working well.

for the dircos issues, this has changed multiple times in the life of minctracc. early on, I had trouble with negative steps and relied on the ICV incorrectly. This was fixed, but I think other bugs were introduced (or made apparent). I generally apply minctracc only to data with identity discos directions. I’ve not been bothered to fix it.

-Louis

[andrewjanke]

Does a test case with no direction cosines look similar but to a
lesser degree? I have probably struck this before with grid files for
use in model generation but got around things by using an approach
like this:

https://github.com/BIC-MNI/minc-widgets/blob/master/gennlxfm/gennlxfm

That is, I always give minctracc an input xfm in order to determine
the bounds of the output xfm.

[andrewjanke]

From Alex:
I see. No - if the volume(s) have no direction cosines, the 'drift' in the
deformation grid lattice does not happen (at all). In that case the only
problem is that the grid is not perfectly centered on the (target?) volume,
but it stays in place during multiple calls to minctracc.

By the way, if the target volume does have direction cosines, they are
inherited by the xfm, and they themselves don't change through multiple
minctracc invocations.