[MINC-users] minctracc bug in lattice generation

[Alex Zijdenbos]

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?

-- A