From zijdenbos at gmail.com  Mon Nov 10 23:21:41 2014
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Mon, 10 Nov 2014 23:21:41 -0500
Subject: [MINC-users] minctracc bug in lattice generation
Message-ID: <CABEEk14oMUYVQanTdKjCXnjkej-VkQUfbiWw1Tz2b_8rH8fEsw@mail.gmail.com>

Hello all,

I stumbled across a fairly significant bug in minctracc's lattice
generation. In short, the world coordinates of the deformation field that
it generates are wrong, especially when the input volume(s) contain
non-standard direction cosines.

First of all, even when an input volume has no (standard) direction
cosines, the resulting grid file is not centered on the target volume:

 verify_nodircos.png
<https://docs.google.com/file/d/0B5fOtqpIs4sKOUhOVWx1NF9nazQ/edit?usp=drive_web>

This is by letting minctracc generate a deformation grid with a 12mm
isotropic step size. You can see that the bounding box of the resulting
deformation grid (red) is not centered on the bounding box of the input
volume (green). The minctracc call here was simply:

minctracc -nonlinear xcorr -step 12 12 12 -iter 1 <in.mnc> <in.mnc>
<out.xfm>

i.e., the volume registered to itself.

Now, when <in.mnc> contains non-standard direction cosines and the call
above is repeated while feeding the xfm of one call, into the next call via
the -transform option:

minctracc -nonlinear xcorr -step 12 12 12 -iter 1 <in.mnc> <in.mnc> <00.xfm>
minctracc -nonlinear xcorr -step 12 12 12 -iter 1 -transform <00.xfm>
<in.mnc> <in.mnc> <01.xfm>
...

something even stranger happens:

 verify_iter00.png
<https://docs.google.com/file/d/0B5fOtqpIs4sKSms2MVF0d0JNTTQ/edit?usp=drive_web>

 verify_iter01.png
<https://docs.google.com/file/d/0B5fOtqpIs4sKVUNlRkhhZ1FZMTg/edit?usp=drive_web>

 verify_iter02.png
<https://docs.google.com/file/d/0B5fOtqpIs4sKbjViYlF0dzBkdTQ/edit?usp=drive_web>

 verify_iter03.png
<https://docs.google.com/file/d/0B5fOtqpIs4sKckpCUEhGODB0QTQ/edit?usp=drive_web>

 verify_iter04.png
<https://docs.google.com/file/d/0B5fOtqpIs4sKR2NvRUx1MzQtVnM/edit?usp=drive_web>

The bounding box of the deformation grid drifts away, and very quickly
falls outside the data volumes - which is a big problem.

I suspect this may not have appeared as an issue yet, as the vast majority
of non-linear registrations probably happen in a standard MNI stereotaxic
space which doesn't have direction cosines; but as soon as you try to
non-linearly register native volumes (that are relatively likely to carry
non-standard direction cosines), you will be affected by this - although it
may go unnoticed, unless you actually look at the deformation fields you
are getting.

Now for fixing this - I stared a while at the code in init_lattice.c, but
had some trouble figuring out the coordinate handling there. Anybody more
familiar with that bit of code?

-- A

From a.janke at gmail.com  Tue Nov 11 00:23:49 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 11 Nov 2014 15:23:49 +1000
Subject: [MINC-users] minctracc bug in lattice generation
In-Reply-To: <CABEEk14oMUYVQanTdKjCXnjkej-VkQUfbiWw1Tz2b_8rH8fEsw@mail.gmail.com>
References: <CABEEk14oMUYVQanTdKjCXnjkej-VkQUfbiWw1Tz2b_8rH8fEsw@mail.gmail.com>
Message-ID: <CAG0CB222zeSRKhAXiMeVU-fipG7PwyXfFNv_UdLFn6EQvZ6cTQ@mail.gmail.com>

On 11 November 2014 14:21, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> I stumbled across a fairly significant bug in minctracc's lattice
> generation. In short, the world coordinates of the deformation field that
> it generates are wrong, especially when the input volume(s) contain
> non-standard direction cosines.

Does a test case with no direction cosines look similar but to a
lesser degree?  I have probably struck this before with grid files for
use in model generation but got around things by using an approach
like this:

   https://github.com/BIC-MNI/minc-widgets/blob/master/gennlxfm/gennlxfm

That is, I always give minctracc an input xfm in order to determine
the bounds of the output xfm.


a

From zijdenbos at gmail.com  Tue Nov 11 07:11:17 2014
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Tue, 11 Nov 2014 07:11:17 -0500
Subject: [MINC-users] minctracc bug in lattice generation
In-Reply-To: <CAG0CB222zeSRKhAXiMeVU-fipG7PwyXfFNv_UdLFn6EQvZ6cTQ@mail.gmail.com>
References: <CABEEk14oMUYVQanTdKjCXnjkej-VkQUfbiWw1Tz2b_8rH8fEsw@mail.gmail.com>
	<CAG0CB222zeSRKhAXiMeVU-fipG7PwyXfFNv_UdLFn6EQvZ6cTQ@mail.gmail.com>
Message-ID: <CABEEk16adi4qvrBRM_kXndmrH8A8G4-R7xBsiU3kxJY-Fk9V0w@mail.gmail.com>

On Tue, Nov 11, 2014 at 12:23 AM, Andrew Janke <a.janke at gmail.com> wrote:

> On 11 November 2014 14:21, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> > I stumbled across a fairly significant bug in minctracc's lattice
> > generation. In short, the world coordinates of the deformation field that
> > it generates are wrong, especially when the input volume(s) contain
> > non-standard direction cosines.
>
> Does a test case with no direction cosines look similar but to a
> lesser degree?  I have probably struck this before with grid files for
> use in model generation but got around things by using an approach
> like this:
>
>    https://github.com/BIC-MNI/minc-widgets/blob/master/gennlxfm/gennlxfm
>
> That is, I always give minctracc an input xfm in order to determine
> the bounds of the output xfm.
>

I see. No - if the volume(s) have no direction cosines, the 'drift' in the
deformation grid lattice does not happen (at all). In that case the only
problem is that the grid is not perfectly centered on the (target?) volume,
but it stays in place during multiple calls to minctracc.

By the way, if the target volume does have direction cosines, they are
inherited by the xfm, and they themselves don't change through multiple
minctracc invocations.

-- A

From louis.collins at mcgill.ca  Tue Nov 11 08:57:15 2014
From: louis.collins at mcgill.ca (D. Louis Collins)
Date: Tue, 11 Nov 2014 08:57:15 -0500
Subject: [MINC-users] minctracc bug in lattice generation
In-Reply-To: <CABEEk14oMUYVQanTdKjCXnjkej-VkQUfbiWw1Tz2b_8rH8fEsw@mail.gmail.com>
References: <CABEEk14oMUYVQanTdKjCXnjkej-VkQUfbiWw1Tz2b_8rH8fEsw@mail.gmail.com>
Message-ID: <84831D11-339B-407E-9D20-773632C9B3D7@mcgill.ca>

Hi all,

On centering: The lattice volume is not supposed to be centered on the existing data volume centre.  It is centred on the thresholded foreground stored within the data volume.  From memory, the default threshold is 5% (or perhaps 10%) of the mean value of the dataset.

In the image you show, the green outline (which I assume to be the grid) is centred on the foreground, so this is working well.

for the dircos issues, this has changed multiple times in the life of minctracc.  early on, I had trouble with negative steps and relied on the ICV incorrectly.  This was fixed, but I think other bugs were introduced (or made apparent).  I generally apply minctracc only to data with identity discos directions.  I?ve not been bothered to fix it.

-Louis


On Nov 10, 2014, at 11:21 PM, Alex Zijdenbos <zijdenbos at gmail.com> wrote:

> Hello all,
> 
> I stumbled across a fairly significant bug in minctracc's lattice
> generation. In short, the world coordinates of the deformation field that
> it generates are wrong, especially when the input volume(s) contain
> non-standard direction cosines.
> 
> First of all, even when an input volume has no (standard) direction
> cosines, the resulting grid file is not centered on the target volume:
> 
> verify_nodircos.png
> <https://docs.google.com/file/d/0B5fOtqpIs4sKOUhOVWx1NF9nazQ/edit?usp=drive_web>
> 
> This is by letting minctracc generate a deformation grid with a 12mm
> isotropic step size. You can see that the bounding box of the resulting
> deformation grid (red) is not centered on the bounding box of the input
> volume (green). The minctracc call here was simply:
> 
> minctracc -nonlinear xcorr -step 12 12 12 -iter 1 <in.mnc> <in.mnc>
> <out.xfm>
> 
> i.e., the volume registered to itself.
> 
> Now, when <in.mnc> contains non-standard direction cosines and the call
> above is repeated while feeding the xfm of one call, into the next call via
> the -transform option:
> 
> minctracc -nonlinear xcorr -step 12 12 12 -iter 1 <in.mnc> <in.mnc> <00.xfm>
> minctracc -nonlinear xcorr -step 12 12 12 -iter 1 -transform <00.xfm>
> <in.mnc> <in.mnc> <01.xfm>
> ...
> 
> something even stranger happens:
> 
> verify_iter00.png
> <https://docs.google.com/file/d/0B5fOtqpIs4sKSms2MVF0d0JNTTQ/edit?usp=drive_web>
> 
> verify_iter01.png
> <https://docs.google.com/file/d/0B5fOtqpIs4sKVUNlRkhhZ1FZMTg/edit?usp=drive_web>
> 
> verify_iter02.png
> <https://docs.google.com/file/d/0B5fOtqpIs4sKbjViYlF0dzBkdTQ/edit?usp=drive_web>
> 
> verify_iter03.png
> <https://docs.google.com/file/d/0B5fOtqpIs4sKckpCUEhGODB0QTQ/edit?usp=drive_web>
> 
> verify_iter04.png
> <https://docs.google.com/file/d/0B5fOtqpIs4sKR2NvRUx1MzQtVnM/edit?usp=drive_web>
> 
> The bounding box of the deformation grid drifts away, and very quickly
> falls outside the data volumes - which is a big problem.
> 
> I suspect this may not have appeared as an issue yet, as the vast majority
> of non-linear registrations probably happen in a standard MNI stereotaxic
> space which doesn't have direction cosines; but as soon as you try to
> non-linearly register native volumes (that are relatively likely to carry
> non-standard direction cosines), you will be affected by this - although it
> may go unnoticed, unless you actually look at the deformation fields you
> are getting.
> 
> Now for fixing this - I stared a while at the code in init_lattice.c, but
> had some trouble figuring out the coordinate handling there. Anybody more
> familiar with that bit of code?
> 
> -- A
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


From zijdenbos at gmail.com  Tue Nov 11 10:24:23 2014
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Tue, 11 Nov 2014 10:24:23 -0500
Subject: [MINC-users] minctracc bug in lattice generation
In-Reply-To: <84831D11-339B-407E-9D20-773632C9B3D7@mcgill.ca>
References: <CABEEk14oMUYVQanTdKjCXnjkej-VkQUfbiWw1Tz2b_8rH8fEsw@mail.gmail.com>
	<84831D11-339B-407E-9D20-773632C9B3D7@mcgill.ca>
Message-ID: <CABEEk15+XQ0gTWVa8BZ_z6HP7NuHEeHGVy15TXcscG5Fo6fB=A@mail.gmail.com>

Hi Louis,

In my image examples, the green outline is the bounding box of the data
volume (identical source and target volumes); the red outline is the extent
of the grid_0.mnc file that minctracc produces. I tried the same thing with
an image made up of all ones, and that still shows that the grid lattice
(red) is not centered on the input volume (green):

 verify_iter00.png
<https://docs.google.com/file/d/0B5fOtqpIs4sKc2tkazFxZHpCelE/edit?usp=drive_web>

However, if I change the step size of the data volume to be positive (they
were all negative steps), the grid _does_ end up centered:

 verify_iter00.png
<https://docs.google.com/file/d/0B5fOtqpIs4sKQzlnSy1NZFRwY0U/edit?usp=drive_web>

This is with identity direction cosines. So the off-center issue seems to
be driven by negative step sizes (only).

However, the drift in the grid lattice due to non-identity direction
cosines, happens either way, but does change direction with the sign of the
step. With negative step sizes (5 calls to minctracc):

 animation.gif
<https://docs.google.com/file/d/0B5fOtqpIs4sKTkFfbk02UncyMlE/edit?usp=drive_web>

changing to positive step sizes:

 animation.gif
<https://docs.google.com/file/d/0B5fOtqpIs4sKZ3BLdU1HSGMzbms/edit?usp=drive_web>

So, my conclusion at the moment is that minctracc only generates a "good"
grid lattice if the data volume has both positive steps AND identity
direction cosines. Although that does cover the most-used case of
non-linear registration of stereotaxic/MNI/ICBM space data, for any other
data there be dragons.

-- A

On Tue, Nov 11, 2014 at 8:57 AM, D. Louis Collins <louis.collins at mcgill.ca>
wrote:

> Hi all,
>
> On centering: The lattice volume is not supposed to be centered on the
> existing data volume centre.  It is centred on the thresholded foreground
> stored within the data volume.  From memory, the default threshold is 5%
> (or perhaps 10%) of the mean value of the dataset.
>
> In the image you show, the green outline (which I assume to be the grid)
> is centred on the foreground, so this is working well.
>
> for the dircos issues, this has changed multiple times in the life of
> minctracc.  early on, I had trouble with negative steps and relied on the
> ICV incorrectly.  This was fixed, but I think other bugs were introduced
> (or made apparent).  I generally apply minctracc only to data with identity
> discos directions.  I've not been bothered to fix it.
>
> -Louis
>
>
> On Nov 10, 2014, at 11:21 PM, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
>
> > Hello all,
> >
> > I stumbled across a fairly significant bug in minctracc's lattice
> > generation. In short, the world coordinates of the deformation field that
> > it generates are wrong, especially when the input volume(s) contain
> > non-standard direction cosines.
> >
> > First of all, even when an input volume has no (standard) direction
> > cosines, the resulting grid file is not centered on the target volume:
> >
> > verify_nodircos.png
> > <
> https://docs.google.com/file/d/0B5fOtqpIs4sKOUhOVWx1NF9nazQ/edit?usp=drive_web
> >
> >
> > This is by letting minctracc generate a deformation grid with a 12mm
> > isotropic step size. You can see that the bounding box of the resulting
> > deformation grid (red) is not centered on the bounding box of the input
> > volume (green). The minctracc call here was simply:
> >
> > minctracc -nonlinear xcorr -step 12 12 12 -iter 1 <in.mnc> <in.mnc>
> > <out.xfm>
> >
> > i.e., the volume registered to itself.
> >
> > Now, when <in.mnc> contains non-standard direction cosines and the call
> > above is repeated while feeding the xfm of one call, into the next call
> via
> > the -transform option:
> >
> > minctracc -nonlinear xcorr -step 12 12 12 -iter 1 <in.mnc> <in.mnc>
> <00.xfm>
> > minctracc -nonlinear xcorr -step 12 12 12 -iter 1 -transform <00.xfm>
> > <in.mnc> <in.mnc> <01.xfm>
> > ...
> >
> > something even stranger happens:
> >
> > verify_iter00.png
> > <
> https://docs.google.com/file/d/0B5fOtqpIs4sKSms2MVF0d0JNTTQ/edit?usp=drive_web
> >
> >
> > verify_iter01.png
> > <
> https://docs.google.com/file/d/0B5fOtqpIs4sKVUNlRkhhZ1FZMTg/edit?usp=drive_web
> >
> >
> > verify_iter02.png
> > <
> https://docs.google.com/file/d/0B5fOtqpIs4sKbjViYlF0dzBkdTQ/edit?usp=drive_web
> >
> >
> > verify_iter03.png
> > <
> https://docs.google.com/file/d/0B5fOtqpIs4sKckpCUEhGODB0QTQ/edit?usp=drive_web
> >
> >
> > verify_iter04.png
> > <
> https://docs.google.com/file/d/0B5fOtqpIs4sKR2NvRUx1MzQtVnM/edit?usp=drive_web
> >
> >
> > The bounding box of the deformation grid drifts away, and very quickly
> > falls outside the data volumes - which is a big problem.
> >
> > I suspect this may not have appeared as an issue yet, as the vast
> majority
> > of non-linear registrations probably happen in a standard MNI stereotaxic
> > space which doesn't have direction cosines; but as soon as you try to
> > non-linearly register native volumes (that are relatively likely to carry
> > non-standard direction cosines), you will be affected by this - although
> it
> > may go unnoticed, unless you actually look at the deformation fields you
> > are getting.
> >
> > Now for fixing this - I stared a while at the code in init_lattice.c, but
> > had some trouble figuring out the coordinate handling there. Anybody more
> > familiar with that bit of code?
> >
> > -- A
> > _______________________________________________
> > 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 a.janke at gmail.com  Tue Nov 11 15:31:30 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 12 Nov 2014 06:31:30 +1000
Subject: [MINC-users] minctracc bug in lattice generation
In-Reply-To: <CABEEk16adi4qvrBRM_kXndmrH8A8G4-R7xBsiU3kxJY-Fk9V0w@mail.gmail.com>
References: <CABEEk14oMUYVQanTdKjCXnjkej-VkQUfbiWw1Tz2b_8rH8fEsw@mail.gmail.com>
	<CAG0CB222zeSRKhAXiMeVU-fipG7PwyXfFNv_UdLFn6EQvZ6cTQ@mail.gmail.com>
	<CABEEk16adi4qvrBRM_kXndmrH8A8G4-R7xBsiU3kxJY-Fk9V0w@mail.gmail.com>
Message-ID: <CAG0CB234_tQdb=rjsJqqj312d-rVF3qk=Wm7YyD2X5U_456A_Q@mail.gmail.com>

On 11 November 2014 22:11, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> I see. No - if the volume(s) have no direction cosines, the 'drift' in the
> deformation grid lattice does not happen (at all). In that case the only
> problem is that the grid is not perfectly centered on the (target?) volume,
> but it stays in place during multiple calls to minctracc.

OK, so it's a direction cosines only bug (well direction cosines other
than identity!). Note that as Louis points out the grid shouldn't be
centred on the volume but on the thresholded volume extents.

> By the way, if the target volume does have direction cosines, they are
> inherited by the xfm, and they themselves don't change through multiple
> minctracc invocations.

OK.

Do you have a minimal test case? (large voxels, made with
make_phantom?) if so then we should file an issue on github, actually
I just looked and Vladimir has beaten me to the punch.

   https://github.com/BIC-MNI/mni_autoreg/issues/9

a

From zijdenbos at gmail.com  Tue Nov 11 21:36:24 2014
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Tue, 11 Nov 2014 21:36:24 -0500
Subject: [MINC-users] minctracc bug in lattice generation
In-Reply-To: <CAG0CB234_tQdb=rjsJqqj312d-rVF3qk=Wm7YyD2X5U_456A_Q@mail.gmail.com>
References: <CABEEk14oMUYVQanTdKjCXnjkej-VkQUfbiWw1Tz2b_8rH8fEsw@mail.gmail.com>
	<CAG0CB222zeSRKhAXiMeVU-fipG7PwyXfFNv_UdLFn6EQvZ6cTQ@mail.gmail.com>
	<CABEEk16adi4qvrBRM_kXndmrH8A8G4-R7xBsiU3kxJY-Fk9V0w@mail.gmail.com>
	<CAG0CB234_tQdb=rjsJqqj312d-rVF3qk=Wm7YyD2X5U_456A_Q@mail.gmail.com>
Message-ID: <CABEEk15qnsJth=CgYS6Jrm+j8t5ESdZYiWs8uOrNJJqnXZd7Hw@mail.gmail.com>

On Tue, Nov 11, 2014 at 3:31 PM, Andrew Janke <a.janke at gmail.com> wrote:
>
> OK, so it's a direction cosines only bug (well direction cosines other
> than identity!). Note that as Louis points out the grid shouldn't be
> centred on the volume but on the thresholded volume extents.

Did my followup post come through? When volume step(s) are negative,
the grid isn't properly centered either (regardless of thresholding).
The only time you get a "good" grid out of minctracc seems to be with
identity direction cosines and positive steps.

> Do you have a minimal test case? (large voxels, made with
> make_phantom?) if so then we should file an issue on github, actually
> I just looked and Vladimir has beaten me to the punch.
>
>    https://github.com/BIC-MNI/mni_autoreg/issues/9

Yup he did :-) and I do [have a test case]. I'll minimalize it/clean
it up and put it on github tomorrow-ish, together with a little
testing script.

-- A

From gdevenyi at gmail.com  Tue Nov 18 14:49:40 2014
From: gdevenyi at gmail.com (Gabriel A. Devenyi)
Date: Tue, 18 Nov 2014 14:49:40 -0500
Subject: [MINC-users] Variations on normalization of minc volumes in
	minc-toolkit
Message-ID: <CAFQOoOoe-NYwSi+QXHcb1u5ccauryXoRhoZVeRNjA_ki5QftyA@mail.gmail.com>

Hi All,

I?m working on streamlining a
?parallel grid-aware ?
preprocessing pipeline using bpipe (see https://code.google.com/p/bpipe/
and https://github.com/CobraLab/bpipe-library) and I?ve come across these
normalization tools within minc-toolkit:

minc_nuyl - documented at http://www.ncbi.nlm.nih.gov/pubmed/10784285
volume_pol - no documentation?
inormalize - no documentation?
normalize_mri - wrapper for inormalize

Is there any documentation out there regarding these tools (what they do,
and how they do it).

Additionally, are there any details on the requirements to apply these
tools?

For example, the source header in inormalize.cc I think indicates that the
volumes must be registered, is that correct?


Can anyone provide any insights on these tools? Thanks!?

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

From a.janke at gmail.com  Tue Nov 18 19:03:44 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 19 Nov 2014 10:03:44 +1000
Subject: [MINC-users] Variations on normalization of minc volumes in
	minc-toolkit
In-Reply-To: <CAFQOoOoe-NYwSi+QXHcb1u5ccauryXoRhoZVeRNjA_ki5QftyA@mail.gmail.com>
References: <CAFQOoOoe-NYwSi+QXHcb1u5ccauryXoRhoZVeRNjA_ki5QftyA@mail.gmail.com>
Message-ID: <CAG0CB23WY_J31ryzicVdEMQa5oPGiMCK6vTH4TUdLFObtg=tkQ@mail.gmail.com>

Hi Gabriel,

I'll comment on the one I know.

inormalize was written by Alex Z and yes it does require volumes to be
aligned to a model. There are a few different ways it can be used to
calculate the map between the two volumes (or even between slices
within one file). These are detailed in the "Solution options" section
of inormalize -help.

I tend to use it like this (I've simplified a bit):

      # calculate normalisation
      map="map.txt"
      if [ ! -e $map ]
      then
         inormalize \
            -nonormalize -print -quiet \
            -model model.mnc \
            -mask model_mask.mnc \
            $infile |\
            sed -e 's/^\ \ //' -e 's/(//' -e 's/\,//' -e 's/)//' |\
            tee $map
      fi

      # apply it
      scale=$(grep medianOfRatios $map | cut -f2 -d\ )
      offset=$(grep medianOfRatios $map | cut -f3 -d\ )
      minccalc -clobber \
         -expression "$offset + $scale*A[0]" \
         $infile $outfile


Note that I separate out the calculation and the subsequent
application of the normalization via minccalc, at the time inormalize
was written I don't think minccalc existed so I doubt you'll find this
method in any of the examples!


a


On 19 November 2014 05:49, Gabriel A. Devenyi <gdevenyi at gmail.com> wrote:
> Hi All,
>
> I'm working on streamlining a
> parallel grid-aware
> preprocessing pipeline using bpipe (see https://code.google.com/p/bpipe/
> and https://github.com/CobraLab/bpipe-library) and I've come across these
> normalization tools within minc-toolkit:
>
> minc_nuyl - documented at http://www.ncbi.nlm.nih.gov/pubmed/10784285
> volume_pol - no documentation?
> inormalize - no documentation?
> normalize_mri - wrapper for inormalize
>
> Is there any documentation out there regarding these tools (what they do,
> and how they do it).
>
> Additionally, are there any details on the requirements to apply these
> tools?
>
> For example, the source header in inormalize.cc I think indicates that the
> volumes must be registered, is that correct?
>
>
> Can anyone provide any insights on these tools? Thanks!
>
>
> --
> Gabriel A. Devenyi B.Eng. Ph.D.
> Research Computing Associate
> Computational Brain Anatomy Laboratory
> Cerebral Imaging Center
> Douglas Mental Health University Institute
> 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 zijdenbos at gmail.com  Wed Nov 19 08:43:20 2014
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Wed, 19 Nov 2014 08:43:20 -0500
Subject: [MINC-users] Variations on normalization of minc volumes in
	minc-toolkit
In-Reply-To: <CAG0CB23WY_J31ryzicVdEMQa5oPGiMCK6vTH4TUdLFObtg=tkQ@mail.gmail.com>
References: <CAFQOoOoe-NYwSi+QXHcb1u5ccauryXoRhoZVeRNjA_ki5QftyA@mail.gmail.com>
	<CAG0CB23WY_J31ryzicVdEMQa5oPGiMCK6vTH4TUdLFObtg=tkQ@mail.gmail.com>
Message-ID: <CABEEk14B6tp+590jFZaAaL2fhJCiLw3rhQz0pqLfbNfBcC1XCw@mail.gmail.com>

Just to follow up on Andrew J's explanation: Yes inormalize predates
minccalc by quite a few years :-) It's now somewhat obsolete though. I
actually started writing a perl wrapper around minccalc that
reproduces the functionality of inormalize. It currently is missing a
few of inormalize's options though, but it will hopefully become a
drop-in replacement.nyul

normalize_mri is indeed a wrapper around inormalize, which plays some
tricks by generating masks that may help with volume-to-volume
normalization. By the way inormalize can also do volume-to-constant
normalization, which only requires one input volume.

volume_pol and minc_nuyl both seem to be part of minc-toolkit - I bet
Vladimir can speak to these?

-- A

On Tue, Nov 18, 2014 at 7:03 PM, Andrew Janke <a.janke at gmail.com> wrote:
> Hi Gabriel,
>
> I'll comment on the one I know.
>
> inormalize was written by Alex Z and yes it does require volumes to be
> aligned to a model. There are a few different ways it can be used to
> calculate the map between the two volumes (or even between slices
> within one file). These are detailed in the "Solution options" section
> of inormalize -help.
>
> I tend to use it like this (I've simplified a bit):
>
>       # calculate normalisation
>       map="map.txt"
>       if [ ! -e $map ]
>       then
>          inormalize \
>             -nonormalize -print -quiet \
>             -model model.mnc \
>             -mask model_mask.mnc \
>             $infile |\
>             sed -e 's/^\ \ //' -e 's/(//' -e 's/\,//' -e 's/)//' |\
>             tee $map
>       fi
>
>       # apply it
>       scale=$(grep medianOfRatios $map | cut -f2 -d\ )
>       offset=$(grep medianOfRatios $map | cut -f3 -d\ )
>       minccalc -clobber \
>          -expression "$offset + $scale*A[0]" \
>          $infile $outfile
>
>
> Note that I separate out the calculation and the subsequent
> application of the normalization via minccalc, at the time inormalize
> was written I don't think minccalc existed so I doubt you'll find this
> method in any of the examples!
>
>
> a
>
>
> On 19 November 2014 05:49, Gabriel A. Devenyi <gdevenyi at gmail.com> wrote:
>> Hi All,
>>
>> I'm working on streamlining a
>> parallel grid-aware
>> preprocessing pipeline using bpipe (see https://code.google.com/p/bpipe/
>> and https://github.com/CobraLab/bpipe-library) and I've come across these
>> normalization tools within minc-toolkit:
>>
>> minc_nuyl - documented at http://www.ncbi.nlm.nih.gov/pubmed/10784285
>> volume_pol - no documentation?
>> inormalize - no documentation?
>> normalize_mri - wrapper for inormalize
>>
>> Is there any documentation out there regarding these tools (what they do,
>> and how they do it).
>>
>> Additionally, are there any details on the requirements to apply these
>> tools?
>>
>> For example, the source header in inormalize.cc I think indicates that the
>> volumes must be registered, is that correct?
>>
>>
>> Can anyone provide any insights on these tools? Thanks!
>>
>>
>> --
>> Gabriel A. Devenyi B.Eng. Ph.D.
>> Research Computing Associate
>> Computational Brain Anatomy Laboratory
>> Cerebral Imaging Center
>> Douglas Mental Health University Institute
>> 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
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From winterburn.julie at gmail.com  Wed Nov 19 17:41:09 2014
From: winterburn.julie at gmail.com (Julie Winterburn)
Date: Wed, 19 Nov 2014 17:41:09 -0500
Subject: [MINC-users] Display 3D window not loading with minc-toolkit 1.0.01
Message-ID: <CADkSHQR4H7jVDquXUeoF_-ythja3FujMpGybd-1HXhVOCfVoGQ@mail.gmail.com>

Hi,

The 3D window in Display doesn't load when you run Display with
minc-toolkit 1.0.01, and I can't seem to find a way to get it to open once
the program is already running. With previous versions, all 3 Display
windows would all load together. Has anyone else been encountering this
problem?

Thanks,
Julie

From vladimir.fonov at gmail.com  Wed Nov 19 17:50:48 2014
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Wed, 19 Nov 2014 17:50:48 -0500
Subject: [MINC-users] Display 3D window not loading with minc-toolkit
	1.0.01
In-Reply-To: <CADkSHQR4H7jVDquXUeoF_-ythja3FujMpGybd-1HXhVOCfVoGQ@mail.gmail.com>
References: <CADkSHQR4H7jVDquXUeoF_-ythja3FujMpGybd-1HXhVOCfVoGQ@mail.gmail.com>
Message-ID: <5AD5D549-E55E-479D-8405-3900C820D3CF@gmail.com>

It?s a feature introduced by certain folks who never use 3D view. To disable it run Display with option -global Hide_3D_window FALSE , or copy  file /opt/minc/lib/Display.globals into your home directory 

and add line ?  Hide_3D_window = FALSE ;  ? there .



On Nov 19, 2014, at 5:41 PM, Julie Winterburn <winterburn.julie at gmail.com> wrote:

> Hi,
> 
> The 3D window in Display doesn't load when you run Display with
> minc-toolkit 1.0.01, and I can't seem to find a way to get it to open once
> the program is already running. With previous versions, all 3 Display
> windows would all load together. Has anyone else been encountering this
> problem?
> 
> Thanks,
> Julie
> _______________________________________________
> 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





From najma at bic.mni.mcgill.ca  Sun Nov 23 11:47:56 2014
From: najma at bic.mni.mcgill.ca (Najmeh Khalili-Mahani)
Date: Sun, 23 Nov 2014 11:47:56 -0500 (EST)
Subject: [MINC-users] mrisim
Message-ID: <Pine.LNX.4.64.1411231143090.6524@agrippa.bic.mni.mcgill.ca>


Hi,

I was wondering if anyone knows if/where to find "mrisim"; and 
whishfully, any documentations on it?

Much thanks
Najma


From a.janke at gmail.com  Sun Nov 23 21:39:29 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 24 Nov 2014 12:39:29 +1000
Subject: [MINC-users] mrisim
In-Reply-To: <Pine.LNX.4.64.1411231143090.6524@agrippa.bic.mni.mcgill.ca>
References: <Pine.LNX.4.64.1411231143090.6524@agrippa.bic.mni.mcgill.ca>
Message-ID: <CAG0CB23=+G=yGPuOBRGAAf_WhWibc4mWLbmgUcEKewp2YeW+NQ@mail.gmail.com>

Hi Najma,

mrisim is included in minc-toolkit

   https://github.com/BIC-MNI/minc-toolkit

There is some documentation here:

   https://github.com/BIC-MNI/mrisim/tree/master/doc



a

On 24 November 2014 at 02:47, Najmeh Khalili-Mahani
<najma at bic.mni.mcgill.ca> wrote:
>
> Hi,
>
> I was wondering if anyone knows if/where to find "mrisim"; and whishfully,
> any documentations on it?
>
> Much thanks
> Najma
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From najma at bic.mni.mcgill.ca  Mon Nov 24 17:01:35 2014
From: najma at bic.mni.mcgill.ca (Najmeh Khalili-Mahani)
Date: Mon, 24 Nov 2014 17:01:35 -0500 (EST)
Subject: [MINC-users] mrisim
In-Reply-To: <CAG0CB23=+G=yGPuOBRGAAf_WhWibc4mWLbmgUcEKewp2YeW+NQ@mail.gmail.com>
References: <Pine.LNX.4.64.1411231143090.6524@agrippa.bic.mni.mcgill.ca>
	<CAG0CB23=+G=yGPuOBRGAAf_WhWibc4mWLbmgUcEKewp2YeW+NQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1411241653580.12799@agrippa.bic.mni.mcgill.ca>


Thank you Andrew, also Alex and Bert for locating it and 
sending the documentation..

So, as I understand

- this is not part of the "minctools" package and must be 
installed separately (obtained from https://github.com/BIC-MNI/mrisim);
- and it is not available through login.bic (I assume this is to prevent running 
high-compute processes on this server?), but it can be found on 
the server that runs the brainweb.
- but it is readily part of the "minc-tookit", and also included 
in the minc-toolkit-1.0.01-20131211-Darwin-x86_64.dmg package 
for MAC.

Cheers
N.

  On Mon, 24 Nov 2014, Andrew Janke wrote:

> Hi Najma,
>
> mrisim is included in minc-toolkit
>
>   https://github.com/BIC-MNI/minc-toolkit
>
> There is some documentation here:
>
>   https://github.com/BIC-MNI/mrisim/tree/master/doc
>
>
>
> a
>
> On 24 November 2014 at 02:47, Najmeh Khalili-Mahani
> <najma at bic.mni.mcgill.ca> wrote:
>>
>> Hi,
>>
>> I was wondering if anyone knows if/where to find "mrisim"; and whishfully,
>> any documentations on it?
>>
>> Much thanks
>> Najma
>>
>> _______________________________________________
>> 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 bert at bic.mni.mcgill.ca  Mon Nov 24 10:44:27 2014
From: bert at bic.mni.mcgill.ca (Robert VINCENT)
Date: Mon, 24 Nov 2014 10:44:27 -0500 (EST)
Subject: [MINC-users] mrisim
In-Reply-To: <Pine.LNX.4.64.1411231143090.6524@agrippa.bic.mni.mcgill.ca>
References: <Pine.LNX.4.64.1411231143090.6524@agrippa.bic.mni.mcgill.ca>
Message-ID: <Pine.LNX.4.64.1411241037570.8625@agrippa.bic.mni.mcgill.ca>

Hi Najma,

As Andrew said, it is available on Github. There is some limited 
documentation included in the package. I've enclosed a PDF file of the
man page.

The individual project's source can be copied to your system with the 
command:

git clone https://github.com/BIC-MNI/mrisim.git

     -bert

On Sun, 23 Nov 2014, Najmeh Khalili-Mahani wrote:

>
> Hi,
>
> I was wondering if anyone knows if/where to find "mrisim"; and whishfully, 
> any documentations on it?
>
> Much thanks
> Najma
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From najma at bic.mni.mcgill.ca  Thu Nov 27 11:31:32 2014
From: najma at bic.mni.mcgill.ca (Najmeh Khalili-Mahani)
Date: Thu, 27 Nov 2014 11:31:32 -0500 (EST)
Subject: [MINC-users] Install Emma on Mac (or a Shepp-logan (3D) minc file?
	:))
Message-ID: <Pine.LNX.4.64.1411271123490.14503@agrippa.bic.mni.mcgill.ca>


Hi,

I was wondering if someone can help me with instructions on installing 
EMMA (found it on Github) on OSx.

Alternatively, if someone has a 3D shepp-logan phantom in 
MINC/NIFTI to share, I would be much grateful :)

All the best,
Najma


From a.janke at gmail.com  Thu Nov 27 15:07:04 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 28 Nov 2014 06:07:04 +1000
Subject: [MINC-users] Install Emma on Mac (or a Shepp-logan (3D) minc
 file? :))
In-Reply-To: <Pine.LNX.4.64.1411271123490.14503@agrippa.bic.mni.mcgill.ca>
References: <Pine.LNX.4.64.1411271123490.14503@agrippa.bic.mni.mcgill.ca>
Message-ID: <CAG0CB20M102Shc8se_WGxRRkH5yrFEc49=tqO-rUAiiQtQUoZg@mail.gmail.com>

Hi Najmeh

> I was wondering if someone can help me with instructions on installing EMMA
> (found it on Github) on OSx.

EMMA has been long obsoleted by Pierre Bellecs NIAK

   https://github.com/SIMEXP/niak

> Alternatively, if someone has a 3D shepp-logan phantom in MINC/NIFTI to
> share, I would be much grateful :)

NIAK should allow you to import the MATLAB phantom.


a

From najma at bic.mni.mcgill.ca  Thu Nov 27 17:18:38 2014
From: najma at bic.mni.mcgill.ca (Najmeh Khalili-Mahani)
Date: Thu, 27 Nov 2014 17:18:38 -0500 (EST)
Subject: [MINC-users] Install Emma on Mac (or a Shepp-logan (3D) minc
 file? :))
In-Reply-To: <CAG0CB20M102Shc8se_WGxRRkH5yrFEc49=tqO-rUAiiQtQUoZg@mail.gmail.com>
References: <Pine.LNX.4.64.1411271123490.14503@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20M102Shc8se_WGxRRkH5yrFEc49=tqO-rUAiiQtQUoZg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1411271651530.25541@agrippa.bic.mni.mcgill.ca>


Hi Andrew, thanks, I missed the ousting of EMMA while 
away from MINC, but glad to have found niak_write_minc.m.

So, surfstat and fmristat no longer depend on EMMA either, 
correct?

Thanks
Naj


On Fri, 28 Nov 2014, Andrew Janke wrote:

> Hi Najmeh
>
>> I was wondering if someone can help me with instructions on installing EMMA
>> (found it on Github) on OSx.
>

> EMMA has been long obsoleted by Pierre Bellecs NIAK
>
>   https://github.com/SIMEXP/niak
>
>> Alternatively, if someone has a 3D shepp-logan phantom in MINC/NIFTI to
>> share, I would be much grateful :)
>
> NIAK should allow you to import the MATLAB phantom.
>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


From a.janke at gmail.com  Thu Nov 27 18:17:47 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 28 Nov 2014 09:17:47 +1000
Subject: [MINC-users] Install Emma on Mac (or a Shepp-logan (3D) minc
 file? :))
In-Reply-To: <Pine.LNX.4.64.1411271651530.25541@agrippa.bic.mni.mcgill.ca>
References: <Pine.LNX.4.64.1411271123490.14503@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20M102Shc8se_WGxRRkH5yrFEc49=tqO-rUAiiQtQUoZg@mail.gmail.com>
	<Pine.LNX.4.64.1411271651530.25541@agrippa.bic.mni.mcgill.ca>
Message-ID: <CAG0CB20u=TOvVNLiS8EV0GSsSmxL7Ro6rrHQi+wG9i6Aa5N_mA@mail.gmail.com>

> So, surfstat and fmristat no longer depend on EMMA either, correct?

They no doubt still will. However it us my understanding that Pierre
has re-implemented most of their functionality in NIAK.


a

From eskild at gmail.com  Fri Nov 28 03:39:47 2014
From: eskild at gmail.com (Simon Eskildsen)
Date: Fri, 28 Nov 2014 09:39:47 +0100
Subject: [MINC-users] Install Emma on Mac (or a Shepp-logan (3D) minc
 file? :))
In-Reply-To: <CAG0CB20u=TOvVNLiS8EV0GSsSmxL7Ro6rrHQi+wG9i6Aa5N_mA@mail.gmail.com>
References: <Pine.LNX.4.64.1411271123490.14503@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20M102Shc8se_WGxRRkH5yrFEc49=tqO-rUAiiQtQUoZg@mail.gmail.com>
	<Pine.LNX.4.64.1411271651530.25541@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20u=TOvVNLiS8EV0GSsSmxL7Ro6rrHQi+wG9i6Aa5N_mA@mail.gmail.com>
Message-ID: <CAD3v434Em+2qguuYAbka==XnuNQ2v4DkY2tJ=cNGv5kjk7UY_g@mail.gmail.com>

For what is worth, I'm using Surfstat without EMMA. There should be no
dependency.
Would I be able to replace Surfstat entirely with NIAK? It's primarily the
random field theory that I'm asking for. Pierre?

Simon

On Fri, Nov 28, 2014 at 12:17 AM, Andrew Janke <a.janke at gmail.com> wrote:

> > So, surfstat and fmristat no longer depend on EMMA either, correct?
>
> They no doubt still will. However it us my understanding that Pierre
> has re-implemented most of their functionality in NIAK.
>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From pierre.bellec at criugm.qc.ca  Fri Nov 28 09:31:17 2014
From: pierre.bellec at criugm.qc.ca (Pierre Bellec)
Date: Fri, 28 Nov 2014 09:31:17 -0500
Subject: [MINC-users] Install Emma on Mac (or a Shepp-logan (3D) minc
 file? :))
In-Reply-To: <CAD3v434Em+2qguuYAbka==XnuNQ2v4DkY2tJ=cNGv5kjk7UY_g@mail.gmail.com>
References: <Pine.LNX.4.64.1411271123490.14503@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20M102Shc8se_WGxRRkH5yrFEc49=tqO-rUAiiQtQUoZg@mail.gmail.com>
	<Pine.LNX.4.64.1411271651530.25541@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20u=TOvVNLiS8EV0GSsSmxL7Ro6rrHQi+wG9i6Aa5N_mA@mail.gmail.com>
	<CAD3v434Em+2qguuYAbka==XnuNQ2v4DkY2tJ=cNGv5kjk7UY_g@mail.gmail.com>
Message-ID: <CADPHwxDoayCrGi6scbAM47HTMkCmj6pJpg=ZROA=XS_jha0VPA@mail.gmail.com>

Dear all,

A quick update on EMMA's replacement. The NIAK has a reader/writer that's
based on standard minc tools (i.e. mincheader, minctoraw, rawtominc, maybe
mincinfo as well). That works pretty well for MRI / fMRI data, but not for
all things minc.
nitrc.org/projects/niak

I started years ago a project called MOMINC that is based on native
matlab/octave netcdf/hdf5 library, which do not require the installation of
any binary and should support any MINC file (including, say, ultrasound).
I'd say the project is 80% complete, and I believe it is viable, but
unfortunately has been stalled for a while now, because it's not really a
priority (it would be better, but very close to what already exists and
works). Hopefully this project will finally get finished in the
not-so-distant future thanks to the coming recruitment of a developer in my
lab.
https://code.google.com/p/mominc/

Re integration of fmristat in NIAK, this has also been an on-going project
for years, with Felix Carbonnell. Very similar status/prospects as MOMINC.
Note that, upon completion, there will be a full pipeline for within-run,
within-subject, between-subject inferences, not just a port of fMRIstat
modules. Nothing usable at this time.

Finally, I don't think surfstat reads or writes 3D volumes, and from what
I've heard it's excellent as is. I also believe that Felix maintains it (I
don't know if he is planning to add features in the future though).



Pierre Bellec
http://simexp-lab.org/brainwiki/doku.php?id=pierrebellec
Telephone              (1) 514 713 5596
SIMEXP lab            http://simexp-lab.org

On Fri, Nov 28, 2014 at 3:39 AM, Simon Eskildsen <eskild at gmail.com> wrote:

> For what is worth, I'm using Surfstat without EMMA. There should be no
> dependency.
> Would I be able to replace Surfstat entirely with NIAK? It's primarily the
> random field theory that I'm asking for. Pierre?
>
> Simon
>
> On Fri, Nov 28, 2014 at 12:17 AM, Andrew Janke <a.janke at gmail.com> wrote:
>
> > > So, surfstat and fmristat no longer depend on EMMA either, correct?
> >
> > They no doubt still will. However it us my understanding that Pierre
> > has re-implemented most of their functionality in NIAK.
> >
> >
> > a
> > _______________________________________________
> > 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
>