Re: Installing MNI registration utilities
Hi Tim, First download netcdf 3.5 and install it. I think there is an rpm for it for some distributions on www.rpmfind.net. That makes it easier because you will not have to compile it (not that there is anything wrong with compiling!). Compile the latest version of MNI tools. Usually the trickiest part is getting the MNI configure to find netcdf. You can tell it where to find netcdf stuff in the configure command (check the INSTALL or README files). Then make, make test, make install (or something close to that). You need to intall the MNI average305. You can download this from their site and installation was straightforward. If all is well after that, you let freesurfer know where everything is. I do this by making edits to my .cshrc. Mine looks like this: setenv MINC_BIN_DIR /usr/pubsw/packages/mni/current/bin setenv MINC_LIB_DIR /usr/pubsw/packages/mni/current/lib setenv FREESURFER_HOME /home/freesurfer/freesurfer_alpha setenv CSURF_DIR /home/freesurfer/freesurfer_alpha setenv MINC_DIR /homes/nmrnew/home/inverse/minc #afni for freesurfer setenv AFNI_DIR /home/freesurfer/freesurfer_alpha/afni setenv NO_FSFAST setenv SUBJECTS_DIR /home/brian/FREESURFER_data setenv FSLDIR /apps/fsl When you source the Free*Env.csh it will not override the variables set in your .cshrc. I can't remember why my installation of minc is in the above directory structure. I think I read somewhere that freesurfer likes that location, but maybe not. If you set your environment variables, you should be fine. When you are finished test it all out by: 1) by converting a COR volume to mnc format and running mritotal yourinput.mnc talairach.xfm (this needs the MNI binaries and average305 to work) 2) mri_motion_correct2 -o . -i 001 -i 002 -i 003 (motion correcting and averaging-this does a super job for automated registration) or mri_motion_correct -o . -i 001 -i 002 -i 003 (depending on your version) If it all works, then freesurfer could find your MNI tools. Good luck. brian - Original Message - From: Timothy Souza [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 03, 2002 6:32 AM Subject: Installing MNI registration utilities HI all, When I first installed the latest version of Freesurfer, I did not initially install the MNI registration utilities from (www.bic.mni.mcgill.ca). I would now like to install these tools, but have been unable to locate instructions on doing this. Could someone provide me with brief instuctions, or point me to the appropriate documentation, to install the MNI tools utility post-Freesurfer installation? In the FreeSurferDefs.csh setup file, I currently have the env variable setenv NO_MINC as well. Thanks, Tm Souza -- Timothy Souza Brown University Department of Neuroscience [EMAIL PROTECTED] ph: 401-863-1258 fax: 401-863-1074
Re: Installing MNI registration utilities
Tim, When using mritotal to fit a dataset, you can specify -model and use the base name average152. make sure average152 and its various datasets (average152_16_blur.mnc, average152_8_blur.mnc, average152_8_dxyz.mnc, average152_16_mask.mnc, average152_8_mask.mnc, average152_headmask.mnc) are in the mni_autoreg directory or wherever you store your model. good luck. brian On Thu, 2002-10-03 at 13:32, Timothy Souza wrote: Brian, Thanks for the advice, I'll give it a shot. Out of curiosity, can MNI tools use the MNI average152 template dataset instead of the MNI average 305? We had been using the MNI_152 template in another normalization scheme we had worked out using flirt in FSL. Thanks, Tim Hi Tim, First download netcdf 3.5 and install it. I think there is an rpm for it for some distributions on www.rpmfind.net. That makes it easier because you will not have to compile it (not that there is anything wrong with compiling!). Compile the latest version of MNI tools. Usually the trickiest part is getting the MNI configure to find netcdf. You can tell it where to find netcdf stuff in the configure command (check the INSTALL or README files). Then make, make test, make install (or something close to that). You need to intall the MNI average305. You can download this from their site and installation was straightforward. If all is well after that, you let freesurfer know where everything is. I do this by making edits to my .cshrc. Mine looks like this: setenv MINC_BIN_DIR /usr/pubsw/packages/mni/current/bin setenv MINC_LIB_DIR /usr/pubsw/packages/mni/current/lib setenv FREESURFER_HOME /home/freesurfer/freesurfer_alpha setenv CSURF_DIR /home/freesurfer/freesurfer_alpha setenv MINC_DIR /homes/nmrnew/home/inverse/minc #afni for freesurfer setenv AFNI_DIR /home/freesurfer/freesurfer_alpha/afni setenv NO_FSFAST setenv SUBJECTS_DIR /home/brian/FREESURFER_data setenv FSLDIR /apps/fsl When you source the Free*Env.csh it will not override the variables set in your .cshrc. I can't remember why my installation of minc is in the above directory structure. I think I read somewhere that freesurfer likes that location, but maybe not. If you set your environment variables, you should be fine. When you are finished test it all out by: 1) by converting a COR volume to mnc format and running mritotal yourinput.mnc talairach.xfm (this needs the MNI binaries and average305 to work) 2) mri_motion_correct2 -o . -i 001 -i 002 -i 003 (motion correcting and averaging-this does a super job for automated registration) or mri_motion_correct -o . -i 001 -i 002 -i 003 (depending on your version) If it all works, then freesurfer could find your MNI tools. Good luck. brian - Original Message - From: Timothy Souza [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 03, 2002 6:32 AM Subject: Installing MNI registration utilities HI all, When I first installed the latest version of Freesurfer, I did not initially install the MNI registration utilities from (www.bic.mni.mcgill.ca). I would now like to install these tools, but have been unable to locate instructions on doing this. Could someone provide me with brief instuctions, or point me to the appropriate documentation, to install the MNI tools utility post-Freesurfer installation? In the FreeSurferDefs.csh setup file, I currently have the env variable setenv NO_MINC as well. Thanks, Tm Souza -- Timothy Souza Brown University Department of Neuroscience [EMAIL PROTECTED] ph: 401-863-1258 fax: 401-863-1074 -- Timothy Souza Brown University Department of Neuroscience [EMAIL PROTECTED] ph: 401-863-1258 fax: 401-863-1074
mri_surfglm!!!
I was able to answer my own question regarding thickness parameter maps from the other day by poking through the Linux/bin directory. Looking forward to using it. brian
Re: mri_surfglm!!!
Bruce, As suggested, I ran mris_euler_number on all of my surfaces. Comparing this output to that of the rh.thickness.asc shows that each surface has the same number of vertices as the thickness curvature. 9 ucsd-ybp00ib7lt:brian:surf mris_euler_number rh.pial euler # = v-e+f = 2g-2: 159216 - 477642 + 318428 = 2 -- 0 holes F =2V-4: 318428 = 318432-4 (0) 2E=3F:955284 = 955284 (0) total defect index = 0 10 ucsd-ybp00ib7lt:brian:surf mris_euler_number rh.white euler # = v-e+f = 2g-2: 159216 - 477642 + 318428 = 2 -- 0 holes F =2V-4: 318428 = 318432-4 (0) 2E=3F:955284 = 955284 (0) total defect index = 0 11 ucsd-ybp00ib7lt:brian:surf mris_euler_number rh.sphere euler # = v-e+f = 2g-2: 159216 - 477642 + 318428 = 2 -- 0 holes F =2V-4: 318428 = 318432-4 (0) 2E=3F:955284 = 955284 (0) total defect index = 0 12 ucsd-ybp00ib7lt:brian:surf mris_euler_number rh.orig euler # = v-e+f = 2g-2: 159216 - 477642 + 318428 = 2 -- 0 holes F =2V-4: 318428 = 318432-4 (0) 2E=3F:955284 = 955284 (0) total defect index = 0 13 ucsd-ybp00ib7lt:brian:surf mris_euler_number rh.inflated euler # = v-e+f = 2g-2: 159216 - 477642 + 318428 = 2 -- 0 holes F =2V-4: 318428 = 318432-4 (0) 2E=3F:955284 = 955284 (0) total defect index = 0 14 ucsd-ybp00ib7lt:brian:surf mris_euler_number rh.sphere.reg euler # = v-e+f = 2g-2: 159216 - 477642 + 318428 = 2 -- 0 holes F =2V-4: 318428 = 318432-4 (0) 2E=3F:955284 = 955284 (0) 17 ucsd-ybp00ib7lt:brian:surf mris_convert -c thickness rh.white rh.thickness.asc MRISreadBinaryCurvature: incompatible vertex number in file ./rh.thickness running cat rh.thickness.asc yields: . . . 159211 33.96269 -4.39503 -25.12681 0.0 159212 35.51861 -3.90923 -23.54850 0.0 159213 14.19163 79.48859 -24.66906 0.0 159214 12.90164 80.48796 -23.34212 0.0 159215 25.63698 81.31319 -18.60597 0.0 which is the same number of vertices as all of the above surfaces. thanks, brian On Mon, 2002-09-30 at 11:45, Bruce Fischl wrote: Hi Brian and Arvid, could you run the binary mris_euler_number on each of the relevant surfaces (?h.sphere.reg, ?h.orig, ?h.white, ?h.pial) and make sure that they all have the same number of vertices and faces, and that that matches what is in the ?h.thickness.asc file? If there is a mismatch in the # of vertices in any of the thicknesses, your results won't mean much. cheers, Bruce Bruce Fischl email: [EMAIL PROTECTED] Mass. General Hosp. NMR Center.tel:(617)-726-4897 Rm. 2328, Building 149, 13th Street fax:(617)-726-7422 Charlestown, MA 02129 USA On Mon, 30 Sep 2002, Brian C. Schweinsburg wrote: Hi Arvid, I did not find a correction for that problem yet. mris_convert may not be causing the problem, because I obtained the same result with an older version of it. Maybe something went wrong in the make final surfaces step. I am still looking for the source of the mismatch between the white and thickness vertices. However, the mri_surfglm program ran without crashing, despite the above problem. It seems like the mismatched vertices could be relevant for the parametric analyses, but I am not sure how/if it uses the pial or white surfaces. This program may use the ?h.sphere.reg which, because it is registered may not have the incompatible vertex number in file issue. I have to go back and look at the output. Sorry I couldn't be more helpful yet. Brian - Original Message - From: Arvid Lundervold [EMAIL PROTECTED] To: Brian Schweinsburg [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, September 30, 2002 9:15 AM Subject: Re: mri_surfglm!!! Dear Brian Please tell me (us) what was your solution to the mris_convert failure (-c thickness rh.white rh.thickness.asc ) Best regards Arvid Lundervold Arvid Lundervold, MD PhD Department of Physiology, University of Bergen AArstadveien 19, N-5009 Bergen, Norway Tel: +47 55 58 63 53 Fax: +47 55 58 64 10 Mob: +47 915 61 824 E-mail: [EMAIL PROTECTED] On 29 Sep 2002, Brian Schweinsburg wrote: I was able to answer my own question regarding thickness parameter maps from the other day by poking through the Linux/bin directory. Looking forward to using it. brian
Re: mri_surfglm!!!
here are the first 7 lines 000 12.61563 -89.76370 -3.82580 0.0 001 11.95849 -89.71229 -3.96183 0.0 002 10.82764 -89.53942 -4.15206 0.0 003 10.03118 -89.17944 -3.95924 0.0 004 14.26332 -89.59046 -5.39858 0.0 005 13.91159 -89.66550 -4.88632 0.0 006 12.91290 -89.80223 -4.61317 0.0 brian On Mon, 2002-09-30 at 12:26, Bruce Fischl wrote: what are the first couple of lines of the rh.thickness.asc file? On 30 Sep 2002, Brian Schweinsburg wrote: Bruce, As suggested, I ran mris_euler_number on all of my surfaces. Comparing this output to that of the rh.thickness.asc shows that each surface has the same number of vertices as the thickness curvature. 9 ucsd-ybp00ib7lt:brian:surf mris_euler_number rh.pial euler # = v-e+f = 2g-2: 159216 - 477642 + 318428 = 2 -- 0 holes F =2V-4: 318428 = 318432-4 (0) 2E=3F:955284 = 955284 (0) total defect index = 0 10 ucsd-ybp00ib7lt:brian:surf mris_euler_number rh.white euler # = v-e+f = 2g-2: 159216 - 477642 + 318428 = 2 -- 0 holes F =2V-4: 318428 = 318432-4 (0) 2E=3F:955284 = 955284 (0) total defect index = 0 11 ucsd-ybp00ib7lt:brian:surf mris_euler_number rh.sphere euler # = v-e+f = 2g-2: 159216 - 477642 + 318428 = 2 -- 0 holes F =2V-4: 318428 = 318432-4 (0) 2E=3F:955284 = 955284 (0) total defect index = 0 12 ucsd-ybp00ib7lt:brian:surf mris_euler_number rh.orig euler # = v-e+f = 2g-2: 159216 - 477642 + 318428 = 2 -- 0 holes F =2V-4: 318428 = 318432-4 (0) 2E=3F:955284 = 955284 (0) total defect index = 0 13 ucsd-ybp00ib7lt:brian:surf mris_euler_number rh.inflated euler # = v-e+f = 2g-2: 159216 - 477642 + 318428 = 2 -- 0 holes F =2V-4: 318428 = 318432-4 (0) 2E=3F:955284 = 955284 (0) total defect index = 0 14 ucsd-ybp00ib7lt:brian:surf mris_euler_number rh.sphere.reg euler # = v-e+f = 2g-2: 159216 - 477642 + 318428 = 2 -- 0 holes F =2V-4: 318428 = 318432-4 (0) 2E=3F:955284 = 955284 (0) 17 ucsd-ybp00ib7lt:brian:surf mris_convert -c thickness rh.white rh.thickness.asc MRISreadBinaryCurvature: incompatible vertex number in file ./rh.thickness running cat rh.thickness.asc yields: . . . 159211 33.96269 -4.39503 -25.12681 0.0 159212 35.51861 -3.90923 -23.54850 0.0 159213 14.19163 79.48859 -24.66906 0.0 159214 12.90164 80.48796 -23.34212 0.0 159215 25.63698 81.31319 -18.60597 0.0 which is the same number of vertices as all of the above surfaces. thanks, brian On Mon, 2002-09-30 at 11:45, Bruce Fischl wrote: Hi Brian and Arvid, could you run the binary mris_euler_number on each of the relevant surfaces (?h.sphere.reg, ?h.orig, ?h.white, ?h.pial) and make sure that they all have the same number of vertices and faces, and that that matches what is in the ?h.thickness.asc file? If there is a mismatch in the # of vertices in any of the thicknesses, your results won't mean much. cheers, Bruce Bruce Fischl email: [EMAIL PROTECTED] Mass. General Hosp. NMR Center.tel:(617)-726-4897 Rm. 2328, Building 149, 13th Street fax:(617)-726-7422 Charlestown, MA 02129 USA On Mon, 30 Sep 2002, Brian C. Schweinsburg wrote: Hi Arvid, I did not find a correction for that problem yet. mris_convert may not be causing the problem, because I obtained the same result with an older version of it. Maybe something went wrong in the make final surfaces step. I am still looking for the source of the mismatch between the white and thickness vertices. However, the mri_surfglm program ran without crashing, despite the above problem. It seems like the mismatched vertices could be relevant for the parametric analyses, but I am not sure how/if it uses the pial or white surfaces. This program may use the ?h.sphere.reg which, because it is registered may not have the incompatible vertex number in file issue. I have to go back and look at the output. Sorry I couldn't be more helpful yet. Brian - Original Message - From: Arvid Lundervold [EMAIL PROTECTED] To: Brian Schweinsburg [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, September 30, 2002 9:15 AM Subject: Re: mri_surfglm!!! Dear Brian Please tell me (us) what was your solution to the mris_convert failure (-c thickness rh.white rh.thickness.asc ) Best regards Arvid Lundervold Arvid Lundervold, MD PhD Department of Physiology, University of Bergen AArstadveien 19, N-5009 Bergen, Norway Tel: +47 55 58 63 53 Fax: +47
mris_convert failure with 9/17/02 snapshot
When using the the snapshot distribution fsa-20020917.tar.gz I get the following error messages when running: mris_convert -c thickness rh.white rh.thickness.asc MRISreadBinaryCurvature: incompatible vertex number in file ./rh.thickness the ascii file output, but all thickness values are zero: 000 12.61563 -89.76370 -3.82580 0.0 001 11.95849 -89.71229 -3.96183 0.0 002 10.82764 -89.53942 -4.15206 0.0 003 10.03118 -89.17944 -3.95924 0.0 004 14.26332 -89.59046 -5.39858 0.0 005 13.91159 -89.66550 -4.88632 0.0 The error file from subject/scripts reads (I am not sure from what I did to get this error, but...): MRISreadVertexPositions(/home/brian/FREESURFER_data/laura/surf/rh.thickness): surfaces differ. vset_read_vertex_set: MRISreadVertexPositions failed MRISreadVertexPositions(/home/brian/FREESURFER_data/laura/surf/rh.thickness): surfaces differ. vset_read_vertex_set: MRISreadVertexPositions failed MRISreadBinaryCurvature: incompatible vertex number in file /home/brian/FREESURFER_data/laura/surf/rh.pial MRISreadBinaryCurvature: incompatible vertex number in file /home/brian/FREESURFER_data/laura/surf/rh.inflated Am I doing something wrong and/or should I go back to an older mris_convert? thanks a bunch. brian
