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
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
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
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 -
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
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
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
