Freesurfer March 2014

freesurfer@nmr.mgh.harvard.edu

147 participants
247 discussions

selxavg3-sess error
by SHAHIN NASR 19 Mar '14

19 Mar '14

Hi, When I run selxavg3-sess, I face this error: ERROR: cannot find volume matching /autofs/cluster/tootell/pitcairn/1/shahin/ColorPrj/7T/Sbj/myla2/bold_Color/013/mcextreg ERROR: loading nonpar reg /autofs/cluster/tootell/pitcairn/1/shahin/ColorPrj/7T/Sbj/myla2/bold_Color/013/mcextreg ------------------------------------------ ERROR: fast_selxavg3() failed\n I repeated the preproc-sess from scratch and it worked fine, finished without any problem and I still get the same error. I even check the registration in this run and it fine. Now I am wondering why do I see this error for this subjects (and why I don't see it for the other subjects)? Regards -- Shahin Nasr PhD in Cognitive Neuroscience Martinos Imaging Center, MGH Harvard Medical School

2 1

bug in surface-based area and volume, and use of total brain volume as a covariate
by Narly Golestani 19 Mar '14

19 Mar '14

Dear all, Related to the bug that was reported in 2011 (see http://www.mail-archive.com/freesurfer%40nmr.mgh.harvard.edu/msg19821.html) with the way that surface-based volumes and areas were calculated in Freesurfer versions 5.1 and earlier, I’d like to confirm that region-of-interest measures obtained using those earlier versions (e.g. when exporting the volume / surface area to tables using aparcstats2table) were unaffected by this bug (i.e. rerunning qcache should not change ROI-based results). 2. I’d like to also confirm that otherwise, for vertex-based analyses, it should be sufficient to run ‘recon-all subject –qcache’ using a more recent version of freesurfer in order to obtain accurate measures for data that was originally processed using 'recon-all –all' with an earlier version of freesurfer (I have data that was originally processed with version 4.4 and other data that was processed with version 5.1 that I would like to now examine in a surface-based manner). 3. The bug was related to how the measures were converted to standard space - I’d like to therefore confirm that when doing surface/vertex-based analyses, it is not necessary to use total brain volume as a covariate (whereas it is for ROI-based analyses). Many thanks, and all the best, Narly.

3 5

bug in surface-based area and volume, and use of total brain volume as a covariate
by Narly Golestani 19 Mar '14

19 Mar '14

>> why would one control for total brain volume in doing vertex-based analyses when the vertex-based measures are computed in standard space? >The vertex-based measures are computed in individual space, not standard >space >doug Dear Doug, I would like to know at what stage the measures computed in individual space are normalised, if at all, in order to make comparisons of data across participants (e.g. in qdec) meaningful. Differences in the relative position of a particular structure across participants will make it difficult if not impossible to examine effects at the group level. If the vertex-wise data is in individual space, then I’m not sure that I understand how using total brain volume as a covariate would solve the above problem. I would greatly appreciate any clarifications that you might have. Best wishes, Narly.

2 1

Problem about Surface-based Registration
by yufeng huang 19 Mar '14

19 Mar '14

Dear Burce, I have 20 normal subjects, and I want to do inter-subject surface-based registration to all of them. So each one's surface can align properly to the other subject's surface. After that I can put the functional data onto the surface which has aligned to each other already. And now I followed the process of creating a registration template from scratch(GW)(https://surfer.nmr.mgh.harvard.edu/fswiki/SurfaceRegAndTemplate… to do the surface-based registration. Round 1, all reference subjects data are registered to the initial template, producing ?h.sphere.myreg0. (I've coordinated the suffix numbers with the template used to produce the registration.) Using that registration, a new template (mytemp1.tif) is made using all reference subjects as input. Round 2 is essentially a repeat of Round 1, but produces an improved template (mytemp2.tif) because Round 2's initial registration step is based on a better template than in Round 1. I get the lh.sphere.reg.newtemplate1 and rh.sphere.reg.newtemplate1 in each subjects's surf folder. I do not know how to check the result about if every subject has aligned to each other properly. And I do not know what should I do next. My question is : 1 How can I check about the result as if every one has aligned each other properly? 2 And what should I do next, I can not know if the functional data can aligned to the new surface properly. If I can use mri_surf2surf or mri_vol2surf can be used for this. 3 The lh.sphere.reg.newtemplate1 and rh.sphere.reg.newtemplate1is just for sphere, and how about the inflate aligned to each other? Yours Yufeng

2 1

Fwd: FW: bug in surface-based area and volume, and use of total brain volume as a covariate
by _andreia_＠sapo.pt 19 Mar '14

19 Mar '14

Hi all, just two quick questions: to what FS version is this related? And what is wrong to do if one does not have the fix? Using what stats/procedures? Thanks, Andreia Quoting Douglas N Greve <greve(a)nmr.mgh.harvard.edu>: >>> why would one control for total brain volume in doing vertex-based > analyses when the vertex-based measures are computed in standard space? > > The vertex-based measures are computed in individual space, not standard > space > doug > > > On 03/17/2014 05:12 PM, Narly Golestani wrote: >> Dear Doug, >> >> Many thanks for your answers. >> >> > 3. The bug was related to how the measures were converted to standard >> > space - I?d like to therefore confirm that when doing >> > surface/vertex-based analyses, it is not necessary to use total brain >> > volume as a covariate (whereas it is for ROI-based analyses). >> > >> This question has nothing to do with the bug. People generally use ICV >> or total brain volume when exploring cortical volume or surface area, >> but it is inappropriate for thicknss studies >> doug >> > >> >> Regarding the last point (which indeed has nothing to do with the bug, >> sorry for having given the impression that I thought that it did), why >> would one control for total brain volume in doing vertex-based >> analyses when the vertex-based measures are computed in standard >> space? I realize that this has to be done for ROI analyses since these >> measures are in native space. >> >> Thanks again, and best, >> Narly. >> >> >> _______________________________________________ >> Freesurfer mailing list >> Freesurfer(a)nmr.mgh.harvard.edu >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > -- > Douglas N. Greve, Ph.D. > MGH-NMR Center > greve(a)nmr.mgh.harvard.edu > Phone Number: 617-724-2358 > Fax: 617-726-7422 > > Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting > FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 > www.nmr.mgh.harvard.edu/facility/filedrop/index.html > Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ > > _______________________________________________ > Freesurfer mailing list > Freesurfer(a)nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > > The information in this e-mail is intended only for the person to whom it is > addressed. If you believe this e-mail was sent to you in error and the e-mail > contains patient information, please contact the Partners Compliance > HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to > you in error > but does not contain patient information, please contact the sender > and properly > dispose of the e-mail.

1 0

what is inflating to sphere rms error?
by chenchunhuichina 19 Mar '14

19 Mar '14

Dear Freesurfers, I am new to freesurfer and I am afraid of doing something wrong, so I am writing to ask is this error indicating something wrong with my data? Any help is appreciated. below are detials of my question. Thank you! I used freesurfer-Linux-centos4_x86_64-stable-pub-v5.3.0 with this command fsl_sub -N cch recon-all -i ${i} -s FSsub${i:3:5} -all I checked the O file from fsl_sub and it said at the end "recon-all -s FSsub12534 finished without error at Thu Jan 23 15:44:35 CST 2014 done" Seems it's OK then checked the e file from fsl_sub (standard_in) 2: Error: comparison in expression Seems this is a problem of fsl_sub, According to https://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/2012-May/023961.html I guess I can ignore it? Then I checked the recon-all.log file and find a lot of "error", Someone asked this question and got the answer "We see this mysterious message sometimes...usually things are fine". So when and why get there errors and does they always fine? https://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/2011-October/020810.h… the "rms radial error" and "distance error " are below or see my attached log file. $ grep -n error FSsub12534/scripts/recon-all.log 2931:inflating to sphere (rms error < 2.00) 2932:000: dt: 0.0000, rms radial error=176.789, avgs=0 2933:005/300: dt: 0.9000, rms radial error=176.532, avgs=0 2934:010/300: dt: 0.9000, rms radial error=175.978, avgs=0 2935:015/300: dt: 0.9000, rms radial error=175.253, avgs=0 2936:020/300: dt: 0.9000, rms radial error=174.426, avgs=0 2937:025/300: dt: 0.9000, rms radial error=173.543, avgs=0 2938:030/300: dt: 0.9000, rms radial error=172.627, avgs=0 2939:035/300: dt: 0.9000, rms radial error=171.693, avgs=0 2940:040/300: dt: 0.9000, rms radial error=170.750, avgs=0 2941:045/300: dt: 0.9000, rms radial error=169.806, avgs=0 2942:050/300: dt: 0.9000, rms radial error=168.861, avgs=0 2943:055/300: dt: 0.9000, rms radial error=167.919, avgs=0 2944:060/300: dt: 0.9000, rms radial error=166.980, avgs=0 2945:065/300: dt: 0.9000, rms radial error=166.045, avgs=0 2946:070/300: dt: 0.9000, rms radial error=165.114, avgs=0 2947:075/300: dt: 0.9000, rms radial error=164.188, avgs=0 2948:080/300: dt: 0.9000, rms radial error=163.267, avgs=0 2949:085/300: dt: 0.9000, rms radial error=162.351, avgs=0 2950:090/300: dt: 0.9000, rms radial error=161.439, avgs=0 2951:095/300: dt: 0.9000, rms radial error=160.532, avgs=0 2952:100/300: dt: 0.9000, rms radial error=159.629, avgs=0 2953:105/300: dt: 0.9000, rms radial error=158.732, avgs=0 2954:110/300: dt: 0.9000, rms radial error=157.839, avgs=0 2955:115/300: dt: 0.9000, rms radial error=156.951, avgs=0 2956:120/300: dt: 0.9000, rms radial error=156.068, avgs=0 2957:125/300: dt: 0.9000, rms radial error=155.189, avgs=0 2958:130/300: dt: 0.9000, rms radial error=154.316, avgs=0 2959:135/300: dt: 0.9000, rms radial error=153.447, avgs=0 2960:140/300: dt: 0.9000, rms radial error=152.583, avgs=0 2961:145/300: dt: 0.9000, rms radial error=151.723, avgs=0 2962:150/300: dt: 0.9000, rms radial error=150.868, avgs=0 2963:155/300: dt: 0.9000, rms radial error=150.018, avgs=0 2964:160/300: dt: 0.9000, rms radial error=149.173, avgs=0 2965:165/300: dt: 0.9000, rms radial error=148.332, avgs=0 2966:170/300: dt: 0.9000, rms radial error=147.496, avgs=0 2967:175/300: dt: 0.9000, rms radial error=146.665, avgs=0 2968:180/300: dt: 0.9000, rms radial error=145.838, avgs=0 2969:185/300: dt: 0.9000, rms radial error=145.015, avgs=0 2970:190/300: dt: 0.9000, rms radial error=144.198, avgs=0 2971:195/300: dt: 0.9000, rms radial error=143.384, avgs=0 2972:200/300: dt: 0.9000, rms radial error=142.576, avgs=0 2973:205/300: dt: 0.9000, rms radial error=141.771, avgs=0 2974:210/300: dt: 0.9000, rms radial error=140.971, avgs=0 2975:215/300: dt: 0.9000, rms radial error=140.176, avgs=0 2976:220/300: dt: 0.9000, rms radial error=139.385, avgs=0 2977:225/300: dt: 0.9000, rms radial error=138.598, avgs=0 2978:230/300: dt: 0.9000, rms radial error=137.816, avgs=0 2979:235/300: dt: 0.9000, rms radial error=137.039, avgs=0 2980:240/300: dt: 0.9000, rms radial error=136.265, avgs=0 2981:245/300: dt: 0.9000, rms radial error=135.496, avgs=0 2982:250/300: dt: 0.9000, rms radial error=134.731, avgs=0 2983:255/300: dt: 0.9000, rms radial error=133.971, avgs=0 2984:260/300: dt: 0.9000, rms radial error=133.215, avgs=0 2985:265/300: dt: 0.9000, rms radial error=132.463, avgs=0 2986:270/300: dt: 0.9000, rms radial error=131.715, avgs=0 2987:275/300: dt: 0.9000, rms radial error=130.972, avgs=0 2988:280/300: dt: 0.9000, rms radial error=130.232, avgs=0 2989:285/300: dt: 0.9000, rms radial error=129.497, avgs=0 2990:290/300: dt: 0.9000, rms radial error=128.766, avgs=0 2991:295/300: dt: 0.9000, rms radial error=128.039, avgs=0 2992:300/300: dt: 0.9000, rms radial error=127.316, avgs=0 3017:distance error %100000.00 3572:pass 1: epoch 1 of 3 starting distance error %19.12 3573:pass 1: epoch 2 of 3 starting distance error %19.11 3575:starting distance error %19.02 3577:final distance error %19.05 4618:inflating to sphere (rms error < 2.00) 4619:000: dt: 0.0000, rms radial error=176.609, avgs=0 4620:005/300: dt: 0.9000, rms radial error=176.351, avgs=0 4621:010/300: dt: 0.9000, rms radial error=175.799, avgs=0 4622:015/300: dt: 0.9000, rms radial error=175.074, avgs=0 4623:020/300: dt: 0.9000, rms radial error=174.248, avgs=0 4624:025/300: dt: 0.9000, rms radial error=173.365, avgs=0 4625:030/300: dt: 0.9000, rms radial error=172.450, avgs=0 4626:035/300: dt: 0.9000, rms radial error=171.518, avgs=0 4627:040/300: dt: 0.9000, rms radial error=170.578, avgs=0 4628:045/300: dt: 0.9000, rms radial error=169.635, avgs=0 4629:050/300: dt: 0.9000, rms radial error=168.695, avgs=0 4630:055/300: dt: 0.9000, rms radial error=167.757, avgs=0 4631:060/300: dt: 0.9000, rms radial error=166.822, avgs=0 4632:065/300: dt: 0.9000, rms radial error=165.892, avgs=0 4633:070/300: dt: 0.9000, rms radial error=164.966, avgs=0 4634:075/300: dt: 0.9000, rms radial error=164.044, avgs=0 4635:080/300: dt: 0.9000, rms radial error=163.127, avgs=0 4636:085/300: dt: 0.9000, rms radial error=162.215, avgs=0 4637:090/300: dt: 0.9000, rms radial error=161.307, avgs=0 4638:095/300: dt: 0.9000, rms radial error=160.405, avgs=0 4639:100/300: dt: 0.9000, rms radial error=159.507, avgs=0 4640:105/300: dt: 0.9000, rms radial error=158.613, avgs=0 4641:110/300: dt: 0.9000, rms radial error=157.725, avgs=0 4642:115/300: dt: 0.9000, rms radial error=156.841, avgs=0 4643:120/300: dt: 0.9000, rms radial error=155.961, avgs=0 4644:125/300: dt: 0.9000, rms radial error=155.086, avgs=0 4645:130/300: dt: 0.9000, rms radial error=154.217, avgs=0 4646:135/300: dt: 0.9000, rms radial error=153.351, avgs=0 4647:140/300: dt: 0.9000, rms radial error=152.490, avgs=0 4648:145/300: dt: 0.9000, rms radial error=151.634, avgs=0 4649:150/300: dt: 0.9000, rms radial error=150.783, avgs=0 4650:155/300: dt: 0.9000, rms radial error=149.936, avgs=0 4651:160/300: dt: 0.9000, rms radial error=149.094, avgs=0 4652:165/300: dt: 0.9000, rms radial error=148.256, avgs=0 4653:170/300: dt: 0.9000, rms radial error=147.423, avgs=0 4654:175/300: dt: 0.9000, rms radial error=146.594, avgs=0 4655:180/300: dt: 0.9000, rms radial error=145.770, avgs=0 4656:185/300: dt: 0.9000, rms radial error=144.950, avgs=0 4657:190/300: dt: 0.9000, rms radial error=144.135, avgs=0 4658:195/300: dt: 0.9000, rms radial error=143.324, avgs=0 4659:200/300: dt: 0.9000, rms radial error=142.517, avgs=0 4660:205/300: dt: 0.9000, rms radial error=141.715, avgs=0 4661:210/300: dt: 0.9000, rms radial error=140.918, avgs=0 4662:215/300: dt: 0.9000, rms radial error=140.125, avgs=0 4663:220/300: dt: 0.9000, rms radial error=139.336, avgs=0 4664:225/300: dt: 0.9000, rms radial error=138.552, avgs=0 4665:230/300: dt: 0.9000, rms radial error=137.771, avgs=0 4666:235/300: dt: 0.9000, rms radial error=136.995, avgs=0 4667:240/300: dt: 0.9000, rms radial error=136.223, avgs=0 4668:245/300: dt: 0.9000, rms radial error=135.455, avgs=0 4669:250/300: dt: 0.9000, rms radial error=134.692, avgs=0 4670:255/300: dt: 0.9000, rms radial error=133.933, avgs=0 4671:260/300: dt: 0.9000, rms radial error=133.178, avgs=0 4672:265/300: dt: 0.9000, rms radial error=132.427, avgs=0 4673:270/300: dt: 0.9000, rms radial error=131.680, avgs=0 4674:275/300: dt: 0.9000, rms radial error=130.938, avgs=0 4675:280/300: dt: 0.9000, rms radial error=130.200, avgs=0 4676:285/300: dt: 0.9000, rms radial error=129.466, avgs=0 4677:290/300: dt: 0.9000, rms radial error=128.736, avgs=0 4678:295/300: dt: 0.9000, rms radial error=128.011, avgs=0 4679:300/300: dt: 0.9000, rms radial error=127.289, avgs=0 4704:distance error %100000.00 5218:pass 1: epoch 1 of 3 starting distance error %19.52 5219:pass 1: epoch 2 of 3 starting distance error %19.45 5221:starting distance error %19.40 5223:final distance error %19.42 9439:recon-all -s FSsub12534 finished without error at Thu Jan 23 15:44:35 CST 2014 2014-03-19 Chunhui Chen _________________ State Key Laboratory of Cognitive Neuroscience and Learning Beijing Normal University Beijing, China 100875

2 1

tksurfer problems
by Joo Tan 19 Mar '14

19 Mar '14

Hello I'm having problems with tksurfer. It crashes whenever I load overlays using File -> Load Overlays. Am not too sure why. Could someone help? I'm using freesurfer 5.1.0 and fsl 5.0.6 on Mac OSX version 10.7.5 Here's what i did bash-3.2$ tksurfer AMP01 rh inflated subject is AMP01 hemi is rh surface is inflated surfer: current subjects dir: /Applications/freesurfer5.1.0/subjects surfer: not in "scripts" dir ==> using cwd for session root surfer: session root data dir ($session) set to: surfer: /Users/Joo/Documents/fMRI/AMMatch/analysis checking for nofix files in 'inflated' Reading image info (/Applications/freesurfer5.1.0/subjects/AMP01) Reading /Applications/freesurfer5.1.0/subjects/AMP01/mri/orig.mgz surfer: Reading header info from /Applications/freesurfer5.1.0/subjects/AMP01/mri/orig.mgz surfer: vertices=134552, faces=269100 surfer: single buffered window surfer: tkoInitWindow(AMP01) surfer: using interface /Applications/freesurfer5.1.0/tktools/tksurfer.tcl Reading /Applications/freesurfer5.1.0/tktools/tkm_common.tcl Reading /Applications/freesurfer5.1.0/tktools/tkm_wrappers.tcl Reading /Applications/freesurfer5.1.0/lib/tcl/fsgdfPlot.tcl Reading /Applications/freesurfer5.1.0/tktools/tkUtils.tcl Successfully parsed tksurfer.tcl reading white matter vertex locations... % HIPS unsupported -- Cheers Joo

2 1

ADC, Radial diffusivity, Axial diffusivity and thresholds
by Yuko Yotsumoto 18 Mar '14

18 Mar '14

Hello FreeSurfer experts, I have a question regarding DTI analysis. I understand that FA values ranges 0-1, and the values are often thresholded by 0.2. Now I am asked to report ADC, RD, AD values in my ROIs, and wondering what would be the most reasonable way. [1] Do not apply thresholds, just average the values within a ROI. [2] Use some arbitrary thresholds to each of ADC, RD, AD. [3] create a mask that contains voxels of the above-threshold-FAvalues, then, calculate mean within the mask. Any suggestions? Best, Yuko Yotsumoto

2 1

Re: [Freesurfer] FW: bug in surface-based area and volume, and use of total brain volume as a covariate
by Narly Golestani 18 Mar '14

18 Mar '14

1 0

Mapping parcellation ROIs to the surface
by Danielle Sliva 18 Mar '14

18 Mar '14

Dear FreeSurfer experts, I am trying to find the surface ROIs for (volumetric) parcellation ROIs, as mentioned in: Frye, RE et al. 2010. Surface Area Accounts for the Relation of Gray Matter Volume to Reading-Related Skills and History of Dyslexia. Cerebral Cortex 20:2625-2635. I have run all subjects through the recon-all stream, and now want to project the inferior frontal, fusiform, angular, and supramarginal gyri to the surfaces. I've been able to find these ROIs in: <subject>/label/aparc.annot.a2009s.ctab: 25 G_pariet_inf-Angular 20 60 220 0 and <subject>/label/aparc.annot.ctab 07 fusiform 180 220 140 0 31 supramarginal 80 160 20 0 18 parsopercularis 220 180 140 0 20 parstriangularis 220 60 20 0 For the above, I'm assuming this means that in the relevant volume files (aparc.a2009s.+aseg.mgz & aparc+aseg.mgz), the voxels with intensities as labelled correspond to to the gyri. How do I project these regions to the subject surfaces? I assume I must use 'mri_vol2surf', but there are so many options I'm not sure what to use. I'd very much appreciate some input! Thanks in advance, Danielle -- Danielle Sliva, MA Data Coordinator Boston Children's Hospital Division of Developmental Medicine Laboratories of Cognitive Neuroscience, Gaab Lab Fetal-Neonatal Neuroimaging & Developmental Science Center 1 Autumn St, AU640 Boston, MA 02215 tel: (857) 218-5210 fax: (617) 730-0518

2 1

← Newer
1
...
10
11
12
13
14
15
16
...
25
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Freesurfer March 2014