[MINC-users] minctracc/masking bug?

Fri May 10 12:07:00 EDT 2013

Hi Claude,

Thanks for the tips. The data I am working on are also histology data;
unfortunately I need to work with masks as the histology doesn't
always have full coverage, and without the use of a mask the
deformation will just stretch things to fit the target. In any event I
am less concerned about the fact that there are tricks to be played
with the mask, as you suggest; and I can understand how different
masks could cause uncontrolled deformations.

However I am very concerned about the asymmetry of the deformation; to
answer your first question: the source-, -target, and -mask images I
am using are all perfectly symmetric, both in terms of FoV (voxel
extent) as well as in world coordinates (about x=0); all have the same
resolution as well. If I flip them about x=0, I get exactly the same
result. The image I posted is the result of a single call to minctracc
by the way, so no iterative process or autocrop was involved. In fact
if I run a series of registration steps (some 'usual' scale-space
series), the effect compounds at every step, and I get things like
what you see in this image:

https://dl.dropboxusercontent.com/u/5709165/test_minctracc2.jpg

Top row is the final resampled source image; 2nd (and last) row is the
target; the rows going down are a series of steps with reducing
FHWM/etc. Regardless of the quality of the warp itself, it shouldn't
be asymmetric like this, given that the input data are symmetric. By
the way, another interesting tidbit: if I reverse the direction (swap
source and target), the deformation behaves much better.

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.

-- A

On Thu, May 9, 2013 at 11:31 PM, Claude LEPAGE <claude at bic.mni.mcgill.ca> wrote:
> Alex,
>
> You got me curious here.
>
> If you mirror your image in x (param2xfm -scales -1 1 1) and perform
> the registration to the (symmetric) model, do you still observe the
> same bias? Has the bias been mirrored? Mirror the mask as well.
>
> I don't know if this can be related, but autocrop causes a shift in
> world coordinates. If this shift can be in autocrop, it can be in
> other minc tools. To keep it simple, use autocrop -isostep 0.5
> on a file of labels. You will see that the xspace:start position is
> the same before and after. However, the start position is centroid
> based in voxel space. If the new voxel is 0.5mm instead of 1mm, its
> centroid will be shifted 0.25mm to the left. The formula to preserve
> world coordinates is:
>   new_start = old_start - 0.5*old_voxel_size + 0.5*new_voxel_size
>
> Now, let's say you are resampling a displacement field from a 4mm grid
> to a 2mm grid...
>
> For my work on the bigbrain (histology at 10 microns), I have the
> following notes in my alignment script for non-linear registration:
>
> # 5 - Non-linear alignment of current histo_mid to average position
> #     avg_id.mnc of id_prev and id_next. NEVER use a mask because
> #     it will cause misregistration near borders where the target
> #     mask differs from the source slice.
>
> # 7 - Full non-linear transform from original histo_mid to avg in previous step.
> #     NOTE: Do NOT use a mask here with -init_xfm. There is a BUG in minctracc.
>
> Here, the slices are pre-masked, but I don't use a mask during
> registration. minctracc evaluates the displacement field everywhere
> in the field of view. In the rare cases I use a mask, I use only the
> target mask (without source mask) and I activate the mask only on
> the smallest grid. I don't remember the details for this approach,
> but I do remember that I had to do this for minctracc to be reliable.
>
> Claude
>
>> Hi Andrew,
>>
>> In this particular set of tests I had adapted the minctracc
>> parameters, but I also usually scale the brains up to roughly human
>> size (by the way, the mice down under must be really tiny, or the
>> humans very large - I always use a scale of ~12x for mouse-growing (in
>> each dimension)). However I tried the same registration after scaling
>> using a vanilla nlfit series, and got very similar results.
>>
>> The mask size definitely has an impact here; if I grow the mask, at
>> some point the problem will by-and-large go away. There also appears
>> to be a strong dependency on the grid step size; various experiments
>> still running.
>>
>> When you mention a bias, are you talking about a directional bias?
>> Because that is what I see coming back in all my experiments - and it
>> has me rather concerned as a consistent directional bias in image
>> deformation would likely cause bias in population analyses, especially
>> for anybody looking at L/R differences. I suppose one solution to this
>> would be to run all deformations twice, once 'normal' and once
>> 'flipped'; but ideally this wouldn't be necessary (and I suspect not
>> many people are actually doing this).
>>
>> -- A
>>
>>
>> On Wed, May 8, 2013 at 10:41 PM, Andrew Janke <a.janke at gmail.com> wrote:
>> > Hi Alex,
>> >
>> > To add to Claudes suggestions.
>> >
>> > I see you are using mouse data, have you scaled the mouse data to
>> > "human" size (~ x30) or have you modified all the parameters of
>> > minctracc? If the second any problem you see will be exacerbated by
>> > constants.
>> >
>> > From all the tests I have done over the years, minctracc does have a
>> > very small undershoot and consistent bias. This is an artifact of the
>> > way the minimisation works but is usually very very small and not a
>> > problem. (thus my comments on scale).
>> >
>> > I think your mask is too tight to use as a fit mask as you loose all
>> > the nice edge information. Once the data starts heading off the edge
>> > of the mask, minctracc has no idea where it is as it's no longer
>> > factored into the minimsation function. Perhaps pre-mask your data
>> > (with a blurred edge) and then fit using an expanded mask (5 or so
>> > voxels? with mincmorph) such that minctracc can benefit from the edge
>> > information.
>> >
>> >
>> > a
>> >
>> >
>> > On 8 May 2013 13:28, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
>> >> Hello all,
>> >>
>> >> I have been chasing some strange behaviour of minctracc, and finally
>> >> narrowed it down to something that I would say is a bug in the way
>> >> minctracc deals with masks.
>> >>
>> >> I have generated symmetric (about x=0), blurred source- and target images,
>> >> and a mask derived from the target image by a simple threshold (and thus
>> >> also symmetric). If I run minctracc to register these two without masks, I
>> >> end up with a deformation field that is by and large symmetric as well.
>> >> However if I add the symmetric mask via the -model_mask option to an
>> >> otherwise identical minctracc call, the resulting deformation becomes
>> >> highly asymmetric, and drags the source image out. I am using mni_autoreg
>> >> 0.99.6, libminc 2.1
>> >>
>> >> Summarized in this image:
>> >>
>> >> https://dl.dropboxusercontent.com/u/5709165/test_minctracc.jpg
>> >>
>> >> Row 1: source image
>> >> Row 2: target image
>> >> Row 3: target mask
>> >> Row 4: deformation field magnitude without using mask
>> >> Row 5: resampled source image with target mask outline
>> >> Row 6/7: as rows 4/5, but after adding the target mask to minctracc
>> >>
>> >> Clearly the addition of the mask has a strong negative (and asymmetric)
>> >> impact on the registration, while it seems it shouldn't have much of an
>> >> effect at all.
>> >>
>> >> I have actually seen this behaviour before but was never able to pinpoint
>> >> it so clearly. What appears to be happening is that masked registrations
>> >> have a tendency to 'flow out' in a particular direction (towards the top
>> >> right in coronal sections).
>> >>
>> >> Thoughts/suggestions, anyone?
>> >>
>> >> Thanks,
>> >>
>> >> -- Alex
>> >> _______________________________________________
>> >> 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
>> >
>> _______________________________________________
>> 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
>