From andrew at biospective.com  Mon Feb  3 16:57:11 2014
From: andrew at biospective.com (Andrew Wood)
Date: Mon, 3 Feb 2014 16:57:11 -0500
Subject: [MINC-users] BIC Objects and Python
In-Reply-To: <Pine.LNX.4.64.1401291120440.29468@nestor.bic.mni.mcgill.ca>
References: <CABApf9EacDjhqgQvofXty2003KcktugeEwtxxApCzci53Ndmdw@mail.gmail.com>
	<CAG0CB22LoDuw2WkBJM8Ed1Xi1EtT4pEAbwzY4nta0+WbcnUbig@mail.gmail.com>
	<4D9CE990-6427-4582-9B43-F3636600B262@mouseimaging.ca>
	<20140129132504.GA2739@kensho.slice>
	<CAD3v435TfoXii37_nk10KMYj3PCskvrb=x4QuuqOWSFscFQ+tg@mail.gmail.com>
	<Pine.LNX.4.64.1401290902550.29468@nestor.bic.mni.mcgill.ca>
	<CAD3v435B2hH2xqY5Mw2S0tAbqZdV1=kwbe4vmfmQW8P+=pi3RA@mail.gmail.com>
	<Pine.LNX.4.64.1401290910230.29468@nestor.bic.mni.mcgill.ca>
	<20140129141859.GA3146@kensho.slice>
	<Pine.LNX.4.64.1401291120440.29468@nestor.bic.mni.mcgill.ca>
Message-ID: <CABApf9EqYZ3n-QRpf1v8ejG6bdp2FhxuChCViT+gA6f2a0HMvQ@mail.gmail.com>

Does anyone have thoughts on what would make the most sense, if someone
felt like implementing this?

1. write a parser from scratch in pure python
2. wrap libbicpl, like pyminc wraps libminc2
3. something else

Thanks,
Andrew


On Wed, Jan 29, 2014 at 11:21 AM, Sylvain Milot
<sylvain at bic.mni.mcgill.ca>wrote:

>
> you will find a section at http://www.bic.mni.mcgill.ca/Services/HowTo
>
> Sylvain
>
>
> On Wed, 29 Jan 2014, Jon Pipitone wrote:
>
>  Perhaps someone could either post the content to the list, or add it to
>> the Wikibook?
>>
>> Jon.
>>
>> On 01/29, Sylvain Milot wrote:
>>
>>>
>>> it is old and should be moved to the new platform.
>>>
>>> Sylvain
>>>
>>> On Wed, 29 Jan 2014, Simon Eskildsen wrote:
>>>
>>>  Yes, that's what I thought. Any reason for restricting public access?
>>>>
>>>> Simon
>>>>
>>>>
>>>> On Wed, Jan 29, 2014 at 3:05 PM, Sylvain Milot <
>>>> sylvain at bic.mni.mcgill.ca>wrote:
>>>>
>>>>
>>>>> This was part of the old wiki and you should find it here:
>>>>> http://wikiobs.bic.mni.mcgill.ca/index.php/ObjectFiles
>>>>>
>>>>> this will only be available inside the BIC network.
>>>>>
>>>>> Sylvain
>>>>>
>>>> _______________________________________________
>> 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 jason at mouseimaging.ca  Mon Feb  3 17:04:32 2014
From: jason at mouseimaging.ca (Jason Lerch)
Date: Mon, 3 Feb 2014 17:04:32 -0500
Subject: [MINC-users] BIC Objects and Python
In-Reply-To: <CABApf9EqYZ3n-QRpf1v8ejG6bdp2FhxuChCViT+gA6f2a0HMvQ@mail.gmail.com>
References: <CABApf9EacDjhqgQvofXty2003KcktugeEwtxxApCzci53Ndmdw@mail.gmail.com>
	<CAG0CB22LoDuw2WkBJM8Ed1Xi1EtT4pEAbwzY4nta0+WbcnUbig@mail.gmail.com>
	<4D9CE990-6427-4582-9B43-F3636600B262@mouseimaging.ca>
	<20140129132504.GA2739@kensho.slice>
	<CAD3v435TfoXii37_nk10KMYj3PCskvrb=x4QuuqOWSFscFQ+tg@mail.gmail.com>
	<Pine.LNX.4.64.1401290902550.29468@nestor.bic.mni.mcgill.ca>
	<CAD3v435B2hH2xqY5Mw2S0tAbqZdV1=kwbe4vmfmQW8P+=pi3RA@mail.gmail.com>
	<Pine.LNX.4.64.1401290910230.29468@nestor.bic.mni.mcgill.ca>
	<20140129141859.GA3146@kensho.slice>
	<Pine.LNX.4.64.1401291120440.29468@nestor.bic.mni.mcgill.ca>
	<CABApf9EqYZ3n-QRpf1v8ejG6bdp2FhxuChCViT+gA6f2a0HMvQ@mail.gmail.com>
Message-ID: <06CFA367-5D9B-4DA8-98DF-6A7D3D865AC8@mouseimaging.ca>

I would advocate for option 2; I suspect only a subset of functions that deal with obj files will need to be wrapped, and not all of bicpl. Option 2 also ensures that the obj format doesn?t accidentally diverge between different readers/writers.

Jason

On Feb 3, 2014, at 4:57 PM, Andrew Wood <andrew at biospective.com> wrote:

> Does anyone have thoughts on what would make the most sense, if someone
> felt like implementing this?
> 
> 1. write a parser from scratch in pure python
> 2. wrap libbicpl, like pyminc wraps libminc2
> 3. something else
> 
> Thanks,
> Andrew
> 
> 
> On Wed, Jan 29, 2014 at 11:21 AM, Sylvain Milot
> <sylvain at bic.mni.mcgill.ca>wrote:
> 
>> 
>> you will find a section at http://www.bic.mni.mcgill.ca/Services/HowTo
>> 
>> Sylvain
>> 
>> 
>> On Wed, 29 Jan 2014, Jon Pipitone wrote:
>> 
>> Perhaps someone could either post the content to the list, or add it to
>>> the Wikibook?
>>> 
>>> Jon.
>>> 
>>> On 01/29, Sylvain Milot wrote:
>>> 
>>>> 
>>>> it is old and should be moved to the new platform.
>>>> 
>>>> Sylvain
>>>> 
>>>> On Wed, 29 Jan 2014, Simon Eskildsen wrote:
>>>> 
>>>> Yes, that's what I thought. Any reason for restricting public access?
>>>>> 
>>>>> Simon
>>>>> 
>>>>> 
>>>>> On Wed, Jan 29, 2014 at 3:05 PM, Sylvain Milot <
>>>>> sylvain at bic.mni.mcgill.ca>wrote:
>>>>> 
>>>>> 
>>>>>> This was part of the old wiki and you should find it here:
>>>>>> http://wikiobs.bic.mni.mcgill.ca/index.php/ObjectFiles
>>>>>> 
>>>>>> this will only be available inside the BIC network.
>>>>>> 
>>>>>> Sylvain
>>>>>> 
>>>>> _______________________________________________
>>> 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 a.janke at gmail.com  Mon Feb  3 17:16:12 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 4 Feb 2014 08:16:12 +1000
Subject: [MINC-users] BIC Objects and Python
In-Reply-To: <06CFA367-5D9B-4DA8-98DF-6A7D3D865AC8@mouseimaging.ca>
References: <CABApf9EacDjhqgQvofXty2003KcktugeEwtxxApCzci53Ndmdw@mail.gmail.com>
	<CAG0CB22LoDuw2WkBJM8Ed1Xi1EtT4pEAbwzY4nta0+WbcnUbig@mail.gmail.com>
	<4D9CE990-6427-4582-9B43-F3636600B262@mouseimaging.ca>
	<20140129132504.GA2739@kensho.slice>
	<CAD3v435TfoXii37_nk10KMYj3PCskvrb=x4QuuqOWSFscFQ+tg@mail.gmail.com>
	<Pine.LNX.4.64.1401290902550.29468@nestor.bic.mni.mcgill.ca>
	<CAD3v435B2hH2xqY5Mw2S0tAbqZdV1=kwbe4vmfmQW8P+=pi3RA@mail.gmail.com>
	<Pine.LNX.4.64.1401290910230.29468@nestor.bic.mni.mcgill.ca>
	<20140129141859.GA3146@kensho.slice>
	<Pine.LNX.4.64.1401291120440.29468@nestor.bic.mni.mcgill.ca>
	<CABApf9EqYZ3n-QRpf1v8ejG6bdp2FhxuChCViT+gA6f2a0HMvQ@mail.gmail.com>
	<06CFA367-5D9B-4DA8-98DF-6A7D3D865AC8@mouseimaging.ca>
Message-ID: <CAG0CB20btJUGm=ijUK9ZF3pApBiPNa3z0cW3KKPrrHkW4gvA2Q@mail.gmail.com>

On 4 February 2014 08:04, Jason Lerch <jason at mouseimaging.ca> wrote:
> I would advocate for option 2

Seconded.



a

From jon at pipitone.ca  Mon Feb  3 20:59:13 2014
From: jon at pipitone.ca (Jon Pipitone)
Date: Mon, 3 Feb 2014 20:59:13 -0500
Subject: [MINC-users] BIC Objects and Python
In-Reply-To: <CAG0CB20btJUGm=ijUK9ZF3pApBiPNa3z0cW3KKPrrHkW4gvA2Q@mail.gmail.com>
References: <20140129132504.GA2739@kensho.slice>
	<CAD3v435TfoXii37_nk10KMYj3PCskvrb=x4QuuqOWSFscFQ+tg@mail.gmail.com>
	<Pine.LNX.4.64.1401290902550.29468@nestor.bic.mni.mcgill.ca>
	<CAD3v435B2hH2xqY5Mw2S0tAbqZdV1=kwbe4vmfmQW8P+=pi3RA@mail.gmail.com>
	<Pine.LNX.4.64.1401290910230.29468@nestor.bic.mni.mcgill.ca>
	<20140129141859.GA3146@kensho.slice>
	<Pine.LNX.4.64.1401291120440.29468@nestor.bic.mni.mcgill.ca>
	<CABApf9EqYZ3n-QRpf1v8ejG6bdp2FhxuChCViT+gA6f2a0HMvQ@mail.gmail.com>
	<06CFA367-5D9B-4DA8-98DF-6A7D3D865AC8@mouseimaging.ca>
	<CAG0CB20btJUGm=ijUK9ZF3pApBiPNa3z0cW3KKPrrHkW4gvA2Q@mail.gmail.com>
Message-ID: <20140204015913.GE27774@kensho.slice>

On 02/04, Andrew Janke wrote:
> On 4 February 2014 08:04, Jason Lerch <jason at mouseimaging.ca> wrote:
> > I would advocate for option 2 [wrapping libbicpl]
> 
> Seconded.

Having never done this before, what would you recommend using? ctypes,
SWIG, or something else entirely? 

Jason, I see you used ctypes for pyminc, did you craft the wrapper by
hand or use something to generate it (even to get started)?

Jon.

From vladimir.fonov at gmail.com  Mon Feb  3 21:32:59 2014
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Mon, 3 Feb 2014 21:32:59 -0500
Subject: [MINC-users] BIC Objects and Python
In-Reply-To: <20140204015913.GE27774@kensho.slice>
References: <20140129132504.GA2739@kensho.slice>
	<CAD3v435TfoXii37_nk10KMYj3PCskvrb=x4QuuqOWSFscFQ+tg@mail.gmail.com>
	<Pine.LNX.4.64.1401290902550.29468@nestor.bic.mni.mcgill.ca>
	<CAD3v435B2hH2xqY5Mw2S0tAbqZdV1=kwbe4vmfmQW8P+=pi3RA@mail.gmail.com>
	<Pine.LNX.4.64.1401290910230.29468@nestor.bic.mni.mcgill.ca>
	<20140129141859.GA3146@kensho.slice>
	<Pine.LNX.4.64.1401291120440.29468@nestor.bic.mni.mcgill.ca>
	<CABApf9EqYZ3n-QRpf1v8ejG6bdp2FhxuChCViT+gA6f2a0HMvQ@mail.gmail.com>
	<06CFA367-5D9B-4DA8-98DF-6A7D3D865AC8@mouseimaging.ca>
	<CAG0CB20btJUGm=ijUK9ZF3pApBiPNa3z0cW3KKPrrHkW4gvA2Q@mail.gmail.com>
	<20140204015913.GE27774@kensho.slice>
Message-ID: <8FFB7A91-F82A-42BB-8EEB-B58C2CD70175@gmail.com>

It is also possible to use cython. 

On a related topic: https://github.com/BIC-MNI/pyezminc - cython based  minc reader/writer for python - creation from NeuroRX - uses EZminc c++ library (part of libminc) 

On 2014-02-03, at 8:59 PM, Jon Pipitone <jon at pipitone.ca> wrote:

> On 02/04, Andrew Janke wrote:
>> On 4 February 2014 08:04, Jason Lerch <jason at mouseimaging.ca> wrote:
>>> I would advocate for option 2 [wrapping libbicpl]
>> 
>> Seconded.
> 
> Having never done this before, what would you recommend using? ctypes,
> SWIG, or something else entirely? 
> 
> Jason, I see you used ctypes for pyminc, did you craft the wrapper by
> hand or use something to generate it (even to get started)?
> 
> Jon.
> _______________________________________________
> 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 jason at mouseimaging.ca  Mon Feb  3 21:40:25 2014
From: jason at mouseimaging.ca (Jason Lerch)
Date: Mon, 3 Feb 2014 21:40:25 -0500
Subject: [MINC-users] BIC Objects and Python
In-Reply-To: <20140204015913.GE27774@kensho.slice>
References: <20140129132504.GA2739@kensho.slice>
	<CAD3v435TfoXii37_nk10KMYj3PCskvrb=x4QuuqOWSFscFQ+tg@mail.gmail.com>
	<Pine.LNX.4.64.1401290902550.29468@nestor.bic.mni.mcgill.ca>
	<CAD3v435B2hH2xqY5Mw2S0tAbqZdV1=kwbe4vmfmQW8P+=pi3RA@mail.gmail.com>
	<Pine.LNX.4.64.1401290910230.29468@nestor.bic.mni.mcgill.ca>
	<20140129141859.GA3146@kensho.slice>
	<Pine.LNX.4.64.1401291120440.29468@nestor.bic.mni.mcgill.ca>
	<CABApf9EqYZ3n-QRpf1v8ejG6bdp2FhxuChCViT+gA6f2a0HMvQ@mail.gmail.com>
	<06CFA367-5D9B-4DA8-98DF-6A7D3D865AC8@mouseimaging.ca>
	<CAG0CB20btJUGm=ijUK9ZF3pApBiPNa3z0cW3KKPrrHkW4gvA2Q@mail.gmail.com>
	<20140204015913.GE27774@kensho.slice>
Message-ID: <7058D300-23C3-4DF3-8FFA-088C57AD3952@mouseimaging.ca>

I quite liked ctypes - don't even really need a wrapper for it, the wrapping only makes a cleaner interface possible. Pyminc was written by hand without any kind of code generator. 

Jason

> On Feb 3, 2014, at 8:59 PM, Jon Pipitone <jon at pipitone.ca> wrote:
> 
>> On 02/04, Andrew Janke wrote:
>>> On 4 February 2014 08:04, Jason Lerch <jason at mouseimaging.ca> wrote:
>>> I would advocate for option 2 [wrapping libbicpl]
>> 
>> Seconded.
> 
> Having never done this before, what would you recommend using? ctypes,
> SWIG, or something else entirely? 
> 
> Jason, I see you used ctypes for pyminc, did you craft the wrapper by
> hand or use something to generate it (even to get started)?
> 
> Jon.
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From alic_nina at yahoo.com  Thu Feb  6 06:21:48 2014
From: alic_nina at yahoo.com (alic nina)
Date: Thu, 6 Feb 2014 03:21:48 -0800 (PST)
Subject: [MINC-users] MINCINFO error
Message-ID: <1391685708.92686.YahooMailNeo@web142306.mail.bf1.yahoo.com>

Dear To Whome It May Be Concerned;

I am trying to run ADNI .mnc image in MATLAB?

I added folder?emma-master,?niak-0.7.1-ammo, mia and?niak-0.7.1-ammo to my path. All these folders are located in?

D:\EMINA BURCH\PhD Thesis\MATLAB Packages

But when I want to open '._bq_t_15T.mnc'?located also in?? D:\EMINA BURCH\PhD Thesis\MATLAB Packages

that is?h = openimage('._bq_n_15T.mnc')

I get the following error

Error using miinquire (line 145)
Error getting image dimensions from file D:\EMINA BURCH\PhD Thesis\MATLAB Packages\._bq_n_15T.mnc

Error in openimage (line 173)
DimSizes = miinquire (filename, 'imagesize');

When I enter debug mode in minquire function ?after the line

? ? [stat,out] = system(['mincinfo -vardims image ' minc_file]);

I get stat = 1 and?out =?'mincinfo' is not recognized as an internal or external command,?operable program or batch file.

May You, please help me with this issue.?

Emina Alickovic, PhD Student
Sarajevo
Bosnia and Herzegovine

From alic_nina at yahoo.com  Thu Feb  6 06:38:22 2014
From: alic_nina at yahoo.com (alic nina)
Date: Thu, 6 Feb 2014 03:38:22 -0800 (PST)
Subject: [MINC-users] MINCINFO error
In-Reply-To: <1391685708.92686.YahooMailNeo@web142306.mail.bf1.yahoo.com>
References: <1391685708.92686.YahooMailNeo@web142306.mail.bf1.yahoo.com>
Message-ID: <1391686702.27428.YahooMailNeo@web142302.mail.bf1.yahoo.com>






Dear To Whome It May Be Concerned;


I am trying to run ADNI .mnc image in MATLAB?

I added folder?emma-master,?niak-0.7.1-ammo, mia and?niak-0.7.1-ammo to my path. All these folders are located in?

D:\EMINA BURCH\PhD Thesis\MATLAB Packages

But when I want to open '._bq_t_15T.mnc'?located also in?? D:\EMINA BURCH\PhD Thesis\MATLAB Packages

that is?h = openimage('._bq_n_15T.mnc')

I get the following error

Error using miinquire (line 145)
Error getting image dimensions from file D:\EMINA BURCH\PhD Thesis\MATLAB Packages\._bq_n_15T.mnc

Error in openimage (line 173)
DimSizes = miinquire (filename, 'imagesize');

When I enter debug mode in minquire function ?after the line

? ? [stat,out] = system(['mincinfo -vardims image ' minc_file]);

I get stat = 1 and?out =?'mincinfo' is not recognized as an internal or external command,?operable program or batch file.

May You, please help me with this issue.?

Emina Alickovic, PhD Student
Sarajevo
Bosnia and Herzegovine
_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From andrew at biospective.com  Thu Feb  6 12:25:12 2014
From: andrew at biospective.com (Andrew Wood)
Date: Thu, 6 Feb 2014 12:25:12 -0500
Subject: [MINC-users] mincresample along a dimension with *-width variables
Message-ID: <CABApf9Ee2jUhRA1aiDgrZ-Wzo5bMDFH2+0wQ8r-zaVgRAgL+rw@mail.gmail.com>

HI All,

I ran into a issue when resampling a volume along a dimension which has
*-width attribute values. It seems that such a dimension can't be resampled
to have a different number of elements.

An example input volume:
$ mincinfo in.mnc
file: in.mnc
image: signed__ short -32768 to 32767
image dimensions: zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    zspace                     47        3.375     -1027.16
    yspace                    128     -2.65336      363.575
    xspace                    128     -2.65336      171.012

$ mincheader in.mnc | grep zspace-width
        double zspace-width(zspace) ;
                zspace-width:dimorder = "zspace" ;
                zspace-width:varid = "MINC standard variable" ;
                zspace-width:vartype = "dim-width____" ;
                zspace-width:version = "MINC Version    1.0" ;
                zspace-width:filtertype = "square____" ;
                zspace-width:spacing = "regular__" ;
                zspace-width:width = -3.375 ;
 zspace-width = -3.375, -3.375, -3.375, -3.375, -3.375, -3.375, -3.375,

Now, add a voxel to each dimension:
$ mincresample -clobber in.mnc out.mnc -nelements 129 129 48
(from miattputstr): Function 'dimrename' not implemented

$ mincinfo out.mnc
file: out.mnc
image: signed__ short -32768 to 32767
image dimensions: zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    zspace                     47        3.375     -1027.16
    yspace                    129     -2.65336      363.575
    xspace                    129     -2.65336      171.012


I dug around the mincresample source code, and the the first thing done
when creating the output volume is a copy of all variable definitions from
the input, excluding {x,y,z}space, image, and image-{min,max}. It appears
that copying the zspace-width actually forces zspace to be copied,
resulting in a naming conflict between the original zspace and our new
zspace. To work around this, it tries to rename the copied zspace to
zspace0, which is where we see the "Function 'dimrename' not implemented"
error message. The result is being stuck with the size of the original
zspace.

The problem goes away if {x,y,z}space-width is added to the exclusion list
for the original variable copy operation. I'm having trouble imagining when
those *-width variables are used though, so I'm not sure if this'd be a
sane fix.

Does anyone have any thoughts that might clear up this situation?

Thanks,
Andrew

From vladimir.fonov at gmail.com  Thu Feb  6 12:31:49 2014
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Thu, 6 Feb 2014 12:31:49 -0500
Subject: [MINC-users] mincresample along a dimension with *-width
	variables
In-Reply-To: <CABApf9Ee2jUhRA1aiDgrZ-Wzo5bMDFH2+0wQ8r-zaVgRAgL+rw@mail.gmail.com>
References: <CABApf9Ee2jUhRA1aiDgrZ-Wzo5bMDFH2+0wQ8r-zaVgRAgL+rw@mail.gmail.com>
Message-ID: <CAMCwi7Max-YyaAE-waxTbidPw99R22T=v4Hh=Nm4-O3WvQNmzw@mail.gmail.com>

I've seen them used in dynamic acquisition where they are used with
time dimension, for example in PET data

On Thu, Feb 6, 2014 at 12:25 PM, Andrew Wood <andrew at biospective.com> wrote:
> HI All,
>
> I ran into a issue when resampling a volume along a dimension which has
> *-width attribute values. It seems that such a dimension can't be resampled
> to have a different number of elements.
>
> An example input volume:
> $ mincinfo in.mnc
> file: in.mnc
> image: signed__ short -32768 to 32767
> image dimensions: zspace yspace xspace
>     dimension name         length         step        start
>     --------------         ------         ----        -----
>     zspace                     47        3.375     -1027.16
>     yspace                    128     -2.65336      363.575
>     xspace                    128     -2.65336      171.012
>
> $ mincheader in.mnc | grep zspace-width
>         double zspace-width(zspace) ;
>                 zspace-width:dimorder = "zspace" ;
>                 zspace-width:varid = "MINC standard variable" ;
>                 zspace-width:vartype = "dim-width____" ;
>                 zspace-width:version = "MINC Version    1.0" ;
>                 zspace-width:filtertype = "square____" ;
>                 zspace-width:spacing = "regular__" ;
>                 zspace-width:width = -3.375 ;
>  zspace-width = -3.375, -3.375, -3.375, -3.375, -3.375, -3.375, -3.375,
>
> Now, add a voxel to each dimension:
> $ mincresample -clobber in.mnc out.mnc -nelements 129 129 48
> (from miattputstr): Function 'dimrename' not implemented
>
> $ mincinfo out.mnc
> file: out.mnc
> image: signed__ short -32768 to 32767
> image dimensions: zspace yspace xspace
>     dimension name         length         step        start
>     --------------         ------         ----        -----
>     zspace                     47        3.375     -1027.16
>     yspace                    129     -2.65336      363.575
>     xspace                    129     -2.65336      171.012
>
>
> I dug around the mincresample source code, and the the first thing done
> when creating the output volume is a copy of all variable definitions from
> the input, excluding {x,y,z}space, image, and image-{min,max}. It appears
> that copying the zspace-width actually forces zspace to be copied,
> resulting in a naming conflict between the original zspace and our new
> zspace. To work around this, it tries to rename the copied zspace to
> zspace0, which is where we see the "Function 'dimrename' not implemented"
> error message. The result is being stuck with the size of the original
> zspace.
>
> The problem goes away if {x,y,z}space-width is added to the exclusion list
> for the original variable copy operation. I'm having trouble imagining when
> those *-width variables are used though, so I'm not sure if this'd be a
> sane fix.
>
> Does anyone have any thoughts that might clear up this situation?
>
> Thanks,
> Andrew
> _______________________________________________
> 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 andrew at biospective.com  Thu Feb  6 13:17:53 2014
From: andrew at biospective.com (Andrew Wood)
Date: Thu, 6 Feb 2014 13:17:53 -0500
Subject: [MINC-users] mincresample along a dimension with *-width
	variables
In-Reply-To: <CAMCwi7Max-YyaAE-waxTbidPw99R22T=v4Hh=Nm4-O3WvQNmzw@mail.gmail.com>
References: <CABApf9Ee2jUhRA1aiDgrZ-Wzo5bMDFH2+0wQ8r-zaVgRAgL+rw@mail.gmail.com>
	<CAMCwi7Max-YyaAE-waxTbidPw99R22T=v4Hh=Nm4-O3WvQNmzw@mail.gmail.com>
Message-ID: <CABApf9HVtvtWtCCELXX2EFwg05HAFCMdDhA10rWXSDVhh+qsdw@mail.gmail.com>

Are they ever used for spatial dimensions? It was actually a mistake that
it ended up in my affected volumes.


On Thu, Feb 6, 2014 at 12:31 PM, Vladimir S. FONOV <vladimir.fonov at gmail.com
> wrote:

> I've seen them used in dynamic acquisition where they are used with
> time dimension, for example in PET data
>
> On Thu, Feb 6, 2014 at 12:25 PM, Andrew Wood <andrew at biospective.com>
> wrote:
> > HI All,
> >
> > I ran into a issue when resampling a volume along a dimension which has
> > *-width attribute values. It seems that such a dimension can't be
> resampled
> > to have a different number of elements.
> >
> > An example input volume:
> > $ mincinfo in.mnc
> > file: in.mnc
> > image: signed__ short -32768 to 32767
> > image dimensions: zspace yspace xspace
> >     dimension name         length         step        start
> >     --------------         ------         ----        -----
> >     zspace                     47        3.375     -1027.16
> >     yspace                    128     -2.65336      363.575
> >     xspace                    128     -2.65336      171.012
> >
> > $ mincheader in.mnc | grep zspace-width
> >         double zspace-width(zspace) ;
> >                 zspace-width:dimorder = "zspace" ;
> >                 zspace-width:varid = "MINC standard variable" ;
> >                 zspace-width:vartype = "dim-width____" ;
> >                 zspace-width:version = "MINC Version    1.0" ;
> >                 zspace-width:filtertype = "square____" ;
> >                 zspace-width:spacing = "regular__" ;
> >                 zspace-width:width = -3.375 ;
> >  zspace-width = -3.375, -3.375, -3.375, -3.375, -3.375, -3.375, -3.375,
> >
> > Now, add a voxel to each dimension:
> > $ mincresample -clobber in.mnc out.mnc -nelements 129 129 48
> > (from miattputstr): Function 'dimrename' not implemented
> >
> > $ mincinfo out.mnc
> > file: out.mnc
> > image: signed__ short -32768 to 32767
> > image dimensions: zspace yspace xspace
> >     dimension name         length         step        start
> >     --------------         ------         ----        -----
> >     zspace                     47        3.375     -1027.16
> >     yspace                    129     -2.65336      363.575
> >     xspace                    129     -2.65336      171.012
> >
> >
> > I dug around the mincresample source code, and the the first thing done
> > when creating the output volume is a copy of all variable definitions
> from
> > the input, excluding {x,y,z}space, image, and image-{min,max}. It appears
> > that copying the zspace-width actually forces zspace to be copied,
> > resulting in a naming conflict between the original zspace and our new
> > zspace. To work around this, it tries to rename the copied zspace to
> > zspace0, which is where we see the "Function 'dimrename' not implemented"
> > error message. The result is being stuck with the size of the original
> > zspace.
> >
> > The problem goes away if {x,y,z}space-width is added to the exclusion
> list
> > for the original variable copy operation. I'm having trouble imagining
> when
> > those *-width variables are used though, so I'm not sure if this'd be a
> > sane fix.
> >
> > Does anyone have any thoughts that might clear up this situation?
> >
> > Thanks,
> > Andrew
> > _______________________________________________
> > 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 zijdenbos at gmail.com  Thu Feb  6 15:00:30 2014
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Thu, 6 Feb 2014 15:00:30 -0500
Subject: [MINC-users] mincresample along a dimension with *-width
	variables
In-Reply-To: <CABApf9HVtvtWtCCELXX2EFwg05HAFCMdDhA10rWXSDVhh+qsdw@mail.gmail.com>
References: <CABApf9Ee2jUhRA1aiDgrZ-Wzo5bMDFH2+0wQ8r-zaVgRAgL+rw@mail.gmail.com>
	<CAMCwi7Max-YyaAE-waxTbidPw99R22T=v4Hh=Nm4-O3WvQNmzw@mail.gmail.com>
	<CABApf9HVtvtWtCCELXX2EFwg05HAFCMdDhA10rWXSDVhh+qsdw@mail.gmail.com>
Message-ID: <CABEEk17nV9ue-nkWny=p7LM_M9PV+j37vkrV1sJsET2M5cU7YA@mail.gmail.com>

In my conceptual understanding, the -width attributes allow you to separate
the "thickness" from the sample step size. Indeed most commonly used along
a time dimension; but I could imagine an image volume being a stack of 3mm
thick slices with a slice gap of 1mm; making the step size 4mm (a lot of
MRI data used to be acquired like that). But I doubt that in reality this
is used much, and I have no idea whether something like mincresample
actually uses this information during resampling (I suspect not) - but it
seems to me that it shouldn't break, either.

-- A


On Thu, Feb 6, 2014 at 1:17 PM, Andrew Wood <andrew at biospective.com> wrote:

> Are they ever used for spatial dimensions? It was actually a mistake that
> it ended up in my affected volumes.
>
>
> On Thu, Feb 6, 2014 at 12:31 PM, Vladimir S. FONOV <
> vladimir.fonov at gmail.com
> > wrote:
>
> > I've seen them used in dynamic acquisition where they are used with
> > time dimension, for example in PET data
> >
> > On Thu, Feb 6, 2014 at 12:25 PM, Andrew Wood <andrew at biospective.com>
> > wrote:
> > > HI All,
> > >
> > > I ran into a issue when resampling a volume along a dimension which has
> > > *-width attribute values. It seems that such a dimension can't be
> > resampled
> > > to have a different number of elements.
> > >
> > > An example input volume:
> > > $ mincinfo in.mnc
> > > file: in.mnc
> > > image: signed__ short -32768 to 32767
> > > image dimensions: zspace yspace xspace
> > >     dimension name         length         step        start
> > >     --------------         ------         ----        -----
> > >     zspace                     47        3.375     -1027.16
> > >     yspace                    128     -2.65336      363.575
> > >     xspace                    128     -2.65336      171.012
> > >
> > > $ mincheader in.mnc | grep zspace-width
> > >         double zspace-width(zspace) ;
> > >                 zspace-width:dimorder = "zspace" ;
> > >                 zspace-width:varid = "MINC standard variable" ;
> > >                 zspace-width:vartype = "dim-width____" ;
> > >                 zspace-width:version = "MINC Version    1.0" ;
> > >                 zspace-width:filtertype = "square____" ;
> > >                 zspace-width:spacing = "regular__" ;
> > >                 zspace-width:width = -3.375 ;
> > >  zspace-width = -3.375, -3.375, -3.375, -3.375, -3.375, -3.375, -3.375,
> > >
> > > Now, add a voxel to each dimension:
> > > $ mincresample -clobber in.mnc out.mnc -nelements 129 129 48
> > > (from miattputstr): Function 'dimrename' not implemented
> > >
> > > $ mincinfo out.mnc
> > > file: out.mnc
> > > image: signed__ short -32768 to 32767
> > > image dimensions: zspace yspace xspace
> > >     dimension name         length         step        start
> > >     --------------         ------         ----        -----
> > >     zspace                     47        3.375     -1027.16
> > >     yspace                    129     -2.65336      363.575
> > >     xspace                    129     -2.65336      171.012
> > >
> > >
> > > I dug around the mincresample source code, and the the first thing done
> > > when creating the output volume is a copy of all variable definitions
> > from
> > > the input, excluding {x,y,z}space, image, and image-{min,max}. It
> appears
> > > that copying the zspace-width actually forces zspace to be copied,
> > > resulting in a naming conflict between the original zspace and our new
> > > zspace. To work around this, it tries to rename the copied zspace to
> > > zspace0, which is where we see the "Function 'dimrename' not
> implemented"
> > > error message. The result is being stuck with the size of the original
> > > zspace.
> > >
> > > The problem goes away if {x,y,z}space-width is added to the exclusion
> > list
> > > for the original variable copy operation. I'm having trouble imagining
> > when
> > > those *-width variables are used though, so I'm not sure if this'd be a
> > > sane fix.
> > >
> > > Does anyone have any thoughts that might clear up this situation?
> > >
> > > Thanks,
> > > Andrew
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>

From a.janke at gmail.com  Thu Feb  6 18:23:12 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 7 Feb 2014 09:23:12 +1000
Subject: [MINC-users] mincresample along a dimension with *-width
	variables
In-Reply-To: <CABEEk17nV9ue-nkWny=p7LM_M9PV+j37vkrV1sJsET2M5cU7YA@mail.gmail.com>
References: <CABApf9Ee2jUhRA1aiDgrZ-Wzo5bMDFH2+0wQ8r-zaVgRAgL+rw@mail.gmail.com>
	<CAMCwi7Max-YyaAE-waxTbidPw99R22T=v4Hh=Nm4-O3WvQNmzw@mail.gmail.com>
	<CABApf9HVtvtWtCCELXX2EFwg05HAFCMdDhA10rWXSDVhh+qsdw@mail.gmail.com>
	<CABEEk17nV9ue-nkWny=p7LM_M9PV+j37vkrV1sJsET2M5cU7YA@mail.gmail.com>
Message-ID: <CAG0CB211eX2B9t28p4Fk8XjhxXWuiONRD3DJNsgCafLCR=gy_A@mail.gmail.com>

Hi all,

As others have commented, the width parameters are typically for data
with a time dimension, but there are use cases for irregular spacing
in an image dimension. I have used it for microscopy data in which we
dynamically change a vibratome slice thickness from 20um -> 80um
depending if we are in an "interesting" part of the tissue or not.

Peter, Bert and I had a long discussion about the use case that Alex
mentioned of capturing slice thickness and gap. This used to be common
in MRI acquisition to avoid slice cross talk but has (thankfully)
faded from use with interleaved sequences. I argued strongly that we
shouldn't support this type of acquisition as it would introduce too
many special cases, what for example do you do when you resample? you
can no longer capture the gaps. Peter as I recall agreed so Bert
didin't get to vote!

History out of the way, I am surprised that your volume has both slice
widths and has a regular__ spacing type. These from my understanding
should be mutually exclusive of each other and I'm guessing is what is
causing the problem.

Why also the use of mincresample to add a few slices? I'd generally do
this (no interpolation needed).

    mincreshape -dimrange zspace=-1,49 in.mnc out.mnc

Do your dimension widths survive the above? I'd suspect not given the
regular__ type. Where did this file originate from?


a

On 7 February 2014 06:00, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> In my conceptual understanding, the -width attributes allow you to separate
> the "thickness" from the sample step size. Indeed most commonly used along
> a time dimension; but I could imagine an image volume being a stack of 3mm
> thick slices with a slice gap of 1mm; making the step size 4mm (a lot of
> MRI data used to be acquired like that). But I doubt that in reality this
> is used much, and I have no idea whether something like mincresample
> actually uses this information during resampling (I suspect not) - but it
> seems to me that it shouldn't break, either.
>
> -- A
>
>
> On Thu, Feb 6, 2014 at 1:17 PM, Andrew Wood <andrew at biospective.com> wrote:
>
>> Are they ever used for spatial dimensions? It was actually a mistake that
>> it ended up in my affected volumes.
>>
>>
>> On Thu, Feb 6, 2014 at 12:31 PM, Vladimir S. FONOV <
>> vladimir.fonov at gmail.com
>> > wrote:
>>
>> > I've seen them used in dynamic acquisition where they are used with
>> > time dimension, for example in PET data
>> >
>> > On Thu, Feb 6, 2014 at 12:25 PM, Andrew Wood <andrew at biospective.com>
>> > wrote:
>> > > HI All,
>> > >
>> > > I ran into a issue when resampling a volume along a dimension which has
>> > > *-width attribute values. It seems that such a dimension can't be
>> > resampled
>> > > to have a different number of elements.
>> > >
>> > > An example input volume:
>> > > $ mincinfo in.mnc
>> > > file: in.mnc
>> > > image: signed__ short -32768 to 32767
>> > > image dimensions: zspace yspace xspace
>> > >     dimension name         length         step        start
>> > >     --------------         ------         ----        -----
>> > >     zspace                     47        3.375     -1027.16
>> > >     yspace                    128     -2.65336      363.575
>> > >     xspace                    128     -2.65336      171.012
>> > >
>> > > $ mincheader in.mnc | grep zspace-width
>> > >         double zspace-width(zspace) ;
>> > >                 zspace-width:dimorder = "zspace" ;
>> > >                 zspace-width:varid = "MINC standard variable" ;
>> > >                 zspace-width:vartype = "dim-width____" ;
>> > >                 zspace-width:version = "MINC Version    1.0" ;
>> > >                 zspace-width:filtertype = "square____" ;
>> > >                 zspace-width:spacing = "regular__" ;
>> > >                 zspace-width:width = -3.375 ;
>> > >  zspace-width = -3.375, -3.375, -3.375, -3.375, -3.375, -3.375, -3.375,
>> > >
>> > > Now, add a voxel to each dimension:
>> > > $ mincresample -clobber in.mnc out.mnc -nelements 129 129 48
>> > > (from miattputstr): Function 'dimrename' not implemented
>> > >
>> > > $ mincinfo out.mnc
>> > > file: out.mnc
>> > > image: signed__ short -32768 to 32767
>> > > image dimensions: zspace yspace xspace
>> > >     dimension name         length         step        start
>> > >     --------------         ------         ----        -----
>> > >     zspace                     47        3.375     -1027.16
>> > >     yspace                    129     -2.65336      363.575
>> > >     xspace                    129     -2.65336      171.012
>> > >
>> > >
>> > > I dug around the mincresample source code, and the the first thing done
>> > > when creating the output volume is a copy of all variable definitions
>> > from
>> > > the input, excluding {x,y,z}space, image, and image-{min,max}. It
>> appears
>> > > that copying the zspace-width actually forces zspace to be copied,
>> > > resulting in a naming conflict between the original zspace and our new
>> > > zspace. To work around this, it tries to rename the copied zspace to
>> > > zspace0, which is where we see the "Function 'dimrename' not
>> implemented"
>> > > error message. The result is being stuck with the size of the original
>> > > zspace.
>> > >
>> > > The problem goes away if {x,y,z}space-width is added to the exclusion
>> > list
>> > > for the original variable copy operation. I'm having trouble imagining
>> > when
>> > > those *-width variables are used though, so I'm not sure if this'd be a
>> > > sane fix.
>> > >
>> > > Does anyone have any thoughts that might clear up this situation?
>> > >
>> > > Thanks,
>> > > Andrew
>> > > _______________________________________________
>> > > 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
>> >
>> _______________________________________________
>> 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  Thu Feb  6 18:47:18 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 7 Feb 2014 09:47:18 +1000
Subject: [MINC-users] MINCINFO error
In-Reply-To: <1391685708.92686.YahooMailNeo@web142306.mail.bf1.yahoo.com>
References: <1391685708.92686.YahooMailNeo@web142306.mail.bf1.yahoo.com>
Message-ID: <CAG0CB21e23EiR3mjZdyg_PrK7XXd3LdF=y15jzkU=qg-+rsKTg@mail.gmail.com>

Hi Emina,

You should only need NIAK as it is a bigger and better replacement for
EMMA. NIAK also still requires an install of MINC. I note that you are
running on Windows which will make things difficult. There have been
compilations of MINC on windows in the past
http://packages.bic.mni.mcgill.ca/win32/ but I can't say they are
supported.

You might also be hitting issues with filenames with spaces in them
but I don't see any evidence of this.

My strong recommendation is that if you planning on continuing in
image analysis would be to run a Linux based Neurodebian Virtual
Machine if you have to stay with Windows or use a linux/OSX machine
for your work. Nearly all of the packages in this space will be hard
on Windows.

Good luck!


a



On 6 February 2014 21:21, alic nina <alic_nina at yahoo.com> wrote:
> Dear To Whome It May Be Concerned;
>
> I am trying to run ADNI .mnc image in MATLAB
>
> I added folder emma-master, niak-0.7.1-ammo, mia and niak-0.7.1-ammo to my path. All these folders are located in
>
> D:\EMINA BURCH\PhD Thesis\MATLAB Packages
>
> But when I want to open '._bq_t_15T.mnc' located also in   D:\EMINA BURCH\PhD Thesis\MATLAB Packages
>
> that is h = openimage('._bq_n_15T.mnc')
>
> I get the following error
>
> Error using miinquire (line 145)
> Error getting image dimensions from file D:\EMINA BURCH\PhD Thesis\MATLAB Packages\._bq_n_15T.mnc
>
> Error in openimage (line 173)
> DimSizes = miinquire (filename, 'imagesize');
>
> When I enter debug mode in minquire function  after the line
>
>     [stat,out] = system(['mincinfo -vardims image ' minc_file]);
>
> I get stat = 1 and out = 'mincinfo' is not recognized as an internal or external command, operable program or batch file.
>
> May You, please help me with this issue.
>
> Emina Alickovic, PhD Student
> Sarajevo
> Bosnia and Herzegovine
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From andrew at biospective.com  Fri Feb  7 08:43:18 2014
From: andrew at biospective.com (Andrew Wood)
Date: Fri, 7 Feb 2014 08:43:18 -0500
Subject: [MINC-users] mincresample along a dimension with *-width
	variables
In-Reply-To: <CAG0CB211eX2B9t28p4Fk8XjhxXWuiONRD3DJNsgCafLCR=gy_A@mail.gmail.com>
References: <CABApf9Ee2jUhRA1aiDgrZ-Wzo5bMDFH2+0wQ8r-zaVgRAgL+rw@mail.gmail.com>
	<CAMCwi7Max-YyaAE-waxTbidPw99R22T=v4Hh=Nm4-O3WvQNmzw@mail.gmail.com>
	<CABApf9HVtvtWtCCELXX2EFwg05HAFCMdDhA10rWXSDVhh+qsdw@mail.gmail.com>
	<CABEEk17nV9ue-nkWny=p7LM_M9PV+j37vkrV1sJsET2M5cU7YA@mail.gmail.com>
	<CAG0CB211eX2B9t28p4Fk8XjhxXWuiONRD3DJNsgCafLCR=gy_A@mail.gmail.com>
Message-ID: <CABApf9FErYmjdUsxBBphdHEBhiTE0vpjw-8B1bcK4stiBQ02cA@mail.gmail.com>

This file came from some some buggy code which artificially inserted
it (was supposed to insert on the time dimension). I thought it was
something
worth looking into as a generic issue, but perhaps the volume should be
considered malformed, and the issue forgotten?

- Andrew


On Thu, Feb 6, 2014 at 6:23 PM, Andrew Janke <a.janke at gmail.com> wrote:

> Hi all,
>
> As others have commented, the width parameters are typically for data
> with a time dimension, but there are use cases for irregular spacing
> in an image dimension. I have used it for microscopy data in which we
> dynamically change a vibratome slice thickness from 20um -> 80um
> depending if we are in an "interesting" part of the tissue or not.
>
> Peter, Bert and I had a long discussion about the use case that Alex
> mentioned of capturing slice thickness and gap. This used to be common
> in MRI acquisition to avoid slice cross talk but has (thankfully)
> faded from use with interleaved sequences. I argued strongly that we
> shouldn't support this type of acquisition as it would introduce too
> many special cases, what for example do you do when you resample? you
> can no longer capture the gaps. Peter as I recall agreed so Bert
> didin't get to vote!
>
> History out of the way, I am surprised that your volume has both slice
> widths and has a regular__ spacing type. These from my understanding
> should be mutually exclusive of each other and I'm guessing is what is
> causing the problem.
>
> Why also the use of mincresample to add a few slices? I'd generally do
> this (no interpolation needed).
>
>     mincreshape -dimrange zspace=-1,49 in.mnc out.mnc
>
> Do your dimension widths survive the above? I'd suspect not given the
> regular__ type. Where did this file originate from?
>
>
> a
>
> On 7 February 2014 06:00, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> > In my conceptual understanding, the -width attributes allow you to
> separate
> > the "thickness" from the sample step size. Indeed most commonly used
> along
> > a time dimension; but I could imagine an image volume being a stack of
> 3mm
> > thick slices with a slice gap of 1mm; making the step size 4mm (a lot of
> > MRI data used to be acquired like that). But I doubt that in reality this
> > is used much, and I have no idea whether something like mincresample
> > actually uses this information during resampling (I suspect not) - but it
> > seems to me that it shouldn't break, either.
> >
> > -- A
> >
> >
> > On Thu, Feb 6, 2014 at 1:17 PM, Andrew Wood <andrew at biospective.com>
> wrote:
> >
> >> Are they ever used for spatial dimensions? It was actually a mistake
> that
> >> it ended up in my affected volumes.
> >>
> >>
> >> On Thu, Feb 6, 2014 at 12:31 PM, Vladimir S. FONOV <
> >> vladimir.fonov at gmail.com
> >> > wrote:
> >>
> >> > I've seen them used in dynamic acquisition where they are used with
> >> > time dimension, for example in PET data
> >> >
> >> > On Thu, Feb 6, 2014 at 12:25 PM, Andrew Wood <andrew at biospective.com>
> >> > wrote:
> >> > > HI All,
> >> > >
> >> > > I ran into a issue when resampling a volume along a dimension which
> has
> >> > > *-width attribute values. It seems that such a dimension can't be
> >> > resampled
> >> > > to have a different number of elements.
> >> > >
> >> > > An example input volume:
> >> > > $ mincinfo in.mnc
> >> > > file: in.mnc
> >> > > image: signed__ short -32768 to 32767
> >> > > image dimensions: zspace yspace xspace
> >> > >     dimension name         length         step        start
> >> > >     --------------         ------         ----        -----
> >> > >     zspace                     47        3.375     -1027.16
> >> > >     yspace                    128     -2.65336      363.575
> >> > >     xspace                    128     -2.65336      171.012
> >> > >
> >> > > $ mincheader in.mnc | grep zspace-width
> >> > >         double zspace-width(zspace) ;
> >> > >                 zspace-width:dimorder = "zspace" ;
> >> > >                 zspace-width:varid = "MINC standard variable" ;
> >> > >                 zspace-width:vartype = "dim-width____" ;
> >> > >                 zspace-width:version = "MINC Version    1.0" ;
> >> > >                 zspace-width:filtertype = "square____" ;
> >> > >                 zspace-width:spacing = "regular__" ;
> >> > >                 zspace-width:width = -3.375 ;
> >> > >  zspace-width = -3.375, -3.375, -3.375, -3.375, -3.375, -3.375,
> -3.375,
> >> > >
> >> > > Now, add a voxel to each dimension:
> >> > > $ mincresample -clobber in.mnc out.mnc -nelements 129 129 48
> >> > > (from miattputstr): Function 'dimrename' not implemented
> >> > >
> >> > > $ mincinfo out.mnc
> >> > > file: out.mnc
> >> > > image: signed__ short -32768 to 32767
> >> > > image dimensions: zspace yspace xspace
> >> > >     dimension name         length         step        start
> >> > >     --------------         ------         ----        -----
> >> > >     zspace                     47        3.375     -1027.16
> >> > >     yspace                    129     -2.65336      363.575
> >> > >     xspace                    129     -2.65336      171.012
> >> > >
> >> > >
> >> > > I dug around the mincresample source code, and the the first thing
> done
> >> > > when creating the output volume is a copy of all variable
> definitions
> >> > from
> >> > > the input, excluding {x,y,z}space, image, and image-{min,max}. It
> >> appears
> >> > > that copying the zspace-width actually forces zspace to be copied,
> >> > > resulting in a naming conflict between the original zspace and our
> new
> >> > > zspace. To work around this, it tries to rename the copied zspace to
> >> > > zspace0, which is where we see the "Function 'dimrename' not
> >> implemented"
> >> > > error message. The result is being stuck with the size of the
> original
> >> > > zspace.
> >> > >
> >> > > The problem goes away if {x,y,z}space-width is added to the
> exclusion
> >> > list
> >> > > for the original variable copy operation. I'm having trouble
> imagining
> >> > when
> >> > > those *-width variables are used though, so I'm not sure if this'd
> be a
> >> > > sane fix.
> >> > >
> >> > > Does anyone have any thoughts that might clear up this situation?
> >> > >
> >> > > Thanks,
> >> > > Andrew
> >> > > _______________________________________________
> >> > > 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
> >> >
> >> _______________________________________________
> >> 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 a.janke at gmail.com  Sun Feb  9 05:21:18 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Sun, 9 Feb 2014 20:21:18 +1000
Subject: [MINC-users] mincresample along a dimension with *-width
	variables
In-Reply-To: <CABApf9FErYmjdUsxBBphdHEBhiTE0vpjw-8B1bcK4stiBQ02cA@mail.gmail.com>
References: <CABApf9Ee2jUhRA1aiDgrZ-Wzo5bMDFH2+0wQ8r-zaVgRAgL+rw@mail.gmail.com>
	<CAMCwi7Max-YyaAE-waxTbidPw99R22T=v4Hh=Nm4-O3WvQNmzw@mail.gmail.com>
	<CABApf9HVtvtWtCCELXX2EFwg05HAFCMdDhA10rWXSDVhh+qsdw@mail.gmail.com>
	<CABEEk17nV9ue-nkWny=p7LM_M9PV+j37vkrV1sJsET2M5cU7YA@mail.gmail.com>
	<CAG0CB211eX2B9t28p4Fk8XjhxXWuiONRD3DJNsgCafLCR=gy_A@mail.gmail.com>
	<CABApf9FErYmjdUsxBBphdHEBhiTE0vpjw-8B1bcK4stiBQ02cA@mail.gmail.com>
Message-ID: <CAG0CB20LxuNG5xKO0ZxwNZY5UBmLpHv8JRz0WTrv2oTJmbLVNg@mail.gmail.com>

On 7 February 2014 23:43, Andrew Wood <andrew at biospective.com> wrote:
> This file came from some some buggy code which artificially inserted
> it (was supposed to insert on the time dimension). I thought it was
> something
> worth looking into as a generic issue, but perhaps the volume should be
> considered malformed, and the issue forgotten?

That is of course one approach!

Do the widths survive the mincreshape call I sent? Or even a no-op mincreshape?

   mincreshape in.mnc out.mnc


a

From andrew at biospective.com  Mon Feb 10 09:17:20 2014
From: andrew at biospective.com (Andrew Wood)
Date: Mon, 10 Feb 2014 09:17:20 -0500
Subject: [MINC-users] mincresample along a dimension with *-width
	variables
In-Reply-To: <CAG0CB20LxuNG5xKO0ZxwNZY5UBmLpHv8JRz0WTrv2oTJmbLVNg@mail.gmail.com>
References: <CABApf9Ee2jUhRA1aiDgrZ-Wzo5bMDFH2+0wQ8r-zaVgRAgL+rw@mail.gmail.com>
	<CAMCwi7Max-YyaAE-waxTbidPw99R22T=v4Hh=Nm4-O3WvQNmzw@mail.gmail.com>
	<CABApf9HVtvtWtCCELXX2EFwg05HAFCMdDhA10rWXSDVhh+qsdw@mail.gmail.com>
	<CABEEk17nV9ue-nkWny=p7LM_M9PV+j37vkrV1sJsET2M5cU7YA@mail.gmail.com>
	<CAG0CB211eX2B9t28p4Fk8XjhxXWuiONRD3DJNsgCafLCR=gy_A@mail.gmail.com>
	<CABApf9FErYmjdUsxBBphdHEBhiTE0vpjw-8B1bcK4stiBQ02cA@mail.gmail.com>
	<CAG0CB20LxuNG5xKO0ZxwNZY5UBmLpHv8JRz0WTrv2oTJmbLVNg@mail.gmail.com>
Message-ID: <CABApf9Fc99ti4W4J5JhGWpv8v7Pv3qROmHa8fXsZu3NByKyP4g@mail.gmail.com>

Hi Andrew,

The widths survive both calls, however zspace:spacing changes from
"regular__" to "irregular." This has no effect on the broken resampling
along the z dimension.

- Andrew




On Sun, Feb 9, 2014 at 5:21 AM, Andrew Janke <a.janke at gmail.com> wrote:

> On 7 February 2014 23:43, Andrew Wood <andrew at biospective.com> wrote:
> > This file came from some some buggy code which artificially inserted
> > it (was supposed to insert on the time dimension). I thought it was
> > something
> > worth looking into as a generic issue, but perhaps the volume should be
> > considered malformed, and the issue forgotten?
>
> That is of course one approach!
>
> Do the widths survive the mincreshape call I sent? Or even a no-op
> mincreshape?
>
>    mincreshape in.mnc out.mnc
>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From vladimir.fonov at gmail.com  Wed Feb 19 01:43:59 2014
From: vladimir.fonov at gmail.com (Vladimir S. Fonov)
Date: Wed, 19 Feb 2014 01:43:59 -0500
Subject: [MINC-users] running voxel-wise mixed-effects modeling on huge
 dataset with Python Rpy2 and pyezminc
Message-ID: <530452AF.1060705@gmail.com>

Hello Everybody,

just wanted to share news about a new tool for running voxel-level 
statistical analysis on minc files, an alternative to RMINC and glim_image.

It is under active development, but it is already usable:

https://github.com/BIC-MNI/pyezminc/tree/develop

in short it is a python module to interface with MINC, mainly developed 
by Haz-Edine from NeuroRX with my additions. It is using cython (I 
recommend using the latest version 0.20 ) and numpy to interact with 
minc files using EZminc API. I have extended it to be able to stream 
data to and from multiple  minc files to easily perform voxel-level 
statistical analysis.
Integrating with Rpy2 ( R interface for Python) allows to easily run 
statistical tests.


For example: 
https://github.com/BIC-MNI/pyezminc/blob/develop/examples/glim_image.py 
- performs a simple voxel-level t-test on difference between two cohorts 
, using DBM data from 64 subjects (with ROI covering the whole brain) 
execution time is 14m56s , equivalent analysis performed using 
glim_image on the same computer takes 3m12s.


The advantage is it is possible to use more complicated statistical 
models (similar to RMINC), next example: 
https://github.com/BIC-MNI/pyezminc/blob/develop/examples/lme_image.py - 
performs voxel-level mixed-effect modeling (quite slowly).


Fortunately, it is pretty simple to parallelize execution of statistical 
modeling in python, example number 3 - running voxel-level mixed-effect 
modelling on a cluster using SCOOP ( https://code.google.com/p/scoop/ ) 
: 
https://github.com/BIC-MNI/pyezminc/blob/develop/examples/parallel_lme_image.py 



Running full-brain linear mixed effect model on 899 scans ( volume of 
mask is 235818 2mm^3 voxels) on a 16 core machine took approximately 23 
minutes. Note that the example doesn't try to play nice with the memory, 
so overall memory used was approximately 10Gb. It will be pretty trivial 
to significantly reduce the memory requirement by not submitting all the 
computation jobs at once , but in chunks.
It should be also possible to make scoop play nicely with SGE ( 
http://scoop.readthedocs.org/en/0.7/usage.html#startup-scripts-cluster-or-grid 
)


p.s. pyezminc depends on a modern installation of MINC (such as that 
found in minc-toolkit). And could be compiled and installed in your 
private python library by running "python setup.py install --user" . 
Currently dependencies are : Cython , numpy and scipy . Examples also 
use Rpy2 and scoop . All these libraries can be installed by running 
"python setup.py install --user" without the need to have root access on 
your system.

--
  Have Fun,

Vladimir S. Fonov


From a.janke at gmail.com  Wed Feb 19 06:21:19 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 19 Feb 2014 21:21:19 +1000
Subject: [MINC-users] running voxel-wise mixed-effects modeling on huge
 dataset with Python Rpy2 and pyezminc
In-Reply-To: <530452AF.1060705@gmail.com>
References: <530452AF.1060705@gmail.com>
Message-ID: <CAG0CB223UpWNNtcOcS3yMc4m9q5uNhWa-ipKyy4gO7OFna+e0w@mail.gmail.com>

On 19 February 2014 16:43, Vladimir S. Fonov <vladimir.fonov at gmail.com> wrote:
> For example:
> https://github.com/BIC-MNI/pyezminc/blob/develop/examples/glim_image.py -
> performs a simple voxel-level t-test on difference between two cohorts ,
> using DBM data from 64 subjects (with ROI covering the whole brain)
> execution time is 14m56s , equivalent analysis performed using glim_image on
> the same computer takes 3m12s.

Hi Vladimir,

This looks like a pretty spectacularly useful bit of porting to me. I
find we are now using python more and more although I do have a stats
PhD student who is an R aficionado.  For those that are interested in
python, you might also find this of interest:

   https://github.com/carlohamalainen/volgenmodel-nipype

A friend of mine is working on integration of some of the existing
MINC tools with nipype, the example is volgenmodel (MDA creation).

This so far has been far more stable than previous versions that used
perl scripts to generate SGI scripts with dependencies and the likes.


a

From lconcha at gmail.com  Wed Feb 19 16:06:51 2014
From: lconcha at gmail.com (Luis Concha)
Date: Wed, 19 Feb 2014 15:06:51 -0600
Subject: [MINC-users] MRI Job Opportunity in Mexico
Message-ID: <CAOq9ZoGp_79X7rwzkRVnQgaKGTAabb-wS_2sPp7WXXv=Bv6kpg@mail.gmail.com>

Sorry to use the minc mailing list to advertise a job opportunity, but
perhaps some of you may be looking for ways to escape the cold weather for
good, while still being able to use your MRI skills. This is an unofficial
(but certain) announcement of this position, and further details will be
provided in due time.

The Institute of Neurobiology of the National Autonomous University of
Mexico, Campus Juriquilla, Quer?taro, has an available position as
full-time researcher in the field of MRI. The applicant must hold a PhD and
at least two years of post-doctoral experience in the fields of MRI and
neuroscience. The Institute owns two 3T clinical MRI scanners (G.E. and
Philips) which are used for clinical work, as well as research. Currently,
three groups use these scanners as their main tool to answer neuroscience
questions. With 55 active researchers in all fields of neuroscience, the
Institute is a very active and intellectually satisfying workplace.
Quer?taro is only 200 km North of Mexico City, and it is ranked the safest
city in the country. The weather here is generally mild, and there is a
very attractive offer of cultural events, as well as ample opportunities
for outdoor sports.

Given the characteristics of the MRI scanners, research involving human
subjects is preferred, but can be in any topic of neuroscience, such as
pre-clinical  imaging, cognitive neuroscience, analysis of brain
connectivity, etc. Applicants are expected to develop their own research,
obtain funding, and participate in academic duties (grad-students only on
campus).

If interested, please contact me directly and I will be able to provide
more information.

Link to the Institute of Neurobiology web site:
http://www.inb.unam.mx/inweb3/index.html

Where is it located?
https://goo.gl/maps/rhqdB


Adi?s, amigos!

Dr. Luis Concha
Instituto de Neurobiolog?a
Laboratorio C-13
UNAM, Campus Juriquilla
Boulervard Juriquilla 3001
Juriquilla, Quer?taro.
C.P. 76230
M?xico
Tel (442) 2 38 10 54
Fax (442) 2 38 10 46
http://personal.inb.unam.mx/lconcha/

From andrew at biospective.com  Tue Feb 25 09:42:15 2014
From: andrew at biospective.com (Andrew Wood)
Date: Tue, 25 Feb 2014 09:42:15 -0500
Subject: [MINC-users] Building minccmp
Message-ID: <CABApf9Fpo8=anTtAvBKbnq2AyR_U-zY2eO_7=RBQooOGm5Togw@mail.gmail.com>

Hi all,

It seems that minctools isn't set up to build minccmp. Has it been excluded
on purpose? Or would it be safe to turn on?

Thanks,
Andrew

From vladimir.fonov at gmail.com  Tue Feb 25 10:36:12 2014
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Tue, 25 Feb 2014 10:36:12 -0500
Subject: [MINC-users] Building minccmp
In-Reply-To: <CABApf9Fpo8=anTtAvBKbnq2AyR_U-zY2eO_7=RBQooOGm5Togw@mail.gmail.com>
References: <CABApf9Fpo8=anTtAvBKbnq2AyR_U-zY2eO_7=RBQooOGm5Togw@mail.gmail.com>
Message-ID: <530CB86C.4020102@gmail.com>

I don't remember why, but now I enabled it in develop branch.

https://github.com/BIC-MNI/minc-tools/commit/4dd55a0409871e5ea7963ccee5ca0c1c3a84eeb6


On 14-02-25 09:42 AM, Andrew Wood wrote:
> Hi all,
>
> It seems that minctools isn't set up to build minccmp. Has it been excluded
> on purpose? Or would it be safe to turn on?
>
> Thanks,
> Andrew
> _______________________________________________
> 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 andrew at biospective.com  Tue Feb 25 16:01:28 2014
From: andrew at biospective.com (Andrew Wood)
Date: Tue, 25 Feb 2014 16:01:28 -0500
Subject: [MINC-users] Building minccmp
In-Reply-To: <530CB86C.4020102@gmail.com>
References: <CABApf9Fpo8=anTtAvBKbnq2AyR_U-zY2eO_7=RBQooOGm5Togw@mail.gmail.com>
	<530CB86C.4020102@gmail.com>
Message-ID: <CABApf9EaL_9tgSVKhUyQcrF2v_OAYUJyRd9LXrd3+XrKMS8tgA@mail.gmail.com>

Hi all,

I've been having trouble with minccmp reporting 'inf' and 'nan' on some
float volumes that I've been working with.

It turns out minccmp doesn't deal correctly with NaN inputs values. I'm
wondering what would be sensible behaviour to expect from minccmp.
When corresponding voxels are both NaN, the obvious choices would
be either exclusion, or being treated as a constant (zero, or
user-specified). When one corresponding voxel is NaN, and the other
real, probably only exclusion makes sense.

Does anyone have any thoughts, or different ideas?

Thanks,
Andrew


On Tue, Feb 25, 2014 at 10:36 AM, Vladimir S. FONOV <
vladimir.fonov at gmail.com> wrote:

> I don't remember why, but now I enabled it in develop branch.
>
> https://github.com/BIC-MNI/minc-tools/commit/
> 4dd55a0409871e5ea7963ccee5ca0c1c3a84eeb6
>
>
>
> On 14-02-25 09:42 AM, Andrew Wood wrote:
>
>> Hi all,
>>
>> It seems that minctools isn't set up to build minccmp. Has it been
>> excluded
>> on purpose? Or would it be safe to turn on?
>>
>> Thanks,
>> Andrew
>> _______________________________________________
>> 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 a.janke at gmail.com  Tue Feb 25 16:23:47 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 26 Feb 2014 07:23:47 +1000
Subject: [MINC-users] Building minccmp
In-Reply-To: <CABApf9EaL_9tgSVKhUyQcrF2v_OAYUJyRd9LXrd3+XrKMS8tgA@mail.gmail.com>
References: <CABApf9Fpo8=anTtAvBKbnq2AyR_U-zY2eO_7=RBQooOGm5Togw@mail.gmail.com>
	<530CB86C.4020102@gmail.com>
	<CABApf9EaL_9tgSVKhUyQcrF2v_OAYUJyRd9LXrd3+XrKMS8tgA@mail.gmail.com>
Message-ID: <CAG0CB236jN-yKp_OtCMR=mUEACV6OoMXehzLLR7KL8T67nVryQ@mail.gmail.com>

Hi Andrew,

> I've been having trouble with minccmp reporting 'inf' and 'nan' on some
> float volumes that I've been working with.
>
> It turns out minccmp doesn't deal correctly with NaN inputs values. I'm
> wondering what would be sensible behaviour to expect from minccmp.
> When corresponding voxels are both NaN, the obvious choices would
> be either exclusion, or being treated as a constant (zero, or
> user-specified). When one corresponding voxel is NaN, and the other
> real, probably only exclusion makes sense.

minccmp was something I wrote one afternoon in order to scratch an
itch I had, I really never got the chance to finish it off with the
types of special case data handling you are talking about. I also had
plans for a whole heap of other comparison functions but by then the
itch was scratched...

So, by all means yes, NaN handling is something it should do. My
personal preference for this would be to mirror the way this is done
in mincmath:

   https://github.com/BIC-MNI/minc-tools/blob/master/progs/mincmath/mincmath.c#L783

This would include mirroring the C/L arguments that mincmath uses to
avoid user confusion (302-314):

   https://github.com/BIC-MNI/minc-tools/blob/master/progs/mincmath/mincmath.c#L302

Thanks


a

From a.janke at gmail.com  Fri Feb 28 07:07:41 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 28 Feb 2014 22:07:41 +1000
Subject: [MINC-users] Introductory Biomedical Imaging (MOOC) course
Message-ID: <CAG0CB21Gi6AniYQ+U2WbqZvmOHwKunt99eR_jC-bW-cvDjFZcg@mail.gmail.com>

Hi all,

Some may be interested in this:

   https://www.edx.org/course/uqx/uqx-bioimg101x-introduction-biomedical-1429

We (CAI, UQ) volunteered a while back to build an introductory
Biomedical Imaging course covering Xray/CT/PET/MRI/Ultrasound for
edx.org, it starts in April so if you have new students or anyone who
wants a background to what we all do, it might be of interest.

Being a MOOC, it's free to participate.



a