From danielkim at gist.ac.kr  Sun Dec  2 21:26:49 2012
From: danielkim at gist.ac.kr (Donghyeon Kim)
Date: Mon, 3 Dec 2012 11:26:49 +0900 (KST)
Subject: [MINC-users] Using MINC in virtual machine
Message-ID: <1081332106.1354501609291.JavaMail.root@eunhasu>

Hi everyone, 

My name is Donghyeon Kim and Phd student in GIST. 4 month ago, I learned 
how to use minc toolbox in montreal, and now I'm already using it. 
Because of few problem in our lab, I'm using windows. Thus i installed 
minc toolbox in virtual machine(ubuntu 12.04 64x). However, in
virtual machine, I cannot run register and display; it occurs error 
"segmantation fault". may be it is about openGL problem. So now, I'm using 
MINCbuntu in packages.bic.mn.mcgill.ca and it doesn't have any problem 
to run display and register. But MINCbuntu is ubuntu 8.04 and it is 
32bit. I want to use ubuntu 10.04 or 12.04 64bit using virtual machine. 
So my question is how can i set minctoolbox in virtualmachine (ubuntu 10.04 or 12.04 64bit) to run display and register properly? 

Thank you 
Donghyeon 









 

    
        
            -------------------------------------------------- 

            DONGHYEON KIM, PhD Student 

            Dept. of Info. &amp; Comm., Gwangju Institute of Science and Technology(GIST) 

            261 Cheomdan-gwagiro, Buk-gu, Gwangju 500-712, South Korea

            Tel: +82-62-715-2266 Cell: +82-10-9361-3781

            E-mail: danielkim at gist.ac.kr URL: http://biocomput.gist.ac.kr

             
        
    



From a.janke at gmail.com  Mon Dec  3 01:31:55 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 3 Dec 2012 16:31:55 +1000
Subject: [MINC-users] Using MINC in virtual machine
In-Reply-To: <1081332106.1354501609291.JavaMail.root@eunhasu>
References: <1081332106.1354501609291.JavaMail.root@eunhasu>
Message-ID: <CAG0CB21GZsaGzu=Zso298LoBctis39BY5QRin1g_CrVFcuFP=A@mail.gmail.com>

Hi Donghyeon,

I would guess that it is an OpenGL problem, can you please post the output of:

   $ dpkg -l | grep OpenGL

This will tell me which version of GLUT you are using.

Thanks.


a

On 3 December 2012 12:26, Donghyeon Kim <danielkim at gist.ac.kr> wrote:
> Hi everyone,
>
> My name is Donghyeon Kim and Phd student in GIST. 4 month ago, I learned
> how to use minc toolbox in montreal, and now I'm already using it.
> Because of few problem in our lab, I'm using windows. Thus i installed
> minc toolbox in virtual machine(ubuntu 12.04 64x). However, in
> virtual machine, I cannot run register and display; it occurs error
> "segmantation fault". may be it is about openGL problem. So now, I'm using
> MINCbuntu in packages.bic.mn.mcgill.ca and it doesn't have any problem
> to run display and register. But MINCbuntu is ubuntu 8.04 and it is
> 32bit. I want to use ubuntu 10.04 or 12.04 64bit using virtual machine.
> So my question is how can i set minctoolbox in virtualmachine (ubuntu 10.04 or 12.04 64bit) to run display and register properly?
>
> Thank you
> Donghyeon
>
>
>
>
>
>
>
>
>
>
>
>
>
>             --------------------------------------------------
>
>             DONGHYEON KIM, PhD Student
>
>             Dept. of Info. &amp; Comm., Gwangju Institute of Science and Technology(GIST)
>
>             261 Cheomdan-gwagiro, Buk-gu, Gwangju 500-712, South Korea
>
>             Tel: +82-62-715-2266 Cell: +82-10-9361-3781
>
>             E-mail: danielkim at gist.ac.kr URL: http://biocomput.gist.ac.kr
>
>
>
>
>
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From danielkim at gist.ac.kr  Mon Dec  3 02:38:24 2012
From: danielkim at gist.ac.kr (Donghyeon Kim)
Date: Mon, 3 Dec 2012 16:38:24 +0900 (KST)
Subject: [MINC-users] Using MINC in virtual machine
In-Reply-To: <CAG0CB21GZsaGzu=Zso298LoBctis39BY5QRin1g_CrVFcuFP=A@mail.gmail.com>
Message-ID: <1202233077.1354520304072.JavaMail.root@eunhasu>

Hi Andrew, Thanks for replay. Following is the log



danielkim at danielkim-VirtualBox:~$ register
OpenGL Warning: XGetVisualInfo returned 0 visuals for 0x1e201d0
OpenGL Warning: Retry with 0x8002 returned 0 visuals
Segmentation fault (core dumped)
danielkim at danielkim-VirtualBox:~$ dpkg -l |grep OpenGL
ii  freeglut3                          2.6.0-1ubuntu3                          OpenGL Utility Toolkit
ii  freeglut3-dbg                      2.6.0-1ubuntu3                          OpenGL Utility Toolkit debugging information
ii  freeglut3-dev                      2.6.0-1ubuntu3                          OpenGL Utility Toolkit development files
ii  libgl1-mesa-dev                    8.0.4-0ubuntu0.2                        free implementation of the OpenGL API -- GLX development files
ii  libgl1-mesa-dri                    8.0.4-0ubuntu0.2                        free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-glx                    8.0.4-0ubuntu0.2                        free implementation of the OpenGL API -- GLX runtime
ii  libgl2ps0                          1.3.6-1                                 Lib providing high quality vector output for OpenGL application
ii  libglu1-mesa                       8.0.4-0ubuntu0.2                        Mesa OpenGL utility library (GLU)
ii  libglu1-mesa-dev                   8.0.4-0ubuntu0.2                        Mesa OpenGL utility library -- development files
ii  libgtkglext1                       1.2.0-2fakesync1                        OpenGL Extension to GTK+ (shared libraries)
danielkim at danielkim-VirtualBox:~$ Display
OpenGL Warning: XGetVisualInfo returned 0 visuals for 0xb155b0
OpenGL Warning: Retry with 0x8002 returned 0 visuals
Segmentation fault (core dumped)


I use Oracle virtual box 4.2.4 and It is Lubuntu 12.04. When I turn off 3D acceration option in virtual machine, register works well, but Display didn't work properly; 3D render view was disappeared.

And when i turn of 3D acceration option, register and Display didn't work.



Donghyeon


--- Original Message ---

>From    :  "Andrew Janke"<a.janke at gmail.com>

To      :  "Donghyeon Kim"<danielkim at gist.ac.kr>, "MINC users mailing list"<minc-users at bic.mni.mcgill.ca>

Date    :  2012/12/03 ??? ?? 3:31:55

Subject :  Re: [MINC-users] Using MINC in virtual machine



Hi Donghyeon, 



I would guess that it is an OpenGL problem, can you please post the output of: 



$ dpkg -l | grep OpenGL 



This will tell me which version of GLUT you are using. 



Thanks. 





a 



On 3 December 2012 12:26, Donghyeon Kim <danielkim at gist.ac.kr>






 

    
        
            -------------------------------------------------- 

            DONGHYEON KIM, PhD Student 

            Dept. of Info. &amp; Comm., Gwangju Institute of Science and Technology(GIST) 

            261 Cheomdan-gwagiro, Buk-gu, Gwangju 500-712, South Korea

            Tel: +82-62-715-2266 Cell: +82-10-9361-3781

            E-mail: danielkim at gist.ac.kr URL: https://biocomput.gist.ac.kr

             
        
    



From danielkim at gist.ac.kr  Mon Dec  3 02:51:55 2012
From: danielkim at gist.ac.kr (Donghyeon Kim)
Date: Mon, 3 Dec 2012 16:51:55 +0900 (KST)
Subject: [MINC-users] Using MINC in virtual machine
In-Reply-To: <CAG0CB21GZsaGzu=Zso298LoBctis39BY5QRin1g_CrVFcuFP=A@mail.gmail.com>
Message-ID: <781643873.1354521115123.JavaMail.root@eunhasu>

Hi Andrew, Thanks for replay. Following is the log



danielkim at danielkim-VirtualBox:~$ register
OpenGL Warning: XGetVisualInfo returned 0 visuals for 0x1e201d0
OpenGL Warning: Retry with 0x8002 returned 0 visuals
Segmentation fault (core dumped)
danielkim at danielkim-VirtualBox:~$ dpkg -l |grep OpenGL
ii  freeglut3                          2.6.0-1ubuntu3                          OpenGL Utility Toolkit
ii  freeglut3-dbg                      2.6.0-1ubuntu3                          OpenGL Utility Toolkit debugging information
ii  freeglut3-dev                      2.6.0-1ubuntu3                          OpenGL Utility Toolkit development files
ii  libgl1-mesa-dev                    8.0.4-0ubuntu0.2                        free implementation of the OpenGL API -- GLX development files
ii  libgl1-mesa-dri                    8.0.4-0ubuntu0.2                        free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-glx                    8.0.4-0ubuntu0.2                        free implementation of the OpenGL API -- GLX runtime
ii  libgl2ps0                          1.3.6-1                                 Lib providing high quality vector output for OpenGL application
ii  libglu1-mesa                       8.0.4-0ubuntu0.2                        Mesa OpenGL utility library (GLU)
ii  libglu1-mesa-dev                   8.0.4-0ubuntu0.2                        Mesa OpenGL utility library -- development files
ii  libgtkglext1                       1.2.0-2fakesync1                        OpenGL Extension to GTK+ (shared libraries)
danielkim at danielkim-VirtualBox:~$ Display
OpenGL Warning: XGetVisualInfo returned 0 visuals for 0xb155b0
OpenGL Warning: Retry with 0x8002 returned 0 visuals
Segmentation fault (core dumped)


I use Oracle virtual box 4.2.4 and It is Lubuntu 12.04. When I turn off 3D acceration option in virtual machine, register works well, but Display didn't work properly; 3D render view was disappeared.

And when i turn of 3D acceration option, register and Display didn't work.



Donghyeon


--- Original Message ---

>From    :  "Andrew Janke"<a.janke at gmail.com>

To      :  "Donghyeon Kim"<danielkim at gist.ac.kr>, "MINC users mailing list"<minc-users at bic.mni.mcgill.ca>

Date    :  2012/12/03 ??? ?? 3:31:55

Subject :  Re: [MINC-users] Using MINC in virtual machine



Hi Donghyeon, 



I would guess that it is an OpenGL problem, can you please post the output of: 



$ dpkg -l | grep OpenGL 



This will tell me which version of GLUT you are using. 



Thanks. 





a 



On 3 December 2012 12:26, Donghyeon Kim <danielkim at gist.ac.kr>






 

    
        
            -------------------------------------------------- 

            DONGHYEON KIM, PhD Student 

            Dept. of Info. &amp; Comm., Gwangju Institute of Science and Technology(GIST) 

            261 Cheomdan-gwagiro, Buk-gu, Gwangju 500-712, South Korea

            Tel: +82-62-715-2266 Cell: +82-10-9361-3781

            E-mail: danielkim at gist.ac.kr URL: https://biocomput.gist.ac.kr

             
        
    



From vladimir.fonov at gmail.com  Mon Dec  3 11:16:32 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Mon, 03 Dec 2012 11:16:32 -0500
Subject: [MINC-users] Using MINC in virtual machine
In-Reply-To: <781643873.1354521115123.JavaMail.root@eunhasu>
References: <781643873.1354521115123.JavaMail.root@eunhasu>
Message-ID: <50BCD060.50305@gmail.com>

Hello,

try setting LIBGL_ALWAYS_INDIRECT to 1

i.e before running register or display:
export LIBGL_ALWAYS_INDIRECT=1


On 12-12-03 02:51 AM, Donghyeon Kim wrote:
> Hi Andrew, Thanks for replay. Following is the log
>
>
>
> danielkim at danielkim-VirtualBox:~$ register
> OpenGL Warning: XGetVisualInfo returned 0 visuals for 0x1e201d0
> OpenGL Warning: Retry with 0x8002 returned 0 visuals
> Segmentation fault (core dumped)
> danielkim at danielkim-VirtualBox:~$ dpkg -l |grep OpenGL
> ii  freeglut3                          2.6.0-1ubuntu3                          OpenGL Utility Toolkit
> ii  freeglut3-dbg                      2.6.0-1ubuntu3                          OpenGL Utility Toolkit debugging information
> ii  freeglut3-dev                      2.6.0-1ubuntu3                          OpenGL Utility Toolkit development files
> ii  libgl1-mesa-dev                    8.0.4-0ubuntu0.2                        free implementation of the OpenGL API -- GLX development files
> ii  libgl1-mesa-dri                    8.0.4-0ubuntu0.2                        free implementation of the OpenGL API -- DRI modules
> ii  libgl1-mesa-glx                    8.0.4-0ubuntu0.2                        free implementation of the OpenGL API -- GLX runtime
> ii  libgl2ps0                          1.3.6-1                                 Lib providing high quality vector output for OpenGL application
> ii  libglu1-mesa                       8.0.4-0ubuntu0.2                        Mesa OpenGL utility library (GLU)
> ii  libglu1-mesa-dev                   8.0.4-0ubuntu0.2                        Mesa OpenGL utility library -- development files
> ii  libgtkglext1                       1.2.0-2fakesync1                        OpenGL Extension to GTK+ (shared libraries)
> danielkim at danielkim-VirtualBox:~$ Display
> OpenGL Warning: XGetVisualInfo returned 0 visuals for 0xb155b0
> OpenGL Warning: Retry with 0x8002 returned 0 visuals
> Segmentation fault (core dumped)
>
>
> I use Oracle virtual box 4.2.4 and It is Lubuntu 12.04. When I turn off 3D acceration option in virtual machine, register works well, but Display didn't work properly; 3D render view was disappeared.
>
> And when i turn of 3D acceration option, register and Display didn't work.


-- 
Best regards,

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

From dallas.card at sickkids.ca  Tue Dec 11 12:56:09 2012
From: dallas.card at sickkids.ca (Dallas Card)
Date: Tue, 11 Dec 2012 17:56:09 +0000
Subject: [MINC-users] bug in minctracc when using mutual information and
	thresholds
Message-ID: <60F32618B6D4F34F84089366F10ED3A329E37679@SKMBXX01.sickkids.ca>

Hello all,

I believe I've found a bug in minctracc. The -threshold option allows you to set thresholds, which are supposed to be specified in terms of the real range. However, when using the mutual information objective function (-mi) the input volumes are automatically converted to bytes, and the thresholds get interpreted in the range 0-255.

The culprit seems to be the function that is used to convert the data, namely replace_volume_data_with_ubyte() in minctracc/Optimize/optimize.c, which contains the following comment:

   /*
   * BLEAGHH!! This is an evil and nasty hack, made worse by the fact that
   * we have to support two versions of Volume_io for it to work!  (At
   * least this is done by the VOXEL_DATA hack^H^H^H^Hmacro, in <config.h>.)
   * -GPW 96/04/34
   */

It does convert the values to bytes, but it fails to set the "real_range_set" flag to True. Thus, when the data are eventually compared to the thresholds, they are not converted back to the real values.

I believe a simple fix is to add the following line at the end of replace_volume_data_with_ubyte():

set_volume_real_range(data, min, max);


I'll make the change and create a pull request.

Cheers,
Dallas

P.S. My apologies if you're seeing this message for the second time.



________________________________

This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.

From pgravel at bic.mni.mcgill.ca  Tue Dec 11 18:59:50 2012
From: pgravel at bic.mni.mcgill.ca (Paul GRAVEL)
Date: Tue, 11 Dec 2012 18:59:50 -0500 (EST)
Subject: [MINC-users] Registering 3T MRI to stereotaxic space
In-Reply-To: <50BCD060.50305@gmail.com>
References: <781643873.1354521115123.JavaMail.root@eunhasu>
	<50BCD060.50305@gmail.com>
Message-ID: <Pine.LNX.4.64.1212111855530.12273@agrippa.bic.mni.mcgill.ca>

Dear All,

I am trying to estimate the transformation parameters to co-register an 
MRI acquired on the 3T MR machine here at the MNI, and it seems that 
mritotal doesn't do such a good job (I used it before for scans 
acquired on the 1.5T machine without any problems). Therefore, I was 
wondering if anyone would have the latest procedure (and is willing to 
share ;-)! ) to coregister an MRI from the 3T to stereotaxic space.

Many thanks!

Paul



From eskild at gmail.com  Wed Dec 12 03:05:35 2012
From: eskild at gmail.com (Simon Eskildsen)
Date: Wed, 12 Dec 2012 09:05:35 +0100
Subject: [MINC-users] Registering 3T MRI to stereotaxic space
In-Reply-To: <Pine.LNX.4.64.1212111855530.12273@agrippa.bic.mni.mcgill.ca>
References: <781643873.1354521115123.JavaMail.root@eunhasu>
	<50BCD060.50305@gmail.com>
	<Pine.LNX.4.64.1212111855530.12273@agrippa.bic.mni.mcgill.ca>
Message-ID: <CAD3v437bZowzM-fpKcpt+k4Lww=5a1a0jZEXVLRMMU+SgA7N9Q@mail.gmail.com>

Hi Paul,

I find that Claude's bestlinreg_s works well. The script is included in
MINC Tool Kit,
http://www.bic.mni.mcgill.ca/ServicesSoftware/ServicesSoftwareMincToolKit

Simon



On Wed, Dec 12, 2012 at 12:59 AM, Paul GRAVEL <pgravel at bic.mni.mcgill.ca>wrote:

> Dear All,
>
> I am trying to estimate the transformation parameters to co-register an
> MRI acquired on the 3T MR machine here at the MNI, and it seems that
> mritotal doesn't do such a good job (I used it before for scans acquired on
> the 1.5T machine without any problems). Therefore, I was wondering if
> anyone would have the latest procedure (and is willing to share ;-)! ) to
> coregister an MRI from the 3T to stereotaxic space.
>
> Many thanks!
>
> Paul
>
>
> ______________________________**_________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/**mailman/listinfo/minc-users<http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users>
>

From pgravel at bic.mni.mcgill.ca  Wed Dec 12 12:50:28 2012
From: pgravel at bic.mni.mcgill.ca (Paul GRAVEL)
Date: Wed, 12 Dec 2012 12:50:28 -0500 (EST)
Subject: [MINC-users] Registering 3T MRI to stereotaxic space
In-Reply-To: <CAD3v437bZowzM-fpKcpt+k4Lww=5a1a0jZEXVLRMMU+SgA7N9Q@mail.gmail.com>
References: <781643873.1354521115123.JavaMail.root@eunhasu>
	<50BCD060.50305@gmail.com>
	<Pine.LNX.4.64.1212111855530.12273@agrippa.bic.mni.mcgill.ca>
	<CAD3v437bZowzM-fpKcpt+k4Lww=5a1a0jZEXVLRMMU+SgA7N9Q@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1212121250060.4745@agrippa.bic.mni.mcgill.ca>

Thanks Simon!

I'll give it a try.

Best Regards,

Paul


On Wed, 12 Dec 2012, Simon Eskildsen wrote:

> Hi Paul,
>
> I find that Claude's bestlinreg_s works well. The script is included in
> MINC Tool Kit,
> http://www.bic.mni.mcgill.ca/ServicesSoftware/ServicesSoftwareMincToolKit
>
> Simon
>
>
>
> On Wed, Dec 12, 2012 at 12:59 AM, Paul GRAVEL <pgravel at bic.mni.mcgill.ca>wrote:
>
>> Dear All,
>>
>> I am trying to estimate the transformation parameters to co-register an
>> MRI acquired on the 3T MR machine here at the MNI, and it seems that
>> mritotal doesn't do such a good job (I used it before for scans acquired on
>> the 1.5T machine without any problems). Therefore, I was wondering if
>> anyone would have the latest procedure (and is willing to share ;-)! ) to
>> coregister an MRI from the 3T to stereotaxic space.
>>
>> Many thanks!
>>
>> Paul
>>
>>
>> ______________________________**_________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/**mailman/listinfo/minc-users<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 cecile.madjar at gmail.com  Wed Dec 12 14:12:27 2012
From: cecile.madjar at gmail.com (Cecile Madjar)
Date: Wed, 12 Dec 2012 14:12:27 -0500
Subject: [MINC-users] loss of image origin while converting from dicom to
	minc format
In-Reply-To: <36A82CDF-E5F9-40AE-8EA1-6000CB92D06E@gmail.com>
References: <36A82CDF-E5F9-40AE-8EA1-6000CB92D06E@gmail.com>
Message-ID: <AE3251A6-B5E4-4B16-9A94-8FA4FFB3901F@gmail.com>

Good afternoon,

I am running into some troubles while converting MR images from dicom to the minc format. It looks like the origin of the image is lost when converting using dcm2mnc. I tried with several version of dcm2mnc (see below the email) and this was consistent across the versions I had. 

During the conversion process, I get this warning but don't know if this could be related:
WARNING: Coordinate spacing (7) differs from DICOM slice spacing (7.98)
 (perhaps you should consider the -usecoordinates option)
 Using 7.98 for the slice spacing value.

Out of desperation, I tried considering the -usecoordinates option but I have the same origin loss issue and it uses very strange slice spacing for some acquisitions (i.e. -14.34 instead of 1.6).

I also tried converting the data from dicom to nifti and then from nifti to minc which *solves* the origin issue (in a very dirty way) but brings other issues as many fields are lost in the process (like acquisition:repetition_time and most of other acquisition:<attr> parameters). This is as problematic as losing the origin as I also need those information for further analyses.

Have anyone else experience this issue before? Is there any clean way to keep the origin of the image in the minc file? 
I will be happy to provide a set of data if necessary or any information that I may have forgotten. 

Thank you!!
Best,

C?cile 


##################################################
I tried with several versions of dcm2mnc, including:

- the latest Mac version (on Mountain Lion)
program: 2.0.07 built Nov 13 2012 18:01:11
libminc: 2.2.00
netcdf : 4.2.1 of Nov 13 2012 17:59:00 $
HDF5   : 1.8.8
 
- the version from ~April 2012 on Ubuntu (don't have the information for this binary anymore)

- the version from Aug. 2012 on Ubuntu
program: 2.0.07 built Aug  9 2012 12:44:38
libminc: 2.1.10
netcdf : 4.1.1 of Nov  7 2011 11:35:16 $
HDF5   : 1.8.4



From vladimir.fonov at gmail.com  Wed Dec 12 17:28:35 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Wed, 12 Dec 2012 17:28:35 -0500
Subject: [MINC-users] Registering 3T MRI to stereotaxic space
In-Reply-To: <Pine.LNX.4.64.1212111855530.12273@agrippa.bic.mni.mcgill.ca>
References: <781643873.1354521115123.JavaMail.root@eunhasu>
	<50BCD060.50305@gmail.com>
	<Pine.LNX.4.64.1212111855530.12273@agrippa.bic.mni.mcgill.ca>
Message-ID: <50C90513.30903@gmail.com>

Hello Paul,

you can try running "standard pipeline" - also distributed with 
minc-toolkit :

1. source the environment

source /ipl/quarantine/experimental/2012-09-18/init.sh for bash
or
source /ipl/quarantine/experimental/2012-09-18/init.csh

2. run the pipeline:


/ipl/quarantine/experimental/2012-09-18/pipeline/standard_pipeline.pl 
<subject> <visit> <t1w.mnc> --prefix <out> --disable_nonlinear 
--model_dir /ipl/quarantine/models/icbm152_model_09c --model 
mni_icbm152_t1_tal_nlin_sym_09c

it will perfom linear registration and brain extraction using BEaST, the 
output files  will following:

<out>/<subject>/<visit>/tal/tal_xfm_<subject>_<visit>_t1w.xfm - linear 
transformation from native space to standard space


<out>/<subject>/<visit>/tal/tal_<subject>_<visit>_t1w.mnc - normalized 
t1w scan in standard space space

<out>/<subject>/<visit>/tal/tal_comp_msk_<subject>_<visit>.mnc - brain mask.

On 12-12-11 06:59 PM, Paul GRAVEL wrote:
> Dear All,
>
> I am trying to estimate the transformation parameters to co-register an
> MRI acquired on the 3T MR machine here at the MNI, and it seems that
> mritotal doesn't do such a good job (I used it before for scans acquired
> on the 1.5T machine without any problems). Therefore, I was wondering if
> anyone would have the latest procedure (and is willing to share ;-)! )
> to coregister an MRI from the 3T to stereotaxic space.


-- 
Best regards,

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

From pgravel at bic.mni.mcgill.ca  Wed Dec 12 17:45:37 2012
From: pgravel at bic.mni.mcgill.ca (Paul GRAVEL)
Date: Wed, 12 Dec 2012 17:45:37 -0500 (EST)
Subject: [MINC-users] Registering 3T MRI to stereotaxic space
In-Reply-To: <50C90513.30903@gmail.com>
References: <781643873.1354521115123.JavaMail.root@eunhasu>
	<50BCD060.50305@gmail.com>
	<Pine.LNX.4.64.1212111855530.12273@agrippa.bic.mni.mcgill.ca>
	<50C90513.30903@gmail.com>
Message-ID: <Pine.LNX.4.64.1212121744020.25234@agrippa.bic.mni.mcgill.ca>

Many thanks Vladimir!

I will give it a try...

@Simon: I did give bestlinreg_s a try, and it definitely does a better job 
I previously had, i.e. mritotal!

Best Regards,

Paul


On Wed, 12 Dec 2012, Vladimir S. FONOV wrote:

> Hello Paul,
>
> you can try running "standard pipeline" - also distributed with minc-toolkit 
> :
>
> 1. source the environment
>
> source /ipl/quarantine/experimental/2012-09-18/init.sh for bash
> or
> source /ipl/quarantine/experimental/2012-09-18/init.csh
>
> 2. run the pipeline:
>
>
> /ipl/quarantine/experimental/2012-09-18/pipeline/standard_pipeline.pl 
> <subject> <visit> <t1w.mnc> --prefix <out> --disable_nonlinear --model_dir 
> /ipl/quarantine/models/icbm152_model_09c --model 
> mni_icbm152_t1_tal_nlin_sym_09c
>
> it will perfom linear registration and brain extraction using BEaST, the 
> output files  will following:
>
> <out>/<subject>/<visit>/tal/tal_xfm_<subject>_<visit>_t1w.xfm - linear 
> transformation from native space to standard space
>
>
> <out>/<subject>/<visit>/tal/tal_<subject>_<visit>_t1w.mnc - normalized t1w 
> scan in standard space space
>
> <out>/<subject>/<visit>/tal/tal_comp_msk_<subject>_<visit>.mnc - brain mask.
>
> On 12-12-11 06:59 PM, Paul GRAVEL wrote:
>> Dear All,
>> 
>> I am trying to estimate the transformation parameters to co-register an
>> MRI acquired on the 3T MR machine here at the MNI, and it seems that
>> mritotal doesn't do such a good job (I used it before for scans acquired
>> on the 1.5T machine without any problems). Therefore, I was wondering if
>> anyone would have the latest procedure (and is willing to share ;-)! )
>> to coregister an MRI from the 3T to stereotaxic space.
>
>
> -- 
> 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 claude at bic.mni.mcgill.ca  Wed Dec 12 18:02:28 2012
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Wed, 12 Dec 2012 18:02:28 -0500
Subject: [MINC-users] Registering 3T MRI to stereotaxic space
In-Reply-To: <Pine.LNX.4.64.1212121744020.25234@agrippa.bic.mni.mcgill.ca>
Message-ID: <201212122302.qBCN2S9b000562@agrippa.bic.mni.mcgill.ca>

Paul,

I also have a new improved best bestlinreg script. :-) I gave a copy
of it to Vlad too.

To some, it may sound counter intuitive, but I'm now using -nmi
(normalized mutual information) for linear registration. It is
much more robust than xcorr and rather insensitive to variations 
in intensities if N3 is not performed a priori.  A mask is no 
longer necessary for linear registration, although cropping the 
neck usually helps. 

Claude


>
> Many thanks Vladimir!
>
> I will give it a try...
>
> @Simon: I did give bestlinreg_s a try, and it definitely does a better job 
> I previously had, i.e. mritotal!
>
> Best Regards,
>
> Paul
>
>
> On Wed, 12 Dec 2012, Vladimir S. FONOV wrote:
>
> > Hello Paul,
> >
> > you can try running "standard pipeline" - also distributed with minc-toolkit 
> > :
> >
> > 1. source the environment
> >
> > source /ipl/quarantine/experimental/2012-09-18/init.sh for bash
> > or
> > source /ipl/quarantine/experimental/2012-09-18/init.csh
> >
> > 2. run the pipeline:
> >
> >
> > /ipl/quarantine/experimental/2012-09-18/pipeline/standard_pipeline.pl 
> > <subject> <visit> <t1w.mnc> --prefix <out> --disable_nonlinear --model_dir 
> > /ipl/quarantine/models/icbm152_model_09c --model 
> > mni_icbm152_t1_tal_nlin_sym_09c
> >
> > it will perfom linear registration and brain extraction using BEaST, the 
> > output files  will following:
> >
> > <out>/<subject>/<visit>/tal/tal_xfm_<subject>_<visit>_t1w.xfm - linear 
> > transformation from native space to standard space
> >
> >
> > <out>/<subject>/<visit>/tal/tal_<subject>_<visit>_t1w.mnc - normalized t1w 
> > scan in standard space space
> >
> > <out>/<subject>/<visit>/tal/tal_comp_msk_<subject>_<visit>.mnc - brain mask.
> >
> > On 12-12-11 06:59 PM, Paul GRAVEL wrote:
> >> Dear All,
> >> 
> >> I am trying to estimate the transformation parameters to co-register an
> >> MRI acquired on the 3T MR machine here at the MNI, and it seems that
> >> mritotal doesn't do such a good job (I used it before for scans acquired
> >> on the 1.5T machine without any problems). Therefore, I was wondering if
> >> anyone would have the latest procedure (and is willing to share ;-)! )
> >> to coregister an MRI from the 3T to stereotaxic space.
> >
> >
> > -- 
> > Best regards,
> >
> > Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From sorench at gmail.com  Thu Dec 13 17:34:58 2012
From: sorench at gmail.com (Soren Christensen)
Date: Thu, 13 Dec 2012 14:34:58 -0800
Subject: [MINC-users] Display zoom not working
Message-ID: <CAHfsrRb5fvPSo=2w6YOXA1XM4kQ+iKSNyFzjYXU1aqCbwdznYQ@mail.gmail.com>

Hi,
 I am using Display 1.6.0 bult form the minc-toolkit.
For some reason shift-left does not zoom anymore (or was it shift-middle
drag it used be be - either way not working). Has anyone else had issues
with this/know how to fix it? I am on Fedora 17.
Thanks

Soren

From vladimir.fonov at gmail.com  Thu Dec 13 17:41:00 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Thu, 13 Dec 2012 17:41:00 -0500
Subject: [MINC-users] Display zoom not working
In-Reply-To: <CAHfsrRb5fvPSo=2w6YOXA1XM4kQ+iKSNyFzjYXU1aqCbwdznYQ@mail.gmail.com>
References: <CAHfsrRb5fvPSo=2w6YOXA1XM4kQ+iKSNyFzjYXU1aqCbwdznYQ@mail.gmail.com>
Message-ID: <50CA597C.9050800@gmail.com>

I just tried - it works for me on Ubuntu 12.04 with shift-middle ,
shift-left drags the image around and shift-right erases the labels.

On 12-12-13 05:34 PM, Soren Christensen wrote:
>   I am using Display 1.6.0 bult form the minc-toolkit.
> For some reason shift-left does not zoom anymore (or was it shift-middle
> drag it used be be - either way not working). Has anyone else had issues
> with this/know how to fix it? I am on Fedora 17.


-- 
Best regards,

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

From pgravel at bic.mni.mcgill.ca  Thu Dec 13 18:37:04 2012
From: pgravel at bic.mni.mcgill.ca (Paul GRAVEL)
Date: Thu, 13 Dec 2012 18:37:04 -0500 (EST)
Subject: [MINC-users] Registering 3T MRI to stereotaxic space
In-Reply-To: <201212122302.qBCN2S9b000562@agrippa.bic.mni.mcgill.ca>
References: <201212122302.qBCN2S9b000562@agrippa.bic.mni.mcgill.ca>
Message-ID: <Pine.LNX.4.64.1212131836180.16496@agrippa.bic.mni.mcgill.ca>

Thanks Claude!

Is the new and improved script now part of the minc-toolkit as well?

Best Regards,

Paul


On Wed, 12 Dec 2012, Claude LEPAGE wrote:

> Paul,
>
> I also have a new improved best bestlinreg script. :-) I gave a copy
> of it to Vlad too.
>
> To some, it may sound counter intuitive, but I'm now using -nmi
> (normalized mutual information) for linear registration. It is
> much more robust than xcorr and rather insensitive to variations
> in intensities if N3 is not performed a priori.  A mask is no
> longer necessary for linear registration, although cropping the
> neck usually helps.
>
> Claude
>
>
>>
>> Many thanks Vladimir!
>>
>> I will give it a try...
>>
>> @Simon: I did give bestlinreg_s a try, and it definitely does a better job
>> I previously had, i.e. mritotal!
>>
>> Best Regards,
>>
>> Paul
>>
>>
>> On Wed, 12 Dec 2012, Vladimir S. FONOV wrote:
>>
>>> Hello Paul,
>>>
>>> you can try running "standard pipeline" - also distributed with minc-toolkit
>>> :
>>>
>>> 1. source the environment
>>>
>>> source /ipl/quarantine/experimental/2012-09-18/init.sh for bash
>>> or
>>> source /ipl/quarantine/experimental/2012-09-18/init.csh
>>>
>>> 2. run the pipeline:
>>>
>>>
>>> /ipl/quarantine/experimental/2012-09-18/pipeline/standard_pipeline.pl
>>> <subject> <visit> <t1w.mnc> --prefix <out> --disable_nonlinear --model_dir
>>> /ipl/quarantine/models/icbm152_model_09c --model
>>> mni_icbm152_t1_tal_nlin_sym_09c
>>>
>>> it will perfom linear registration and brain extraction using BEaST, the
>>> output files  will following:
>>>
>>> <out>/<subject>/<visit>/tal/tal_xfm_<subject>_<visit>_t1w.xfm - linear
>>> transformation from native space to standard space
>>>
>>>
>>> <out>/<subject>/<visit>/tal/tal_<subject>_<visit>_t1w.mnc - normalized t1w
>>> scan in standard space space
>>>
>>> <out>/<subject>/<visit>/tal/tal_comp_msk_<subject>_<visit>.mnc - brain mask.
>>>
>>> On 12-12-11 06:59 PM, Paul GRAVEL wrote:
>>>> Dear All,
>>>>
>>>> I am trying to estimate the transformation parameters to co-register an
>>>> MRI acquired on the 3T MR machine here at the MNI, and it seems that
>>>> mritotal doesn't do such a good job (I used it before for scans acquired
>>>> on the 1.5T machine without any problems). Therefore, I was wondering if
>>>> anyone would have the latest procedure (and is willing to share ;-)! )
>>>> to coregister an MRI from the 3T to stereotaxic space.
>>>
>>>
>>> --
>>> Best regards,
>>>
>>> Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com
>>> _______________________________________________
>>> MINC-users at bic.mni.mcgill.ca
>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>>
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From sorench at gmail.com  Thu Dec 13 23:23:03 2012
From: sorench at gmail.com (Soren Christensen)
Date: Fri, 14 Dec 2012 15:23:03 +1100
Subject: [MINC-users] Display zoom not working
In-Reply-To: <50CA597C.9050800@gmail.com>
References: <CAHfsrRb5fvPSo=2w6YOXA1XM4kQ+iKSNyFzjYXU1aqCbwdznYQ@mail.gmail.com>
	<50CA597C.9050800@gmail.com>
Message-ID: <CAHfsrRaXadNj-6gy1LBQMBq=VPVx8uTS_3NGWEAhsS=GxfJbKg@mail.gmail.com>

Thanks that helped pin it down. It was gnome shadowing that event for
something (move windows?).

yum install dconf-editor

then org?gnome?desktop?wm?preferences and change the mouse-button-modifier
to ""

Soren


On Fri, Dec 14, 2012 at 9:41 AM, Vladimir S. FONOV <vladimir.fonov at gmail.com
> wrote:

> I just tried - it works for me on Ubuntu 12.04 with shift-middle ,
> shift-left drags the image around and shift-right erases the labels.
>
>
> On 12-12-13 05:34 PM, Soren Christensen wrote:
>
>>   I am using Display 1.6.0 bult form the minc-toolkit.
>> For some reason shift-left does not zoom anymore (or was it shift-middle
>> drag it used be be - either way not working). Has anyone else had issues
>> with this/know how to fix it? I am on Fedora 17.
>>
>
>
> --
> 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<http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users>
>

From a.janke at gmail.com  Fri Dec 14 06:05:58 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 14 Dec 2012 21:05:58 +1000
Subject: [MINC-users] Display zoom not working
In-Reply-To: <CAHfsrRaXadNj-6gy1LBQMBq=VPVx8uTS_3NGWEAhsS=GxfJbKg@mail.gmail.com>
References: <CAHfsrRb5fvPSo=2w6YOXA1XM4kQ+iKSNyFzjYXU1aqCbwdznYQ@mail.gmail.com>
	<50CA597C.9050800@gmail.com>
	<CAHfsrRaXadNj-6gy1LBQMBq=VPVx8uTS_3NGWEAhsS=GxfJbKg@mail.gmail.com>
Message-ID: <CAG0CB20bBhS5rj1sKyR8sFBud8O-K++_6Nbt18qb574p9Zm_Hg@mail.gmail.com>

Or: Just use the Control key, both Shift and Control work.

a


On 14 December 2012 14:23, Soren Christensen <sorench at gmail.com> wrote:
> Thanks that helped pin it down. It was gnome shadowing that event for
> something (move windows?).

From vladimir.fonov at gmail.com  Fri Dec 14 10:54:52 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Fri, 14 Dec 2012 10:54:52 -0500
Subject: [MINC-users] Registering 3T MRI to stereotaxic space
In-Reply-To: <Pine.LNX.4.64.1212131836180.16496@agrippa.bic.mni.mcgill.ca>
References: <201212122302.qBCN2S9b000562@agrippa.bic.mni.mcgill.ca>
	<Pine.LNX.4.64.1212131836180.16496@agrippa.bic.mni.mcgill.ca>
Message-ID: <CAMCwi7NT_pzAVr=YMFO7DUFTcmm_fHwKK+G6k77B=4+W1W3OQg@mail.gmail.com>

Hello,

yes, I included Claude's changes into bestlireg_s , call it with -nmi
option.


On Thu, Dec 13, 2012 at 6:37 PM, Paul GRAVEL <pgravel at bic.mni.mcgill.ca>wrote:

> Thanks Claude!
>
> Is the new and improved script now part of the minc-toolkit as well?
>
> Best Regards,
>
> Paul
>
>
>
> On Wed, 12 Dec 2012, Claude LEPAGE wrote:
>
>  Paul,
>>
>> I also have a new improved best bestlinreg script. :-) I gave a copy
>> of it to Vlad too.
>>
>> To some, it may sound counter intuitive, but I'm now using -nmi
>> (normalized mutual information) for linear registration. It is
>> much more robust than xcorr and rather insensitive to variations
>> in intensities if N3 is not performed a priori.  A mask is no
>> longer necessary for linear registration, although cropping the
>> neck usually helps.
>>
>> Claude
>>
>>
>>
>>> Many thanks Vladimir!
>>>
>>> I will give it a try...
>>>
>>> @Simon: I did give bestlinreg_s a try, and it definitely does a better
>>> job
>>> I previously had, i.e. mritotal!
>>>
>>> Best Regards,
>>>
>>> Paul
>>>
>>>
>>> On Wed, 12 Dec 2012, Vladimir S. FONOV wrote:
>>>
>>>  Hello Paul,
>>>>
>>>> you can try running "standard pipeline" - also distributed with
>>>> minc-toolkit
>>>> :
>>>>
>>>> 1. source the environment
>>>>
>>>> source /ipl/quarantine/experimental/**2012-09-18/init.sh for bash
>>>> or
>>>> source /ipl/quarantine/experimental/**2012-09-18/init.csh
>>>>
>>>> 2. run the pipeline:
>>>>
>>>>
>>>> /ipl/quarantine/experimental/**2012-09-18/pipeline/standard_**
>>>> pipeline.pl <http://standard_pipeline.pl>
>>>> <subject> <visit> <t1w.mnc> --prefix <out> --disable_nonlinear
>>>> --model_dir
>>>> /ipl/quarantine/models/**icbm152_model_09c --model
>>>> mni_icbm152_t1_tal_nlin_sym_**09c
>>>>
>>>> it will perfom linear registration and brain extraction using BEaST, the
>>>> output files  will following:
>>>>
>>>> <out>/<subject>/<visit>/tal/**tal_xfm_<subject>_<visit>_t1w.**xfm -
>>>> linear
>>>> transformation from native space to standard space
>>>>
>>>>
>>>> <out>/<subject>/<visit>/tal/**tal_<subject>_<visit>_t1w.mnc -
>>>> normalized t1w
>>>> scan in standard space space
>>>>
>>>> <out>/<subject>/<visit>/tal/**tal_comp_msk_<subject>_<visit>**.mnc -
>>>> brain mask.
>>>>
>>>> On 12-12-11 06:59 PM, Paul GRAVEL wrote:
>>>>
>>>>> Dear All,
>>>>>
>>>>> I am trying to estimate the transformation parameters to co-register an
>>>>> MRI acquired on the 3T MR machine here at the MNI, and it seems that
>>>>> mritotal doesn't do such a good job (I used it before for scans
>>>>> acquired
>>>>> on the 1.5T machine without any problems). Therefore, I was wondering
>>>>> if
>>>>> anyone would have the latest procedure (and is willing to share ;-)! )
>>>>> to coregister an MRI from the 3T to stereotaxic space.
>>>>>
>>>>
>>>>
>>>> --
>>>> 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<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<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<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<http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users>
>



-- 
Best regards,

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

From cecile.madjar at gmail.com  Fri Dec 14 12:56:56 2012
From: cecile.madjar at gmail.com (Cecile Madjar)
Date: Fri, 14 Dec 2012 12:56:56 -0500
Subject: [MINC-users] loss of image origin solved
Message-ID: <E4A9472B-4AE1-448B-A51A-FEB86CC0CC8C@gmail.com>

Hi everyone,

sorry I have misinterpreted the problem I had while superimposing bold images onto a t1 image taken during the same acquisition. Actually, the origin was not lost during the conversion.

I was experiencing a problem that came from register. Register was crashing (on Mac) while displaying bold images (with a significant angle) onto a t1 image systematically (i.e. register t1 bold). However, if I do the contrary, superimpose the t1 onto the bold, register was able to open the files (i.e. register bold t1). Claude helped me dig into this on a Linux installation and it looks like when register (on Linux) loads the second image, the cosines are not taken into account (or something like that). 

Anyway, sorry again for the false alarm concerning dcm2mnc conversion. 

Many thanks to Vlad and Claude for having helped me out with this issue!!

Have a great weekend!

C?cile



From sorench at gmail.com  Fri Dec 14 14:48:14 2012
From: sorench at gmail.com (Soren Christensen)
Date: Fri, 14 Dec 2012 11:48:14 -0800
Subject: [MINC-users] Display zoom not working
In-Reply-To: <CAG0CB20bBhS5rj1sKyR8sFBud8O-K++_6Nbt18qb574p9Zm_Hg@mail.gmail.com>
References: <CAHfsrRb5fvPSo=2w6YOXA1XM4kQ+iKSNyFzjYXU1aqCbwdznYQ@mail.gmail.com>
	<50CA597C.9050800@gmail.com>
	<CAHfsrRaXadNj-6gy1LBQMBq=VPVx8uTS_3NGWEAhsS=GxfJbKg@mail.gmail.com>
	<CAG0CB20bBhS5rj1sKyR8sFBud8O-K++_6Nbt18qb574p9Zm_Hg@mail.gmail.com>
Message-ID: <CAHfsrRYgBBwyw5hpS2ztd7O9ueS=DwW+iK+6TZudCbUUWn9uZg@mail.gmail.com>

That call back is also blocked.
Interestingly, the above procedure solves it on my laptop, but not on my
Desktop also with Fedora 17.

Apparently other have problems too and it has to do with the call back not
reaching glut I think: http://forums.fedoraforum.org/showthread.php?t=285424



Soren


On Fri, Dec 14, 2012 at 3:05 AM, Andrew Janke <a.janke at gmail.com> wrote:

> Or: Just use the Control key, both Shift and Control work.
>
> a
>
>
> On 14 December 2012 14:23, Soren Christensen <sorench at gmail.com> wrote:
> > Thanks that helped pin it down. It was gnome shadowing that event for
> > something (move windows?).
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From pgravel at bic.mni.mcgill.ca  Fri Dec 14 15:30:39 2012
From: pgravel at bic.mni.mcgill.ca (Paul GRAVEL)
Date: Fri, 14 Dec 2012 15:30:39 -0500 (EST)
Subject: [MINC-users] Registering 3T MRI to stereotaxic space
In-Reply-To: <CAMCwi7NT_pzAVr=YMFO7DUFTcmm_fHwKK+G6k77B=4+W1W3OQg@mail.gmail.com>
References: <201212122302.qBCN2S9b000562@agrippa.bic.mni.mcgill.ca>
	<Pine.LNX.4.64.1212131836180.16496@agrippa.bic.mni.mcgill.ca>
	<CAMCwi7NT_pzAVr=YMFO7DUFTcmm_fHwKK+G6k77B=4+W1W3OQg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1212141529360.836@agrippa.bic.mni.mcgill.ca>

Thanks Vlad,

I didn't get Claude's joke right away (lets just say it was late ;-)!).

Best,

Paul


On Fri, 14 Dec 2012, Vladimir S. FONOV wrote:

> Hello,
>
> yes, I included Claude's changes into bestlireg_s , call it with -nmi
> option.
>
>
> On Thu, Dec 13, 2012 at 6:37 PM, Paul GRAVEL <pgravel at bic.mni.mcgill.ca>wrote:
>
>> Thanks Claude!
>>
>> Is the new and improved script now part of the minc-toolkit as well?
>>
>> Best Regards,
>>
>> Paul
>>
>>
>>
>> On Wed, 12 Dec 2012, Claude LEPAGE wrote:
>>
>>  Paul,
>>>
>>> I also have a new improved best bestlinreg script. :-) I gave a copy
>>> of it to Vlad too.
>>>
>>> To some, it may sound counter intuitive, but I'm now using -nmi
>>> (normalized mutual information) for linear registration. It is
>>> much more robust than xcorr and rather insensitive to variations
>>> in intensities if N3 is not performed a priori.  A mask is no
>>> longer necessary for linear registration, although cropping the
>>> neck usually helps.
>>>
>>> Claude
>>>
>>>
>>>
>>>> Many thanks Vladimir!
>>>>
>>>> I will give it a try...
>>>>
>>>> @Simon: I did give bestlinreg_s a try, and it definitely does a better
>>>> job
>>>> I previously had, i.e. mritotal!
>>>>
>>>> Best Regards,
>>>>
>>>> Paul
>>>>
>>>>
>>>> On Wed, 12 Dec 2012, Vladimir S. FONOV wrote:
>>>>
>>>>  Hello Paul,
>>>>>
>>>>> you can try running "standard pipeline" - also distributed with
>>>>> minc-toolkit
>>>>> :
>>>>>
>>>>> 1. source the environment
>>>>>
>>>>> source /ipl/quarantine/experimental/**2012-09-18/init.sh for bash
>>>>> or
>>>>> source /ipl/quarantine/experimental/**2012-09-18/init.csh
>>>>>
>>>>> 2. run the pipeline:
>>>>>
>>>>>
>>>>> /ipl/quarantine/experimental/**2012-09-18/pipeline/standard_**
>>>>> pipeline.pl <http://standard_pipeline.pl>
>>>>> <subject> <visit> <t1w.mnc> --prefix <out> --disable_nonlinear
>>>>> --model_dir
>>>>> /ipl/quarantine/models/**icbm152_model_09c --model
>>>>> mni_icbm152_t1_tal_nlin_sym_**09c
>>>>>
>>>>> it will perfom linear registration and brain extraction using BEaST, the
>>>>> output files  will following:
>>>>>
>>>>> <out>/<subject>/<visit>/tal/**tal_xfm_<subject>_<visit>_t1w.**xfm -
>>>>> linear
>>>>> transformation from native space to standard space
>>>>>
>>>>>
>>>>> <out>/<subject>/<visit>/tal/**tal_<subject>_<visit>_t1w.mnc -
>>>>> normalized t1w
>>>>> scan in standard space space
>>>>>
>>>>> <out>/<subject>/<visit>/tal/**tal_comp_msk_<subject>_<visit>**.mnc -
>>>>> brain mask.
>>>>>
>>>>> On 12-12-11 06:59 PM, Paul GRAVEL wrote:
>>>>>
>>>>>> Dear All,
>>>>>>
>>>>>> I am trying to estimate the transformation parameters to co-register an
>>>>>> MRI acquired on the 3T MR machine here at the MNI, and it seems that
>>>>>> mritotal doesn't do such a good job (I used it before for scans
>>>>>> acquired
>>>>>> on the 1.5T machine without any problems). Therefore, I was wondering
>>>>>> if
>>>>>> anyone would have the latest procedure (and is willing to share ;-)! )
>>>>>> to coregister an MRI from the 3T to stereotaxic space.
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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<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<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<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<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 sorench at gmail.com  Fri Dec 14 20:27:59 2012
From: sorench at gmail.com (Soren Christensen)
Date: Fri, 14 Dec 2012 17:27:59 -0800
Subject: [MINC-users] mincreshape problem
Message-ID: <CAHfsrRYsL5QR4vPhvLB52SZwzmBZdjb83pkbbjJsX2GEuG104Q@mail.gmail.com>

Hi,
 I am trying to fix up some MINC files that were written by MIPAV, for some
reason some of these files have extra slices and displacement of the ROI.
In plane resolution is the same.
What I am stuck with is the followoing mincresample behaviour:

file: a.mnc
image: signed__ short -32768 to 32767
image dimensions: zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    zspace                     26            5     -77.0989
    yspace                    256      -0.9375      128.406
    xspace                    256      -0.9375      121.591


file: b.mnc
image: signed__ short -32767 to 32767
image dimensions: zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    zspace                     27            5     -77.0989
    yspace                    256      -0.9375      128.406
    xspace                    256      -0.9375      121.591


So file a has one slice less than b, but spatial info match. So I'd like to
resample b.mnc like a, in the hope that the top slice is irrelevant ()

mincresample -like a.mnc b.mnc b_likea.mnc
(from miattputstr): Function 'dimrename' not implemented
Transforming slices:..........................Done

#> mincinfo a.mnc b_likea.mnc
file: a.mnc
image: signed__ short -32768 to 32767
image dimensions: zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    zspace                     26            5     -77.0989
    yspace                    256      -0.9375      128.406
    xspace                    256      -0.9375      121.591


file: b_likea.mnc
image: signed__ short -32767 to 32767
image dimensions: zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    zspace                     27            5     -77.0989
    yspace                    256      -0.9375      128.406
    xspace                    256      -0.9375      121.591


So b_likea.mnc is not what expect it to be (26 slices). The file seems
broken:

Display b_likea.mnc
Input b_likea.mnc
HDF5-DIAG: Error detected in HDF5 (1.8.8) thread 0:
  #000: H5Dio.c line 153 in H5Dread(): selection+offset not within extent
    major: Dataspace
    minor: Out of range
(from miicv_attach): Can't read dataset /minc-2.0/image/0/image-min
(from miicv_attach): Can't read variable ID# 1
miicv_attach: MINC package entry point
HDF5-DIAG: Error detected in HDF5 (1.8.8) thread 0:
  #000: H5Dio.c line 153 in H5Dread(): selection+offset not within extent
    major: Dataspace
    minor: Out of range
(from miicv_attach): Can't read dataset /minc-2.0/image/0/image-min
(from miicv_attach): Can't read variable ID# 1
miicv_attach: MINC package entry point
(from miicv_get): ICV is not attached
(from miicv_get): ICV is not attached
(from miicv_get): ICV is not attached
(from miicv_get): ICV is not attached
(from miicv_get): ICV is not attached
(from miicv_get): ICV is not attached
(from miicv_get): ICV is not attached
(from miicv_get): ICV is not attached
(from miicv_get): ICV is not attached
(from miicv_get): ICV is not attached
(from miicv_get): ICV is not attached
(from miicv_get): ICV is not attached
(from miicv_get): ICV is not attached
(from miicv_get): ICV is not attached


Any suggestions to what is happening herE?

Soren

From a.janke at gmail.com  Sun Dec 16 15:20:41 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 17 Dec 2012 06:20:41 +1000
Subject: [MINC-users] mincreshape problem
In-Reply-To: <CAHfsrRYsL5QR4vPhvLB52SZwzmBZdjb83pkbbjJsX2GEuG104Q@mail.gmail.com>
References: <CAHfsrRYsL5QR4vPhvLB52SZwzmBZdjb83pkbbjJsX2GEuG104Q@mail.gmail.com>
Message-ID: <CAG0CB23y_LsDNjqkxuppbhorPkDurzjQpUc2bShWszq0g9OQ+Q@mail.gmail.com>

Hi Soren,

On 15 December 2012 11:27, Soren Christensen <sorench at gmail.com> wrote:
>  I am trying to fix up some MINC files that were written by MIPAV, for some
> reason some of these files have extra slices and displacement of the ROI.
> In plane resolution is the same.
> What I am stuck with is the followoing mincresample behaviour:

I have seen strange behaviour with malformed MINC files but not with
the particular error/warning that is being output for you.

First off, do the files have irregular or regular dimension spacing?

I have often found that rewriting the MINC file will sort things, one
way to force this is with mincconvert (to v1 and back again).

   $ mincconvert a.mnc a.mnc1
   $ mincconvert -2 a.mnc1 a.mnc



a

From vladimir.fonov at gmail.com  Sun Dec 16 16:16:39 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Sun, 16 Dec 2012 16:16:39 -0500
Subject: [MINC-users] mincreshape problem
In-Reply-To: <CAHfsrRYsL5QR4vPhvLB52SZwzmBZdjb83pkbbjJsX2GEuG104Q@mail.gmail.com>
References: <CAHfsrRYsL5QR4vPhvLB52SZwzmBZdjb83pkbbjJsX2GEuG104Q@mail.gmail.com>
Message-ID: <3AACE6F2-D1F1-4600-A337-0A718300702D@gmail.com>

Hello,


it looks like this minc file from MIPAV doesn't have variable image-min defined, i.e if you do h5ls -r on a well-defined minc2 file it will show you something like that:

/                        Group
/minc-2.0                Group
/minc-2.0/dimensions     Group
/minc-2.0/dimensions/xspace Dataset {SCALAR}
/minc-2.0/dimensions/yspace Dataset {SCALAR}
/minc-2.0/dimensions/zspace Dataset {SCALAR}
/minc-2.0/image          Group
/minc-2.0/image/0        Group
/minc-2.0/image/0/image  Dataset {193, 229, 193}
/minc-2.0/image/0/image-max Dataset {193}
/minc-2.0/image/0/image-min Dataset {193}
? etc ?

so, you file probably have /minc-2.0/image/0/image-min bit missing?
which is needed to correctly interpret the intensity information in the file.


On 2012-12-14, at 8:27 PM, Soren Christensen <sorench at gmail.com> wrote:

> Hi,
> I am trying to fix up some MINC files that were written by MIPAV, for some
> reason some of these files have extra slices and displacement of the ROI.
> In plane resolution is the same.
> What I am stuck with is the followoing mincresample behaviour:
> 
> file: a.mnc
> image: signed__ short -32768 to 32767
> image dimensions: zspace yspace xspace
>    dimension name         length         step        start
>    --------------         ------         ----        -----
>    zspace                     26            5     -77.0989
>    yspace                    256      -0.9375      128.406
>    xspace                    256      -0.9375      121.591
> 
> 
> file: b.mnc
> image: signed__ short -32767 to 32767
> image dimensions: zspace yspace xspace
>    dimension name         length         step        start
>    --------------         ------         ----        -----
>    zspace                     27            5     -77.0989
>    yspace                    256      -0.9375      128.406
>    xspace                    256      -0.9375      121.591
> 
> 
> So file a has one slice less than b, but spatial info match. So I'd like to
> resample b.mnc like a, in the hope that the top slice is irrelevant ()
> 
> mincresample -like a.mnc b.mnc b_likea.mnc
> (from miattputstr): Function 'dimrename' not implemented
> Transforming slices:..........................Done
> 
> #> mincinfo a.mnc b_likea.mnc
> file: a.mnc
> image: signed__ short -32768 to 32767
> image dimensions: zspace yspace xspace
>    dimension name         length         step        start
>    --------------         ------         ----        -----
>    zspace                     26            5     -77.0989
>    yspace                    256      -0.9375      128.406
>    xspace                    256      -0.9375      121.591
> 
> 
> file: b_likea.mnc
> image: signed__ short -32767 to 32767
> image dimensions: zspace yspace xspace
>    dimension name         length         step        start
>    --------------         ------         ----        -----
>    zspace                     27            5     -77.0989
>    yspace                    256      -0.9375      128.406
>    xspace                    256      -0.9375      121.591
> 
> 
> So b_likea.mnc is not what expect it to be (26 slices). The file seems
> broken:
> 
> Display b_likea.mnc
> Input b_likea.mnc
> HDF5-DIAG: Error detected in HDF5 (1.8.8) thread 0:
>  #000: H5Dio.c line 153 in H5Dread(): selection+offset not within extent
>    major: Dataspace
>    minor: Out of range
> (from miicv_attach): Can't read dataset /minc-2.0/image/0/image-min
> (from miicv_attach): Can't read variable ID# 1
> miicv_attach: MINC package entry point
> HDF5-DIAG: Error detected in HDF5 (1.8.8) thread 0:
>  #000: H5Dio.c line 153 in H5Dread(): selection+offset not within extent
>    major: Dataspace
>    minor: Out of range
> (from miicv_attach): Can't read dataset /minc-2.0/image/0/image-min
> (from miicv_attach): Can't read variable ID# 1
> miicv_attach: MINC package entry point
> (from miicv_get): ICV is not attached
> (from miicv_get): ICV is not attached
> (from miicv_get): ICV is not attached
> (from miicv_get): ICV is not attached
> (from miicv_get): ICV is not attached
> (from miicv_get): ICV is not attached
> (from miicv_get): ICV is not attached
> (from miicv_get): ICV is not attached
> (from miicv_get): ICV is not attached
> (from miicv_get): ICV is not attached
> (from miicv_get): ICV is not attached
> (from miicv_get): ICV is not attached
> (from miicv_get): ICV is not attached
> (from miicv_get): ICV is not attached
> 
> 
> Any suggestions to what is happening herE?
> 
> Soren
> _______________________________________________
> 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 sorench at gmail.com  Mon Dec 17 12:05:26 2012
From: sorench at gmail.com (Soren Christensen)
Date: Mon, 17 Dec 2012 09:05:26 -0800
Subject: [MINC-users] mincreshape problem
In-Reply-To: <3AACE6F2-D1F1-4600-A337-0A718300702D@gmail.com>
References: <CAHfsrRYsL5QR4vPhvLB52SZwzmBZdjb83pkbbjJsX2GEuG104Q@mail.gmail.com>
	<3AACE6F2-D1F1-4600-A337-0A718300702D@gmail.com>
Message-ID: <CAHfsrRbtov5gk3RRuaEReDjVhMHtP8kP76Hiugwoj3+KD1WbSg@mail.gmail.com>

Thanks - it is a bit of a mystery. Both a.mnc and b.mnc are minc1 files.
b.mnc written by MIPAV, a.mnc by dcm2mnc.  Problem was the guy who created
the files loaded the DICOMs directly into MIPAV and then saved the ROI with
the MIPAV generated header (which apparently deviates from what dcm2mnc
does).
Both minc1 files have min and max defined (per-slice), but mincresample
writes MINC2 and for some reason this file gives the out-of range messages.
In the interest of time I am going to use minctoraw->rawtominc and simply
use a.mnc as -like option. That seems to work well.


Soren




On Sun, Dec 16, 2012 at 1:16 PM, Vladimir S. FONOV <vladimir.fonov at gmail.com
> wrote:

> Hello,
>
>
> it looks like this minc file from MIPAV doesn't have variable image-min
> defined, i.e if you do h5ls -r on a well-defined minc2 file it will show
> you something like that:
>
> /                        Group
> /minc-2.0                Group
> /minc-2.0/dimensions     Group
> /minc-2.0/dimensions/xspace Dataset {SCALAR}
> /minc-2.0/dimensions/yspace Dataset {SCALAR}
> /minc-2.0/dimensions/zspace Dataset {SCALAR}
> /minc-2.0/image          Group
> /minc-2.0/image/0        Group
> /minc-2.0/image/0/image  Dataset {193, 229, 193}
> /minc-2.0/image/0/image-max Dataset {193}
> /minc-2.0/image/0/image-min Dataset {193}
> ? etc ?
>
> so, you file probably have /minc-2.0/image/0/image-min bit missing?
> which is needed to correctly interpret the intensity information in the
> file.
>
>
> On 2012-12-14, at 8:27 PM, Soren Christensen <sorench at gmail.com> wrote:
>
> > Hi,
> > I am trying to fix up some MINC files that were written by MIPAV, for
> some
> > reason some of these files have extra slices and displacement of the ROI.
> > In plane resolution is the same.
> > What I am stuck with is the followoing mincresample behaviour:
> >
> > file: a.mnc
> > image: signed__ short -32768 to 32767
> > image dimensions: zspace yspace xspace
> >    dimension name         length         step        start
> >    --------------         ------         ----        -----
> >    zspace                     26            5     -77.0989
> >    yspace                    256      -0.9375      128.406
> >    xspace                    256      -0.9375      121.591
> >
> >
> > file: b.mnc
> > image: signed__ short -32767 to 32767
> > image dimensions: zspace yspace xspace
> >    dimension name         length         step        start
> >    --------------         ------         ----        -----
> >    zspace                     27            5     -77.0989
> >    yspace                    256      -0.9375      128.406
> >    xspace                    256      -0.9375      121.591
> >
> >
> > So file a has one slice less than b, but spatial info match. So I'd like
> to
> > resample b.mnc like a, in the hope that the top slice is irrelevant ()
> >
> > mincresample -like a.mnc b.mnc b_likea.mnc
> > (from miattputstr): Function 'dimrename' not implemented
> > Transforming slices:..........................Done
> >
> > #> mincinfo a.mnc b_likea.mnc
> > file: a.mnc
> > image: signed__ short -32768 to 32767
> > image dimensions: zspace yspace xspace
> >    dimension name         length         step        start
> >    --------------         ------         ----        -----
> >    zspace                     26            5     -77.0989
> >    yspace                    256      -0.9375      128.406
> >    xspace                    256      -0.9375      121.591
> >
> >
> > file: b_likea.mnc
> > image: signed__ short -32767 to 32767
> > image dimensions: zspace yspace xspace
> >    dimension name         length         step        start
> >    --------------         ------         ----        -----
> >    zspace                     27            5     -77.0989
> >    yspace                    256      -0.9375      128.406
> >    xspace                    256      -0.9375      121.591
> >
> >
> > So b_likea.mnc is not what expect it to be (26 slices). The file seems
> > broken:
> >
> > Display b_likea.mnc
> > Input b_likea.mnc
> > HDF5-DIAG: Error detected in HDF5 (1.8.8) thread 0:
> >  #000: H5Dio.c line 153 in H5Dread(): selection+offset not within extent
> >    major: Dataspace
> >    minor: Out of range
> > (from miicv_attach): Can't read dataset /minc-2.0/image/0/image-min
> > (from miicv_attach): Can't read variable ID# 1
> > miicv_attach: MINC package entry point
> > HDF5-DIAG: Error detected in HDF5 (1.8.8) thread 0:
> >  #000: H5Dio.c line 153 in H5Dread(): selection+offset not within extent
> >    major: Dataspace
> >    minor: Out of range
> > (from miicv_attach): Can't read dataset /minc-2.0/image/0/image-min
> > (from miicv_attach): Can't read variable ID# 1
> > miicv_attach: MINC package entry point
> > (from miicv_get): ICV is not attached
> > (from miicv_get): ICV is not attached
> > (from miicv_get): ICV is not attached
> > (from miicv_get): ICV is not attached
> > (from miicv_get): ICV is not attached
> > (from miicv_get): ICV is not attached
> > (from miicv_get): ICV is not attached
> > (from miicv_get): ICV is not attached
> > (from miicv_get): ICV is not attached
> > (from miicv_get): ICV is not attached
> > (from miicv_get): ICV is not attached
> > (from miicv_get): ICV is not attached
> > (from miicv_get): ICV is not attached
> > (from miicv_get): ICV is not attached
> >
> >
> > Any suggestions to what is happening herE?
> >
> > Soren
> > _______________________________________________
> > 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
>
>
>
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From trash001 at odu.edu  Mon Dec 17 23:03:42 2012
From: trash001 at odu.edu (Tanweer Rashid)
Date: Mon, 17 Dec 2012 23:03:42 -0500
Subject: [MINC-users] Build minc on 64 bit Win 7
Message-ID: <CAE1j2ujQrzrN+G2zAnbnMiHzjYouUeZ1HKxAoW1EwT3ME45rEg@mail.gmail.com>

Hi,

I have been trying to build MINC on 64 bit Windows 7 using MSVS2010. I
haven't been able to find a 64 bit version of bison and flex. Any ideas?

-- 
Tanweer Rashid
MSVE Dept.
Old Dominion University

From a.janke at gmail.com  Mon Dec 17 23:09:59 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 18 Dec 2012 14:09:59 +1000
Subject: [MINC-users] Build minc on 64 bit Win 7
In-Reply-To: <CAE1j2ujQrzrN+G2zAnbnMiHzjYouUeZ1HKxAoW1EwT3ME45rEg@mail.gmail.com>
References: <CAE1j2ujQrzrN+G2zAnbnMiHzjYouUeZ1HKxAoW1EwT3ME45rEg@mail.gmail.com>
Message-ID: <CAG0CB21yoTsBNE=8orxW-h6b4ab4NxqXw1N4Rub-Lnoba_VrWQ@mail.gmail.com>

Hi Tanweer,

Bison and Flex are only needed for minccalc and the distribution
should include a pre-generated gram.c (from gram.y) and a lex.c (from
lex.l).  So you should be quite safe to simply remove all things
related to bison/flex.

There are a few "archaeological" Makefile.msvc-win32's in there from a
previous developer that we haven't had the heart to kill off just yet.

If you are trying to build the library only you may be interested to
know that we recently split libminc from the minc tools and have made
two distributions here:

   https://github.com/BIC-MNI/libminc

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

As of the next release (MINC 2.3) this will be the way things are from
now on in.


a

On 18 December 2012 14:03, Tanweer Rashid <trash001 at odu.edu> wrote:
> Hi,
>
> I have been trying to build MINC on 64 bit Windows 7 using MSVS2010. I
> haven't been able to find a 64 bit version of bison and flex. Any ideas?
>
> --
> Tanweer Rashid
> MSVE Dept.
> Old Dominion University
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From trash001 at odu.edu  Tue Dec 18 11:50:31 2012
From: trash001 at odu.edu (Tanweer Rashid)
Date: Tue, 18 Dec 2012 11:50:31 -0500
Subject: [MINC-users] CMake errors when LIBMINC_BUILD_SHARED_LIBS is on
Message-ID: <CAE1j2uiBw89jq6=vX2ggP2S4D8eAtveATBm=F1OCVR9fdv3LSw@mail.gmail.com>

Hi,

I am trying to build libminc from github on 64 bit Windows 7 with MSVS
2010.
When LIBMINC_BUILD_SHARED_LIBS is checked off, CMake configures and
generates without problems. However, when LIBMINC_BUILD_SHARED_LIBS is
checked on, I get the following errors:


     CMake Error at CMakeLists.txt:316 (INSTALL):

     install Library TARGETS given no DESTINATION!



     CMake Error at CMakeLists.txt:317 (INSTALL):

     install Library TARGETS given no DESTINATION!



     CMake Error at ezminc/CMakeLists.txt:25 (INSTALL):

     install Library TARGETS given no DESTINATION!



     Configuring incomplete, errors occurred!




-- 
Tanweer Rashid
MSVE Dept.
Old Dominion University

From sorench at gmail.com  Thu Dec 20 01:32:37 2012
From: sorench at gmail.com (Soren Christensen)
Date: Thu, 20 Dec 2012 17:32:37 +1100
Subject: [MINC-users] MINC 2.0 coordinate system
Message-ID: <CAHfsrRbqDg=K4p9YgDUoxMXqP9BG4tpRR9kZSz-gk7Fzvs2=sQ@mail.gmail.com>

Hi,
 In the MINC 2.0 coordinate system section of
http://en.wikibooks.org/wiki/MINC/Reference/MINC2.0_File_Format_Reference#MINC_2.0_Structural_Attributes
there is mention of "Startx, Starty and Startz" - just after the line
"and the origin (0,0,0) in voxel coordinates is located at world
coordinates (ox,oy,oz) as given by:"

I got a bit confused here. The Start values for x y and z that we see
using mincinfo are the world coordinates (referred to as "o") in that
section right?   If so, what does these Start values in the wiki
document refer to?
Isn't the order of these matrix multiplications the wrong way around by the way?

Soren

From peter.neelin at gmail.com  Thu Dec 20 08:01:53 2012
From: peter.neelin at gmail.com (Peter Neelin)
Date: Thu, 20 Dec 2012 08:01:53 -0500
Subject: [MINC-users] MINC 2.0 coordinate system
In-Reply-To: <CAHfsrRbqDg=K4p9YgDUoxMXqP9BG4tpRR9kZSz-gk7Fzvs2=sQ@mail.gmail.com>
References: <CAHfsrRbqDg=K4p9YgDUoxMXqP9BG4tpRR9kZSz-gk7Fzvs2=sQ@mail.gmail.com>
Message-ID: <CANcjydbztS6_JB31yfx4cMK7Dy-+S3cf-yj6FYgr6Ggh2YA1LA@mail.gmail.com>

On Dec 20, 2012 1:34 AM, "Soren Christensen" <sorench at gmail.com> wrote:

>  In the MINC 2.0 coordinate system section of
>
http://en.wikibooks.org/wiki/MINC/Reference/MINC2.0_File_Format_Reference#MINC_2.0_Structural_Attributes
> there is mention of "Startx, Starty and Startz" - just after the line
> "and the origin (0,0,0) in voxel coordinates is located at world
> coordinates (ox,oy,oz) as given by:"
>
> I got a bit confused here. The Start values for x y and z that we see
> using mincinfo are the world coordinates (referred to as "o") in that
> section right?

Nope. The start values are as described in that section (assuming that the
matrix order is fixed). Only when the direction cosines are the non-rotated
([1 0 0], [0 1 0], [0 0 1]) do the start values match the origin.

This convention was chosen so that applications that ignore direction
cosines will have the correct origin in the rotated frame (start and step
are expressed along the dimension and are self-consistent). Applications
that want to use the full coordinate information can do the right thing -
it is not hard, and you will almost certainly already have code doing
matrix math, so what is a little more?

> Isn't the order of these matrix multiplications the wrong way around by
the way?

Yup. That should be fixed.

Peter
--
Peter Neelin
peter.neelin at gmail.com

From sorench at gmail.com  Thu Dec 20 12:30:49 2012
From: sorench at gmail.com (Soren Christensen)
Date: Thu, 20 Dec 2012 09:30:49 -0800
Subject: [MINC-users] MINC 2.0 coordinate system
In-Reply-To: <CANcjydbztS6_JB31yfx4cMK7Dy-+S3cf-yj6FYgr6Ggh2YA1LA@mail.gmail.com>
References: <CAHfsrRbqDg=K4p9YgDUoxMXqP9BG4tpRR9kZSz-gk7Fzvs2=sQ@mail.gmail.com>
	<CANcjydbztS6_JB31yfx4cMK7Dy-+S3cf-yj6FYgr6Ggh2YA1LA@mail.gmail.com>
Message-ID: <CAHfsrRaeuBTbHDOGiMBA8-ChbjobSgjEmETzW4EDJWor9pZRAA@mail.gmail.com>

Thanks - that clears it up for me.

Soren


On Thu, Dec 20, 2012 at 5:01 AM, Peter Neelin <peter.neelin at gmail.com>wrote:

> On Dec 20, 2012 1:34 AM, "Soren Christensen" <sorench at gmail.com> wrote:
>
> >  In the MINC 2.0 coordinate system section of
> >
>
> http://en.wikibooks.org/wiki/MINC/Reference/MINC2.0_File_Format_Reference#MINC_2.0_Structural_Attributes
> > there is mention of "Startx, Starty and Startz" - just after the line
> > "and the origin (0,0,0) in voxel coordinates is located at world
> > coordinates (ox,oy,oz) as given by:"
> >
> > I got a bit confused here. The Start values for x y and z that we see
> > using mincinfo are the world coordinates (referred to as "o") in that
> > section right?
>
> Nope. The start values are as described in that section (assuming that the
> matrix order is fixed). Only when the direction cosines are the non-rotated
> ([1 0 0], [0 1 0], [0 0 1]) do the start values match the origin.
>
> This convention was chosen so that applications that ignore direction
> cosines will have the correct origin in the rotated frame (start and step
> are expressed along the dimension and are self-consistent). Applications
> that want to use the full coordinate information can do the right thing -
> it is not hard, and you will almost certainly already have code doing
> matrix math, so what is a little more?
>
> > Isn't the order of these matrix multiplications the wrong way around by
> the way?
>
> Yup. That should be fixed.
>
> Peter
> --
> Peter Neelin
> peter.neelin at gmail.com
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From peter.neelin at gmail.com  Thu Dec 20 13:09:57 2012
From: peter.neelin at gmail.com (Peter Neelin)
Date: Thu, 20 Dec 2012 13:09:57 -0500
Subject: [MINC-users] MINC 2.0 coordinate system
In-Reply-To: <CANcjydbztS6_JB31yfx4cMK7Dy-+S3cf-yj6FYgr6Ggh2YA1LA@mail.gmail.com>
References: <CAHfsrRbqDg=K4p9YgDUoxMXqP9BG4tpRR9kZSz-gk7Fzvs2=sQ@mail.gmail.com>
	<CANcjydbztS6_JB31yfx4cMK7Dy-+S3cf-yj6FYgr6Ggh2YA1LA@mail.gmail.com>
Message-ID: <CANcjydYE5CiPr3h55KJ_p4LeOOYdU_77dJ5YFw2F+iDbtyO2CA@mail.gmail.com>

On Thu, Dec 20, 2012 at 8:01 AM, Peter Neelin <peter.neelin at gmail.com> wrote:
> On Dec 20, 2012 1:34 AM, "Soren Christensen" <sorench at gmail.com> wrote:
>> Isn't the order of these matrix multiplications the wrong way around by
>> the way?
>
> Yup. That should be fixed.

Just had a quick look again, and I suspect (without thinking too hard
about it) that the direction cosine matrix is transposed as well
(assuming column vectors). Looks like someone might have been thinking
in row vectors and then wrote them as column vectors. The start is the
distance along the dimension axis (and step is the sample separation
along the dimension axis). So to get origin you have to multiple each
start by the appropriate direction cosine and then sum up for all
sampling axes (which happen to be labelled x, y and z, even though
they do not align exactly with the world space x, y and z - a bit
confusing, I will admit).

Peter
-- 
Peter Neelin
(peter.neelin at gmail.com)