[MINC-users] minctracc/masking bug?

Wed May 22 00:11:59 EDT 2013

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
>>