Freesurfer

freesurfer@nmr.mgh.harvard.edu

5 participants
30076 discussions

Re: Freesurfer Digest, Vol 47, Issue 2
by Simon Rushton 02 Jan '08

02 Jan '08

I feel somewhat uneasy simply assuming that the process worked just because it didn't exit with an error. Is my concern misplaced? Should I feel happy about submitting a ms based on freesurfer analyses that have not been independently checked? If it is necessary/advisable to do some independent checking, are there a couple of simple things (later reconstructions) that can be checked that indicate whether all is fine, or whether it is necessary to go back and check systematically each of the various stages documented on the wiki pages? simon > Date: Wed, 2 Jan 2008 07:17:13 -0500 (EST) > From: Bruce Fischl <fischl(a)nmr.mgh.harvard.edu> > Subject: Re: [Freesurfer] checking problems > To: Feng-Xian Yan <b9403208(a)stmail.cgu.edu.tw> > Cc: freesurfer <freesurfer(a)nmr.mgh.harvard.edu> > Message-ID: > <Pine.LNX.4.62.0801020716430.5653(a)gate.nmr.mgh.harvard.edu> > Content-Type: text/plain; charset="big5" > > Hi, > > we don't usually stop and check anymore as things fail pretty > rarely. You > can look at the tutorial on the wiki for examples of the types of > failures > and how to fix them. > > cheers, > Bruce > > On > Wed, 2 Jan 2008, Feng-Xian Yan wrote: > >> Hi, >> I have some confusion. When I completely run the command, recon-all >> ¡Vs x249 ¡Vautorecon1, and I should stop to check for problems with >> intensity normalization, talairach transformation and skull >> stripping. >> How can I do to check these problems? And, which is I must do first? >> >> Thanks. >> >> _______________________________________________ >> Freesurfer mailing list >> Freesurfer(a)nmr.mgh.harvard.edu >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >>

3 4

checking problems
by Feng-Xian Yan 02 Jan '08

02 Jan '08

Hi, I have some confusion. When I completely run the command, recon-all –s x249 –autorecon1, and I should stop to check for problems with intensity normalization, talairach transformation and skull stripping. How can I do to check these problems? And, which is I must do first? Thanks.

3 2

How to generate inflated.H file?
by Jiefeng Jiang 01 Jan '08

01 Jan '08

Hi, Happy New Year everybody! I met a problem when I tried to make a template using "mris_make_template", it needs ?h.inflated.H file. However, I only have ?h.inflated file. Does anyone know how to generate ?h.inflated.H file? Thank you in advance! Jiefeng Jiang Medical image computing National lab of pattern recognition Institute of automation, CAS Beijing, China +86 10 62659278

2 1

Status of the Source ?
by Ivan Blagoev Topolsky 30 Dec '07

30 Dec '07

Hello, I wanted to ask about what's hapenning with the source code, will it be release anytime soon ? The webpages say that it will be available any moment now, but in fact the message has remained such for quite some time : my last question about it on this list was back in summer 2006. Did some unexpected problem arise ? Or will actually the source code be available soon ? Also, another question : Are there developers trying to use GPGPU techniques to accelerate the processing speed ? (using nvidia's CUDA, ATI's Brook or similar technologies ?) Thank you for your help. - Ivan -

1 0

mri_convert --out_orientation with inhomogeneous volumes
by Ray Fix 23 Dec '07

23 Dec '07

Dear FS Listers, mri_convert isn't giving me quite what I expected when I use it to reorient an inhomogeneous volume. I apologize in advance if it is my misunderstanding or something that has been covered before. These orientation issues make my head spin (as they do the subject data ;-). Consider the following example: > % mri_info volume.mgz > : > dimensions: 256 x 256 x 128 > voxel sizes: 1.0000, 1.0000, 1.3300 > : > Orientation : PIL > Primary Slice Direction: sagittal > : > I take this volume and reorient it with mri_convert to LIA orientation. > % mri_convert --out_orientation LIA volume.mgz volume_LIA.mgz But what it gives me back is unexpected. > % mri_info volume_LIA.mgh > : > dimensions: 256 x 256 x 128 > voxel sizes: 1.0000, 1.0000, 1.3300 > : > Orientation : LIA > Primary Slice Direction: coronal I was first surprised first that mri_convert was resorting to trilinear interpolation. It seems like this kind of transformation could be done with 100% fidelity using nearest neighbor. But the bigger concern is I would have also expected the output dimensions to be 128x256x256 with the voxel sizes 1.33, 1.00, 1.00. It seems like if you reorient a non cubic volume with mri_convert, it arbitrarily cuts some of the data out from the posterior and anterior. tkmedit display seems to confirm this. To put it another way, I would expect: > mri_convert --out_orientation PIL volume_LIA.mgz volume_PIL.mgz to generate at volume_PIL.mgz file that was voxel identical to the original volume.mgz. Thanks for your time. Ray

2 2

where is the patient information in the mgz files
by Wang, Xin 23 Dec '07

23 Dec '07

Hello, Group, I have a problem to read patient information in the .mgz files. this information was stored in the header files of dicom files. Could sb. tell me how to read this information from the .mgz files? Thank you in advance, Xin Wang

3 2

Aseg stats and white surfaces
by Michael Harms 22 Dec '07

22 Dec '07

Hello, In FS v4.0.1 the Aseg Stats stage now occurs toward the end of the recon-all script, and is designed to use the "--surf-wm-vol" flag if both the lh.white and rh.white surfaces exist. Just wanted to point out that if any subsequent edits are made resulting in changes to either lh.white or rh.white (e.g. as a consequence of making edits and then running either -autorecon2-cp, -autorecon2-wm, or -autorecon2-pial), the values for "cerebral-white-matter" volume contained in aseg.stats will no longer reflect the true volume for the current ?h.white surfaces, since Aseg Stats is not automatically rerun as part of those flags. Perhaps "set DoSegStats = 1" should be included as part of any flag that results in new ?h.white surfaces? cheers, Mike H . -- Michael Harms, Ph.D. -------------------------------------------------------------------- Conte Center for the Neuroscience of Mental Disorders Washington University School of Medicine Department of Psychiatry, Box 8134 Renard Hospital, Room 6615 Tel: 314-747-6173 660 South Euclid Ave. Fax: 314-747-2182 St. Louis, MO 63110 Email: mharms(a)wustl.edu --------------------------------------------------------------------

1 0

anatomical stats in stable-pub-v3.0.5
by Paul Greenberg 21 Dec '07

21 Dec '07

Hi All, I've processed a set of 40 subjects with freesurfer-Linux-centos4_x86_64-stable-pub-v3.0.5 and am now working on a series of morphometric analyses. I am comparing gray matter volumes found in: 1) aparc.stats from recon-all, (same as output of "mris_anatomical_stats" run from the command line) 2) "mris_volume" run from the command line for each hemisphere. I'm seeing slightly different results for the same subject and was wondering why. ** From aparc.stats, I see an initial value of 197405 mm3. This includes a column of data labeled corpus callosum that I assume is not gray matter. Subtracting that, I get 196549 mm3 for a single subject. I'm assuming that the corpus callosum value found in aparc.stats, though small, ought to be removed when calculating total gray volume per hemisphere? ** Running the command line option "mris_volume rh.pial" , followed by "mris_volume rh.white" and subtracting the two values I get 193215 mm3. This is 4190 mm3 smaller than the initial values from aparc.stats for that subject. The question: Are these differences expected? Which value is better to use, and why? Would the general cause of these differences in cortical gray matter volume quantification be consistent for all subjects? Thanks very much, Paul -- Paul Greenberg, Ph.D. Radiology Department, University of California, San Diego VA San Diego Healthcare System (116A-13) 3350 La Jolla Village Drive San Diego, CA 92161 Phone: (858) 552-8585 ext. 2903 Fax: (858) 642-3836 pgreenberg(a)ucsd.edu

2 1

Cerebellar surface?
by Paul Greenberg 21 Dec '07

21 Dec '07

Hi all, Are there any plans for freesurfer to create a cerebellar surface rendering suitable for the display of fMRI results, or is 3D Slicer a good option for creating a 3D cerebellum from the aseg parcellation? Thanks much and happy holidays, Paul -- Paul Greenberg, Ph.D. Radiology Department, University of California, San Diego VA San Diego Healthcare System (116A-13) 3350 La Jolla Village Drive San Diego, CA 92161 Phone: (858) 552-8585 ext. 2903 Fax: (858) 642-3836 pgreenberg(a)ucsd.edu

2 1

jacobian analyses
by Michael Harms 21 Dec '07

21 Dec '07

Hello, I'm going back and running the jacobian analyses (using v4 recon-all) so that I can look at distortion arising from the spherical registration. Couple questions about what is going on "under the hood": 1) When using the -jacobian_white flag, the command executed is: mris_jacobian ?h.white ?h.sphere.reg ?h.jacobian_white Why the use of ?h.white rather than ?h.sphere as the "original surface"? 2) When using the -jacobian_dist0 flag (which appears to be analogous to the old -jacobian flag in the recon-all from v3) the input surface used is ?h.sphere.reg. If I understand correctly, this means that the resulting ?h.jacobian_dist0 file reflects the ADDITIONAL distortion that ensues when registering the already partially registered ?h.sphere.reg to the average convexity of the target atlas with the distance constraints turned offf. Is that concept of "additional" distortion the correct way to think about the ?h.jacobian_dist0 data? 3) In terms of Eq (5) from Fischl et al 1999 ("High-Resolution Intersubject Averaging..."): J = J_p + A*J_a + D*J_d Are BOTH constants A and D set to zero by the -dist0 flag in mris_register (or is it just D that is set to zero)? thanks, Mike H. -- Michael Harms, Ph.D. -------------------------------------------------------------------- Conte Center for the Neuroscience of Mental Disorders Washington University School of Medicine Department of Psychiatry, Box 8134 Renard Hospital, Room 6615 Tel: 314-747-6173 660 South Euclid Ave. Fax: 314-747-2182 St. Louis, MO 63110 Email: mharms(a)wustl.edu --------------------------------------------------------------------

2 3

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