Freesurfer March 2012

freesurfer@nmr.mgh.harvard.edu

137 participants
209 discussions

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

Re: [Freesurfer] Annotation question
by Douglas N Greve 08 Mar '12

08 Mar '12

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

1 0

Interpreting Results
by Allie Rosen 08 Mar '12

08 Mar '12

Hi All, I'm having trouble reconciling the cluster colours with the graph that can be made when you load the group descriptor file and click on a point. I've attached an example. In this study, I'm comparing thickness in a patient and control group, with age regressed out. The contrast I've used means that blue means control<patient. Therefore, patients are thicker than controls. But in the graph, patients don't seem to be thicker. I've seen the same results with red clusters (i.e. they should mean that controls are thicker but the graph shows otherwhise). Please let me know how I can interpret my findings given the graph. Which group is actually thicker? Thank you, Allison

3 14

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

08 Mar '12

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

1 0

Re: [Freesurfer] freesurfer 5.1 error: MPR2MNI305_TARGET: Undefined variable
by Ian Charest 08 Mar '12

08 Mar '12

Hi again More on this note: Using the previous stable version 4.3.0 that I have installed here, I have absolutely no problem in running the same process. ian From: freesurfer-bounces(a)nmr.mgh.harvard.edu [mailto:freesurfer-bounces@nmr.mgh.harvard.edu] On Behalf Of Ian Charest Sent: 07 March 2012 18:09 To: freesurfer(a)nmr.mgh.harvard.edu Subject: [Freesurfer] freesurfer 5.1 error: MPR2MNI305_TARGET: Undefined variable Hi When running recon-all I get the following error: ERROR: mpr2mni305 failed, see transforms/talairach_avi.log I called recon-all like so: recon-all -i /imaging/ic01/mridata/subject01/structurals/subject01.MR.SEQUENCE.0014.0001.2011.12.16.57.613319.8231038.IMA -all -subjid subject01 I checked the talairach_avi.log file (see the full report below), and the mistake happens at the call to mpr2mni305 MPR2MNI305_TARGET: Undefined variable. I searched the mailing list for similar errors and saw a similar post here: https://mail.nmr.mgh.harvard.edu/pipermail//freesurfer/2011-May/018445.html<https://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/2011-May/018445.html> but in this user's case there seemed to be a problem with the MPRAGE image itself (the brain seemed "squashed") I checked the dimensions of my orig.mgz and they are ok (1x1x1). I had a look at my orig.mgz in tkmedit and all seems fine. Any Idea what could be going wrong? Best Wishes Ian Charest ====== talairach_avi.log: /imaging/ic01/subjects/subject01/mri /imaging/local/software/freesurfer/5.1.0/i686//bin/talairach_avi --i orig.mgz --xfm transforms/talairach.auto.xfm $Id: talairach_avi,v 1.9 2011/03/02 18:38:06 nicks Exp $ Linux l34 2.6.9-89.0.25.ELsmp #1 SMP Mon Apr 19 06:05:15 EDT 2010 i686 i686 i386 GNU/Linux Wed Mar 7 16:56:30 GMT 2012 /imaging/local/software/freesurfer/5.1.0/i686/bin_original/mri_convert orig.mgz talsrcimg.img $Id: mri_convert.c,v 1.179.2.2 2011/05/16 20:53:47 greve Exp $ reading from orig.mgz... TR=2300.00, TE=2.96, TI=900.00, flip angle=9.00 i_ras = (-1, 4.65661e-08, -4.09782e-08) j_ras = (-2.23517e-08, -3.72529e-09, -1) k_ras = (3.81842e-08, 1, -6.98492e-10) writing to talsrcimg.img... Analyze Output Matrix -1.000 -0.000 0.000 132.161; 0.000 -0.000 1.000 -103.886; -0.000 -1.000 -0.000 97.205; 0.000 0.000 0.000 1.000; -------------------- INFO: set hdr.hist.orient to -1 mpr2mni305 talsrcimg Wed Mar 7 16:56:34 GMT 2012 /imaging/local/software/freesurfer/5.1.0/i686/bin_original/mpr2mni305 talsrcimg $Id: mpr2mni305,v 1.4 2009/06/03 16:01:38 nicks Exp $ MPR2MNI305_TARGET: Undefined variable.

3 3

recon-all exit with errors.
by Hellyer, Peter 08 Mar '12

08 Mar '12

Good Morning, List. I'm recon-all(ing) a bunch of T1 images using the command recon-all -i input.nii.gz -subject name -all -sd /path/to/subject/directory Most of the time, these are running just fine, but occasionally, they are exiting with error (recon-all.log attached). I don't understand what is going on, as the input data looks okay and I'm running the same command over and over (using PBS)…. Any help would be appreciated. Best Wishes Peter

3 2

← Newer
1
...
13
14
15
16
17
18
19
20
21
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 2012