From michael.a.yee at vanderbilt.edu Tue Jul 7 12:58:43 2009 From: michael.a.yee at vanderbilt.edu (Michael Alexander Yee) Date: Tue, 7 Jul 2009 11:58:43 -0500 Subject: [MINC-users] Rawtominc problems Message-ID: I am trying to convert .img files (float) to .mnc using rawtominc, but I keep getting a "premature end of file" message and mincheader shows that several slices do not have a corresponding min/max. I have written: cat name.img | rawtominc -float -ofloat -scan_range -xstep 2 -ystep 2 -zstep 2 -xstart 46 -ystart 64 -zstart 37 name.mnc 91 109 91 -clobber -osigned Any idea what the problem is? Michael From sorench at gmail.com Tue Jul 7 17:32:49 2009 From: sorench at gmail.com (Soren Christensen) Date: Wed, 8 Jul 2009 07:32:49 +1000 Subject: [MINC-users] Rawtominc problems In-Reply-To: References: Message-ID: Hi, I am not sure -osigned has any effect with -ofloat but that is probably not the problem. Does the file size equal the product of the dimensions * sizeof(float)? Soren On Wed, Jul 8, 2009 at 2:58 AM, Michael Alexander Yee < michael.a.yee at vanderbilt.edu> wrote: > I am trying to convert .img files (float) to .mnc using rawtominc, but I > keep getting a "premature end of file" message and mincheader shows that > several slices do not have a corresponding min/max. > > I have written: > > cat name.img | rawtominc -float -ofloat -scan_range -xstep 2 -ystep 2 > -zstep > 2 -xstart 46 -ystart 64 -zstart 37 name.mnc 91 109 91 -clobber -osigned > > Any idea what the problem is? > > Michael > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From a.janke at gmail.com Tue Jul 7 21:03:16 2009 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 8 Jul 2009 11:03:16 +1000 Subject: [MINC-users] Rawtominc problems In-Reply-To: References: Message-ID: Hi Michael, On Wed, Jul 8, 2009 at 02:58, Michael Alexander Yee wrote: > I am trying to convert .img files (float) to .mnc using rawtominc, but I > keep getting a "premature end of file" message and mincheader shows that > several slices do not have a corresponding min/max. > > I have written: > > cat name.img | rawtominc -float -ofloat -scan_range -xstep 2 -ystep 2 -zstep > 2 -xstart 46 ?-ystart 64 ?-zstart 37 ?name.mnc 91 109 91 -clobber -osigned As Soren has already pointed out the -osigned argument will have no effect for float values. My question is if these are ANALYZE? volumes why not just use nii2mnc? $ nii2mnc name.hdr out.mnc This will take care of all the various datatype issues that you might be having. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From michael.a.yee at vanderbilt.edu Wed Jul 8 10:59:03 2009 From: michael.a.yee at vanderbilt.edu (Michael Alexander Yee) Date: Wed, 8 Jul 2009 09:59:03 -0500 Subject: [MINC-users] Rawtominc problems In-Reply-To: References: Message-ID: To Soren: Thanks for responding, but how do I check the file size, and is ofloat 32 bits? To Andrew: Thank you also for replying, but could you explain the $ nii2mnc command, it does not seem to work with the minc software I am using - "command not found." I still do not understand why my command of: cat name.img | rawtominc -float -ofloat -scan_range -xstep 2 -ystep 2 -zstep 2 -xstart 46 -ystart 64 -zstart 37 name.mnc 91 109 91 -clobber Gives me a "premature end of file" message. Origin (x,y,z) 46,64,37 Dimensions (x,y,z) 91,109,91 Voxel resolution 2,2,2 Data type - 32 bit real Thanks, Michael On Tue, Jul 7, 2009 at 8:03 PM, Andrew Janke wrote: > Hi Michael, > > On Wed, Jul 8, 2009 at 02:58, Michael Alexander > Yee wrote: > > I am trying to convert .img files (float) to .mnc using rawtominc, but I > > keep getting a "premature end of file" message and mincheader shows that > > several slices do not have a corresponding min/max. > > > > I have written: > > > > cat name.img | rawtominc -float -ofloat -scan_range -xstep 2 -ystep 2 > -zstep > > 2 -xstart 46 -ystart 64 -zstart 37 name.mnc 91 109 91 -clobber > -osigned > > As Soren has already pointed out the -osigned argument will have no > effect for float values. My question is if these are ANALYZE? volumes > why not just use nii2mnc? > > $ nii2mnc name.hdr out.mnc > > This will take care of all the various datatype issues that you might be > having. > > > -- > 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 michael.a.yee at vanderbilt.edu Wed Jul 8 13:27:11 2009 From: michael.a.yee at vanderbilt.edu (Michael Alexander Yee) Date: Wed, 8 Jul 2009 12:27:11 -0500 Subject: [MINC-users] Rawtominc problems In-Reply-To: References: Message-ID: Furthermore, When converting other images from rawtominc, I have successfully created int 16 bit images that can be viewed on register.exe in .mnc format and look like the original .img files, but the voxel readings are not only wrong, but they are not integers. I used: cat baseline.img | rawtominc -short -oshort -swap_bytes -scan_range -xstep -2 -ystep 2 -zstep 2 -xstart 46 -ystart 64 -zstart 37 baseline.mnc 91 109 91 -clobber -osigned Any suggestions on why the readings are wrong but the image looks right? Michael On Wed, Jul 8, 2009 at 9:59 AM, Michael Alexander Yee < michael.a.yee at vanderbilt.edu> wrote: > To Soren: > Thanks for responding, but how do I check the file size, and is ofloat 32 > bits? > > To Andrew: > Thank you also for replying, but could you explain the $ nii2mnc command, > it does not seem to work with the minc software I am using - "command not > found." > > I still do not understand why my command of: > > cat name.img | rawtominc -float -ofloat -scan_range -xstep 2 -ystep 2 > -zstep 2 -xstart 46 -ystart 64 -zstart 37 name.mnc 91 109 91 -clobber > > Gives me a "premature end of file" message. > > Origin (x,y,z) 46,64,37 > Dimensions (x,y,z) 91,109,91 > Voxel resolution 2,2,2 > Data type - 32 bit real > > Thanks, > > Michael > > > > On Tue, Jul 7, 2009 at 8:03 PM, Andrew Janke wrote: > >> Hi Michael, >> >> On Wed, Jul 8, 2009 at 02:58, Michael Alexander >> Yee wrote: >> > I am trying to convert .img files (float) to .mnc using rawtominc, but I >> > keep getting a "premature end of file" message and mincheader shows that >> > several slices do not have a corresponding min/max. >> > >> > I have written: >> > >> > cat name.img | rawtominc -float -ofloat -scan_range -xstep 2 -ystep 2 >> -zstep >> > 2 -xstart 46 -ystart 64 -zstart 37 name.mnc 91 109 91 -clobber >> -osigned >> >> As Soren has already pointed out the -osigned argument will have no >> effect for float values. My question is if these are ANALYZE? volumes >> why not just use nii2mnc? >> >> $ nii2mnc name.hdr out.mnc >> >> This will take care of all the various datatype issues that you might be >> having. >> >> >> -- >> 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 Thu Jul 9 18:59:42 2009 From: mishkind at gmail.com (Mishkin Derakhshan) Date: Thu, 9 Jul 2009 18:59:42 -0400 Subject: [MINC-users] jaunty problems In-Reply-To: References: <9c5abb60906021047q34a41365t4e15721db40a64c0@mail.gmail.com> Message-ID: <9c5abb60907091559sc92cdb6mc3cd0503e382b76@mail.gmail.com> I've been trying to track down the problem. Seems to be a bug that was fixed in xserver-xorg-video-intel. I installed xserver-xorg-video-intel_2.7.1-1_i386.deb (and the libdrm-intel1_2.4.11-1_i386.deb dependency) and now register and display work fine! Unfortunately, my screen resolutions are all messed up because xorg is reverting back to VESA because of some intel.ids file that is missing in xserver-xorg-video-intel 2.7.1-1. (For details see https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/379504). This bug can be fixed by installing xserver-xorg-core_1.6.1.901-3_i386.deb, however this requires libgcrypt11_1.4.4-2. Here is my problem, I can't install libgcrypt11 because it says: Error: Breaks exisiting package 'libgcrypt11-dev' dependency libgcrypt11 (= 1.4.1-2ubuntu1) And, I can't install libgcrypt11-dev because it says: Error: Dependency is not satisfiable: libgcrypt11 (= 1.4.4-2) I was thinking of removing my current version of libgcrypt11*, but they have major dependencies that would be removed as well. So before I go breaking my system can someone let me know how I can update libgcrypt11, so i can then install xserver-xorg-core, so I can then finally open a minc file at home? thanks, mishkin On Wed, Jun 3, 2009 at 6:02 AM, Andrew Janke wrote: > On Wed, Jun 3, 2009 at 19:57, Flemming Andersen wrote: >> Yes both intel. I tried both with and without compiz (just metacity) and no >> change.. same with -single and -rgb on register, no change. > >> I have my eyes on freeglut too... > > I have this: > > localhost:~$ dpkg --list | grep glut > ii ?freeglut3 > 2.4.0-6.1ubuntu1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? OpenGL > Utility Toolkit > ii ?freeglut3-dev > 2.4.0-6.1ubuntu1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? OpenGL > Utility Toolkit development files > ii ?glutg3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 3.7-25 > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? the OpenGL Utility > Toolkit > ii ?glutg3-dev ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 3.7-25 > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? the OpenGL Utility > Toolkit development files > ii ?libglut3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 3.7-25 > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? the OpenGL Utility > Toolkit > > Note that it is possible to compile register/Display against the > software rendering versions of GLUT which can have interesting > effects... > > > a > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From michael.a.yee at vanderbilt.edu Fri Jul 10 13:06:44 2009 From: michael.a.yee at vanderbilt.edu (Michael Alexander Yee) Date: Fri, 10 Jul 2009 12:06:44 -0500 Subject: [MINC-users] Masking voxels Message-ID: Hello! Is it possible to mask any voxel readings that are below a minimum desired reading? I have used: mincmath name.mnc -segment -const2 40 90000 nameseg.mnc But it turns all readings into either 0 or 1. Is there a command to use so that voxel readings within the range will keep their values instead of changing to 1? Thanks, Michael From mok at bic.mni.mcgill.ca Fri Jul 10 14:09:50 2009 From: mok at bic.mni.mcgill.ca (Kelvin Mok) Date: Fri, 10 Jul 2009 14:09:50 -0400 Subject: [MINC-users] Masking voxels In-Reply-To: References: Message-ID: <4A5783EE.8070507@bic.mni.mcgill.ca> Michael Alexander Yee wrote: > Hello! > > Is it possible to mask any voxel readings that are below a minimum desired > reading? I have used: > > mincmath name.mnc -segment -const2 40 90000 nameseg.mnc > > But it turns all readings into either 0 or 1. Is there a command to use so > that voxel readings within the range will keep their values instead of > changing to 1? > > Thanks, > Michael > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > Hi Michael, You can use minccalc and specify your rule with the switch "-expression".... minccalc -expression "if (A[0] References: Message-ID: Both register and Display re-discretize your values to byte range so you will often see discrepancies to your in-file real values. This is just when viewing, will not affect any analysis using the other tools. This has been discussed previously on the list and you should be able to find info there as well. single precision Float is 32 bit (See wiki). Do ls -l to get size or right click an see file properties using your OS gui. Soren On Thu, Jul 9, 2009 at 3:27 AM, Michael Alexander Yee < michael.a.yee at vanderbilt.edu> wrote: > Furthermore, > > When converting other images from rawtominc, I have successfully created > int > 16 bit images that can be viewed on register.exe in .mnc format and look > like the original .img files, but the voxel readings are not only wrong, > but > they are not integers. > > I used: > > cat baseline.img | rawtominc -short -oshort -swap_bytes -scan_range -xstep > -2 -ystep 2 -zstep 2 -xstart 46 -ystart 64 -zstart 37 baseline.mnc 91 > 109 > 91 -clobber -osigned > > Any suggestions on why the readings are wrong but the image looks right? > > Michael > > On Wed, Jul 8, 2009 at 9:59 AM, Michael Alexander Yee < > michael.a.yee at vanderbilt.edu> wrote: > > > To Soren: > > Thanks for responding, but how do I check the file size, and is ofloat 32 > > bits? > > > > To Andrew: > > Thank you also for replying, but could you explain the $ nii2mnc command, > > it does not seem to work with the minc software I am using - "command not > > found." > > > > I still do not understand why my command of: > > > > cat name.img | rawtominc -float -ofloat -scan_range -xstep 2 -ystep 2 > > -zstep 2 -xstart 46 -ystart 64 -zstart 37 name.mnc 91 109 91 -clobber > > > > Gives me a "premature end of file" message. > > > > Origin (x,y,z) 46,64,37 > > Dimensions (x,y,z) 91,109,91 > > Voxel resolution 2,2,2 > > Data type - 32 bit real > > > > Thanks, > > > > Michael > > > > > > > > On Tue, Jul 7, 2009 at 8:03 PM, Andrew Janke wrote: > > > >> Hi Michael, > >> > >> On Wed, Jul 8, 2009 at 02:58, Michael Alexander > >> Yee wrote: > >> > I am trying to convert .img files (float) to .mnc using rawtominc, but > I > >> > keep getting a "premature end of file" message and mincheader shows > that > >> > several slices do not have a corresponding min/max. > >> > > >> > I have written: > >> > > >> > cat name.img | rawtominc -float -ofloat -scan_range -xstep 2 -ystep 2 > >> -zstep > >> > 2 -xstart 46 -ystart 64 -zstart 37 name.mnc 91 109 91 -clobber > >> -osigned > >> > >> As Soren has already pointed out the -osigned argument will have no > >> effect for float values. My question is if these are ANALYZE? volumes > >> why not just use nii2mnc? > >> > >> $ nii2mnc name.hdr out.mnc > >> > >> This will take care of all the various datatype issues that you might be > >> having. > >> > >> > >> -- > >> 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 > >> > > > > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users > From a.janke at gmail.com Sat Jul 11 11:57:22 2009 From: a.janke at gmail.com (Andrew Janke) Date: Sat, 11 Jul 2009 17:57:22 +0200 Subject: [MINC-users] Rawtominc problems In-Reply-To: References: Message-ID: Hi Michael > Thank you also for replying, but could you explain the $ nii2mnc command, it > does not seem to work with the minc software I am using - "command not > found." nii2mnc is part of any recent MINC version starting from about 1.3 in the old series and 2.0.05 (IIRC) in the 2.X series. Which version are you currently using? (use mincmath -version to find out) Andrew From a.janke at gmail.com Sun Jul 12 01:01:39 2009 From: a.janke at gmail.com (Andrew Janke) Date: Sun, 12 Jul 2009 07:01:39 +0200 Subject: [MINC-users] Masking voxels In-Reply-To: References: Message-ID: Hi Michael, > Is it possible to mask any voxel readings that are below a minimum desired > reading? ?I have used: > > mincmath name.mnc -segment -const2 40 90000 ?nameseg.mnc > > But it turns all readings into either 0 or 1. ?Is there a command to use so > that voxel readings within the range will keep their values instead of > changing to 1? Kelvin is bang on the mark with his minccalc call. Just to assure though, you were on the right track with mincmath, you just needed to add an extra step whereby you multiplied your 1/0 volume by the original using: mincmath -mult nameseg.mnc name.mnc out.mnc -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From michael.a.yee at vanderbilt.edu Mon Jul 13 10:07:32 2009 From: michael.a.yee at vanderbilt.edu (Michael Alexander Yee) Date: Mon, 13 Jul 2009 09:07:32 -0500 Subject: [MINC-users] Masking voxels In-Reply-To: References: Message-ID: It worked great! Thanks. On Sun, Jul 12, 2009 at 12:01 AM, Andrew Janke wrote: > Hi Michael, > > > Is it possible to mask any voxel readings that are below a minimum > desired > > reading? I have used: > > > > mincmath name.mnc -segment -const2 40 90000 nameseg.mnc > > > > But it turns all readings into either 0 or 1. Is there a command to use > so > > that voxel readings within the range will keep their values instead of > > changing to 1? > > Kelvin is bang on the mark with his minccalc call. Just to assure > though, you were on the right track with mincmath, you just needed to > add an extra step whereby you multiplied your 1/0 volume by the > original using: > > mincmath -mult nameseg.mnc name.mnc out.mnc > > > -- > 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 anthonin at bic.mni.mcgill.ca Fri Jul 10 14:38:04 2009 From: anthonin at bic.mni.mcgill.ca (Anthonin REILHAC) Date: Fri, 10 Jul 2009 14:38:04 -0400 Subject: [MINC-users] volume_io Message-ID: Hi all, I would like to read a whole minc file (time,z,y,x) in one shot (using input_volume) and save it back in one shot using ouput_volume(). When I do this, the min/max values per xy-slice the original file contains are lost, and replaced by min/max values for the whole 4D volume. Is there a way to fix this? Also, I am trying a variant: I load the whole volume with input_volume in a Volume variable and save the same volume back (using the same Volume variable) in a new file, xy-slice wise (using loops over time and z), with output_volume_to_minc_file_position() function. But this does not work. In this last variant, should the Volume passed to output_volume_to_minc_file_position be of the dimension of the subset of the whole volume we want to write on disk(of a xy-slice?) or can it be of the dimension of the whole volume and we specify the part we want to write with volumes_counts and file_start? Thanks in advance. Anthonin Reilhac McConnell Brain Imaging Centre, WB2B Montreal Neurological Institute 3801 University Montreal, Quebec, Canada phone: (514) 398 4965 From mishkind at gmail.com Mon Jul 13 16:31:18 2009 From: mishkind at gmail.com (Mishkin Derakhshan) Date: Mon, 13 Jul 2009 16:31:18 -0400 Subject: [MINC-users] jaunty problems In-Reply-To: <9c5abb60907091559sc92cdb6mc3cd0503e382b76@mail.gmail.com> References: <9c5abb60906021047q34a41365t4e15721db40a64c0@mail.gmail.com> <9c5abb60907091559sc92cdb6mc3cd0503e382b76@mail.gmail.com> Message-ID: <9c5abb60907131331g4de5c3aei73926a98ea1f52cb@mail.gmail.com> I don't think my original attempt made it to the mailing list... On Thu, Jul 9, 2009 at 6:59 PM, Mishkin Derakhshan wrote: > I've been trying to track down the problem. > > Seems to be a bug that was fixed in xserver-xorg-video-intel. I > installed xserver-xorg-video-intel_2.7.1-1_i386.deb (and the > libdrm-intel1_2.4.11-1_i386.deb dependency) and now register and > display work fine! > > Unfortunately, my screen resolutions are all messed up because xorg is > reverting back to VESA because of some intel.ids file that is missing > in xserver-xorg-video-intel 2.7.1-1. (For details see > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/379504). > > This bug can be fixed by installing > xserver-xorg-core_1.6.1.901-3_i386.deb, however this requires > libgcrypt11_1.4.4-2. > > Here is my problem, I can't install libgcrypt11 because it says: > Error: Breaks exisiting package 'libgcrypt11-dev' dependency > libgcrypt11 (= 1.4.1-2ubuntu1) > > And, I can't install libgcrypt11-dev because it says: > Error: Dependency is not satisfiable: libgcrypt11 (= 1.4.4-2) > > I was thinking of removing my current version of libgcrypt11*, but > they have major dependencies that would be removed as well. > > So before I go breaking my system can someone let me know how I can > update libgcrypt11, so i can then install xserver-xorg-core, so I can > then finally open a minc file at home? > > thanks, > mishkin > > > > On Wed, Jun 3, 2009 at 6:02 AM, Andrew Janke wrote: >> On Wed, Jun 3, 2009 at 19:57, Flemming Andersen wrote: >>> Yes both intel. I tried both with and without compiz (just metacity) and no >>> change.. same with -single and -rgb on register, no change. >> >>> I have my eyes on freeglut too... >> >> I have this: >> >> localhost:~$ dpkg --list | grep glut >> ii ?freeglut3 >> 2.4.0-6.1ubuntu1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? OpenGL >> Utility Toolkit >> ii ?freeglut3-dev >> 2.4.0-6.1ubuntu1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? OpenGL >> Utility Toolkit development files >> ii ?glutg3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 3.7-25 >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? the OpenGL Utility >> Toolkit >> ii ?glutg3-dev ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 3.7-25 >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? the OpenGL Utility >> Toolkit development files >> ii ?libglut3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 3.7-25 >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? the OpenGL Utility >> Toolkit >> >> Note that it is possible to compile register/Display against the >> software rendering versions of GLUT which can have interesting >> effects... >> >> >> a >> _______________________________________________ >> MINC-users at bic.mni.mcgill.ca >> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users >> > From acveilleux at mrs.mni.mcgill.ca Mon Jul 13 16:43:05 2009 From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX) Date: Mon, 13 Jul 2009 16:43:05 -0400 Subject: [MINC-users] jaunty problems In-Reply-To: <9c5abb60907131331g4de5c3aei73926a98ea1f52cb@mail.gmail.com>; from mishkind@gmail.com on Mon, Jul 13, 2009 at 04:31:18PM -0400 References: <9c5abb60906021047q34a41365t4e15721db40a64c0@mail.gmail.com> <9c5abb60907091559sc92cdb6mc3cd0503e382b76@mail.gmail.com> <9c5abb60907131331g4de5c3aei73926a98ea1f52cb@mail.gmail.com> Message-ID: <20090713164305.Q5985@mrs.mni.mcgill.ca> Why not upgrade both the libgcrypt package in the same command-line? That should let apt resolve the circular dependency, no? Alex On Mon, Jul 13, 2009 at 04:31:18PM -0400, Mishkin Derakhshan wrote: > From: Mishkin Derakhshan > Date: Mon, 13 Jul 2009 16:31:18 -0400 > To: MINC users mailing list > Subject: Re: [MINC-users] jaunty problems > > I don't think my original attempt made it to the mailing list... > > On Thu, Jul 9, 2009 at 6:59 PM, Mishkin Derakhshan wrote: > > I've been trying to track down the problem. > > > > Seems to be a bug that was fixed in xserver-xorg-video-intel. I > > installed xserver-xorg-video-intel_2.7.1-1_i386.deb (and the > > libdrm-intel1_2.4.11-1_i386.deb dependency) and now register and > > display work fine! > > > > Unfortunately, my screen resolutions are all messed up because xorg is > > reverting back to VESA because of some intel.ids file that is missing > > in xserver-xorg-video-intel 2.7.1-1. (For details see > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/379504). > > > > This bug can be fixed by installing > > xserver-xorg-core_1.6.1.901-3_i386.deb, however this requires > > libgcrypt11_1.4.4-2. > > > > Here is my problem, I can't install libgcrypt11 because it says: > > Error: Breaks exisiting package 'libgcrypt11-dev' dependency > > libgcrypt11 (= 1.4.1-2ubuntu1) > > > > And, I can't install libgcrypt11-dev because it says: > > Error: Dependency is not satisfiable: libgcrypt11 (= 1.4.4-2) > > > > I was thinking of removing my current version of libgcrypt11*, but > > they have major dependencies that would be removed as well. > > > > So before I go breaking my system can someone let me know how I can > > update libgcrypt11, so i can then install xserver-xorg-core, so I can > > then finally open a minc file at home? > > > > thanks, > > mishkin > > > > > > > > On Wed, Jun 3, 2009 at 6:02 AM, Andrew Janke wrote: > >> On Wed, Jun 3, 2009 at 19:57, Flemming Andersen wrote: > >>> Yes both intel. I tried both with and without compiz (just metacity) and no > >>> change.. same with -single and -rgb on register, no change. > >> > >>> I have my eyes on freeglut too... > >> > >> I have this: > >> > >> localhost:~$ dpkg --list | grep glut > >> ii ?freeglut3 > >> 2.4.0-6.1ubuntu1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? OpenGL > >> Utility Toolkit > >> ii ?freeglut3-dev > >> 2.4.0-6.1ubuntu1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? OpenGL > >> Utility Toolkit development files > >> ii ?glutg3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 3.7-25 > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? the OpenGL Utility > >> Toolkit > >> ii ?glutg3-dev ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 3.7-25 > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? the OpenGL Utility > >> Toolkit development files > >> ii ?libglut3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 3.7-25 > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? the OpenGL Utility > >> Toolkit > >> > >> Note that it is possible to compile register/Display against the > >> software rendering versions of GLUT which can have interesting > >> effects... > >> > >> > >> a > >> _______________________________________________ > >> 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 From a.janke at gmail.com Wed Jul 15 08:22:52 2009 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 15 Jul 2009 14:22:52 +0200 Subject: [MINC-users] [FSL] N3 correction In-Reply-To: <44FFFBE3-13CC-4209-A05E-1FD5BB26FCF4@fmrib.ox.ac.uk> References: <44FFFBE3-13CC-4209-A05E-1FD5BB26FCF4@fmrib.ox.ac.uk> Message-ID: Hi Moran, yes, these sorts of things are best sent here: minc-users at bic.mni.mcgill.ca the short answer to your question is that N3 is not really made for EPI as the histogram sharpening will have trouble with the EPi contrast. Andrew On Wed, Jul 15, 2009 at 09:18, Steve Smith wrote: > Hi - nu_correct is not an FSL program - you'll have to ask the MINC people > about that! > Cheers. > > > On 14 Jul 2009, at 15:59, Moran Artzi wrote: > >> Hi >> I'm trying to use N3 tool (nu_correct) for the correcting of epi >> (perfusion) >> data. However its seems that the default mode (nu_correct -mask mask.mnc >> vol1_brain.mnc voln3.mnc) is not rough enough for this kind of data >> (a significant brain asymmetry is still demonstrated with minor >> differences >> between the corrected and uncorrected data). >> >> Can you please help me to improve my results? >> Many thanks >> Moran >> > > > --------------------------------------------------------------------------- > Stephen M. Smith, Professor of Biomedical Engineering > Associate Director, ?Oxford University FMRIB Centre > > FMRIB, JR Hospital, Headington, Oxford ?OX3 9DU, UK > +44 (0) 1865 222726 ?(fax 222717) > steve at fmrib.ox.ac.uk ? ?http://www.fmrib.ox.ac.uk/~steve > --------------------------------------------------------------------------- > From penhunelab at gmail.com Mon Jul 27 13:47:28 2009 From: penhunelab at gmail.com (Penhune Lab) Date: Mon, 27 Jul 2009 13:47:28 -0400 Subject: [MINC-users] functional connectivity problem with alternating slice pattern (Keith's way) Message-ID: Hello all, I have been trying to implement a functional connectivity analysis (direct FC and stimulus modulated - what Keith called "effective connectivity") and I wondered if someone might have some insights into my problem: the mag_t.mnc files resulting from the analysis appear to have an alternating slice pattern. I have already conducted simple model-based fmrilm analyses on this data set and do not see this same alternating slice pattern in them. I acquired at a resolution of 4mm^3 (interleaved ascending*) *on the BIC 3T. From what I can tell, the issue arises because of the interleaved ascending slicetimes. If I change the slicetimes from interleaved ascending to ascending the alternating pattern disappears. Any thoughts? Regards, Chris -- 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 From a.janke at gmail.com Mon Jul 27 20:27:23 2009 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 28 Jul 2009 10:27:23 +1000 Subject: [MINC-users] functional connectivity problem with alternating slice pattern (Keith's way) In-Reply-To: References: Message-ID: Hi Chris, On Tue, Jul 28, 2009 at 03:47, Penhune Lab wrote: > problem: the mag_t.mnc files resulting from the analysis appear to have an > alternating slice pattern. > > I have already conducted simple model-based fmrilm analyses on this data set > and do not see this same alternating slice pattern in them. I acquired at a > resolution of 4mm^3 (interleaved ascending*) *on the BIC 3T. From what I can > tell, the issue arises because of the interleaved ascending slicetimes. If I > change the slicetimes from interleaved ascending to ascending the > alternating pattern disappears. Sounds to me like you are being bitten by slice scaling issues. MINC will scale each slice separately (and maintain an internal list of scaling values) to ensure the best range is stored for each slice as it is converted/processed. You seem to be using fmristat? which means you are using EMMA and I not sure as to how well EMMA handled slice scaling. My first approach to this problem would be to convert your input volume to float. When volumes are in float/double format slice scaling is not used. mincreshape -float input.mnc input_float.mnc And then re-run the analysis. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From penhunelab at gmail.com Tue Jul 28 11:07:12 2009 From: penhunelab at gmail.com (Penhune Lab) Date: Tue, 28 Jul 2009 11:07:12 -0400 Subject: [MINC-users] functional connectivity problem with alternating slice pattern (Keith's way) In-Reply-To: References: Message-ID: Thank you Andrew, I have an analysis running right now but will check this and get back to you when it completes (sometime this evening or tomorrow). Having looked at the images created by both ascending and descending slicetimes for this analysis, my sense is that there is not that the slicetimes don't make that much of a difference - and that this difference is reflected in lower magnitude t-values rather than spurious results. Do you think this is accurate? Cheers, Chris On Mon, Jul 27, 2009 at 8:27 PM, Andrew Janke wrote: > Hi Chris, > > On Tue, Jul 28, 2009 at 03:47, Penhune Lab wrote: > > problem: the mag_t.mnc files resulting from the analysis appear to have > an > > alternating slice pattern. > > > > I have already conducted simple model-based fmrilm analyses on this data > set > > and do not see this same alternating slice pattern in them. I acquired at > a > > resolution of 4mm^3 (interleaved ascending*) *on the BIC 3T. From what I > can > > tell, the issue arises because of the interleaved ascending slicetimes. > If I > > change the slicetimes from interleaved ascending to ascending the > > alternating pattern disappears. > > Sounds to me like you are being bitten by slice scaling issues. MINC > will scale each slice separately (and maintain an internal list of > scaling values) to ensure the best range is stored for each slice as > it is converted/processed. You seem to be using fmristat? which means > you are using EMMA and I not sure as to how well EMMA handled slice > scaling. My first approach to this problem would be to convert your > input volume to float. When volumes are in float/double format slice > scaling is not used. > > mincreshape -float input.mnc input_float.mnc > > And then re-run the analysis. > > > -- > 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 > -- 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 From a.janke at gmail.com Tue Jul 28 22:49:43 2009 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 29 Jul 2009 12:49:43 +1000 Subject: [MINC-users] functional connectivity problem with alternating slice pattern (Keith's way) In-Reply-To: References: Message-ID: On Wed, Jul 29, 2009 at 01:07, Penhune Lab wrote: > my sense is that there is not that the > slicetimes don't make that much of a difference - and that this difference > is reflected in lower magnitude t-values rather than spurious results. Do > you think this is accurate? Possibly. Depends on what you using to view your results. If it is something like register/Display then I would not expect to see this. Doesn't mean it isn't possible though! -- 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 Fri Jul 31 16:40:41 2009 From: nikelski at bic.mni.mcgill.ca (EJ Nikelski) Date: Fri, 31 Jul 2009 16:40:41 -0400 Subject: [MINC-users] EMMA replacement? In-Reply-To: References: <6fe841c70907301401h491f5d36g33d66238b7fbea78@mail.gmail.com> Message-ID: Hi All, I hope that none of the original posters to this thread mind, but I would really like to bounce this conversion past all minc users, as all minc users may have an interest and/or input, and I believe that the points being made are stimulating and excellent grist for a sleepy Friday afternoon. Thanks Pierre for sharing your views and experiences. Matlab does indeed seem to be the currently reigning champ with regard to high-level multi-platform image manipulation software. Of course, most compelling is the fact that it can certainly do the job, as evidenced by Pierre's work, as well as by that done by the SPM group. So, it would appear as if any suggested move away from Matlab would need to be able to show a clear set of advantages over Matlab. Octave, whilst circumventing the Matlab licensing issues still has a number of problems. Firstly, and quite significantly, IMHO Octave is a second class citizen, which simply looks like an inferior Matlab wanna-be. I've been following Octave for years, and its development has always been stop-and-go, and the developers really don't seem willing to plot their own course. Personally, I would think long and hard before hitching my wagon to Octave. Secondly, Octave suffers from the fact that, like Matlab, it's a development language that is geared towards linear algebra -- not statistics. Now, I know that people can get terribly attached to their development environments, so I shall tread carefully. Whether one chooses Matlab or R seems to be a function of what one wishes to do. Matlab is all about linear algebra, which can indeed come in very handy when working with imaging volumes. R, on the other hand, is all about statistics, so ... if, for example, you are doing 80,000 regressions on a cortical surface, R would be an appropriate tool. Not only because R can do linear regression out-of-the-box, but it can also work (just as easily) with nonlinear regression, mixed-effects models, generalized additive models, and just about anything else that you might want to throw at it. In addition, it includes an extremely flexible and powerful programming language, extensible with C call (as needed). But wait, there's more! R can also make use of multiple cores, permitting easy parallelization (sp?) of processing (see the "doMC" and "foreach" packages). Of course, Matlab *can* do stats, as demonstrated by Pierre and Keith Worsley, and the SPM folks, however, I suggest that using Matlab for this purpose is like trying to peel a banana while wearing boxing gloves -- it's messy, and there are better alternatives. Finally, nobody has addressed the gorilla in the room --- has nifti-1 basically already killed minc, making all of this rather academic? Have a spliffy weekend, -Jim On Fri, Jul 31, 2009 at 1:04 PM, Samir Das wrote: > Hello all, > Just adding a bit to what Pierre said. I agree that his new pipeline manager > PSOM and the NIAK toolkit is a great way to go, especially since it can work > with Octave which is an open source language (therefore no pricey licenses). > From what I understand, it takes care of almost all of the issues that one > would run into for fMRI processing and it seems to be working under quite > well for those that have started using it. That said, Pierre is but one man > and ongoing development continues. The only potential drawback (other than > one's choice of programming language) is that Octave sometimes does not work > exactly the same way as Matlab, so work will be required to maintain it. > The reason I am speaking up is because from the thread below, I have seen > some comments about?developing?this in R. I have spent quite a bit of time > using and understanding Jason's R libraries, particularly as it relates to > VBM and cortical thickness, and I think I would be able to enhance or add to > those libraries to enable things like 4D image importing and manipulation. > My only problem is while I would be interested in looking into something > like this, I really can't seem to find the time right now. > Again, that could be a moot point since Pierre has > already?developed?something quite nice. I just thought I would pipe in. > Samir Das > > > On Thu, Jul 30, 2009 at 5:19 PM, Alan EVANS wrote: >> >> Hi Pierre, >> ? ? ? ? Thanks for the rapid (and complete) response. >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Alan >> >> >> On Thu, 30 Jul 2009, Pierre Bellec wrote: >> >>> Hi all, >>> >>> When reading Jim's email I recognized many of the questions I ran into in >>> the recent past. Here's an update of the choices I've made at the time. >>> >>> There is first the question of the choice of the programming language for >>> future developments. Coming from an applied maths background, matlab was >>> sort of a natural choice. It lets you code powerful algorithms into >>> concise >>> code, has very decent runtime execution performance and great >>> debugging/profiling capabilities. I don't have enough experiences with >>> other >>> languages (including R) to discuss the pros and cons in details, all I >>> know >>> is that it does the job for me and it is very well established in the >>> biomedical engineering community, among others. There is obviously a >>> concern >>> regarding Matlab licenses. I have been trying over the past year to make >>> my >>> codes compatible with both Matlab and Octave (the GNU clone of Matlab) >>> and >>> it is almost painless. Octave is not as comfortable as Matlab in the >>> development phase (mainly due to poor debugging tools), but to run code >>> developed for Matlab it works. My conclusion is that Matlab is a >>> perfectly >>> viable choice to develop and disseminate image analysis/statistical >>> analysis >>> tools. But if for some reason (coding style or existing libraries for >>> example) one wants to go for R, I think that would work too and it >>> certainly >>> did for Jason. It would only take a couple of motivated developers to set >>> up >>> coding guidelines and core functions to extend the Rminc package into >>> something cleaner. >>> >>> Speaking of which, I started such an initiative about a year ago, using >>> Matlab/Octave as my reference language. The project is hosted on google >>> code >>> and called NIAK . The objective for >>> release >>> 1.0 is to have a full pipeline for fMRI preprocessing and general linear >>> model analysis. I am currently working with Felix Carbonell on breaking >>> up >>> fMRIstat into modules and including them in the pipeline. The fMRI >>> preprocessing pipeline has been working for a couple of months now and >>> was >>> used notably by people from Jean Gotman and Alain Dagher's lab. The >>> feedback >>> is good so far even though NIAK is more oriented towards developers than >>> end-users. I am pushing for the linear model pipeline to be integrated in >>> the Cbrain project which would provide the final nice user-friendly >>> interface. The timeline for first release is next winter, and I am >>> planning >>> on starting to advertise for the project at that point. >>> >>> I have developed some (hopefully) clean coding guidelines, and the >>> pipeline >>> runtime is powered by a generic pipeline manager called >>> PSOM. >>> PSOM is essentially an extension of PMP fully written in Matlab. I am >>> currently using it at CLUMEQ (the McGill supercomputing center) and a >>> pipeline of more than 15000 jobs was handled there smoothly. I believe >>> that >>> this framework is quite efficient at handling compicated pipelines with >>> tons >>> of parameters in a distributed computing environment, especially if one >>> wants to play around with the flowchart and the choice of parameters. At >>> least, it was designed with that purpose in mind. My plan is to use NIAK >>> as >>> the framework for all my future developments. I haven't done much >>> publicity >>> still, but Dr Christophe Grova and a couple of his students have adopted >>> it >>> as their development framework, as well as Gaolang Gang (a postdoc from >>> Alan's lab) and the feedback from them is very positive. ?I would be more >>> than happy if some developers were interested to develop their own >>> toolbox >>> in the NIAK framework, right now it is essentially a solo effort with >>> input >>> from Felix (and Keith in a sense) for the GLM part, and a couple of >>> functions contributed by Vincent Perlbarg from my former lab in Paris. >>> But >>> of course, as I said before, Rminc is also a very nice package that would >>> be >>> a great basis for future development. >>> >>> I almost forgot... the MINC reader/writer ! So I had to get rid of EMMA. >>> First because it is awfully slow, second because I wanted to avoid >>> compiled >>> code and third because I needed something that worked with Octave. There >>> are >>> functions called NIAK_READ_VOL and NIAK_WRITE_VOL that will do the job, >>> and >>> actually support NIFTI and ANALYZE as well (the output header structure >>> is >>> common to the three format, except for an HDR.DETAILS field that contains >>> the complete list of format-specific fields). The reader/writer is just a >>> wraper arond MINCHEADER, RAWTOMINC and MINCTORAW, so as long as the minc >>> tools are installed it should work. I still have the idea to code a >>> reader >>> based on the internal matlab HDF5 and NETCDF libraries (which would be >>> faster and cleaner) but I am not diving in because that will be a pure >>> waste >>> of time as far as octave is concerned. >>> >>> Let me know what you think, >>> >>> Pierre >>> >>> 2009/7/30 Alan EVANS >>> >>>> Hi Jim, >>>> ? ? Somebody, has recently developed tools to by-pass the need for EMMA >>>> (NIAK, Pierre ?). Can somebody on this cc-list clarify ?. >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Alan >>>> >>>> >>>> On Tue, 28 Jul 2009, EJ Nikelski wrote: >>>> >>>> ?Hi Howard and Alan, >>>>> >>>>> ?The purpose of this e-mail is to elucidate some of the ideas that >>>>> were expressed in a recent meeting between Howard and myself and gets >>>>> Alan's input. ?These ideas sprang from our discussion regarding our >>>>> PiB data, and how best to write our analysis functions -- particularly >>>>> given that the PiB data starts life as a 4-D volume. >>>>> >>>>> Background: >>>>> ?Many years ago, immediately subsequent to the development of minc, >>>>> Sean Marrett and other wrote a Matlab toolbox (EMMA), which allowed >>>>> users to write Matlab functions capable of reading/writing minc >>>>> volumes. ?This toolbox has remained heavily used around BIC, as it >>>>> allows us to easily manipulate minc data. ?Unfortunately, there are a >>>>> few problems: (1) EMMA requires a Matlab license, which is often >>>>> expensive -- depending upon the whims of The Mathworks people and >>>>> whether McGill is able to wrangle a site license, (2) EMMA is not >>>>> really supported any more, and certainly isn't being actively >>>>> developed, Matlab, while well suited for linear algebra, is a pretty >>>>> poor excuse for a proper programming language. >>>>> >>>>> ?The alternative to using EMMA would be to continue along the path >>>>> that Jason Lerch set with his RMINC package. ?Jason's RMINC package >>>>> uses the R statistical software (instead of Matlab), and extends it, >>>>> permitting it to read/write minc2 volumes. ?Advantages include: (1) R >>>>> is a more sophisticated high-level functional language -- Matlab is >>>>> tuned for linear algebra, and it shows, (2) R is specialized for >>>>> statistical processing, Matlab is not, (3) R is an open source >>>>> project, thus no license fees, and (4) R is actively being developed. >>>>> >>>>> ?Unfortunately, Jason's RMINC package has a few drawbacks: (1) it >>>>> will not read/write 4-D volumes, which we *need* when processing PiB >>>>> volumes, (2) Jason incorporated VBM functions into the RMINC package, >>>>> making the package a bit messy, and (3) Jason wrote the interface >>>>> using R S3 classes, which also makes the objects a bit messy and less >>>>> maintainable. ?If we were to go down this road I would suggest taking >>>>> inspiration from RMINC, and : (1) design it using S4 classes and the >>>>> minc2 API, (2) remove the VBM code, creating a package comprised of >>>>> R/minc accessor functions only (call it, say, mniMincIO), (3) the >>>>> accessor functions would be able to deal with 4-D volumes, and (4) a >>>>> simplified layer could be written on top of mniMincIO to present an >>>>> EMMA-like simple interface. ?I believe that I could write the main >>>>> accessor functions in 1 week. >>>>> >>>>> ?So the question is: Is this functionality worth the work? ?I believe >>>>> that having solid R-based minc access functions would make life a lot >>>>> easier for those of us who are writing our own analysis routines using >>>>> minc volumes. ?Having said that, EMMA, as old and decrepit as it is, >>>>> *can* currently do the job -- it just isn't as pretty, and convenient, >>>>> and requires Matlab. ?I suppose we also need to consider the future of >>>>> minc ... and whether minc *has* a future, given that the "provisional" >>>>> nifti-1 standard appears to be very widely used and accepted. >>>>> >>>>> ?Ideas and suggestions? Alan? >>>>> >>>>> -Jim >>>>> >>>>> >>>>> -- >>>>> ================================= >>>>> 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 >>>>> >>>>> >>> >>> >>> -- >>> Pierre Bellec >>> Home page: http://wiki.bic.mni.mcgill.ca/index.php/PierreBellec >>> Address: ? McConnel Brain Imaging Center, Webster 2B >>> ? ? ? ? Montreal Neurological Institute >>> ? ? ? ? 3801 University Street >>> ? ? ? ? Montreal, Quebec, Canada H3A 2B4 >>> tel: ? ? ? (001)(514) 398 5220 >>> fax: ? ? ?(001)(514) 398 8948 >>> > > -- ================================= 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 From acveilleux at mrs.mni.mcgill.ca Fri Jul 31 17:07:40 2009 From: acveilleux at mrs.mni.mcgill.ca (Alexandre CARMEL-VEILLEUX) Date: Fri, 31 Jul 2009 17:07:40 -0400 Subject: [MINC-users] EMMA replacement? In-Reply-To: ; from nikelski@bic.mni.mcgill.ca on Fri, Jul 31, 2009 at 04:40:41PM -0400 References: <6fe841c70907301401h491f5d36g33d66238b7fbea78@mail.gmail.com> Message-ID: <20090731170740.T17358@mrs.mni.mcgill.ca> Why not hitch your wagon behind a general purpose language like Python? People are doing all thee kinds of things in Python already (i.e.: http://www.astro.cornell.edu/staff/loredo/statpy/ for example) Plus if you make that leap, You can use RSPython, the R/SPlus bridge to call any R function from python. There's at least two modules that can deal with netCDF so the mechanics of opening MINC1 files would not be too hard to do. Same for HDF5 / Minc2. Why limit this to MATLAB vs. R? A python interface would be much more useful to the non-fMRI MINC users then R too... Alex On Fri, Jul 31, 2009 at 04:40:41PM -0400, EJ Nikelski wrote: > Date: Fri, 31 Jul 2009 16:40:41 -0400 > From: EJ Nikelski > To: minc users > Cc: "Howard Chertkow, Dr." > Subject: Re: [MINC-users] EMMA replacement? > > Hi All, > > I hope that none of the original posters to this thread mind, but I > would really like to bounce this conversion past all minc users, as > all minc users may have an interest and/or input, and I believe that > the points being made are stimulating and excellent grist for a sleepy > Friday afternoon. > > Thanks Pierre for sharing your views and experiences. Matlab does > indeed seem to be the currently reigning champ with regard to > high-level multi-platform image manipulation software. Of course, > most compelling is the fact that it can certainly do the job, as > evidenced by Pierre's work, as well as by that done by the SPM group. > So, it would appear as if any suggested move away from Matlab would > need to be able to show a clear set of advantages over Matlab. > > Octave, whilst circumventing the Matlab licensing issues still has > a number of problems. Firstly, and quite significantly, IMHO Octave > is a second class citizen, which simply looks like an inferior Matlab > wanna-be. I've been following Octave for years, and its development > has always been stop-and-go, and the developers really don't seem > willing to plot their own course. Personally, I would think long and > hard before hitching my wagon to Octave. Secondly, Octave suffers > from the fact that, like Matlab, it's a development language that is > geared towards linear algebra -- not statistics. > > Now, I know that people can get terribly attached to their > development environments, so I shall tread carefully. Whether one > chooses Matlab or R seems to be a function of what one wishes to do. > Matlab is all about linear algebra, which can indeed come in very > handy when working with imaging volumes. R, on the other hand, is all > about statistics, so ... if, for example, you are doing 80,000 > regressions on a cortical surface, R would be an appropriate tool. Not > only because R can do linear regression out-of-the-box, but it can > also work (just as easily) with nonlinear regression, mixed-effects > models, generalized additive models, and just about anything else that > you might want to throw at it. In addition, it includes an extremely > flexible and powerful programming language, extensible with C call (as > needed). But wait, there's more! R can also make use of multiple > cores, permitting easy parallelization (sp?) of processing (see the > "doMC" and "foreach" packages). Of course, Matlab *can* do stats, as > demonstrated by Pierre and Keith Worsley, and the SPM folks, however, > I suggest that using Matlab for this purpose is like trying to peel a > banana while wearing boxing gloves -- it's messy, and there are better > alternatives. > > Finally, nobody has addressed the gorilla in the room --- has > nifti-1 basically already killed minc, making all of this rather > academic? > > > Have a spliffy weekend, > > -Jim > > > > On Fri, Jul 31, 2009 at 1:04 PM, Samir Das wrote: > > Hello all, > > Just adding a bit to what Pierre said. I agree that his new pipeline manager > > PSOM and the NIAK toolkit is a great way to go, especially since it can work > > with Octave which is an open source language (therefore no pricey licenses). > > From what I understand, it takes care of almost all of the issues that one > > would run into for fMRI processing and it seems to be working under quite > > well for those that have started using it. That said, Pierre is but one man > > and ongoing development continues. The only potential drawback (other than > > one's choice of programming language) is that Octave sometimes does not work > > exactly the same way as Matlab, so work will be required to maintain it. > > The reason I am speaking up is because from the thread below, I have seen > > some comments about?developing?this in R. I have spent quite a bit of time > > using and understanding Jason's R libraries, particularly as it relates to > > VBM and cortical thickness, and I think I would be able to enhance or add to > > those libraries to enable things like 4D image importing and manipulation. > > My only problem is while I would be interested in looking into something > > like this, I really can't seem to find the time right now. > > Again, that could be a moot point since Pierre has > > already?developed?something quite nice. I just thought I would pipe in. > > Samir Das > > > > > > On Thu, Jul 30, 2009 at 5:19 PM, Alan EVANS wrote: > >> > >> Hi Pierre, > >> ? ? ? ? Thanks for the rapid (and complete) response. > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Alan > >> > >> > >> On Thu, 30 Jul 2009, Pierre Bellec wrote: > >> > >>> Hi all, > >>> > >>> When reading Jim's email I recognized many of the questions I ran into in > >>> the recent past. Here's an update of the choices I've made at the time. > >>> > >>> There is first the question of the choice of the programming language for > >>> future developments. Coming from an applied maths background, matlab was > >>> sort of a natural choice. It lets you code powerful algorithms into > >>> concise > >>> code, has very decent runtime execution performance and great > >>> debugging/profiling capabilities. I don't have enough experiences with > >>> other > >>> languages (including R) to discuss the pros and cons in details, all I > >>> know > >>> is that it does the job for me and it is very well established in the > >>> biomedical engineering community, among others. There is obviously a > >>> concern > >>> regarding Matlab licenses. I have been trying over the past year to make > >>> my > >>> codes compatible with both Matlab and Octave (the GNU clone of Matlab) > >>> and > >>> it is almost painless. Octave is not as comfortable as Matlab in the > >>> development phase (mainly due to poor debugging tools), but to run code > >>> developed for Matlab it works. My conclusion is that Matlab is a > >>> perfectly > >>> viable choice to develop and disseminate image analysis/statistical > >>> analysis > >>> tools. But if for some reason (coding style or existing libraries for > >>> example) one wants to go for R, I think that would work too and it > >>> certainly > >>> did for Jason. It would only take a couple of motivated developers to set > >>> up > >>> coding guidelines and core functions to extend the Rminc package into > >>> something cleaner. > >>> > >>> Speaking of which, I started such an initiative about a year ago, using > >>> Matlab/Octave as my reference language. The project is hosted on google > >>> code > >>> and called NIAK . The objective for > >>> release > >>> 1.0 is to have a full pipeline for fMRI preprocessing and general linear > >>> model analysis. I am currently working with Felix Carbonell on breaking > >>> up > >>> fMRIstat into modules and including them in the pipeline. The fMRI > >>> preprocessing pipeline has been working for a couple of months now and > >>> was > >>> used notably by people from Jean Gotman and Alain Dagher's lab. The > >>> feedback > >>> is good so far even though NIAK is more oriented towards developers than > >>> end-users. I am pushing for the linear model pipeline to be integrated in > >>> the Cbrain project which would provide the final nice user-friendly > >>> interface. The timeline for first release is next winter, and I am > >>> planning > >>> on starting to advertise for the project at that point. > >>> > >>> I have developed some (hopefully) clean coding guidelines, and the > >>> pipeline > >>> runtime is powered by a generic pipeline manager called > >>> PSOM. > >>> PSOM is essentially an extension of PMP fully written in Matlab. I am > >>> currently using it at CLUMEQ (the McGill supercomputing center) and a > >>> pipeline of more than 15000 jobs was handled there smoothly. I believe > >>> that > >>> this framework is quite efficient at handling compicated pipelines with > >>> tons > >>> of parameters in a distributed computing environment, especially if one > >>> wants to play around with the flowchart and the choice of parameters. At > >>> least, it was designed with that purpose in mind. My plan is to use NIAK > >>> as > >>> the framework for all my future developments. I haven't done much > >>> publicity > >>> still, but Dr Christophe Grova and a couple of his students have adopted > >>> it > >>> as their development framework, as well as Gaolang Gang (a postdoc from > >>> Alan's lab) and the feedback from them is very positive. ?I would be more > >>> than happy if some developers were interested to develop their own > >>> toolbox > >>> in the NIAK framework, right now it is essentially a solo effort with > >>> input > >>> from Felix (and Keith in a sense) for the GLM part, and a couple of > >>> functions contributed by Vincent Perlbarg from my former lab in Paris. > >>> But > >>> of course, as I said before, Rminc is also a very nice package that would > >>> be > >>> a great basis for future development. > >>> > >>> I almost forgot... the MINC reader/writer ! So I had to get rid of EMMA. > >>> First because it is awfully slow, second because I wanted to avoid > >>> compiled > >>> code and third because I needed something that worked with Octave. There > >>> are > >>> functions called NIAK_READ_VOL and NIAK_WRITE_VOL that will do the job, > >>> and > >>> actually support NIFTI and ANALYZE as well (the output header structure > >>> is > >>> common to the three format, except for an HDR.DETAILS field that contains > >>> the complete list of format-specific fields). The reader/writer is just a > >>> wraper arond MINCHEADER, RAWTOMINC and MINCTORAW, so as long as the minc > >>> tools are installed it should work. I still have the idea to code a > >>> reader > >>> based on the internal matlab HDF5 and NETCDF libraries (which would be > >>> faster and cleaner) but I am not diving in because that will be a pure > >>> waste > >>> of time as far as octave is concerned. > >>> > >>> Let me know what you think, > >>> > >>> Pierre > >>> > >>> 2009/7/30 Alan EVANS > >>> > >>>> Hi Jim, > >>>> ? ? Somebody, has recently developed tools to by-pass the need for EMMA > >>>> (NIAK, Pierre ?). Can somebody on this cc-list clarify ?. > >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Alan > >>>> > >>>> > >>>> On Tue, 28 Jul 2009, EJ Nikelski wrote: > >>>> > >>>> ?Hi Howard and Alan, > >>>>> > >>>>> ?The purpose of this e-mail is to elucidate some of the ideas that > >>>>> were expressed in a recent meeting between Howard and myself and gets > >>>>> Alan's input. ?These ideas sprang from our discussion regarding our > >>>>> PiB data, and how best to write our analysis functions -- particularly > >>>>> given that the PiB data starts life as a 4-D volume. > >>>>> > >>>>> Background: > >>>>> ?Many years ago, immediately subsequent to the development of minc, > >>>>> Sean Marrett and other wrote a Matlab toolbox (EMMA), which allowed > >>>>> users to write Matlab functions capable of reading/writing minc > >>>>> volumes. ?This toolbox has remained heavily used around BIC, as it > >>>>> allows us to easily manipulate minc data. ?Unfortunately, there are a > >>>>> few problems: (1) EMMA requires a Matlab license, which is often > >>>>> expensive -- depending upon the whims of The Mathworks people and > >>>>> whether McGill is able to wrangle a site license, (2) EMMA is not > >>>>> really supported any more, and certainly isn't being actively > >>>>> developed, Matlab, while well suited for linear algebra, is a pretty > >>>>> poor excuse for a proper programming language. > >>>>> > >>>>> ?The alternative to using EMMA would be to continue along the path > >>>>> that Jason Lerch set with his RMINC package. ?Jason's RMINC package > >>>>> uses the R statistical software (instead of Matlab), and extends it, > >>>>> permitting it to read/write minc2 volumes. ?Advantages include: (1) R > >>>>> is a more sophisticated high-level functional language -- Matlab is > >>>>> tuned for linear algebra, and it shows, (2) R is specialized for > >>>>> statistical processing, Matlab is not, (3) R is an open source > >>>>> project, thus no license fees, and (4) R is actively being developed. > >>>>> > >>>>> ?Unfortunately, Jason's RMINC package has a few drawbacks: (1) it > >>>>> will not read/write 4-D volumes, which we *need* when processing PiB > >>>>> volumes, (2) Jason incorporated VBM functions into the RMINC package, > >>>>> making the package a bit messy, and (3) Jason wrote the interface > >>>>> using R S3 classes, which also makes the objects a bit messy and less > >>>>> maintainable. ?If we were to go down this road I would suggest taking > >>>>> inspiration from RMINC, and : (1) design it using S4 classes and the > >>>>> minc2 API, (2) remove the VBM code, creating a package comprised of > >>>>> R/minc accessor functions only (call it, say, mniMincIO), (3) the > >>>>> accessor functions would be able to deal with 4-D volumes, and (4) a > >>>>> simplified layer could be written on top of mniMincIO to present an > >>>>> EMMA-like simple interface. ?I believe that I could write the main > >>>>> accessor functions in 1 week. > >>>>> > >>>>> ?So the question is: Is this functionality worth the work? ?I believe > >>>>> that having solid R-based minc access functions would make life a lot > >>>>> easier for those of us who are writing our own analysis routines using > >>>>> minc volumes. ?Having said that, EMMA, as old and decrepit as it is, > >>>>> *can* currently do the job -- it just isn't as pretty, and convenient, > >>>>> and requires Matlab. ?I suppose we also need to consider the future of > >>>>> minc ... and whether minc *has* a future, given that the "provisional" > >>>>> nifti-1 standard appears to be very widely used and accepted. > >>>>> > >>>>> ?Ideas and suggestions? Alan? > >>>>> > >>>>> -Jim > >>>>> > >>>>> > >>>>> -- > >>>>> ================================= > >>>>> 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 > >>>>> > >>>>> > >>> > >>> > >>> -- > >>> Pierre Bellec > >>> Home page: http://wiki.bic.mni.mcgill.ca/index.php/PierreBellec > >>> Address: ? McConnel Brain Imaging Center, Webster 2B > >>> ? ? ? ? Montreal Neurological Institute > >>> ? ? ? ? 3801 University Street > >>> ? ? ? ? Montreal, Quebec, Canada H3A 2B4 > >>> tel: ? ? ? (001)(514) 398 5220 > >>> fax: ? ? ?(001)(514) 398 8948 > >>> > > > > > > > > -- > ================================= > 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 > > _______________________________________________ > MINC-users at bic.mni.mcgill.ca > http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users From jason at bic.mni.mcgill.ca Fri Jul 31 17:25:04 2009 From: jason at bic.mni.mcgill.ca (Jason Lerch) Date: Fri, 31 Jul 2009 17:25:04 -0400 Subject: [MINC-users] EMMA replacement? In-Reply-To: <20090731170740.T17358@mrs.mni.mcgill.ca> References: Message-ID: I have modules to read MINC2 volumes in both R (RMINC) and python (pyminc - I'm very creative with my naming scheme). If anyone wants either I'm happy to send them to you. RMINC is already on launchpad, and I keep meaning to put the pyminc stuff there too ... Little side node about R - while I absolutely love it for the majority of my stats work, it's not the best development language because it's too slow for most of what us imaging folks want. So every function that I use often I've rewritten in C, leaving R mostly as a nice shell for handling data/formulas and for graphics. But rewriting all core algorithms in C certainly slows down development. Jason On 31-Jul-09, at 5:07 PM, Alexandre CARMEL-VEILLEUX wrote: > Why not hitch your wagon behind a general purpose language like > Python? People are doing all thee kinds of things in Python already > (i.e.: http://www.astro.cornell.edu/staff/loredo/statpy/ for example) > > Plus if you make that leap, You can use RSPython, the R/SPlus bridge > to call any R function from python. There's at least two modules > that can deal with netCDF so the mechanics of opening MINC1 files > would not be too hard to do. Same for HDF5 / Minc2. > > Why limit this to MATLAB vs. R? A python interface would be much > more useful to the non-fMRI MINC users then R too... > > Alex > > On Fri, Jul 31, 2009 at 04:40:41PM -0400, EJ Nikelski wrote: >> Date: Fri, 31 Jul 2009 16:40:41 -0400 >> From: EJ Nikelski >> To: minc users >> Cc: "Howard Chertkow, Dr." >> Subject: Re: [MINC-users] EMMA replacement? >> >> Hi All, >> >> I hope that none of the original posters to this thread mind, but I >> would really like to bounce this conversion past all minc users, as >> all minc users may have an interest and/or input, and I believe that >> the points being made are stimulating and excellent grist for a >> sleepy >> Friday afternoon. >> >> Thanks Pierre for sharing your views and experiences. Matlab does >> indeed seem to be the currently reigning champ with regard to >> high-level multi-platform image manipulation software. Of course, >> most compelling is the fact that it can certainly do the job, as >> evidenced by Pierre's work, as well as by that done by the SPM group. >> So, it would appear as if any suggested move away from Matlab would >> need to be able to show a clear set of advantages over Matlab. >> >> Octave, whilst circumventing the Matlab licensing issues still has >> a number of problems. Firstly, and quite significantly, IMHO Octave >> is a second class citizen, which simply looks like an inferior Matlab >> wanna-be. I've been following Octave for years, and its development >> has always been stop-and-go, and the developers really don't seem >> willing to plot their own course. Personally, I would think long and >> hard before hitching my wagon to Octave. Secondly, Octave suffers >> from the fact that, like Matlab, it's a development language that is >> geared towards linear algebra -- not statistics. >> >> Now, I know that people can get terribly attached to their >> development environments, so I shall tread carefully. Whether one >> chooses Matlab or R seems to be a function of what one wishes to do. >> Matlab is all about linear algebra, which can indeed come in very >> handy when working with imaging volumes. R, on the other hand, is >> all >> about statistics, so ... if, for example, you are doing 80,000 >> regressions on a cortical surface, R would be an appropriate tool. >> Not >> only because R can do linear regression out-of-the-box, but it can >> also work (just as easily) with nonlinear regression, mixed-effects >> models, generalized additive models, and just about anything else >> that >> you might want to throw at it. In addition, it includes an extremely >> flexible and powerful programming language, extensible with C call >> (as >> needed). But wait, there's more! R can also make use of multiple >> cores, permitting easy parallelization (sp?) of processing (see the >> "doMC" and "foreach" packages). Of course, Matlab *can* do stats, as >> demonstrated by Pierre and Keith Worsley, and the SPM folks, however, >> I suggest that using Matlab for this purpose is like trying to peel a >> banana while wearing boxing gloves -- it's messy, and there are >> better >> alternatives. >> >> Finally, nobody has addressed the gorilla in the room --- has >> nifti-1 basically already killed minc, making all of this rather >> academic? >> >> >> Have a spliffy weekend, >> >> -Jim >> >> >> >> On Fri, Jul 31, 2009 at 1:04 PM, Samir Das >> wrote: >>> Hello all, >>> Just adding a bit to what Pierre said. I agree that his new >>> pipeline manager >>> PSOM and the NIAK toolkit is a great way to go, especially since >>> it can work >>> with Octave which is an open source language (therefore no pricey >>> licenses). >>> From what I understand, it takes care of almost all of the issues >>> that one >>> would run into for fMRI processing and it seems to be working >>> under quite >>> well for those that have started using it. That said, Pierre is >>> but one man >>> and ongoing development continues. The only potential drawback >>> (other than >>> one's choice of programming language) is that Octave sometimes >>> does not work >>> exactly the same way as Matlab, so work will be required to >>> maintain it. >>> The reason I am speaking up is because from the thread below, I >>> have seen >>> some comments about developing this in R. I have spent quite a bit >>> of time >>> using and understanding Jason's R libraries, particularly as it >>> relates to >>> VBM and cortical thickness, and I think I would be able to enhance >>> or add to >>> those libraries to enable things like 4D image importing and >>> manipulation. >>> My only problem is while I would be interested in looking into >>> something >>> like this, I really can't seem to find the time right now. >>> Again, that could be a moot point since Pierre has >>> already developed something quite nice. I just thought I would >>> pipe in. >>> Samir Das >>> >>> >>> On Thu, Jul 30, 2009 at 5:19 PM, Alan EVANS >>> wrote: >>>> >>>> Hi Pierre, >>>> Thanks for the rapid (and complete) response. >>>> Alan >>>> >>>> >>>> On Thu, 30 Jul 2009, Pierre Bellec wrote: >>>> >>>>> Hi all, >>>>> >>>>> When reading Jim's email I recognized many of the questions I >>>>> ran into in >>>>> the recent past. Here's an update of the choices I've made at >>>>> the time. >>>>> >>>>> There is first the question of the choice of the programming >>>>> language for >>>>> future developments. Coming from an applied maths background, >>>>> matlab was >>>>> sort of a natural choice. It lets you code powerful algorithms >>>>> into >>>>> concise >>>>> code, has very decent runtime execution performance and great >>>>> debugging/profiling capabilities. I don't have enough >>>>> experiences with >>>>> other >>>>> languages (including R) to discuss the pros and cons in details, >>>>> all I >>>>> know >>>>> is that it does the job for me and it is very well established >>>>> in the >>>>> biomedical engineering community, among others. There is >>>>> obviously a >>>>> concern >>>>> regarding Matlab licenses. I have been trying over the past year >>>>> to make >>>>> my >>>>> codes compatible with both Matlab and Octave (the GNU clone of >>>>> Matlab) >>>>> and >>>>> it is almost painless. Octave is not as comfortable as Matlab in >>>>> the >>>>> development phase (mainly due to poor debugging tools), but to >>>>> run code >>>>> developed for Matlab it works. My conclusion is that Matlab is a >>>>> perfectly >>>>> viable choice to develop and disseminate image analysis/ >>>>> statistical >>>>> analysis >>>>> tools. But if for some reason (coding style or existing >>>>> libraries for >>>>> example) one wants to go for R, I think that would work too and it >>>>> certainly >>>>> did for Jason. It would only take a couple of motivated >>>>> developers to set >>>>> up >>>>> coding guidelines and core functions to extend the Rminc package >>>>> into >>>>> something cleaner. >>>>> >>>>> Speaking of which, I started such an initiative about a year >>>>> ago, using >>>>> Matlab/Octave as my reference language. The project is hosted on >>>>> google >>>>> code >>>>> and called NIAK . The objective >>>>> for >>>>> release >>>>> 1.0 is to have a full pipeline for fMRI preprocessing and >>>>> general linear >>>>> model analysis. I am currently working with Felix Carbonell on >>>>> breaking >>>>> up >>>>> fMRIstat into modules and including them in the pipeline. The fMRI >>>>> preprocessing pipeline has been working for a couple of months >>>>> now and >>>>> was >>>>> used notably by people from Jean Gotman and Alain Dagher's lab. >>>>> The >>>>> feedback >>>>> is good so far even though NIAK is more oriented towards >>>>> developers than >>>>> end-users. I am pushing for the linear model pipeline to be >>>>> integrated in >>>>> the Cbrain project which would provide the final nice user- >>>>> friendly >>>>> interface. The timeline for first release is next winter, and I am >>>>> planning >>>>> on starting to advertise for the project at that point. >>>>> >>>>> I have developed some (hopefully) clean coding guidelines, and the >>>>> pipeline >>>>> runtime is powered by a generic pipeline manager called >>>>> PSOM. >>>>> PSOM is essentially an extension of PMP fully written in Matlab. >>>>> I am >>>>> currently using it at CLUMEQ (the McGill supercomputing center) >>>>> and a >>>>> pipeline of more than 15000 jobs was handled there smoothly. I >>>>> believe >>>>> that >>>>> this framework is quite efficient at handling compicated >>>>> pipelines with >>>>> tons >>>>> of parameters in a distributed computing environment, especially >>>>> if one >>>>> wants to play around with the flowchart and the choice of >>>>> parameters. At >>>>> least, it was designed with that purpose in mind. My plan is to >>>>> use NIAK >>>>> as >>>>> the framework for all my future developments. I haven't done much >>>>> publicity >>>>> still, but Dr Christophe Grova and a couple of his students have >>>>> adopted >>>>> it >>>>> as their development framework, as well as Gaolang Gang (a >>>>> postdoc from >>>>> Alan's lab) and the feedback from them is very positive. I >>>>> would be more >>>>> than happy if some developers were interested to develop their own >>>>> toolbox >>>>> in the NIAK framework, right now it is essentially a solo effort >>>>> with >>>>> input >>>>> from Felix (and Keith in a sense) for the GLM part, and a couple >>>>> of >>>>> functions contributed by Vincent Perlbarg from my former lab in >>>>> Paris. >>>>> But >>>>> of course, as I said before, Rminc is also a very nice package >>>>> that would >>>>> be >>>>> a great basis for future development. >>>>> >>>>> I almost forgot... the MINC reader/writer ! So I had to get rid >>>>> of EMMA. >>>>> First because it is awfully slow, second because I wanted to avoid >>>>> compiled >>>>> code and third because I needed something that worked with >>>>> Octave. There >>>>> are >>>>> functions called NIAK_READ_VOL and NIAK_WRITE_VOL that will do >>>>> the job, >>>>> and >>>>> actually support NIFTI and ANALYZE as well (the output header >>>>> structure >>>>> is >>>>> common to the three format, except for an HDR.DETAILS field that >>>>> contains >>>>> the complete list of format-specific fields). The reader/writer >>>>> is just a >>>>> wraper arond MINCHEADER, RAWTOMINC and MINCTORAW, so as long as >>>>> the minc >>>>> tools are installed it should work. I still have the idea to >>>>> code a >>>>> reader >>>>> based on the internal matlab HDF5 and NETCDF libraries (which >>>>> would be >>>>> faster and cleaner) but I am not diving in because that will be >>>>> a pure >>>>> waste >>>>> of time as far as octave is concerned. >>>>> >>>>> Let me know what you think, >>>>> >>>>> Pierre >>>>> >>>>> 2009/7/30 Alan EVANS >>>>> >>>>>> Hi Jim, >>>>>> Somebody, has recently developed tools to by-pass the need >>>>>> for EMMA >>>>>> (NIAK, Pierre ?). Can somebody on this cc-list clarify ?. >>>>>> Alan >>>>>> >>>>>> >>>>>> On Tue, 28 Jul 2009, EJ Nikelski wrote: >>>>>> >>>>>> Hi Howard and Alan, >>>>>>> >>>>>>> The purpose of this e-mail is to elucidate some of the ideas >>>>>>> that >>>>>>> were expressed in a recent meeting between Howard and myself >>>>>>> and gets >>>>>>> Alan's input. These ideas sprang from our discussion >>>>>>> regarding our >>>>>>> PiB data, and how best to write our analysis functions -- >>>>>>> particularly >>>>>>> given that the PiB data starts life as a 4-D volume. >>>>>>> >>>>>>> Background: >>>>>>> Many years ago, immediately subsequent to the development of >>>>>>> minc, >>>>>>> Sean Marrett and other wrote a Matlab toolbox (EMMA), which >>>>>>> allowed >>>>>>> users to write Matlab functions capable of reading/writing minc >>>>>>> volumes. This toolbox has remained heavily used around BIC, >>>>>>> as it >>>>>>> allows us to easily manipulate minc data. Unfortunately, >>>>>>> there are a >>>>>>> few problems: (1) EMMA requires a Matlab license, which is often >>>>>>> expensive -- depending upon the whims of The Mathworks people >>>>>>> and >>>>>>> whether McGill is able to wrangle a site license, (2) EMMA is >>>>>>> not >>>>>>> really supported any more, and certainly isn't being actively >>>>>>> developed, Matlab, while well suited for linear algebra, is a >>>>>>> pretty >>>>>>> poor excuse for a proper programming language. >>>>>>> >>>>>>> The alternative to using EMMA would be to continue along the >>>>>>> path >>>>>>> that Jason Lerch set with his RMINC package. Jason's RMINC >>>>>>> package >>>>>>> uses the R statistical software (instead of Matlab), and >>>>>>> extends it, >>>>>>> permitting it to read/write minc2 volumes. Advantages >>>>>>> include: (1) R >>>>>>> is a more sophisticated high-level functional language -- >>>>>>> Matlab is >>>>>>> tuned for linear algebra, and it shows, (2) R is specialized for >>>>>>> statistical processing, Matlab is not, (3) R is an open source >>>>>>> project, thus no license fees, and (4) R is actively being >>>>>>> developed. >>>>>>> >>>>>>> Unfortunately, Jason's RMINC package has a few drawbacks: (1) >>>>>>> it >>>>>>> will not read/write 4-D volumes, which we *need* when >>>>>>> processing PiB >>>>>>> volumes, (2) Jason incorporated VBM functions into the RMINC >>>>>>> package, >>>>>>> making the package a bit messy, and (3) Jason wrote the >>>>>>> interface >>>>>>> using R S3 classes, which also makes the objects a bit messy >>>>>>> and less >>>>>>> maintainable. If we were to go down this road I would suggest >>>>>>> taking >>>>>>> inspiration from RMINC, and : (1) design it using S4 classes >>>>>>> and the >>>>>>> minc2 API, (2) remove the VBM code, creating a package >>>>>>> comprised of >>>>>>> R/minc accessor functions only (call it, say, mniMincIO), (3) >>>>>>> the >>>>>>> accessor functions would be able to deal with 4-D volumes, and >>>>>>> (4) a >>>>>>> simplified layer could be written on top of mniMincIO to >>>>>>> present an >>>>>>> EMMA-like simple interface. I believe that I could write the >>>>>>> main >>>>>>> accessor functions in 1 week. >>>>>>> >>>>>>> So the question is: Is this functionality worth the work? I >>>>>>> believe >>>>>>> that having solid R-based minc access functions would make >>>>>>> life a lot >>>>>>> easier for those of us who are writing our own analysis >>>>>>> routines using >>>>>>> minc volumes. Having said that, EMMA, as old and decrepit as >>>>>>> it is, >>>>>>> *can* currently do the job -- it just isn't as pretty, and >>>>>>> convenient, >>>>>>> and requires Matlab. I suppose we also need to consider the >>>>>>> future of >>>>>>> minc ... and whether minc *has* a future, given that the >>>>>>> "provisional" >>>>>>> nifti-1 standard appears to be very widely used and accepted. >>>>>>> >>>>>>> Ideas and suggestions? Alan? >>>>>>> >>>>>>> -Jim >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ================================= >>>>>>> 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 >>>>>>> >>>>>>> >>>>> >>>>> >>>>> -- >>>>> Pierre Bellec >>>>> Home page: http://wiki.bic.mni.mcgill.ca/index.php/PierreBellec >>>>> Address: McConnel Brain Imaging Center, Webster 2B >>>>> Montreal Neurological Institute >>>>> 3801 University Street >>>>> Montreal, Quebec, Canada H3A 2B4 >>>>> tel: (001)(514) 398 5220 >>>>> fax: (001)(514) 398 8948 >>>>> >>> >>> >> >> >> >> -- >> ================================= >> 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 >> >> _______________________________________________ >> 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