From nikelski at bic.mni.mcgill.ca  Sun Mar  2 17:26:55 2008
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Sun, 2 Mar 2008 17:26:55 -0500
Subject: [MINC-users] Display and Register Building under Leopard
Message-ID: <e12172550803021426j7774a946u5f4b9bd0d6f8cc2b@mail.gmail.com>

Hello List,

   As part of my rebuilding the world using minc-2.0.15, I seem to
have come across a problem under Leopard (10.5).  Specifically, the
linker dies while linking Display and Register with the following
error message ...

ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib
collect2: ld returned 1 exit status
make[2]: *** [register] Error 1

   According to "The Google" this is a common error under Leopard.
The work-around is to add a couple of linker flags, like this ...

LDFLAGS="-Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib"


This fixed the build error for me. Very cursory testing found both
programs functioning OK.


-Jim

From a.janke at gmail.com  Sun Mar  2 17:44:00 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 3 Mar 2008 09:44:00 +1100
Subject: [MINC-users] Display and Register Building under Leopard
In-Reply-To: <e12172550803021426j7774a946u5f4b9bd0d6f8cc2b@mail.gmail.com>
References: <e12172550803021426j7774a946u5f4b9bd0d6f8cc2b@mail.gmail.com>
Message-ID: <d747ed50803021444j7db2813fm452b436b500aa495@mail.gmail.com>

Thanks for this Jim,

This I presume is with the --with-apple-opengl-framework configure option?

Others at UCLA have also found this error on leopard.


a

On Mon, Mar 3, 2008 at 9:26 AM, EJ Nikelski <nikelski at bic.mni.mcgill.ca> wrote:
> Hello List,
>
>    As part of my rebuilding the world using minc-2.0.15, I seem to
>  have come across a problem under Leopard (10.5).  Specifically, the
>  linker dies while linking Display and Register with the following
>  error message ...
>
>  ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib
>  collect2: ld returned 1 exit status
>  make[2]: *** [register] Error 1
>
>    According to "The Google" this is a common error under Leopard.
>  The work-around is to add a couple of linker flags, like this ...
>
>  LDFLAGS="-Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib"
>
>
>  This fixed the build error for me. Very cursory testing found both
>  programs functioning OK.
>
>
>  -Jim
>  _______________________________________________
>  MINC-users at bic.mni.mcgill.ca
>  http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia    +61 (402) 700 883

From nikelski at bic.mni.mcgill.ca  Sun Mar  2 17:59:47 2008
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Sun, 2 Mar 2008 17:59:47 -0500
Subject: [MINC-users] Display and Register Building under Leopard
In-Reply-To: <d747ed50803021444j7db2813fm452b436b500aa495@mail.gmail.com>
References: <e12172550803021426j7774a946u5f4b9bd0d6f8cc2b@mail.gmail.com>
	<d747ed50803021444j7db2813fm452b436b500aa495@mail.gmail.com>
Message-ID: <e12172550803021459n316b84f0g163a03448733e9e5@mail.gmail.com>

Hi Andrew,


On Sun, Mar 2, 2008 at 5:44 PM, Andrew Janke <a.janke at gmail.com> wrote:
> Thanks for this Jim,

You're very welcome!

>
>  This I presume is with the --with-apple-opengl-framework configure option?

Yup, it is.

>
>  Others at UCLA have also found this error on leopard.
>
>
>  a
>
>
>
>  On Mon, Mar 3, 2008 at 9:26 AM, EJ Nikelski <nikelski at bic.mni.mcgill.ca> wrote:
>  > Hello List,
>  >
>  >    As part of my rebuilding the world using minc-2.0.15, I seem to
>  >  have come across a problem under Leopard (10.5).  Specifically, the
>  >  linker dies while linking Display and Register with the following
>  >  error message ...
>  >
>  >  ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib
>  >  collect2: ld returned 1 exit status
>  >  make[2]: *** [register] Error 1
>  >
>  >    According to "The Google" this is a common error under Leopard.
>  >  The work-around is to add a couple of linker flags, like this ...
>  >
>  >  LDFLAGS="-Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib"
>  >
>  >
>  >  This fixed the build error for me. Very cursory testing found both
>  >  programs functioning OK.
>  >
>  >
>  >  -Jim
>  >  _______________________________________________
>  >  MINC-users at bic.mni.mcgill.ca
>  >  http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>  >
>
>
>
>  --
>  Andrew Janke   (a.janke at gmail.com || http://a.janke.googlepages.com/)
>  Canberra->Australia    +61 (402) 700 883
>  _______________________________________________
>  MINC-users at bic.mni.mcgill.ca
>  http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From mishkind at gmail.com  Wed Mar 12 16:35:14 2008
From: mishkind at gmail.com (Mishkin Derakhshan)
Date: Wed, 12 Mar 2008 16:35:14 -0400
Subject: [MINC-users] multiply with 0 not equal to 0?
Message-ID: <9c5abb60803121335r6c98bf57obc46964627abf0ae@mail.gmail.com>

Hi,

I have a binary mask that I multiply with a volume and I am expecting
that in the resultant image, everywhere that the mask was 0, the
resulting image should be zero as well. Instead, it is some number
close to zero but not necessarily 0.

I am not sure if this is a problem with how register/display display
the values or with the data itself.

I used this command
mincmath -mult mask.mnc volume.mnc out.mnc

(minccalc -expression "A[0]*A[1]" mask.mnc volume.mnc out.mnc doesn't
seem to work either).

The mask is a unisgned byte, real range 0 to 1, voxel range 0 to 255.
The volume is a signed short. real range -91.323 to 1364.351, voxel
range 0 to 4095.

I have tried changing the order of the multiplication, adding -double,
-short, -int, -long, -byte, -unsigned, -signed to the mincmath command
but nothing seems to work.

The data can be found here if you want to see for yourself.
http://www.bic.mni.mcgill.ca/users/mishkin/files/

thanks,
mishkin

From a.janke at gmail.com  Wed Mar 12 16:52:03 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 13 Mar 2008 07:52:03 +1100
Subject: [MINC-users] multiply with 0 not equal to 0?
In-Reply-To: <9c5abb60803121335r6c98bf57obc46964627abf0ae@mail.gmail.com>
References: <9c5abb60803121335r6c98bf57obc46964627abf0ae@mail.gmail.com>
Message-ID: <d747ed50803121352t6b38b5e4i9168a76151c8fe07@mail.gmail.com>

Hi Mishkin,

On Thu, Mar 13, 2008 at 7:35 AM, Mishkin Derakhshan <mishkind at gmail.com> wrote:
> Hi,
>
>  I have a binary mask that I multiply with a volume and I am expecting
>  that in the resultant image, everywhere that the mask was 0, the
>  resulting image should be zero as well. Instead, it is some number
>  close to zero but not necessarily 0.
>
>  I am not sure if this is a problem with how register/display display
>  the values or with the data itself.

I would take a bet that you are being bitten by a combination of both.
 Certainly register always rescales all values between 0 and 255
internally.

>  I used this command
>  mincmath -mult mask.mnc volume.mnc out.mnc
>
>  (minccalc -expression "A[0]*A[1]" mask.mnc volume.mnc out.mnc doesn't
>  seem to work either).
>
>  The mask is a unisgned byte, real range 0 to 1, voxel range 0 to 255.
>  The volume is a signed short. real range -91.323 to 1364.351, voxel
>  range 0 to 4095.

My first suggestion would be to use mincextract to determine the real
values that are being produced in the resulting file and then if this
is wrong start investigating further.  ie: to get the value at voxel
coord 0,0,0 (which i presume will/should be a "0") do this:

   $ mincextract -start 0,0,0 -count 1,1,1 out.mnc

Then if this is working you can either rescale your output volume to
force it to lie between 0 and 255 as a byte (so that register will
display the result "correctly" or simply ignore the value from
register! :)


-- 
Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia +61 (402) 700 883

From claude at bic.mni.mcgill.ca  Wed Mar 12 18:03:35 2008
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Wed, 12 Mar 2008 18:03:35 -0400 (EDT)
Subject: [MINC-users] multiply with 0 not equal to 0?
References: <9c5abb60803121335r6c98bf57obc46964627abf0ae@mail.gmail.com>
Message-ID: <200803122203.m2CM3ZbL27428705@yorick.bic.mni.mcgill.ca>

Hi Mishkin,

Welcome to the world of minc ranges.

If you use xdisp, you will see the true voxel values, unlike register or
Display that will recast the ranges in 0..255. If you do so, you will see
that the background value is -0.0257254 - which happens to be the "zero"
range for your image in signed short (min=-91.32 to max=1364.35). In register,
the 0..255 zero bin has value -0.90810. Working in floats doesn't really 
help as the zero bin will be converted to a small value, not necessarily
zero. 

If you want something visually good but equally wrong, try this:

minccalc -unsigned -short -range 0 4095 -expre 'if(A[0]>0&&A[1]>0.5){out=A[0]}else{out=0}' 
signed_short_volume.mnc.gz unsigned_byte_mask.mnc.gz out.mnc

Now the zero range will show up as zero in register but the true value will
not be exactly zero (I get 0.0194111). 

Claude

From stinson at bic.mni.mcgill.ca  Tue Mar 18 14:29:25 2008
From: stinson at bic.mni.mcgill.ca (Eric STINSON - B. Pike Lab)
Date: Tue, 18 Mar 2008 14:29:25 -0400
Subject: [MINC-users] Blur and resample a volume_io volume
Message-ID: <200803181829.m2IITP8H016903@dromio.bic.mni.mcgill.ca>

Hi,
I'm working on a registration and distortion correction program using volume_io volumes.  My algorithm includes a multiresolution approach, and until now I have been using system calls to mincblur and mincresample to facilitate this.  I've now decided that it's best to not use the system calls, and would like to just blur the volumes in the program.  Are there any libraries available to help with this?  Or, does anyone have any other ideas as to how I could accomplish this without all my system calls to the minctools?  Any help would be greatly appreciated.  Thanks!
Eric

From louis.collins at mcgill.ca  Tue Mar 18 14:56:35 2008
From: louis.collins at mcgill.ca (D. Louis Collins)
Date: Tue, 18 Mar 2008 14:56:35 -0400
Subject: [MINC-users] Blur and resample a volume_io volume
In-Reply-To: <200803181829.m2IITP8H016903@dromio.bic.mni.mcgill.ca>
References: <200803181829.m2IITP8H016903@dromio.bic.mni.mcgill.ca>
Message-ID: <289A0A75-B36E-440C-9132-74291D469AC8@mcgill.ca>

Eric,

you can use the source code for blurring in the mni_autoreg/mincblur  
program.

-Louis

On Mar 18, 2008, at 2:29 PM, Eric STINSON - B. Pike Lab wrote:

> Hi,
> I'm working on a registration and distortion correction program  
> using volume_io volumes.  My algorithm includes a multiresolution  
> approach, and until now I have been using system calls to mincblur  
> and mincresample to facilitate this.  I've now decided that it's  
> best to not use the system calls, and would like to just blur the  
> volumes in the program.  Are there any libraries available to help  
> with this?  Or, does anyone have any other ideas as to how I could  
> accomplish this without all my system calls to the minctools?  Any  
> help would be greatly appreciated.  Thanks!
> Eric
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users


From nikelski at bic.mni.mcgill.ca  Tue Mar 18 19:13:04 2008
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Tue, 18 Mar 2008 19:13:04 -0400
Subject: [MINC-users] EMMA for MacIntel
Message-ID: <e12172550803181613r470096cdwbb40b05b510ebf63@mail.gmail.com>

Hi All,

   I have both a problem and a solution ... and a problem.  Firstly,
emma will not build properly on Intel Macs since the mex files have
the extension .mexmaci (note the trailing "i").  Happily, this is
avoided by either changing the MEX_EXT parameter in Makefile.macosx to
mexmaci (the quick work-around), or by creating a new Makefile.macOSXi
build file and then changing Makefile to test for processor type
(uname -p) in addition to OS when dealing with OSX.  So, that fixes
that.

   Sadly, even after a happy and otherwise uneventful installation, I
still got a Matlab abort when trying to open a minc2 volume.   As the
dump showed it failing in the hdf5 library, I tried it again with the
same volume, but converted to minc1 ... and it worked. So, the problem
seems to be hdf5-related.  I built my hdf5+netcdf+minc2 from scratch,
and all works well ... except emma under minc2. Does anyone have any
ideas or suggestions?

-Jim

From a.janke at gmail.com  Tue Mar 18 21:43:11 2008
From: a.janke at gmail.com (Andrew Janke)
Date: Wed, 19 Mar 2008 12:43:11 +1100
Subject: [MINC-users] EMMA for MacIntel
In-Reply-To: <e12172550803181613r470096cdwbb40b05b510ebf63@mail.gmail.com>
References: <e12172550803181613r470096cdwbb40b05b510ebf63@mail.gmail.com>
Message-ID: <d747ed50803181843j1a3391c4ka0b4fbbe05bbed0f@mail.gmail.com>

Hi Jim,

Afraid I cannot help you here, although from a quick search it would
appear that you are not alone with HDF5 + Matlab + leopard/Tiger.  The
atmospheric research lot are up the creek too. :(


a

On Wed, Mar 19, 2008 at 10:13 AM, EJ Nikelski
<nikelski at bic.mni.mcgill.ca> wrote:
> Hi All,
>
>    I have both a problem and a solution ... and a problem.  Firstly,
>  emma will not build properly on Intel Macs since the mex files have
>  the extension .mexmaci (note the trailing "i").  Happily, this is
>  avoided by either changing the MEX_EXT parameter in Makefile.macosx to
>  mexmaci (the quick work-around), or by creating a new Makefile.macOSXi
>  build file and then changing Makefile to test for processor type
>  (uname -p) in addition to OS when dealing with OSX.  So, that fixes
>  that.
>
>    Sadly, even after a happy and otherwise uneventful installation, I
>  still got a Matlab abort when trying to open a minc2 volume.   As the
>  dump showed it failing in the hdf5 library, I tried it again with the
>  same volume, but converted to minc1 ... and it worked. So, the problem
>  seems to be hdf5-related.  I built my hdf5+netcdf+minc2 from scratch,
>  and all works well ... except emma under minc2. Does anyone have any
>  ideas or suggestions?
>
>  -Jim
>  _______________________________________________
>  MINC-users at bic.mni.mcgill.ca
>  http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>



-- 
Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/)
Canberra->Australia +61 (402) 700 883

From nikelski at bic.mni.mcgill.ca  Wed Mar 19 12:52:32 2008
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Wed, 19 Mar 2008 12:52:32 -0400
Subject: [MINC-users] get_meansd_voi???
Message-ID: <e12172550803190952k4ba92b55s146e02b75798cec1@mail.gmail.com>

Hi all,

   Does anyone know whatever happened to "get_meansd_voi"?  It was a
lovely little utility that allowed you to enter a world coordinate and
a radius and then extract values (mean and sd) from a minc volume.
Yorick is still aware of "get_meansd_vois", a script written by Alex
that calls "get_meansd_voi", but I cannot find get_meansd_voi itself.
Yes, I know that mincextract can extract values as well, but the
radius feature in get_meansd_voi was very useful.  Ideas?

-Jim

From sylvain at bic.mni.mcgill.ca  Wed Mar 19 13:32:49 2008
From: sylvain at bic.mni.mcgill.ca (Sylvain Milot)
Date: Wed, 19 Mar 2008 13:32:49 -0400 (EDT)
Subject: [MINC-users] get_meansd_voi???
In-Reply-To: <e12172550803190952k4ba92b55s146e02b75798cec1@mail.gmail.com>
References: <e12172550803190952k4ba92b55s146e02b75798cec1@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0803191328250.9581@mustardseed.bic.mni.mcgill.ca>


Hi Jim,

get_meansd_voi is part of dot and that has never been fully ported to 
linux.

I may actually complete this one day as yorick's days are counted! I was 
thinking the entire package would have been obsoleted by now but it is 
still useful.

S

On Wed, 19 Mar 2008, EJ Nikelski wrote:

> Hi all,
>
>   Does anyone know whatever happened to "get_meansd_voi"?  It was a
> lovely little utility that allowed you to enter a world coordinate and
> a radius and then extract values (mean and sd) from a minc volume.
> Yorick is still aware of "get_meansd_vois", a script written by Alex
> that calls "get_meansd_voi", but I cannot find get_meansd_voi itself.
> Yes, I know that mincextract can extract values as well, but the
> radius feature in get_meansd_voi was very useful.  Ideas?
>
> -Jim
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

---
Sylvain Milot (sylvain at bic.mni.mcgill.ca)
               (bicadmin at bic.mni.mcgill.ca)
Brain Imaging Centre
Montreal Neurological Institute
3801 University Street
Webster 2B, Room 212
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

From nikelski at bic.mni.mcgill.ca  Fri Mar 21 17:54:59 2008
From: nikelski at bic.mni.mcgill.ca (EJ Nikelski)
Date: Fri, 21 Mar 2008 17:54:59 -0400
Subject: [MINC-users] Where is RegistrationFilenames.pm?
Message-ID: <e12172550803211454i72055df8q844fa348f688fd0b@mail.gmail.com>

Hi all,

    I need to create spatially normalized rCBF volumes.  In the past,
I either had "dot" do it, or I did it manually with some scripts
created by Greg Ward (e.g. do_mritotal, do_pettopet, do_mritopet).
Now these scripts use some rather dated perl modules, all of which I
have been able to find on Yorick (god bless Yorick).  The only
exception is "RegistrationFilenames.pm", called from mritopet, which I
am unable to locate. Does anyone know where it might be hiding?
Alternatively, does anyone else who might also be using these scripts
have a copy that I could grab?

   On a related note, am I correct in my understanding that the tool
that used to do all of this processing (pettopet, etc), --- "dot"---,
has been effectively decommissioned, without an effective replacement?
 I know that fmristat can do PET analyses, but it requires the input
emission scan volumes to already be in stereotactic space.  Greg's
"do_xxxtoyyy" scripts  fill the bill, but appear to be evaporating.
Are there more current options at the BIC, or are we ceding this
domain to SPM and its ilk?


-Jim

From kumakura at bic.mni.mcgill.ca  Wed Mar 26 09:20:46 2008
From: kumakura at bic.mni.mcgill.ca (Yoshitaka KUMAKURA)
Date: Wed, 26 Mar 2008 09:20:46 -0400
Subject: [MINC-users] upet2mnc
Message-ID: <Pine.SGI.4.58.0803260810110.28941597@yorick.bic.mni.mcgill.ca>

Hi minc users,

I have a number of static (3D) MicroPET data obtained from Focus 120, and
I would like to convert them to minc. To circumvent multiple-frame
reconstruction process, I just specified a certain time window for 3DRP
or OSEM-MAP reconstruction, and I've confirmed that Siemens AsiPro viewer
works well with the reconstructed 3D images. (So, it is unlikely the .img
and .img.hdr files are problematic.) My probelwm is that I have never been
able to get upet2mnc working properly for the 3D MicroPET images, though I'happy that upet2mnc always works perfectly well
for 4D.

Is thre any option or trick to get this done as I intend?

Thank you very much.

Yoshi

Yoshi Kumakura, M.D., Ph.D.
kumakura at bic.mni.mcgil.ca
Research Center for Advanced Science and Technology, the Univeristy of
Tokyo, Japan