From nikelski at bic.mni.mcgill.ca Tue Jul 8 12:02:19 2008 From: nikelski at bic.mni.mcgill.ca (EJ Nikelski) Date: Tue, 8 Jul 2008 12:02:19 -0400 Subject: [MINC-users] minc2 api question Message-ID: Hi List, I had a question concerning the operation of a subset of minc2 functions, which I believe I posted a few weeks ago -- although I'm now wondering if the post may have been lost. So, just to be sure that it got out, let me throw it out again (pls forgive the redundancy if the first one did get out). ========== start previous post I've been writing some minc2 code, and have run into a problem when retrieving attributes from a minc2 volume. For example, say that I wanted to get information on attribute "xspace:varid" (just as an example). If I were to start by retrieving the length of the attribute by calling miget_attr_length, I would get a no-find returned since miget_attr_length starts all attribute searches relative to /minc-2.0/info. Any path passed to miget_attr_length is simply appended to /minc-2.0/info. Therefore, call like this : result = miget_attr_length(minc_volume, "/minc-2.0/dimensions/xspace", "varid", &attr_length); ... would result in /minc-2.0/info/minc-2.0/dimensions/xspace being searched for attribute "varid" (and subsequently not found). The code that causes this behaviour can be found in a number of miget_attr_xxx functions, and therefore most other attribute related functions similarly are unable to find requested attributes. Now I know that the API has specialty functions to retrieve all sorts of attributes, however, I had assumed that one should be able to use the miget_attr_xxx functions to retrieve any or all of the attributes -- and not just those in /minc-2.0/info/. Is this assumption incorrect? By the way, I modified some of the miget_attr_xxx functions on my system to respect an absolute path when passed (and not prepend /minc-2.0/info/), which worked ... but broke other things (including the minc2 "make check", amongst other things) ... so beware, as some code assumes the current behaviour. Any comments/suggestions on this stuff would be welcome. -Jim From baghdadi at phenogenomics.ca Tue Jul 8 12:26:00 2008 From: baghdadi at phenogenomics.ca (Leila Baghdadi) Date: Tue, 8 Jul 2008 12:26:00 -0400 Subject: [MINC-users] minc2 api question In-Reply-To: References: Message-ID: <1215534360.15320.4.camel@mouse17.phenogenomics.ca> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www2.bic.mni.mcgill.ca/pipermail/minc-users/attachments/20080708/305fa0a0/attachment.txt From nikelski at bic.mni.mcgill.ca Fri Jul 11 09:23:17 2008 From: nikelski at bic.mni.mcgill.ca (EJ Nikelski) Date: Fri, 11 Jul 2008 09:23:17 -0400 Subject: [MINC-users] minc2 api question In-Reply-To: <1215534360.15320.4.camel@mouse17.phenogenomics.ca> References: <1215534360.15320.4.camel@mouse17.phenogenomics.ca> Message-ID: Hi Leila (and List), Thanks for the response. Given my unfamiliarity with the minc2 api, I was mainly interested in knowing whether the attributes behaviour was an intentional design decision or a bug. Given your response, I gather it's a bug. This problem appears to have fairly wide-ranging consequences, given that any function that attempts to access spatial attributes via these accessor functions is going to fail. For example, "miget_space_name" fails (i.e. it returns the default "native__" space, even for talairach volumes), since it uses the miget_attr_xxxx function to search the spatial attributes. As my current minc2-related work is not super time critical, I'll wait until the minc2 api modifications hit cvs, at which time I will be happy to test the full range of attribute-related functions. Cheers, -Jim On Tue, Jul 8, 2008 at 12:26 PM, Leila Baghdadi wrote: > Ej > > I have done some modification to attribute functions. I am not sure if > that would resolve your situation or not.However, I did not get a chance > to contribute it to cvs as I am working on some other project. > > I will try finding some time soon to do that, however not sure when. > > If you want I can send you the code and you can change yours to see if > that resolves the problem. > > Leila > > On Tue, 2008-08-07 at 12:02 -0400, EJ Nikelski wrote: >> Hi List, >> >> I had a question concerning the operation of a subset of minc2 >> functions, which I believe I posted a few weeks ago -- although I'm >> now wondering if the post may have been lost. So, just to be sure >> that it got out, let me throw it out again (pls forgive the redundancy >> if the first one did get out). >> >> >> ========== start previous post >> >> I've been writing some minc2 code, and have run into a problem >> when retrieving attributes from a minc2 volume. For example, say that >> I wanted to get information on attribute "xspace:varid" (just as an >> example). If I were to start by retrieving the length of the >> attribute by calling miget_attr_length, I would get a no-find returned >> since miget_attr_length starts all attribute searches relative to >> /minc-2.0/info. Any path passed to miget_attr_length is simply >> appended to /minc-2.0/info. Therefore, call like this : >> >> result = miget_attr_length(minc_volume, "/minc-2.0/dimensions/xspace", >> "varid", &attr_length); >> >> ... would result in /minc-2.0/info/minc-2.0/dimensions/xspace being >> searched for attribute "varid" (and subsequently not found). The code >> that causes this behaviour can be found in a number of miget_attr_xxx >> functions, and therefore most other attribute related functions >> similarly are unable to find requested attributes. Now I know that >> the API has specialty functions to retrieve all sorts of attributes, >> however, I had assumed that one should be able to use the >> miget_attr_xxx functions to retrieve any or all of the attributes -- >> and not just those in /minc-2.0/info/. Is this assumption incorrect? >> >> By the way, I modified some of the miget_attr_xxx functions on my >> system to respect an absolute path when passed (and not prepend >> /minc-2.0/info/), which worked ... but broke other things (including >> the minc2 "make check", amongst other things) ... so beware, as some >> code assumes the current behaviour. >> >> Any comments/suggestions on this stuff would be welcome. >> >> >> -Jim >> _______________________________________________ >> MINC-users at bic.mni.mcgill.ca >> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- ================================= Jim Nikelski, Ph.D. Postdoctoral Research Fellow Bloomfield Centre for Research in Aging Lady Davis Institute for Medical Research Sir Mortimer B. Davis - Jewish General Hospital McGill University Tel: (514) 340-8222 x 2298 Fax: (514) 340-8295 From rupe.brooks at gmail.com Tue Jul 15 07:47:56 2008 From: rupe.brooks at gmail.com (Rupert Brooks) Date: Tue, 15 Jul 2008 07:47:56 -0400 Subject: [MINC-users] win32 versions of register and Display In-Reply-To: References: <160E3DD4FB702C4CB860C65186686E6902886E23@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E6902425013@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E69029C1E9E@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E69020202A4@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E6902425014@MRZS152229.medizin.uni-leipzig.de> <200806261243.m5QCh7VE020072@yorick.bic.mni.mcgill.ca> <160E3DD4FB702C4CB860C65186686E690242501C@MRZS152229.medizin.uni-leipzig.de> <4863A0D4.7090103@bic.mni.mcgill.ca> Message-ID: Hi I decided to build my own win32 Register and Display, using cygwin. I've gotten stuck with Register - I get the following error - a conflicting dtoa. Has anyone seen this and have a workaround? thanks Rupert B. make[2]: Entering directory `/cygdrive/g/builds/minc/cygwin/Register-1.3.6/Regis ter_resample' if gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -MT register_resample.o -MD -MP - MF ".deps/register_resample.Tpo" -c -o register_resample.o register_resample.c; \ then mv -f ".deps/register_resample.Tpo" ".deps/register_resample.Po"; e lse rm -f ".deps/register_resample.Tpo"; exit 1; fi register_resample.c:75:1: warning: "X" redefined In file included from /cygdrive/g/builds/minc/cygwin/install/include/volume_io.h :44, from register_resample.c:58: /cygdrive/g/builds/minc/cygwin/install/include/volume_io/geom_structs.h:42:1: wa rning: this is the location of the previous definition register_resample.c:76:1: warning: "Y" redefined /cygdrive/g/builds/minc/cygwin/install/include/volume_io/geom_structs.h:43:1: wa rning: this is the location of the previous definition register_resample.c:77:1: warning: "Z" redefined /cygdrive/g/builds/minc/cygwin/install/include/volume_io/geom_structs.h:44:1: wa rning: this is the location of the previous definition register_resample.c:101: error: conflicting types for 'dtoa' /usr/include/stdlib.h:143: error: previous declaration of 'dtoa' was here register_resample.c:101: error: conflicting types for 'dtoa' /usr/include/stdlib.h:143: error: previous declaration of 'dtoa' was here make[2]: *** [register_resample.o] Error 1 make[2]: Leaving directory `/cygdrive/g/builds/minc/cygwin/Register-1.3.6/Regist er_resample' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/g/builds/minc/cygwin/Register-1.3.6' make: *** [all] Error 2 Rupert Brooks at Rupeslap /cygdrive/g/builds/minc/cygwin/Register-1.3.6 $ On Thu, Jun 26, 2008 at 3:32 PM, Penhune Lab wrote: > We have a copy that we got (i think) from Dr Jorge Armony. It runs natively > on winXP. I don't know which version it is exactly, it reports: > > "register.exe: Version: 1.3 Aug 25, 1998" > > But i don't know if thats 1.3.0 or 1.3.x and just doesn't report the second > decimal > > I also wrote a matlab script to call register from matlab that takes care of > some path problems when calling register from a DOS shell (pretty much > changing the directory delimiter \ to /) > > Let me know if you want a copy > > Alejandro > > On 6/26/08, Laurence Mercier wrote: >> >> Hello Michel, >> >> I actually have register and Display running on my Windows XP machine... >> but I installed it while ago and am not sure from what source. I wonder >> if it is from the last package Andrew compiled for Windows (on top of >> cygwin)? Or maybe it is from Frank Morales page. For register I can call >> it directly from cygwin and for Display I first have to type startx and >> then call Display from the X window. >> >> >> Laurence >> >> >> >> Audette, Michel wrote: >> > Hi Claude, >> > >> > thanks for the kind reply. I guess I'll give it a try. >> > >> > Cheers, >> > >> > Michel >> > >> > Michel Audette, Ph.D. >> > Innovation Center Computer Assisted Surgery (ICCAS) >> > Semmelweisstra?e 14 >> > Leipzig, Germany >> > Phone: ++49 (0) 341 / 97 - 1 20 13 >> > Fax: ++49 (0) 341 / 97 - 1 20 09 >> > >> > >> > >> > >> > >> > -----Original Message----- >> > From: minc-users-bounces at bic.mni.mcgill.ca [mailto: >> minc-users-bounces at bic.mni.mcgill.ca] On Behalf Of Claude LEPAGE >> > Sent: June 26, 2008 2:43 PM >> > To: MINC users mailing list >> > Subject: Re: [MINC-users] win32 versions of register and Display >> > >> > Hi Michel, >> > >> >> Hello again, >> >> >> >> I found windows binaries in Frank Morales' page, but they don't seem to >> run on Windows XP. [Typing register elicits a response "GLUT: Fatal Error in >> no_program_name: pixel format with necessary capabilities not found".] >> >> >> >> The Windows MINC 2.0 software does not build Display or register. >> >> >> >> If anyone can suggest where to look for win32 versions, that would be >> great. >> > >> > Well, I did build Display and register on my Windows XP machine >> > at home (mostly for fun), but using cygwin 5.1. It works nicely, >> > no problem. Would you like to try those? >> > >> > Claude >> > _______________________________________________ >> > MINC-users at bic.mni.mcgill.ca >> > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> > >> > _______________________________________________ >> > MINC-users at bic.mni.mcgill.ca >> > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> >> >> _______________________________________________ >> MINC-users at bic.mni.mcgill.ca >> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> > > > > -- > Laboratory for Motor Learning and Neural Plasticity > Directed by Dr. Virginia Penhune > Department of Psychology, Concordia University > SP-A 244, 7141 Sherbrooke St. W > Montreal, QC H4B 1R6 Canada > (514)848-2424 ext. 7567 > http://psychology.concordia.ca/fac/penhune/winindex.html > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- -------------------------------------------------------------- Rupert Brooks McGill Centre for Intelligent Machines (www.cim.mcgill.ca) Ph.D Student, Electrical and Computer Engineering http://www.cyberus.ca/~rbrooks From a.janke at gmail.com Tue Jul 15 08:34:02 2008 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 15 Jul 2008 22:34:02 +1000 Subject: [MINC-users] win32 versions of register and Display In-Reply-To: References: <160E3DD4FB702C4CB860C65186686E6902886E23@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E6902425013@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E69029C1E9E@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E69020202A4@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E6902425014@MRZS152229.medizin.uni-leipzig.de> <200806261243.m5QCh7VE020072@yorick.bic.mni.mcgill.ca> <160E3DD4FB702C4CB860C65186686E690242501C@MRZS152229.medizin.uni-leipzig.de> <4863A0D4.7090103@bic.mni.mcgill.ca> Message-ID: Hi Rupert, On Tue, Jul 15, 2008 at 21:47, Rupert Brooks wrote: > I decided to build my own win32 Register and Display, using cygwin. > I've gotten stuck with Register - I get the following error - a > conflicting dtoa. Has anyone seen this and have a workaround? > > ... > > register_resample.c:101: error: conflicting types for 'dtoa' > /usr/include/stdlib.h:143: error: previous declaration of 'dtoa' was here > register_resample.c:101: error: conflicting types for 'dtoa' I myself have not seen this. Is this on Vista or XP? I have a fairly current Vista cygwin build that seemed OK. In any case the simplest hack fix is to just fiddle in Register_resample/register_resample.c and rename the offending function (line 468) to dtoa_rr or something like that. This little function that peter wote nigh on 15 years ago doesn't seem to be used anywhere else. Either that or just comment out the build of register_resample from line 5 of Makefile.am, it is an extra executable that I doubt many people use or even know exists. Have fun -- 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 Tue Jul 15 11:58:17 2008 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Tue, 15 Jul 2008 11:58:17 -0400 (EDT) Subject: [MINC-users] win32 versions of register and Display References: <160E3DD4FB702C4CB860C65186686E6902886E23@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E6902425013@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E69029C1E9E@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E69020202A4@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E6902425014@MRZS152229.medizin.uni-leipzig.de> <200806261243.m5QCh7VE020072@yorick.bic.mni.mcgill.ca> <160E3DD4FB702C4CB860C65186686E690242501C@MRZS152229.medizin.uni-leipzig.de> <4863A0D4.7090103@bic.mni.mcgill.ca> Message-ID: <200807151558.m6FFwHw91360901@yorick.bic.mni.mcgill.ca> Hi > I decided to build my own win32 Register and Display, using cygwin. > I've gotten stuck with Register - I get the following error - a > conflicting dtoa. Has anyone seen this and have a workaround? I modified the function and renamed dtoa to my_dtoa. You could have found Register and Display using cygwin (on XP) on my web page: http://www.bic.mni.mcgill.ca/users/claude/winxp/ Claude From rupe.brooks at gmail.com Wed Jul 16 08:32:10 2008 From: rupe.brooks at gmail.com (Rupert Brooks) Date: Wed, 16 Jul 2008 08:32:10 -0400 Subject: [MINC-users] win32 versions of register and Display In-Reply-To: <200807151558.m6FFwHw91360901@yorick.bic.mni.mcgill.ca> References: <160E3DD4FB702C4CB860C65186686E6902886E23@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E6902425013@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E69029C1E9E@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E69020202A4@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E6902425014@MRZS152229.medizin.uni-leipzig.de> <200806261243.m5QCh7VE020072@yorick.bic.mni.mcgill.ca> <160E3DD4FB702C4CB860C65186686E690242501C@MRZS152229.medizin.uni-leipzig.de> <4863A0D4.7090103@bic.mni.mcgill.ca> <200807151558.m6FFwHw91360901@yorick.bic.mni.mcgill.ca> Message-ID: Thanks. That got it building. For the record - this was on XP. A number of other odd things occurred with the configure script when building - i had to add a lot of things via the CPATH, LIBRARY_PATH and LIBS variables. This may also be related. However - there remains one issue. Both this build, and the one on your web site use X, and dont use acceleration (this is probably due to cygwins freeglut, rather than register particularly). There was an old cygwin build of register kicking around that used the windows GL directly, and did not require X at all. Unfortunately, i dont really know who built it or where it came from... Do you or anyone else know how to achieve that? Before someone asks, the reason i am trying to replace the older build is that it did not support minc2 :-) Cheers Rupert On Tue, Jul 15, 2008 at 11:58 AM, Claude LEPAGE wrote: > Hi > >> I decided to build my own win32 Register and Display, using cygwin. >> I've gotten stuck with Register - I get the following error - a >> conflicting dtoa. Has anyone seen this and have a workaround? > > I modified the function and renamed dtoa to my_dtoa. > > You could have found Register and Display using cygwin (on XP) on > my web page: > > http://www.bic.mni.mcgill.ca/users/claude/winxp/ > > Claude > -- -------------------------------------------------------------- Rupert Brooks McGill Centre for Intelligent Machines (www.cim.mcgill.ca) Ph.D Student, Electrical and Computer Engineering http://www.cyberus.ca/~rbrooks From a.janke at gmail.com Thu Jul 17 03:03:17 2008 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 17 Jul 2008 17:03:17 +1000 Subject: [MINC-users] win32 versions of register and Display In-Reply-To: References: <160E3DD4FB702C4CB860C65186686E6902886E23@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E69029C1E9E@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E69020202A4@MRZS152229.medizin.uni-leipzig.de> <160E3DD4FB702C4CB860C65186686E6902425014@MRZS152229.medizin.uni-leipzig.de> <200806261243.m5QCh7VE020072@yorick.bic.mni.mcgill.ca> <160E3DD4FB702C4CB860C65186686E690242501C@MRZS152229.medizin.uni-leipzig.de> <4863A0D4.7090103@bic.mni.mcgill.ca> <200807151558.m6FFwHw91360901@yorick.bic.mni.mcgill.ca> Message-ID: On Wed, Jul 16, 2008 at 22:32, Rupert Brooks wrote: > For the record - this was on XP. A number of other odd things > occurred with the configure script when building - i had to add a lot > of things via the CPATH, LIBRARY_PATH and LIBS variables. This may > also be related. Aye.. (see below) > However - there remains one issue. Both this build, and the one on > your web site use X, and dont use acceleration (this is probably due > to cygwins freeglut, rather than register particularly). There was an > old cygwin build of register kicking around that used the windows GL > directly, and did not require X at all. Unfortunately, i dont really > know who built it or where it came from... Do you or anyone else know > how to achieve that? That would have been me! Although I only managed to get register to behave in this fashion not Display ever. In this case I went through a whole lot of convolutions in which you install the cygwin doo-dads that link to the win32 openGL libraries (you have to link in -lopengl32 or some such thing -- this is all a dim-dark memory) instead of the default cygwin opengl and glut libraries which happen to be freeglut and mesa. > Before someone asks, the reason i am trying to replace the older build > is that it did not support minc2 :-) Ah, true that. I will have to have a hack at rebuilding all of this myself. a From acveilleux at mrs.mni.mcgill.ca Tue Jul 22 13:54:37 2008 From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX) Date: Tue, 22 Jul 2008 13:54:37 -0400 Subject: [MINC-users] Minc 1.5.1 64-bit compatibility bug Message-ID: <20080722135437.N18530@mrs.mni.mcgill.ca> Hi, Minc 1.5.1 includes ParseArgv as part of libminc. This library provides the argument parsing support for most libtools. rawtominc (and probably others) misuse ParseArgv when dealing with constants. The offending code looks like: /* Argument table */ ArgvInfo argTable[] = { // ... snip ... {"-nomodality", ARGV_CONSTANT, NULL, (char *) &modality, "Do not store modality type in file."}, "-pet", ARGV_CONSTANT, MI_PET, (char *) &modality, "PET data."}, {"-mri", ARGV_CONSTANT, MI_MRI, (char *) &modality, "MRI data."}, // ... snip ... In ParseArgv however the arguments gets converted to an int: case ARGV_CONSTANT: *((int *) infoPtr->dst) = *((int*)(&infoPtr->src)); break; On 64-bit platforms this causes the upper 32-bit of the pointers to be dropped. On subsequent use by rawtominc, the whole thing breaks because rawtominc still expects a pointer: /* Create the modality attribute */ if (modality != NULL) { varid = micreate_group_variable(cdfid, MIstudy); (void) miattputstr(cdfid, varid, MImodality, modality); } Output (with extra debugging, line offset off by 1 due to fprintf): (gdb) run test.mnc 60 256 192 -clobber -mri Starting program: /localscratch/compile/minc-1.5.1/progs/rawtominc/rawtominc test.mnc 60 256 192 -clobber -mri Reading symbols for shared libraries ++. done miattputstr(cdfid, varid, MImodality, modality) where: modality(int) = 200150 modality(pointer) = 0x30dd6 modality(actual pointer) = 0x100030dd6 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000030dd0 0x00007fff80a3a0d0 in strlen () (gdb) bt #0 0x00007fff80a3a0d0 in strlen () #1 0x000000010000cfe8 in miattputstr () #2 0x0000000100001b1b in main (argc=7, argv=0x7fff5fbff488) at progs/rawtominc/rawtominc.c:636 (gdb) I don't have access to fix this in the CVS. When this is dealt with, I'll update my 64-bit os-x 10.5 tarball. Alex From acveilleux at mrs.mni.mcgill.ca Tue Jul 22 14:12:38 2008 From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX) Date: Tue, 22 Jul 2008 14:12:38 -0400 Subject: [MINC-users] Minc 1.5.1 64-bit compatibility bug In-Reply-To: <20080722135437.N18530@mrs.mni.mcgill.ca>; from acveilleux@mrs.mni.mcgill.ca on Tue, Jul 22, 2008 at 01:54:37PM -0400 References: <20080722135437.N18530@mrs.mni.mcgill.ca> Message-ID: <20080722141238.O18530@mrs.mni.mcgill.ca> Hi, I forgot the "easy" fix: case ARGV_CONSTANT: *((int *) infoPtr->dst) = *((int*)(&infoPtr->src)); break; Becomes: case ARGV_CONSTANT: *((long *) infoPtr->dst) = *((long*)(&infoPtr->src)); break; Alex On Tue, Jul 22, 2008 at 01:54:37PM -0400, Alexandre CARMEL-VEILLEUX wrote: > Date: Tue, 22 Jul 2008 13:54:37 -0400 > From: Alexandre CARMEL-VEILLEUX > To: minc-users at bic.mni.mcgill.ca > Cc: Samson ANTEL > Subject: [MINC-users] Minc 1.5.1 64-bit compatibility bug > > Hi, > > Minc 1.5.1 includes ParseArgv as part of libminc. This library > provides the argument parsing support for most libtools. rawtominc (and > probably others) misuse ParseArgv when dealing with constants. > > The offending code looks like: > > /* Argument table */ > ArgvInfo argTable[] = { > // ... snip ... > {"-nomodality", ARGV_CONSTANT, NULL, (char *) &modality, > "Do not store modality type in file."}, > "-pet", ARGV_CONSTANT, MI_PET, (char *) &modality, > "PET data."}, > {"-mri", ARGV_CONSTANT, MI_MRI, (char *) &modality, > "MRI data."}, > // ... snip ... > > In ParseArgv however the arguments gets converted to an int: > > case ARGV_CONSTANT: > *((int *) infoPtr->dst) = *((int*)(&infoPtr->src)); > break; > > On 64-bit platforms this causes the upper 32-bit of the pointers to be > dropped. > > On subsequent use by rawtominc, the whole thing breaks because rawtominc > still expects a pointer: > > /* Create the modality attribute */ > if (modality != NULL) { > varid = micreate_group_variable(cdfid, MIstudy); > (void) miattputstr(cdfid, varid, MImodality, modality); > } > > Output (with extra debugging, line offset off by 1 due to fprintf): > > (gdb) run test.mnc 60 256 192 -clobber -mri > Starting program: /localscratch/compile/minc-1.5.1/progs/rawtominc/rawtominc test.mnc 60 256 192 -clobber -mri > Reading symbols for shared libraries ++. done > miattputstr(cdfid, varid, MImodality, modality) where: > modality(int) = 200150 > modality(pointer) = 0x30dd6 > modality(actual pointer) = 0x100030dd6 > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x0000000000030dd0 > 0x00007fff80a3a0d0 in strlen () > (gdb) bt > #0 0x00007fff80a3a0d0 in strlen () > #1 0x000000010000cfe8 in miattputstr () > #2 0x0000000100001b1b in main (argc=7, argv=0x7fff5fbff488) at progs/rawtominc/rawtominc.c:636 > (gdb) > > I don't have access to fix this in the CVS. When this is dealt > with, I'll update my 64-bit os-x 10.5 tarball. > > Alex > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users From claude at bic.mni.mcgill.ca Tue Jul 22 14:33:57 2008 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Tue, 22 Jul 2008 14:33:57 -0400 (EDT) Subject: [MINC-users] Minc 1.5.1 64-bit compatibility bug Message-ID: <200807221833.m6MIXvvZ004520@yorick.bic.mni.mcgill.ca> Hi Alex, > Minc 1.5.1 includes ParseArgv as part of libminc. This library > provides the argument parsing support for most libtools. rawtominc (and > probably others) misuse ParseArgv when dealing with constants. Hmmm... let's see. MI_PET = "PET__" MI_MRI = "MRI__" char * modality; > The offending code looks like: > > /* Argument table */ > ArgvInfo argTable[] = { > // ... snip ... > {"-nomodality", ARGV_CONSTANT, NULL, (char *) &modality, > "Do not store modality type in file."}, > "-pet", ARGV_CONSTANT, MI_PET, (char *) &modality, > "PET data."}, > {"-mri", ARGV_CONSTANT, MI_MRI, (char *) &modality, > "MRI data."}, Shouldn't rawtominc.c use ARGV_STRING instead of ARGV_CONSTANT? These are strings, not integers. > // ... snip ... > > In ParseArgv however the arguments gets converted to an int: > > case ARGV_CONSTANT: > *((int *) infoPtr->dst) = *((int*)(&infoPtr->src)); > break; > > On 64-bit platforms this causes the upper 32-bit of the pointers to be > dropped. > > On subsequent use by rawtominc, the whole thing breaks because rawtominc > still expects a pointer: > > /* Create the modality attribute */ > if (modality != NULL) { > varid = micreate_group_variable(cdfid, MIstudy); > (void) miattputstr(cdfid, varid, MImodality, modality); > } > > Output (with extra debugging, line offset off by 1 due to fprintf): > > (gdb) run test.mnc 60 256 192 -clobber -mri > Starting program: /localscratch/compile/minc-1.5.1/progs/rawtominc/rawtominc test.mnc 60 256 192 -clobber -mri > Reading symbols for shared libraries ++. done > miattputstr(cdfid, varid, MImodality, modality) where: > modality(int) = 200150 > modality(pointer) = 0x30dd6 > modality(actual pointer) = 0x100030dd6 > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x0000000000030dd0 > 0x00007fff80a3a0d0 in strlen () > (gdb) bt > #0 0x00007fff80a3a0d0 in strlen () > #1 0x000000010000cfe8 in miattputstr () > #2 0x0000000100001b1b in main (argc=7, argv=0x7fff5fbff488) at progs/rawtominc/rawtominc.c:636 > (gdb) > > I don't have access to fix this in the CVS. When this is dealt > with, I'll update my 64-bit os-x 10.5 tarball. > > Alex > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From claude at bic.mni.mcgill.ca Tue Jul 22 14:38:17 2008 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Tue, 22 Jul 2008 14:38:17 -0400 (EDT) Subject: [MINC-users] Minc 1.5.1 64-bit compatibility bug References: <20080722135437.N18530@mrs.mni.mcgill.ca> Message-ID: <200807221838.m6MIcHjx004590@yorick.bic.mni.mcgill.ca> Alex, See my previous post. > > I forgot the "easy" fix: > > case ARGV_CONSTANT: > *((int *) infoPtr->dst) = *((int*)(&infoPtr->src)); > break; > > Becomes: > > case ARGV_CONSTANT: > *((long *) infoPtr->dst) = *((long*)(&infoPtr->src)); > break; MI_PET = "PET__" (5bytes + 1byte for \0) The above will get you 8 bytes (and the full string), but should clobber the infoPtr->help key follwing src in the struct. Use ARGV_STRING. Claude From acveilleux at mrs.mni.mcgill.ca Tue Jul 22 14:39:35 2008 From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX) Date: Tue, 22 Jul 2008 14:39:35 -0400 Subject: [MINC-users] Minc 1.5.1 64-bit compatibility bug In-Reply-To: <200807221833.m6MIXvvZ004520@yorick.bic.mni.mcgill.ca>; from claude@bic.mni.mcgill.ca on Tue, Jul 22, 2008 at 02:33:57PM -0400 References: <200807221833.m6MIXvvZ004520@yorick.bic.mni.mcgill.ca> Message-ID: <20080722143935.R18530@mrs.mni.mcgill.ca> On Tue, Jul 22, 2008 at 02:33:57PM -0400, Claude LEPAGE wrote: > > Shouldn't rawtominc.c use ARGV_STRING instead of ARGV_CONSTANT? These > are strings, not integers. ARGV_STRING expects that the next argument on the command-line should be a string. -mri is only a flag and doesn't expect an argument. The ParseArgv man page states: ARGV_STRING In this form, dst is treated as a pointer to a (char *); ParseArgv stores at *dst a pointer to the following argument, and discards the matching and following arguments from argv. Src is treated as an integer count: if its value is greater than 1, then that many arguments are processed and Dst is treated as an array pointer. Alex From acveilleux at mrs.mni.mcgill.ca Tue Jul 22 14:43:31 2008 From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX) Date: Tue, 22 Jul 2008 14:43:31 -0400 Subject: [MINC-users] Minc 1.5.1 64-bit compatibility bug In-Reply-To: <200807221838.m6MIcHjx004590@yorick.bic.mni.mcgill.ca>; from claude@bic.mni.mcgill.ca on Tue, Jul 22, 2008 at 02:38:17PM -0400 References: <20080722135437.N18530@mrs.mni.mcgill.ca> <200807221838.m6MIcHjx004590@yorick.bic.mni.mcgill.ca> Message-ID: <20080722144331.S18530@mrs.mni.mcgill.ca> On Tue, Jul 22, 2008 at 02:38:17PM -0400, Claude LEPAGE wrote: > > > > I forgot the "easy" fix: > > > > case ARGV_CONSTANT: > > *((int *) infoPtr->dst) = *((int*)(&infoPtr->src)); > > break; > > > > Becomes: > > > > case ARGV_CONSTANT: > > *((long *) infoPtr->dst) = *((long*)(&infoPtr->src)); > > break; > > MI_PET = "PET__" (5bytes + 1byte for \0) infoPtr->src contains the pointer to "PET__", not "PET__". This is the case where a Pointer is being passed as a "constant" argument. On 32-bit platform all works well because an int can contain a pointer. Alex > The above will get you 8 bytes (and the full string), but should clobber > the infoPtr->help key follwing src in the struct. > > Use ARGV_STRING. > > Claude > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users From baghdadi at phenogenomics.ca Wed Jul 23 11:24:24 2008 From: baghdadi at phenogenomics.ca (Leila Baghdadi) Date: Wed, 23 Jul 2008 11:24:24 -0400 Subject: [MINC-users] MINC convention for oblique imaging Message-ID: <1216826665.12330.20.camel@mouse17.phenogenomics.ca> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www2.bic.mni.mcgill.ca/pipermail/minc-users/attachments/20080723/ba41775f/attachment.txt From burt.crepeault at crulrg.ulaval.ca Wed Jul 23 15:16:17 2008 From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=) Date: Wed, 23 Jul 2008 15:16:17 -0400 Subject: [MINC-users] X Error of failed request: BadRequest Message-ID: Hi all, I just installed the Mac OS X binaries from here: http://www.bic.mni.mcgill.ca/software/distribution/osx.html over a fresh install of Leopard. When launching Register, I get: X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 128 (Apple-DRI) Minor opcode of failed request: 1 () Serial number of failed request: 16 Current serial number in output stream: 16 Anybody have any ideas what might be the cause? By the way, the above package is dated January 28, 2004, is there a newer one laying around? Would there be interest from the OS X community in getting a newer version since I'm pretty sure some of the tools have changed in the past 4.5 years? In other words, I'm willing to help doing the legwork but since I'm no guru in these matters, I need a little push to get started (where to get the source files, how to compile, how to make the package, etc.). Thanks, -- Burt Cr?peault Research Assistant Centre de Recherche de l'Universit? Laval - Robert-Giffard 418-663-5741, ext 6844 From acveilleux at mrs.mni.mcgill.ca Wed Jul 23 15:28:04 2008 From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX) Date: Wed, 23 Jul 2008 15:28:04 -0400 Subject: [MINC-users] X Error of failed request: BadRequest In-Reply-To: ; from burt.crepeault@crulrg.ulaval.ca on Wed, Jul 23, 2008 at 03:16:17PM -0400 References: Message-ID: <20080723152804.N18530@mrs.mni.mcgill.ca> Ouch. The place to get MINC is http://packages.bic.mni.mcgill.ca. This is where the newer versions are. The newer register/Display pacakges for OSX are native Aqua software and don't use X11 for display. Also, if you're installing on an intel mac, there's a 64-bit x86_84 leopard build there. Alex On Wed, Jul 23, 2008 at 03:16:17PM -0400, Burt Cr?peault wrote: > Date: Wed, 23 Jul 2008 15:16:17 -0400 > From: "Burt Cr?peault" > To: "MINC users mailing list" > Subject: [MINC-users] X Error of failed request: BadRequest > > Hi all, > > I just installed the Mac OS X binaries from here: > http://www.bic.mni.mcgill.ca/software/distribution/osx.html over a fresh > install of Leopard. > > When launching Register, I get: > > X Error of failed request: BadRequest (invalid request code or no such > operation) > Major opcode of failed request: 128 (Apple-DRI) > Minor opcode of failed request: 1 () > Serial number of failed request: 16 > Current serial number in output stream: 16 > > Anybody have any ideas what might be the cause? > > By the way, the above package is dated January 28, 2004, is there a newer > one laying around? Would there be interest from the OS X community in > getting a newer version since I'm pretty sure some of the tools have changed > in the past 4.5 years? In other words, I'm willing to help doing the legwork > but since I'm no guru in these matters, I need a little push to get started > (where to get the source files, how to compile, how to make the package, > etc.). > > Thanks, > > -- > Burt Cr?peault > Research Assistant > Centre de Recherche de l'Universit? Laval - Robert-Giffard > 418-663-5741, ext 6844 > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users From a.janke at gmail.com Wed Jul 23 20:04:12 2008 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 24 Jul 2008 10:04:12 +1000 Subject: [MINC-users] MINC convention for oblique imaging In-Reply-To: <1216826665.12330.20.camel@mouse17.phenogenomics.ca> References: <1216826665.12330.20.camel@mouse17.phenogenomics.ca> Message-ID: > By MINC definition, xyz dimensions are defined in patient coordinates Um maybe? :) I always was of the opinion that the world co-ordinates referred to the scanner. And thus 0,0,0 for a MRI machine is at the centre of the gradients and 0,0,0 on some PET machines is at the patients feet. > and direction cosines are recommended to be the identity matrix. If you add this into the mix then perhaps the top statement makes more sense. > Therefore, in an oblique dataset, do MINC xyz dimensions refer to > patient coordinates or MRI voxel coordinates? If the latter, is the MRI > convention of readout='x', phase encoding='y', and slab encoding='z' > also used by MINC? No, and as far as I am aware there is no way you can guarantee that phase will be y and slab in z. I think this sort of thinig is what gets "other" file formats in trouble. Yes most imaging sequences might use this order but there is no way that you can guarantee this. I certainly remember going through all sorts of contortions converting bruker format data in which this sort of thing is/can be a convention. > If the latter, then how to reconcile the > inconsistency in coordinate definition between 'cor','sag' and 'trans' > on the one hand and 'oblique' on the other? The answer to this is to just think of the MINC world space as a sampling of the scanner, if a patient head happens to be in there then good and well. :) Of course this does beg the question of why there are -coronal type options in MINC but my answer to this would be "ease of use for 90% of users" -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From baghdadi at phenogenomics.ca Thu Jul 24 13:22:13 2008 From: baghdadi at phenogenomics.ca (Leila Baghdadi) Date: Thu, 24 Jul 2008 13:22:13 -0400 Subject: [MINC-users] [Fwd: Re: [Fwd: Re: MINC convention for oblique imaging]] Message-ID: <1216920133.12330.26.camel@mouse17.phenogenomics.ca> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www2.bic.mni.mcgill.ca/pipermail/minc-users/attachments/20080724/c36fbe91/attachment.txt From a.janke at gmail.com Thu Jul 24 22:23:36 2008 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 25 Jul 2008 12:23:36 +1000 Subject: [MINC-users] Minc 1.5.1 64-bit compatibility bug In-Reply-To: <20080722135437.N18530@mrs.mni.mcgill.ca> References: <20080722135437.N18530@mrs.mni.mcgill.ca> Message-ID: On Wed, Jul 23, 2008 at 03:54, Alexandre CARMEL-VEILLEUX wrote: > Minc 1.5.1 includes ParseArgv as part of libminc. This library > provides the argument parsing support for most libtools. rawtominc (and > probably others) misuse ParseArgv when dealing with constants. > > Hi Alex, Thanks for the report. However you lost me a bit as I cant reproduce this on my 64 bit Ubuntu hardy machine. Is this an OSX specific error or have I missed something. I checked out a 1.5.x version of MINC with the code you described and rawtominc -mri works fine. I actually used something like this: rawtominc -mri -short test.mnc 10 10 10 < /dev/zero and all was good. Still I admit that the code you point to should result in a problem but I dont see it. In any case I have it ready to check in against the 1.5.X branch. Still this begs the question of why are you still sticking with 1.5.X? -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From burt.crepeault at crulrg.ulaval.ca Mon Jul 28 14:03:40 2008 From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=) Date: Mon, 28 Jul 2008 14:03:40 -0400 Subject: [MINC-users] MINC2 on Mac OS X 10.5 Message-ID: Hi again, After downloading and installing all the packages from here on a fresh install of Leopard, I'm still having problems. On most of them I get this error message: dyld: Library not loaded: /usr/local/lib/libhdf5.0.dylib Referenced from: /usr/local/bic/bin/inormalize Reason: image not found Trace/BPT trap (libhdf5.0.dylib is nowhere to be found on the Mac). I also got this error message attempting nu_correct: Can't locate MNI/Startup.pm in @INC (@INC contains: /Users/Simon/lib/perl /System/Library/Perl/5.8.8/darwin-thread-multi-2level /System/Library/Perl/5.8.8 /Library/Perl/5.8.8/darwin-thread-multi-2level /Library/Perl/5.8.8 /Library/Perl /Network/Library/Perl/5.8.8/darwin-thread-multi-2level /Network/Library/Perl/5.8.8 /Network/Library/Perl /System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level /System/Library/Perl/Extras/5.8.8 /Library/Perl/5.8.6 /Library/Perl/5.8.1 .) at /usr/local/bic/bin/nu_correct line 37. BEGIN failed--compilation aborted at /usr/local/bic/bin/nu_correct line 37. Obviously I'm missing some libraries and/or have wrongly set environment variables. What are the dependencies for the minc packages to install and run properly? Is there a readme somewhere about this? I looked all over the wiki but must admit, coming from the outside, I feel kind of lost in there. Thanks, -- Burt Cr?peault Research Assistant Centre de Recherche de l'Universit? Laval - Robert-Giffard 418-663-5741, ext 6844 From acveilleux at mrs.mni.mcgill.ca Mon Jul 28 14:26:26 2008 From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX) Date: Mon, 28 Jul 2008 14:26:26 -0400 Subject: [MINC-users] MINC2 on Mac OS X 10.5 In-Reply-To: ; from burt.crepeault@crulrg.ulaval.ca on Mon, Jul 28, 2008 at 02:03:40PM -0400 References: Message-ID: <20080728142626.F18530@mrs.mni.mcgill.ca> Andrew Janke's 10.5 packages assume that you have the following already installed: libhdf5 libnetcdf He installs those with Fink. (http://www.finkproject.org/) Alex On Mon, Jul 28, 2008 at 02:03:40PM -0400, Burt Cr?peault wrote: > Date: Mon, 28 Jul 2008 14:03:40 -0400 > From: "Burt Cr?peault" > To: "MINC users mailing list" > Subject: [MINC-users] MINC2 on Mac OS X 10.5 > > Hi again, > > After downloading and installing all the packages from here on a fresh > install of Leopard, I'm still having problems. On most of them I get this > error message: > > dyld: Library not loaded: /usr/local/lib/libhdf5.0.dylib > Referenced from: /usr/local/bic/bin/inormalize > Reason: image not found > Trace/BPT trap > > (libhdf5.0.dylib is nowhere to be found on the Mac). > > I also got this error message attempting nu_correct: > > Can't locate MNI/Startup.pm in @INC (@INC contains: /Users/Simon/lib/perl > /System/Library/Perl/5.8.8/darwin-thread-multi-2level > /System/Library/Perl/5.8.8 /Library/Perl/5.8.8/darwin-thread-multi-2level > /Library/Perl/5.8.8 /Library/Perl > /Network/Library/Perl/5.8.8/darwin-thread-multi-2level > /Network/Library/Perl/5.8.8 /Network/Library/Perl > /System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level > /System/Library/Perl/Extras/5.8.8 /Library/Perl/5.8.6 /Library/Perl/5.8.1 .) > at /usr/local/bic/bin/nu_correct line 37. > BEGIN failed--compilation aborted at /usr/local/bic/bin/nu_correct line 37. > > Obviously I'm missing some libraries and/or have wrongly set environment > variables. > > What are the dependencies for the minc packages to install and run properly? > Is there a readme somewhere about this? I looked all over the wiki but must > admit, coming from the outside, I feel kind of lost in there. > > Thanks, > > -- > Burt Cr?peault > Research Assistant > Centre de Recherche de l'Universit? Laval - Robert-Giffard > 418-663-5741, ext 6844 > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users From burt.crepeault at crulrg.ulaval.ca Tue Jul 29 10:58:49 2008 From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=) Date: Tue, 29 Jul 2008 10:58:49 -0400 Subject: [MINC-users] MINC2 on Mac OS X 10.5 In-Reply-To: References: <20080728142626.F18530@mrs.mni.mcgill.ca> Message-ID: Ok, got a little further but not much. What I did so far on a fresh Leopard install: - installed all the packages from http://packages.bic.mni.mcgill.ca/osx-10.5/ - installed fink - from a terminal: # sudo apt-get install hdf5 # sudo apt-get install netcdf # registerdyld: Library not loaded: /usr/local/lib/libhdf5.0.dylib Referenced from: /usr/local/bic/bin/register Reason: image not found # sudo ln -sf /sw/lib/libhdf5.0.0.0.dylib /usr/local/lib/libhdf5.0.dylib # registerdyld: Library not loaded: /usr/local/lib/libhdf5.0.dylib Referenced from: /usr/local/bic/bin/register Reason: no suitable image found. Did find: /usr/local/lib/libhdf5.0.dylib: mach-o, but wrong architecture /usr/local/lib/libhdf5.0.dylib: mach-o, but wrong architecture - tried installing hdf5 through macports, got same errors Is this a 32-bit vs. 64-bit error? Should I install Alex's 64-bit package found at http://packages.bic.mni.mcgill.ca/osx-10.5-x86_64-alex/ ? Burt. On Mon, Jul 28, 2008 at 2:26 PM, Alexandre CARMEL-VEILLEUX < acveilleux at mrs.mni.mcgill.ca> wrote: > Andrew Janke's 10.5 packages assume that you have the following > already installed: > > libhdf5 > libnetcdf > > He installs those with Fink. (http://www.finkproject.org/) > > Alex > > On Mon, Jul 28, 2008 at 02:03:40PM -0400, Burt Cr?peault wrote: > > Date: Mon, 28 Jul 2008 14:03:40 -0400 > > From: "Burt Cr?peault" > > To: "MINC users mailing list" > > Subject: [MINC-users] MINC2 on Mac OS X 10.5 > > > > Hi again, > > > > After downloading and installing all the packages from here on a fresh > > install of Leopard, I'm still having problems. On most of them I get this > > error message: > > > > dyld: Library not loaded: /usr/local/lib/libhdf5.0.dylib > > Referenced from: /usr/local/bic/bin/inormalize > > Reason: image not found > > Trace/BPT trap > > > > (libhdf5.0.dylib is nowhere to be found on the Mac). > > > > I also got this error message attempting nu_correct: > > > > Can't locate MNI/Startup.pm in @INC (@INC contains: /Users/Simon/lib/perl > > /System/Library/Perl/5.8.8/darwin-thread-multi-2level > > /System/Library/Perl/5.8.8 /Library/Perl/5.8.8/darwin-thread-multi-2level > > /Library/Perl/5.8.8 /Library/Perl > > /Network/Library/Perl/5.8.8/darwin-thread-multi-2level > > /Network/Library/Perl/5.8.8 /Network/Library/Perl > > /System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level > > /System/Library/Perl/Extras/5.8.8 /Library/Perl/5.8.6 /Library/Perl/5.8.1 > .) > > at /usr/local/bic/bin/nu_correct line 37. > > BEGIN failed--compilation aborted at /usr/local/bic/bin/nu_correct line > 37. > > > > Obviously I'm missing some libraries and/or have wrongly set environment > > variables. > > > > What are the dependencies for the minc packages to install and run > properly? > > Is there a readme somewhere about this? I looked all over the wiki but > must > > admit, coming from the outside, I feel kind of lost in there. > > > > Thanks, > > > > -- > > Burt Cr?peault > > Research Assistant > > Centre de Recherche de l'Universit? Laval - Robert-Giffard > > 418-663-5741, ext 6844 > > _______________________________________________ > > MINC-users at bic.mni.mcgill.ca > > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- Burt Cr?peault Research Assistant Centre de Recherche de l'Universit? Laval - Robert-Giffard 418-663-5741, ext 6844 > -- Burt Cr?peault Research Assistant Centre de Recherche de l'Universit? Laval - Robert-Giffard 418-663-5741, ext 6844 From acveilleux at mrs.mni.mcgill.ca Tue Jul 29 11:17:39 2008 From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX) Date: Tue, 29 Jul 2008 11:17:39 -0400 Subject: [MINC-users] MINC2 on Mac OS X 10.5 In-Reply-To: ; from burt.crepeault@crulrg.ulaval.ca on Tue, Jul 29, 2008 at 10:58:49AM -0400 References: <20080728142626.F18530@mrs.mni.mcgill.ca> Message-ID: <20080729111739.I18530@mrs.mni.mcgill.ca> It could be an intel vs. PPC issue as well. What's the output of: file /sw/lib/libhdf5.0.0.0.dylib and file /usr/local/bic/bin/register My "package" is a tar-ball of /usr/local on my build machine. All dependencies are compiled and in the various subdirectory. In the package, rawtominc (at least for the MINC 1.5 version) is broken due to a 32 vs 64 bit bug. My build will only run on an x86_64 architecture 10.5 mac. Alex On Tue, Jul 29, 2008 at 10:58:49AM -0400, Burt Cr?peault wrote: > Date: Tue, 29 Jul 2008 10:58:49 -0400 > From: "Burt Cr?peault" > To: "MINC users mailing list" > Subject: Re: [MINC-users] MINC2 on Mac OS X 10.5 > > Ok, got a little further but not much. What I did so far on a fresh Leopard > install: > > - installed all the packages from > http://packages.bic.mni.mcgill.ca/osx-10.5/ > - installed fink > - from a terminal: > # sudo apt-get install hdf5 > # sudo apt-get install netcdf > # registerdyld: Library not loaded: /usr/local/lib/libhdf5.0.dylib > Referenced from: /usr/local/bic/bin/register > Reason: image not found > # sudo ln -sf /sw/lib/libhdf5.0.0.0.dylib /usr/local/lib/libhdf5.0.dylib > # registerdyld: Library not loaded: /usr/local/lib/libhdf5.0.dylib > Referenced from: /usr/local/bic/bin/register > Reason: no suitable image found. Did find: > /usr/local/lib/libhdf5.0.dylib: mach-o, but wrong architecture > /usr/local/lib/libhdf5.0.dylib: mach-o, but wrong architecture > - tried installing hdf5 through macports, got same errors > > Is this a 32-bit vs. 64-bit error? Should I install Alex's 64-bit package > found at http://packages.bic.mni.mcgill.ca/osx-10.5-x86_64-alex/ ? > > Burt. > > > On Mon, Jul 28, 2008 at 2:26 PM, Alexandre CARMEL-VEILLEUX < > acveilleux at mrs.mni.mcgill.ca> wrote: > > > Andrew Janke's 10.5 packages assume that you have the following > > already installed: > > > > libhdf5 > > libnetcdf > > > > He installs those with Fink. (http://www.finkproject.org/) > > > > Alex > > > > On Mon, Jul 28, 2008 at 02:03:40PM -0400, Burt Cr?peault wrote: > > > Date: Mon, 28 Jul 2008 14:03:40 -0400 > > > From: "Burt Cr?peault" > > > To: "MINC users mailing list" > > > Subject: [MINC-users] MINC2 on Mac OS X 10.5 > > > > > > Hi again, > > > > > > After downloading and installing all the packages from here on a fresh > > > install of Leopard, I'm still having problems. On most of them I get this > > > error message: > > > > > > dyld: Library not loaded: /usr/local/lib/libhdf5.0.dylib > > > Referenced from: /usr/local/bic/bin/inormalize > > > Reason: image not found > > > Trace/BPT trap > > > > > > (libhdf5.0.dylib is nowhere to be found on the Mac). > > > > > > I also got this error message attempting nu_correct: > > > > > > Can't locate MNI/Startup.pm in @INC (@INC contains: /Users/Simon/lib/perl > > > /System/Library/Perl/5.8.8/darwin-thread-multi-2level > > > /System/Library/Perl/5.8.8 /Library/Perl/5.8.8/darwin-thread-multi-2level > > > /Library/Perl/5.8.8 /Library/Perl > > > /Network/Library/Perl/5.8.8/darwin-thread-multi-2level > > > /Network/Library/Perl/5.8.8 /Network/Library/Perl > > > /System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level > > > /System/Library/Perl/Extras/5.8.8 /Library/Perl/5.8.6 /Library/Perl/5.8.1 > > .) > > > at /usr/local/bic/bin/nu_correct line 37. > > > BEGIN failed--compilation aborted at /usr/local/bic/bin/nu_correct line > > 37. > > > > > > Obviously I'm missing some libraries and/or have wrongly set environment > > > variables. > > > > > > What are the dependencies for the minc packages to install and run > > properly? > > > Is there a readme somewhere about this? I looked all over the wiki but > > must > > > admit, coming from the outside, I feel kind of lost in there. > > > > > > Thanks, > > > > > > -- > > > Burt Cr?peault > > > Research Assistant > > > Centre de Recherche de l'Universit? Laval - Robert-Giffard > > > 418-663-5741, ext 6844 > > > _______________________________________________ > > > MINC-users at bic.mni.mcgill.ca > > > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > _______________________________________________ > > MINC-users at bic.mni.mcgill.ca > > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > -- > Burt Cr?peault > Research Assistant > Centre de Recherche de l'Universit? Laval - Robert-Giffard > 418-663-5741, ext 6844 > > > > > > -- > Burt Cr?peault > Research Assistant > Centre de Recherche de l'Universit? Laval - Robert-Giffard > 418-663-5741, ext 6844 > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users From bouffard at bic.mni.mcgill.ca Tue Jul 29 11:38:36 2008 From: bouffard at bic.mni.mcgill.ca (Marc BOUFFARD) Date: Tue, 29 Jul 2008 11:38:36 -0400 Subject: [MINC-users] determinant of non-linear local deformation fields Message-ID: Hello, I have a question about deformation grids obtained from non-linear registration using nlpfit. These grids contain the 3D displacements at each voxel applied to the source to match the template or to the template to match the source? Now if the determinant is calculated from those grids with mincblob and it is found that voxel x has a value greater than 1. Does this mean the region in the neighborhood of x has expanded relative to the source or relative to the target? In a further step, to obtain modulated VBM data should the standard VBM data be multiplied by the determinant of the Jacobian matrix or its inverse? From burt.crepeault at crulrg.ulaval.ca Tue Jul 29 11:39:43 2008 From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=) Date: Tue, 29 Jul 2008 11:39:43 -0400 Subject: [MINC-users] MINC2 on Mac OS X 10.5 In-Reply-To: <20080729111739.I18530@mrs.mni.mcgill.ca> References: <20080728142626.F18530@mrs.mni.mcgill.ca> <20080729111739.I18530@mrs.mni.mcgill.ca> Message-ID: # file /sw/lib/libhdf5.0.0.0.dylib /sw/lib/libhdf5.0.0.0.dylib: Mach-O dynamically linked shared library i386 # file /usr/local/bic/bin/register /usr/local/bic/bin/register: Mach-O 64-bit executable x86_64 On Tue, Jul 29, 2008 at 11:17 AM, Alexandre CARMEL-VEILLEUX < acveilleux at mrs.mni.mcgill.ca> wrote: > It could be an intel vs. PPC issue as well. What's the output of: > > file /sw/lib/libhdf5.0.0.0.dylib > > and > > file /usr/local/bic/bin/register > > My "package" is a tar-ball of /usr/local on my build machine. All > dependencies are compiled and in the various subdirectory. In the > package, rawtominc (at least for the MINC 1.5 version) is broken > due to a 32 vs 64 bit bug. My build will only run on an x86_64 > architecture 10.5 mac. > > Alex > > On Tue, Jul 29, 2008 at 10:58:49AM -0400, Burt Cr?peault wrote: > > Date: Tue, 29 Jul 2008 10:58:49 -0400 > > From: "Burt Cr?peault" > > To: "MINC users mailing list" > > Subject: Re: [MINC-users] MINC2 on Mac OS X 10.5 > > > > Ok, got a little further but not much. What I did so far on a fresh > Leopard > > install: > > > > - installed all the packages from > > http://packages.bic.mni.mcgill.ca/osx-10.5/ > > - installed fink > > - from a terminal: > > # sudo apt-get install hdf5 > > # sudo apt-get install netcdf > > # registerdyld: Library not loaded: /usr/local/lib/libhdf5.0.dylib > > Referenced from: /usr/local/bic/bin/register > > Reason: image not found > > # sudo ln -sf /sw/lib/libhdf5.0.0.0.dylib /usr/local/lib/libhdf5.0.dylib > > # registerdyld: Library not loaded: /usr/local/lib/libhdf5.0.dylib > > Referenced from: /usr/local/bic/bin/register > > Reason: no suitable image found. Did find: > > /usr/local/lib/libhdf5.0.dylib: mach-o, but wrong architecture > > /usr/local/lib/libhdf5.0.dylib: mach-o, but wrong architecture > > - tried installing hdf5 through macports, got same errors > > > > Is this a 32-bit vs. 64-bit error? Should I install Alex's 64-bit package > > found at http://packages.bic.mni.mcgill.ca/osx-10.5-x86_64-alex/ ? > > > > Burt. > > > > > > On Mon, Jul 28, 2008 at 2:26 PM, Alexandre CARMEL-VEILLEUX < > > acveilleux at mrs.mni.mcgill.ca> wrote: > > > > > Andrew Janke's 10.5 packages assume that you have the following > > > already installed: > > > > > > libhdf5 > > > libnetcdf > > > > > > He installs those with Fink. (http://www.finkproject.org/) > > > > > > Alex > > > > > > On Mon, Jul 28, 2008 at 02:03:40PM -0400, Burt Cr?peault wrote: > > > > Date: Mon, 28 Jul 2008 14:03:40 -0400 > > > > From: "Burt Cr?peault" > > > > To: "MINC users mailing list" > > > > Subject: [MINC-users] MINC2 on Mac OS X 10.5 > > > > > > > > Hi again, > > > > > > > > After downloading and installing all the packages from here on a > fresh > > > > install of Leopard, I'm still having problems. On most of them I get > this > > > > error message: > > > > > > > > dyld: Library not loaded: /usr/local/lib/libhdf5.0.dylib > > > > Referenced from: /usr/local/bic/bin/inormalize > > > > Reason: image not found > > > > Trace/BPT trap > > > > > > > > (libhdf5.0.dylib is nowhere to be found on the Mac). > > > > > > > > I also got this error message attempting nu_correct: > > > > > > > > Can't locate MNI/Startup.pm in @INC (@INC contains: > /Users/Simon/lib/perl > > > > /System/Library/Perl/5.8.8/darwin-thread-multi-2level > > > > /System/Library/Perl/5.8.8 > /Library/Perl/5.8.8/darwin-thread-multi-2level > > > > /Library/Perl/5.8.8 /Library/Perl > > > > /Network/Library/Perl/5.8.8/darwin-thread-multi-2level > > > > /Network/Library/Perl/5.8.8 /Network/Library/Perl > > > > /System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level > > > > /System/Library/Perl/Extras/5.8.8 /Library/Perl/5.8.6 > /Library/Perl/5.8.1 > > > .) > > > > at /usr/local/bic/bin/nu_correct line 37. > > > > BEGIN failed--compilation aborted at /usr/local/bic/bin/nu_correct > line > > > 37. > > > > > > > > Obviously I'm missing some libraries and/or have wrongly set > environment > > > > variables. > > > > > > > > What are the dependencies for the minc packages to install and run > > > properly? > > > > Is there a readme somewhere about this? I looked all over the wiki > but > > > must > > > > admit, coming from the outside, I feel kind of lost in there. > > > > > > > > Thanks, > > > > > > > > -- > > > > Burt Cr?peault > > > > Research Assistant > > > > Centre de Recherche de l'Universit? Laval - Robert-Giffard > > > > 418-663-5741, ext 6844 > > > > _______________________________________________ > > > > MINC-users at bic.mni.mcgill.ca > > > > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > _______________________________________________ > > > MINC-users at bic.mni.mcgill.ca > > > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > > > > > > > > > -- > > Burt Cr?peault > > Research Assistant > > Centre de Recherche de l'Universit? Laval - Robert-Giffard > > 418-663-5741, ext 6844 > > > > > > > > > > > -- > > Burt Cr?peault > > Research Assistant > > Centre de Recherche de l'Universit? Laval - Robert-Giffard > > 418-663-5741, ext 6844 > > _______________________________________________ > > MINC-users at bic.mni.mcgill.ca > > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- Burt Cr?peault Research Assistant Centre de Recherche de l'Universit? Laval - Robert-Giffard 418-663-5741, ext 6844 From acveilleux at mrs.mni.mcgill.ca Tue Jul 29 11:50:13 2008 From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX) Date: Tue, 29 Jul 2008 11:50:13 -0400 Subject: [MINC-users] MINC2 on Mac OS X 10.5 In-Reply-To: ; from burt.crepeault@crulrg.ulaval.ca on Tue, Jul 29, 2008 at 11:39:43AM -0400 References: <20080728142626.F18530@mrs.mni.mcgill.ca> <20080729111739.I18530@mrs.mni.mcgill.ca> Message-ID: <20080729115013.K18530@mrs.mni.mcgill.ca> On Tue, Jul 29, 2008 at 11:39:43AM -0400, Burt Cr?peault wrote: > > # file /sw/lib/libhdf5.0.0.0.dylib > /sw/lib/libhdf5.0.0.0.dylib: Mach-O dynamically linked shared library i386 > # file /usr/local/bic/bin/register > /usr/local/bic/bin/register: Mach-O 64-bit executable x86_64 There's your problem... You need the 64-bit version of the libs. You can pluck them out of my tarball. Or go through the trouble of building them. One of them (hdf5?) will require you to rebuild the autoconf/automake pipeline since it can't link 64-bit on mac. You can also reuild the minc stuff in 32-bit, it's pretty straight forward. Takes about 2 or 3 hours to build most of it. Alex From burt.crepeault at crulrg.ulaval.ca Tue Jul 29 12:15:37 2008 From: burt.crepeault at crulrg.ulaval.ca (=?ISO-8859-1?Q?Burt_Cr=E9peault?=) Date: Tue, 29 Jul 2008 12:15:37 -0400 Subject: [MINC-users] MINC2 on Mac OS X 10.5 In-Reply-To: <20080729115013.K18530@mrs.mni.mcgill.ca> References: <20080728142626.F18530@mrs.mni.mcgill.ca> <20080729111739.I18530@mrs.mni.mcgill.ca> <20080729115013.K18530@mrs.mni.mcgill.ca> Message-ID: Thanks Alex, I simply copied the full content of your 64-bit tarball into /usr/local/ and everything appears to be working fine. Wished I had tried that first thing... ;) For future Mac OS X 10.5 users, here's what I did, step by step: - downloaded bic_tools.tar.gz from http://packages.bic.mni.mcgill.ca/osx-10.5-x86_64-alex/ and saved to the desktop - double-clicked bic_tools.tar.gz to unzip, untar it - opened a terminal window - # sudo mkdir /usr/local - # sudo cp -R ~/Desktop/bic_tools/* /usr/local/ Cheers, Burt. On Tue, Jul 29, 2008 at 11:50 AM, Alexandre CARMEL-VEILLEUX < acveilleux at mrs.mni.mcgill.ca> wrote: > On Tue, Jul 29, 2008 at 11:39:43AM -0400, Burt Cr?peault wrote: > > > > # file /sw/lib/libhdf5.0.0.0.dylib > > /sw/lib/libhdf5.0.0.0.dylib: Mach-O dynamically linked shared library > i386 > > # file /usr/local/bic/bin/register > > /usr/local/bic/bin/register: Mach-O 64-bit executable x86_64 > > There's your problem... You need the 64-bit version of the libs. > You can pluck them out of my tarball. Or go through the trouble of building > them. One of them (hdf5?) will require you to rebuild the autoconf/automake > pipeline since it can't link 64-bit on mac. > > You can also reuild the minc stuff in 32-bit, it's pretty straight > forward. Takes about 2 or 3 hours to build most of it. > > Alex > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > -- Burt Cr?peault Research Assistant Centre de Recherche de l'Universit? Laval - Robert-Giffard 418-663-5741, ext 6844 From laurence at bic.mni.mcgill.ca Tue Jul 29 13:10:02 2008 From: laurence at bic.mni.mcgill.ca (Laurence MERCIER) Date: Tue, 29 Jul 2008 13:10:02 -0400 Subject: [MINC-users] reference for Display and Register Message-ID: Hello dear minc users, I am writing an article in which I mention Display and Register. I would like to know if there is an article or a tech report that describes these tools that I could use as reference? Thank you for your help! Laurence __________________________________ Laurence Mercier, PhD student McConnell Brain Imaging Center Montreal Neurological Institute 3801 University St, room: WB-320 Montreal (QC), H3A 2B4 CANADA tel: +1 514.398.1573 fax: +1 514.398.2975 __________________________________ From james.gibbon at nottingham.ac.uk Wed Jul 30 05:08:24 2008 From: james.gibbon at nottingham.ac.uk (James Gibbon) Date: Wed, 30 Jul 2008 10:08:24 +0100 Subject: [MINC-users] MINC2 on Mac OS X 10.5 In-Reply-To: References: <20080728142626.F18530@mrs.mni.mcgill.ca> <20080729111739.I18530@mrs.mni.mcgill.ca> <20080729115013.K18530@mrs.mni.mcgill.ca> Message-ID: <20080730100824.64eb6331.james.gibbon@nottingham.ac.uk> On Tue, 29 Jul 2008 12:15:37 -0400 "Burt Cr?peault" wrote: > > For future Mac OS X 10.5 users, here's what I did, step by step: > > - downloaded bic_tools.tar.gz from > http://packages.bic.mni.mcgill.ca/osx-10.5-x86_64-alex/ and saved to the > desktop > - double-clicked bic_tools.tar.gz to unzip, untar it > - opened a terminal window > - # sudo mkdir /usr/local > - # sudo cp -R ~/Desktop/bic_tools/* /usr/local/ > You could also do, in a terminal following downloading: sudo -s mkdir /usr/local cd /usr/local tar xzf ~/Desktop/bic_tools.tar.gz -- System Administrator ------------------------ Brain and Body Centre University of Nottingham Nottingham NG7 2RD +44 115 846 8255 This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From sorench at gmail.com Thu Jul 31 01:49:11 2008 From: sorench at gmail.com (Soren Christensen) Date: Thu, 31 Jul 2008 15:49:11 +1000 Subject: [MINC-users] inf values in MINC files Message-ID: Hi, I have some parameter maps that may contain 'inf' values. I noticed they fail to render in Display and thought of writing a wrapper that replaces inf with the highest non-inf value in the dataset - just for display purposes. I wanted to use mincstats -max to determine presence of infs, but it does not identify inf as the max value - is there another way to tease out these inf voxels? Should mincmath handle infs? I don't seem to be able to find them using -eq inf either. Cheers Soren From a.janke at gmail.com Thu Jul 31 01:57:58 2008 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 31 Jul 2008 15:57:58 +1000 Subject: [MINC-users] inf values in MINC files In-Reply-To: References: Message-ID: Hi Soren, Without checking I think what you want is: mincmath -isnan fred.mnc infmask.mnc a On Thu, Jul 31, 2008 at 15:49, Soren Christensen wrote: > Hi, > I have some parameter maps that may contain 'inf' values. I noticed they > fail to render in Display and thought of writing a wrapper that replaces inf > with the highest non-inf value in the dataset - just for display purposes. I > wanted to use mincstats -max to determine presence of infs, but it does > not identify inf as the max value - is there another way to tease out > these inf voxels? > Should mincmath handle infs? I don't seem to be able to find them using > -eq inf either. > > Cheers > Soren > _______________________________________________ > 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 sorench at gmail.com Thu Jul 31 02:07:18 2008 From: sorench at gmail.com (Soren Christensen) Date: Thu, 31 Jul 2008 16:07:18 +1000 Subject: [MINC-users] inf values in MINC files In-Reply-To: References: Message-ID: Hi Andrew, That seems to not find the infs. Just get an all 0 image. If you use EMMA and read into matlab, and imagesc(isinf(imagedata)) correctly shows the inf voxels. Cheers Soren On Thu, Jul 31, 2008 at 3:57 PM, Andrew Janke wrote: > Hi Soren, > > Without checking I think what you want is: > > mincmath -isnan fred.mnc infmask.mnc > > a > > > On Thu, Jul 31, 2008 at 15:49, Soren Christensen > wrote: > > Hi, > > I have some parameter maps that may contain 'inf' values. I noticed they > > fail to render in Display and thought of writing a wrapper that replaces > inf > > with the highest non-inf value in the dataset - just for display > purposes. I > > wanted to use mincstats -max to determine presence of infs, but it does > > not identify inf as the max value - is there another way to tease out > > these inf voxels? > > Should mincmath handle infs? I don't seem to be able to find them using > > -eq inf either. > > > > Cheers > > Soren > > _______________________________________________ > > 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 claude at bic.mni.mcgill.ca Thu Jul 31 08:44:15 2008 From: claude at bic.mni.mcgill.ca (Claude LEPAGE) Date: Thu, 31 Jul 2008 08:44:15 -0400 (EDT) Subject: [MINC-users] inf values in MINC files Message-ID: <200807311244.m6VCiFhd1249280@yorick.bic.mni.mcgill.ca> Nothing like "minccalc -help"... Try -zero or -illegal_value . There are similar options too to treat illegal numbers. > Hi, > I have some parameter maps that may contain 'inf' values. I noticed they > fail to render in Display and thought of writing a wrapper that replaces inf > with the highest non-inf value in the dataset - just for display purposes. I > wanted to use mincstats -max to determine presence of infs, but it does > not identify inf as the max value - is there another way to tease out > these inf voxels? > Should mincmath handle infs? I don't seem to be able to find them using > -eq inf either. > > Cheers > Soren > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From sorench at gmail.com Thu Jul 31 19:54:20 2008 From: sorench at gmail.com (Soren Christensen) Date: Fri, 1 Aug 2008 09:54:20 +1000 Subject: [MINC-users] inf values in MINC files In-Reply-To: <200807311244.m6VCiFhd1249280@yorick.bic.mni.mcgill.ca> References: <200807311244.m6VCiFhd1249280@yorick.bic.mni.mcgill.ca> Message-ID: Thanks for tip. I tried minccalc -clobber -illegal_value 1 -expression "A[0]*0" TTPfit.mnc test.mnc hoping that all 0*inf operations would result in 1 in the resulting image (usually this would be a NaN). the resulting image i ranged 0-0 I also tried a few other variants but either end up with a 0-inf or 0-0 ranged image. Finally, minccalc -clobber -expression "A[0]>100" TTPfit.mnc test.mnc Works because 100 is the largest non-infinite value - I guess this opens a way to do what I want be first determining max and then doing the above. If there is a smarter way I'd like to know. Regards Soren On Thu, Jul 31, 2008 at 10:44 PM, Claude LEPAGE wrote: > Nothing like "minccalc -help"... > Try -zero or -illegal_value . There are similar > options too to treat illegal numbers. > > > > Hi, > > I have some parameter maps that may contain 'inf' values. I noticed they > > fail to render in Display and thought of writing a wrapper that replaces > inf > > with the highest non-inf value in the dataset - just for display > purposes. I > > wanted to use mincstats -max to determine presence of infs, but it does > > not identify inf as the max value - is there another way to tease out > > these inf voxels? > > Should mincmath handle infs? I don't seem to be able to find them using > > -eq inf either. > > > > Cheers > > Soren > > _______________________________________________ > > MINC-users at bic.mni.mcgill.ca > > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users >