Freesurfer

freesurfer@nmr.mgh.harvard.edu

30132 discussions

Brain Twitter Conference 2019 #brainTC
by Kivisaari Sasa 17 Jan '19

17 Jan '19

External Email - Use Caution Dear colleagues, The 3rd Annual Brain Twitter Conference 2019 (#brainTC) will take place on March 14th, 2019 and the abstract submission is now open! This year the keynote tweeters include Russ Poldrack (@russpoldrack‏) and Jay van Bavel (@jayvanbavel)! For more information about the conference and how to submit an abstract, please visit our website https://brain.tc and follow @RealBrainTC. What is Twitter Conference? A Twitter conference is meant for scientists to present and discuss their research on social media. During the conference presenters will be allocated a 15 min time slot, during which they will present a series of 6 tweets or less, marked with the #brainTC tag and an ordinal number of the tweet. A Twitter conference allows for scientific discussions without the hassle of travel; it’s therefore a carbon-neutral, time-efficient and family-friendly way to share you work and to network. In the last two years #brainTC has a reached an average of ~ 0.5 million Twitter users! On behalf of the organizing committee, best wishes, Sasa Kivisaari Post-doctoral Scientist Aalto University Finland

1 0

unsubscribe
by 230159460＠seu.edu.cn 16 Jan '19

16 Jan '19

External Email - Use Caution Dear Sir， I am wonder how to unsubscribe the mails like ， my mailbox is almost full and i can not recieve mails from my workmates Shaoxun Yuan, PhD Candidate State Key Laboratory of Bioelectronics School of Biological Science and Medical Engineering Southeast University, Nanjing, 210018, China Phone:(86)18761869223

1 0

Longitudinal Hippocampal Subfields - error during segmentation
by Rachel Phillips 16 Jan '19

16 Jan '19

External Email - Use Caution Hello, I have run a longitudinal sample (up to 4 timepoints per subject) through the Freesurfer 6.0 longitudinal processing pipeline, and currently I am attempting to produce the longitudinal hippocampal subfield segmentation with the following command: longHippoSubfieldsT1.sh <baseID> [SubjectsDirectory]. I am receiving the following error: "Error using SegmentSubfeldsT1Longitudinal (line 441) The vector of prior probabilities in the mesh nodes must always sum to one over all classes". Below is an example of the output that precedes this error: [> In SegmentSubfieldsT1Longitudinal at 418] Reading contexts of file /usr/local/packages/freesurfer_v6.0.0/average/HippoSF/atlas/compressionLookupTable.txt -------------- Making Lateral-nucleus map to reduced label 1 Making Paralaminar-nucleus map to reduced label 1 Making Basal-nucleus map to reduced label 1 Making Accessory-Basal-nucleus map to reduced label 1 Making Corticoamygdaloid-transitio map to reduced label 1 Making Central-nucleus map to reduced label 1 Making Cortical-nucleus map to reduced label 1 Making Medial-nucleus map to reduced label 1 Making Anterior-amygdaloid-area-AAA map to reduced label 1 -------------- Making alveus map to reduced label 2 Making Hippocampal_tail map to reduced label 2 Making HATA map to reduced label 2 Making fimbria map to reduced label 2 Making parasubiculum map to reduced label 2 Making hippocampal-fissure map to reduced label 2 -------------- Making Left-Cerebral-Cortex map to reduced label 3 -------------- Making Left-Cerebral-White-Matter map to reduced label 4 -------------- Making Left-Lateral-Ventricle map to reduced label 5 -------------- Making Left-choroid-plexus map to reduced label 6 -------------- Making Unknown map to reduced label 7 -------------- Making Left-VentralDC map to reduced label 8 -------------- Making Left-Putamen map to reduced label 9 -------------- Making Left-Pallidum map to reduced label 10 -------------- Making Left-Thalamus-Proper map to reduced label 11 -------------- Making Left-Accumbens-area map to reduced label 12 -------------- Making Left-Caudate map to reduced label 13 Error using SegmentSubfieldsT1Longitudinal (line 441) The vector of prior probabilities in the mesh nodes must always sum to one over all classes Any guidance on this error would be greatly appreciated. Thanks, Rachel

3 5

Re: [Freesurfer] preproc-sess mask issue
by Dowling, Kevin Francis 16 Jan '19

16 Jan '19

Hi Doug, Thanks so much for your note, that makes complete sense! To confirm, if I just delete the session/bold/masks and session/bold/RRR/masks and re-ran my preproc-sess command (-update) in v 6.0 new masks would be generated but my registration, stc, motion correction, (normalization?), would remain in 5.3. Is there any chance that version 6.0 might view the absence of register.dof6.lta files for my subjects (generated as register.dof6.dat files in 5.3) as cause for re-running the registration step and generating/using the register.dof6.lta files for use downstream of this step? Thank you again for your help! Best wishes, Kevin Date: Tue, 15 Jan 2019 21:47:37 +0000 From: "Greve, Douglas N.,Ph.D." <DGREVE(a)mgh.harvard.edu> Subject: Re: [Freesurfer] preproc-sess mask issue To: "freesurfer(a)nmr.mgh.harvard.edu" <freesurfer(a)nmr.mgh.harvard.edu> Message-ID: <5b4ea669-5ade-6be4-2435-aed05faf1454(a)mgh.harvard.edu> Content-Type: text/plain; charset="Windows-1252" Yea, the 5.3 stream used FSL brain masking to make the masks for the fmri. Version 6 uses the FS brain mask transferred into fmri space. Inevitably, you will have to do a lot of reprocessing. The simplest thing to do is to delete the mask files in session/bold/masks and sessoin/bold/RRR/masks (where RRR is the run number). When you re-run preproc-sess, it will figure out what needs to be re-run. It should not rerun motion correction, slice timing correction, or registration ________________________________ ________________________________ On 1/15/19 1:26 PM, Dowling, Kevin Francis wrote: > > Hello FreeSurfer Experts, > > > I'm writing to follow-up on my question about incomplete lhrh cortical > and mni305 subcortical masks in preproc-sess. My initial email is > copied below, but briefly when running WLS functional analyses via > mri_glmfit in FS 5.3, I noticed a number of large regions that were > pruned out?in my subcortical and cortical analyses. I traced these > pruning problems back to subjects' whose raw and fmcpr.siemens.nii.gz > data are fine for all functional runs, but for whom some pre-processed > runs had brain.mni305.nii.gz, brain.fsaverage.rh.nii.gz, and > brain.fsaverage.lh.nii.gz masks that were missing voxels/vertices (0 > values rather than 1s) that cause the pruning problem later on in > mri_glmfit.I tried pre-processing a number of these problematic > subjects in FS 6 and noticed that these missing voxels/vertices were > all fixed. However, as our analysis has ~200 subjects and is > multi-modal in nature, I would like to avoid re-doing all of our > analyses in FS 6.0 unless absolutely necessary. > > > Since the fmcpr.siemens.nii.gz functional data looks fine to me for > the problematic subject runs (as do the brain.nii.gz and > brain.e3.nii.gz masks), I thought something might possibly be amiss > with the registration in the mni305 mask generation command (below). > Specifically,when I look at the output of this command for the > problematic runs relative to the good runs, the mask > brain.mni305.2mm.nii.gz looks like it has been rotated away from the > normal orientation (see attached image, rotated_mask_questionable.png). > > > mri_vol2vol --mov > /autofs/cluster/roffman/users/Stable5_PerRun/GDDA161_Testing/bold/masks/brain.nii.gz > --reg > /autofs/cluster/roffman/users/Stable5_PerRun/GDDA161_Testing/bold/022/register.dof6.dat > --tal --talres 2 --talxfm talairach.xfm --nearest --no-save-reg --o > /autofs/cluster/roffman/users/Stable5_PerRun/GDDA161_Testing/bold/022/masks/brain.mni305.2mm.nii.gz > > > When I look at the analogous surface command (below), there are > similar problems, that result in a mask missing 50% of its vertices: > > > mri_vol2surf --mov > /autofs/cluster/roffman/users/Stable5_PerRun/GDDA161_Testing/bold/masks/brain.nii.gz > --reg > /autofs/cluster/roffman/users/Stable5_PerRun/GDDA161_Testing/bold/022/register.dof6.dat > --trgsubject fsaverage --interp nearest --projfrac 0.5 --hemi rh --o > /autofs/cluster/roffman/users/Stable5_PerRun/GDDA161_Testing/bold/022/masks/brain.fsaverage.rh.nii.gz > --noreshape --cortex --surfreg sphere.reg > > > Looking at the structural functional alignment for this subject with > tkregister-sess -s GDDA161_Testing -per-run -fsd bold, the > registration (from register.dof6.dat) seems fine (mincost .57 for this > problem run, but looks good visually).?Since the use of the > register.dof6.dat file is common to these two processes, and since FS > 6.0 uses register.dof6.lta rather than the .dat file, my? inclination > was to suspect there was a registration issue except that, again, > visualizing register.dof6.dat via tkregister-sess is fine. > > > Forgive this somewhat naive question, but beyond checking the input > (which seems fine) and output (which is bad) of this command along > with the subject's structural/functional registration, is there > anything else I could do to further troubleshoot this issue? Is there > a different registration file I should be looking at, or alternatively > am I looking too far downstream in the preproc-sess pipeline? I would > be most grateful for any additional troubleshooting ideas. > > > I have attached a .txt file containing the debug output for the > described subject, whom is an extreme example of the pruning/masking > issue. The problem run is 022. > > > Thank you again for any thoughts or suggestions you might have! > > > Best wishes, > > Kevin > > > *Kevin F. Dowling * > Clinical Research Coordinator > Brain Genomics Laboratory > Division of Psychiatric Neuroimaging > Martinos Center for Biomedical Imaging > Massachusetts General Hospital > 149 13th Street > Charlestown, MA, 02129 > (p) 617.643.3215 > He / Him / His > > > ------------------------------------------------------------------------ > *From:* Dowling, Kevin Francis > *Sent:* Tuesday, January 8, 2019 2:40 PM > *To:* freesurfer(a)nmr.mgh.harvard.edu > *Subject:* preproc-sess mask issue > > Hello FreeSurfer Experts, > > > I'm writing with a question about a potential problems that has come > up in my functional analysis. I'm running FS version 5.3 on a Linux > (at the Martinos Center - CentOS release 7.6.1810). > > > I was recently running osgm WLS analyses with mri_glmfit and the > --prune flag when I noticed that a large number of vertices in my > surface based analysis were pruned out due to no signal (about 40% of > the entire surface, see attached an example image of a group analysis > that includes one of the bad subjects: pruning_issue.png). My first > thought was that this result was potentially due to a poor > functional/structural alignment for some subjects. However, I > re-checked my functional and structural alignments, along with the > quality of the recons, and they all look good. Upon further > inspection, I observed similar erroneous pruning problems affecting > voxels in the mni305 space (for an example see pruning_issue2.png). > This issue stems from a modest number of subjects that have first > level analyses with large amounts of no signal. Indeed, removing these > problematic subjects from group surface based analyses resolves most > of the excessive surface pruning problems. > > > When I look at the fmcpr.siemens.nii.gz files for the runs in the > problematic subjects' directories the processed functional data looks > good, but when I visualize the fmcpr.siemens.sm5.mni305.nii.gz (and > ...fsaverage.lh.nii.gz / ...fsaverage.rh.nii.gz) files it is clear > that an inappropriate number of voxels (/vertices) have been masked > out. When I look at the brain.mni305.nii.gz, > brain.fsaverage.rh.nii.gz, and brain.fsaverage.lh.nii.gz masks I can > see they are missing a large number of voxels/vertices that should be > in the masks, which leads me to think that something may be going > wrong in the lh/rh/mni305 masking/mask generation step (though > brain.nii.gz and brain.e3.nii.gz masks look fine to me). I've looked > through the archives and wasn't able find a similar issue discussed > previously. > > > I was therefore wondering what might be causing this mask issue (given > the alignments appear to be good) and what might be the best way to go > about correcting this error. Would I need to manually edit all of > these masks to include the missing voxels/vertices if the automatic > generation failed or is there a better solution someone might be able > to suggest? > > > My preprocessing command is: preproc-sess -s SubjectID01 -surface > fsaverage lhrh -mni305 -d $SUBJECTS_DIR -fsd bold -stc siemens -fwhm 5 > -per-run > > > I would be happy to send along mask files/other files should they be > of help. > > > Thank you in advance for any suggestions you might be able to provide! > > Best wishes, > Kevin > > > *Kevin F. Dowling * > Clinical Research Coordinator > Brain Genomics Laboratory > Division of Psychiatric Neuroimaging > Martinos Center for Biomedical Imaging > Massachusetts General Hospital > 149 13th Street > Charlestown, MA, 02129 > (p) 617.643.3215 > He / Him / His

2 1

Large cluster size significant clusters
by Azeez, Azeezat 16 Jan '19

16 Jan '19

External Email - Use Caution Hello , I have results for my mri_glmfit-sim. I find a significant results in my cache.th20abs.sig.cluster.summary. Yet, the cluster size of the significant cluster is almost the size of the total cortical surface area. I am not sure what to make of this any help would be helpful. # Total Cortical Surface Area 65416.6 (mm^2) # ClusterNo Max VtxMax Size(mm^2) MNIX MNIY MNIZ CWP CWPLow CWPHi NVtxs Annot 1 -44.154 9733 55204.38 -4.9 -47.1 29.6 0.00020 0.00000 0.00040 108257 isthmuscingulate -- Azeezat Azeez

2 3

using tkregister2 to check registration to custom atlas
by lindsay hanford 16 Jan '19

16 Jan '19

External Email - Use Caution Hello Freesurfer Community, I am interested in seeing how well my subject scan registered to a custom atlas after being run through recon-all. From Freesurfer Wiki, although it is possible to see this in freeview, tkregister2 seems to be the best method as manual edits can be made if the registration went badly. I am however running into issues trying to load the subject image, atlas image, and surfaces in the same space. If I understand correctly, when I ran my recon-all specifying a custom atlas (-custom-tal-atlas RLB700_atlas_as_orig) the transform files (talairach.xfm) are to the custom atlas rather than the talairach atlas. If I load: tkregister2 --s 180523_HTP02168_ANAT5_init2base --fstal --surfs the subject scan, talairach atlas and surfaces load just fine. It is clear the talairach atlas was not used. I have tried running multiple variations of the following, and in all cases, the atlas is in a different space. tkregister2 --mov RLB700.nii.gz --s 180523_HTP02168_ANAT5_init2base --regheader --reg 180523_HTP02168_ANAT5_init2base/mri/transforms/talairach.xfm --surfs Resources used: https://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/Talairach_freeview https://surfer.nmr.mgh.harvard.edu/fswiki/MulitModalIntegration Any suggestions? Thanks, Lindsay

2 3

mni --> RAS T1
by Krieger, Donald N. 16 Jan '19

16 Jan '19

External Email - Use Caution Is there a 4x4 transformation somewhere to convert mni coordinates to RAS T1 coordinates, I.e. something comparable to the transforms provided by mri_info -tkrscanner Thanks - Don

2 1

Re: [Freesurfer] Running TRACULA
by Yendiki, Anastasia 16 Jan '19

16 Jan '19

Have you checked the registration between the structural and diffusion? The concern here would be that some of your subjects' brains could look more like bert's brain than others, and the registration could be better for the former than the latter. You would have to ensure that this doesn't introduce biases between groups (or age/gender biases) in your specific study, and therefore does not induce false group differences or accentuate any real differences. On Jan 11, 2019 9:35 AM, Ainara Gomez <ainara.ggastiasoro(a)deusto.es> wrote: External Email - Use Caution Hi Anastasia, thank you for your rapid response. Since I do not have the T1 of my subjects, I have not run the recon-all. Instead of that, I have copy-pasted the "mri" folder (including the aparc+aseg.mgz file) located in $FREESURFER_HOME/freesurfer/subjects/bert/mri into each subject's folder ($SUBJECTS_DIR/$subjectid/) so TRACULA can find all the files from Freesurfer that are needed in trac-all prep step. Thanks a lot again, Ainara El vie., 11 ene. 2019 a las 14:49, Yendiki, Anastasia (<AYENDIKI(a)mgh.harvard.edu<mailto:AYENDIKI@mgh.harvard.edu>>) escribió: Hi Ainara - What do you mean by default freesurfer files? Can you describe how you created each subject's recon-all style directory under SUBJECTS_DIR? TRACULA looks for $SUBJECTS_DIR/$subjectid/mri/aparc+aseg.mgz for each subject ID. a.y On Jan 11, 2019 8:30 AM, Ainara Gomez <ainara.ggastiasoro(a)deusto.es<mailto:ainara.ggastiasoro@deusto.es>> wrote: External Email - Use Caution Dear Freesurfer experts, I am trying to run TRACULA as a complementary analysis on a patients and healthy controls sample. I have read in the tutorial that it is assumed that FreeSurfer has already been run on all the subjects' T1-weighted data because TRACULA will use the aparc+aseg.mgz from each subject's FreeSurfer reconstruction. However, T1s of my subjects are not available for this study and I only have the diffusion images. I have run the three steps of the trac-all separately (using the default freesurfer files: aseg+aparc.mgz...) and all the processes have ended without errors. Is this correct? Is it possible to use the default freesurfer files instead of each subject's recon-all files in order to run trac-all? Thank you very much in advance, Ainara -- Ainara Gómez Gastiasoro Dpt of Methods and Experimental Psychology Neuropsychology of Severe Medical Conditions research team Faculty of Psychology and Education University of Deusto neurolab.deusto.es<http://neurolab.deusto.es/> https://twitter.com/deustoneurolab Avda. de las Universidades 24, 48007, Bilbao (Spain) Phone: +34 944139000 (ext. 3268) <tel:%2B34%20944139000> _______________________________________________ Freesurfer mailing list Freesurfer(a)nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer -- Ainara Gómez Gastiasoro Dpt of Methods and Experimental Psychology Neuropsychology of Severe Medical Conditions research team Faculty of Psychology and Education University of Deusto neurolab.deusto.es<http://neurolab.deusto.es/> https://twitter.com/deustoneurolab Avda. de las Universidades 24, 48007, Bilbao (Spain) Phone: +34 944139000 (ext. 3268) <tel:%2B34%20944139000>

2 1

preproc-sess mask issue
by Dowling, Kevin Francis 15 Jan '19

15 Jan '19

Hello FreeSurfer Experts, I'm writing with a question about a potential problems that has come up in my functional analysis. I'm running FS version 5.3 on a Linux (at the Martinos Center - CentOS release 7.6.1810). I was recently running osgm WLS analyses with mri_glmfit and the --prune flag when I noticed that a large number of vertices in my surface based analysis were pruned out due to no signal (about 40% of the entire surface, see attached an example image of a group analysis that includes one of the bad subjects: pruning_issue.png). My first thought was that this result was potentially due to a poor functional/structural alignment for some subjects. However, I re-checked my functional and structural alignments, along with the quality of the recons, and they all look good. Upon further inspection, I observed similar erroneous pruning problems affecting voxels in the mni305 space (for an example see pruning_issue2.png). This issue stems from a modest number of subjects that have first level analyses with large amounts of no signal. Indeed, removing these problematic subjects from group surface based analyses resolves most of the excessive surface pruning problems. When I look at the fmcpr.siemens.nii.gz files for the runs in the problematic subjects' directories the processed functional data looks good, but when I visualize the fmcpr.siemens.sm5.mni305.nii.gz (and ...fsaverage.lh.nii.gz / ...fsaverage.rh.nii.gz) files it is clear that an inappropriate number of voxels (/vertices) have been masked out. When I look at the brain.mni305.nii.gz, brain.fsaverage.rh.nii.gz, and brain.fsaverage.lh.nii.gz masks I can see they are missing a large number of voxels/vertices that should be in the masks, which leads me to think that something may be going wrong in the lh/rh/mni305 masking/mask generation step (though brain.nii.gz and brain.e3.nii.gz masks look fine to me). I've looked through the archives and wasn't able find a similar issue discussed previously. I was therefore wondering what might be causing this mask issue (given the alignments appear to be good) and what might be the best way to go about correcting this error. Would I need to manually edit all of these masks to include the missing voxels/vertices if the automatic generation failed or is there a better solution someone might be able to suggest? My preprocessing command is: preproc-sess -s SubjectID01 -surface fsaverage lhrh -mni305 -d $SUBJECTS_DIR -fsd bold -stc siemens -fwhm 5 -per-run I would be happy to send along mask files/other files should they be of help. Thank you in advance for any suggestions you might be able to provide! Best wishes, Kevin Kevin F. Dowling Clinical Research Coordinator Brain Genomics Laboratory Division of Psychiatric Neuroimaging Martinos Center for Biomedical Imaging Massachusetts General Hospital 149 13th Street Charlestown, MA, 02129 (p) 617.643.3215 He / Him / His

2 2

QDEC - command not found
by Alba Castells Sánchez 15 Jan '19

15 Jan '19

External Email - Use Caution Dear freesurfer experts, we installed the last version of freesurfer dev in a centos7 system (8th january 2019) and the matlab runtime to run segmentHA_T1.sh. We could obtain all the files without problems. However, today we tried to open qdec typing qdec like we used to do with other versions without problem and the answer is "command not found". We are really surprised, we haven't found any other comment on internet and the mailing list with this same problem. We have installed the same last version in a mac and we had the same problem. qdec doesn't exist. We have checked the files .sh in Freesurfersetup and similar files in the freesurfer direcotry looking for qdec without success. HOwever, there is a direcotry called Qdec in freesurfer/matlab/lme We don't know where is our mistake. We are also considering that maybe the issue is related with the version. Is this possible? Could you help us, please? Thousand thanks

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