From sean at rogue-research.com  Thu Sep  1 10:54:49 2005
From: sean at rogue-research.com (Sean McBride)
Date: Thu, 1 Sep 2005 10:54:49 -0400
Subject: [MINC-users] minc-1.4 on Mac OS X 10.4.1
In-Reply-To: <Pine.SGI.4.44.0508301424020.785313-100000@shadow.bic.mni.mcgill.ca>
References: <20050830161043.29443@smtp1.sympatico.ca>
	<Pine.SGI.4.44.0508301424020.785313-100000@shadow.bic.mni.mcgill.ca>
Message-ID: <20050901145449.24946@smtp1.sympatico.ca>

On 2005-08-30 14:28, Robert VINCENT said:

>In addition to Steve Robbins' change (using sysconf(_SC_CLK_TCK) if
>available), I have also added the following lines to the beginning of
>volume_io/Prog_utils/time.c:
>
>#ifndef CLK_TCK
>#define CLK_TCK CLOCKS_PER_SEC
>#endif
>
>This should catch systems that do not define the older CLK_TCK symbol, but
>do define the newer CLOCKS_PER_SEC constant.

Thanks Bert,

Any chance of there being a 1.4.1 to spare others from hitting this
compilation problem?

Take care,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr?al, Qu?bec, Canada




From a.janke at gmail.com  Fri Sep  2 13:27:44 2005
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 2 Sep 2005 13:27:44 -0400
Subject: [MINC-users] resource for source_mask option in minctracc?
In-Reply-To: <20050831162734.GA882728@shadow.bic.mni.mcgill.ca>
References: <20050831162734.GA882728@shadow.bic.mni.mcgill.ca>
Message-ID: <d747ed505090210271e96049f@mail.gmail.com>

Jonathan, 

This option allows you to specify a minc file as a mask to use during
the fitting. ie:

   minctracc ....  -source_mask mask.mnc .....  

It has the effect that the similarity function is only evaluated
within the mask as applied to the input source volume.

This means: 

   * Fitting is often faster  (less voxels to compute obj function over)
   * Fitting is more precise for the area within the mask as features
       from structures outside the mask are ignored.

a

On 31/08/05, Jonathan LAU <lau at bic.mni.mcgill.ca> wrote:
> Hi,
> 
> I am interested in learning how the -source_mask flag works in minctracc.  It definitely improves the registration I am getting between a source (with a mask) and my target data, but I'm just curious to know about the underlying algorithm.  A source for this would be great.
> 
> Thanks,
> Jonathan
> 
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> 


-- 
Andrew Janke      (a.janke at gmail.com || www.cmr.uq.edu.au/~rotor)
Canada->Montreal                                   Cell: +1 (514) 924 2012


From nikelski at bic.mni.mcgill.ca  Mon Sep  5 18:19:05 2005
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Mon, 05 Sep 2005 18:19:05 -0400
Subject: [MINC-users] xdisp does not build on Debian Etch
Message-ID: <431CC459.2030804@bic.mni.mcgill.ca>

Hi all,

    FYI, just tried to build xdisp-4.5 (retrieved from packages.bic...)
 and apparently xdisp wants/needs the EZWGL widget library --- as
evidenced by the make complaining about not finding EZ.h. Perhaps this
dependency should be noted in the README/INSTALL files and/or have the
.configure process look for it.

    At any rate, I found and built EZWGL-1.50 as a static lib. Retried
to make xdisp, and was presented with a brand new error, as follows:

 jnikelski at Brunnhilde:~/software/xdisp-4.5$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for ranlib... ranlib
checking for a BSD-compatible install... /usr/bin/install -c
checking how to run the C preprocessor... gcc -E
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... no
checking for library m... yes
checking for library netcdf... yes
checking for library minc... yes
checking for library volume_io... yes
configure: creating ./config.status
config.status: creating epm-header
config.status: creating Makefile
config.status: creating olgx/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
jnikelski at Brunnhilde:~/software/xdisp-4.5$ make
make  all-recursive
make[1]: Entering directory `/home/jnikelski/software/xdisp-4.5'
Making all in olgx
make[2]: Entering directory `/home/jnikelski/software/xdisp-4.5/olgx'
if gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -MT ol_button.o -MD -MP
-MF ".deps/ol_button.Tpo" -c -o ol_button.o ol_button.c; \
then mv -f ".deps/ol_button.Tpo" ".deps/ol_button.Po"; else rm -f
".deps/ol_button.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -MT ol_color.o -MD -MP
-MF ".deps/ol_color.Tpo" -c -o ol_color.o ol_color.c; \
then mv -f ".deps/ol_color.Tpo" ".deps/ol_color.Po"; else rm -f
".deps/ol_color.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -MT ol_draw.o -MD -MP -MF
".deps/ol_draw.Tpo" -c -o ol_draw.o ol_draw.c; \
then mv -f ".deps/ol_draw.Tpo" ".deps/ol_draw.Po"; else rm -f
".deps/ol_draw.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -MT ol_init.o -MD -MP -MF
".deps/ol_init.Tpo" -c -o ol_init.o ol_init.c; \

...

if gcc -DHAVE_CONFIG_H -I. -I. -I.    -Iolgx -IEZWGL-1.50/include
-I/usr/X11R6/include -g -O2 -MT xdisp-xbutton.o -MD -MP -MF
".deps/xdisp-xbutton.Tpo" -c -o xdisp-xbutton.o `test -f 'xbutton.c' ||
echo './'`xbutton.c; \
then mv -f ".deps/xdisp-xbutton.Tpo" ".deps/xdisp-xbutton.Po"; else rm
-f ".deps/xdisp-xbutton.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I.    -Iolgx -IEZWGL-1.50/include
-I/usr/X11R6/include -g -O2 -MT xdisp-xwinutil.o -MD -MP -MF
".deps/xdisp-xwinutil.Tpo" -c -o xdisp-xwinutil.o `test -f 'xwinutil.c'
|| echo './'`xwinutil.c; \
then mv -f ".deps/xdisp-xwinutil.Tpo" ".deps/xdisp-xwinutil.Po"; else rm
-f ".deps/xdisp-xwinutil.Tpo"; exit 1; fi
make[2]: *** No rule to make target `EZWGL-1.50/lib/libEZ.a', needed by
`xdisp'.  Stop.
make[2]: Leaving directory `/home/jnikelski/software/xdisp-4.5'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jnikelski/software/xdisp-4.5'
make: *** [all] Error 2


Any ideas?

Cheers,

-Jim












From nikelski at bic.mni.mcgill.ca  Wed Sep  7 11:36:17 2005
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Wed, 07 Sep 2005 11:36:17 -0400
Subject: [MINC-users] xdisp does not build on Debian Etch
In-Reply-To: <431CC459.2030804@bic.mni.mcgill.ca>
References: <431CC459.2030804@bic.mni.mcgill.ca>
Message-ID: <431F08F1.8050801@bic.mni.mcgill.ca>

Hi again,

    After a brief introduction to the autotools, I find myself replying
to my own posting. xdisp does not build because EZWGL **USED** to be
included and built with xdisp, but has since been partially removed --
although there is no mention of this in the ChangeLog. So, while
configure.ac has commented out the reference to EZWGL, it persists in
Makefile.am, resulting in the previously mentioned build error. A very
quick work-around: build EZWGL separately, and then copy the entire
EZWGL-1.50 subdirectory into the xdisp build directory ... then do xdisp
configure, make, etc. Works for me.

-Jim



EJ Nikelski wrote:
> Hi all,
> 
>     FYI, just tried to build xdisp-4.5 (retrieved from packages.bic...)
>  and apparently xdisp wants/needs the EZWGL widget library --- as
> evidenced by the make complaining about not finding EZ.h. Perhaps this
> dependency should be noted in the README/INSTALL files and/or have the
> .configure process look for it.
> 
>     At any rate, I found and built EZWGL-1.50 as a static lib. Retried
> to make xdisp, and was presented with a brand new error, as follows:
> 
>  jnikelski at Brunnhilde:~/software/xdisp-4.5$ ./configure
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for gawk... no
> checking for mawk... mawk
> checking whether make sets $(MAKE)... yes
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ANSI C... none needed
> checking for style of include used by make... GNU
> checking dependency style of gcc... gcc3
> checking for ranlib... ranlib
> checking for a BSD-compatible install... /usr/bin/install -c
> checking how to run the C preprocessor... gcc -E
> checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
> checking for gethostbyname... yes
> checking for connect... yes
> checking for remove... yes
> checking for shmat... yes
> checking for IceConnectionNumber in -lICE... no
> checking for library m... yes
> checking for library netcdf... yes
> checking for library minc... yes
> checking for library volume_io... yes
> configure: creating ./config.status
> config.status: creating epm-header
> config.status: creating Makefile
> config.status: creating olgx/Makefile
> config.status: creating config.h
> config.status: config.h is unchanged
> config.status: executing depfiles commands
> jnikelski at Brunnhilde:~/software/xdisp-4.5$ make
> make  all-recursive
> make[1]: Entering directory `/home/jnikelski/software/xdisp-4.5'
> Making all in olgx
> make[2]: Entering directory `/home/jnikelski/software/xdisp-4.5/olgx'
> if gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -MT ol_button.o -MD -MP
> -MF ".deps/ol_button.Tpo" -c -o ol_button.o ol_button.c; \
> then mv -f ".deps/ol_button.Tpo" ".deps/ol_button.Po"; else rm -f
> ".deps/ol_button.Tpo"; exit 1; fi
> if gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -MT ol_color.o -MD -MP
> -MF ".deps/ol_color.Tpo" -c -o ol_color.o ol_color.c; \
> then mv -f ".deps/ol_color.Tpo" ".deps/ol_color.Po"; else rm -f
> ".deps/ol_color.Tpo"; exit 1; fi
> if gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -MT ol_draw.o -MD -MP -MF
> ".deps/ol_draw.Tpo" -c -o ol_draw.o ol_draw.c; \
> then mv -f ".deps/ol_draw.Tpo" ".deps/ol_draw.Po"; else rm -f
> ".deps/ol_draw.Tpo"; exit 1; fi
> if gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -MT ol_init.o -MD -MP -MF
> ".deps/ol_init.Tpo" -c -o ol_init.o ol_init.c; \
> 
> ...
> 
> if gcc -DHAVE_CONFIG_H -I. -I. -I.    -Iolgx -IEZWGL-1.50/include
> -I/usr/X11R6/include -g -O2 -MT xdisp-xbutton.o -MD -MP -MF
> ".deps/xdisp-xbutton.Tpo" -c -o xdisp-xbutton.o `test -f 'xbutton.c' ||
> echo './'`xbutton.c; \
> then mv -f ".deps/xdisp-xbutton.Tpo" ".deps/xdisp-xbutton.Po"; else rm
> -f ".deps/xdisp-xbutton.Tpo"; exit 1; fi
> if gcc -DHAVE_CONFIG_H -I. -I. -I.    -Iolgx -IEZWGL-1.50/include
> -I/usr/X11R6/include -g -O2 -MT xdisp-xwinutil.o -MD -MP -MF
> ".deps/xdisp-xwinutil.Tpo" -c -o xdisp-xwinutil.o `test -f 'xwinutil.c'
> || echo './'`xwinutil.c; \
> then mv -f ".deps/xdisp-xwinutil.Tpo" ".deps/xdisp-xwinutil.Po"; else rm
> -f ".deps/xdisp-xwinutil.Tpo"; exit 1; fi
> make[2]: *** No rule to make target `EZWGL-1.50/lib/libEZ.a', needed by
> `xdisp'.  Stop.
> make[2]: Leaving directory `/home/jnikelski/software/xdisp-4.5'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/jnikelski/software/xdisp-4.5'
> make: *** [all] Error 2
> 
> 
> Any ideas?
> 
> Cheers,
> 
> -Jim
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> 


From a.janke at gmail.com  Fri Sep  9 01:43:38 2005
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 9 Sep 2005 01:43:38 -0400
Subject: [MINC-users] xdisp does not build on Debian Etch
In-Reply-To: <431F08F1.8050801@bic.mni.mcgill.ca>
References: <431CC459.2030804@bic.mni.mcgill.ca>
	<431F08F1.8050801@bic.mni.mcgill.ca>
Message-ID: <d747ed505090822431e35a662@mail.gmail.com>

Thanks for the bug-report Ej, 

You are right, 4.5 was supposed to mark the release of the first
version that didint include EZWGL.  Appears that this little "detail"
slipped by..

Just so that I get the wires connected right: Did the .tar.gz you
downloaded include EZWGL or not?  From a look at the current version
in CVS (4.5.1) it is still included.  Looks like I was almost done
removing EZWGL and gave up at the last moment and released as it was.

-- 
Andrew Janke      (a.janke at gmail.com || www.cmr.uq.edu.au/~rotor)
Canada->Montreal                                   Cell: +1 (514) 924 2012


From nikelski at bic.mni.mcgill.ca  Fri Sep  9 08:53:04 2005
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Fri, 09 Sep 2005 08:53:04 -0400
Subject: [MINC-users] xdisp does not build on Debian Etch
In-Reply-To: <d747ed505090822431e35a662@mail.gmail.com>
References: <431CC459.2030804@bic.mni.mcgill.ca>
	<431F08F1.8050801@bic.mni.mcgill.ca>
	<d747ed505090822431e35a662@mail.gmail.com>
Message-ID: <432185B0.2020200@bic.mni.mcgill.ca>

Hi,

   Andrew, the .tar.gz that I downloaded from the BIC site did *not*
include EZWGL (only the m4 and olgx subdirectories were included in the
tarball) ... I downloaded EZWGL separately from the main EZWGL site. The
 tainted xdisp package is still available at:

http://packages.bic.mni.mcgill.ca/tgz/xdisp-4.5.tar.gz


 Strange that it still shows up in CVS. Thanks for the response.

Cheers,

-Jim



Andrew Janke wrote:
> Thanks for the bug-report Ej, 
> 
> You are right, 4.5 was supposed to mark the release of the first
> version that didint include EZWGL.  Appears that this little "detail"
> slipped by..
> 
> Just so that I get the wires connected right: Did the .tar.gz you
> downloaded include EZWGL or not?  From a look at the current version
> in CVS (4.5.1) it is still included.  Looks like I was almost done
> removing EZWGL and gave up at the last moment and released as it was.
> 


From nikelski at bic.mni.mcgill.ca  Tue Sep 13 09:50:31 2005
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Tue, 13 Sep 2005 09:50:31 -0400
Subject: [MINC-users] mni_autoreg_model-1.1 build error (and fix)
Message-ID: <4326D927.8000406@bic.mni.mcgill.ca>

Hi all,

    An attempted build of autreg-1.1 (posted on packages.bic.mni.....)
resulted in an error while calling autocrop. Problem is with the
autocrop script in mni_autoreg-0.98u which fails to include the *labs*
function from MNI::NumericUtilities. A fix to this problem would require
the following modification to autocrop ...

34c34
< use MNI::NumericUtilities qw( round );
---
> use MNI::NumericUtilities qw( round labs);


Works for me.


-Jim


From k.h.kho at azu.nl  Wed Sep 14 06:51:29 2005
From: k.h.kho at azu.nl (Kuan H. Kho)
Date: Wed, 14 Sep 2005 12:51:29 +0200
Subject: [MINC-users]  regions of interest
Message-ID: <a06210201bf4db0b77678@[143.121.42.76]>

Hi Andrew,

When will this ICBM atlas be publicly available? I assume it is a
(validated?) segmented brain that which can be used to automatically
segment other brains with ANIMAL?

Best,

Kuan
---
Kuan H. Kho
Depts. of Psychiatry & Neurosurgery, G03.124
University Medical Center Utrecht
Heidelberglaan 100
P.O.Box 85500
3508 GA Utrecht
The Netherlands

P +31-30-2507969/2507953
F +31-30-2542100
E k.h.kho_'at'_azu.nl

>Stephen,
>
>Give that you are at the BIC you can have a look here on any of the
>BIC systems for the jacobs atlas.
>
>    /usr/local/mni/data/ANIMAL
>
>There are a number of traced sub-structure/lobes here.  For those
>external to the BIC I am pleased to say that there soon will be a
>publically available version of the ICBM/jacobs sub-structure atlases.
>
>
>--
>Andrew Janke      (a.janke at gmail.com || www.cmr.uq.edu.au/~rotor)
>Canada->Montreal                                   Cell: +1 (514) 924 2012

From a.janke at gmail.com  Wed Sep 14 22:53:48 2005
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 14 Sep 2005 22:53:48 -0400
Subject: [MINC-users] mni_autoreg_model-1.1 build error (and fix)
In-Reply-To: <4326D927.8000406@bic.mni.mcgill.ca>
References: <4326D927.8000406@bic.mni.mcgill.ca>
Message-ID: <d747ed505091419537c76e13d@mail.gmail.com>

Thanks for the bug fix Jim, 

I had recently re-written all the MNI perllib in mni_autoreg and
obviously missed this bit. I have checked this change into CVS.

thanks again

a
 

On 13/09/05, EJ Nikelski <nikelski at bic.mni.mcgill.ca> wrote:
> Hi all,
> 
>     An attempted build of autreg-1.1 (posted on packages.bic.mni.....)
> resulted in an error while calling autocrop. Problem is with the
> autocrop script in mni_autoreg-0.98u which fails to include the *labs*
> function from MNI::NumericUtilities. A fix to this problem would require
> the following modification to autocrop ...
> 
> 34c34
> < use MNI::NumericUtilities qw( round );
> ---
> > use MNI::NumericUtilities qw( round labs);
> 
> 
> Works for me.
> 
> 
> -Jim
> 
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> 


-- 
Andrew Janke      (a.janke at gmail.com || www.cmr.uq.edu.au/~rotor)
Canada->Montreal                                   Cell: +1 (514) 924 2012


From nikelski at bic.mni.mcgill.ca  Fri Sep 16 13:10:19 2005
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Fri, 16 Sep 2005 13:10:19 -0400
Subject: [MINC-users] Volume orientation problem
Message-ID: <432AFC7B.2090809@bic.mni.mcgill.ca>

Dear List,

   I should probably be able to figure this out myself, but I'm stumped.
In short, I have a DICOM format T1 volume which I convert to minc using
dcm2mnc, and then transform into Talairach space. Conversion to minc
looks terrific when viewed in Display, but the Talairach space volume
looks *very* wrong.

Here are the details:

(1) DICOM volume produced from a GE Signa Excite 3T scanner. Conversion
to minc produces a volume that looks like this ...

>>>>>>
 jnikelski at Brunnhilde:~/tmp/xxx$ mincinfo anat_stephane.mnc
file: anat_stephane.mnc
image: signed__ short -32768 to 32767
image dimensions: yspace zspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    yspace                    248    -0.800001     -72.2295
    zspace                    512    -0.371094      110.619
    xspace                    512    -0.371094      90.7169
<<<<<<<

(2) Run mritotal/mincresample. mritotal provides an initial/final
objective function of 0.1900/0.1897 (not good?) The xfm is ...

>>>>>>>
jnikelski at Brunnhilde:~/tmp/xxx$ cat anat_stephane.xfm
MNI Transform File
%Fri Sep 16 12:34:42 2005>>> /usr/local/bin/minctracc
/var/tmp/mritotal_1964//anat_stephane_8_dxyz.mnc
/usr/local/bin/../share/mni_autoreg/average_305_8_dxyz.mnc
anat_stephane.xfm -transformation
/var/tmp/mritotal_1964//anat_stephane_8tmp2c.xfm -lsq9 -xcorr
-model_mask /usr/local/bin/../share/mni_autoreg/average_305_8_mask.mnc
-center -2.655523 -169.076736 9.518312 -step 4 4 4 -tol 0.004 -simplex 2
%(Package mni_autoreg 0.98u, compiled by jnikelski at Brunnhilde
(i686-pc-linux-gnu) on Mon Sep 12 16:07:47 EDT 2005)

Transform_Type = Linear;
Linear_Transform =
 1.10752904415131 -0.0873657912015915 0.0189949013292789 -12.5382280349731
 0.0655834898352623 0.592145144939423 -1.10042119026184 95.9860992431641
 0.0736042037606239 1.05778276920319 0.573587834835052 155.421844482422;
<<<<<<<<

(3) When I pull up the Talairach volume in Display I get ...

    (a) The sagittal image, which was pointing to the left, has been
rotated 90 degrees counter-clockwise and is pointing down ... and is
clipped.
    (b) The coronal view now looks kind of axial ... and is clipped.
    (c) The axial view now looks coronal, and is upside-down.


Help? I'm sure that this must be due to the initial orientation info fed
to dcm2mnc being incorrect ... but I have no idea how to feed this
process orientation information.

Cheers,

-Jim












From nikelski at bic.mni.mcgill.ca  Sun Sep 18 17:37:38 2005
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Sun, 18 Sep 2005 17:37:38 -0400
Subject: [MINC-users] Volume orientation problem
In-Reply-To: <OF8F21B28E.E02EEDD4-ON8525707E.006CCE48-8525707E.006D0477@mcgill.ca>
References: <OF8F21B28E.E02EEDD4-ON8525707E.006CCE48-8525707E.006D0477@mcgill.ca>
Message-ID: <432DDE22.2050105@bic.mni.mcgill.ca>

Dear List,

    Thanks for the suggestion Jeff, I ran my DICOM files through
dicom3_to_minc, and it all looks much better. Even the transform to
Talairach was blissfully uneventful. However, I considered this process
more of a debugging step, since a working dcm2mnc would deliver serious
performance gains.

     Bert: The comparison of the dcm2mnc and dicom3_to_minc volumes
yielded differences in the sign of one dimension's Step, in addition to
some sign differences in direction cosines (BTW, is (0)=(-0) in
direction cosine land?). I have created a tarball of my DICOM files and
transferred them to BIC, if you would like to test against them. Let me
know if you're interested.

Cheers,

-Jim



Jeffrey Atkinson wrote:
> I have similar orientation problems with dcm2mnc and our GE 1.5 T scanner
> -- but our problem occurs immediately after the dcm2mnc step without any
> transformation.  John Harlap's dicom3_to_minc perl script works just fine.
> 
> Jeff
> 
> 


From J.Janssen at azu.nl  Tue Sep 13 12:18:37 2005
From: J.Janssen at azu.nl (Joost Janssen)
Date: Tue, 13 Sep 2005 18:18:37 +0200 (METDST)
Subject: [MINC-users] Display option
Message-ID: <Pine.HPX.4.10.10509131807150.1523-100000@rembrant.azu.nl>

Dear Minc users,

i have a question regarding the use of the Display program. suppose i have
a label containing more than 1 value. after loading the file and label
into the DISPLAY program i scroll through the slices. i want to erase one
value but leave intact the other values, is there a function which permits
my 'brush' to only erase voxels with a certain value leaving intact those
with other values, so that i don't need to be accurate in erasing? i know
i can use the 'change labels' option but might there be a more efficient
way?

thanks,
-joost janssen


From kate at bic.mni.mcgill.ca  Tue Sep 20 13:15:53 2005
From: kate at bic.mni.mcgill.ca (Kate HANRATTY)
Date: Tue, 20 Sep 2005 13:15:53 -0400
Subject: [MINC-users] Erasing a label in Display
In-Reply-To: <mailman.5.1127232010.1514720.minc-users@bic.mni.mcgill.ca>;
	from minc-users-request@bic.mni.mcgill.ca on Tue, Sep 20, 2005 at
	12:00:10PM -0400
References: <mailman.5.1127232010.1514720.minc-users@bic.mni.mcgill.ca>
Message-ID: <20050920131553.A1530729@shadow.bic.mni.mcgill.ca>

Hi Joost,

The fastest way to erase all voxels of a certain label value in a
volume is to go the Segmenting menu - [F] from the main menu - and
select Change Labels [U]. Then follow the prompts in the command
window.  

Here's what my command window looked like when I erased all of label 9 
from my volume:

Label or range to change from: 9
Label to change to: 0
Min and max of value range: 9 9

At the "Min and max of value range:" prompt you can either type in the
value of the label to be erased - and you'll have to type it twice -
or type in the image intensity range (e.g. 0 - 256 if that is the
range of intensities in the image you are segmenting/painting).

HTH
Kate.

-- 
Kate Hanratty
kate at bic.mni.mcgill.ca

From mansi at bic.mni.mcgill.ca  Tue Sep 20 14:54:35 2005
From: mansi at bic.mni.mcgill.ca (Thomas Mansi)
Date: Tue, 20 Sep 2005 20:54:35 +0200
Subject: [MINC-users] N3 and Cygwin
Message-ID: <43305AEB.5010406@bic.mni.mcgill.ca>

Hi everyone,

I am trying to install N3 on a cygwin system. I managed to install all 
the required things but when executing nu_estimate for example, it gives 
me this strange message:

******************

$ nu_estimate mcd_001_t1.mnc.gz mcd_001_t1_test.imp
MNI::MincUtilities: warning: $main::Execute not defined (assuming true) 
-- did you use MNI::Startup?
Use of uninitialized value in pattern match (m//) at 
/usr/local/mni/bin/nu_estimate line 411.
Use of uninitialized value in concatenation (.) or string at 
/usr/local/mni/bin/nu_estimate line 264.
Use of uninitialized value in concatenation (.) or string at 
/usr/local/mni/bin/nu_estimate line 264.
Use of uninitialized value in concatenation (.) or string at 
/usr/local/mni/bin/nu_estimate line 270.
Use of uninitialized value in join or string at 
/usr/lib/perl5/site_perl/5.8/MNI/Spawn.pm line 830.
MNI::MincUtilities: warning: $main::Execute not defined (assuming true) 
-- did you use MNI::Startup?
Useless use of a constant in void context at 
/usr/local/mni/bin/nu_estimate_np_and_em line 49.
Name "main::KeepTmp" used only once: possible typo at 
/usr/local/mni/bin/nu_estimate_np_and_em line 1163.
Use of uninitialized value in concatenation (.) or string at 
/usr/local/mni/bin/nu_estimate_np_and_em line 1417.
Use of uninitialized value in concatenation (.) or string at 
/usr/local/mni/bin/nu_estimate_np_and_em line 1417.
Use of uninitialized value in concatenation (.) or string at 
/usr/local/mni/bin/nu_estimate_np_and_em line 1423.
Leftover args: mcd_001_t1_test.imp
, version 1.10

Usage:  [-help] [options] input_volume.mnc nu_field.imp
Incorrect number of arguments
nu_estimate: crashed while running nu_estimate_np_and_em (termination 
status=512)

*****************

Does anyone know what I can do at this stage? The installation of minc, 
EBTKS, getop::tabular and N3 were performed without any problem. As for 
perllib, when I executed perl Makefile.PL, I had this strange message:

Makefile.PL: I don't grok the manifypods section, so can't tweak the 
pod2man args at Makefile.PL line 162.

What did it mean? However, I went on installing, without additional 
problems.

Many thanks in advance for your help!
Thomas Mansi

PS: I'm using perl version 5.8.7 and gcc version 3.4.4.

	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
T?l?chargez cette version sur http://fr.messenger.yahoo.com

From pvcorrection at yahoo.com  Tue Sep 20 15:10:25 2005
From: pvcorrection at yahoo.com (Olivier Rousset)
Date: Tue, 20 Sep 2005 12:10:25 -0700 (PDT)
Subject: [MINC-users] Erasing a label in Display
In-Reply-To: <20050920131553.A1530729@shadow.bic.mni.mcgill.ca>
Message-ID: <20050920191025.76805.qmail@web31701.mail.mud.yahoo.com>

Kate,

I am not sure this is what Joost wants... What you
propose is not to erase voxels but rather change their
label (e.g., from 9 to 0). The only way I know to
definitely erase labeled voxels is to -while in the
F-segmenting menu- hold the Ctrl key while dragging
the cursor with the right button of the mouse (I don't
know about Mac users here ;-) Alternatively typing a
"w" while the cursor is over a given voxel will also
result in the labeled voxel to be erased -that's more
for working in tight quarters.

Hope this helps,

-- Olivier

--- Kate HANRATTY <kate at bic.mni.mcgill.ca> wrote:

> Hi Joost,
> 
> The fastest way to erase all voxels of a certain
> label value in a
> volume is to go the Segmenting menu - [F] from the
> main menu - and
> select Change Labels [U]. Then follow the prompts in
> the command
> window.  
> 
> Here's what my command window looked like when I
> erased all of label 9 
> from my volume:
> 
> Label or range to change from: 9
> Label to change to: 0
> Min and max of value range: 9 9
> 
> At the "Min and max of value range:" prompt you can
> either type in the
> value of the label to be erased - and you'll have to
> type it twice -
> or type in the image intensity range (e.g. 0 - 256
> if that is the
> range of intensities in the image you are
> segmenting/painting).
> 
> HTH
> Kate.
> 
> -- 
> Kate Hanratty
> kate at bic.mni.mcgill.ca
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
>
http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> 


From marc.schoenwiesner at mcgill.ca  Thu Sep 22 12:33:37 2005
From: marc.schoenwiesner at mcgill.ca (Marc Schoenwiesner)
Date: Thu, 22 Sep 2005 12:33:37 -0400
Subject: [MINC-users] converting dicom data (functional runs) to 4D minc
	files
Message-ID: <1127406817.4332dce12505e@webmail.mcgill.ca>

Hi,

I have dicom data (14 subjects, T1 and multiple EPI runs) that I'd like to
convert to minc. Dicom_to_minc works fine for the single volume structural
scans, but I am looking for a painless way to convert each functional run into
a 4D minc file (i.e. 1349 files containing single slices -> 71 volumes of 19
slices in one minc file).
I'd be thankful for any pointers!

Marc




From bert at bic.mni.mcgill.ca  Thu Sep 22 12:39:59 2005
From: bert at bic.mni.mcgill.ca (Robert VINCENT)
Date: Thu, 22 Sep 2005 12:39:59 -0400
Subject: [MINC-users] converting dicom data (functional runs) to 4D minc
 files
In-Reply-To: <1127406817.4332dce12505e@webmail.mcgill.ca>
Message-ID: <Pine.SGI.4.44.0509221239060.1715430-100000@shadow.bic.mni.mcgill.ca>

Hi Marc,

You should be able to convert the functional runs using dcm2mnc, which is
part of the MINC 1.4 distribution available at
http://packages.bic.mni.mcgill.ca

	-bert

On Thu, 22 Sep 2005, Marc Schoenwiesner wrote:

> Hi,
>
> I have dicom data (14 subjects, T1 and multiple EPI runs) that I'd like to
> convert to minc. Dicom_to_minc works fine for the single volume structural
> scans, but I am looking for a painless way to convert each functional run into
> a 4D minc file (i.e. 1349 files containing single slices -> 71 volumes of 19
> slices in one minc file).
> I'd be thankful for any pointers!
>
> Marc
>
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


From marc.schoenwiesner at mcgill.ca  Mon Sep 26 14:40:09 2005
From: marc.schoenwiesner at mcgill.ca (Marc Schoenwiesner)
Date: Mon, 26 Sep 2005 14:40:09 -0400
Subject: [MINC-users] motion correction and lid closure
Message-ID: <1127760009.43384089c567c@webmail.mcgill.ca>

Hi,

this is a question about intra-subject intra-modality image registration to
correct motion within a run of functional images. In their 2002 neuroimage
paper Stephan et al. showed that closing and opening the eyes may lead to small
misalignments in the registration, because the intensity of the eye voxels
changes. Some people recommend to mask out the eyes in functional runs before
motion correction. How could this be done with tools at the BIC? Zeroing the
eye voxels in all images may not be the optimal solution, because this creates
an artificial structural feature which might mislead the registration even
more... Roger Woods AIR package for instance has a -mask option which allows to
disregard the eye signal without creating structural features. How could that be
done in the frm_preprocess step?

Thanks for any pointers!
Cheers
Marc

From a.janke at gmail.com  Tue Sep 27 23:05:06 2005
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 27 Sep 2005 23:05:06 -0400
Subject: [MINC-users] motion correction and lid closure
In-Reply-To: <1127760009.43384089c567c@webmail.mcgill.ca>
References: <1127760009.43384089c567c@webmail.mcgill.ca>
Message-ID: <d747ed505092720056f4a54f8@mail.gmail.com>

Hi Marc,

I suspect in order to do this you will have to edit fmr_preprocess
itself to add the masking to the minctracc calls.

I do know of some eye masks that are already in talairach space, but
you are likely best to make your own in mni (approximate talairach)
space that suits your data.  Make the eye mask in Display, then invert
it (mincmath -invert).

Then add your new mask to the minctracc registration calls using -source_mask.


Andrew



On 26/09/05, Marc Schoenwiesner <marc.schoenwiesner at mcgill.ca> wrote:
> Hi,
>
> this is a question about intra-subject intra-modality image registration to
> correct motion within a run of functional images. In their 2002 neuroimage
> paper Stephan et al. showed that closing and opening the eyes may lead to small
> misalignments in the registration, because the intensity of the eye voxels
> changes. Some people recommend to mask out the eyes in functional runs before
> motion correction. How could this be done with tools at the BIC? Zeroing the
> eye voxels in all images may not be the optimal solution, because this creates
> an artificial structural feature which might mislead the registration even
> more... Roger Woods AIR package for instance has a -mask option which allows to
> disregard the eye signal without creating structural features. How could that be
> done in the frm_preprocess step?
>
> Thanks for any pointers!
> Cheers
> Marc
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


--
Andrew Janke      (a.janke at gmail.com || www.cmr.uq.edu.au/~rotor)
Canada->Montreal                                   Cell: +1 (514) 924 2012


From U951678 at STUDMED.AU.DK  Tue Sep 27 00:02:29 2005
From: U951678 at STUDMED.AU.DK (=?iso-8859-1?Q?S=F8ren_Christensen?=)
Date: Tue, 27 Sep 2005 06:02:29 +0200
Subject: [MINC-users] emma
Message-ID: <FB47ED393635794CB4523F0C52A3D1C2F09F21@urd.svf.au.dk>

Hi,
 I am truing to install the updated EMMA on fedora core 3. The compilation seemed to work, however when calling:
t=mireadimages(fname)      , the following error occours
??? Invalid MEX-file '/usr/local/matlab704/toolbox/emma/mireadimages.mexglx': /usr/local/matlab704/bin/glnx86/../../sys/os/glnx86/libgcc_s.so.1: version `GCC_3.3' not found (required by /usr/lib/libstdc++.so.6).


My gcc compiler is version 3.4.3.

I am not sure how to fix this.
Has something gone wrong during compilation of EMMA?   I can't find anywhere to specify which gcc to use in the Makefiles.

Cheers
Soren


From U951678 at STUDMED.AU.DK  Tue Sep 27 09:02:16 2005
From: U951678 at STUDMED.AU.DK (=?iso-8859-1?Q?S=F8ren_Christensen?=)
Date: Tue, 27 Sep 2005 15:02:16 +0200
Subject: [MINC-users] emma and Matlab 7.5
Message-ID: <FB47ED393635794CB4523F0C52A3D1C2F09F25@urd.svf.au.dk>

Hello list,
 I have trouble making Matlab 7.5 work with EMMA. 
I am running Fedora Core 3, apparently the gcc 3.4 compiler does not work for creating mex files at all(several reports of this on comp.sys.matlab). 
Mex files compiled using gcc3.4 give errors when called from Matlab, i tried mexing the yprime.c testprogram that comes with Matlab and it does not work.
Using gcc3.3  seems to work without problems.
 
After changing the compiler to gcc3.3 in the Makefile.linux file i was hoping for EMMA to work, but now Matlab crashes whenever calling a mex function.
 
Does anyone have a solution or pherhaps binaries?
Is someone working on EMMA or an alternative Matlab-MINC interface? There were some posts from 2004 suggesting it. 
 
Best regards
Soren


From a.janke at gmail.com  Wed Sep 28 08:00:31 2005
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 28 Sep 2005 08:00:31 -0400
Subject: [MINC-users] Mailing list admins wanted!
Message-ID: <d747ed50509280500af2e15a@mail.gmail.com>

Hi all,

Just wondering if anyone else out there has in interest in doing a
little bit of day to day admin of the minc-users mailing list.

It should take no more that 5 minutes of your time every 4 days or so.
(deleting SPAM, approving new users, etc). The admin interface is web
based given that mailman runs the list.

If you are interested, send me an email.

Thanks


--
Andrew Janke      (a.janke at gmail.com || www.cmr.uq.edu.au/~rotor)
Canada->Montreal                                   Cell: +1 (514) 924 2012


From bert at bic.mni.mcgill.ca  Wed Sep 28 11:26:17 2005
From: bert at bic.mni.mcgill.ca (Robert VINCENT)
Date: Wed, 28 Sep 2005 11:26:17 -0400
Subject: [MINC-users] emma and Matlab 7.5
In-Reply-To: <FB47ED393635794CB4523F0C52A3D1C2F09F25@urd.svf.au.dk>
Message-ID: <Pine.SGI.4.44.0509281124260.2421832-100000@shadow.bic.mni.mcgill.ca>

Hi,

Please try the binary package available here:

http://www.bic.mni.mcgill.ca/~bert/emma-0.9.7-linux.tar.gz

Let me know if this helps!

	-bert

On Tue, 27 Sep 2005, S?ren Christensen wrote:

> Hello list,
>  I have trouble making Matlab 7.5 work with EMMA.
> I am running Fedora Core 3, apparently the gcc 3.4 compiler does not work for creating mex files at all(several reports of this on comp.sys.matlab).
> Mex files compiled using gcc3.4 give errors when called from Matlab, i tried mexing the yprime.c testprogram that comes with Matlab and it does not work.
> Using gcc3.3  seems to work without problems.
>
> After changing the compiler to gcc3.3 in the Makefile.linux file i was hoping for EMMA to work, but now Matlab crashes whenever calling a mex function.
>
> Does anyone have a solution or pherhaps binaries?
> Is someone working on EMMA or an alternative Matlab-MINC interface? There were some posts from 2004 suggesting it.
>
> Best regards
> Soren
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



From pgravel at bic.mni.mcgill.ca  Thu Sep 29 13:39:37 2005
From: pgravel at bic.mni.mcgill.ca (Paul GRAVEL)
Date: Thu, 29 Sep 2005 13:39:37 -0400
Subject: [MINC-users] BNC File and PET Image Units
Message-ID: <Pine.SGI.4.44.0509291329520.2307170-100000@shadow.bic.mni.mcgill.ca>

Dear All,

I am getting mixed up with what units are used
in both bnc files and pet images.

>From the code of the program used to create
the bnc files, it seems that the units used
are counts/second, which I would assume would
translate to Becquerels. Is that correct?

As for PET images, some programs seems to be
showing that units are in nCuries, some in ECAT counts, or
in Becquerels (I assume it is just a matter of multiplying
by a certain factor).

However, is there a way to make sure that the units of the
PET image with its related bnc file are the same?
And if so, to know which units are used by default?

Thank you very much in advance.

Best Regards,

Paul
______________________________

Paul Gravel
Neurobiological Psychiatry Unit
McGill University
1033 Pine Avenue West Room 203
Montreal, Quebec, Canada, H3A 1A1
Phone:  (514) 398-7301
Fax:    (514) 398-4866



From marc.schoenwiesner at mcgill.ca  Thu Sep 29 19:58:34 2005
From: marc.schoenwiesner at mcgill.ca (Marc Schoenwiesner)
Date: Thu, 29 Sep 2005 19:58:34 -0400
Subject: [MINC-users] negative zstep causes trouble
Message-ID: <1128038314.433c7faa10753@webmail.mcgill.ca>

Hi,

I am struggling with the conversion/analysis of fMRI data from outside
BIC, but have located the problem more or less. Maybe someone knows about this.

Problem: fmr_preprocess crashes with a dynamic minc file.
The trouble maker is the positive zstep:
>>
file: run1.mncimage: signed__ short 0 to 4095
image dimensions: time zspace yspace xspace dimension name
length step start
    --------------         ------         ----        -----
    time                       71            9            0
    zspace                     19            4     -3.29857
    yspace                     64     -3.12497      95.4729
    xspace                     64     -3.12497      97.9577
>>

fmr_preprocess crashed when resampling the volume, because $nelem_z (resampling
steps in z direction) gets negative. I copied fmr_preprocess and added an abs()
to the 238 to make the calculation robust against positive zsteps:
    $nelem_z = abs (int ((($z_sp - 1) * $z_step ) / $resampling_step));

This step works now. The next hang is when minctracc is called. I found that
this is because the center of gravity of the volume seems to be either
incorrectly calculated by volume_cog, or minctracc cannot handle centroids in
certain quadrants.

center with zstep=4   0.912580 -4.248807  35.571903 (minctracc crashes)
center with zstep=-4 -0.077238 -9.411657 -41.277493 (works fine)

I can work around this problem by setting zstep to -4:
% minc_modify_header -dinsert zspace:step=4 run1.mnc
then run fmr_preprocess and setting it back, but this is ugly and I might mess
up my file orientations (this is a left-brain right-brain thing, so I really
don't want to risk anything of that sort. By the way, mincreshape +/-zdirection
doesn't seem to do anything at all with this file.)

volume_cog and mictracc are binary, so I am stuck here.
I'd be very grateful if anyone could clarify the centroid issue! I am new to the
BIC and MINC (had my first look at the software this week) and don't seem to be
able to get this straightened out myself.

Cheers
Marc

From U951678 at STUDMED.AU.DK  Thu Sep 29 20:38:08 2005
From: U951678 at STUDMED.AU.DK (=?iso-8859-1?Q?S=F8ren_Christensen?=)
Date: Fri, 30 Sep 2005 02:38:08 +0200
Subject: [MINC-users] emma and Matlab 7.5
Message-ID: <FB47ED393635794CB4523F0C52A3D1C2F09F32@urd.svf.au.dk>

Hi Robert,
 That seems to work fine on Linux which is great as this is where i needed it to work.
Unfortunately miinquire does not work on Windows now (but the old version does).
 
Thanks!
 
Soren
 
 
________________________________

Fra: minc-users-bounces at bic.mni.mcgill.ca p? vegne af Robert VINCENT
Sendt: to 29-09-2005 01:26
Til: MINC users mailing list
Emne: Re: [MINC-users] emma and Matlab 7.5



Hi,

Please try the binary package available here:

http://www.bic.mni.mcgill.ca/~bert/emma-0.9.7-linux.tar.gz

Let me know if this helps!

        -bert

On Tue, 27 Sep 2005, S?ren Christensen wrote:

> Hello list,
>  I have trouble making Matlab 7.5 work with EMMA.
> I am running Fedora Core 3, apparently the gcc 3.4 compiler does not work for creating mex files at all(several reports of this on comp.sys.matlab).
> Mex files compiled using gcc3.4 give errors when called from Matlab, i tried mexing the yprime.c testprogram that comes with Matlab and it does not work.
> Using gcc3.3  seems to work without problems.
>
> After changing the compiler to gcc3.3 in the Makefile.linux file i was hoping for EMMA to work, but now Matlab crashes whenever calling a mex function.
>
> Does anyone have a solution or pherhaps binaries?
> Is someone working on EMMA or an alternative Matlab-MINC interface? There were some posts from 2004 suggesting it.
>
> Best regards
> Soren
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users



From bert at bic.mni.mcgill.ca  Fri Sep 30 00:03:10 2005
From: bert at bic.mni.mcgill.ca (Robert VINCENT)
Date: Fri, 30 Sep 2005 00:03:10 -0400
Subject: [MINC-users] emma and Matlab 7.5
In-Reply-To: <FB47ED393635794CB4523F0C52A3D1C2F09F32@urd.svf.au.dk>
Message-ID: <Pine.SGI.4.44.0509300002390.2281276-100000@shadow.bic.mni.mcgill.ca>

Hi Soren,

I've had reports of problems w/matlab 7 and emma on windows - it's on my
"to do" list...

	-bert

On Fri, 30 Sep 2005, S?ren Christensen wrote:

> Hi Robert,
>  That seems to work fine on Linux which is great as this is where i needed it to work.
> Unfortunately miinquire does not work on Windows now (but the old version does).
>
> Thanks!
>
> Soren
>
>
> ________________________________
>
> Fra: minc-users-bounces at bic.mni.mcgill.ca p? vegne af Robert VINCENT
> Sendt: to 29-09-2005 01:26
> Til: MINC users mailing list
> Emne: Re: [MINC-users] emma and Matlab 7.5
>
>
>
> Hi,
>
> Please try the binary package available here:
>
> http://www.bic.mni.mcgill.ca/~bert/emma-0.9.7-linux.tar.gz
>
> Let me know if this helps!
>
>         -bert
>
> On Tue, 27 Sep 2005, S?ren Christensen wrote:
>
> > Hello list,
> >  I have trouble making Matlab 7.5 work with EMMA.
> > I am running Fedora Core 3, apparently the gcc 3.4 compiler does not work for creating mex files at all(several reports of this on comp.sys.matlab).
> > Mex files compiled using gcc3.4 give errors when called from Matlab, i tried mexing the yprime.c testprogram that comes with Matlab and it does not work.
> > Using gcc3.3  seems to work without problems.
> >
> > After changing the compiler to gcc3.3 in the Makefile.linux file i was hoping for EMMA to work, but now Matlab crashes whenever calling a mex function.
> >
> > Does anyone have a solution or pherhaps binaries?
> > Is someone working on EMMA or an alternative Matlab-MINC interface? There were some posts from 2004 suggesting it.
> >
> > Best regards
> > Soren
> >
> > _______________________________________________
> > 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 sylvain at bic.mni.mcgill.ca  Fri Sep 30 13:21:24 2005
From: sylvain at bic.mni.mcgill.ca (Sylvain MILOT)
Date: Fri, 30 Sep 2005 13:21:24 -0400
Subject: [MINC-users] BNC File and PET Image Units
In-Reply-To: <Pine.SGI.4.44.0509291329520.2307170-100000@shadow.bic.mni.mcgill.ca>
Message-ID: <Pine.SGI.4.44.0509291731300.2636571-100000@shadow.bic.mni.mcgill.ca>



Hi Paul,

If you use mincheader on either a BNC or MNC file, you'll
see the units are listed (look for :units).

For the BNC, activity units are a little ambiguous:

The "activity" is  counts/count_length (in seconds), so yes it would
translate to becquerels.

The decay "corrected_activity" is in Becquerels/gram (look at the
Blood-Lab code, i.e. CAL.C and DATFILES.C to get the correction factor)

As far as I can tell, units on the minc side are listed as nCi/cc

If  1 Ci = 37 GBq, then 1 nCi = 37 Bq

Hope this helps a little,

Sylvain


On Thu, 29 Sep 2005, Paul GRAVEL wrote:

> Dear All,
>
> I am getting mixed up with what units are used
> in both bnc files and pet images.
>
> >From the code of the program used to create
> the bnc files, it seems that the units used
> are counts/second, which I would assume would
> translate to Becquerels. Is that correct?
>
> As for PET images, some programs seems to be
> showing that units are in nCuries, some in ECAT counts, or
> in Becquerels (I assume it is just a matter of multiplying
> by a certain factor).
>
> However, is there a way to make sure that the units of the
> PET image with its related bnc file are the same?
> And if so, to know which units are used by default?
>
> Thank you very much in advance.
>
> Best Regards,
>
> Paul
> ______________________________
>
> Paul Gravel
> Neurobiological Psychiatry Unit
> McGill University
> 1033 Pine Avenue West Room 203
> Montreal, Quebec, Canada, H3A 1A1
> Phone:  (514) 398-7301
> Fax:    (514) 398-4866
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

---
Sylvain Milot (sylvain at bic.mni.mcgill.ca)
              (trinity at bic.mni.mcgill.ca)
Brain Imaging Centre
Montreal Neurological Institute
Webster 2B, Room 208
Montreal, Qc., Canada, H3A 2B4
Phone  : (514) 398-4965, Fax: 398-8948
Mobile : (514) 712-1768
Office : 527 Av Des Pins O., Room 204
         Montreal, Qc., H2W 1S4