Re: Re: Re: Re: Question on segmentation
can you send it with the neighbor threshold at it's default value (1). thanks, Bruce On Fri, 1 Nov 2002, Xiangchuan Chen wrote: Hi Bruce, The content of the log file is listed below. Thanks for your help. Xiangchuan ## csurf0.9: log ending: Wed Oct 30 16:59:25 EST 2002 ## # Command Log # /softwares/freesurfer/freesurfer_alpha/bin/Linux/mri_fill -lval 255 -rval 80 -ccmask -T 8 -L /home/chxc/freesurfer-data/subjects/sheng_new/mri/tmp/ponscall.dat /home/chxc/freesurfer-data/subjects/sheng_new/mri/wm /home/chxc/freesurfer-data/subjects/sheng_new/mri/filled using 255 as fill val for left hemisphere. using 80 as fill val for right hemisphere. not using corpus callosum to mask possible location of pons. logging cutting plane coordinates to /home/chxc/freesurfer-data/subjects/sheng_new/mri/tmp/ponscall.dat... reading input volume...done. searching for cutting planes...done. filling left hemisphere... filling volume: pass 1 of 3...total of 483589 voxels filled... filling volume: pass 2 of 3...total of 16226171 voxels filled... filling volume: pass 3 of 3...total of 240285 voxels filled...done. filling right hemisphere... filling volume: pass 1 of 3...total of 483589 voxels filled... filling volume: pass 2 of 3...total of 16226171 voxels filled... filling volume: pass 3 of 3...total of 238617 voxels filled...done. filling degenerate left hemisphere surface locations... 275 voxels filled 0 voxels filled filling degenerate right hemisphere surface locations... 315 voxels filled 0 voxels filled combining hemispheres... writing output to /home/chxc/freesurfer-data/subjects/sheng_new/mri/filled... filling took 3.8 minutes Command Finished /softwares/freesurfer/freesurfer_alpha/bin/Linux/mri_tessellate /home/chxc/freesurfer-data/subjects/sheng_new/mri/filled 80 /home/chxc/freesurfer-data/subjects/sheng_new/surf/rh.orig slice 50: 2661 vertices, 2850 faces slice 60: 9074 vertices, 9312 faces slice 70: 17008 vertices, 17337 faces slice 80: 26619 vertices, 26946 faces slice 90: 36923 vertices, 37283 faces slice 100: 47136 vertices, 47487 faces slice 110: 60042 vertices, 60440 faces slice 120: 72312 vertices, 72739 faces slice 130: 82849 vertices, 83231 faces slice 140: 93501 vertices, 93872 faces slice 150: 102733 vertices, 103030 faces slice 160: 110701 vertices, 110956 faces slice 170: 117496 vertices, 117707 faces slice 180: 123160 vertices, 123326 faces slice 190: 127019 vertices, 127145 faces slice 200: 128240 vertices, 128242 faces slice 210: 128240 vertices, 128242 faces slice 220: 128240 vertices, 128242 faces slice 230: 128240 vertices, 128242 faces slice 240: 128240 vertices, 128242 faces slice 250: 128240 vertices, 128242 faces Command Finished /softwares/freesurfer/freesurfer_alpha/bin/Linux/mri_tessellate /home/chxc/freesurfer-data/subjects/sheng_new/mri/filled 255 /home/chxc/freesurfer-data/subjects/sheng_new/surf/lh.orig slice 40: 248 vertices, 295 faces slice 50: 3879 vertices, 4046 faces slice 60: 10443 vertices, 10680 faces slice 70: 18507 vertices, 18838 faces slice 80: 28264 vertices, 28592 faces slice 90: 37793 vertices, 38136 faces slice 100: 48335 vertices, 48706 faces slice 110: 60833 vertices, 61269 faces slice 120: 73737 vertices, 74149 faces slice 130: 84812 vertices, 85205 faces slice 140: 95460 vertices, 95812 faces slice 150: 104054 vertices, 104330 faces slice 160: 112226 vertices, 112503 faces slice 170: 118749 vertices, 118937 faces slice 180: 123555 vertices, 123692 faces slice 190: 126742 vertices, 126817 faces slice 200: 127470 vertices, 127470 faces slice 210: 127470 vertices, 127470 faces slice 220: 127470 vertices, 127470 faces slice 230: 127470 vertices, 127470 faces slice 240: 127470 vertices, 127470 faces slice 250: 127470 vertices, 127470 faces Command Finished /softwares/freesurfer/freesurfer_alpha/bin/Linux/mris_smooth -n 10 /home/chxc/freesurfer-data/subjects/sheng_new/surf/rh.orig /home/chxc/freesurfer-data/subjects/sheng_new/surf/rh.smoothwm smoothing for 10 iterations smoothing surface tessellation for 10 iterations... smoothing complete - recomputing first and second fundamental forms... writing smoothed curvature to /home/chxc/freesurfer-data/subjects/sheng_new/surf/rh.curv writing smoothed area to /home/chxc/freesurfer-data/subjects/sheng_new/surf/rh.area Command Finished /softwares/freesurfer/freesurfer_alpha/bin/Linux/mris_smooth -n 10 /home/chxc/freesurfer-data/subjects/sheng_new/surf/lh.orig /home/chxc/freesurfer-data/subjects/sheng_new/surf/lh.smoothwm smoothing for 10 iterations smoothing surface tessellation for 10 iterations... smoothing complete - recomputing first and second fundamental forms... writing smoothed curvature to /home/chxc/freesurfer-data/subjects/sheng_new/surf/lh.curv writing
Re: Re: Re: Re: Re: Question on segmentation
it looks fine. Does the filled volume have your editing changes in it? On Fri, 1 Nov 2002, Xiangchuan Chen wrote: It is as follows. Thanks, Xiangchuan ## csurf0.9: log ending: Fri Nov 1 00:07:13 EST 2002 ## # Command Log # /home/chxc/softwares/freesurfer_alpha/bin/Linux/mri_fill -lval 255 -rval 80 -ccmask -T 1 -L /home/chxc/freesurfer-data/subjects/sheng_new/mri/tmp/ponscall.dat /home/chxc/freesurfer-data/subjects/sheng_new/mri/wm /home/chxc/freesurfer-data/subjects/sheng_new/mri/filled using 255 as fill val for left hemisphere. using 80 as fill val for right hemisphere. not using corpus callosum to mask possible location of pons. logging cutting plane coordinates to /home/chxc/freesurfer-data/subjects/sheng_new/mri/tmp/ponscall.dat... updating initial cc seed to (127, 136, 128) corpus callosum seed point found at (127, 137, 132), TAL: (1.0, 4.0, -9.0) corpus callosum: cutting at slice 7, area 1671, (127, 137, 132) putative pons found at (110, 174) -- (127, 174, 111) pons seed point found at (125, 174, 114), TAL: (3.0, -14.0, -46.0) pons: cutting at slice 8, area 496, (125, 173, 114) rh seed point at (109, 137, 132): 5 neighbors on. searching for lh wm seed...found at (146, 138, 132) lh seed point at (146, 138, 132): 5 neighbors on. filling left hemisphere... total of 485249 voxels filled... total of 16224555 voxels filled... total of 0 holes filled total of 486104 voxels filled... total of 0 holes filled filling right hemisphere... total of 485249 voxels filled... total of 16224555 voxels filled... total of 0 holes filled total of 486104 voxels filled... total of 0 holes filled filling degenerate left hemisphere surface locations... 1075 voxels filled 16 voxels filled 1 voxels filled 0 voxels filled filling degenerate right hemisphere surface locations... 1075 voxels filled 16 voxels filled 1 voxels filled 0 voxels filled combining hemispheres... using variable coefficient diffusion to correct hemispheric overlap... 26: 486732 ambiguous voxels remaining 9: 40255 ambiguous voxels remaining 8: 15694 ambiguous voxels remaining 7: 5290 ambiguous voxels remaining 6: 1624 ambiguous voxels remaining 5: 607 ambiguous voxels remaining 4: 229 ambiguous voxels remaining 3: 76 ambiguous voxels remaining 2: 18 ambiguous voxels remaining 1: 0 ambiguous voxels remaining writing output to /home/chxc/freesurfer-data/subjects/sheng_new/mri/filled... filling took 5.8 minutes Command Finished Start Of Original Message Date: 2002-11-01Time: 17:04:00 From: Bruce Fischl ([EMAIL PROTECTED]) To: freesurfer ([EMAIL PROTECTED]) Subject: Re: Re: Re: Re: Question on segmentation can you send it with the neighbor threshold at it's default value (1). thanks, Bruce On Fri, 1 Nov 2002, Xiangchuan Chen wrote: Hi Bruce, The content of the log file is listed below. Thanks for your help. Xiangchuan ## csurf0.9: log ending: Wed Oct 30 16:59:25 EST 2002 ## # Command Log # /softwares/freesurfer/freesurfer_alpha/bin/Linux/mri_fill -lval 255 -rval 80 -ccmask -T 8 -L /home/chxc/freesurfer-data/subjects/sheng_new/mri/tmp/ponscall.dat /home/chxc/freesurfer-data/subjects/sheng_new/mri/wm /home/chxc/freesurfer-data/subjects/sheng_new/mri/filled using 255 as fill val for left hemisphere. using 80 as fill val for right hemisphere. not using corpus callosum to mask possible location of pons. logging cutting plane coordinates to /home/chxc/freesurfer-data/subjects/sheng_new/mri/tmp/ponscall.dat... reading input volume...done. searching for cutting planes...done. filling left hemisphere... filling volume: pass 1 of 3...total of 483589 voxels filled... filling volume: pass 2 of 3...total of 16226171 voxels filled... filling volume: pass 3 of 3...total of 240285 voxels filled...done. filling right hemisphere... filling volume: pass 1 of 3...total of 483589 voxels filled... filling volume: pass 2 of 3...total of 16226171 voxels filled... filling volume: pass 3 of 3...total of 238617 voxels filled...done. filling degenerate left hemisphere surface locations... 275 voxels filled 0 voxels filled filling degenerate right hemisphere surface locations... 315 voxels filled 0 voxels filled combining hemispheres... writing output to /home/chxc/freesurfer-data/subjects/sheng_new/mri/filled... filling took 3.8 minutes Command Finished /softwares/freesurfer/freesurfer_alpha/bin/Linux/mri_tessellate /home/chxc/freesurfer-data/subjects/sheng_new/mri/filled 80 /home/chxc/freesurfer-data/subjects/sheng_new/surf/rh.orig slice 50: 2661 vertices, 2850 faces
Re: a feature request
Hi Darren, you can load alternate surface configurations with file-load surface configuration, but each one must have the same number of vertices and faces as the main one. We are working on a new viewer that will let you load multiple different surfaces, but it will be a while. Bruce p.s. you can also script the loading of whatever surfaces you want in tcl using LoadMainSurface, LoadCanonicalSurface and LoadOriginalSurface. On Wed, 30 Oct 2002, Darren Weber wrote: Dear Bruce et al., it would be nice, in future, to have options to load non-default surface(s) into tkmedit. At present, you can only define a main surface and it will then go looking for predefined associated surfaces. For example, I have surfaces called rh.scalp, rh.innerskull and rh.outerskull (~2,500 vertices, small files). It is only possible to load one of these at a time, but they are handled very well. It is possible to fool tkmedit by removing all the default rh.orig etc files and renaming these unconventional surfaces with conventional names. Thanks, Darren -- Darren Weber, PhD Student Cognitive Neuroscience, School of Psychology Flinders University of SA, GPO Box 2100, Adelaide, SA 5001, Aust. Ph: (61 8) 8201 3889, Fax: (61 8) 8201 3877 http://203.3.164.46/~dlw/homepages/index.html
Re: thickness analysis display
Hi Darren, the -log10(p) transform simply means you're looking at the exponent, with increasing values meaning more significant. For example, if your threshold were set to: fthresh = 1 fmid = 2 fslope = 1 nothing with p1e-1 would be colored, the mid point of the color scale would be p=1e-2 and the full saturation would be fmid+1/fslope=1e-3. If fslope is too confusing (which it is to most people) you can set fmax instead. Note that in your example you should be using log10 not log: -log10(0.05) ans = 1.3010 so setting fthresh = 1.3 would give you an effective threshold of .05 (instead of .1 in the example above). 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 Wed, 30 Oct 2002, Darren Weber wrote: Dear Doug et al, I've completed mris_surfglm on the cortical thickness, comparing two groups. For a linear regression, I would normally check the assumptions of linearity, homoscedasticity and normality in the residuals, but for 250,000 analyses, it's a daunting, if not impossible, task! So, lets assume the linear model applies. I need to confirm and clarify a few points on how to display/threshold the stats. Firstly, I followed the --help option examples and saved the output stats using: --sigt ./glm/group-sigt-rh.w paint I can now load these values as an overlay on the target subject surface of choice, great. Now the questions arise as to what quantity this is and how to use the overlay threshold GUI. Firstly, what quantity is it? According to the --help option: #Save the signficance (p-value) of the t-ratio of the contrast. The #value is actually the -log10 of the significance with the same #sign as the t-ratio from which it was computed. The significance #is computed from a double-sided t-test and is NOT corrected for #multiple comparisons across space. fmt is the format (see OUTPUT #FORMATS). So, the output values are not t or p, but -log10(p). Why is this so? I don't understand the advantage of doing this transform on the p-values. If so, and this should be simple, do we calculate a threshold of p = .05 as: p = .05; thresh = -log(p) thresh =2.9957 This would be a 2-tail threshold for any value of p. How would you obtain a 1-tailed threshold? Perhaps multiply p by 2, ie: thresh = -log(p*2) thresh =2.3026 OK, so we get a threshold value somehow. I'm not sure how to use the overlay threshold GUI, which has three slides and a slope value. The tksurfer manual does not describe the threshold controls, it only contains the following description: Overlay File Display Options To select which overlay to show, use the View-Overlay Layer submenu. The field names are automatically set to the file name loaded. You can change this name by typing a new one into the information area in the Tool window. The display for the current overlay can be configured in the View-Configure-Configure Overlay Display dialog. You can select the color scale to use with the radio buttons in the top area of the dialog. The Truncate option can be checked to turn off the display of negative values. Check the Reverse option to reverse the sign of the values as they are drawn in the color scale. View- Inverse and Complex are reserved for future upgrades. What does each slider do and how would you best set these so that the above threshold values will be applied accurately? Thanks very much, Darren -- Darren Weber, PhD Student Cognitive Neuroscience, School of Psychology Flinders University of SA, GPO Box 2100, Adelaide, SA 5001, Aust. Ph: (61 8) 8201 3889, Fax: (61 8) 8201 3877 http://203.3.164.46/~dlw/homepages/index.html
Re: fov?
Hi Tom, I don't believe it matters, except for displaying stuff in tksurfer. Bruce On Mon, 28 Oct 2002, Tom Holroyd wrote: Hi. I converted some genesis I.??? files off a GE scanner and the COR-.info file had a fov of 0. Everything else was OK but the surface coordinates came out strange and the surface was sort of inside out. I set fov to .256 by hand, and everything came out OK. Then I realized that was wrong, and set it to .240, but the generated surface was identical, though the viewer showed a slight change in the default size. Does fov matter for anything? Maybe it only affects the viewer? Dr. Tom Holroyd I am, as I said, inspired by the biological phenomena in which chemical forces are used in repetitious fashion to produce all kinds of weird effects (one of which is the author). -- Richard Feynman, _There's Plenty of Room at the Bottom_
Re: registration of whole cortical sheet
Hi Darren, we usually start with one ?h.sphere, register a bunch of subjects to it to create ?h.sphere.reg files, then create a new template with them. cheers, Bruce On Fri, 11 Oct 2002, Darren Weber wrote: Thanks, Bruce. mris_make_template --help stops at 'valid options are:' :-( One of the input parameters is a surface name - I suppose 'orig', 'white', 'pial' etc are valid. I'm not sure what surface to specify; is it 'sphere' or 'inflated' or something else? Cheers, Darren - Original Message - From: Bruce Fischl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 11, 2002 12:12 PM Subject: Re: registration of whole cortical sheet Hi Darren, that's pretty much the way I generated the lh and rh templates we use. There's a binary named mris_make_template,which you probably have, that will take a bunch of surface models and construct a template (.tif) from them. You'll have to name the individual surface lh or rh, since it's expecting a hemisphere. The mris_register binary is actually smart enough to change it's default parameters if the target is from a single surface (it uses a more rigid morph). Good luck, Bruce On Fri, 11 Oct 2002, Darren Weber wrote: Dear Bruce et al, my query is about how to register cortical surfaces across X subjects, given that we have modified the usual left/right surface separation. Some time ago we discussed how to extract a complete cortical surface, rather than the left/right hemi surfaces. The purpose of this being to use a complete cortical surface for ERP/MEG source modelling methods. This involves a couple of modifications to the wm volume and the usual inputs to the fill white matter process (see attached shell script for details). In my case, the resulting surfaces are called rh.*, although they actually contain both left and right hemispheres, joined by the corpus callosum (not strictly cortex, but unavoidable in this approach). For source modelling, these surfaces are nice. Having obtained these surfaces for nearly 20 subjects, we've raised the possibility of doing a cortical thickness analysis for two groups, controls and PTSD patients. This requires that any vertex A is located in the same coordinate system and location for all subjects, so they must be coregistered (Fischl et al, 1999, Human Brain Mapping 8:272-284; http://www3.interscience.wiley.com/cgi-bin/issuetoc?ID=67501785). Normally, I assume the registration process morphs each left/right hemi cortex into two unit spheres (rather than morphing each hemi cortex onto the left/right hemisphere of one unit sphere). So, many of the examples in Fischl et al (1999) illustrate one hemisphere or another. Thus, we normally have lh.sphere and rh.sphere, two unit spheres, one for each hemi cortex surface. Further, the spherical sulcal patterns of each lh.sphere and rh.sphere are then further morphed (non-linear) to match the patterns of some average template. Obviously the whole cortical surfaces we have are not separated into lh/rh, rather the rh contains both. My concern here is with this template - I don't know much about it. I assume the template (average7) is specific for each left/right hemi-cortex. It might not be a good template for our data, which contains the whole cortex, including the sagittal fissure and corpus callosum. Can you recommend a template for registration of these subjects' surfaces? Is it reasonable to use one subject surface as a template for all others? If so, what do you think of a two stage process, first registering all subjects to subject X, then averaging across all subjects to create a study specific average, then reregister all subjects to this average? Many thanks for your consideration, Darren -- Darren Weber, PhD Student Cognitive Neuroscience, School of Psychology Flinders University of SA, GPO Box 2100, Adelaide, SA 5001, Aust. Ph: (61 8) 8201 3889, Fax: (61 8) 8201 3877 http://203.3.164.46/~dlw/homepages/index.html
Re: registration of whole cortical sheet
Hi Darren, that's pretty much the way I generated the lh and rh templates we use. There's a binary named mris_make_template,which you probably have, that will take a bunch of surface models and construct a template (.tif) from them. You'll have to name the individual surface lh or rh, since it's expecting a hemisphere. The mris_register binary is actually smart enough to change it's default parameters if the target is from a single surface (it uses a more rigid morph). Good luck, Bruce On Fri, 11 Oct 2002, Darren Weber wrote: Dear Bruce et al, my query is about how to register cortical surfaces across X subjects, given that we have modified the usual left/right surface separation. Some time ago we discussed how to extract a complete cortical surface, rather than the left/right hemi surfaces. The purpose of this being to use a complete cortical surface for ERP/MEG source modelling methods. This involves a couple of modifications to the wm volume and the usual inputs to the fill white matter process (see attached shell script for details). In my case, the resulting surfaces are called rh.*, although they actually contain both left and right hemispheres, joined by the corpus callosum (not strictly cortex, but unavoidable in this approach). For source modelling, these surfaces are nice. Having obtained these surfaces for nearly 20 subjects, we've raised the possibility of doing a cortical thickness analysis for two groups, controls and PTSD patients. This requires that any vertex A is located in the same coordinate system and location for all subjects, so they must be coregistered (Fischl et al, 1999, Human Brain Mapping 8:272-284; http://www3.interscience.wiley.com/cgi-bin/issuetoc?ID=67501785). Normally, I assume the registration process morphs each left/right hemi cortex into two unit spheres (rather than morphing each hemi cortex onto the left/right hemisphere of one unit sphere). So, many of the examples in Fischl et al (1999) illustrate one hemisphere or another. Thus, we normally have lh.sphere and rh.sphere, two unit spheres, one for each hemi cortex surface. Further, the spherical sulcal patterns of each lh.sphere and rh.sphere are then further morphed (non-linear) to match the patterns of some average template. Obviously the whole cortical surfaces we have are not separated into lh/rh, rather the rh contains both. My concern here is with this template - I don't know much about it. I assume the template (average7) is specific for each left/right hemi-cortex. It might not be a good template for our data, which contains the whole cortex, including the sagittal fissure and corpus callosum. Can you recommend a template for registration of these subjects' surfaces? Is it reasonable to use one subject surface as a template for all others? If so, what do you think of a two stage process, first registering all subjects to subject X, then averaging across all subjects to create a study specific average, then reregister all subjects to this average? Many thanks for your consideration, Darren -- Darren Weber, PhD Student Cognitive Neuroscience, School of Psychology Flinders University of SA, GPO Box 2100, Adelaide, SA 5001, Aust. Ph: (61 8) 8201 3889, Fax: (61 8) 8201 3877 http://203.3.164.46/~dlw/homepages/index.html
Re: trouble converting to COR, can't stat ??
Hi Scott, are you still having problems? Did you try specifying the directory with the COR files, instead of one of the individual files? What are you trying to convert to? I you're trying to convert I.* files, you should use: mri_convert path to I.*/I.001 $SUBJECTS_DIR/subject name/mri/orig cheers, Bruce On Fri, 4 Oct 2002, Scott Laurence Fairhall wrote: Ver 0.9 (33y) On 2 Oct 2002, at 2:12, Brian C. Schweinsburg wrote: Hi Scott, What version of freesurfer are you using? brian - Original Message - From: Scott Laurence Fairhall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 01, 2002 11:20 PM Subject: trouble converting to COR, can't stat ?? Hello, I'm probably doing something very stupid but I can't figure out what. When I attempted to load in my anatomical files through the GUI I recieved an error saying: Convert (scott) failed - working on: orig/a/I.%03d So I tried the tutorial (bert) files through the command line and got: --- [all@ikirk 001]$ mri_convert -it cor cor-001 . mri_convert -it cor cor-001 . reading from cor-001... corRead(): can't stat cor-001 --- and I have no clue what's going wrong. Any advice would be very much appreciated. Scott Fairhall
Re: trouble converting to COR, can't stat ??
Hi Scott, when specifying a COR volume, just give it a directory name (not the name of one of the files). 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 Wed, 2 Oct 2002, Scott Laurence Fairhall wrote: Hello, I'm probably doing something very stupid but I can't figure out what. When I attempted to load in my anatomical files through the GUI I recieved an error saying: Convert (scott) failed - working on: orig/a/I.%03d So I tried the tutorial (bert) files through the command line and got: --- [all@ikirk 001]$ mri_convert -it cor cor-001 . mri_convert -it cor cor-001 . reading from cor-001... corRead(): can't stat cor-001 --- and I have no clue what's going wrong. Any advice would be very much appreciated. Scott Fairhall
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!!!
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: RF bias correction with mri_convert
p.s. what we do is not really bias field estimation/correction, but something much more aggressive, really a pre-segmentation, which accounts for bias fields as well as tissue inhomogeneity. If what you want is really the bias field for some other purpose, you're probably better of using the EM stuff from the FSL (unless you can measure it directly with your scanner, which is the best solution!). Bruce On Thu, 29 Aug 2002, Stephen Smith wrote: Hi - no, it doesn't - that is part of the initial freesurfer processing (which estimates white matter and then estimates bias field on the basis of white matter points), not the format conversion. ttfn, Steve. On Thu, 29 Aug 2002, Darren Weber wrote: Dear Bruce et al, does mri_convert automatically apply RF bias field estimation/correction? If it can do the RF bias correction, what is the best command line option for this? Take care, Darren -- Darren Weber, PhD Student Cognitive Neuroscience, School of Psychology Flinders University of SA, GPO Box 2100, Adelaide, SA 5001, Aust. Ph: (61 8) 8201 3889, Fax: (61 8) 8201 3877 http://203.3.164.46/~dlw/homepages/index.html Stephen M. Smith Head of Image Analysis, FMRIB Oxford University Centre for Functional MRI of the Brain John Radcliffe Hospital, Headington, Oxford OX3 9DU, UK +44 (0) 1865 222726 (fax 222717) [EMAIL PROTECTED] http://www.fmrib.ox.ac.uk/~steve
Re: Tksurfer problem
check the fov field in the subject's mri/T1/COR-.info file. If it is 0, then change it to .256. cheers, Bruce On Mon, 26 Aug 2002, Rutvik Desai wrote: Hello, During the Edit Segmentation stage, the Tksurfer window does not seem to recognize any mouse operations. The TkMedit display and controls work fine. But the Tksurfer window is black to begin with. I can see the 3D surface if I zoom out (reduce the brain size) a great deal. After that. the cursor and the mouse positions are always in the center, regardless of where you move or click the mouse in the display. There are no white dots as described in the manual, even after redrawing. I have tried different static versions of Tksurfer provided with the distribution, but all give the same result. Any ideas are welcome. thanks, Rutvik
Re: eeg-toolbox release
Hi Darren, speaking for myself, I don't consider this off-topic for the freesurfer list. Congratulations on getting it done. Bruce On Fri, 16 Aug 2002, Darren Weber wrote: Hi, there is a new release of the matlab eeg-toolbox/mri-toolbox available via http://eeg.sourceforge.net/. This release incorporates a new mesh_shrinkwrap function (alpha release) for generating a surface from an Analyze MRI volume. If given the Analyze version of the original input to freesurfer (eg, mri_convert -oid 1 0 0 -ojd 0 1 0 -okd 0 0 1 orig orig.asc), it will output a scalp in the same space as the freesurfer cortex asc file (created by freesurfer command, mris_convert). It is possible to use the FSL BET program to get a skull from volume from this orig volume, which can be tesselated also. Please see the mesh_3shell_script for an example of this process. This release also updates the mesh plot functions, to provide overlays and transparency. For recipients who would like to hear about or discuss releases of this toolbox, please subscribe to the eeg-users email list. This will be the last announcement for this toolbox that will be sent to related email lists. I sincerely apologise to regular users of these lists and their administrators for this 'off-topic' announcement, but I hope the distribution of these tools might benefit other users of scan, freesurfer, spm, fsl, etc tools. All communication related to this matlab toolbox will hereafter be conducted in [EMAIL PROTECTED] All the best with your work. Kind regards, Darren -- Darren Weber, PhD Student Cognitive Neuroscience, School of Psychology Flinders University of SA, GPO Box 2100, Adelaide, SA 5001, Aust. Ph: (61 8) 8201 3889, Fax: (61 8) 8201 3877 http://203.3.164.46/~dlw/homepages/index.html
Re: MNI space in freesurfer
Hi Tim, you could spatialize normalize the data before running mri_convert, the only down side is that you have added an interpolation to the processing that you didn't need to, and so sacrificed some resolution. You will probably want to create a talairach.xfm file in the subject's mri/transforms directory that is the identity so that the software knows that the data is in talairach coordinates (you'll also have to add a line to the mri/orig/COR-.info file speficying where the transform is with: xform subjects_dir/subject name/mri/transforms/talairach.xfm Note that this must be done before the rest of the processing so that the other steps both know that the data has been talairached, and also propagate that information down the pipeline. 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 Fri, 9 Aug 2002, Timothy Souza wrote: Hi all, I'm a fairly new user of Freesurfer, although I have been a user of AFNI for some time. I have a question related to using MNI space in freesurfer. Currently we have been normalizing our data to the MNI_avg_152 template, using FLIRT in FSL. I understand that Freesurfer can be set up to use MNI tools for this process, which is implemented during the cortical reconstruction stream. Is there any reason why we wouldn't be able to use MNI normalized data as our raw data before running mri_convert? Will converting raw data to COR format remove this data from MNI space, and put it into a new space? Or, is there a particular reason why MNI normalization occurs midstream in the freesurfer process? Thanks, Tim Souza -- Timothy Souza Brown University Department of Neuroscience [EMAIL PROTECTED] ph: 401-863-1258 fax: 401-863-1074
Re: primate scans
Hi Tom, we've never really used our skull stripping for primates, so I'm not surprised to hear that it fails. It's good to know that BET works well, so I would definitely use it instead of ours. In general, we have been working over the last year or so to integrate with the Oxford tools, so hopefully things are pretty interchangeable now. However, I would investigate the error message you got a bit further, as it sounds like something went wrong in your intensity normalization. Did you look at your T1 volume? It should have wm intensities at or close to 110. For primates, this is usually done by selecting a couple of control points in the white matter, and running the normalization with them (with humans is uses the auto-talairaching, which of course will fail on a monkey). As for the libppm stuff, I think we have fixed that in the most recent version (since we don't really use ppm). Try getting a new version. 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, 15 Jul 2002, Tom Schoenemann wrote: Hello, When we try to strip the skull on a primate brain, it fails with the following message: lots of stuff deleted **WATERSHED* preflooding height equal to 25 percent Sorting... first estimation of the COG coord: x=129 y=91 z=127 r=73 first estimation of the main basin volume: 1647886 voxels Error intensity too high...probable pbm Command Finished In the manual is says to try setting seed points using TKmedit. However, when we try to open TKmedit we get: /home/opt2/freesurfer_alpha/bin/Linux/tkmedit bonobo.jill orig -csurf /home/opt2/freesurfer_alpha/bin/Linux/tkmedit: error while loading shared libraries: libppm.so.1: cannot open shared object file: No such file or directory Command Finished Clearly we are missing something. The operating system was recently upgraded. Is it possible something was left out? Any suggestions what we might try? -Tom P. Thomas Schoenemann Assistant Professor Department of Anthropology University of Pennsylvania Philadelphia, PA 19104-6398 Phone: (215) 573-7671 Fax: (215) 898-7462 E-mail: [EMAIL PROTECTED] Homepage: http://www.sas.upenn.edu/~ptschoen/
Re: Problems with csurf (tksurfer)
one workaround is to use tksurfer.static, which will be slower, but should work. Bruce On Thu, 11 Jul 2002, Nicholas Knouf wrote: I'm having problems running tksurfer on a couple Linux machines (they are running a modified version (MIT athena) of RedHat 7.1). Here is the output of the log window: env tksurferinterface=csurf patchname= /raid-5/new_fs/freesurfer_alpha/bin/Linux/tksurfer -010719ao rh inflated -tcl /tmp/TmpTclSurf.3275 Couldn't create output file .xdebug_/raid-5/new_fs/freesurfer_alpha/bin/Linux/tksurferltMNIread: could not open file /raid-5/time/reconstructions/010719ao/mri/transforms/talairach.xfm No such file or directory tksurfer.tcl: startup done Window type not found! surfer: current subjects dir: /raid-5/time/reconstructions surfer: in subjects scripts dir surfer: session root data dir ($session) set to: surfer: /mit/nklab-5/time/reconstructions/010719ao surfer: /raid-5/time/reconstructions/010719ao/mri/T1/COR-.info surfer: Talairach xform file not found (ignored) surfer: vertices=126867, faces=253728 tksurfer: interface: /raid-5/new_fs/freesurfer_alpha/lib/tcl/tksurfer.tcl tksurfer: run tcl script: /tmp/TmpTclSurf.3275 surfer: single buffered window surfer: curvature read: min=-1.54 max=1.19 The surfer tools window shows up, but no output window appears with the inflated brain. This is for a subject that we have not yet Talairached. However, when I run csurf (and tksurfer) on the same subject on machine that has an earlier version of RedHat (ie, MIT athena) installed, everything works perfectly. The only difference in the log files between the two machines (of course ignoring the tmp files) is the line (for the machine that doesn't work) Window type not found!. Now, it would be impossible for me to describe all of the differences between the two RedHat versions here (since MIT changes the default distribution radically when releasing new versions of Athena); however, the only relevant difference I can discover between the two systems is a difference in TCL-TK versions. For the system where tksurfer works, it has TCL-TK version 8.0.5 installed, while for the system where tksurfer doesn't work, it has TCL-TK version 8.3.1 installed. Do you know of any issues between these two versions of TCL-TK that might cause this problem? Or is there any clue in the log file that you might be able to use to point me in a new direction to look? Thanks, Nick Knouf
Re: quantifying surface area
you should convert the patch to ascii using mris_convert -p and get the vertex #s from the ascii file. Also, I think you must have an old version of mris_convert (as every other area is 0, which it certainly shouldn't be). Try taking a new one from surfer.nmr.mgh.harvard.edu:/space/outgoing/fsdev. cheers, Bruce On Thu, 13 Jun 2002, Tom Schoenemann wrote: Thanks Bruce, A few more questions: On Thursday, June 13, 2002, at 03:00 PM, Bruce Fischl wrote: Hi Tom, the mris_convert command line for converting curvature files is a bit arcane (my fault). You need to specify that it is a curvature format file with the -c option, and which one you want, but then you still need an input surface in order to read it. So, from the surf directory you could do: mris_convert -c ./lh.area lh.orig lh.area.asc the values in the file lh.area.asc will then be the surface area of each vertex. Here is the first few lines of the lh.area.asc file that we created this way: %more lh.area.asc 000 -9.5 -97.5 -23.5 161.92000 001 -10.5 -97.5 -23.5 0.0 002 -11.5 -97.5 -23.5 163.2 003 -7.5 -97.5 -24.5 0.0 004 -8.5 -97.5 -24.5 162.88000 005 -9.5 -97.5 -24.5 0.0 006 -10.5 -97.5 -24.5 162.88000 007 -11.5 -97.5 -24.5 0.0 This doesn't match what the manual states should be the output (see below). I assume that the first number of each line is the vertex identifier. The next 3 are, I'm guessing, the X, Y, Z coordinates for that vertex. Is the last number the average area of the triangles that meet at that vertex? If so, what are the units? And why do all the odd numbered vertices have 0.0 as their last number? Note that the vertex #s are invariant across the different surface representations, so you should be able to relate it to the vertices in the patches with no trouble. OK but how do we get the list of vertices in the patch? Don't we need the .area file for this patch? How is this obtained, e.g., from our rh.occip.patch.3d file? -Tom On Thu, 13 Jun 2002, Tom Schoenemann wrote: Hi again, On Friday, June 7, 2002, at 06:38 PM, Bruce Fischl wrote: Hi Tom, we write out an ?h.area file that contains the area of every vertex in the tessellation (the average area of all triangles it is a member of). You should be able to convert it to ascii using mris_convert in the usual way. When you say you write out an ?h.area file..., what exactly does this mean? In the process of following the tutorial, the program has produced files in the surf directory of the subject we are working on named: rh.area and lh.area, as well as a files for patches named rh.occip.patch.3d and rh.occip.patch.flat. The manual mentions a -p flag for mris_convert to use for patches. Does this mean we don't need to produce some sort of a .area file for patches? We tried doing mris_convert rh.area rh.area.asc while in the surf directory and got only a segmentation fault after a fair amount of time (it was doing something). Any thoughts about what is wrong? Also, in the manual under the section for mris_convert (p. 128-129), nothing is said about the area of every vertex being listed: The first (non-comment) line contains the number of vertices nvertices and the number of faces nfaces in the tessellation. The is followed by the nvertices lines of 3 floating point numbers and one integer. The 3 floats are the x y z coordinates of that vertex, and the integer is a flag indicating whether the vertex is part of the tessellation (i.e. whether it has been cut out (1) or not (0)). Directly following the vertex description are a list of the faces. Each line describing a face contains 4 integers. The first three are the indices of the vertices making up that face, and the fourth is a flag, similar to the one above, indicating whether the face has been cut out of the tessellation (1) or not (0). ??? Also, note that the vertex index is invariant across the different surface representations, including flattened, so you can always relate data across them. As far as getting used to looking at the flatmaps, it takes a little bit of time, but it's not that bad. Probably the best thing to do is run two copies of tksurfer, one with the inflated and one with the flattened surfaces, and use send and goto point to see how they are related. In the tksurfer guide (http://surfer.nmr.mgh.harvard.edu/docs/tksurfer_doc.html) is says: TkSurfer can be started in any of three ways: launching it from FreeSurfer with the Surface button, using the tksurfer-sess script, and calling it from the command line. Depending on which method you use, you may see different types of data loaded, but all methods require a surface data set to be loaded. How exactly would one start another
Re: wrong number of vertices error
Hi Petr, this almost certainly means that you didn't reinflate after running the topology correction, so that there is no longer a correspondence between the orig (which has been corrected) and the inflated surfaces. The reason the orig doubles in size is that the corrected surfaces have to be triangular, whereas the uncorrected surfaces are quadrangular and hence have 1/2 the number of faces. Try rerunning mris_inflate (and possibly mris_smooth) to regenerate the smoothwm and the inflated surfaces. Bruce On Wed, 12 Jun 2002, Petr Janata wrote: Hi, I've been experiencing some problems with the rh.orig and lh.orig files in the surf/ directory. The problem manifests itself as an inability to find the proper saved vertex on a T1 volume displayed in TkEdit following selection of that vertex on an inflated surface. The error arises in the Surfer module when I go to save the vertex, claiming that there are an incorrect number of vertices/faces in the .orig file. I've noticed that the .orig files change (double) in size during various processing steps, and I've also found that this error occurs if I fix the topology of one hemisphere and only run create surface on that hemisphere. When I move to the other hemisphere I encounter the problem, whereas if I run create surface on both the error tends not to occur. Unfortunately, I've now encountered the situation in which I ran a Fix Topology with apparently corrupted .orig files and then found the error. When I went back and ran create surface and then fix topology on both hemispheres the problem persisted and the previously good hemisphere became corrupted. I could no longer click on a location on a patch, save it, and have the point be located on a T1 image. I'd prefer not to have to start all over with white matter fixing, so if anyone can suggest a workaround, I'd be very appreciative. Thanks. Petr Petr Janata, Ph.D. Research Assistant Professor Dept. of Psychological and Brain Sciences Dartmouth College 6207 Moore Hall Hanover NH, 03755 phone: 603 646 0062 fax: 603 646 1419 http://atonal.dartmouth.edu/~petr
Re: quantifying surface area
Hi Tom, we write out an ?h.area file that contains the area of every vertex in the tessellation (the average area of all triangles it is a member of). You should be able to convert it to ascii using mris_convert in the usual way. Also, note that the vertex index is invariant across the different surface representations, including flattened, so you can always relate data across them. As far as getting used to looking at the flatmaps, it takes a little bit of time, but it's not that bad. Probably the best thing to do is run two copies of tksurfer, one with the inflated and one with the flattened surfaces, and use send and goto point to see how they are related. cheers, Bruce On Fri, 7 Jun 2002, Tom Schoenemann wrote: Is there any way to get a measure of absolute surface area of, e.g., the pial surface of an individual? If so, can this be run on cut portions of the cortical surface (e.g., the occipical pole)? We worked our way to the point at which freesurfer has created a model of the surface of each hemisphere. We are beginning to experiment with cuts as a prelude to flattening. We would like to make comparisons between individuals in the size and distribution of surface area across the cortex. Also, it isn't clear from the guide how easy it would be to interpret the flattened cortex map. That is, how do we know which part of the map corresponds to which part of the cortex, just by looking at the map itself. Is the flattened map presented in some standardized perspective? Apologies if we have overlooked this in the guide and/or tutorial! -Tom _ P. Thomas Schoenemann Assistant Professor Department of Anthropology University of Pennsylvania Philadelphia, PA 19104-6398 Phone: (215) 573-7671 Fax: (215) 898-7462 E-mail: [EMAIL PROTECTED] Homepage: http://www.sas.upenn.edu/~ptschoen/
Re: error using updated mris_smooth
Hi Frederick, I'm not sure what's wrong, as this works fine for me. Check the dates on your files, and make sure that the area file was created after the orig. If you are still having problems and can put your data somewhere we can look at it, we will. 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 Tue, 14 May 2002, Frederick Klauschen wrote: Hi Bruce, I downloaded the updated mris_smooth.Linux from the path you indicated below and I moved the file to /freesurfer_alpha/bin/Linux/mris_smooth. Then I restartet the CREATE_SURFACE process and got a new ?h.area file. Then I transformed to ascii again: mris_convert -c area /freesurfer_alpha/subjects/t1normal/surf/lh.orig /freesurfer_alpha/subjects/t1normal/surf/lh.area.asc MRISreadBinaryCurvature: incompatible vertex number in file /li2/freesurfer/freesurfer_alpha/subjects/t1normal /surf/lh.area A new lh.area.asc is output, the vertex number is the same as before but the area values are all zero! Thanks, Frederick --- Bruce Fischl [EMAIL PROTECTED] wrote: Hi Frederick, the thickness and area measures should be in mm and mm^2 respectively. I think you have an old version of mris_smooth that generates incorrect ?h.area files, which is why you are getting alternate zeros. I've put new versions on our ftp site: ftp surfer.nmr.mgh.harvard.edu Connected to surfer.nmr.mgh.harvard.edu. 220 surfer.nmr.mgh.harvard.edu FTP server (Version wu-2.6.1-16.7x.1) ready. Name (surfer.nmr.mgh.harvard.edu:fischl): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 230-The response 'fischl@nmr' is not valid 230-Next time please use your e-mail address as your password 230-for example: [EMAIL PROTECTED] 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp cd /space/outgoing/fsdev 250 CWD command successful. ftp ls mris_smooth* 227 Entering Passive Mode (132,183,202,158,9,149) 150 Opening ASCII mode data connection for directory listing. -rwxrwxr-x 1 5499 160 1639184 May 13 16:12 mris_smooth.IRIX -rwxrwxr-x 1 5499 160 2546764 May 13 16:12 mris_smooth.Linux -rwxrwxr-x 1 5499 160 2378232 May 13 16:12 mris_smooth.Solaris 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 Sun, 12 May 2002, Frederick Klauschen wrote: Hi, I have done the conversion of the ?h.thickness and ?h.area files to ascii format. I have got an array of the size 163993x5. Each row contains an index, three coordinates and another value, which probably is the thickness/area. Unfortunately, I was not able to find any details about this thickness/area value (unit?). In order to calculate the grey matter volume, do I just have to sum up the thickness or rather take the average thickness and weigh with the total area(why is only every second entry in the area field (5th column) of ?h.area.asc different from zero?)? Thanks for any help, Frederick __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
Re: skull stripping and segmentation
Hi Phoebe, are you using a talairaching procedure? If so, please check that it worked properly. If it fails, everything after it fails as well. Please also check your T1 volume by bringing it up in tkmedit. The vast majority of the white matter should have an intensity of exactly 110. If this is not the case, then the intensity normalization didn't work properly, possibly because of a talairach failure, or for some other reason. The segmentation itself usually works pretty well, so I suspect that it is one of the previous steps that is causing you problems. 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 Sun, 28 Apr 2002, Phoebe Chan wrote: Dear all, I got some problems in skull stripping and segmentation of 2 brains in my data. I've tried to reduce the value of preflooding heights to 5 (at 'expert preferences'), however, it seems that still lots of skull fragments remain on the image. In addition, the white matter is not segmented properly when I overlay the white matter volume on the T1 volume using tkmedit. As far as I understand, the parameters in 'wmfilter' cannot be altered. Do you know how I can correct these problems? Your help will be very much appreciated. Phoebe.
support for freesurfer
Hi All, I have two favors to ask of the freesurfer users community. This is important to us, as our P41 regional resource grant, which is the *only* mechanism that currently funds support for freesurfer, is up for renewal next year. In that regard, it would be very helpful for us if: 1. You could please send me email indicating that you are an active user of freesurfer. If you could also include the following info, it would be very helpful: your institutional affiliation the approximate # of cortical surface models you have successfully generated the approximate # of people in your institution who use freesurfer 2. The other thing that will be very important for us for getting renewed is the # of publication that cite the freesurfer methods papers. Unfortunately, it seems that people have been treating us like matlab and not citing the academic methods papers. If you do publish results using freesurfer, please cite the following papers: Fischl, B., M.I. Sereno, and A.M. Dale, Cortical Surface-Based Analysis II: Inflation, Flattening, a Surface-Based Coordinate System. NeuroImage, 1999. 9: p. 195-207. Fischl, B., A. Liu, and A.M. Dale, Automated Manifold Surgery: Constructing Geometrically Accurate and Topologically Correct Models of the Human Cerebral Cortex. IEEE Transactions on Medical Imaging., 2001. 20(1): p. 70-80. Dale, A.M. and M.I. Sereno, Improved localization of cortical activity by combining EEG and MEG with MRI cortical surface reconstruction: A linear approach. Journal of Cognitive Neuroscience, 1993. 5(2): p. 162-176. Dale, A.M., B. Fischl, and M.I. Sereno, Cortical Surface-Based Analysis I: Segmentation and Surface Reconstruction. NeuroImage, 1999. 9: p. 179-194. if you are using the thickness tools, please also cite: Fischl, B. and A.M. Dale, Measuring the thickness of the human cerebral cortex from magnetic resonance images. Proceedings of the National Academy of Sciences, 2000. 97: p. 11044-11049. finally, if you are using the spherical averaging include: Fischl, B., M.I. Sereno, R.B.H. Tootell, and A.M. Dale, High-resolution inter-subject averaging and a coordinate system for the cortical surface. Human Brain Mapping, 1999. 8(4): p. 272-284. thanks, 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
Re: Problems
Hi Felix, check the fov field in the COR-.info files in the subject's mri/orig and mri/T1 directories. It should be 0.256, but for some reason is sometimes is set incorrectly. As far as the volume/surface problem, the problem is usually the other way (okay in tkmedit, no good in tksurfer), so I'm not sure what's going on. 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, 22 Apr 2002, Felix Blankenburg wrote: Dear Freesurfers! Does anyone know a solution for the following problem: after running freesurfer I have to zoom in the surface every time for a few hundred per cent to see it correctly in the display window (i. e. how to save the surface size)? An other problem is, when I try to overlay a statistical parametric map (SPM99) in 2D (i. e. in tkmedit) it looks misplaced whereas in 3D ( i.e. in tksurfer) it looks fine. Is there any possibility for a correct transformation in 2D or is it intended? Is there any possibility to change the colour of the surfaces? Thank you very much for your help and best greetings, Felix Blankenburg
Re: calculating distance along the cortical surface?
Hi Al, we typically leave the spherical images in a scale (i.e. radius) that is a good size for visualization. In order to compute the geodesics, you will need to scale them according to: scale = sqrt(total folded surface area / total spherical surface area). the true distances would then be great circles on the sphere, scaled by this factor. cheers, Bruce On Wed, 10 Apr 2002, Albert Kim wrote: Hi, Here is an issue that I brought up earlier (March 4), but got sidetracked from: I asked if there was a away to calculate distance along the cortical surface between two vertices on the surface. Bruce Fischl responded with this: you should be able to use spherical coordinates in order to compute approximate geodesic distances (the length of the arc along the great circle connecting two points will be an approximation of the geodesic distance on the gray/white boundary surface). The typical error for cortex is around 10-15%. This sounds promising, but I do not know how to interpret my spherical coordinates, so I do not know how to go about following your suggestion. That is, if I mris_convert my ?h.sphere file, I get a bunch of vertices and presumably faces. Would it be possible to find out what coordinate system these are in? or could you point me to the appropriate documentation? Thanks very much, Al Kim
Re: cortechs registration
Try http://surfer.nmr.mgh.harvard.edu/registration.html 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 Fri, 22 Mar 2002, Timothy Souza wrote: Hi, The cortechs registration page for freesurfer does not appear to be working correctly...Is there an alternate method of registering freesurfer? Thanks, Tim Souza -- Timothy Souza Brown University Department of Neuroscience [EMAIL PROTECTED] ph: 401-863-1258 fax: 401-863-1074
Re: original coordinates and reconstructed surface coordinates
Hi Al, I'm not sure what your question is. The vertex coordinates are in an RAS coordinate system, with the origin at the center of the volume (voxel 127.5,127.5,127.5 I think). The voxel coords are arranged in coronal slices, which I think you have figured out. 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 Thu, 7 Mar 2002, Albert Kim wrote: Hi Bruce, Very sorry but I'm still confused. When I click on a point in TKSURFER and then SAVE the point, I see the following effect on the logs (NOTE: this vertex happens to be the 0th Vertex): surfer: dmin=0.0569, vno=0, x=-32.9801, y=-124.2833, z=-37.1158 surfer: curv=-0.23, fs=0.00 surfer: val=0.00, val2=0.00 surfer: amp=0.00, angle=0.00 deg (0.00) surfer: vertex 0 marked (curv=-0.23, stat=0.00) x = (-33.0, -124.3, -37.1), n = (-0.5, -0.9, -0.1). writing coordinates to file /home/alkim/freesurfer_alpha/subjects/E12410/tmp/edit.dat vertex 0 coordinates: ORIGINAL (11.5 -88.5 -8.5) SPHERICAL (6.7 -90.2 -41.2): (114.5, -85.8) If I goto this point in Tkmedit, I land at the following Volume Index: 116, 136, 39 which are voxel coords. Now, I see that these voxel coords can be transformed into the ORIGINAL coords above by swapping the second and third dimensions and offsetting things by 127.5. -116+ 127.5 = 11.5 39 - 127.5 = -88.5 -136+ 127.5 = -8.5 And I can see that these ORIGINAL coordinates are what are called the Volume RAS coords in TKMEDIT and Vertex RAS in TKSURFER. But I still do not understand the x,y,z coordinates: surfer: dmin=0.0569, vno=0, x=-32.9801, y=-124.2833, z=-37.1158 These xyz coordinates are the output I see when I use mris_convert to convert my rh.inflated surface into ascii format. For instance the first row of the rh.inflated.ascii file is: -32.980091 -124.283272 -37.115761, which is the same as the stuff above. I apologize if I'm missing something obvious here. Al On Wed, 6 Mar 2002, Bruce Fischl wrote: Hi Al, the matrix to convert row,col,slice voxel coords into the vertex coordinates (which are RAS in the COR file coordinate system with the origin at the center of the volume) should be: -1 0 0 128.5 0 1 -128.5 0 -1 0 128.5 we have been plagued by off-by-ones and off-by-1/2s, but I think this is correct. 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 Wed, 6 Mar 2002, Albert Kim wrote: Bruce, Thanks. I'm approaching a solution, but not quite there yet. I'm assuming you meant that I should use mris_convert (not mri_convert) to create the ascii version of my surface file. I did this as follows: mris_convert rh.inflated rh.inflated.asc However, the resulting ascii file does not contain RAS coordinates. Rather, it contains x,y,z coordinates in a format I do not understand, exemplified by this: #!ascii version of rh.inflated 145185 290366 -32.980091 -124.283272 -37.115761 0 -33.141834 -124.183533 -37.142693 0 -33.435402 -123.985886 -37.259331 0 -32.554119 -124.488083 -37.194771 0 ...etc... I've been wondering what these coordinates are (I hope Im not missing something obvious here). These coordinates are not RAS nor voxel coords. They are, however, shown in the tksurfer logs when I click on points. That is, if I click on the 0th vertex in Tksurfer and then SAVE that point, I see the following effects in the log (the x,y,z coords below are the same as in the first row of the ascii file shown above): surfer: dmin=0.1721, vno=0, x=-32.9801, y=-124.2833, z=-37.1158 surfer: curv=-0.23, fs=0.00 surfer: val=0.00, val2=0.00 surfer: amp=0.00, angle=0.00 deg (0.00) surfer: vertex 0 marked (curv=-0.23, stat=0.00) x = (-33.0, -124.3, -37.1), n = (-0.5, -0.9, -0.1). writing coordinates to file /home/alkim/freesurfer_alpha/subjects/E12410/tmp/edit.dat vertex 0 coordinates: ORIGINAL (11.5 -88.5 -8.5) SPHERICAL (6.7 -90.2 -41.2): (114.5, -85.8) So... could you either: 1) Tell me how to produce RAS coordinates in my ascii file or 2) Could you point me to an explanation of the coordinates that I am seeing in my ascii file
Re: view spherical surface
Hi Al, the spherical transform creates two surfaces: ?h.sphere - quasi isometric spherical surface ?h.sphere.reg - registered spherical surface. you should be able to bring them up and view then in tksurfer as any surface, but they probably won't be very informative to look at. You might consider using the send_to_subject command, which will let you see the point correspondence between any two subjects (bring up a second tksurfer with the target subject and click goto point after doing send_to_subject). I can't remember if the version we distributed has this on the interface, if not you should be able to use a tcl command directly. 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 Wed, 27 Feb 2002, Albert Kim wrote: Hi, I cannot figure out how to view my spherical surface, which I've just generated by running Register Surface from the GUI. The only documentation I can find on it is p47,48 of the manual. Anybody know how to do this? Thanks, Al Kim Department of Psychology University of Washington, Box 351525 Seattle, WA. 98195, USA E-Mail: [EMAIL PROTECTED]; Tel: (206)543-2395
Re: avearge inflated brain
Hi Arshad, I haven't seen it. Is it an average? If so, then it will never work. If it's an individual then it might if it has high enough contrast-to-noise. We also have average inflated/white/pial brains that we use, which we could make available to people if there is enough interest. Bruce On Thu, 20 Dec 2001, A Zaman wrote: Dear Bruce (and all), Is there anyway to inflate the SPM T1 (template) brain? Best wishes, Arshad */ Dr. Arshad Zaman Magnetic Resonance Image Analysis Research Centre University of Liverpool Liverpool L69 3BX Tel + 44 (0) 151 794 5645 Fax + 44 (0) 151 794 5635 [EMAIL PROTECTED] */ On Tue, 11 Dec 2001, Bruce Fischl wrote: Hi Arshad, not really, but you can create an average curvature map and paint it onto an individual brain so that it shows what the average folding pattern of a group of subjects is. See the binary mris_average_curvature. For example: mris_average_curvature curv lh sphere.reg subject 1 subject 2 ... subject n avg_curv will generate an average of the n curvature maps and write it into the file lh.avg_curv in subject n's surf directory. cheers, Bruce On Tue, 11 Dec 2001, A Zaman wrote: Dear Bruce, I was wondering is it possible to construct an 'average' inflated brain for a number of subjects. Many thanks, Arshad */ Dr. Arshad Zaman Magnetic Resonance Image Analysis Research Centre University of Liverpool Liverpool L69 3BX Tel + 44 (0) 151 794 5645 Fax + 44 (0) 151 794 5635 [EMAIL PROTECTED] */
Re: from flat map to origs
Hi Claus, the coordinates are in the flat space, in which z=0 for all vertices. The last number is the vertex index, which is invariant across surface representations. You can therefore convert the orig (or white or pial) to ascii format and use the vertex index to lookup the 3D coordinate of that vertex on any of the surface representations. cheers, Bruce On Thu, 1 Nov 2001, Claus Tempelmann wrote: Ok Bruce, mris_convert has worked, but I have no idea what the numbers in the asc-file might mean. Is there a chapter in one of the manuals which would tell me about it? I did the mris_convert with the complete rh.occip.patch.flat which is not what I want but I assume it should work in the same way. Of course I get a long file, about 40% of the file contains float coordinates where the third coordinate is always 0.00, e.g. 9.62000 -37.419998 0.00 the rest of the file has three integer coordinates for each voxel (??) but the numbers have up to 6 digits, e.g. 146214 146207 144544 ?! If these are the voxel coordinates, which coordinate system is this? Claus From [EMAIL PROTECTED] Thu Nov 01 20:19:40 2001 Envelope-to: [EMAIL PROTECTED] Delivery-date: Thu, 01 Nov 2001 20:19:40 +0100 X-Authentication-Warning: surfer.nmr.mgh.harvard.edu: majordomo set sender to [EMAIL PROTECTED] using -f Date: Thu, 1 Nov 2001 14:17:19 -0500 (EST) From: Bruce Fischl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: from flat map to origs MIME-Version: 1.0 Hi Claus, my mistake, I meant mris_convert, not mri_convert (since of course we are talking about surfaces not volumes). cheers, Bruce On Thu, 1 Nov 2001, Claus Tempelmann wrote: Dear Bruce, thanks for the prompt reply. Doesn't sound too complicated :-) However, all my old versions of mri_convert give the reply unknown option -p I am trying to get the October 2001 version downloaded, unfortunately the connection isn't good enough for new speed records, anyway finally I will get it. Hopefully that version knows about the option -p ;-) Claus From [EMAIL PROTECTED] Thu Nov 01 19:20:14 2001 Envelope-to: [EMAIL PROTECTED] Delivery-date: Thu, 01 Nov 2001 19:20:14 +0100 X-Authentication-Warning: surfer.nmr.mgh.harvard.edu: majordomo set sender to [EMAIL PROTECTED] using -f Date: Thu, 1 Nov 2001 13:17:39 -0500 (EST) From: Bruce Fischl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: from flat map to origs MIME-Version: 1.0 Hi Claus, you should be able to use mri_convert -p input patch output patch.asc) to convert a patch to ascii format, and therefore get the voxel coords out in matlab or whatever. cheers, Bruce On Thu, 1 Nov 2001, Claus Tempelmann wrote: Hi everybody, many people are working with retinotopic maps on flat brains. A typical task would be to identify a region on the flat map (e.g. V2) and to get a list of all corresponding voxels of the anatomical data set (e.g. 3D-scan). I assume some of you have already done that with freesurfer tools. I would appreciate if you could list the important steps on this way. Thanks in advance Claus - Claus Tempelmann email: [EMAIL PROTECTED] Clinic for Neurology II MR department phone: +49-391-6117177 OvG University Magdeburg +49-391-6117183 Leipziger Strasse 44 39120 Magdeburg fax:+49-391-6117178 Germany
Re: from flat map to origs
if you convert the ?h.orig file as well as the patch, it will contain the coordinates of that surface. You'll need to convert them to voxel indices from RAS coords, but that's pretty straightforward. Your question is a bit confusing though, as the surface is a 2D manifold embedded in the 3D volume, so for example, all the orig coordinates will be on voxel boundaries (i.e. all the coordinates will end in .5). What are you trying to do? Does that answer your question? Bruce On Thu, 1 Nov 2001, Claus Tempelmann wrote: Hi Bruce again, thanks for your patience! May be I got it, if I did there was probably a misunderstanding, I'm not looking for the 3D coordinates for the orig or white or pial surface, but the coordinates of the corresponding voxels in the original anatomical data, i.e. I want to know which voxels in which of the files COR-001 to COR-256 in the directory /subject/mri/orig belong to my patch. Can I derive this information from the asc-files created with mris_convert? Claus From [EMAIL PROTECTED] Thu Nov 01 20:59:44 2001 Envelope-to: [EMAIL PROTECTED] Delivery-date: Thu, 01 Nov 2001 20:59:44 +0100 X-Authentication-Warning: surfer.nmr.mgh.harvard.edu: majordomo set sender to [EMAIL PROTECTED] using -f Date: Thu, 1 Nov 2001 14:56:56 -0500 (EST) From: Bruce Fischl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: from flat map to origs MIME-Version: 1.0 Hi Claus, the coordinates are in the flat space, in which z=0 for all vertices. The last number is the vertex index, which is invariant across surface representations. You can therefore convert the orig (or white or pial) to ascii format and use the vertex index to lookup the 3D coordinate of that vertex on any of the surface representations. cheers, Bruce On Thu, 1 Nov 2001, Claus Tempelmann wrote: Ok Bruce, mris_convert has worked, but I have no idea what the numbers in the asc-file might mean. Is there a chapter in one of the manuals which would tell me about it? I did the mris_convert with the complete rh.occip.patch.flat which is not what I want but I assume it should work in the same way. Of course I get a long file, about 40% of the file contains float coordinates where the third coordinate is always 0.00, e.g. 9.62000 -37.419998 0.00 the rest of the file has three integer coordinates for each voxel (??) but the numbers have up to 6 digits, e.g. 146214 146207 144544 ?! If these are the voxel coordinates, which coordinate system is this? Claus From [EMAIL PROTECTED] Thu Nov 01 20:19:40 2001 Envelope-to: [EMAIL PROTECTED] Delivery-date: Thu, 01 Nov 2001 20:19:40 +0100 X-Authentication-Warning: surfer.nmr.mgh.harvard.edu: majordomo set sender to [EMAIL PROTECTED] using -f Date: Thu, 1 Nov 2001 14:17:19 -0500 (EST) From: Bruce Fischl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: from flat map to origs MIME-Version: 1.0 Hi Claus, my mistake, I meant mris_convert, not mri_convert (since of course we are talking about surfaces not volumes). cheers, Bruce On Thu, 1 Nov 2001, Claus Tempelmann wrote: Dear Bruce, thanks for the prompt reply. Doesn't sound too complicated :-) However, all my old versions of mri_convert give the reply unknown option -p I am trying to get the October 2001 version downloaded, unfortunately the connection isn't good enough for new speed records, anyway finally I will get it. Hopefully that version knows about the option -p ;-) Claus From [EMAIL PROTECTED] Thu Nov 01 19:20:14 2001 Envelope-to: [EMAIL PROTECTED] Delivery-date: Thu, 01 Nov 2001 19:20:14 +0100 X-Authentication-Warning: surfer.nmr.mgh.harvard.edu: majordomo set sender to [EMAIL PROTECTED] using -f Date: Thu, 1 Nov 2001 13:17:39 -0500 (EST) From: Bruce Fischl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: from flat map to origs MIME-Version: 1.0 Hi Claus, you should be able to use mri_convert -p input patch output patch.asc) to convert a patch to ascii format, and therefore get the voxel coords out in matlab or whatever. cheers, Bruce On Thu, 1 Nov 2001, Claus Tempelmann wrote: Hi everybody, many people are working with retinotopic maps on flat brains. A typical task would be to identify a region on the flat map (e.g. V2) and to get a list of all corresponding voxels of the anatomical data set (e.g. 3D-scan). I assume some of you have already done that with freesurfer tools. I would appreciate if you could list the important steps on this way. Thanks in advance Claus
Re: rigid alignment averaging
Hi Brian, the -a option to mri_average causes it to do motion correction of each volume to the set preceeding it before averaging. Otherwise it assumes they are in register. The only disadvantage is that we haven't tested it much. cheers, Bruce On Mon, 29 Oct 2001, Brian C. Schweinsburg wrote: Hi all, What are the basic advantages and/or disadvantages of using the rigid alignment option in the new version of mri_average (-a)? Thanks, Brian ___ Brian C. Schweinsburg University of California, San Diego San Diego State University Office: (858) 642-3736 Pager: (619) 290-2659 Fax: (858) 552-7432 http://mednmr3.ucsd.edu/brian/home.htm ___
Re: sphere registration error
Hi Brian, typically we rerun it with the -curv switch, which causes it to use curvature information after the average convexity has converged. This allows secondary folds such as the hand area to align, where possible. cheers, Bruce On Thu, 11 Oct 2001, Brian C. Schweinsburg wrote: Bruce, I reran the spherical registration allowing overwrite of rh.sphere. When freesurfer tries to run the spherical registration it seems as if it calls mris_sphere for a second time instead of mris_register-thus the overwrite message. This is reflected in the attached txt files rh.sphere.out (from scripts directory) and rh.sphere.viewlogs (pasted from the command window), where the logs show that mri_sphere was run when the in progress window stated the registration was being run. As a comparison, I deleted bert's registered images and tried to recreate them, but the same overwrite rh.sphere problem appeared. I ran mris_register [options] rh.sphere ~/average/rh.average.tiff rh.sphere.reg without any options. I wasn't sure what options to include, but a comparsion of bert's sample output for rh.sphere.reg.out showed that the sphere was rotated while my output only said scanning. A registered image was produced and looked reasonable. What options do you run for the command line, and are their lists of options anywhere for each command line program (particularly those for morphometric studies. e.g., mris_convert)? Thanks for all of your help, Brian - Original Message - From: Bruce Fischl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 10, 2001 11:17 AM Subject: Re: sphere registration error could you please send along the logs for the spherical registration, answering yes to the overwrite question (you can cp the files elsewehere beforehand so that you don't have to rerun the spherical transformation). Please check view logs under expert prefs, then send the contents of the csurf window that opens for the registration step. Bruce On Wed, 10 Oct 2001, Brian C. Schweinsburg wrote: The log files in ~/subject4/scripts reveal no error messages. the ?h.sphere's ran without a problem. This is the exact message I get during the four part sphere process: [register RH to target -- in progress] ~/subject4/rh.sphere exists -- use it or redo/overwrite. I did not do any cortical flattening-I don't know why that would impact this but ..? As I mentioned before, I am using the Linux binary. Brian - Original Message - From: Bruce Fischl [EMAIL PROTECTED] To: freesurfer [EMAIL PROTECTED] Sent: Wednesday, October 10, 2001 5:38 AM Subject: Re: sphere registration error do the log files report any error? 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 Wed, 10 Oct 2001, Brian C. Schweinsburg wrote: Hi all, After running through some of the first processing steps (manual editing, fix topology,etc.), I had some trouble. I started sphere surface, and it ran through the rh and lh without a problem. However, the next two steps are spherical registration for each hemisphere, and this did not work. While displaying the in progress message for the rh registration, it asked me if I wanted to overwrite rh.sphere. It seems the registration should create a file called ?h.sphere.reg, but mine does not. I tried it twice on two different machines, both Linux, and got the same overwrite message. One time I let it overwrite, rh.sphere and the end result looked the same as the first spherical transformation. Am I doing something wrong? Is there a fix for the GUI? Can you run the registration from the command line? Thanks, Brian ___ Brian C. Schweinsburg University of California, San Diego San Diego State University Office: (858) 642-3736 Pager: (619) 290-2659 Fax: (858) 552-7432 http://mednmr3.ucsd.edu/brian/home.htm ___
Re: Medx Functional Overlay
Hi Winfred, I just put Linux, Solaris and IRIX versions of tkregister on our anonymous ftp site: ftp surfer.nmr.mgh.harvard.edu:/space/outgoing/flat good luck, 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 Fri, 28 Sep 2001, Winfred Kao wrote: Hi, I'm trying to figure out how to functionally overlay a functional image from Medx onto an inflated brain in Freesurfer. Currently I have saved my Medx image in Analyze format, then converted it to bfloat. However, it seems I still need to make a transformation matrix called register.dat. I have been trying to run tkregister to manually register slice data. Problem is that I get an error when I try to run it in a tkshell. It seems that I don't have the binary executable of tkregister in my Linux distribution of Freesurfer, which I just . I do have the tcl script tkregister.tcl. Looking through the code of csurf I noticed a comment suggesting that a Linux binary for tkregister was still pending. Is there a binary version of tkregister for Linux available or another method for creating this transfomration matrix. Thanks, Winfred __ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com
Re: extracting cortical thickness data
almost. mris_convert -c thickness \ $SUBJECTS_DIR/$subject/surf/rh.white \ $SUBJECTS_DIR/$subject/surf/rh.thickness.asc should do the trick. 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, 24 Sep 2001, Brian C. Schweinsburg wrote: How do you extract cortical thickness data in order to create a histogram like Figure 3 (Histogram of thickness values, y axis=# of vertices, x axis=thickness) in Fischl and Dale (2000). Measuring the thickness of the human cerebral cortex..? Is this close at all? mris_convert -c curv rh.thickness rh.thickness.asc If so, then what! Thanks, Brian Schweinsburg University of California, San Diego
Re: About .w transformation
I've put new versions of mris_convert for each of the 3 supported platforms on our ftp site. Try these, although you may be having problems because of redhat 7.0, I'll try to find out. ftping: ftp surfer.nmr.mgh.harvard.edu Connected to surfer.nmr.mgh.harvard.edu. 220 surfer.nmr.mgh.harvard.edu FTP server (Version wu-2.6.1(1) Wed Apr 11 10:53:56 EDT 2001) ready. Name (surfer.nmr.mgh.harvard.edu:fischl): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp bin 200 Type set to I. ftp cd /space/outgoing/flat 250 CWD command successful. ftp ls mris_convert.* 200 PORT command successful. 150 Opening ASCII mode data connection for directory listing. -rwxrwxr-x 1 5385 145 1634976 Sep 12 01:23 mris_convert.IRIX -rwxrwxr-x 1 5385 145 1582356 Sep 12 01:23 mris_convert.Linux -rwxrwxr-x 1 5385 145 1511356 Sep 12 01:24 mris_convert.Solaris 226 Transfer complete. On Wed, 12 Sep 2001, lzx wrote: Dear Bruce, I got a Segmentation fault. Exit 139 while trying this command. I'm in Redhat 7.0, kernal 2.2.16. I am using the latest version from nmr.mgh.harvard.edu site. Could you help me figure out where is the problem, then? Many thanks. mris_convert file.w file.asc should do the trick. cheers, Bruce On Tue, 11 Sep 2001, lzx wrote: Dear Bruce, I searched the maillist of FreeSurfer and found that you've mentioned transformation from ascii file to .w file. But now my problem is how to transfer from .w file to ascii, then I could use it in our following processes? Could do kindly give me any hint? Best Wishes
Re: tkmedit ?...
there is a (much) newer version that has been extensively rewritten that will be part of the new release (still coming soon). Bruce On Fri, 24 Aug 2001, Souheil Inati wrote: Hey giorgio, any response about this? souheil [EMAIL PROTECTED] wrote: Hi all, this problem may be related to the one Souheil mentioned a few days ago. I took one of the orig COR sets, converted it to bfloats and looked at it as a functional overlay in tkmedit. The two datasets should be on top of each other (I used the identity matrix for register.dat). Instead, the functional dataset seems shifted by 16 mm to the left (relative to the orig set). By fiddling with register.dat things can be fixed, obviously, but there might be some misregistration between the two spaces. I still have the tkmedit version from the Summer 2000 distribution... Is there another version available ? Thanks. -Giorgio
Re: Freesurfer´s problem
Hi Jim, I think your problem must have to do with having an old version of mri_convert. I have put new versions on our anonymous ftp site. With them I was able to convert your data just fine. Let me know if this solves your problem. Bruce FTP: Name (surfer.nmr.mgh.harvard.edu:fischl): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp cd /transfer/outgoing/flat 250 CWD command successful. ftp ls mri_convert.* 200 PORT command successful. 150 Opening ASCII mode data connection for directory listing. -rwxrwxr-x 1 5385 145 2520976 Aug 20 19:07 mri_convert.IRIX -rwxrwxr-x 1 5385 145 2175188 Aug 20 19:07 mri_convert.Linux -rwxrwxr-x 1 5385 145 2156092 Aug 20 19:07 mri_convert.Solaris 226 Transfer complete. On Thu, 23 Aug 2001, James Eliassen wrote: On Wed, 22 Aug 2001, James Eliassen wrote: Hi Bruce and Rafael, I have more details now. We are having a problem with the Convert/Average step in Freesurfer. We have two high-res anatomicals (originally saggital slices), 1x1 mm in plane, 1mm thick. They were 256x256 FOV and 160 slices. We convert the raw Siemens .ima files (Vision system at 1.5T) to AFNI BRIKS. Then we co-register the two AFNI BRIKS with AFNI's 3d Registration plugin tool. They appear to be co-registered to within a mm or so of each other. These 2 BRIKS are made up of shorts (as opposed to bytes, but the problem is the same if we convert them to byte files first). We place these two separate BRIKS and associated HEAD files into ~freesurfer/Subjects/SubName/mri/orig/001 and 002/ and then perform Setup Structural Scans. After identifying the proper directories and files and reading the header (using the freesurfer button, which correctly reads this information) we push the Convert/Average button. The images that come out can be viewed on our web server http://fmri.neuro.brown.edu/freesurfer.html The saggital image shows what looks to be an ear in white amongst the noise (i.e., the correct orientation of the slab), but the other two planes indicate that the same image is present throughout the slab. Any further question and suggestions will be graciously accepted! -jim Hi Rafael and Jim, could you give us more details about your problems? 2 anatomicals should be fine for reconstruction (one will work as well if it is high enough quality, but the surfaces won't be as accurate). Saggital acquisitions should be fine. Have you successfully reconstructed surface models? Is the problem you're having with functional overlay? 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 02129USA On Mon, 20 Aug 2001, James Eliassen wrote: Hi Rafael, We did not solve the problem. The trouble is that only one slice is represented in the dataset (after the convert/average step), so it may look like an image viewed from the appropriate plane, but because the (single) image is the same throughout, views in the other planes just appear as black and white lines. There were three possibilities, we think. 1. We were only using two high-res anatomical image sets, instead of the recommended 3. 2. the brik2bfloat version we were using was out of date, although the versions I was able to locate at the time (February/March or so) were the same as the one we had. 3. Our hi-res anatomicals (siemens MPRAGE's) were acquired in the saggital plane and converted to afni briks. Maybe Freesurfer did not like the saggital images. I think there is a way to convert the images to the coronal plane but we didn't solve that problem. Good luck, let me know if you have success. -jim Dear James: IÃm trying to use Freesurfer, but I have the problem of the white and gray lines on black background. Did you solve the problem? What is the solution? IÃll appreciate very much your help. Thank you in advance, Rafael. Send reply to: [EMAIL PROTECTED] Get 250 color business cards for FREE! http://businesscards.lycos.com/vp/fastpath/
