Freesurfer

freesurfer@nmr.mgh.harvard.edu

30132 discussions

Error viewing corrected results
by Martin Juneja 06 Mar '17

06 Mar '17

Hello everyone, I am trying to extract clusters showing significant correlation between LGI and a behavioral measure. I am able to extract PCC and sig.mgh but at the last step when I try to run simulation command to view corrected results and I run: mri_glmfit-sim --glmdir lh.MEQ_LGI.glmdir --cache 4 neg --cwp 0.05 --2spaces I get following error: ERROR: cannot find /usr/local/freesurfer/average/mult-comp-cor/fsaverage/lh/cortex/fwhm35/neg/th40/mc-z.csd But I can see mc-z.csd file in fwhm30 etc. Full message on terminal window is attached following. Any help would be really appreciated. ----- Full message ---- cmdline mri_glmfit.bin --y lh.MEQ_LGI.10.mgh --fsgd MEQ.fsgd dods --C Corr-MEQ-cor.mtx --surf fsaverage lh --cortex --glmdir lh.MEQ_LGI.glmdir WARNING: unrecognized mri_glmfit cmd option mri_glmfit.bin SURFACE: fsaverage lh log file is lh.MEQ_LGI.glmdir/cache.mri_glmfit-sim.log /usr/local/freesurfer/bin/mri_glmfit-sim --glmdir lh.MEQ_LGI.glmdir --cache 4 neg --cwp 0.05 --2spaces $Id: mri_glmfit-sim,v 1.60 2016/04/30 15:13:36 greve Exp $ Mon Mar 6 11:11:13 MST 2017 setenv SUBJECTS_DIR /data/emot/Freesurfer/FreeSurferSegmentation/SB_AgingAll FREESURFER_HOME /usr/local/freesurfer Original mri_glmfit command line: cmdline mri_glmfit.bin --y lh.MEQ_LGI.10.mgh --fsgd MEQ.fsgd dods --C Corr-MEQ-cor.mtx --surf fsaverage lh --cortex --glmdir lh.MEQ_LGI.glmdir DoSim = 0 UseCache = 1 DoPoll = 0 DoPBSubmit = 0 DoBackground = 0 DiagCluster = 0 gd2mtx = dods fwhm = 35.073391 ERROR: cannot find /usr/local/freesurfer/average/mult-comp-cor/fsaverage/lh/cortex/fwhm35/neg/th40/mc-z.csd

2 3

OFC wmparc labels
by Duncan Cleveland 06 Mar '17

06 Mar '17

Dear FreeSurfer experts, I am writing today to ask if you can help my group and I with an issue with the white matter parcellations. While inspecting the output from wmparc.mgz in our dataset, we noticed an unusual parcellation in the medial- and lateral OFC labels in both the left and right hemispheres. Specifically, the white matter labels often extend behind the nucleus accumbens and the putamen (see attached screenshot FS_OFC.tif). Curiously, there appears to be lateralization in the extension; while the right hemisphere often has both the medial and lateral OFC labels extend, the left hemisphere only sees the medial OFC label extend that far back. We have looked through several subjects and their FreeSurfer output, and the effect appears in nearly all the subjects. Initially, we thought this was an issue with our processing stream or subtle biases in our data collection. However, subjects which come packaged with FreeSurfer also show the same effect. Bert, for example, shows the same extension of the OFC posterior to subcortical structures (see screenshot Bert_FS5_OFC or coordinates 133, 127, 137). Again, we see the differences in hemispheres as well, with the left containing only medial OFC posterior to subcortical structures and the right containing both lateral and medial OFC. We are running version 5.3, but the issue persists into version 6.0 (Bert_FS6_OFC or coordinates 134, 128, 137). In fact, we not only see hemispheric differences, but the left hemisphere medial OFC actually bleeds into the right hemisphere as well. Fsaverage does not have a wmparc, so I was unable to see if the issue persists in that output as well. I have a number of questions associated with this issue. First, to confirm, is this a real issue of mistaken anatomy? The output in this region simply looks incorrect to us anatomically, as we believe that the OFC should not extend posterior to subcortical structures. Second, is there a method to restrict the OFC to regions anterior to the nucleus accumbens without messing up the rest of the algorithm? And third, why do we see differences in hemispheres? Why does the left hemisphere only have medial OFC white matter posterior to the accumbens when the right hemisphere has both? Thanks and best, Duncan Cleveland MCTFR University of Minnesota

2 1

Re: [Freesurfer] Automated extraction of dural/meningeal ROI?
by Antonin Skoch 06 Mar '17

06 Mar '17

Dear Daniel, For the "outer" boundary of your ROI, I would try the betsurf from FSL for the inner skull surface estimation. This should be more precise than using brainmask.mgz. https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/BET/UserGuide Antonin You could remove the brain (as found in aseg.mgz) from the brainmask.mgz. This will leave some dura. It is not an elegant or accurate solution On 03/06/2017 02:24 PM, Albrecht, Daniel S. wrote: > Hello, > > We have a PET dataset where we expect to see pathogenic changes in the > meninges. We'd like to extract the meningeal signal in subject space, > and were hoping to come up with an automated strategy to create > meningeal ROIs, containing no brain or scalp. > So my question is: can you suggest any way within the FreeSurfer > pipeline that we can create a meningeal-only ROI, or alternatively an > ROI containing both skull and meninges, but still no scalp or brain? > > Your help is greatly appreciated! > > Daniel S. Albrecht, PhD > Research Fellow in Radiology > Martinos Center for Biomedical Imaging

1 0

Automated extraction of dural/meningeal ROI?
by Albrecht, Daniel S. 06 Mar '17

06 Mar '17

Hello, We have a PET dataset where we expect to see pathogenic changes in the meninges. We'd like to extract the meningeal signal in subject space, and were hoping to come up with an automated strategy to create meningeal ROIs, containing no brain or scalp. So my question is: can you suggest any way within the FreeSurfer pipeline that we can create a meningeal-only ROI, or alternatively an ROI containing both skull and meninges, but still no scalp or brain? Your help is greatly appreciated! Daniel S. Albrecht, PhD Research Fellow in Radiology Martinos Center for Biomedical Imaging Massachusetts General Hospital 149 Thirteenth Street, Room 2301 Charlestown, MA 02129 Phone: (617) 643-6748 Fax: (617) 726-7422 dsalbrecht(a)mgh.harvard.edu<https://owa.partners.org/cvpn/aHR0cHM6Ly9wcm94eS1vd2EucGFydG5lcnMub3Jn/owa/…>

2 1

Re: [Freesurfer] threshold method used to obtain *exvivo.thresh.labels
by Antonin Skoch 06 Mar '17

06 Mar '17

Dear experts, concerning my question regarding thresholding method of entorhinal and perirhinal labels, I looked at Augustinack JC et al, Predicting the location of human perirhinal cortex, Brodmann's area 35, from MRI, Neuroimage 2013 Jan 1;64:32-42. where I found the text: For each label, the vertices were ordered from most probable least probable), then thresholded so that the surface area of each predicted entorhinal cortex or perirhinal cortex label matched the average surface area of the ex vivo labels. So, if I understand it correctly, at least for the entorhinal and perirhinal *thresh labels, the threshold has been found individually for each label and hemisphere separately, so that the area of the label in the fsaverage space match average surface area of the corresponding ex-vivo labels? Therefore, no restriction for overlap of perirhinal and entorhinal labels was applied in the thresholding? I found that in the right hemisphere the rh.entorhinal_thresh.label almost completely overlaps with lh.entorhinal_thresh.label. But, for generating custom aparc+aseg I need non-overlapping labels. I attempted to resolve the issue by using mris_label2annot --s fsaverage --l fsaverage/label/lh.entorhinal_exvivo.label --l fsaverage/label/lh.perirhinal_exvivo.label --hemi lh --ctab entorhinal_perirhinal.annot.ctab --maxstatwinner --thresh 0.4 --a entorhinal_perirhinal_thresh_0.4 i.e. using --maxstatswinner and --thresh 0.4 which gives non-overlapping labels with shapes approximately similar to the original entorhinal_exvivo.thresh.label and perirhinal_exvivo.thresh.label, but it probably violates the condition of similar area extent. Could you please comment on if my used method is acceptable, or suggest better method how to achieve non-overlaping entorhinal and perirhinal labels for the purpose of generating custom aparc+aseg from them? Regards, Antonin Skoch Dear experts, Could you please provide me the information how exactly the *_exvivo.thresh.labels have been thresholded?According to this post, http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg32542.html .thresh labels are thresholded to pick the most likely vertices that give a label that is the right surface area.But how they are thresholded in the boundary of the region where the unthresholded labels do not overlap? There must be additional threshold applied: For example for BA45 there is no further BA label towards frontal pole, but the BA45_exvivo.thresh.label is also restricted in this region wrt BA45_exvivo.label. I have further question concerning used thresholding method of perirhinal_exvivo.thresh and entorhinal_exvivo.thresh labels. It seems that this method is not applied here since looking at them at the fsaverage surface, they are overlapping. And also *rhinal_exvivo.labels are much more extending to the adjacent regions than *rhinal_exvivo.thresh.labels. What method is applied here? My main objective to obtain annotation with the vertices properly assigned to perirhinal_exvivo and entorhinal_exvivo to supply this annotation to mri_aparc2aseg to assign ribbon voxels to that parcellation. I think I could use mris_label2annot --maxstatswinner with unthresholded entorhinal and perirhinal labels to assign vertices to most probable label, but I would need to further threshold the labels by correct value to obtain results similar in extent to thresh.labels. For perirhinal, it seems that the additional threshold is 0.4 (what is rationale for this value?), for entorhinal it seems also around 0.4 but could not find any particular threshold to obtain the exact shape of label corresponding to entorhinal_exvivo.thresh. Thank you in advance for clarification. Regards, Antonin Skoch

2 1

mri_vol2surf
by Redwan Maatoug 06 Mar '17

06 Mar '17

Hi all ! I would like to convert my files : volumetrics nifti files to surfaces files. My volumetrics nifti files come from an Atlas and I would like to convert them to surfaces files (i need the surfaces files). Could you please tell me the process because I have tried many things like : mri_vol2surf --src pathwaytomyfile --hemi lh --float2int round --out thepathwayIwantToputmySurfaceFileAfterConversion And it did not work. Thank you for your help, Redwan

3 4

preproc-sess - Cannot allocate memory
by Peled, Noam 06 Mar '17

06 Mar '17

Hey all, I'm running preproc-sess, and getting the following error: ... Reading in mov rest/tmp.bbregister.28405/template.nii Reading in ref .../mri/brainmask.mgz Reading in and applying refmask .../mri/aparc+aseg.mgz Cannot allocate memory I checked, and the aparc+aseg.mgz file is ok (I can read it with nibabel) I'm using the FreeSurfer dev version (freesurfer-Linux-centos6_x86_64-dev-20161215-dd925e2) on a 32GB CentOs7 machine, so I don't think I'm really out of memory. Thanks, Noam

2 1

Resting State group comparison procedure
by Bailin, Emma 06 Mar '17

06 Mar '17

Hello, I'm currently doing a resting state functional connectivity analysis. I have two groups and my ultimate goal is to compare the resting state network of group 1 to that of group 2. What is the standard procedure for comparing resting state connectivity across groups? I've followed the directions on the FsFast Functional Connectivity Walkthrough (http://surfer.nmr.mgh.harvard.edu/fswiki/FsFastFunctionalConnectivityWalkth…) and after the isxconcat-sess, I did mri_glmfit --y ces.nii.gz -wls pcc.nii.gz -surface fsaverage lh -glmdir [my/group1.directory.wls} -nii.gz, for each group. This got me the mean for both groups individually. I'm now stuck on how to proceed to compare across my groups. Using mri_glmfit creates the problem of trying to pre-process each group without a variable for -measure, and I'm not sure if using the -iv flag with the ces.nii.gz or pcc.nii.gz is going to give me what I need. Thank you. --Emma Bailin Emma Bailin Research Coordinator Laboratory for Visual Neuroplasticity Schepens Eye Research Institute Mass. Eye and Ear Infirmary Harvard Medical School Emma_Bailin(a)MEEI.harvard.edu<mailto:Emma_Bailin@MEEI.harvard.edu> (617)-573-3794 Mass. Eye and Ear Confidentiality Notice: This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual(s) addressed in the message above. This communication may contain sensitive or confidential information. If you are not an intended recipient, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you believe you have received this e-mail in error and the email contains patient information, please contact the Mass. Eye and Ear Compliance Line at 844-815-4401. If the e-mail was sent to you in error but does not contain patient information, please contact the sender and delete the e-mail.

2 1

transform a custom segmentation to native space
by Gabor Perlaki 06 Mar '17

06 Mar '17

Dear all, We've segmented some brain regions on orig.mgz using another program (this custom segmentation is called our_segmentation.mgz). Is it possible to transform this segmentation into the original native anatomical space using the following command? mri_label2vol --seg our_segmentation.mgz --temp rawavg.mgz --o our_segmentation-in-rawavg.mgz --regheader aseg.mgz Could somebody verify, that the above command is OK or not? Best, Gabor <petzinger.gabor(a)gmail.com>

2 1

Re: [Freesurfer] Creating custom aparc.a2009s+aseg.mgz: Shuffled names of parcellations after mris_label2annot
by Antonin Skoch 06 Mar '17

06 Mar '17

Dear Doug, I am using quite recent dev version built 8/2/2017. mris_label2annot of this version is following: $Id: mris_label2annot.c,v 1.20 2016/01/07 23:28:11 greve Regards, Antonin what version are you using? I thought I fixed the missing-last-label problem in v6 On 03/01/2017 06:42 PM, Antonin Skoch wrote: > Dear Doug, > > thank you, adding --no-unknown indeed fixed the global shuffling of > the label names. However, last line of .ctab seems not to be read this > time and produced .annot does not contain perirhinal label. > > My modified .ctab file looks like this: > > 0 Unknown 0 0 0 0 > 1 G&S_frontomargin 23 220 60 0 > 2 G&S_occipital_inf 23 60 180 0 > 3 G&S_paracentral 63 100 60 0 > 4 G&S_subcentral 63 20 220 0 > 5 G&S_transv_frontopol 13 0 250 0 > 6 G&S_cingul-Ant 26 60 0 0 > 7 G&S_cingul-Mid-Ant 26 60 75 0 > 8 G&S_cingul-Mid-Post 26 60 150 0 > 9 G_cingul-Post-dorsal 25 60 250 0 > 10 G_cingul-Post-ventral 60 25 25 0 > 11 G_cuneus 180 20 20 0 > 12 G_front_inf-Opercular 220 20 100 0 > 13 G_front_inf-Orbital 140 60 60 0 > 14 G_front_inf-Triangul 180 220 140 0 > 15 G_front_middle 140 100 180 0 > 16 G_front_sup 180 20 140 0 > 17 G_Ins_lg&S_cent_ins 23 10 10 0 > 18 G_insular_short 225 140 140 0 > 19 G_occipital_middle 180 60 180 0 > 20 G_occipital_sup 20 220 60 0 > 21 G_oc-temp_lat-fusifor 60 20 140 0 > 22 G_oc-temp_med-Lingual 220 180 140 0 > 23 G_oc-temp_med-Parahip 65 100 20 0 > 24 G_orbital 220 60 20 0 > 25 G_pariet_inf-Angular 20 60 220 0 > 26 G_pariet_inf-Supramar 100 100 60 0 > 27 G_parietal_sup 220 180 220 0 > 28 G_postcentral 20 180 140 0 > 29 G_precentral 60 140 180 0 > 30 G_precuneus 25 20 140 0 > 31 G_rectus 20 60 100 0 > 32 G_subcallosal 60 220 20 0 > 33 G_temp_sup-G_T_transv 60 60 220 0 > 34 G_temp_sup-Lateral 220 60 220 0 > 35 G_temp_sup-Plan_polar 65 220 60 0 > 36 G_temp_sup-Plan_tempo 25 140 20 0 > 37 G_temporal_inf 220 220 100 0 > 38 G_temporal_middle 180 60 60 0 > 39 Lat_Fis-ant-Horizont 61 20 220 0 > 40 Lat_Fis-ant-Vertical 61 20 60 0 > 41 Lat_Fis-post 61 60 100 0 > 42 Medial_wall 25 25 25 0 > 43 Pole_occipital 140 20 60 0 > 44 Pole_temporal 220 180 20 0 > 45 S_calcarine 63 180 180 0 > 46 S_central 221 20 10 0 > 47 S_cingul-Marginalis 221 20 100 0 > 48 S_circular_insula_ant 221 60 140 0 > 49 S_circular_insula_inf 221 20 220 0 > 50 S_circular_insula_sup 61 220 220 0 > 51 S_collat_transv_ant 100 200 200 0 > 52 S_collat_transv_post 10 200 200 0 > 53 S_front_inf 221 220 20 0 > 54 S_front_middle 141 20 100 0 > 55 S_front_sup 61 220 100 0 > 56 S_interm_prim-Jensen 141 60 20 0 > 57 S_intrapariet&P_trans 143 20 220 0 > 58 S_oc_middle&Lunatus 101 60 220 0 > 59 S_oc_sup&transversal 21 20 140 0 > 60 S_occipital_ant 61 20 180 0 > 61 S_oc-temp_lat 221 140 20 0 > 62 S_oc-temp_med&Lingual 141 100 220 0 > 63 S_orbital_lateral 221 100 20 0 > 64 S_orbital_med-olfact 181 200 20 0 > 65 S_orbital-H_Shaped 101 20 20 0 > 66 S_parieto_occipital 101 100 180 0 > 67 S_pericallosal 181 220 20 0 > 68 S_postcentral 21 140 200 0 > 69 S_precentral-inf-part 21 20 240 0 > 70 S_precentral-sup-part 21 20 200 0 > 71 S_suborbital 21 20 60 0 > 72 S_subparietal 101 60 60 0 > 73 S_temporal_inf 21 180 180 0 > 74 S_temporal_sup 223 220 60 0 > 75 S_temporal_transverse 221 60 60 0 > 76 entorhinal_exvivo.thresh 222 62 67 0 > 77 perirhninal_exvivo.thresh 223 65 60 0 > > with newline in the end. > > However, I was able to successfully generate annotation with 2 labels > ( previous swap of names in .annot produced using --l options was my > fault since I did not read the help to the detail to learn that the > order of label files of --l arguments has to match the order of names > in .ctab). So I could possibly achieve my goal by run mri_aparc2aseg > on this simple 2-label annot and somehow merge the result with the > default aparc.a2009s to bring the rhinal labels into that. Do you see > any pitfall with that? > > In any case, however, before running aparc2aseg I have to cope with > another problem with rhinal labels - the rhinal.thresh labels are > overlapping and I would need to correctly assign vertices in the label > intersection (see my previous post > http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg51919.html > ). > > Regards, > > Antonin > > > Try adding --no-unknown to the label2annot command line > On 02/28/2017 04:45 PM, Antonin Skoch wrote: > > Dear experts, > > > > I would like to create modified aparc.a2009s+aseg file with relevant > > parts of parahippocampal cortical ribbon voxel labels replaced by > > labels derived from surface labels of entorhinal and parahippocampal > > cortex (created also by default in recon-all). This modified > > aparc.a2009s+aseg file I want to use for streamline assignment in > > structural connectome generation in MrTrix3. > > > > I think that mri_label2vol is not optimal way to do it since it would > > leave some voxels in the ribbon unassigned. > > > > I think that the better, but much complicated, way to do this is to > > modify aparc.a2009s.annot with the information from these labels and > > then run again mris_aparc2aseg. > > > > I tried to do this by using: > > > > mri_annotation2label > > > > and > > > > mris_label2annot --hemi lh --subject my_subject --ldir my_labels --a > > my_aparc.a2009s --ctab my_aparc.annot.a2009s.ctab --debug > > > > I took the aparc.annot.a2009s.ctab from the my_subject/label > > directory and added to the end 2 row with entorrhinal and perirhinal > > parcellations with unique RGB values to assure the relevant parts of > > parahippocampal gyrus label are replaced by these new labels I want to > > supply. > > > > But the resulting new .annot file is not correct - the labels are in > > correct position on cortical surfaces, but the label names of all > > labels are shuffled. > > > > I even tried the sequence of mri_annotation2label, mris_label2annot > > without adding new labels, just converting annotation to labels and > > back, and the annotation naming is also corrupted. > > > > I also tried to create new annotation just from 2 new labels, > > preparing .ctab file and running mris_label2annot by explicitly > > specifying my 2 labels like > > > > mris_label2annot --hemi lh --subject my_subject --l > > lh_labels/lh.perirhinal_exvivo.thresh.label --l > > lh_labels/lh.entorhinal_exvivo.thresh.label --a rhinal_aparc.a2009s > > --debug --ctab rhinal_aparc.annot.a2009s.ctab > > > > In this case the label names in annotation are swapped (entorhinal is > > perirhinal and vice versa), swapped are also file names of labels > > which I tried to back convert by using mri_annotation2label. > > > > I am using quite recent build of dev version of Freesurfer from > > 28/2/2017. > > > > Could you suggest where could be the problem? > > > > Or could you advice different, possibly more simple way, how to > > achieve my goal? > > > > Thank you in advance. > > > > Regards, > > > > Antonin Skoch

2 1

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