[MINC-users] minctracc bug in lattice generation

[D. Louis Collins]

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