Freesurfer June 2012

freesurfer@nmr.mgh.harvard.edu

124 participants
195 discussions

Problem with mri_glmfit ill-conditioned matrix
by Carl Anderson 26 Jun '12

26 Jun '12

Dear Freesurfer, We have a recurrent problem with an ill-conditioned matrix. Could someone shed some light on our problem. Here is the command line: mri_glmfit --y lh.ELS-CON.thickness.10.mgh --fsgd CAT-SP_June26.FSGF dods --C ELSvsCON_COV-Gen-Age-ICV.mtx --surf fsaverage lh --cortex --glmdir ELS_CON_June26_contrast_one Below is the Design matrix and attached is the fsgd Thanks very much, Creating output directory ELS_CON_June26_contrast_one Loading y from /Applications/freesurfer/subjects/SP-CAT_data/lh.ELS-CON.thickness.10.mgh INFO: gd2mtx_method is dods Saving design matrix to ELS_CON_June26_contrast_one/Xg.dat Normalized matrix condition is 44113.9 Design matrix ------------------ 0.000 0.000 0.000 1.000 0.000 0.000 0.000 29.600 0.000 0.000 0.000 1302835.625; 0.000 1.000 0.000 0.000 0.000 30.000 0.000 0.000 0.000 1785397.750 0.000 0.000; 0.000 0.000 0.000 1.000 0.000 0.000 0.000 29.930 0.000 0.000 0.000 1350884.250; 0.000 0.000 0.000 1.000 0.000 0.000 0.000 29.610 0.000 0.000 0.000 1492907.500; 0.000 0.000 0.000 1.000 0.000 0.000 0.000 29.380 0.000 0.000 0.000 1479810.250; 0.000 1.000 0.000 0.000 0.000 30.220 0.000 0.000 0.000 1408085.125 0.000 0.000; 0.000 0.000 0.000 1.000 0.000 0.000 0.000 30.470 0.000 0.000 0.000 1257495.875; 0.000 0.000 0.000 1.000 0.000 0.000 0.000 30.810 0.000 0.000 0.000 1221350.500; 0.000 0.000 0.000 1.000 0.000 0.000 0.000 29.740 0.000 0.000 0.000 1325784.500; 0.000 0.000 0.000 1.000 0.000 0.000 0.000 29.770 0.000 0.000 0.000 1428926.125; 0.000 0.000 0.000 1.000 0.000 0.000 0.000 30.310 0.000 0.000 0.000 1099130.750; 0.000 1.000 0.000 0.000 0.000 29.000 0.000 0.000 0.000 1766575.750 0.000 0.000; 0.000 0.000 0.000 1.000 0.000 0.000 0.000 29.050 0.000 0.000 0.000 1311269.250; 0.000 1.000 0.000 0.000 0.000 29.550 0.000 0.000 0.000 1749889.250 0.000 0.000; 0.000 0.000 1.000 0.000 0.000 0.000 22.440 0.000 0.000 0.000 1617660.625 0.000; 0.000 0.000 1.000 0.000 0.000 0.000 25.560 0.000 0.000 0.000 1749327.375 0.000; 0.000 0.000 1.000 0.000 0.000 0.000 22.190 0.000 0.000 0.000 1532579.000 0.000; 1.000 0.000 0.000 0.000 25.530 0.000 0.000 0.000 2144050.750 0.000 0.000 0.000; 0.000 0.000 1.000 0.000 0.000 0.000 25.950 0.000 0.000 0.000 1664001.125 0.000; 0.000 0.000 1.000 0.000 0.000 0.000 22.790 0.000 0.000 0.000 1544209.625 0.000; 1.000 0.000 0.000 0.000 25.800 0.000 0.000 0.000 1718912.750 0.000 0.000 0.000; 0.000 0.000 1.000 0.000 0.000 0.000 23.810 0.000 0.000 0.000 1624601.625 0.000; 0.000 0.000 1.000 0.000 0.000 0.000 22.800 0.000 0.000 0.000 1706050.125 0.000; 1.000 0.000 0.000 0.000 21.250 0.000 0.000 0.000 1508681.750 0.000 0.000 0.000; 0.000 0.000 1.000 0.000 0.000 0.000 25.720 0.000 0.000 0.000 1526436.125 0.000; 1.000 0.000 0.000 0.000 25.600 0.000 0.000 0.000 1558595.125 0.000 0.000 0.000; 0.000 0.000 1.000 0.000 0.000 0.000 23.950 0.000 0.000 0.000 1523555.500 0.000; 0.000 0.000 1.000 0.000 0.000 0.000 22.280 0.000 0.000 0.000 1436572.375 0.000; 0.000 0.000 1.000 0.000 0.000 0.000 24.840 0.000 0.000 0.000 1391633.500 0.000; 0.000 0.000 1.000 0.000 0.000 0.000 23.790 0.000 0.000 0.000 1484742.375 0.000; 0.000 0.000 1.000 0.000 0.000 0.000 23.770 0.000 0.000 0.000 1523672.500 0.000; 0.000 0.000 1.000 0.000 0.000 0.000 24.130 0.000 0.000 0.000 1616389.875 0.000; 0.000 0.000 1.000 0.000 0.000 0.000 25.790 0.000 0.000 0.000 1620330.625 0.000; 1.000 0.000 0.000 0.000 23.830 0.000 0.000 0.000 1785148.125 0.000 0.000 0.000; 1.000 0.000 0.000 0.000 23.790 0.000 0.000 0.000 1685555.500 0.000 0.000 0.000; 1.000 0.000 0.000 0.000 24.960 0.000 0.000 0.000 1791343.625 0.000 0.000 0.000; -------------------------------- ERROR: matrix is ill-conditioned or badly scaled, condno = 44113.9 -------------------------------- Possible problem with experimental design: Check for duplicate entries and/or lack of range of continuous variables within a class. If you seek help with this problem, make sure to send: 1. Your command line: mri_glmfit --y lh.ELS-CON.thickness.10.mgh --fsgd CAT-SP_June26.FSGF dods --C ELSvsCON_COV-Gen-Age-ICV.mtx --surf fsaverage lh --cortex --glmdir ELS_CON_June26_contrast_one 2. The FSGD file (if using one) 3. And the design matrix above -- <<•>>~<>~<<•>>~<>~<<•>>~<>~<<•>>~<>~<<•>>~<>~<<•>>~<>~<<•>>~<>~<<•>> Carl M. Anderson, Ph.D. (mail stop 204) Assistant Professor of Psychiatry, Harvard Medical School & The Neuroimaging Center, McLean Hospital 115 Mill St. Belmont, MA 02478 Ph: 617-855-2972; Fax: 617-855-2770 e-mail: remfract(a)gmail.com; carl_anderson(a)hms.harvard.edu <<•>>~<>~<<•>>~<>~<<•>>~<>~<<•>>~<>~<<•>>~<>~<<•>>~<>~<<•>>~<>~<<•>>

1 0

Re: [Freesurfer] pars triangular and BA44 segmentation bug?
by Gabor Perlaki 26 Jun '12

26 Jun '12

Dear Bruce, In the paper "Left-right asymmetry in volume and number of neurons in adult Broca's area." by Katrin Amunts, 10 subjects (5 men and 5 women) were studied, and the volume of BA44 was greater in the left hemisphere than in the right in all ten cases. So, it is very strange that the volume of BA44 was greater in the right hemisphere in all of the 80 subjects analyzed by Eniko. Thanks, Gabor

3 6

trac-all: error during trac-paths due to tract missing
by Torben Prokscha 26 Jun '12

26 Jun '12

Dear all, while running trac-all, I got the following error: ERROR: Could not open /Users/torben/Desktop/tracon/fs_diff/s001/dlabel/diff/lh.cst_AS_avg33_mni_flt_cpts_5.txt Obviously, a similar problem was discussed before (here: https://mail.nmr.mgh.harvard.edu/pipermail//freesurfer/2011-August/019570.h…) However, no general solution was publicly mailed. Since it was requested then, I attach the trac-all.log file. Thanks in advance for any help! Best Torben Prokscha

3 3

skull strip (ss) and pial/wm/orig surf
by Kushal Kapse 26 Jun '12

26 Jun '12

hi FS users; have two questions which i am having issue across ss and pial/wm/orig surf boundaries 1- it has happened that sometimes the sagittal view of individual was flipped from left to right. but the pial/wm boundaries look good. was wondering why this happened only for countable ppl? i tried to look up in forum for anyone with similar issue but no clue yet...has anyone come across this issue and if yes, how to flip back the orientation in sagittal view 2- how much ss issue should be considered. ss issue= skull pieces left behind, or large GM cut. the reason i m asking is because sometimes there would be a huge piece of skull remaining but that individual would have perfect visual alignment of boundaries and nice inflated surface. sometimes they have mediocre skull remaining or GM cut, and that would make pial/wm boundaries go wrong and inflation is with holes and droplets. my question is how much of skull stripping errors( pieces of skull remaining, gm/wm removed beyond limit or orientation flipped) matters to segmentation, inflation and further analysis. any help would be appreciated thanks kk

1 0

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

← Newer
1
2
3
4
5
6
7
8
...
20
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 June 2012