Freesurfer April 2013

freesurfer@nmr.mgh.harvard.edu

131 participants
220 discussions

Re: [Freesurfer] Problem with longitudinal edits
by Vy Dinh 01 Apr '13

01 Apr '13

Hi Martin, Thank you for getting back to me. To clarify what I did: 1. edited all cross-sectionals & reran until surfaces are accurate. 2. created the base from the cross-sectionals. 3. edited base & reran until surfaces are accurate 4. created longitudinal files from edited cross-sectionals & base 5. edited longitudinal data & reran We only edited the brain.finalsurfs.manedit.mgz file (not brainmask.mgz as it was problematic to delete the cerebellum in this file) in each case, except that when I recreated the surfaces for the longitudinal data, it appears that the edits from both cross-sectionals and base did not transfer at all! While the edits in the longitudinal data are minor, we try to be precise with our manual edits. (hence, why we edited all cross-sectionals & base prior to editing the longitudinal data). We edited these edits and reran only to find out that the surfaces look worse in the longitudinal data after rerunning than it did before editing. Based on your response, it appears that we should forego editing the cerebellum in the brain.finalsurfs.manedit.mgz file if we do not want the extra effort of reediting longitudinal surface from scratch because the existence of this file prevents edits from the cross-sectionals and base to be transferred to the longitudinal data? Do you suggest we: Accept the minor issues with the surface boundaries and not edit the longitudinal data at all? (BTW, I checked cross-sectional and base to see if these issues exist in these images. They do not.) or Just rerun recon-all -autorecon2-pial -autorecon3 -long subid_1 subid_template & edit from scratch to get most accurate surfaces? It would help if I understand what the autorecon2 & 3 codes are doing exactly with the images & edits. Also, your tutorials suggest using autorecon2-pial in one instance and autorecon3-pial in another. If possible, could you please elaborate on the differences between the 2 commands? *Regarding your inquiry about editing the brain.finalsurfs.manedit.mgz file: * When we first learned that the brain.finalsurfs.manedit.mgz file was used for editing the cerebellum, I posted the question to your group: If the brain.finalsurfs.manedit.mgz file was used as the final determinant for the surface boundaries, which ultimately determines how FS extracts the segmentation and parcellation data, why not make edits to brain.finalsurfs.manedit.mgz file only? This would've saved us a lot of time because we only had to inspect and edit one file. The response was "there doesn't seem to be any reason for not doing this," so we stuck with editing the brain.finalsurfs.manedit.mgz, which appeared to work fine until now. On Mon, Apr 1, 2013 at 3:39 PM, Martin Reuter <mreuter(a)nmr.mgh.harvard.edu>wrote: > Hi Vy, > > not sure what it going on in your data. Surfaces are copied from the base > and if they are not accurate there you need to fix it there. It seems you > did that and you worked the edits in the right order. > > What exactly happened? You fixed cross and base and everything look fine. > When you run long it looks fine, but when you edit long and run it again it > messes up? > > Did you edit only the brain.finalsurfs or also other things at the same > time? Also, if you edited long, these edits will be kept and not replaced > with new edits from base or cross. So if cross or base get edited it may be > good to rename or remove the edit file in the long and run long without > edits again. This way the cross and base edits get transferred to long > automatically. Only if that is not sufficient you need to do edits in the > long. > > Sorry I cannot say more right now without knowing what you did. > > Best, Martin > > > > On Fri, Mar 29, 2013 at 10:13 AM, Vy Dinh <vy_dinh(a)rush.edu> wrote: > >> BTW, we are using Freesurfer 5.1: >> freesurfer-i686-apple-darwin9.8.0-stable5-20110525 >> >> >> On Fri, Mar 29, 2013 at 10:08 AM, Vy Dinh <vy_dinh(a)rush.edu> wrote: >> >>> Dear Developers, >>> >>> I have a significant problem when rerunning the pial edits for the >>> longitudinal data. Our dataset consists of subjects & a followup scan (for >>> each sub). To be thorough, we edited brain.finalsurfs.manedit.mgz (as it >>> was further in the processing stream) for the cross-sectional scans, the >>> base scans, and the longitudinal scans. The longitudinal data were created >>> only after the base has been edited and rerun. Likewise, the base was only >>> created and rerun after the cross-sectionals were finalized. >>> >>> We work with a clinical population so minor edits do show up on the >>> longitudinal scans. However, after editing and recreating the surfaces from >>> these longitudinal scans, the pial surfaces has extended to include dura & >>> other voxels that were not previously included within the pial surface >>> (during the initial creation of the longitudinal data). We tried both >>> commands (listed below) and get this same problem: >>> >>> recon-all -autorecon2-pial -autorecon3 -long tpN tp_base ( >>> http://surfer.nmr.mgh.harvard.edu/fswiki/LongitudinalEdits) >>> or recon-all -autorecon3-pial -long tpN tp_base ( >>> http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/LongitudinalTutorial >>> ) >>> >>> *Could you please help us figure out why the pial surface extends to >>> include nonbrain regions when recreating the surfaces? * >>> * >>> * >>> *What solutions would you suggest in resolving this problem?* >>> * >>> * >>> Thank you, >>> >>> Vy Dinh >>> Research Associate >>> Department of Neurological Sciences >>> Rush University Medical Center >>> >> >> > > > _______________________________________________ > Freesurfer mailing listFreesurfer@nmr.mgh.harvard.eduhttps://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > > -- > Dr. Martin Reuter > Assistant in Neuroscience - Massachusetts General Hospital > Instructor in Neurology - Harvard Medical School > MGH / HMS / MIT > > A.A.Martinos Center for Biomedical Imaging > 149 Thirteenth Street, Suite 2301 > Charlestown, MA 02129 > > Phone: +1-617-724-5652 > Email: > mreuter(a)nmr.mgh.harvard.edu > reuter(a)mit.edu > Web : http://reuter.mit.edu > > 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. >

1 0

Problem with longitudinal edits
by Vy Dinh 01 Apr '13

01 Apr '13

Dear Developers, I have a significant problem when rerunning the pial edits for the longitudinal data. Our dataset consists of subjects & a followup scan (for each sub). To be thorough, we edited brain.finalsurfs.manedit.mgz (as it was further in the processing stream) for the cross-sectional scans, the base scans, and the longitudinal scans. The longitudinal data were created only after the base has been edited and rerun. Likewise, the base was only created and rerun after the cross-sectionals were finalized. We work with a clinical population so minor edits do show up on the longitudinal scans. However, after editing and recreating the surfaces from these longitudinal scans, the pial surfaces has extended to include dura & other voxels that were not previously included within the pial surface (during the initial creation of the longitudinal data). We tried both commands (listed below) and get this same problem: recon-all -autorecon2-pial -autorecon3 -long tpN tp_base ( http://surfer.nmr.mgh.harvard.edu/fswiki/LongitudinalEdits) or recon-all -autorecon3-pial -long tpN tp_base ( http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/LongitudinalTutorial) *Could you please help us figure out why the pial surface extends to include nonbrain regions when recreating the surfaces? * * * *What solutions would you suggest in resolving this problem?* * * Thank you, Vy Dinh Research Associate Department of Neurological Sciences Rush University Medical Center

3 5

Doctoral (PhD) and Postdoctoral Position in Geneva, Switzerland
by Sascha Fruehholz 01 Apr '13

01 Apr '13

We invite applications for a Doctoral (PhD) and a Postdoctoral position at the Swiss Center for Affective Sciences (University of Geneva, Switzerland; www.affective-sciences.org/ ) and the Neuroscience of Emotions and Affective Dynamics Lab (Head: Prof. Didier Grandjean). We are seeking for highly motivated and talented research candidates to work on a project on the neural basis of processing human affective vocalizations. The positions are funded by the Swiss National Science Foundation (SNFS). For the Doctoral (PhD) position candidates should have a relevant degree in psychology, neuroscience or a related field. Furthermore, they should be familiar with fMRI and/or EEG and have a strong background in affective or auditory neuroscience. Programming skills (i.e. Matlab) are advantageous. The position is available for 3 years. For the Postdoctoral position candidates should have a Ph.D. (or equivalent) in psychology, biology, neuroscience or a related field. Furthermore, they should be familiar with fMRI (on 3T and/or 7T scanners) and have a strong background in auditory neuroscience. Candidates should have experience in brain image analysis (SPM, FSL and/or FreeSurfer), pattern recognition, and statistics. Excellent programming skills (Matlab, UNIX, etc.) are highly desirable. The position is initially available for 2 years with a possible extension for one year. The University of Geneva provides an excellent multidisciplinary and interactive neuroimaging environment with research dedicated brain imaging facilities (http://bbl.unige.ch/index.html) within the framework of the Geneva Neuroscience Center (http://neurocenter.unige.ch/) The positions are available immediately and applications will be considered until the positions are filled. Candidates should submit a CV, names and full contact details of two referees and a statement of research interests by e-mail to Dr. Sascha Frühholz (sascha.fruehholz(a)unige.ch) Informal inquiries and questions should be addressed to sascha.fruehholz(a)unige.ch or didier.grandjean(a)unige.ch.

1 0

slice timing
by Meryem Ayse Yucel 01 Apr '13

01 Apr '13

Doug, I use preproc-sess 's -stc up option to time correct my slices. I only have 6 slices. Donald, I am not calculating absolute CBF values using the calibration scan. I pre-process the data and then either surround-subtract or just subtract tag from control to get CBF, would it still be a problem to use slice time correction? Thanks, Meryem Message: 11 Date: Fri, 29 Mar 2013 13:40:42 -0400 From: "MCLAREN, Donald" <mclaren.donald(a)gmail.com> Subject: Re: [Freesurfer] slice timing To: Douglas N Greve <greve(a)nmr.mgh.harvard.edu> Cc: freesurfer(a)nmr.mgh.harvard.edu Message-ID: <CAKwrF_XJfg=PRTm2htZ12FN74VtP2qGzqffAGKeZBJO+pXDrQQ(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" If you are using ASL, you do not want to use Slice timing. You must compute the CBF maps and keep the slice timing intact. Removing the time delay between slices will lead to the wrong CBF values as the CBF equations have the time delay in the equation. Best Regards, Donald McLaren ================= D.G. McLaren, Ph.D. Research Fellow, Department of Neurology, Massachusetts General Hospital and Harvard Medical School Postdoctoral Research Fellow, GRECC, Bedford VA Website: http://www.martinos.org/~mclaren Office: (773) 406-2464 ===================== This e-mail contains CONFIDENTIAL INFORMATION which may contain PROTECTED HEALTHCARE INFORMATION and may also be LEGALLY PRIVILEGED and which is intended only for the use of the individual or entity named above. If the reader of the e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that you are in possession of confidential and privileged information. Any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this e-mail unintentionally, please immediately notify the sender via telephone at (773) 406-2464 or email. On Fri, Mar 29, 2013 at 1:08 PM, Douglas N Greve <greve(a)nmr.mgh.harvard.edu>wrote: > what are you using to do STC? I think by default FSL will move it to the > middle slice, but there is probably a way to make take into account the > fact that the slices are not uniform over the TR. You should contact the > list of the software you are using to get a definative answer. > doug > > > On 03/29/2013 11:37 AM, Meryem Ayse Yucel wrote: > > Hi, > > > > I am running a pASL sequence with a TR = 3 sec and TI2 = 1.8. I am > > wondering when I do slice time correction does that move all slices to > the > > mid of TR that is 1.5 s prior in time or, it moves them to the timing of > > the mid slice, which would be the mid of image acquisition aorund 0.6 sec > > prior in time with respect to the end of TR. > > > > Thank you, > > > > Meryem > > _______________________________________________ > > Freesurfer mailing list > > Freesurfer(a)nmr.mgh.harvard.edu > > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > >

3 2

slice timing
by Meryem Ayse Yucel 01 Apr '13

01 Apr '13

1 0

More QDEC questions
by Tudor Popescu 01 Apr '13

01 Apr '13

Hi everyone, My QDEC analysis ran into an error message that seems to be a "classic" (and, so far, it seems unsolved), from mri_concat, which I've described in a separate message, just sent. I have, however, more theoretical questions about QDEC, which I hope some kind soul will help me with: - why does QDEC only provide the volume of *subcortical* structures under StatsDataImport/aseg.volume, when the automatic GM/WM segmentation is done for the entire brain, not just for subcortical regions? - how are the volume measurements provided in aseg.volume different from the ones done obtained with a VBM analysis? - why is *volume *the result of *segmentation *(aseg.volume) whereas *thickness *derives from *parcelation *(rh.aparc.thickness)? Is it not the case that both operations (segmentation+parcellation) are necessary to calculate volume as well as thickness? - how is a QDEC thickness analysis different from a regular AN(C)OVA in which you are interested in main and interaction effects of the IVs on the DV? I ask this because some of the questions that appear in QDEC's Analysis Results tab – e.g. "is the correlation between (DV) and (IV) different from zero?" – would not (I think) be directly answerable by an ANOVA - would the same type of ANOVA done by QDEC be doable by extracting the values of the DV for each subject (using e.g. *aseg.volume*) and then doing the ANOVA in e.g. SPSS? If so, when would you do one versus the other? - why is it that only continuous factors (e.g. age) can be taken in the analysis as nuisance factors, when discrete variables (e.g. gender) might also be irrelevant for a particular analysis and thus belong to the Nuisance Factor list? Many thanks in advance!! Tudor

2 4

MAking cuts using tksurfer
by Anupa AV 01 Apr '13

01 Apr '13

Dear All, How to explore the "cut" tools in freesurfer using tksurfer? I'd like to make a cut along the vertex on the cortical surface (say, inflated) to divide medial and lateral components. How to do it after loading DKatlas labels and I want to cut along the vertex to divde medial and lateral components.? Thanks in advance for your response.

2 1

FS 5.2 asegstats2table is not found or is too small to be a valid stats file error
by Salil Soman 31 Mar '13

31 Mar '13

Dear Experts, I am trying to extract FS 5.2 statistics for a single subject using the following command: asegstats2table --subjects SUBJECTNAME --tablefile teststats.txt I keep getting *the following error: * *The stats file /PATH/SUBJECTNAME/stats/aseg.stats is not found or is too small to be a valid statsfile Use --skip flag to automatically skip bad stats files * Any suggestions on what I am doing incorrectly? I would like to extract all of the statistics in aseg.stats into a single row per subject to facilitate additional analysis in other programs. Any suggestions on how to accomplish this would be much appreciated. Thank you. -S* *

2 1

mri_glmfit-sim doesn't recognize --label flag
by Yizhou Ma 31 Mar '13

31 Mar '13

Dear freesurfer experts, I'm doing small volume correction for multiple comparison. However, when I run "mri_glmfit-sim" with "--label mylabelfile", I got the error that "--label unrecognizable". I use "mri_glmfit-sim --help" to see the help information but there is no information regarding "--label" or "--mask". May I know why this? P.S. I use FS510. I have run mri_glmfit-sim successfully without a mask. Thanks, Cherry

2 1

tractstats@table output oddity
by Jon Wieser 31 Mar '13

31 Mar '13

I ran tractstats2table to make a table of my dti tract stats for the fmajor_PP tract see the attached script file @tractstats2table and the file list "fmajor_file_list.txt" it produced the output file "fmajor_table.txt" (attached) in the output table all the values for the variables are the same for the 7 rows. the values are from last file in the list DTItracts/1276/fmajor_PP_avg23_mni_flt/pathstats.overall.txt why is this? input files have different values for the various variable Jon -- Jon Wieser Research Specialist UW-Milwaukee Psychology Department, Pearse Hall Rm 366 2441 East Hartford Ave Milwaukee, WI 53211 Phone: 414-229-7145 Fax: 414-229-5219

1 2

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 April 2013