[MINC-users] minctracc/masking bug?

Fri Jan 31 17:10:02 EST 2014

Hello all,

Reviving an issue I raised last year, that I believe we have now fixed
(thanks to François Hébert and Andrew Wood!). To summarize, for a long time
we've been plagued by minctracc's tendency to favor positive directions
along the parameter space dimensions. This affects both linear- and
non-linear registration; for the linear registration this results in biases
with respect to orientation; for the non-linear, this results in a tendency
to 'inflate' towards positive directions (as a result of which, by the way,
I believe that any studies of brain asymmetry using minctracc, or any kind
of sidedness in fact, are suspect).

The cause turned out to be in the initialization of the simplex/amoeba
optimization, which always initializes itself towards the positive end of
the parameter axes, at line 270 of
amoeba.c<https://github.com/BIC-MNI/mni_autoreg/blob/master/minctracc/Optimize/amoeba.c>.
This results in an inherent bias of the optimization in those directions.
We have fixed this by also evaluating the mirrored (negative) starting
position along each axis, resulting in a directionally unbiased amoeba
initialization.

To illustrate the effect and fix, I generate 3 animated gifs as examples.
Each of these flip between 'old' and 'new' (make sure the viewer you use
speaks animated gif):

1. human_average_lin<https://www.dropbox.com/s/hn45jqmisby9h8v/asym_avg.gif>:
linear average of ~100 scans. You will see the tendency of the 'old'
towards more positive rotations and translations

2. human_single_nonlin<https://www.dropbox.com/s/bidmbzmjt77jm2l/verify.gif>:
single subject; you will see the asymmetric 'blowout' of the resampled
image.

3. mouse_single_nonlin<https://www.dropbox.com/s/54ae54wh4zex4v1/verify_mouse.gif>:
single mouse. In this case, both the source- and target images are
symmetric about x=0, so one would expect a symmetric deformation field as a
result. The bottom row shows the deformation magnitude of the transform,
clearly showing its asymmetry with the old minctracc, versus the symmetric
def with the patched amoeba.c.

Andrew Wood will submit the updated code next week.

Have a good weekend!

-- Alex

On Wed, May 22, 2013 at 12:11 AM, Alex Zijdenbos <zijdenbos at gmail.com>wrote:

> OK, by popular demand, I generated some data and wrote a simple script
> that illustrates the issue discussed here. Although I have already
> seen that masking can have a drastic impact on the deformation
> asymmetry, this example keeps it simple by not using masks, nor
> blurring; it uses a simple and single minctracc call, with 1
> iteration.
>
> Here is the tarball:
>
>    https://dl.dropboxusercontent.com/u/5709165/MINC/SymTestDist.tar.gz
>
> To run the experiment:
>
>    tar zxvf /home/alex/pchome/Scratch/SymTestDist.tar.gz
>    cd SymTestDist/
>    ./run_sym_test.pl -tmpdir tmp image.mnc model.mnc resdiff.mnc
> defdiffmag.mnc | tee sym_test.log
>
> This will:
>
> - register image.mnc (asymmetric) to model.mnc (symmetric)
> - register them again after flipping both image.mnc and model.mnc about x=0
> - flip the flipped resampled image and the flipped deformation field back
> - generate the subtraction of the two resampled files (resdiff.mnc)
> - generate the magnitude of the difference between the two deformation
> fields (defdiffmag.mnc).
>
> In an ideal situation, both output files would be 0; any non-zero
> values in these two output files indicate a methodological asymmetry
> in the deformation field that minctracc generates. You can in fact
> obtain "perfect" (0, barring some slice scaling) output by registering
> model.mnc to itself. However, as another test, use model_0.99.mnc as
> the source image; this is model.mnc shrunk a small amount by scaling
> it by 0.99 in all dimensions. You will see that the asymmetric
> behaviour immediately shows up even in this case.
>
> -- A
>
>
>
> On Tue, May 21, 2013 at 12:05 PM, Alex Zijdenbos <zijdenbos at gmail.com>
> wrote:
> > Hi Vlad,
> >
> > I simply flipped the grid file itself (resample it with $flip,
> > essentially), so without going through xfmconcat and xfm2def. Just to
> > be sure I just tested this on one case, and the results of your
> > process and simply flipping the grid file are identical.
> >
> > As for the asymmetry, I will pursue this further following Andrew's
> > suggestions as well; I'll try to narrow it down to something simple
> > that I can easily share.
> >
> > -- A
> >
> > On Tue, May 21, 2013 at 10:28 AM, Vladimir S. FONOV
> > <vladimir.fonov at gmail.com> wrote:
> >> What is the procedure that you are using for flipping the grid file ?
> >>
> >> The way how I am doing it in my symmetric model building script (
> >> https://github.com/vfonov/build_average_model )  :
> >>
> >> nlfit_s $input $model $tempdir/left_nl.xfm -source_mask $input_mask
> >> -target_mask $model_mask -level $level
> >>
> >> nlfit_s $input_flip $model $tempdir/right_nl.xfm -source_mask
> >> $input_flip_mask -target_mask $model_mask \
> >>      -level $level -work_dir $tempdir
> >>
> >> xfm_normalize.pl $tempdir/left_nl.xfm $tempdir/output_left.xfm -like
> >> $model --step $level
> >>
> >> xfmconcat $flip $tempdir/right_nl.xfm $flip $tempdir/right_nl_flip.xfm
> >>
> >> #make nonlinear only
> >> xfm_normalize.pl $tempdir/right_nl_flip.xfm
> >> $tempdir/output_right_flip.xfm -like $model --step $level
> >>
> >> #average left and right flipped
> >> xfmavg $tempdir/output_left.xfm $tempdir/output_right_flip.xfm $output
> >>
> >> On Tue, May 21, 2013 at 12:07 AM, Alex Zijdenbos <zijdenbos at gmail.com>
> wrote:
> >>> Thanks, Claude - looking at your suggestions (and at the minctracc
> >>> source code). In the mean time, I performed some phenomenological
> >>> experiments that I thought would be interesting to share. Here's what
> >>> I did:
> >>>
> >>> - take 100 subjects, already in linear template (stx) space
> >>> - register these with an nlfit*-like process, up to 4mm grid step
> >>> size, to a symmetric template+mask
> >>> - flip the subject image and its mask about x=0, repeat the
> registration
> >>> - flip the resampled image and the grid from the registration again
> about x=0
> >>> - calculate the magnitude of the difference between the 'normal' and
> >>> '2xflipped' grid (per subject)
> >>>
> >>> - average the 'normal' and '2xflipped' grid files across subjects
> >>> - calculate the magnitude of the difference between the average
> >>> 'normal' and average '2xflipped' grid files
> >>>
> >>> In the end, what I am left with is the asymmetry in the deformation
> >>> field(s) due solely to the registration process; if minctracc were
> >>> unbiased, these difference images would be 0. This image:
> >>>
> >>> https://dl.dropboxusercontent.com/u/5709165/def_diff_mag.jpeg
> >>>
> >>> shows the average of the non-linearly registered images over these 100
> >>> subjects; and the magnitude of the difference of the average
> >>> deformation estimated 'normally' and '2xflipped'. Note that the in
> >>> these population averages, the maximum deformation magnitude is 2.86;
> >>> in individual subjects, the max magnitude of the deformation
> >>> difference is typically in the 10-20 range. In other words, the
> >>> asymmetry in the estimated deformation field purely caused by the
> >>> methodology, can be as high as 20mm.
> >>>
> >>> I'd be very happy if somebody could run a similar experiment, if
> >>> anything on a single subject; just to confirm that I didn't do
> >>> anything fundamentally wrong somewhere (which would be great).
> >>>
> >>> -- A
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, May 10, 2013 at 2:00 PM, Claude LEPAGE <
> claude at bic.mni.mcgill.ca> wrote:
> >>>> Alex,
> >>>>
> >>>>> So far the only explanation I can think of, is that the optimizer
> >>>>> follows a particular/fixed trajectory through the parameter space,
> >>>>> implicitly generating an "expansion force" in a particular direction
> >>>>> that can go unchecked given the right set of circumstances (a
> >>>>> particular mask being one of them). Anyways, still testing different
> >>>>> parameters, will report on what I find.
> >>>>
> >>>> Can you do only 1 iteration of minctracc? Is symmetry preserved?
> >>>> Try this 1 iteration with and without smoothing (set smoothing weight
> >>>> to zero). Still symmetric?
> >>>>
> >>>> Your suggestion above sounds like the result could be influenced by
> >>>> the order of the loops. This is a common mistake in numerical
> analysis.
> >>>> For example:
> >>>>    vec[i] = some_function( vec[i-1], vec[i], vec[i+1] );
> >>>> When you process vec[i+1], the value of its previous neighbour has
> >>>> changed, so running the loop forward/backward gives a different
> answer.
> >>>> You can check the code for something like this (good luck).
> >>>>
> >>>> Have you tried minctracc 0.99.3? Have you tried mincreshape to change
> >>>> the x,y,z ordering? I doubt this will have an impact on the results.
> >>>>
> >>>> Claude
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>
> >>
> >>
> >> --
> >> Best regards,
> >>
> >>  Vladimir S. Fonov ~ vladimir <dot> fonov <at> gmail <dot> com
> >> _______________________________________________
> >> MINC-users at bic.mni.mcgill.ca
> >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >>
>