Freesurfer

freesurfer@nmr.mgh.harvard.edu

19 participants
30088 discussions

DTI analysis: freesurfer vs DTI studio
by Ayaz, Muhammad 09 Mar '12

09 Mar '12

Dear All, I am new to freesurfer DTI analysis. Can anybody explain what is the advantage of using freesurfer for DTI analysis over DTI studio? Ayaz The information contained in this message and any attachments is intended only for the use of the individual or entity to which it is addressed, and may contain information that is PRIVILEGED, CONFIDENTIAL, and exempt from disclosure under applicable law. If you are not the intended recipient, you are prohibited from copying, distributing, or using the information. Please contact the sender immediately by return e-mail and delete the original message from your system.

4 3

Group comparison
by Allie Rosen 09 Mar '12

09 Mar '12

Hi All, I am trying to compare controls to patients. There is an interaction between group and age (i.e. the aging pattern is different for both groups). I did an interaction contrast and this was significant in the same areas that were significant in the original comparison. I can't switch to a DOSS model (because the slopes are different). Interestingly, I'm getting some areas increasing with age as well, but I'm not sure if these results are valid since some may argue I can't compare the group thicknesses if there is this interaction. There aren't topologic errors in my samples either. Given all this, I'm at a bit of a loss in terms of figuring out how to compare thicknesses between the groups. Can it still be done? Thank you, Allison

1 0

save custom made path on surface as label
by Erhan Genc 09 Mar '12

09 Mar '12

Dear freesurfer experts, I draw a path with the tksurfer tools on a surface, but was not able to save this path as a label. During the custom fill step it marked the whole surface and not just the path. I think it is because the path is not closed. Is there still a way to get a path as a label file? cheers, erhan -- Dipl. Psych. Erhan Genc Max Planck Institute for Brain Research Department of Neurophysiology Deutschordenstr. 46 60528 Frankfurt am Main -GERMANY- phone: +49 (69) 96769-471 fax: +49 (69) 96769-327 e-mail: genc(a)mpih-frankfurt.mpg.de http://www.brain.mpg.de/research/singer-emeritus-department/people/erhan-ge…

2 3

tkregister2 error
by Daniel Preciado 09 Mar '12

09 Mar '12

Dear list, I'm having problems with the tkregister2 command, I input the following command: tkregister2 --mov ~/Desktop/input/*_d/mri/rawavg.mgz --noedit --s *_d --regheader --reg ~/Desktop/input/*_d/mri/register.dat Where I'm setting the directory of my subjects, and I get the following output /Desktop/input/*_d/mri/register.dat /usr/local/freesurfer/tktools/tkregister2.bin: No match. However, when I try a similar command with the sample data from bert (And after adjusting the subject folder settings) It works fine. I ran out of ideas on how to fix it, does anybody have any clue of what can I do? Thanks a lot for your help Regards

2 1

dimension mismatch in fieldsign-sess
by Greg Burgess 08 Mar '12

08 Mar '12

Hi freesurfers, I'm getting an error that I don't know how to track down. Running the following command: fieldsign-sess -a rtopy.self.lh -sphere -s CP10021_v5 I get the following error: reading colortable from annotation file... colortable with 36 entries read (originally /autofs/space/terrier_001/users/nicks/freesurfer/average/colortable_desikan_killiany.txt) Complex Reshaping 7208 Ripping Zeros ERROR: MRISripZeros(): dimension mismatch ERROR: MRIScopyMRI: Surf/Src dimension mismatch. ERROR: MRIScopyMRI: Surf/Src dimension mismatch. ERROR: MRIScopyMRI: Surf/Src dimension mismatch. ERROR: MRIScopyMRI: Surf/Src dimension mismatch. Rot (rad): 0 0 surfer: compute_fieldsign() As suggested in previous posts, I've tried running: recon-all -s CP10021_v5 -make all -dontrun recon-all -vno-check -s CP10021_v5 but no issues are reported, and I can't find any issues in the log files or output. Can anyone suggest a next step? Thanks, --Greg ____________________________________________________________________ Greg Burgess, Ph.D. Staff Scientist, Human Connectome Project Washington University School of Medicine Department of Anatomy and Neurobiology Email: burgessg(a)pcg.wustl.edu

3 4

Re: [Freesurfer] strange values for % signal change
by Douglas N Greve 08 Mar '12

08 Mar '12

It might be ok to do it the way that you suggest. If you have an event that does not have many presentations, then it will be susceptible to noise. If you then average that with other events that have many presentations, then the average will be contaminated and it will be better to combine them in the paradigm file. If the number of presentations is balanced, then combining them in the contrast is probably ok. If you do this, when you look at the output of roisummary-sess you should average the values together before judging whether they are high or low. doug Finnegan Calabro wrote: > I'll try that… we created a lot of events with the intention of just having a couple contrasts that combine many events together (e.g., to compare events 1-10 vs 11-21 in one contrast, and 1-5/11-15 vs 6-10/16-21 in another, and so on). So the contrasts that do this do have lots of significant regions, but we haven't actually tried looking at the individual events vs null (though I suspect you're right that they won't have much that's significant). > > But maybe this isn't an ideal way of doing the analysis, and it'd be better to either (1) have fewer events and just use different analyses (with a different trial-to-event mapping for each) for each contrast, or (2) compute % signal change based on the contrast rather than the event (though I'm not sure if there's a nice way to do this other than loading ces.nii and h-offset.nii in matlab and masking them by the roi?). > > > > > On Mar 8, 2012, at 3:04 PM, Douglas N Greve wrote: > > >> The only thing that I can think of is that the data are really noisy and you're just getting a really big spread. I computed the efficiency of condition 18, and it was pretty low. The variance reduction factor was actually less than 1, meaning that you are actually amplifying the noise in your design. This is probably a side effect of having 21 conditions. To debug this further, try reducing the number of conditions (maybe just to 1 or 2) and see if the extreme values go away. Do you actually see any significance in the maps of 18 vs fixation? >> doug >> >> Finnegan Calabro wrote: >> >>> Here it is, thanks again. >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> On Mar 8, 2012, at 2:39 PM, Douglas N Greve wrote: >>> >>> >>> >>>> Nothing comes to mind. Can you send me the X.mat file in the analysis dir? >>>> >>>> >>>> Finnegan Calabro wrote: >>>> >>>> >>>>> Thanks Doug. Looking at the beta.nii.gz values in the mask (assuming the first N entries in beta correspond to the N events, with nuisance variables after that), the values for event 18 (which had a particularly high % signal change) look like: >>>>> >>>>> 4.3453 >>>>> 21.4786 >>>>> 16.6500 >>>>> 8.1440 >>>>> 31.4507 >>>>> 5.0272 >>>>> 15.9165 >>>>> 36.8251 >>>>> 7.9907 >>>>> 20.7835 >>>>> 14.6263 >>>>> 18.0771 >>>>> 19.3031 >>>>> 9.8763 >>>>> 5.2008 >>>>> 9.1234 >>>>> 21.6566 >>>>> 22.7819 >>>>> 27.9337 >>>>> 22.8663 >>>>> 22.2126 >>>>> >>>>> So it doesn't seem to be one (or a small number) of voxels skewing the data. I don't think we're landing in the ventricles either, in part because this is happening to all of the 7 ROIs we've defined all over the cortex. We also looked at cespct.nii.gz and see lots of pretty high values in there as well (though that's for a contrast, not an event, and I'm not sure whether those values should necessarily match). >>>>> >>>>> Can you think of anything else we should check that could be causing this? (it was a pretty standard analysis design i think, but could something wrong at that stage have produced results like this?). >>>>> >>>>> Thanks very much! >>>>> >>>>> >>>>> On Mar 8, 2012, at 11:58 AM, Douglas N Greve wrote: >>>>> >>>>> >>>>> >>>>>> Hi Finnegan, there's nothing there that looks wrong with your commands, but I agree that those values look too high. It is possible that some of the 12 voxels in the ROI is causing the problem. If you go into the subject's analysis dir, you'll see a mask there that corresponds to your ROI. You can load that in matlab, find the voxels in the mask, then load the beta.nii.gz and extract out the values from those voxels to see if something looks funny. Also, check to see whether any of the mask falls into ventricle. >>>>>> doug >>>>>> >>>>>> Finnegan Calabro wrote: >>>>>> >>>>>> >>>>>>> Hi all, we're using 5.1 to analyze some single subject, event-related functional data, and are getting some strangely high values for % signal change when using func2roi-sess and roisummary-sess. Here are the commands we're running: >>>>>>> >>>>>>> func2roi-sess -s LMV2012_N01_heading -roidef rhmed_singlevsdouble_1 -analysis glheadgen_analysis -labelfile /home/vmrao17/freesurfer/subjects/LMV2012_N01/label/rhmed_singlevsdouble_1.label -maskcontrast allvsoff -maskthresh 1.50 -masktail pos -maskmap sig >>>>>>> >>>>>>> roisummary-sess -sumfile /home/vmrao17/tmp/summary.txt -roidef rhmed_singlevsdouble_1 -analysis glheadgen_analysis -s LMV2012_N01_heading >>>>>>> >>>>>>> >>>>>>> And this is the output of summary.txt: >>>>>>> >>>>>>> LMV2012_N01_heading 51 >>>>>>> 12 >>>>>>> 123.737160 >>>>>>> 1.535988 >>>>>>> 1572.000000 >>>>>>> 0.050000 >>>>>>> -0.000000 >>>>>>> 21 >>>>>>> 1 >>>>>>> 0.734151 >>>>>>> 3.595402 >>>>>>> 4.435675 >>>>>>> 5.482294 >>>>>>> 0.544176 >>>>>>> -0.166144 >>>>>>> 2.951724 >>>>>>> 2.114511 >>>>>>> 3.178010 >>>>>>> 2.814232 >>>>>>> 0.944738 >>>>>>> 0.466052 >>>>>>> 8.508595 >>>>>>> 7.646451 >>>>>>> 6.767788 >>>>>>> 9.197896 >>>>>>> 8.802674 >>>>>>> 11.339759 >>>>>>> 7.822568 >>>>>>> 4.040024 >>>>>>> 8.018742 >>>>>>> >>>>>>> The problem is that the effect size values seem very high and/or the baseline seems very low (e.g., 100*11.33/123.7=9%!). >>>>>>> >>>>>>> In 4.5 we were computing a scaling factor for these values, but my understanding was that in 5.1 that was no longer needed, correct? Is there anything else we should be doing differently when computing % signal change from this output now? The only other strange thing I notice is that the TER value is 0.05, but documentation describes TR/20 and our TR=2sec, which would seem to suggest it should be 0.1 instead of 0.05? >>>>>>> >>>>>>> I'm attaching the full output log for the two commands above as well. Anything that we're obviously doing wrong? Thanks! >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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: www.nmr.mgh.harvard.edu/facility/filedrop/index.html >>>>>> >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>> >>>>> >>>> -- >>>> 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: www.nmr.mgh.harvard.edu/facility/filedrop/index.html >>>> >>>> >> -- >> 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: www.nmr.mgh.harvard.edu/facility/filedrop/index.html >> > > > > -- 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: www.nmr.mgh.harvard.edu/facility/filedrop/index.html

1 0

Re: [Freesurfer] strange values for % signal change
by Douglas N Greve 08 Mar '12

08 Mar '12

The only thing that I can think of is that the data are really noisy and you're just getting a really big spread. I computed the efficiency of condition 18, and it was pretty low. The variance reduction factor was actually less than 1, meaning that you are actually amplifying the noise in your design. This is probably a side effect of having 21 conditions. To debug this further, try reducing the number of conditions (maybe just to 1 or 2) and see if the extreme values go away. Do you actually see any significance in the maps of 18 vs fixation? doug Finnegan Calabro wrote: > Here it is, thanks again. > > ------------------------------------------------------------------------ > > > > > On Mar 8, 2012, at 2:39 PM, Douglas N Greve wrote: > > >> Nothing comes to mind. Can you send me the X.mat file in the analysis dir? >> >> >> Finnegan Calabro wrote: >> >>> Thanks Doug. Looking at the beta.nii.gz values in the mask (assuming the first N entries in beta correspond to the N events, with nuisance variables after that), the values for event 18 (which had a particularly high % signal change) look like: >>> >>> 4.3453 >>> 21.4786 >>> 16.6500 >>> 8.1440 >>> 31.4507 >>> 5.0272 >>> 15.9165 >>> 36.8251 >>> 7.9907 >>> 20.7835 >>> 14.6263 >>> 18.0771 >>> 19.3031 >>> 9.8763 >>> 5.2008 >>> 9.1234 >>> 21.6566 >>> 22.7819 >>> 27.9337 >>> 22.8663 >>> 22.2126 >>> >>> So it doesn't seem to be one (or a small number) of voxels skewing the data. I don't think we're landing in the ventricles either, in part because this is happening to all of the 7 ROIs we've defined all over the cortex. We also looked at cespct.nii.gz and see lots of pretty high values in there as well (though that's for a contrast, not an event, and I'm not sure whether those values should necessarily match). >>> >>> Can you think of anything else we should check that could be causing this? (it was a pretty standard analysis design i think, but could something wrong at that stage have produced results like this?). >>> >>> Thanks very much! >>> >>> >>> On Mar 8, 2012, at 11:58 AM, Douglas N Greve wrote: >>> >>> >>> >>>> Hi Finnegan, there's nothing there that looks wrong with your commands, but I agree that those values look too high. It is possible that some of the 12 voxels in the ROI is causing the problem. If you go into the subject's analysis dir, you'll see a mask there that corresponds to your ROI. You can load that in matlab, find the voxels in the mask, then load the beta.nii.gz and extract out the values from those voxels to see if something looks funny. Also, check to see whether any of the mask falls into ventricle. >>>> doug >>>> >>>> Finnegan Calabro wrote: >>>> >>>> >>>>> Hi all, we're using 5.1 to analyze some single subject, event-related functional data, and are getting some strangely high values for % signal change when using func2roi-sess and roisummary-sess. Here are the commands we're running: >>>>> >>>>> func2roi-sess -s LMV2012_N01_heading -roidef rhmed_singlevsdouble_1 -analysis glheadgen_analysis -labelfile /home/vmrao17/freesurfer/subjects/LMV2012_N01/label/rhmed_singlevsdouble_1.label -maskcontrast allvsoff -maskthresh 1.50 -masktail pos -maskmap sig >>>>> >>>>> roisummary-sess -sumfile /home/vmrao17/tmp/summary.txt -roidef rhmed_singlevsdouble_1 -analysis glheadgen_analysis -s LMV2012_N01_heading >>>>> >>>>> >>>>> And this is the output of summary.txt: >>>>> >>>>> LMV2012_N01_heading 51 >>>>> 12 >>>>> 123.737160 >>>>> 1.535988 >>>>> 1572.000000 >>>>> 0.050000 >>>>> -0.000000 >>>>> 21 >>>>> 1 >>>>> 0.734151 >>>>> 3.595402 >>>>> 4.435675 >>>>> 5.482294 >>>>> 0.544176 >>>>> -0.166144 >>>>> 2.951724 >>>>> 2.114511 >>>>> 3.178010 >>>>> 2.814232 >>>>> 0.944738 >>>>> 0.466052 >>>>> 8.508595 >>>>> 7.646451 >>>>> 6.767788 >>>>> 9.197896 >>>>> 8.802674 >>>>> 11.339759 >>>>> 7.822568 >>>>> 4.040024 >>>>> 8.018742 >>>>> >>>>> The problem is that the effect size values seem very high and/or the baseline seems very low (e.g., 100*11.33/123.7=9%!). >>>>> >>>>> In 4.5 we were computing a scaling factor for these values, but my understanding was that in 5.1 that was no longer needed, correct? Is there anything else we should be doing differently when computing % signal change from this output now? The only other strange thing I notice is that the TER value is 0.05, but documentation describes TR/20 and our TR=2sec, which would seem to suggest it should be 0.1 instead of 0.05? >>>>> >>>>> I'm attaching the full output log for the two commands above as well. Anything that we're obviously doing wrong? Thanks! >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> 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: www.nmr.mgh.harvard.edu/facility/filedrop/index.html >>>> >>>> >>>> >>>> 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. >>>> >>>> >>> >>> >>> >> -- >> 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: www.nmr.mgh.harvard.edu/facility/filedrop/index.html >> -- 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: www.nmr.mgh.harvard.edu/facility/filedrop/index.html

1 0

strange values for % signal change
by Finnegan Calabro 08 Mar '12

08 Mar '12

Hi all, we're using 5.1 to analyze some single subject, event-related functional data, and are getting some strangely high values for % signal change when using func2roi-sess and roisummary-sess. Here are the commands we're running: func2roi-sess -s LMV2012_N01_heading -roidef rhmed_singlevsdouble_1 -analysis glheadgen_analysis -labelfile /home/vmrao17/freesurfer/subjects/LMV2012_N01/label/rhmed_singlevsdouble_1.label -maskcontrast allvsoff -maskthresh 1.50 -masktail pos -maskmap sig roisummary-sess -sumfile /home/vmrao17/tmp/summary.txt -roidef rhmed_singlevsdouble_1 -analysis glheadgen_analysis -s LMV2012_N01_heading And this is the output of summary.txt: LMV2012_N01_heading 51 12 123.737160 1.535988 1572.000000 0.050000 -0.000000 21 1 0.734151 3.595402 4.435675 5.482294 0.544176 -0.166144 2.951724 2.114511 3.178010 2.814232 0.944738 0.466052 8.508595 7.646451 6.767788 9.197896 8.802674 11.339759 7.822568 4.040024 8.018742 The problem is that the effect size values seem very high and/or the baseline seems very low (e.g., 100*11.33/123.7=9%!). In 4.5 we were computing a scaling factor for these values, but my understanding was that in 5.1 that was no longer needed, correct? Is there anything else we should be doing differently when computing % signal change from this output now? The only other strange thing I notice is that the TER value is 0.05, but documentation describes TR/20 and our TR=2sec, which would seem to suggest it should be 0.1 instead of 0.05? I'm attaching the full output log for the two commands above as well. Anything that we're obviously doing wrong? Thanks!

2 3

Re: [Freesurfer] Annotation question
by Antonella Kis 08 Mar '12

08 Mar '12

Thanks Doug. You mean by subject to define the subject in the fs_tal2surf which by default is 'subj': FreeSurfer subject % {default = 'fsaverage'} to be subj = cvs_avg35? Thanks. Antonella ________________________________ From: Douglas N Greve <greve(a)nmr.mgh.harvard.edu> To: Antonella Kis <atorok9(a)yahoo.com>; freesurfer <freesurfer(a)nmr.mgh.harvard.edu> Sent: Thursday, March 8, 2012 12:06 PM Subject: Re: Annotation question Hi Antonella, use cvs_avg35 as the subject and ?h.aparc.annot for the annotation. Antonella Kis wrote: > Hi Doug, > > Sorry I bother again I just want to ask you an advice. I was running the code which was sent to me by Don: > > vals = fs_tal2surf([-16.92 -29.55 34.44]); > ind_lh = find(vals{1}); > ind_rh = find(vals{2}); > > [lh_roinums,lh_roilabels] = fs_read_annotation(fname_annot_lh); > [rh_roinums,rh_roilabels] = fs_read_annotation(fname_annot_rh); > > if ~isempty(ind_lh) > roinum = lh_roinums(ind_lh); > roilabel = lh_roilabels{roinum}; > elseif ~isempty(ind_rh) > roinum = rh_roinums(ind_rh); > roilabel = rh_roilabels{roinum}; > end > > > and it works perfect but I am a little confused regarding my data. > > I am looking to find the nearst cortical label for my clusters for the DTI data:FA, MD,RD,AD. I registered this data on the CVS space so I wonder if I should use for the fname_annot_lh and fname_annot_rh the annotations from the CVS space not from fsaverage. I tried both and got different locations for my clusters. > > Can you please advise me? > > Many thansk. > Antonella -- 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: www.nmr.mgh.harvard.edu/facility/filedrop/index.html 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.

2 1

Re: [Freesurfer] aparc.a2005s+aseg.mgz
by Douglas N Greve 08 Mar '12

08 Mar '12

That is just a color lookup table that has an exhaustive list of possible regions. We do not label all of these, and some of them appear in some segmentations and not in others. I don't know who (or what program) does that thalamus labeling (it is not part of a2005s). It is probably part of the tract-based labeling that Zeynep Saygin does. doug Kern, Mark wrote: > Hi Doug, > > I must be misunderstanding the contents of the a2005s. From the LUT at http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/AnatomicalROI/FreeSurfe…, there is a section under the color table listing for the a2005s for index numbers in the 7000's and 8000's that list thalamic and subcortical regions. If these indices are not part of the a2005s scheme, are they available in any other segmentation schemes? > Thanks for considering this matter. > > Best, > Mark > > > ________________________________________ > From: Douglas N Greve [greve(a)nmr.mgh.harvard.edu] > Sent: Thursday, March 08, 2012 10:37 AM > To: Kern, Mark; freesurfer > Subject: Re: [Freesurfer] aparc.a2005s+aseg.mgz > > Hi Mark, I don't think thalamic structures were part of the a2005s. I > think it was only cortical structures. The aparc.a2005s+aseg.mgz will > have a whole thalamus segmentation, but that is inherited from the aseg.mgz > doug > > Kern, Mark wrote: > >> Hi Doug, >> >> Yes, the aparc.a2009s+aseg.mgz files were created and I have used them in a great deal of our analysis of large scale network connectivity of cerebral cortical regions. We have a desire to look at some subcortical structures that are part of the a2005s scheme but not included in the a2009s treatment, especially the subdivision of the thalamus. Any help in this matter would be greatly appreciated. >> >> Best Wishes, >> Mark >> >> >> On Mar 7, 2012, at 10:47 PM, Douglas Greve wrote: >> >> >> >>> Hi Mark, was aparc.a2009s+aseg.mgz created? That is the new one. >>> doug >>> >>> On 3/7/12 8:43 AM, Kern, Mark wrote: >>> >>> >>>> Dear Freesurfer Mavens, >>>> >>>> After running "recon-all -all" on a set of anatomical data, I wished to used the aparc.a2005s+aseg.mgz in a connectivity analysis pipeline to create some ROI masks. I was particularly interested in the subcortical regions contained in the a2005s scheme. However, the aparc.a2005s+aseg.mgz file was not created during the recon-all processing run. Is there a way to get the a2005s segmentation data? >>>> >>>> Thanks for your help. >>>> >>>> Best, >>>> >>>> Mark >>>> >>>> Senior Research Scientist >>>> Division of Gastroenterology and Hepatology >>>> Departmernt of Medicine >>>> Medical College of Wisconsin >>>> Milwaukee, WI >>>> _______________________________________________ >>>> Freesurfer mailing list >>>> Freesurfer(a)nmr.mgh.harvard.edu >>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> 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. >>> >>> >>> >> >> >> > > -- > 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: www.nmr.mgh.harvard.edu/facility/filedrop/index.html > > > > -- 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: www.nmr.mgh.harvard.edu/facility/filedrop/index.html

1 0

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