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