[MINC-users] minctracc bug in lattice generation

[Alex Zijdenbos]

Hi Louis,

In my image examples, the green outline is the bounding box of the data
volume (identical source and target volumes); the red outline is the extent
of the grid_0.mnc file that minctracc produces. I tried the same thing with
an image made up of all ones, and that still shows that the grid lattice
(red) is not centered on the input volume (green):

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

However, if I change the step size of the data volume to be positive (they
were all negative steps), the grid _does_ end up centered:

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

This is with identity direction cosines. So the off-center issue seems to
be driven by negative step sizes (only).

However, the drift in the grid lattice due to non-identity direction
cosines, happens either way, but does change direction with the sign of the
step. With negative step sizes (5 calls to minctracc):

 animation.gif
<https://docs.google.com/file/d/0B5fOtqpIs4sKTkFfbk02UncyMlE/edit?usp=drive_web>

changing to positive step sizes:

 animation.gif
<https://docs.google.com/file/d/0B5fOtqpIs4sKZ3BLdU1HSGMzbms/edit?usp=drive_web>

So, my conclusion at the moment is that minctracc only generates a "good"
grid lattice if the data volume has both positive steps AND identity
direction cosines. Although that does cover the most-used case of
non-linear registration of stereotaxic/MNI/ICBM space data, for any other
data there be dragons.

-- A

On Tue, Nov 11, 2014 at 8:57 AM, D. Louis Collins <louis.collins at mcgill.ca>
wrote:

> 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
>
>
> On Nov 10, 2014, at 11:21 PM, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
>
> > 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
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>