Freesurfer October 2017

freesurfer@nmr.mgh.harvard.edu

119 participants
179 discussions

Start a nNew thread

Re: [Freesurfer] Recon-all for Allen Brain Institute T1 image
by Melanie Ganz 19 Oct '17

19 Oct '17

3 2

Re: [Freesurfer] Recon-all for Allen Brain Institute T1 image
by Seán Froudist Walsh 19 Oct '17

19 Oct '17

Hi, Was the following issue ever solved?

3 3

Re: [Freesurfer] Registering T-maps to the inflated surface
by Nicholas Blauch 19 Oct '17

19 Oct '17

Hi Bruce, That worked great. Thanks. And for others reading, you might want to specify --surf pial in the call to mri_vol2surf, if your activations are expected in cortex. When I did it with no --surf specified, a face-selective localizer yielded weird results on the ventral surface. Specifying pial fixed it in this case. Maybe the average of white and pial would be optimal, or a weighted average if one is interested in different cortical layers? There is no mid-cortical surface by default, right? best, Nick > Message: 4 > Date: Wed, 18 Oct 2017 19:58:26 -0400 (EDT) > From: Bruce Fischl <fischl(a)nmr.mgh.harvard.edu> > Subject: Re: [Freesurfer] Registering T-maps to the inflated surface > To: Freesurfer support list <freesurfer(a)nmr.mgh.harvard.edu> > Message-ID: > <alpine.LRH.2.20.1710181957170.4903(a)gate.nmr.mgh.harvard.edu> > Content-Type: text/plain; charset="utf-8" > > Hi Nick > > you only need to register once to all the surfaces. If you use spmregister > to create a register.dat, you can then use mri_vol2surf with it and your T > map t create a surface-based T map, which you should then be able to load > as an overlay on top of any surface for that subject and hemi (e.g. > lh.white, lh.inflated, lh.pial, lh.smoothwm, etc....) > > cheers > Bruce > > > On Wed, 18 Oct 2017, Nicholas Blauch wrote: > > > Hello to the folks at Freesurfer, > > > > I'm just getting started with your tools and am finding them very > useful. Thanks for the great > > work.? > > > > I am trying to register my functional images to freesurfer surfaces in > order to overlay SPM T maps. > > I have pre-processed and co-registered my functional images to the brain > volume using SPM, where I > > also ran functional analyses. I followed the instructions on the web for > using spmregister. Doing > > so?produces a register.dat file that seems to work well for overlaying > my T maps onto the white, > > orig, and pial surfaces, but not the inflated surfaces. When attempting > to?register to the inflated > > surface using tkregister, I get the error "ERROR: vertex 0 > (14.6911,-132.739,-34.1424) is out of > > range (113,162,-5)". When I attempt to overlay onto the inflated surface > in freeview,?the locations > > are not remotely correct (usually invisible, within the inflated > surface). > > > > I think that freesurfer is basically doing a volumetric registration > which is why it has trouble > > with the inflated surface, which is mostly outside of the brain. Whereas > I think the desired method > > would be to?co-register a given functional/statistical volume to the > freesurfer orig volume, and > > then take advantage of links between orig and all surfaces created from > it.? > > > > Does anybody know of a way to achieve this linking between an arbitrary > volume and all surfaces? Or > > of another workaround?to plot SPM T-maps on the subject's inflated > surface?? > > > > Thanks for any help. > > > > cheers > > Nick > > > > -- > > Nicholas Blauch, B.S. > > Lab Manager? > > Computational Memory and Perception Laboratory > > Department of Psychological and Brain Sciences > > University of Massachusetts, Amherst > > > >

2 1

Question about mg and mgx
by Shane Schofield 19 Oct '17

19 Oct '17

Hi Freesurfer, I have two question about the different partial volume correction options. Basically how is the --mg method different from the --mgx? I cannot seem to find papers that have compared these methods. Any opinions on this? Does this have any effect on the region of interest GTM results? Cheers and have a great day,Shane

1 0

readVolGeom corner case leads to lta_convert failures
by Christopher Markiewicz 18 Oct '17

18 Oct '17

Hi all, We've run into an issue where lta_convert is failing if the filename line in a volume geometry is of a specific length. We've identified the source of the problem, and made a pull request on GitHub that at least partially fixes the issue (https://github.com/freesurfer/freesurfer/pull/180) Doug's requested that all bugs be posted to the mailing list, so I excerpt the pull request below. ----- It is currently possible to create a valid VolGeom string that will break readVolGeom, by setting the length of the line beginning "filename = " to be 255 characters (+ `'\n'`). The filename is defined to be a 1024 byte string, and so up to 1023 characters: https://github.com/freesurfer/freesurfer/blob/9b79bf0eef76710a70a5b73142a8f… So, in writeVolGeom, a line may be written that is up to 1035 characters long (`"filename = "` + 1023 + `'\n'`): https://github.com/freesurfer/freesurfer/blob/9b79bf0eef76710a70a5b73142a8f… If the line is exactly 255 characters long (excluding newline), then the `fgets` call will retrieve the entire contents of the line (256 characters - terminating `'\NUL'`) without retrieving a newline. The next call to `fgets` will then get a line of length 0, resulting in a premature termination of the loop. To observe an effect of this issue, consider the following LTA file: type = 0 # LINEAR_VOX_TO_VOX nxforms = 1 mean = 0.0000 0.0000 0.0000 sigma = 1.0000 1 4 4 2.327464342117310e+00 4.245608299970627e-02 3.455499932169914e-02 -1.319661331176758e+01 -7.824462652206421e-02 3.904805898666382e+00 2.233271896839142e-01 -5.291442871093750e-01 -4.939173907041550e-02 -1.728723645210266e-01 4.818737983703613e+00 7.657078552246094e+01 0.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 1.000000000000000e+00 src volume info valid = 1 # volume info valid filename = /scratch/03763/oesteban/fmriprep-phase1/work/ds000110/fmriprep_wf/single_subject_07_wf/func_preproc_task_IncidentalencodingtaskusingPosnercueingparadigmwithobjectvgreeblejudgment_run_05_wf/bold_reg_wf/bbreg_wf/bbregister/ants_susceptibility_War volume = 64 64 30 voxelsize = 3.437500000000000e+00 3.437500000000000e+00 4.000000000000000e+00 xras = 1.000000000000000e+00 0.000000000000000e+00 0.000000000000000e+00 yras = 0.000000000000000e+00 9.979115724563599e-01 -6.459446996450424e-02 zras = 0.000000000000000e+00 6.459447741508484e-02 9.979115724563599e-01 cras = 3.437500000000000e+00 8.357086181640625e-01 4.582891845703125e+01 dst volume info valid = 1 # volume info valid filename = /scratch/03763/oesteban/fmriprep-phase1/work/ds000110/fmriprep_wf/single_subject_07_wf/anat_preproc_wf/t1_merge/sub-07_T1w_ras_template.nii.gz volume = 124 256 256 voxelsize = 1.500000000000000e+00 8.593999743461609e-01 8.593999743461609e-01 xras = 9.998608827590942e-01 1.065783575177193e-02 -1.283265277743340e-02 yras = -9.511843323707581e-03 9.962262511253357e-01 8.627174794673920e-02 zras = 1.370369549840689e-02 -8.613768219947815e-02 9.961889982223511e-01 cras = -3.533935546875000e-01 5.862289428710938e+00 -1.128549194335938e+01 subject sub-07 fscale 0.100000 If you save this as `test.lta`, the following command fails in an unexpected way: $ lta_convert --inlta truncated.lta --outlta out.lta $Id: lta_convert.cpp,v 1.9.2.1 2016/08/09 02:33:22 zkaufman Exp $ --inlta: truncated.lta input LTA transform. --outlta: out.lta output LTA. LTAchangeType: dst geometry must be valid The offending line is: filename = /scratch/03763/oesteban/fmriprep-phase1/work/ds000110/fmriprep_wf/single_subject_07_wf/func_preproc_task_IncidentalencodingtaskusingPosnercueingparadigmwithobjectvgreeblejudgment_run_05_wf/bold_reg_wf/bbreg_wf/bbregister/ants_susceptibility_War Add or remove a character and the command proceeds without error. However, supposing you add a character (and, critically, convert between `RAS_TO_RAS` and `VOX_TO_VOX`): $ lta_convert --inlta extended.lta --outlta out1.lta $Id: lta_convert.cpp,v 1.9.2.1 2016/08/09 02:33:22 zkaufman Exp $ --inlta: extended.lta input LTA transform. --outlta: out1.lta output LTA. LTA read, type : 1 1.01550 0.01035 0.02607 -3.12509; -0.00760 0.97176 -0.10423 6.51772; -0.02702 0.10772 1.03053 -46.97261; 0.00000 0.00000 0.00000 1.00000; Writing LTA to file out1.lta... lta_convert successful. $ lta_convert --inlta out1.lta --outlta out2.lta --ltavox2vox $Id: lta_convert.cpp,v 1.9.2.1 2016/08/09 02:33:22 zkaufman Exp $ --inlta: out1.lta input LTA transform. --outlta: out2.lta output LTA. --ltavox2vox: output LTA as VOX_TO_VOX transform. LTA read, type : 1 1.01550 0.01035 0.02607 -3.12509; -0.00760 0.97176 -0.10423 6.51772; -0.02702 0.10772 1.03053 -46.97261; 0.00000 0.00000 0.00000 1.00000; LTAchangeType: dst geometry must be valid This is a result of the truncation that occurs during the read. Thanks for your time, -- Chris Markiewicz Center for Reproducible Neuroscience Stanford University

1 0

Registering T-maps to the inflated surface
by Nicholas Blauch 18 Oct '17

18 Oct '17

Hello to the folks at Freesurfer, I'm just getting started with your tools and am finding them very useful. Thanks for the great work. I am trying to register my functional images to freesurfer surfaces in order to overlay SPM T maps. I have pre-processed and co-registered my functional images to the brain volume using SPM, where I also ran functional analyses. I followed the instructions on the web for using spmregister. Doing so produces a register.dat file that seems to work well for overlaying my T maps onto the white, orig, and pial surfaces, but not the inflated surfaces. When attempting to register to the inflated surface using tkregister, I get the error "ERROR: vertex 0 (14.6911,-132.739,-34.1424) is out of range (113,162,-5)". When I attempt to overlay onto the inflated surface in freeview, the locations are not remotely correct (usually invisible, within the inflated surface). I think that freesurfer is basically doing a volumetric registration which is why it has trouble with the inflated surface, which is mostly outside of the brain. Whereas I think the desired method would be to co-register a given functional/statistical volume to the freesurfer orig volume, and then take advantage of links between orig and all surfaces created from it. Does anybody know of a way to achieve this linking between an arbitrary volume and all surfaces? Or of another workaround to plot SPM T-maps on the subject's inflated surface? Thanks for any help. cheers Nick -- Nicholas Blauch, B.S. Lab Manager Computational Memory and Perception Laboratory Department of Psychological and Brain Sciences University of Massachusetts, Amherst

2 1

FW: seeking MR physicist (fwd)
by Bruce Fischl 18 Oct '17

18 Oct '17

FYI ---------- Forwarded message ---------- Date: Wed, 18 Oct 2017 16:11:10 +0000 From: Elfar Adalsteinsson <elfar(a)mit.edu> To: mrigroup <mrigroup(a)mit.edu>, ptx <ptx(a)mit.edu>, fetal <fetal(a)mit.edu> Cc: "fischl(a)nmr.mgh.harvard.edu" <fischl(a)nmr.mgh.harvard.edu> Subject: FW: seeking MR physicist Hi All, West coast colleagues and friends are looking to fill a postdoc slot …if you are interested you can talk to me for info or reach out to Natalie May Zahr [mailto:nzahr@stanford.edu] Research Scientist Department of Psychiatry and Behavioral Sciences Stanford University School of Medicine Stanford, CA 94305

1 0

Re: [Freesurfer] TRACULA qc: forceps minor and major
by Yendiki, Anastasia 18 Oct '17

18 Oct '17

Hi Linnea Marie – You’re right in your assessment. Are you using 6.0? You can reinitialize those bad cases, by adding “set reinit = 1” in your config file and changing the path list and subject list to specify only the tract and subjects that you want. Then rerun trac-all --prior and trac-all —path for those cases. Best, a.y From: <freesurfer-bounces(a)nmr.mgh.harvard.edu<mailto:freesurfer-bounces@nmr.mgh.harvard.edu>> on behalf of Linnea Marie Dramdal Borg <lmborg(a)stud.ntnu.no<mailto:lmborg@stud.ntnu.no>> Reply-To: Freesurfer support list <freesurfer(a)nmr.mgh.harvard.edu<mailto:freesurfer@nmr.mgh.harvard.edu>> Date: Friday, October 6, 2017 at 6:13 AM To: "freesurfer(a)nmr.mgh.harvard.edu<mailto:freesurfer@nmr.mgh.harvard.edu>" <freesurfer(a)nmr.mgh.harvard.edu<mailto:freesurfer@nmr.mgh.harvard.edu>> Subject: [Freesurfer] TRACULA qc: forceps minor and major Hi, We have run into some issues with our forceps major and forceps minor tractographies. I have attached examples: In "fminor_bro_139.png", there is a "bridge" in forceps minor in the space between the hemispheres. We've also come across other cases of bridging in forceps minor, with somewhat unusual voxel intensity distribution, such as in "fminor_onestripe_otherwOK.png" and" fminor_litenbro_OKornot_210.png". Also, "fmajor_132_toolateral.png", fmajor brances out in the left hemisphere (right in the picture). All of these cases seem pretty bad to us. Do you agree? In contrast, "fminor_allslicesOKbutone_158.png" looks fine, but there is one slice where it branches out to some extent. Are we correct in assuming this won't affect the results too much, or is there something we can/should do about this? Thank you, Linnea Marie

2 2

FLAIR pial segmentation imprecisions
by Patrícia Klobušiaková 18 Oct '17

18 Oct '17

Dear Freesurfer experts, we used recon-all -s <subid> -i <T1> -FLAIR <FLAIR> -FLAIRpial -all on cca 100 subjects. About 10 of them have this pial surface error (see below). Pial surface on temporal lobes is erroneous. White matter seems pretty much OK to me. Would for example changing of -ghi parameter in mri_segment expert option help? What would be the best way to handle this? Thanks! Patricia [image: Vnorený obrázok 1]

1 0

Re: [Freesurfer] TRACULA bedpostx step with gpu
by Mehta, Chintan 18 Oct '17

18 Oct '17

Thank you Anastasia!

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
18
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 October 2017