From gdevenyi at gmail.com  Tue Aug  2 14:24:32 2016
From: gdevenyi at gmail.com (Gabriel A. Devenyi)
Date: Tue, 2 Aug 2016 14:24:32 -0400
Subject: [MINC-users] Segmentation: Handling poor T1 contrast?
Message-ID: <CAFQOoOrd4rtK821V0RagFApCssE7tEyKiNhzKipWFY6Ueq7+-Q@mail.gmail.com>

Hi all,

I was wondering if anyone could recommend any tricks to deal with T1 scans
with poor contrast (likely due to inappropriate T1 parameters?). I'm trying
to do some grey/white segmentation and the lack of contrast is causing
issues.

Thanks!

--
Gabriel A. Devenyi B.Eng. Ph.D.
Research Computing Associate
Computational Brain Anatomy Laboratory
Cerebral Imaging Center
Douglas Mental Health University Institute
Affiliate, Department of Psychiatry
McGill University
t: 514.761.6131x4781
e: gdevenyi at gmail.com

From gdevenyi at gmail.com  Wed Aug  3 15:13:30 2016
From: gdevenyi at gmail.com (Gabriel A. Devenyi)
Date: Wed, 03 Aug 2016 19:13:30 +0000
Subject: [MINC-users] Minc Flood Fill
In-Reply-To: <CABApf9HOHicHtvwYwQodoE5WFnzjPJW887hU7GoG2-pFHHdG+Q@mail.gmail.com>
References: <CABApf9HOHicHtvwYwQodoE5WFnzjPJW887hU7GoG2-pFHHdG+Q@mail.gmail.com>
Message-ID: <CAFQOoOo00mxM_3yjCss=wFEm1-YVF7DDjH6xhbCXZ3AjhYcbDA@mail.gmail.com>

ANTs has some fill through masks functionality in ImageMath, which might be
what you're looking for. Its included with minc-toolkit-v2



On Mon, Jul 25, 2016, 14:01 Andrew Wood <andrew at biospective.com> wrote:

> Hi all,
>
> I'm wondering if a minc tool exists that can do a flood fill operation. It
> would take:
>   1) an image
>   2) a label volume, defining seed regions
>   3) a threshold, defining the "aggressiveness" of the fill
>
> Display can do it ("set threshold" and "label fill" in the Segmenting
> menu), but of course requires a human user; I was hoping for a tool that
> could be used in an automated pipeline.
>
> Thanks,
> Andrew
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From abrouse at neurorx.com  Wed Aug  3 15:53:46 2016
From: abrouse at neurorx.com (Andrew Brouse)
Date: Wed, 3 Aug 2016 15:53:46 -0400
Subject: [MINC-users] status of MINC in BREW on El Capitan
Message-ID: <F443E3EB-93EF-4E41-9102-5DD4B90702BC@neurorx.com>

Hello folks,

I am wondering whether anyone can provide some clarity about the status of the MINC tools in the BREW environment on macOS 10.11 going forward.

I see there are formulae available:

?
abrouse% brew search minc
homebrew/science/libminc ?                            homebrew/science/minc                                 homebrew/science/minced 
?

I have managed to install libminc but minc will not compile on 10.11.6:

?
MINC executables can't find libhdf5.9.dylib https://github.com/Homebrew/homebrew-science/issues/2751
minc does not compile on OS X 10.11 El Capitan https://github.com/Homebrew/homebrew-science/issues/2927 <https://github.com/Homebrew/homebrew-science/issues/2927>
?

There is some info here:
https://github.com/Homebrew/homebrew-science/issues/2927 <https://github.com/Homebrew/homebrew-science/issues/2927>

but even that is already a bit stale...

thanks for any help,
Andrew

Andrew Brouse
System Administrator
NeuroRx Research
3575, av. du Parc #5322
Montr?al, QC, H2X 3P9
Canada

t: +1-514-906-3909 x333
e: abrouse at neurorx.com <mailto:abrouse at neurorx.com>

From vladimir.fonov at gmail.com  Wed Aug  3 16:19:23 2016
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Wed, 3 Aug 2016 16:19:23 -0400
Subject: [MINC-users] status of MINC in BREW on El Capitan
In-Reply-To: <F443E3EB-93EF-4E41-9102-5DD4B90702BC@neurorx.com>
References: <F443E3EB-93EF-4E41-9102-5DD4B90702BC@neurorx.com>
Message-ID: <776c6bad-e902-6f63-3c2b-2bf649646b66@gmail.com>

Something like this:

https://github.com/BIC-MNI/minc-toolkit-v2/blob/develop/homebrew/minc-toolkit.rb

However I didn't test for a while.

On 2016-08-03 03:53 PM, Andrew Brouse wrote:
> Hello folks,
>
> I am wondering whether anyone can provide some clarity about the status of the MINC tools in the BREW environment on macOS 10.11 going forward.
>
> I see there are formulae available:
>
> ?
> abrouse% brew search minc
> homebrew/science/libminc ?                            homebrew/science/minc                                 homebrew/science/minced
> ?
>
> I have managed to install libminc but minc will not compile on 10.11.6:
>
> ?
> MINC executables can't find libhdf5.9.dylib https://github.com/Homebrew/homebrew-science/issues/2751
> minc does not compile on OS X 10.11 El Capitan https://github.com/Homebrew/homebrew-science/issues/2927 <https://github.com/Homebrew/homebrew-science/issues/2927>
> ?
>
> There is some info here:
> https://github.com/Homebrew/homebrew-science/issues/2927 <https://github.com/Homebrew/homebrew-science/issues/2927>
>
> but even that is already a bit stale...
>
> thanks for any help,
> Andrew
>
> Andrew Brouse
> System Administrator
> NeuroRx Research
> 3575, av. du Parc #5322
> Montr?al, QC, H2X 3P9
> Canada
>
> t: +1-514-906-3909 x333
> e: abrouse at neurorx.com <mailto:abrouse at neurorx.com>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


-- 
Best regards,

  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com

From a.janke at gmail.com  Wed Aug  3 19:25:37 2016
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 4 Aug 2016 09:25:37 +1000
Subject: [MINC-users] Minc Flood Fill
In-Reply-To: <CAFQOoOo00mxM_3yjCss=wFEm1-YVF7DDjH6xhbCXZ3AjhYcbDA@mail.gmail.com>
References: <CABApf9HOHicHtvwYwQodoE5WFnzjPJW887hU7GoG2-pFHHdG+Q@mail.gmail.com>
	<CAFQOoOo00mxM_3yjCss=wFEm1-YVF7DDjH6xhbCXZ3AjhYcbDA@mail.gmail.com>
Message-ID: <CAG0CB21GKBYuezfPR9vLvg8AkQw2eKmLzjZ46q_UGcRJfOj2fw@mail.gmail.com>

mincmorph doesn't do this specifically but in a way the algorithm is
already there with the grouping function (Borgefors algorithm).

   https://github.com/BIC-MNI/minc-tools/blob/master/progs/mincmorph/kernel_ops.c#L469

Depends on how much code you want to write!


a

On 4 August 2016 at 05:13, Gabriel A. Devenyi <gdevenyi at gmail.com> wrote:
> ANTs has some fill through masks functionality in ImageMath, which might be
> what you're looking for. Its included with minc-toolkit-v2
>
>
>
> On Mon, Jul 25, 2016, 14:01 Andrew Wood <andrew at biospective.com> wrote:
>
>> Hi all,
>>
>> I'm wondering if a minc tool exists that can do a flood fill operation. It
>> would take:
>>   1) an image
>>   2) a label volume, defining seed regions
>>   3) a threshold, defining the "aggressiveness" of the fill
>>
>> Display can do it ("set threshold" and "label fill" in the Segmenting
>> menu), but of course requires a human user; I was hoping for a tool that
>> could be used in an automated pipeline.
>>
>> Thanks,
>> Andrew
>> _______________________________________________
>> 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

From ptcougopinto at gmail.com  Thu Aug  4 14:03:41 2016
From: ptcougopinto at gmail.com (Pedro)
Date: Thu, 4 Aug 2016 15:03:41 -0300
Subject: [MINC-users] Segmentation: Handling poor T1 contrast?
In-Reply-To: <CAFQOoOrd4rtK821V0RagFApCssE7tEyKiNhzKipWFY6Ueq7+-Q@mail.gmail.com>
References: <CAFQOoOrd4rtK821V0RagFApCssE7tEyKiNhzKipWFY6Ueq7+-Q@mail.gmail.com>
Message-ID: <E1BA2952-08A9-45F2-AECC-14DDE82FCF6A@gmail.com>

Hi, Gabriel ?

I?d also highly appreciate any insights on that. I?m also dealing with the same issue with some clinical 3T T1s. Up to now, I could improve the segmentation by tweaking the N3 normalization parameters, but still not completely happy with the results. Did you have any progress?

Thanks!
Pedro
> Em 2 de ago de 2016, ?(s) 15:24, Gabriel A. Devenyi <gdevenyi at gmail.com> escreveu:
> 
> Hi all,
> 
> I was wondering if anyone could recommend any tricks to deal with T1 scans
> with poor contrast (likely due to inappropriate T1 parameters?). I'm trying
> to do some grey/white segmentation and the lack of contrast is causing
> issues.
> 
> Thanks!
> 
> --
> Gabriel A. Devenyi B.Eng. Ph.D.
> Research Computing Associate
> Computational Brain Anatomy Laboratory
> Cerebral Imaging Center
> Douglas Mental Health University Institute
> Affiliate, Department of Psychiatry
> McGill University
> t: 514.761.6131x4781
> e: gdevenyi at gmail.com
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


From a.janke at gmail.com  Thu Aug  4 16:40:04 2016
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 5 Aug 2016 06:40:04 +1000
Subject: [MINC-users] Segmentation: Handling poor T1 contrast?
In-Reply-To: <CAFQOoOrd4rtK821V0RagFApCssE7tEyKiNhzKipWFY6Ueq7+-Q@mail.gmail.com>
References: <CAFQOoOrd4rtK821V0RagFApCssE7tEyKiNhzKipWFY6Ueq7+-Q@mail.gmail.com>
Message-ID: <CAG0CB20jP35f-6esSnGc7R3UAsf7MVWMHMyVsO1C6666Ze3hZw@mail.gmail.com>

Hi Gabriel,

If the images are consistent in their contrast my approach is to build
a nonlinear model from them, match the model to the another with
"correct" contrast and then build a joint histogram between them, fit
a polynomial to the result and then use this to remap intensities on
the originals. It isn't perfect but it does help a bit.  There was a
tool called PolFit some years ago by Sylvain Prima when he was
visiting Louis lab, not sure if it ever made it to release or not. Its
primary application was to assist with registration between image
types by building a synthetic intermediate image. Vlad may know for
sure.

ta


a


On 3 August 2016 at 04:24, Gabriel A. Devenyi <gdevenyi at gmail.com> wrote:
> Hi all,
>
> I was wondering if anyone could recommend any tricks to deal with T1 scans
> with poor contrast (likely due to inappropriate T1 parameters?). I'm trying
> to do some grey/white segmentation and the lack of contrast is causing
> issues.
>
> Thanks!
>
> --
> Gabriel A. Devenyi B.Eng. Ph.D.
> Research Computing Associate
> Computational Brain Anatomy Laboratory
> Cerebral Imaging Center
> Douglas Mental Health University Institute
> Affiliate, Department of Psychiatry
> McGill University
> t: 514.761.6131x4781
> e: gdevenyi at gmail.com
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From ptcougopinto at gmail.com  Tue Aug 16 11:47:15 2016
From: ptcougopinto at gmail.com (Pedro Telles Cougo Pinto)
Date: Tue, 16 Aug 2016 12:47:15 -0300
Subject: [MINC-users] Fill ROI
Message-ID: <1773343C-BA3F-4A75-819C-1704E5D1524F@gmail.com>

Hi, everyone

Is there a way to fill holes in binary volumes? Such as in the -fill option from mincbeast.

Thanks
Pedro

From a.janke at gmail.com  Tue Aug 16 11:51:48 2016
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 17 Aug 2016 01:51:48 +1000
Subject: [MINC-users] Fill ROI
In-Reply-To: <1773343C-BA3F-4A75-819C-1704E5D1524F@gmail.com>
References: <1773343C-BA3F-4A75-819C-1704E5D1524F@gmail.com>
Message-ID: <CAG0CB20HNL7rP7a7+oK0HjQaHoz8Bo5FfNZwJku1YM1C-UcHiw@mail.gmail.com>

Hi Pedro,

Vladimir has some tools in ITK to do this but it depends on what you
means by holes and if the remainder of the binary image is contiguous.

If the latter then have a look at mincmorph, you can then frame the
problem as removing the smallest contiguous object of the inverse of
the binary mask. To do this use the Group and K[] - keep operations.


a

On 17 August 2016 at 01:47, Pedro Telles Cougo Pinto
<ptcougopinto at gmail.com> wrote:
> Hi, everyone
>
> Is there a way to fill holes in binary volumes? Such as in the -fill option from mincbeast.
>
> Thanks
> Pedro
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From gdevenyi at gmail.com  Tue Aug 16 12:16:00 2016
From: gdevenyi at gmail.com (Gabriel A. Devenyi)
Date: Tue, 16 Aug 2016 16:16:00 +0000
Subject: [MINC-users] Fill ROI
In-Reply-To: <CAG0CB20HNL7rP7a7+oK0HjQaHoz8Bo5FfNZwJku1YM1C-UcHiw@mail.gmail.com>
References: <1773343C-BA3F-4A75-819C-1704E5D1524F@gmail.com>
	<CAG0CB20HNL7rP7a7+oK0HjQaHoz8Bo5FfNZwJku1YM1C-UcHiw@mail.gmail.com>
Message-ID: <CAFQOoOrySkEehSnXnwr8CvPRodQMMuaBV95zabvSDHySXBPVTQ@mail.gmail.com>

ANTs (included in minc-toolkit-v2) ImageMath has FillHoles (must be
completely enclosed holes to be filled)

On Tue, Aug 16, 2016 at 11:53 AM Andrew Janke <a.janke at gmail.com> wrote:

> Hi Pedro,
>
> Vladimir has some tools in ITK to do this but it depends on what you
> means by holes and if the remainder of the binary image is contiguous.
>
> If the latter then have a look at mincmorph, you can then frame the
> problem as removing the smallest contiguous object of the inverse of
> the binary mask. To do this use the Group and K[] - keep operations.
>
>
> a
>
> On 17 August 2016 at 01:47, Pedro Telles Cougo Pinto
> <ptcougopinto at gmail.com> wrote:
> > Hi, everyone
> >
> > Is there a way to fill holes in binary volumes? Such as in the -fill
> option from mincbeast.
> >
> > Thanks
> > Pedro
> > _______________________________________________
> > 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
>

From zijdenbos at gmail.com  Wed Aug 17 11:54:57 2016
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Wed, 17 Aug 2016 11:54:57 -0400
Subject: [MINC-users] mincresample and linear 'deformations'
Message-ID: <CABEEk14Lws4o2cxb-gdFGOwUWcdXecrjTjfqW3sg_Tp1JeE20Q@mail.gmail.com>

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.

Thoughts?

-- A

?
 lsq3_verify.png
<https://drive.google.com/file/d/0B5fOtqpIs4sKd0U0UVQ3al95WTA/view?usp=drive_web>
?

From vladimir.fonov at gmail.com  Wed Aug 17 12:28:23 2016
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Wed, 17 Aug 2016 12:28:23 -0400
Subject: [MINC-users] mincresample and linear 'deformations'
In-Reply-To: <CABEEk14Lws4o2cxb-gdFGOwUWcdXecrjTjfqW3sg_Tp1JeE20Q@mail.gmail.com>
References: <CABEEk14Lws4o2cxb-gdFGOwUWcdXecrjTjfqW3sg_Tp1JeE20Q@mail.gmail.com>
Message-ID: <f418716d-d13b-105d-a331-28a66787b58e@gmail.com>

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.
>
> Thoughts?
>
> -- A
>
> ?
>  lsq3_verify.png
> <https://drive.google.com/file/d/0B5fOtqpIs4sKd0U0UVQ3al95WTA/view?usp=drive_web>
> ?
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


-- 
Best regards,

  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com

From zijdenbos at gmail.com  Wed Aug 17 13:50:17 2016
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Wed, 17 Aug 2016 13:50:17 -0400
Subject: [MINC-users] mincresample and linear 'deformations'
In-Reply-To: <f418716d-d13b-105d-a331-28a66787b58e@gmail.com>
References: <CABEEk14Lws4o2cxb-gdFGOwUWcdXecrjTjfqW3sg_Tp1JeE20Q@mail.gmail.com>
	<f418716d-d13b-105d-a331-28a66787b58e@gmail.com>
Message-ID: <CABEEk15FKE-mWn3c1khVHWoP0sxwbCABOdFvoQ+Z0NwxWmeYJQ@mail.gmail.com>

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.
>>
>> Thoughts?
>>
>> -- A
>>
>> ?
>>  lsq3_verify.png
>> <https://drive.google.com/file/d/0B5fOtqpIs4sKd0U0UVQ3al95WT
>> A/view?usp=drive_web>
>> ?
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
>>
>
> --
> 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
>

From sorench at gmail.com  Wed Aug 17 14:09:28 2016
From: sorench at gmail.com (Soren Christensen)
Date: Wed, 17 Aug 2016 11:09:28 -0700
Subject: [MINC-users] MINC-users Digest, Vol 131, Issue 14
In-Reply-To: <BN3PR03MB1445B8A770A11A1E52D5AB64A6010@BN3PR03MB1445.namprd03.prod.outlook.com>
References: <mailman.3.1469635201.14522.minc-users@bic.mni.mcgill.ca>
	<BN3PR03MB1445B8A770A11A1E52D5AB64A6010@BN3PR03MB1445.namprd03.prod.outlook.com>
Message-ID: <CAHfsrRaic1H850mPd5QhvHtdB3KrvyMDv-UDGhMmfr8OVNuHaA@mail.gmail.com>

Thanks for posting. I had the same issue. Based on your mod it seems the
source fix is to change lines 55 ad 61
in minctools/conversion/CMakeLists.txt
and move ${ZNZ_LIBRARY} to the left of ${LIBMINC_LIBRARIES}.  At leas that
seems to work for me.


Soren

On Thu, Jul 28, 2016 at 7:18 PM, Thomas Funck, Mr <
thomas.funck at mail.mcgill.ca> wrote:

> Compiling ZLIB before the rest didn't work, but I found a rather hacky
> workaround.
>
>
> In the following files the path to libz.a has to be moved to be behind the
> path to libznz.a.
>
>
> ./minctools/conversion/CMakeFiles/nii2mnc.dir/link.txt
> ./minctools/conversion/CMakeFiles/mnc2nii.dir/link.txt
>
> After that the compilation works.
>
> Thomas
>
>
> ________________________________
> From: minc-users-bounces at bic.mni.mcgill.ca <minc-users-bounces at bic.mni.
> mcgill.ca> on behalf of minc-users-request at bic.mni.mcgill.ca <
> minc-users-request at bic.mni.mcgill.ca>
> Sent: Wednesday, July 27, 2016 12:00:01 PM
> To: minc-users at bic.mni.mcgill.ca
> Subject: MINC-users Digest, Vol 131, Issue 14
>
> Send MINC-users mailing list submissions to
>         minc-users at bic.mni.mcgill.ca
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> or, via email, send a message with subject or body 'help' to
>         minc-users-request at bic.mni.mcgill.ca
>
> You can reach the person managing the list at
>         minc-users-owner at bic.mni.mcgill.ca
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MINC-users digest..."
>
>
> Today's Topics:
>
>    1. dcm2mnc error regarding PatientAge (Daniel Marchand)
>    2. Problem with ZLIB when compiling minc-toolkit-v2
>       (Thomas Funck, Mr)
>    3. Re: Problem with ZLIB when compiling minc-toolkit-v2
>       (vladimir.fonov at gmail.com)
>    4. Re: dcm2mnc error regarding PatientAge (Robert D. Vincent)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 26 Jul 2016 13:05:35 -0400
> From: Daniel Marchand <daniel at biospective.com>
> To: minc-users at bic.mni.mcgill.ca
> Subject: [MINC-users] dcm2mnc error regarding PatientAge
> Message-ID:
>         <CALZEBsYNOnpxS-opkovO6mJFu1Xf-a1BeHjHNYbdPxNPLdz0Uw at mail.
> gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> I'm having trouble converting a dicom file including the line:
> (0010,1010) AS [0000]                                   #   4, 1 PatientAge
>
> which throws the error:
> Age units (0000) unknown
>
> It seems that the cause of the error is
> inside of conversion/dcm2mnc/minc_file.c :
>
>     if (strlen(general_info->patient.age) > 0) {
>         string_t temp;
>         int i;
>         double age;
>
>         strncpy(temp, general_info->patient.age, STRING_T_LEN - 1);
>         while (temp[i] != 0 && !isdigit(temp[i]))
>           i++;
>         if (temp[i] == 0) {
>           fprintf(stderr, "ERROR: Age was not numeric!!\n");
>           exit(-1);
>         }
>         age = atof(&temp[i]);
>         while (temp[i] != 0 && isdigit(temp[i]))
>           i++;
>         if (temp[i] == 'M')     /* age is in months */
>           age /= 12.0;
>         else if (temp[i] == 'W')   /* age is in weeks */
>           age /= 52.0;
>         else if (temp[i] == 'D')   /* age is in days */
>           age /= 365.0;
>         else if (temp[i] != 'Y') { /* age is in years */
>           fprintf(stderr, "ERROR: Age units (%s) unknown.\n", temp);
>           exit(-1);
>         }
>         miattputdbl(mincid, varid, MIage, age);
>
> I would appear that perhaps a new option could be added where
> dcm2mnc doesn't crash if the age is written as [0000]?
>
> Best,
>
> Daniel
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 26 Jul 2016 18:36:14 +0000
> From: "Thomas Funck, Mr" <thomas.funck at mail.mcgill.ca>
> To: "minc-users at bic.mni.mcgill.ca" <minc-users at bic.mni.mcgill.ca>
> Subject: [MINC-users] Problem with ZLIB when compiling minc-toolkit-v2
> Message-ID:
>         <BN3PR03MB1445BC1E1A497B51E9AB82E1A60E0 at BN3PR03MB1445.
> namprd03.prod.outlook.com>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> I'm trying to compile minc-toolkit-v2, but ran into the following problem.
> I'm trying to compile on Ubuntu 16.04.1 LTS and with USE_SYSTEM_ZLIB=OFF. I
> also tried minc-toolkit but ran into the same error.
>
> Thanks for any help,
>
> Thomas
>
> Scanning dependencies of target nii2mnc
> [ 23%] Building C object minctools/conversion/
> CMakeFiles/nii2mnc.dir/nifti1/nii2mnc.c.o
> [ 23%] Linking C executable nii2mnc
> ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzopen':
> znzlib.c:(.text+0x4a): undefined reference to `gzopen'
> ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzdopen':
> znzlib.c:(.text+0x102): undefined reference to `gzdopen'
> ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `Xznzclose':
> znzlib.c:(.text+0x166): undefined reference to `gzclose'
> ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzread':
> znzlib.c:(.text+0x220): undefined reference to `gzread'
> ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzwrite':
> znzlib.c:(.text+0x320): undefined reference to `gzwrite'
> ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzseek':
> znzlib.c:(.text+0x3db): undefined reference to `gzseek'
> ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzrewind':
> znzlib.c:(.text+0x447): undefined reference to `gzseek'
> ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znztell':
> znzlib.c:(.text+0x4a3): undefined reference to `gztell'
> ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzputs':
> znzlib.c:(.text+0x4f7): undefined reference to `gzputs'
> ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzgets':
> znzlib.c:(.text+0x55b): undefined reference to `gzgets'
> ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzflush':
> znzlib.c:(.text+0x5c5): undefined reference to `gzflush'
> ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzeof':
> znzlib.c:(.text+0x623): undefined reference to `gzeof'
> ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzputc':
> znzlib.c:(.text+0x677): undefined reference to `gzputc'
> ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzgetc':
> znzlib.c:(.text+0x6f5): undefined reference to `gzgetc'
> ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzprintf':
> znzlib.c:(.text+0x798): undefined reference to `gzprintf'
> collect2: error: ld returned 1 exit status
> minctools/conversion/CMakeFiles/nii2mnc.dir/build.make:105: recipe for
> target 'minctools/conversion/nii2mnc' failed
> make[2]: *** [minctools/conversion/nii2mnc] Error 1
> CMakeFiles/Makefile2:5017: recipe for target 'minctools/conversion/CMakeFiles/nii2mnc.dir/all'
> failed
> make[1]: *** [minctools/conversion/CMakeFiles/nii2mnc.dir/all] Error 2
> Makefile:160: recipe for target 'all' failed
> make: *** [all] Error 2
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 26 Jul 2016 14:43:17 -0400
> From: vladimir.fonov at gmail.com
> To: MINC list <minc-users at bic.mni.mcgill.ca>
> Subject: Re: [MINC-users] Problem with ZLIB when compiling
>         minc-toolkit-v2
> Message-ID: <64C52D64-4ED0-4241-A956-8952D5B37DF9 at gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> Can you try running ?make ZLIB? first , and then ?make nii2mnc? ?
>
>
> > On Jul 26, 2016, at 14:36, Thomas Funck, Mr <thomas.funck at mail.mcgill.ca>
> wrote:
> >
> > Hi,
> >
> > I'm trying to compile minc-toolkit-v2, but ran into the following
> problem. I'm trying to compile on Ubuntu 16.04.1 LTS and with
> USE_SYSTEM_ZLIB=OFF. I also tried minc-toolkit but ran into the same error.
> >
> > Thanks for any help,
> >
> > Thomas
> >
> > Scanning dependencies of target nii2mnc
> > [ 23%] Building C object minctools/conversion/
> CMakeFiles/nii2mnc.dir/nifti1/nii2mnc.c.o
> > [ 23%] Linking C executable nii2mnc
> > ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzopen':
> > znzlib.c:(.text+0x4a): undefined reference to `gzopen'
> > ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzdopen':
> > znzlib.c:(.text+0x102): undefined reference to `gzdopen'
> > ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `Xznzclose':
> > znzlib.c:(.text+0x166): undefined reference to `gzclose'
> > ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzread':
> > znzlib.c:(.text+0x220): undefined reference to `gzread'
> > ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzwrite':
> > znzlib.c:(.text+0x320): undefined reference to `gzwrite'
> > ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzseek':
> > znzlib.c:(.text+0x3db): undefined reference to `gzseek'
> > ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzrewind':
> > znzlib.c:(.text+0x447): undefined reference to `gzseek'
> > ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znztell':
> > znzlib.c:(.text+0x4a3): undefined reference to `gztell'
> > ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzputs':
> > znzlib.c:(.text+0x4f7): undefined reference to `gzputs'
> > ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzgets':
> > znzlib.c:(.text+0x55b): undefined reference to `gzgets'
> > ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzflush':
> > znzlib.c:(.text+0x5c5): undefined reference to `gzflush'
> > ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzeof':
> > znzlib.c:(.text+0x623): undefined reference to `gzeof'
> > ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzputc':
> > znzlib.c:(.text+0x677): undefined reference to `gzputc'
> > ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzgetc':
> > znzlib.c:(.text+0x6f5): undefined reference to `gzgetc'
> > ../../external//usr/local/minc/lib/libznz.a(znzlib.o): In function
> `znzprintf':
> > znzlib.c:(.text+0x798): undefined reference to `gzprintf'
> > collect2: error: ld returned 1 exit status
> > minctools/conversion/CMakeFiles/nii2mnc.dir/build.make:105: recipe for
> target 'minctools/conversion/nii2mnc' failed
> > make[2]: *** [minctools/conversion/nii2mnc] Error 1
> > CMakeFiles/Makefile2:5017: recipe for target 'minctools/conversion/CMakeFiles/nii2mnc.dir/all'
> failed
> > make[1]: *** [minctools/conversion/CMakeFiles/nii2mnc.dir/all] Error 2
> > Makefile:160: recipe for target 'all' failed
> > make: *** [all] Error 2
> >
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
> Best regards, Vladimir S. FONOV ~ v.s.fonov <at> ilmarin.info
>
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 26 Jul 2016 23:36:34 -0400
> From: "Robert D. Vincent" <robert.d.vincent at mcgill.ca>
> To: MINC users mailing list <minc-users at bic.mni.mcgill.ca>
> Subject: Re: [MINC-users] dcm2mnc error regarding PatientAge
> Message-ID:
>         <CAAd5DeQz2bmP8UkREuQeOA3WJDxoyLnhcW59JiycLpoV-YFNSw at mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> I'll relax the test and make it a warning. But the AS VR does not permit a
> field value of 0000.
>
>     -bert
>
> On Tue, Jul 26, 2016 at 1:05 PM, Daniel Marchand <daniel at biospective.com>
> wrote:
>
> > Hi,
> >
> > I'm having trouble converting a dicom file including the line:
> > (0010,1010) AS [0000]                                   #   4, 1
> PatientAge
> >
> > which throws the error:
> > Age units (0000) unknown
> >
> > It seems that the cause of the error is
> > inside of conversion/dcm2mnc/minc_file.c :
> >
> >     if (strlen(general_info->patient.age) > 0) {
> >         string_t temp;
> >         int i;
> >         double age;
> >
> >         strncpy(temp, general_info->patient.age, STRING_T_LEN - 1);
> >         while (temp[i] != 0 && !isdigit(temp[i]))
> >           i++;
> >         if (temp[i] == 0) {
> >           fprintf(stderr, "ERROR: Age was not numeric!!\n");
> >           exit(-1);
> >         }
> >         age = atof(&temp[i]);
> >         while (temp[i] != 0 && isdigit(temp[i]))
> >           i++;
> >         if (temp[i] == 'M')     /* age is in months */
> >           age /= 12.0;
> >         else if (temp[i] == 'W')   /* age is in weeks */
> >           age /= 52.0;
> >         else if (temp[i] == 'D')   /* age is in days */
> >           age /= 365.0;
> >         else if (temp[i] != 'Y') { /* age is in years */
> >           fprintf(stderr, "ERROR: Age units (%s) unknown.\n", temp);
> >           exit(-1);
> >         }
> >         miattputdbl(mincid, varid, MIage, age);
> >
> > I would appear that perhaps a new option could be added where
> > dcm2mnc doesn't crash if the age is written as [0000]?
> >
> > Best,
> >
> > Daniel
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
>
>
> ------------------------------
>
> _______________________________________________
> MINC-users mailing list
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>
> End of MINC-users Digest, Vol 131, Issue 14
> *******************************************
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From vladimir.fonov at gmail.com  Wed Aug 17 15:21:48 2016
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Wed, 17 Aug 2016 15:21:48 -0400
Subject: [MINC-users] mincresample and linear 'deformations'
In-Reply-To: <CABEEk15FKE-mWn3c1khVHWoP0sxwbCABOdFvoQ+Z0NwxWmeYJQ@mail.gmail.com>
References: <CABEEk14Lws4o2cxb-gdFGOwUWcdXecrjTjfqW3sg_Tp1JeE20Q@mail.gmail.com>
	<f418716d-d13b-105d-a331-28a66787b58e@gmail.com>
	<CABEEk15FKE-mWn3c1khVHWoP0sxwbCABOdFvoQ+Z0NwxWmeYJQ@mail.gmail.com>
Message-ID: <CAMCwi7OVrifC-Q_j2Yy56H5a8vsFutYS4RiakaxpiHR-u52HFQ@mail.gmail.com>

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.
> >>
> >> Thoughts?
> >>
> >> -- A
> >>
> >> ?
> >>  lsq3_verify.png
> >> <https://drive.google.com/file/d/0B5fOtqpIs4sKd0U0UVQ3al95WT
> >> A/view?usp=drive_web>
> >> ?
> >> _______________________________________________
> >> MINC-users at bic.mni.mcgill.ca
> >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >>
> >>
> >
> > --
> > 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
>



-- 
Best regards,

 Vladimir S. Fonov ~ vladimir <dot> fonov <at> gmail <dot> com

From zijdenbos at gmail.com  Wed Aug 17 16:30:47 2016
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Wed, 17 Aug 2016 16:30:47 -0400
Subject: [MINC-users] mincresample and linear 'deformations'
In-Reply-To: <CAMCwi7OVrifC-Q_j2Yy56H5a8vsFutYS4RiakaxpiHR-u52HFQ@mail.gmail.com>
References: <CABEEk14Lws4o2cxb-gdFGOwUWcdXecrjTjfqW3sg_Tp1JeE20Q@mail.gmail.com>
	<f418716d-d13b-105d-a331-28a66787b58e@gmail.com>
	<CABEEk15FKE-mWn3c1khVHWoP0sxwbCABOdFvoQ+Z0NwxWmeYJQ@mail.gmail.com>
	<CAMCwi7OVrifC-Q_j2Yy56H5a8vsFutYS4RiakaxpiHR-u52HFQ@mail.gmail.com>
Message-ID: <CABEEk1409-7F7PsKR+V8PTYFJ7NGzi-HJw0=+EGZwD-iL7p2WA@mail.gmail.com>

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.
> > >>
> > >> Thoughts?
> > >>
> > >> -- A
> > >>
> > >> ?
> > >>  lsq3_verify.png
> > >> <https://drive.google.com/file/d/0B5fOtqpIs4sKd0U0UVQ3al95WT
> > >> A/view?usp=drive_web>
> > >> ?
> > >> _______________________________________________
> > >> MINC-users at bic.mni.mcgill.ca
> > >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > >>
> > >>
> > >
> > > --
> > > 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
> >
>
>
>
> --
> 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
>

From louis.collins at mcgill.ca  Wed Aug 17 16:36:57 2016
From: louis.collins at mcgill.ca (Louis Collins, Dr.)
Date: Wed, 17 Aug 2016 20:36:57 +0000
Subject: [MINC-users] mincresample and linear 'deformations'
In-Reply-To: <CAMCwi7OVrifC-Q_j2Yy56H5a8vsFutYS4RiakaxpiHR-u52HFQ@mail.gmail.com>
References: <CABEEk14Lws4o2cxb-gdFGOwUWcdXecrjTjfqW3sg_Tp1JeE20Q@mail.gmail.com>
	<f418716d-d13b-105d-a331-28a66787b58e@gmail.com>
	<CABEEk15FKE-mWn3c1khVHWoP0sxwbCABOdFvoQ+Z0NwxWmeYJQ@mail.gmail.com>
	<CAMCwi7OVrifC-Q_j2Yy56H5a8vsFutYS4RiakaxpiHR-u52HFQ@mail.gmail.com>
Message-ID: <F302FD0F-597A-4A94-AB5D-6017098DADAC@mcgill.ca>

this is indeed the issue. the inverse of the source to target transform is required for mincresample or itk_resample to be able to identify the source voxels needed to interpret the intensity value for the voxel in the target volume.   unless the xfm transform is explicitly represented in its inverse form, mincresample uses an iterative scheme to invert the transform numerically.  Depending on the magnitude of the error to be minimized, it is possible that the greedy optimization procedure used by mincresample does not arrive at the proper value in the limited (n=50?) number of iterations allowed.  I?m not sure if the same procedure is used in itk_resample.
-Louis
> On 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.
>>>> 
>>>> Thoughts?
>>>> 
>>>> -- A
>>>> 
>>>> ?
>>>> lsq3_verify.png
>>>> <https://drive.google.com/file/d/0B5fOtqpIs4sKd0U0UVQ3al95WT
>>>> A/view?usp=drive_web>
>>>> ?
>>>> _______________________________________________
>>>> MINC-users at bic.mni.mcgill.ca
>>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>>> 
>>>> 
>>> 
>>> --
>>> 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
>> 
> 
> 
> 
> -- 
> 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


From vladimir.fonov at gmail.com  Wed Aug 17 17:24:08 2016
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Wed, 17 Aug 2016 17:24:08 -0400
Subject: [MINC-users] mincresample and linear 'deformations'
In-Reply-To: <CABEEk1409-7F7PsKR+V8PTYFJ7NGzi-HJw0=+EGZwD-iL7p2WA@mail.gmail.com>
References: <CABEEk14Lws4o2cxb-gdFGOwUWcdXecrjTjfqW3sg_Tp1JeE20Q@mail.gmail.com>
	<f418716d-d13b-105d-a331-28a66787b58e@gmail.com>
	<CABEEk15FKE-mWn3c1khVHWoP0sxwbCABOdFvoQ+Z0NwxWmeYJQ@mail.gmail.com>
	<CAMCwi7OVrifC-Q_j2Yy56H5a8vsFutYS4RiakaxpiHR-u52HFQ@mail.gmail.com>
	<CABEEk1409-7F7PsKR+V8PTYFJ7NGzi-HJw0=+EGZwD-iL7p2WA@mail.gmail.com>
Message-ID: <cac2bba6-b4bb-259a-cba4-5f393afb5b23@gmail.com>

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

From zijdenbos at gmail.com  Wed Aug 17 18:05:44 2016
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Wed, 17 Aug 2016 18:05:44 -0400
Subject: [MINC-users] mincresample and linear 'deformations'
In-Reply-To: <cac2bba6-b4bb-259a-cba4-5f393afb5b23@gmail.com>
References: <CABEEk14Lws4o2cxb-gdFGOwUWcdXecrjTjfqW3sg_Tp1JeE20Q@mail.gmail.com>
	<f418716d-d13b-105d-a331-28a66787b58e@gmail.com>
	<CABEEk15FKE-mWn3c1khVHWoP0sxwbCABOdFvoQ+Z0NwxWmeYJQ@mail.gmail.com>
	<CAMCwi7OVrifC-Q_j2Yy56H5a8vsFutYS4RiakaxpiHR-u52HFQ@mail.gmail.com>
	<CABEEk1409-7F7PsKR+V8PTYFJ7NGzi-HJw0=+EGZwD-iL7p2WA@mail.gmail.com>
	<cac2bba6-b4bb-259a-cba4-5f393afb5b23@gmail.com>
Message-ID: <CABEEk17c-O2YmC+zkonJP2kdqe70TYSN=8VJyyb3ttqSrDhM=Q@mail.gmail.com>

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
>

From a.janke at gmail.com  Wed Aug 17 20:38:58 2016
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 18 Aug 2016 10:38:58 +1000
Subject: [MINC-users] mincresample and linear 'deformations'
In-Reply-To: <CABEEk17c-O2YmC+zkonJP2kdqe70TYSN=8VJyyb3ttqSrDhM=Q@mail.gmail.com>
References: <CABEEk14Lws4o2cxb-gdFGOwUWcdXecrjTjfqW3sg_Tp1JeE20Q@mail.gmail.com>
	<f418716d-d13b-105d-a331-28a66787b58e@gmail.com>
	<CABEEk15FKE-mWn3c1khVHWoP0sxwbCABOdFvoQ+Z0NwxWmeYJQ@mail.gmail.com>
	<CAMCwi7OVrifC-Q_j2Yy56H5a8vsFutYS4RiakaxpiHR-u52HFQ@mail.gmail.com>
	<CABEEk1409-7F7PsKR+V8PTYFJ7NGzi-HJw0=+EGZwD-iL7p2WA@mail.gmail.com>
	<cac2bba6-b4bb-259a-cba4-5f393afb5b23@gmail.com>
	<CABEEk17c-O2YmC+zkonJP2kdqe70TYSN=8VJyyb3ttqSrDhM=Q@mail.gmail.com>
Message-ID: <CAG0CB21pnoSb5Ko+hVTjn+4WXJHDx=WSw6T2Dp=xVNo3bZGU4g@mail.gmail.com>

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

From robert.d.vincent at mcgill.ca  Thu Aug 18 10:37:00 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Thu, 18 Aug 2016 10:37:00 -0400
Subject: [MINC-users] mincresample and linear 'deformations'
In-Reply-To: <CAG0CB21pnoSb5Ko+hVTjn+4WXJHDx=WSw6T2Dp=xVNo3bZGU4g@mail.gmail.com>
References: <CABEEk14Lws4o2cxb-gdFGOwUWcdXecrjTjfqW3sg_Tp1JeE20Q@mail.gmail.com>
	<f418716d-d13b-105d-a331-28a66787b58e@gmail.com>
	<CABEEk15FKE-mWn3c1khVHWoP0sxwbCABOdFvoQ+Z0NwxWmeYJQ@mail.gmail.com>
	<CAMCwi7OVrifC-Q_j2Yy56H5a8vsFutYS4RiakaxpiHR-u52HFQ@mail.gmail.com>
	<CABEEk1409-7F7PsKR+V8PTYFJ7NGzi-HJw0=+EGZwD-iL7p2WA@mail.gmail.com>
	<cac2bba6-b4bb-259a-cba4-5f393afb5b23@gmail.com>
	<CABEEk17c-O2YmC+zkonJP2kdqe70TYSN=8VJyyb3ttqSrDhM=Q@mail.gmail.com>
	<CAG0CB21pnoSb5Ko+hVTjn+4WXJHDx=WSw6T2Dp=xVNo3bZGU4g@mail.gmail.com>
Message-ID: <CAAd5DeTLUGfZ0F4Hqev6g0ppQrjaBgfUzM4QyajLJHDAv9a0Dw@mail.gmail.com>

Hi all,

The core of the issue from an implementation perspective is the function
evaluate_grid_volume(), which is responsible for evaluating the grid
transform for a point in world space. If the point lies outside the grid,
this function silently returns zero for all of the displacements, so the
point is not transformed and the original data is copied.

It is trivial to modify this function to return an error indication if the
point is outside the grid, so that the resampling process could "do the
right thing", whatever that is...

    -bert

On Wed, Aug 17, 2016 at 8:38 PM, Andrew Janke <a.janke at gmail.com> wrote:

> 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
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From zijdenbos at gmail.com  Thu Aug 18 11:00:14 2016
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Thu, 18 Aug 2016 11:00:14 -0400
Subject: [MINC-users] mincresample and linear 'deformations'
In-Reply-To: <CAAd5DeTLUGfZ0F4Hqev6g0ppQrjaBgfUzM4QyajLJHDAv9a0Dw@mail.gmail.com>
References: <CABEEk14Lws4o2cxb-gdFGOwUWcdXecrjTjfqW3sg_Tp1JeE20Q@mail.gmail.com>
	<f418716d-d13b-105d-a331-28a66787b58e@gmail.com>
	<CABEEk15FKE-mWn3c1khVHWoP0sxwbCABOdFvoQ+Z0NwxWmeYJQ@mail.gmail.com>
	<CAMCwi7OVrifC-Q_j2Yy56H5a8vsFutYS4RiakaxpiHR-u52HFQ@mail.gmail.com>
	<CABEEk1409-7F7PsKR+V8PTYFJ7NGzi-HJw0=+EGZwD-iL7p2WA@mail.gmail.com>
	<cac2bba6-b4bb-259a-cba4-5f393afb5b23@gmail.com>
	<CABEEk17c-O2YmC+zkonJP2kdqe70TYSN=8VJyyb3ttqSrDhM=Q@mail.gmail.com>
	<CAG0CB21pnoSb5Ko+hVTjn+4WXJHDx=WSw6T2Dp=xVNo3bZGU4g@mail.gmail.com>
	<CAAd5DeTLUGfZ0F4Hqev6g0ppQrjaBgfUzM4QyajLJHDAv9a0Dw@mail.gmail.com>
Message-ID: <CABEEk15=rO_Kk3x26vcKg_zaR93Tm9JBWMQofwANGTZFgDDcrw@mail.gmail.com>

Hi all,

Thanks for all your input. I'm still trying to figure out how to do what I
want, which is really to convert an arbitrary xfm into a deformation field
and have everything "just work", but I have some ideas that I'll pursue.

Bert, whatever the "right thing" is for mincresample, I'm pretty sure we
don't want to change its current behaviour; however, do you think it would
be feasible to add an option to it to control this? Would require
implementing what you suggest, and then adding a mincresample option to
insert the fill value as opposed to assuming '0 displacement'.

-- A



On Thu, Aug 18, 2016 at 10:37 AM, Robert D. Vincent <
robert.d.vincent at mcgill.ca> wrote:

> Hi all,
>
> The core of the issue from an implementation perspective is the function
> evaluate_grid_volume(), which is responsible for evaluating the grid
> transform for a point in world space. If the point lies outside the grid,
> this function silently returns zero for all of the displacements, so the
> point is not transformed and the original data is copied.
>
> It is trivial to modify this function to return an error indication if the
> point is outside the grid, so that the resampling process could "do the
> right thing", whatever that is...
>
>     -bert
>
> On Wed, Aug 17, 2016 at 8:38 PM, Andrew Janke <a.janke at gmail.com> wrote:
>
> > 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
> > _______________________________________________
> > 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
>
>

From robert.d.vincent at mcgill.ca  Thu Aug 18 11:36:40 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Thu, 18 Aug 2016 11:36:40 -0400
Subject: [MINC-users] mincresample and linear 'deformations'
In-Reply-To: <CABEEk15=rO_Kk3x26vcKg_zaR93Tm9JBWMQofwANGTZFgDDcrw@mail.gmail.com>
References: <CABEEk14Lws4o2cxb-gdFGOwUWcdXecrjTjfqW3sg_Tp1JeE20Q@mail.gmail.com>
	<f418716d-d13b-105d-a331-28a66787b58e@gmail.com>
	<CABEEk15FKE-mWn3c1khVHWoP0sxwbCABOdFvoQ+Z0NwxWmeYJQ@mail.gmail.com>
	<CAMCwi7OVrifC-Q_j2Yy56H5a8vsFutYS4RiakaxpiHR-u52HFQ@mail.gmail.com>
	<CABEEk1409-7F7PsKR+V8PTYFJ7NGzi-HJw0=+EGZwD-iL7p2WA@mail.gmail.com>
	<cac2bba6-b4bb-259a-cba4-5f393afb5b23@gmail.com>
	<CABEEk17c-O2YmC+zkonJP2kdqe70TYSN=8VJyyb3ttqSrDhM=Q@mail.gmail.com>
	<CAG0CB21pnoSb5Ko+hVTjn+4WXJHDx=WSw6T2Dp=xVNo3bZGU4g@mail.gmail.com>
	<CAAd5DeTLUGfZ0F4Hqev6g0ppQrjaBgfUzM4QyajLJHDAv9a0Dw@mail.gmail.com>
	<CABEEk15=rO_Kk3x26vcKg_zaR93Tm9JBWMQofwANGTZFgDDcrw@mail.gmail.com>
Message-ID: <CAAd5DeTDq+b7aYC4gRz88skWiRhErLuBq8RQMa-EGO9d9_4OZw@mail.gmail.com>

Hi Alex,

Sure, it's possible, but I would have to be careful about the unintended
consequences. My biggest issue is how the change might affect some of the
clients of the transform functions. At the very least the change would be
the effect on some of the libminc tests - several would have to be modified
to account for the change in behavior of general_transform_point() and its
ilk.

    -bert

On Thu, Aug 18, 2016 at 11:00 AM, Alex Zijdenbos <zijdenbos at gmail.com>
wrote:

> Hi all,
>
> Thanks for all your input. I'm still trying to figure out how to do what I
> want, which is really to convert an arbitrary xfm into a deformation field
> and have everything "just work", but I have some ideas that I'll pursue.
>
> Bert, whatever the "right thing" is for mincresample, I'm pretty sure we
> don't want to change its current behaviour; however, do you think it would
> be feasible to add an option to it to control this? Would require
> implementing what you suggest, and then adding a mincresample option to
> insert the fill value as opposed to assuming '0 displacement'.
>
> -- A
>
>
>
> On Thu, Aug 18, 2016 at 10:37 AM, Robert D. Vincent <
> robert.d.vincent at mcgill.ca> wrote:
>
> > Hi all,
> >
> > The core of the issue from an implementation perspective is the function
> > evaluate_grid_volume(), which is responsible for evaluating the grid
> > transform for a point in world space. If the point lies outside the grid,
> > this function silently returns zero for all of the displacements, so the
> > point is not transformed and the original data is copied.
> >
> > It is trivial to modify this function to return an error indication if
> the
> > point is outside the grid, so that the resampling process could "do the
> > right thing", whatever that is...
> >
> >     -bert
> >
> > On Wed, Aug 17, 2016 at 8:38 PM, Andrew Janke <a.janke at gmail.com> wrote:
> >
> > > 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
> > > _______________________________________________
> > > 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
>

From zijdenbos at gmail.com  Thu Aug 18 20:38:53 2016
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Thu, 18 Aug 2016 20:38:53 -0400
Subject: [MINC-users] mincresample and linear 'deformations'
In-Reply-To: <CAAd5DeTDq+b7aYC4gRz88skWiRhErLuBq8RQMa-EGO9d9_4OZw@mail.gmail.com>
References: <CABEEk14Lws4o2cxb-gdFGOwUWcdXecrjTjfqW3sg_Tp1JeE20Q@mail.gmail.com>
	<f418716d-d13b-105d-a331-28a66787b58e@gmail.com>
	<CABEEk15FKE-mWn3c1khVHWoP0sxwbCABOdFvoQ+Z0NwxWmeYJQ@mail.gmail.com>
	<CAMCwi7OVrifC-Q_j2Yy56H5a8vsFutYS4RiakaxpiHR-u52HFQ@mail.gmail.com>
	<CABEEk1409-7F7PsKR+V8PTYFJ7NGzi-HJw0=+EGZwD-iL7p2WA@mail.gmail.com>
	<cac2bba6-b4bb-259a-cba4-5f393afb5b23@gmail.com>
	<CABEEk17c-O2YmC+zkonJP2kdqe70TYSN=8VJyyb3ttqSrDhM=Q@mail.gmail.com>
	<CAG0CB21pnoSb5Ko+hVTjn+4WXJHDx=WSw6T2Dp=xVNo3bZGU4g@mail.gmail.com>
	<CAAd5DeTLUGfZ0F4Hqev6g0ppQrjaBgfUzM4QyajLJHDAv9a0Dw@mail.gmail.com>
	<CABEEk15=rO_Kk3x26vcKg_zaR93Tm9JBWMQofwANGTZFgDDcrw@mail.gmail.com>
	<CAAd5DeTDq+b7aYC4gRz88skWiRhErLuBq8RQMa-EGO9d9_4OZw@mail.gmail.com>
Message-ID: <CABEEk17jBQkn7gf7Q0MUqEbqkojza0NsO84YnVWzHFFD3rCJLQ@mail.gmail.com>

Hi Bert,

Agreed on carefully testing. I would argue that implementationally this
would be the correct behaviour of evaluate_grid_volume() though. "0
displacement" and "cannot compute displacement" are two very different
things, and it should be up to the caller to decide how to interpret these.

-- A

On Thu, Aug 18, 2016 at 11:36 AM, Robert D. Vincent <
robert.d.vincent at mcgill.ca> wrote:

> Hi Alex,
>
> Sure, it's possible, but I would have to be careful about the unintended
> consequences. My biggest issue is how the change might affect some of the
> clients of the transform functions. At the very least the change would be
> the effect on some of the libminc tests - several would have to be modified
> to account for the change in behavior of general_transform_point() and its
> ilk.
>
>     -bert
>
> On Thu, Aug 18, 2016 at 11:00 AM, Alex Zijdenbos <zijdenbos at gmail.com>
> wrote:
>
> > Hi all,
> >
> > Thanks for all your input. I'm still trying to figure out how to do what
> I
> > want, which is really to convert an arbitrary xfm into a deformation
> field
> > and have everything "just work", but I have some ideas that I'll pursue.
> >
> > Bert, whatever the "right thing" is for mincresample, I'm pretty sure we
> > don't want to change its current behaviour; however, do you think it
> would
> > be feasible to add an option to it to control this? Would require
> > implementing what you suggest, and then adding a mincresample option to
> > insert the fill value as opposed to assuming '0 displacement'.
> >
> > -- A
> >
> >
> >
> > On Thu, Aug 18, 2016 at 10:37 AM, Robert D. Vincent <
> > robert.d.vincent at mcgill.ca> wrote:
> >
> > > Hi all,
> > >
> > > The core of the issue from an implementation perspective is the
> function
> > > evaluate_grid_volume(), which is responsible for evaluating the grid
> > > transform for a point in world space. If the point lies outside the
> grid,
> > > this function silently returns zero for all of the displacements, so
> the
> > > point is not transformed and the original data is copied.
> > >
> > > It is trivial to modify this function to return an error indication if
> > the
> > > point is outside the grid, so that the resampling process could "do the
> > > right thing", whatever that is...
> > >
> > >     -bert
> > >
> > > On Wed, Aug 17, 2016 at 8:38 PM, Andrew Janke <a.janke at gmail.com>
> wrote:
> > >
> > > > 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
> > > > _______________________________________________
> > > > 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
>
>

From Oury.Monchi at ucalgary.ca  Mon Aug 22 16:56:08 2016
From: Oury.Monchi at ucalgary.ca (Oury Monchi)
Date: Mon, 22 Aug 2016 20:56:08 +0000
Subject: [MINC-users] Job opening
Message-ID: <70F2A595-55DD-49DD-A44A-3F7C88C34D67@ucalgary.ca>

Dear all,

Bruce Pike and I would like to bring to your attention this job opening in Calgary :

http://careers.ucalgary.ca/jobs/5751065-senior-research-associate-clinical-neurosciences-cumming-school-of-medicine

Best,
Oury.

-----------------------------------------------------------------
Oury Monchi, PhD
Professor and Tourmaline Chair in Parkinson?s Disease
Canada Research Chair in Non-Motor Symptoms of Parkinson?s disease
Director of Clinical Research,
Departments of Clinical Neurosciences and Radiology,
Leader of the Movement Disorders Research Neuroteam,
Hotchkiss Brain Institute,
Cumming School of Medicine, University of Calgary.
Tel: 403-2208048
E-mail:oury.monchi at ucalgary.ca<mailto:oury.monchi at ucalgary.ca>
http://pcanlab.ca<http://pcanlab.ca/>/