Re: mri_surfglm!!!
Hi Brian, I just finished that program a few weeks ago. This program allows you to do cross-subject/cross-group analysis of surface data by solving a GLM with ordinary least-squares (OLS). It also allows you to pre-smooth the surface values as well as include covariates (eg, age, gender, etc). Look at the help page (using mri_surfglm --help) for more info. Since it just uses OLS, it cannot do more sophisticated modeling of the variances (eg, modeling different groups with different variances), though we hope to integrate it with FLAME, a program that will be in FSL's next release. Those who do not have mri_surfglm in their bin directory can download it with the most recent snapshot from: ftp://surfer.nmr.mgh.harvard.edu/pub/dist/snapshots/ Let me know how it goes. doug 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 -- Douglas N. Greve, Ph.D. MGH-NMR Center [EMAIL PROTECTED] Phone Number: 617-724-2358 Fax: 617-726-7422
Re: mri_surfglm!!!
Hi Brian, you probably need to specify a target subject (--trgsubj). I've put a newer version of mri_surfglm at ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/FreeSurfer/. The guts of it have not changed, but it does better command-line error checking. doug Brian C. Schweinsburg wrote: Hi Doug, I was looking forward to a program like this. The help file is excellent! I used the info in it to run an analysis and everything ran okay except the very last part. It gave me an error message when the paint command was listed last (like the the gender-age example in the help file). It said something like it had no surface to paint to (I don't have the exact message because I am not in linux right now). So, I haven't seen the painted on results yet. thanks, brian - Original Message - From: Doug Greve [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 02, 2002 7:49 AM Subject: Re: mri_surfglm!!! Hi Brian, I just finished that program a few weeks ago. This program allows you to do cross-subject/cross-group analysis of surface data by solving a GLM with ordinary least-squares (OLS). It also allows you to pre-smooth the surface values as well as include covariates (eg, age, gender, etc). Look at the help page (using mri_surfglm --help) for more info. Since it just uses OLS, it cannot do more sophisticated modeling of the variances (eg, modeling different groups with different variances), though we hope to integrate it with FLAME, a program that will be in FSL's next release. Those who do not have mri_surfglm in their bin directory can download it with the most recent snapshot from: ftp://surfer.nmr.mgh.harvard.edu/pub/dist/snapshots/ Let me know how it goes. doug 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 -- Douglas N. Greve, Ph.D. MGH-NMR Center [EMAIL PROTECTED] Phone Number: 617-724-2358 Fax: 617-726-7422 -- Douglas N. Greve, Ph.D. MGH-NMR Center [EMAIL PROTECTED] Phone Number: 617-724-2358 Fax: 617-726-7422
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!!!
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!!!
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!!!
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!!!
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 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!!!
Dear Bruce I have: [freesurfer@arvid surf]$ mris_euler_number rh.inflated euler # = v-e+f = 2g-2: 138843 - 416523 + 277682 = 2 -- 0 holes F =2V-4: 277682 = 277686-4 (0) 2E=3F:833046 = 833046 (0) total defect index = 0 [freesurfer@arvid surf]$ mris_euler_number rh.orig euler # = v-e+f = 2g-2: 138843 - 416523 + 277682 = 2 -- 0 holes F =2V-4: 277682 = 277686-4 (0) 2E=3F:833046 = 833046 (0) total defect index = 0 [freesurfer@arvid surf]$ mris_euler_number rh.pial euler # = v-e+f = 2g-2: 138843 - 416523 + 277682 = 2 -- 0 holes F =2V-4: 277682 = 277686-4 (0) 2E=3F:833046 = 833046 (0) total defect index = 0 [freesurfer@arvid surf]$ mris_euler_number rh.qsphere euler # = v-e+f = 2g-2: 138942 - 416873 + 277916 = -15 -- 8 holes OBS!! F =2V-4: 277916 != 277884-4 (-36) 2E=3F:833746 != 833748 (-2) total defect index = 19 [freesurfer@arvid surf]$ mris_euler_number rh.white euler # = v-e+f = 2g-2: 138843 - 416523 + 277682 = 2 -- 0 holes F =2V-4: 277682 = 277686-4 (0) 2E=3F:833046 = 833046 (0) total defect index = 0 and: [freesurfer@arvid surf]$ mris_convert -c thickness rh.white rh.thickness.asc MRISreadBinaryCurvature: incompatible vertex number in file ./rh.thickness [freesurfer@arvid surf]$ head rh.thickness.asc 000 14.76140 -90.12495 -1.35007 0.0 001 14.47272 -90.17822 -1.45615 0.0 002 14.72146 -90.17825 -1.81132 0.0 ... [freesurfer@arvid surf]$ tail rh.thickness.asc ... 138841 26.59108 24.28280 65.88673 0.0 138842 25.87438 24.15891 64.43772 0.0 Is rh.qsphere making the problem here? How to solve? Regards Arvid On Mon, 30 Sep 2002, 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
