[MINC-users] minctracc/masking bug?

[Alex Zijdenbos]

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
>