[MINC-users] mincresample and linear 'deformations'

[Andrew Janke]

Note that xfm2def does not have to calculate the sampling of the grid
from the input volume. You can define this output grid transform
sampling however you choose. This will solve your current problem, but
not all problems like this as the input xfm can be any xfm, which
itself may have a defined sampling (eg: def grid)

I'd argue that what you are seeing is correct behaviour, I use this
feature of mincresample regularly when doing resampling of large (TB
scale) microscopy data. In this case you perform the registration on
chunks and then perform some magic to smoothly interpolate the
resulting deformation grids at the edges. Move edges, repeat, iterate.


a

On 18 August 2016 at 08:05, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> 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
>>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users