Freesurfer

freesurfer@nmr.mgh.harvard.edu

30132 discussions

local gyrification index - contrast and doss vs. dods
by C.P.E. Rollins 26 Feb '18

26 Feb '18

Dear Freesurfer Developers, I'm following the very well-documented steps proposed by Marie Schaer for measuring local gyrification index in the paper "How to Measure Cortical Folding from MR Images: a Step-by-Step Tutorial to Compute Local Gyrification Index" (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3369773/) I have 2 questions I was wondering whether you might be able to answer: 1) Based on the contrast and FSDG files described in the paper (patients vs. controls, controlling for age and gender), would significant regions in blue refer to regions with reduced gyrification in patients relative to controls (patient LGI < control LGI) or vice versa? 2) When I try running the analysis in QDEC as opposed to command line with mri_glmfit, I get very different results - I think because QDEC is generating different contrast files than the one specified in the paper (1 1 -1 -1 0). Basically, this seems to be due to the difference in modelling LGI with doss (command line) or dods (default QDEC). I was wondering whether there were any reason doss was chosen for LGI instead of dods (see Step 5 in Section 4 Statistical Group Comparisons)? Thank you in advance for your help. Kindest regards, Colleen -- Colleen Rollins, PhD Candidate Department of Psychiatry University of Cambridge Herchel Smith Building, Robinson Way, Cambridge CB2 0SZ

2 1

Surface Errors
by Emily Schwartz 26 Feb '18

26 Feb '18

Hi FreeSurfer community, I am working on elderly subjects and have had this kind of surface error quite often in different locations. Usually, it's over about 3-4 slices (in one view) and can be fixed, but I am finding multiple in almost every subject and therefore taking a lot of time to edit (and then once reprocessed new ones sometimes come up in different locations). I was wondering if these are normal to have, minor surface errors that do not necessarily need to be fixed. I have added images of an example below. Here are some of the values I get from aparc.stats for caudal middle frontal lh after manually editing: Surface area: Original - 2500 mm^2 Edited - 2532 mm^2 Grey volume: Original - 1710 mm^3 Edited - 1727 mm^3 Thickness avg Original - 4455 mm std: 2.371 Edited - 4445 mm std: 2.365 Although the thickness values only differ by 10 mm, we are a little concerned because the difference is not within the standard deviation. Please let me know if all of these errors should be edited or if it may be okay to keep the smaller segmentation/topological errors as they are. Thank you, Emily

3 14

Re: [Freesurfer] MRI protocol for hippocampal subfield segmentation
by Gabor Perlaki 26 Feb '18

26 Feb '18

Does anybody else have a comment on the experienced artefact?

2 1

Re: [Freesurfer] MRI protocol for hippocampal subfield segmentation
by Gabor Perlaki 26 Feb '18

26 Feb '18

Does anybody else have a comment on the experienced artefact <petzinger.gabor(a)gmail.com>

1 0

Re: [Freesurfer] Hippocampal Subfield Error
by Iglesias Gonzalez, Eugenio 26 Feb '18

26 Feb '18

Dear Theo, Can you please provide us with the command you executed, and the complete output logs? Cheers, /Eugenio -- Juan Eugenio Iglesias ERC Senior Research Fellow Translational Imaging Group University College London http://www.jeiglesias.com http://cmictig.cs.ucl.ac.uk/ From: <freesurfer-bounces(a)nmr.mgh.harvard.edu> on behalf of "AKUDJEDU, THEOPHILUS" <T.AKUDJEDU1(a)nuigalway.ie> Reply-To: Freesurfer support list <freesurfer(a)nmr.mgh.harvard.edu> Date: Monday, 26 February 2018 at 12:39 To: "freesurfer(a)nmr.mgh.harvard.edu" <freesurfer(a)nmr.mgh.harvard.edu> Subject: [Freesurfer] Hippocampal Subfield Error Hi All, I tried to run a subject through FreeSurfer 6.0 for hippocampal Subfield segmentation but exited with errors. The content of the recon-all.error file is below. SUBJECT CHRM2001 DATE Sun Feb 25 00:34:13 GMT 2018 USER 15233963 HOST psych-sl03 PROCESSOR x86_64 OS Linux Linux psych-sl03 3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux $Id: recon-all,v 1.580.2.16 2017/01/18 14:11:24 zkaufman Exp $ /opt/ohpc/pub/apps/freesurfer/6.0.0/bin/recon-all PWD /home/15233963/freesurfer/SUBJECTS/CHRM2001/label CMD mris_anatomical_stats -th3 -mgz -f ../stats/rh.BA_exvivo.thresh.stats -b -a ./rh.BA_exvivo.thresh.annot -c ./BA_exvivo.thresh.ctab CHRM2001 rh white Will be glad if you can provide guidance. Cheers Theo _______________________________ Theophilus Akudjedu BSc, MSc, PhD Candidate Room 202 Comerford Suite, Clinical Science Institute, Department of Psychiatry, National University of Ireland, Galway Phone: +353 838329602 Email: t.akudjedu1(a)nuigalway.ie<mailto:t.akudjedu1@nuigalway.ie> rasningo(a)gmail.com<mailto:rasningo@gmail.com> [mage removed by sender.]

1 0

-make versus -all for edits
by Maksimovskiy, Arkadiy 26 Feb '18

26 Feb '18

Dear Experts, I was wondering if someone might be able to help me understand what the difference is between the two commands below. It seems that they can be used interchangeably, because I can forsee a situation in which one might not remember which command to run and also have done several types of corrections. Or would the former (-make) method only work on with 1 edits? Thanks, Arkadiy If you cannot remember which command to run, use the -make flag. Recon-all will automatically begin at whichever point in the processing stream you made your edits. recon-all -make all -subjid <subject> If you have corrected several types of errors, it is recommended that you re-run recon-all from the beginning, to ensure that none of your edits were left out. (Running from autorecon1 will not save you much time) recon-all -all -subjid <subject> -- Arkadiy L. Maksimovskiy, Ph.D. Postdoctoral Research Fellow McLean Imaging Center, McLean Hospital Department of Psychiatry, Harvard Medical School

2 1

Hippocampal Subfield Error
by AKUDJEDU, THEOPHILUS 26 Feb '18

26 Feb '18

Hi All, I tried to run a subject through FreeSurfer 6.0 for hippocampal Subfield segmentation but exited with errors. The content of the recon-all.error file is below. SUBJECT CHRM2001 DATE Sun Feb 25 00:34:13 GMT 2018 USER 15233963 HOST psych-sl03 PROCESSOR x86_64 OS Linux Linux psych-sl03 3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux $Id: recon-all,v 1.580.2.16 2017/01/18 14:11:24 zkaufman Exp $ /opt/ohpc/pub/apps/freesurfer/6.0.0/bin/recon-all PWD /home/15233963/freesurfer/SUBJECTS/CHRM2001/label CMD mris_anatomical_stats -th3 -mgz -f ../stats/rh.BA_exvivo.thresh.stats -b -a ./rh.BA_exvivo.thresh.annot -c ./BA_exvivo.thresh.ctab CHRM2001 rh white Will be glad if you can provide guidance. Cheers Theo _______________________________ Theophilus Akudjedu BSc, MSc, PhD Candidate Room 202 Comerford Suite, Clinical Science Institute, Department of Psychiatry, National University of Ireland, Galway Phone: +353 838329602 Email: t.akudjedu1(a)nuigalway.ie<mailto:t.akudjedu1@nuigalway.ie> rasningo(a)gmail.com<mailto:rasningo@gmail.com> [https://ci6.googleusercontent.com/proxy/b9-AoNc-V0v85TZ_pj6puJTgX7uWBNlZdoh…]

1 0

Re: [Freesurfer] TRACULA registration
by Gabriela Longo 23 Feb '18

23 Feb '18

Yes, got it. But in these text files, the first line is already "#!ascii label, vox2ras=scanner". It seems the problem is before the -stat step because I got many NaN. My impression is that the tracts inter-subjects are not well aligned. I also verified the registration, I will send the pictures: 1) dfifit_FA with MNI, that looks good: [image: Imagem inline 1] 2) merged_avg33_mni_bbr.mgz x dtifit_FA.nii.gz, that also looks good: [image: Imagem inline 2] 3) and then, when I checked the merged_avg33_mni_bbr.mgz with MNI, it looks incorrect: [image: Imagem inline 3] 2018-02-23 15:21 GMT-05:00 Gabriela Longo < gabrielalongo.radiologia(a)gmail.com>: > In these text files, the first line is already "#!ascii label, > vox2ras=scanner". > > It seems the problem is before the -stat step because I got many NaN. My > impression is that the tracts inter-subjects are not well aligned. > I also verified the registration, I will send the pictures: > > 1) dfifit_FA with MNI, that looks good: > [image: Imagem inline 1] > > 2) merged_avg33_mni_bbr.mgz x dtifit_FA.nii.gz, that also looks good: > [image: Imagem inline 2] > > 3) and then, when I checked the merged_avg33_mni_bbr.mgz with MNI, it > looks incorrect: > [image: Imagem inline 3] > > 2018-02-23 14:11 GMT-05:00 Yendiki, Anastasia <AYENDIKI(a)mgh.harvard.edu>: > >> So you may have been caught in that transition. The paths that you load >> into trackvis with the –w option are text files. Change the first line in >> those files to: >> #!ascii label, vox2ras=scanner >> >> When you do that and load the paths into freeview again, do they show up >> inside the brain? >> >> From: <freesurfer-bounces(a)nmr.mgh.harvard.edu> on behalf of Gabriela >> Longo <gabrielalongo.radiologia(a)gmail.com> >> Reply-To: Freesurfer support list <freesurfer(a)nmr.mgh.harvard.edu> >> Date: Friday, February 23, 2018 at 1:34 PM >> To: Freesurfer support list <freesurfer(a)nmr.mgh.harvard.edu> >> Subject: Re: [Freesurfer] TRACULA registration >> >> Hi Anastasia, >> >> thanks for your email. >> I did the whole analysis in the developmental version, even the -stat. >> >> Thanks, Gabriela >> >> 2018-02-23 13:21 GMT-05:00 Yendiki, Anastasia <AYENDIKI(a)mgh.harvard.edu>: >> >>> Hi Gabriela – Any chance that you generated the paths with an older >>> version of TRACULA, and viewed them in a newer version of freeview? There >>> was a change in freeview at some point, in terms of the header that it >>> expects those path files to have. This change happened between the 5.3 and >>> 6.0 freesurfer releases, so if you ran TRACULA from the 5.3 release and >>> used freeview from 6.0 or from a patched version that you downloaded in >>> between 5.3 and 6.0, they may be incompatible. This would explain the >>> outside the brain part. Now beyond that it seems that there's more >>> strangeness going on, but let’s figure that part out first. >>> >>> Thanks, >>> a.y >>> >>> From: <freesurfer-bounces(a)nmr.mgh.harvard.edu> on behalf of Gabriela >>> Longo <gabrielalongo.radiologia(a)gmail.com> >>> Reply-To: Freesurfer support list <freesurfer(a)nmr.mgh.harvard.edu> >>> Date: Friday, February 23, 2018 at 11:25 AM >>> To: "freesurfer(a)nmr.mgh.harvard.edu" <freesurfer(a)nmr.mgh.harvard.edu> >>> Subject: [Freesurfer] TRACULA registration >>> >>> Hi, >>> >>> I processed some subjects in TRACULA for a longitudinal evaluation. >>> I registered all of them in the MNI template (set doregmni = 1 >>> set mnitemp = $FSLDIR/data/standard/MNI152_T1_1mm_brain.nii.gz). >>> >>> I checked the registration of my dtifit_FA.bbr.nii.gz with the MNI of >>> all subjects. >>> However, when I performed the group analysis, I got more NaN than >>> expected and I checked the images and the results are outside the MNI >>> template (I am sending a picture). >>> >>> I went back and checked the registration of the paths. Despite the dtifit_FA.bbr.nii.gz >>> is correctly registered in the MNI, the paths aren't. >>> >>> I am struggling here to find solutions. I really appreciate any insight >>> to help me to solve this issue. >>> >>> Thanks in advance, >>> >>> Gabriela Longo >>> >>> [image: Imagem inline 2] >>> >>> >>> _______________________________________________ >>> 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. >>> >>> >> >> _______________________________________________ >> 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

FreeSurfer Labels To Diffusion Toolkit/TrackVis
by Katherine Damme 22 Feb '18

22 Feb '18

Hello Everyone, I would like to use the FreeSurfer labels for fMRI and DTI in graph theory analyses. I am attempting to use UMPC <https://github.com/jbrown81/umcp> to generate the graphs, which requires that the diffusion tensor imaging be in .dtk form. However, I have been struggling to get the FreeSurfer labels into the .dtk space. While I have found this <https://surfer.nmr.mgh.harvard.edu/fswiki/FreeSurferTrackVisTransforms>website suggesting a method for moving from the dtk space to FreeSurfer, it doesn't appear to be a reversible process. Leading me to ask: 1. Is there a way to generate graphs from TRACULA? or 2. How can I transform the labels or dlabels into dtk space? Thank you for any help on this topic! Kate Damme

2 1

Update: asymmetric parcellation error
by Dijkshoorn, A.B.C. (Aicha) 22 Feb '18

22 Feb '18

Dear Freesurfer developers, When I was troubleshooting my data I came across an odd parcellation error that I can not place. When looking at the reconstructed surface parcellation (freeview -f {$subject}/surf/lh.pial:annot=aparc.annot:name=pial_aparc:visible=0 \ --viewport 3d) I noticed that in a large proportion of my subjects the parcellated errors are not placed correctly. Moreover, the error mostly seems to apply to the right cortex and not the left. I adjusted foto's for visual information. I already checked the brain mask.mgz file and the rh.white and rh.pial surfaces I cannot find any segmentation errors either. Do you have any idea what could have gone wrong and how I can correct for this? Kind regards, Aicha

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