Freesurfer

freesurfer@nmr.mgh.harvard.edu

30132 discussions

Re: [Freesurfer] qdec_glmfit problem
by Douglas N Greve 26 Jun '12

26 Jun '12

You have to make it manually. See the tutorial for an example. doug On 06/26/2012 01:01 PM, Nicolai Grüner-Hegge wrote: > Hi Doug, > > Thank you for the link. I was able to get up to pre-smoothing my > fsaverage surfaces but do not know how to continue to the > qdec.table.dat section. Is this a text file I must make manually or is > there a code which can put the data of the subjects into this table > format (Was the recon-all -s <subjid> -qcache code meant to do this?)? > Thank you for your time! > > Best Regards, > Nicolai > > On Wed, Jun 20, 2012 at 4:20 PM, Douglas N Greve > <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>> wrote: > > Hi Nicolai, have you looked at the qdec tutorial on our wiki page? > It has an example on how to create the table > > http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/QdecGroupAnalysis > > doug > > On 06/20/2012 03:49 PM, Nicolai Grüner-Hegge wrote: > > Dear FreeSurfer, > > > > I am emailing you to ask for your help with the qdec_glmfit > command (I > > got the command from the following link: > > http://www.freesurfer.net/fswiki/qdec_glmfit) > > > > My issue is that I do not know how to turn my raw data into the .dat > > file required by the command (you used qdec.table.dat as an > example). > > Could you please tell me how I can turn my raw data into the > .dat file > > that is required for the qdec_glmfit command to work? Thank you for > > your time! > > > > Best Regards, > > Nicolai > > _______________________________________________ > > Freesurfer mailing list > > Freesurfer(a)nmr.mgh.harvard.edu > <mailto:Freesurfer@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 <mailto:greve@nmr.mgh.harvard.edu> > Phone Number: 617-724-2358 <tel:617-724-2358> > Fax: 617-726-7422 <tel:617-726-7422> > > Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting > <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> > FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html > <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> > > _______________________________________________ > Freesurfer mailing list > Freesurfer(a)nmr.mgh.harvard.edu <mailto:Freesurfer@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

mri_vol2surf and Spherical Surfaces
by Luis R. Piloto 26 Jun '12

26 Jun '12

Hello Fellow Freesurfers, I need some verification that my method for mapping functional data onto a spherical surface is sound. What I'm currently doing is running recon-all on my high-resolution, structural volume (.nii.gz format). After that, I take a single timepoint of my functional data (that has been both registered and upsampled to the high-res structural space), and run it through mri_vol2surf with the following command: mri_vol2surf --mov highres_functional_slice00.niii.gz --hemi lh --regheader my_subject_name --out_type paint -o ./my_output_surface.w What I'm most worried about is whether this method of registration (i.e. specifying --regheader) is sufficient to go from the upsampled/registered functional to the surface? Also is there some more efficient way of doing this? I feel like there might be a smarter way to go from the functional to the structural without having to explicitly register and upsample before using mri_vol2surf. After this step, I simply pass my_output_surface.w to a program that reads the corresponding vertex and functional activity at that location and look up the vertex coordinates in my lh.sphere file. Any feedback would be really appreciated as I'm still really new to this software suite and was given a highly specific task to take care of. Thanks in advance! Regards, Luis Piloto

2 1

mri_segstats: reported volume depends on voxels size
by Masaya Misaki 26 Jun '12

26 Jun '12

Hello all, I found volume size reported by mri_segstats is changed very much depending on voxel size when partial volume correction (--pv option) is used. The difference was much larger than that can be explained by the difference of image resolution. (mri_segstats version is 1.75.22 2011/4/27 in FreeSurfer v5.1.0) When I performed segmentation for high-resolution image (voxel size = 0.5 mm^3), I found all volumes of segmented regions in aseg.stats was too small; about 8 times smaller than that was estimated from 1mm^3 conformed image. So I tested the effect of voxel size on mri_segstats. At first, recon-all was run with conforming 1mm^3 voxel (default option). Then aseg.mgz and norm.mgz were conformed to small voxel size, and mri_segstats was applied to the conformed files: mri_convert aseg.mgz aseg_cs05.mgz -cs 0.5 rt nearest mri_convert norm.mgz norm_cs05.mgz -cs 0.5 mri_segstats --seg aseg_cs05.mgz --pv norm_cs05.mgz \ --ctab $FREESURFER_HOME/FreeSurferColorLUT.txt \ --nonempty --excludeid 0 --sum aseg_cs05.stats (these are just for testing the effect of voxel size, not for actual analysis) All volumes reported in aseg_cs05.stats (for 0.5mm^3 voxel) was about 8 times smaller than aseg.stats (for 1mm^3 voxel). So the reported volume was scaled with the same ratio as the voxel size. Same effect was observed when voxel size was conformed to larger one (e.g. 1.5mm^3); reported volumes were about 3 times larger than those for 1mm^3-voxel. The number of voxels in the segmented regions (Nvoxels column in aseg.stats) were similar across different voxel sizes while voxel sizes are different. When --pv option was not used, the reported volumes were almost the same across different voxel sizes. So the partial volume correction in mri_segstats seems to depend on voxel size. Can I fix this with some missed options or shouldn't I use --pv option for the image with voxel size other than 1mm^3? thanks, -- Masaya Misaki Ph.D.

1 0

Improving bad pial surfaces from low gray/csf CNR volumes
by Winter, Warren 25 Jun '12

25 Jun '12

Hi there, We have a set of about 80 MPRAGEs whose acquisition parameters (chosen by and used at another lab with whom we collaborated) must have compromised their quality, as FreeSurfer has been consistently generating, in most of our subjects, a pial surface that excludes a lot of lateral cortex throughout the brain. The intensity values of true GM typically run from 40-80. The white matter surfaces are generally fine, though the intensity values drop off to the low 90s in the outer regions of WM strands. The skull strips are fine. We've had some success in using control points to push the pial surface out appropriately, but only after adding roughly between 300 and 1300 CPs per subject -- and even then it has not always fully ameliorated the problem. Snapshots of a typical brain from this dataset: http://imgur.com/905Rm , http://imgur.com/5zVLQ , http://imgur.com/Abz2C . If it would help, I could upload a full subject to the file drop. I ran mri_cnr on a bunch of our norm.mgz volumes from this data set and the gray/csf CNR is typically in the 0.55-0.80 range, whereas the gray/white CNR is around 1.7-2.0. To compare, bert's norm.mgz gray/csf CNR is ~1.05 CNR, gray/white CNR ~1.85. Here are the parameters that were used: TR = 1910 msec, TE = 3 msec, flip angle = 8 degrees. They are transverse T1-weighted MPRAGE images. Mri_probedicom output says that the transmitting coil was a body coil, which came as a surprise to us and is hopefully not true. In any event, these scans were of a pediatric population studied under special historical circumstances and so it is imperative that we salvage as much reliable data from the scans as possible. I have tried a few other tweaks to recon-all in an attempt to automate some of the correction: (1) running as many as 8 iterations of nu_correct (default = 2) (2) running mri_normalize with b = 20 (from the wiki, this argues "use control point with intensity b below target (default=10.0)") and n = 5 (argues "use n 3d normalization iterations (default=2)") both separately and together (3) generating a bias field volume from 18 brains that had been successfully corrected with many control points (using mri_compute_bias), applying the bias volume to the orig.mgz (using mri_apply_bias) of other brains with the same issue, and then feeding this orig.mgz into recon-all with motion correction skipped and the first talaraich transform cleaned. None of these adjustments has resulted in improvement comparable to massive control point placement. Is there anything else you could recommend? I've found in the archives some people reporting improvement for similar problems after using many more iterations of nu_correct than I tried, and I'm wondering if our images would benefit from more smoothing than is default (and if so, at which step -- as an argument in mri_compute_bias? As an expert option for mris_smooth?). Bruce also suggested in one case of low gray/csf contrast ( https://mail.nmr.mgh.harvard.edu/pipermail//freesurfer/2009-August/011572.h… ) to manually correct an image and then use certain switches that will take the intensity distribution parameters from there rather than from the atlas. Many thanks for your attention and help! Warren -- Warren Winter Research Coordinator Boston Children's Hospital Sheridan Laboratory of Cognitive Neuroscience Division of Developmental Medicine 1 Autumn Street, AU 650 Boston, MA 02215 857-218-5224

2 1

Re: [Freesurfer] mris_label2annot mislabeling
by Douglas Greve 25 Jun '12

25 Jun '12

Weren't you concerned that the names in the annotation were incorrect? You get to pick the names and the colors to be whatever you want to be. By default, it uses FreeSurferColorLUT.txt. doug On 6/23/12 9:54 PM, Arno Klein wrote: > > dear doug, > > thank you for your response. for the custom color table, what do i > assign for the different anatomical names and color values? why > wouldn't the names and colors in FreeSurferColorLUT.txt work? > > cheers, > @rno > > > > Re: [Freesurfer] mris_label2annot mislabeling > > Douglas N Greve > Wed, 20 Jun 2012 08:58:50 -0700 > > Arno, you need to create a custom color table (--ctab). > doug > > On 06/20/2012 12:05 AM, Arno Klein wrote: > > > > hello! > > > > i have saved a couple of .label files and am trying to convert them to > > a .annot file with: > > > > mris_label2annot --h lh --s MMRR-21-1 > > --l lh.superiorfrontal.label > > --l lh.superiorparietal.label > > --ctab FreeSurferColorLUT.txt --a output > > > > the stdout is: > > > > ColorTable atlas_colortable.txt > > AnnotName output > > nlables 2 > > LabelThresh 0 0.000000 > > Loading /usr/local/freesurfer/subjects/MMRR-21-1/surf/lh.orig > > 1 11829830 Left-Cerebral-Exterior > > 2 16119285 Left-Cerebral-White-Matter > > Mapping unhit to unknown > > ... > > > > clearly the anatomical names assigned are incorrect, and when i view > > the output with tksurfer, the labeled patches are in the right places > > but are assigned these same incorrect anatomical names. > > > > i have tried renaming the .label files to no avail. what am i doing > > wrong? > > > > cheers, > > @rno >

3 3

OpenMP parallelization
by Akio Yamamoto 25 Jun '12

25 Jun '12

FreeSurfer experts, I need to make the process of each one brain 10-20 times faster somehow - one way should be parallelization approach. Currently I'm trying to add OpenMP parallelization to time-consuming part of the source code, especially mri_ca_register and mri_em_register. Not completed yet, but at this point of time, I can not see the speed-up in proportion to the number of CPU cores; it's just x2.5 speed-up using 8 or 16 cores. I'm afraid there might be fundamental limitations in algorithm and/or implementation of the code. Should I proceed with this work? Any advice, help or comment would be appreciated. Akio

3 2

freesurfer labels to binary masks for use as targets in fsl probtrackx
by Ludersdorfer, Philipp 25 Jun '12

25 Jun '12

Dear Freesurfers, I want to run FSL probtrackx and use Freesurfer labels (aparc + asec) as seed and targets. I followed the instructions from here http://www.fmrib.ox.ac.uk/fsl/fdt/fdt_surface.html to define the seed and the transformation. However, I have problems defining Freesurfer labels as targets. These targets should be binary volume masks and they should be in the same space as the seed (hence, in the freesurfer conformed structural space). Now, I am not sure how to transform the labels into such binary masks. As I see it, one option would be to take the aparc+aseg.mgz image and use mri_binarize to create such binary masks (one by one), e.g., mri_binarize --i aparc+aseg.mgz --o left_fusiform.nii.gz --match 1007 I am not confident that this is the correct way. In the Freesurfer mailing list, I read something that using mri_annotation2label and afterwards mri_label2vol is a better way. However, in that specific case from the mailing list the person also wanted the masks to be in native structural space something I dont need to have. So basically, my question is whether the mri_binarize option is correct. Thanks a lot in advance (I know that there are several related threads in the mailing list archive but nothing really answered my question). Philipp --- Philipp Ludersdorfer Department of Psychology and Center for Neurocognitive Research University of Salzburg Hellbrunner Strasse 34 5020 Salzburg

1 0

Question Regarding Contents of FreeSurfer
by Alexander Thomas 23 Jun '12

23 Jun '12

Dear FreeSurfer, I am looking for a database of brain areas and their associated functions. Is it the content of the FreeSurfer software? For example, if I point to a certain brain area (e.g. Broca's area), will FreeSurfer tell me its associated function (e.g. speech production)? Thank you

2 1

how to save edited lh.white using matlab
by Leon 22 Jun '12

22 Jun '12

Hi, FreeSurfer Experts I checked the archive but did not find what I want: I removed part of the lh.white and lh.pial and want to save the edited lh.white and lh.pial in matlab. However, I could not find the corresponding matlab function for read_surf to write the edited surface? Could someone tell how I can save edited ?h.white and pial surfaces using matlab functions? Many thanks Leon

2 1

FW: Segmentation stats unevenly allocating volumes to Unkown, Insula, and the Corpus Callosum in our data set
by ntandon＠bidmc.harvard.edu 22 Jun '12

22 Jun '12

We're having a problem where some of our subjects show insula volumes in the aparc.stats file, but others do not show insula but show unknown and corpus callosum volumes in the file. All subjects were run in Freesurfer 5.1. We did some testing on our dataset and found that in cases where the insula was missing and unknown was present, the unknown is much larger. We also understand that the unknown volume is more than just the insula, so a simple substitution is not possible. We want to know a few things: 1) In cases where Freesurfer cannot allocate to the insula, is that volume automatically added to the 'unknown' volume? 1) If there's a way to somehow force volumes to go to these labels consistently throughout our data set (i.e. to each of insula, CC and unknown rather than only to some of them.) 2) If that' s not possible (i.e. if there's no way to maintain consistency in output) then will measures from the other regions (everything besides insula, CC or unknown) will be affected by the difference? Thanks, Neeraj

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