Freesurfer

freesurfer@nmr.mgh.harvard.edu

21 participants
30070 discussions

freesurfer and monkey (macaque) brain processing
by Istvan Akos Morocz 06 Jun '06

06 Jun '06

dear freesurfer group, is there anywhere some cookbook-like instruction for processing monkey (macaque) brain MRI data with FreeSurfer ? are there any normalized macaque brain templates needed for FreeSurfer ? thanks, bye, pisti ----- pisti(a)bwh.harvard.edu

2 1

Problems runing a complete freesurfer analysis under Centos4 X86-64
by jorge luis 05 Jun '06

05 Jun '06

Hello all I have a Dual core Intel Pentium 3.0Gz machine with 2GB RAM and two SATA2 Hard Disks (300 GB and 80GB, respectively). I have successfully installed Linux Centos4 X86-64 (on the 80 GB disk) and the corresponding freesurfer version. I have run several freesurfer commands successfully (eg. tkmedit bert orig.mgz). The problem is when I try to run a complete analysis (recon-all - autorecon-all), the corresponding terminal gets stop undefinedly when it has to execute a copy operation (e.g. cp aseg.auto.mgz aseg.mgz). That is to say the problem get rise when freesurfer sends a copy order to the operating system. Manually I carry out the copy command and I don't have any problems. But when I reactivate freesurfer (eg. recon-all - autorecon2-cp) the terminal stops again when it has to carry out a copy operation again. I have another Intel Dual Xeon Dual Core 2.8Gz 5GB RAM machine with Linux Centos 4 X86-64 and the same configuration. No problem is there. Any tip to overcome this problem is welcome Thank you in advance Jorge ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com

3 2

problems with make_average_subject
by Lars M. Rimol 05 Jun '06

05 Jun '06

Hi, I am analysing a dataset with 180 subjects. When I run make_average_subjects it crashes, the error message usually being something like this: mghRead: encountered error executing: 'zcat /space/monkeys/1/home/lmr/subjects/VETSA_test/testAVG/tmp/make_average_vol-tmp/orig- 19963b.mgz',frame -1 I have tried running it with fewer subjects and it worked with 3, 10 and 73 subjects. Also, it crashes at different points in the processing stream, so once it crashed at subject # 130, which I removed from the list of subjects, and then next time it crashed at # 30. My frist guess was that it is a memory problem. I tried running the top command in a different terminal at the same time as running make_average_subject with 2 and 10 subjects, and it seemed to require up to 400m of virtual memory and 10% of memory, but I couldn't see any difference in memory demands between running 2 and 10 subjects. This was running with 4G of physical memory and 2G of swap. Is this a known issue? (Couldn't find anything in the mailing list archive..) Thank you! -- yours, LMR

3 2

make_average_subject
by Lars M. Rimol 05 Jun '06

05 Jun '06

Hi, I have two questions on make_average_subject 1) Why are two sets of surfaces created by the make_average_subject script? What is the difference between e.g. inflated and inflated_avg? Which one(s) should be used for visualization? 2) As far as I understand, make_average_subject is run for visualization purposes only, and the output is not critical for the integrity of the statistical analyses (recon-all does the spherical warping and registration, and t he mris_preproc script makes sure the tesselation is uniform across the data set). So, does it matter if there are defects in the surfaces created by make_average_subject? I tend to get topological defects in the inflated_avg. Thank you! -- yours, LMR

2 1

trouble importing SPM2/Analyze file with tkregister2 in order to create a register.dat file
by Istvan Akos Morocz 05 Jun '06

05 Jun '06

dear freesurfer team, i experience trouble to compute the register.dat file when using tkregister2 to import an SPM2 BOLD brain volume f.img together with an 001.mgz structural file. segmentation and flattening worked flawlessly for that 001.mgz file (imported initially from an SPM2 anatomical data). here some examples of my desperate attempts: tkregister2 --mov ANALYZE/f.img --s fs1 --regheader --noedit --reg register.dat tkregister2 --mov ANALYZE/f.img --targ ANALYZE/cor.img --s fs1 --regheader --noedit --reg register.dat tkregister2 --mov ANALYZE/f.img --targ ANALYZE/cfs1/mri/orig/001.mgz --s fs1 --regheader --noedit --reg register.dat tkregister2 --mov ANALYZE/f.img --targ fs1/mri/orig/001.mgz --s fs1 --regheader --noedit --reg register.dat tkregister2 --mov ANALYZE/f.mat --targ fs1/mri/orig/001.mgz --s fs1 --regheader --noedit --reg register.dat tkregister2 --mov ANALYZE/f.hdr --targ fs1/mri/orig/001.mgz --s fs1 --regheader --noedit --reg register.dat please, see error messages below. something seems to run wrongly when reading the f.mat file. i use matlab v7.1 with SPM2. the mat file initially was created as compressed mat file (v7 style), but then i converted the f.mat alsoto a v6 style = non-compressed, but no difference. content of the f.mat file is, after doing: 'load f.mat' mat = 3.7499 -0.0312 0.0122 -128.3677 0.0325 3.6227 -1.2914 -110.0712 -0.0008 0.9686 4.8303 -86.1374 0 0 0 1.0000 ==> are there somewhere out there clear instructions how to make SPM2 and freesurfer coexist ? thanks, bye, pisti ---------------------------------------------------------------------- error messages: - 1 ------------------------------------------------------------------ tkregister2 --mov ANALYZE/f.img --s fs1 --regheader --reg register.dat INFO: no target volume specified, assuming FreeSurfer orig volume. target volume orig movable volume ANALYZE/f.img reg file register.dat LoadVol 1 $Id: tkregister2.c,v 1.49.2.4 2006/03/27 21:48:16 greve Exp $ Diagnostic Level -1 matfile: only read 423 bytes of name (1768711468 specified) MatlabRead: readHeader returned NULL WARNING: analyzeRead(): matfile ANALYZE/f.mat exists but could not read ... may not be matlab4 mat file ... proceeding without it. ----------------------------------------------------------------- INFO: could not find ANALYZE/f.mat file for direction cosine info. INFO: use Analyze 7.5 hdr->hist.orient value: 0, transverse unflipped (default). INFO: if not valid, please provide the information in ANALYZE/f.mat file ----------------------------------------------------------------- INFO: loading target /data/kodaly/r/pisti/numerals/fMRI_LM_060427/fs1/mri/orig.mgz INFO: changing target type to float Ttarg: -------------------- -1.000 0.000 0.000 128.000; 0.000 0.000 1.000 -128.000; 0.000 -1.000 0.000 128.000; 0.000 0.000 0.000 1.000; INFO: loading movable ANALYZE/f.img matReadHeader: couldn't allocate 1768711469 bytes for name Cannot allocate memory - 2 ------------------------------------------------------------------ tkregister2 --mov ANALYZE/f.img --targ fs1/mri/orig/001.mgz --s fs1 --regheader --noedit --reg register.dat target volume fs1/mri/orig/001.mgz movable volume ANALYZE/f.img reg file register.dat LoadVol 0 $Id: tkregister2.c,v 1.49.2.4 2006/03/27 21:48:16 greve Exp $ Diagnostic Level -1 matfile: only read 423 bytes of name (1768711468 specified) MatlabRead: readHeader returned NULL WARNING: analyzeRead(): matfile ANALYZE/f.mat exists but could not read ... may not be matlab4 mat file ... proceeding without it. ----------------------------------------------------------------- INFO: could not find ANALYZE/f.mat file for direction cosine info. INFO: use Analyze 7.5 hdr->hist.orient value: 0, transverse unflipped (default). INFO: if not valid, please provide the information in ANALYZE/f.mat file ----------------------------------------------------------------- INFO: loading target fs1/mri/orig/001.mgz INFO: target does not conform to COR format, so I'm going to reslice to COR. This will not affect the final registration. Ttarg: -------------------- -1.000 0.000 0.000 128.000; 0.000 0.000 1.000 -128.000; 0.000 -1.000 0.000 128.000; 0.000 0.000 0.000 1.000; INFO: loading movable ANALYZE/f.img matReadHeader: couldn't allocate 1768711469 bytes for name Cannot allocate memory - 3 ------------------------------------------------------------------ tkregister2 --mov ANALYZE/f.hdr --targ fs1/mri/orig/001.mgz --s fs1 --regheader --noedit --reg register.dat target volume fs1/mri/orig/001.mgz movable volume ANALYZE/f.hdr reg file register.dat LoadVol 0 $Id: tkregister2.c,v 1.49.2.4 2006/03/27 21:48:16 greve Exp $ Diagnostic Level -1 ERROR: cannot determine type of ANALYZE/f.hdr - 4 ------------------------------------------------------------------ tkregister2 --mov ANALYZE/f.mat --targ fs1/mri/orig/001.mgz --s fs1 --regheader --noedit --reg register.dat target volume fs1/mri/orig/001.mgz movable volume ANALYZE/f.mat reg file register.dat LoadVol 0 $Id: tkregister2.c,v 1.49.2.4 2006/03/27 21:48:16 greve Exp $ Diagnostic Level -1 matfile: only read 423 bytes of name (1768711468 specified) MatlabRead: readHeader returned NULL ImageRead(ANALYZE/f.mat) failed Segmentation fault and so on... ----- pisti(a)bwh.harvard.edu

2 1

memory limitations
by Don Hagler 04 Jun '06

04 Jun '06

Running recon-all with the v3.0.2 release, I have noticed recently that the process will run into seg faults at various stages (e.g. topology correction, sphere reg, or cortical parcellation). This seems somewhat random, but judging from some other posts, and the fact that it happenened when I was running multiple jobs at once but didn't (for the same subject) when it was the only job, it seems to be memory dependent. That is, when there is not enough available memory, things crash without warning or relevant error messages (e.g. not enough memory). Does that seem like an accurate assessment of things? Aside from hardware solutions (e.g. more RAM or bigger swap space), is there anything that can be done to the software to allow the user to balance speed with memory usage? And die in a less mysterious way?

2 1

question about distortion from flattening
by adam walczak 03 Jun '06

03 Jun '06

Hello, I was wondering if there is a more intutive way than guess-and-check to help me to eliminate the distortion on the flattened surfaces. I know that it is due the the placement/length of the cuts, but I am not sure how to alter the cuts so that the images won't be distorted. This seems like a problem that has been encountered before, so I was wondering if anyone had a method. Thanks for any help you give, Adam adam __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

measures of folding
by Sasha Wolosin 02 Jun '06

02 Jun '06

Dear All, We are interested in degree of cortical folding within our subject populations. Would someone please help me to better understand what the measures "MeanCurv", "GausCurv", "FoldInd" and "CurvInd" in the ?h.aparc.stats files mean? Also, are whole brain stats reported elsewhere? Thanks, Sasha Disclaimer: The materials in this e-mail are private and may contain Protected Health Information. Please note that e-mail is not necessarily confidential or secure. Your use of e-mail constitutes your acknowledgment of these confidentiality and security limitations. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying, distribution, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender via telephone or return e-mail.

2 1

statistics without mri_glmfit
by Lars M. Rimol 02 Jun '06

02 Jun '06

Hi, I would like to analyse my data without using the mri_glmfit, because it is not flexible enough for my current purposes. But I would like to use mris_preproc and surf2surf in order to get the data into common space. However, when executing the mris_preproc I am required to specify a FSGD file, i.e. a design (variables, regressors etc.). I am wondering if that influences the processing of the data in any way - before mri_glmfit of course. So, what I am doing is just loading the ?h.FSGDF.thickness.10.mgh file that is the output of the surf2surf script, into Matlab and doing the statistics there. However, I am worried that the mris_preproc script may be using the information from the FSGD file to alter the measurements in any way. Of course, I turn of the reshape that is default in surf2surf. Are there any other options I should turn off or change? Thank you! -- yours, LMR

2 1

Some FS input questions
by Graham Wideman 02 Jun '06

02 Jun '06

Most likely to Nick S, unless anyone else would like to chime in... I'm gearing up for some extensive use of FS... it's downloaded, installed, and initial tests run OK... so far with minimum of pain (yay team!). Now... I need to discover how to feed in data other than raw scanned files, because we want to try several alternatives to the initial processing, which we have in AFNI format, ac-pc aligned with iso-sided voxels but not 1 mm. I suspect I'll end up scouring the recon-all script, but a few hints would be helpful, mainly aimed at (a) taking advantage of processing that we have done by other methods, (b) minimizing resampling and (c) winding up with surfaces and segmentations that are most readily overlayed with our other processed data, tracings etc. 1. If we want to feed in already ac-pc aligned, brain-extracted input, at what stage of recon-all should we be looking to supply it? (I can figure out where in the directories to put the data, but not sure on the stage of processing to start at). 2. It used to be that FS's surface pipeline didn't insist on Talairaching the voxel data, and skipping that resulted in output that is true to original space. Is that still the case? 3. Does current FS proper require 256x256x256 1mm data, or can it take any shape "brick" and voxel size (ie: without resampling) these days? 4. If FS *does* want to work with 1mm voxels only: It used to be that though FS wanted 1mm input voxels, you could feed in some other sizes by do-it-yourself creation of the COR images, and FS was fine... is that still the case (but now with mgz format)? 4. Is it the case that the subcortical voxel-based parcellation *does* require the Talairaching step for correspondence with the probability atlas? 5. The surface and voxel-based pipelines are separate, not even sharing the white segmentation step, right? Thanks in advance, Graham

3 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