[MINC-users] mincresample and linear 'deformations'

Alex Zijdenbos zijdenbos at gmail.com
Wed Aug 17 18:05:44 EDT 2016


Thanks, Louis, Vlad!

I was getting to the same conclusion as Vlad's explanation; but that still
leaves me with the problem that two conceptually the same operations
generate very different output:

1) voxel-wise transformation inversion fails (due to lack of support) => 0
deformation => insert source image value
2) voxel-wise transformation ok/no inversion needed, points outside input
image => insert 0 (or fill value).

Not sure how to deal with this, unless by adding an option to mincresample
that would insert a 0 (fill value) when the transformation inversion fails,
as opposed to treating that as '0 transformation'. E.g., -fill_def_missing
or some such.

Alternatively, pad or transform the deformation grid lattice to allow for
the inversion to work?

-- A



On Wed, Aug 17, 2016 at 5:24 PM, Vladimir S. FONOV <vladimir.fonov at gmail.com
> wrote:

> xfm2def samples forward deformation in the space of input image.
> Then when you apply the transformation, mincresample will try to calculate
> the inverse (numerically) in the space of output image.
> So, if your transformation is a shift of 30mm the forward transformation
> will have the same vector everywhere. However when inverse is calculated,
> mincresmple will reach the edge of the domain where vectors are defined and
> will take value of 0 for the translation outside of this domain - that's
> why you have a sudden jump in the result.
>
> However, if you invert the original affine transformation,  and sample it
> for every voxel and then invert again (applying xfminvert to a non-linear
> transformation doesn't actually recompute the transform, only adds a flag
> that it have to be inverted), then when mincresample will run, it will
> again apply the inverse of the transform, on top of inverted transform ,
> negating the need to actually numerically recompute the transformation.
>
>
>
> On 2016-08-17 04:30 PM, Alex Zijdenbos wrote:
>
>> Right - I am aware of that, but I don't think that explains any of this
>> though?
>>
>> On Wed, Aug 17, 2016 at 3:21 PM, Vladimir S. FONOV <
>> vladimir.fonov at gmail.com
>>
>>> wrote:
>>>
>>
>> When you apply "simple" forward transform, mincresample have to invert it
>>> internally.
>>>
>>> On Wed, Aug 17, 2016 at 1:50 PM, Alex Zijdenbos <zijdenbos at gmail.com>
>>> wrote:
>>>
>>> These were simple forward resamplings. I experimented a bit with various
>>>> sequences of inversions, and found that this process:
>>>>
>>>> xfminvert( xfm2def( xfminvert( lin.xfm )))
>>>>
>>>> Yields a deformation grid that I can use in a forward resampling call
>>>> and
>>>> have it produce the same result as resampling using lin.xfm directly.
>>>>
>>>> Well I am puzzled.
>>>>
>>>> -- A
>>>>
>>>> For some more details, I tried these steps. Starting with
>>>>
>>>> param2xfm -translation 10 20 30 lsq3.xfm
>>>> mincresample -use_input_sampling -transform lsq3_D.xfm in.mnc res.mnc
>>>>
>>>> I had done this:
>>>>
>>>> xfm2def -float [lattice from input volume] lsq3.xfm lsq3_D.xfm
>>>> mincresample -use_input_sampling -transform lsq3_D.xfm in.mnc res_D.mnc
>>>>
>>>> which "fails". Similarly, this:
>>>>
>>>> xfminvert lsq3_D.xfm lsq3_D_inv.xfm
>>>> mincresample -use_input_sampling -transform lsq3_D_inv.xfm -invert
>>>> in.mnc
>>>> res_D_inv.mnc
>>>>
>>>> reproduces res_D.mnc (the "bad" result). Note that the xfminvert call in
>>>> this case only sets the "Invert" flag in the xfm, it doesn't actually
>>>> invert the deformation field. But now, this:
>>>>
>>>> xfminvert lsq3.xfm lsq3_inv.xfm
>>>> xfm2def -float [lattice from input volume] lsq3_inv.xfm lsq3_inv_D.xfm
>>>> mincresample -use_input_sampling -transform lsq3_inv_D.xfm -invert
>>>> in.mnc
>>>> res_inv_D.mnc
>>>>
>>>> Exactly reproduces res.mnc (the "good" result). So inverting the linear
>>>>
>>> xfm
>>>
>>>> first, then converting it to a deformation and resampling with
>>>> inversion,
>>>> somehow does the right thing. Then this:
>>>>
>>>> xfminvert lsq3.xfm lsq3_inv.xfm
>>>> xfm2def -float [lattice from input volume] lsq3_inv.xfm lsq3_inv_D.xfm
>>>> xfminvert lsq3_inv_D.xfm lsq3_inv_D_inv.xfm
>>>> mincresample -use_input_sampling -transform lsq3_inv_D.xfm in.mnc
>>>> res_inv_D_inv.mnc
>>>>
>>>> also does the right thing.
>>>>
>>>>
>>>> On Wed, Aug 17, 2016 at 12:28 PM, Vladimir S. FONOV <
>>>> vladimir.fonov at gmail.com> wrote:
>>>>
>>>> It looks like it's a problem of finding an inverse of the
>>>>>
>>>> transformation
>>>
>>>> outside of the domain where it's defined.
>>>>>
>>>>> When you apply the transform do you apply it directly or with
>>>>> -invert_transformation ?
>>>>>
>>>>>
>>>>> On 2016-08-17 11:54 AM, Alex Zijdenbos wrote:
>>>>>
>>>>> Hi all,
>>>>>>
>>>>>> I was always under the impression that one could turn a linear xfm
>>>>>>
>>>>> into
>>>
>>>> a
>>>>
>>>>> deformation field (using xfm2def), and that the application of the
>>>>>> resulting deformation would be equivalent to using the linear xfm.
>>>>>> However,
>>>>>> mincresample disagrees.
>>>>>>
>>>>>> In the attached image, I've created a simpe lsq3 (param2xfm
>>>>>>
>>>>> -translation
>>>
>>>> 10
>>>>>> 20 30) linear xfm, generated a 'deformation' field out of that using
>>>>>> xfm2def (same lattice as the input volume), and resampled the input
>>>>>>
>>>>> volume
>>>>
>>>>> with both xfms. Clearly, in the case of a 'deformation' xfm, the
>>>>>>
>>>>> volume
>>>
>>>> is
>>>>
>>>>> filled with unmodified voxels where I didn't expect them.
>>>>>>
>>>>>> This is tied to the sampling lattice of the deformation field, which
>>>>>>
>>>>> in
>>>
>>>> this example is the same as the input volume. The resamplings are done
>>>>>> using -use_input_sampling btw. The two bottom rows show the resampling
>>>>>> using a padded input volume (no change), and using a 'deformation'
>>>>>>
>>>>> grid
>>>
>>>> with a larger extent (generated on a lattice that is 10 voxels larger
>>>>>>
>>>>> all
>>>>
>>>>> around).
>>>>>>
>>>>>> To pre-empt Vladimir, itk_resample behaves the same way ;-)
>>>>>>
>>>>>> Bug, or feature? I'd say the former.
>>>>>>
>>>>>>
>
> --
> Best regards,
>
>  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


More information about the MINC-users mailing list