Freesurfer

freesurfer@nmr.mgh.harvard.edu

30132 discussions

Question about version upgrade
by Efrat Kliper 02 May '12

02 May '12

Dear FreeSurfer expert, I am currently working on FreeSurfer Version 4.5.0 and already performed an analysis for approximately 200 subjects. Is there a way to change the version that I am working on (4.5.0) to 5.0.1 without the need to run recon-all again in the new version? Thanks in advanced, efrat

5 5

correlation coefficient
by Tetiana Dadakova 02 May '12

02 May '12

Dear FS experts, I try to look at correlation between thickness and performance. I run mri_glmfit (using performance as covariate) and mri_glmfit-sim. After this I get some significant clusters. I would like to ask if I could get a correlation coefficient for these clusters, or/and a regression plot? Thank you, Tanja.

2 1

How to obtain cortical thickness in fsaverage space
by ZhiLiangLong 02 May '12

02 May '12

Hi all: After finishing group analysis, how can i obtain the thickness value of each ROIs showing significant group-difference in fsaverage space? That is to say, how i get the value of each ROIs which have been normalized to the fsaverage template. The method suggested in tutorials page(http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/QdecGroupAnalysis) just tells the way to get the thickness values in individual space.

3 2

Re: [Freesurfer] Freeview chrash
by Focke, Niels 02 May '12

02 May '12

Dear Ruopeng, this happens with any surface, for example "bert" lh/rh.pial (that comes with Freesurfer). I have attached a locally generated surface as well, but I would guess that the problem is not the surface (files) but rather freeview itself or an incompatibility maybe with the Centos 5 libraries (btw. I have the same problem on Centos 5.2 on another machine). I have just noted, that another user has reported the same (or similar) problem recently (https://mail.nmr.mgh.harvard.edu/pipermail//freesurfer/2012-April/023361.htm l) in ubuntu. Although this thread seems to have ended without resolution. Cheers, Niels __________________________________________________________________________ Dr. Niels Focke Klinische Neurophysiologie UMG - Universitätsmedizin Göttingen

1 0

mri_path2label segmentation fault, with recon-all -localGI
by veronica misc 01 May '12

01 May '12

Hi all, I've been getting a segmentation fault and was hoping someone could help/advise. I have been running recon-all -s [subject] -localGI, and eventually I get an segmentation fault (log below). The error occurs with all subjects, running on numerous machines. I remember I was able to run the same command a few months ago with success. The seg fault seems to happen during mri_path2label, and it doesn't crash right away but gets pretty far along first. I am running Freesurfer 'stable5' on Martinos. I tried with 'stable' and got the same error. Thanks! Veronica Filling 1176 nlabel 10560 Saving label file /autofs/cluster/purdonlab/users/vsw/archive/intracranial-induction/freesurfer-output/mg43/surf/tmp-mris_compute_lgi-rh.pial/rh.pial.001301.label LabelWrite: saving to /autofs/cluster/purdonlab/users/vsw/archive/intracranial-induction/freesurfer-output/mg43/surf/tmp-mris_compute_lgi-rh.pial/rh.pial.001301.label Connecting and filling vertices in path at fillseed 160894 Finding path.................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................... done Segmentation fault (core dumped) ERROR: mri_path2label --confillxfn rh.pial /autofs/cluster/purdonlab/users/vsw/archive/intracranial-induction/freesurfer-output/mg43/surf/tmp-mris_compute_lgi-rh.pial/mri_path2label.input failed!

2 1

How to fix pial surface looping errors
by Laura M. Tully 01 May '12

01 May '12

Hi Freesurfer Experts, I am finding strange loops in the pial surface of my subjects and I'm not sure how to fix them. They do not seem to be caused by problems in the brainmask.mgz - the wm surface looks fine - and they do no seem to be caused by problems in the wm.mgz. What is the best way to deal with them? I have attached a few tiff examples of these loops as visualized in the brainmask.mgz and accomanying saved points in the inflated surfaces so that you can see what I am referencing. Any advice you have would be most appreciated! Best, Laura. -- Laura Tully Social Neuroscience & Psychopathology Harvard University 840 William James Hall 33 Kirkland St Cambridge, MA 02138 ltully(a)fas.harvard.edu -- My musings as a young clinical scientist: http://theclinicalbrain.blogspot.com/

2 1

WM-hypointensities
by Steven Korycinski 01 May '12

01 May '12

To all, I've been using aseg.stats to gather volumetric data about size of the left caudate for a group of subjects. For one subject in particular, there's a large purple-colored area labeled "WM-hypointensities" near the left caudate in aseg.mgz (see attached image) that looks to me like it should be labeled caudate instead (though I'll admit, I'm not an expert in neuroanatomy). I know that aseg.mgz is used in generating the statistics in aseg.stats, so I'm concerned that if I am correct the statistics I've been using are not accurate. Can anyone help me understand what these "WM-hypointensities" are and why there seems to be a large area labeled as such for this particular subject? Am I correct in assuming that an error of some kind may have occurred, and that this area should actually be labeled as caudate? Thanks, -Steve

2 1

mutualinfo in flirt T1->MNI registration
by Andi Heckel 01 May '12

01 May '12

Dear Tracula Team, i noticed that TRACULA uses fsl's flirt with "mutualinfo" as cost function to register the anatomical individual T1 brain (brain_anat.nii.gz) to the MNI152 space T1 template (MNI152_T1_1mm_brain.nii.gz), i.e. for an intramodal registration. I was wondering why "mutualinfo" (which is often used for intermodal registrations) is also used for a an intramodal registration in TRACULA'S implementation rather than e.g. least squares or correlation ratio, the latter being the fsl default. Is "mutualinfo" preferable not only for intermodal (e.g., b0 -> t1) but also for intramodal t1->t1 registrations for your purpose ? - I am just curious to know :) kind regards, andi

2 1

Re: [Freesurfer] bbregister for fmri FEAT data
by Erlend Hodneland 30 Apr '12

30 Apr '12

Hi again Yes, test.nii is the functional data registered to the anatomy. The following files have now been uploaded to your filedrop and can be downloaded by the email account "greve(a)nmr.mgh.harvard.edu" 1. vol0001.nii.gz : functional input 2. orig.mgz : anatomical target 3. register-test.dat : Output Freesurfer registration file 4. test.nii : Output functional data registered to anatomy Thank you for helping us, Erlend And the functional is test.nii.gz? If so, can you upload vol0001.nii.gz, register-test.dat, test.nii.gz, and orig.mgz to our file drop? doug On 04/25/2012 07:49 AM, Erlend Hodneland wrote: > Both the fmri data registered to orig is mismatched, and also the original > raw fmri data are mismatched with orig, > see the link here showing our raw data (fmri, orig and 152MNI) shown in > fslview > > http://vedlegg.uib.no/?id=297a1242fa82b4b7565b470806254c5a > > > It is orig.nii converted from orig.mgz that we show yes. > > Erlend > > > What images are mismatched? Specifically, which anatomical image are you > loading into fslview? > If you have not loaded the orig.mgz (converted to nii), then there will be be > a > mismatch. > doug > > > > On 04/24/2012 04:29 AM, Erlend Hodneland wrote: > > Hi again, > > > > We are trying to do the same as was done in Trachtenberg et al 2012 > > (Neurobiology of Aging), ie opt.the commonly used FLIRT+FNIRT registration > > in > > FEAT with BBreg: > > > > "For group analysis, functional data were registered, via the high > > resolution > > anatomical image, to the Montreal Neurological Institute (MNI) standard > > brain. Functional data were aligned to the anatomical image initially using > > FMRIB's Linear Image Registration Tool, (FLIRT) ([Jenkinson and Smith, > > 2001] > > <http://www.sciencedirect.com/science/article/pii/S0197458010004926#bib27> > > and[Jenkinson et al., 2002] > > > > <http://www.sciencedirect.com/science/article/pii/S0197458010004926#bib28>), > > then optimized using the Boundary-Based Registration (BBR) approach (Greve > > and Fischl, 2009 > > > > <http://www.sciencedirect.com/science/article/pii/S0197458010004926#bib21>). > > Registration from anatomical to standard space was carried out using > > FMRIB’s > > Non-Linear Image Registration Tool (FNIRT)." > > > > > > That is, flirt from fmri --> brain, then initializing bbregister fmri --> > > brain by the previous flirt registration, then flirt and fnirt from brain > > --> > > standard space and finally fmri --> standard space and putting all these > > transformations together. > > > > > > However, our images are orientad as follows from top -> bottom (fmri, > > orig, > > 152MNI): > > > > http://vedlegg.uib.no/?id=297a1242fa82b4b7565b470806254c5a > > > > As shown in the previous communication, when we directly apply the images > > to > > the registration the results are oriented incorrectly, as the input images. > > > > Can you recommend a specific solution to overcome the orientation mismatch > > in > > these images which is compatible with the registration tasks? > > > > > > Thank you for your patience and help! > > > > > > All best > > > > E.H. > > > > > > Hi Erlend, while the images in the tkregister2 pics are oriented > > correctly the registration is way off. What images are you loading into > > fslview? You'll need to convert the orig.mgz into nii and load that to > > check the registration. > > doug > > > > On 04/22/2012 04:16 AM, Erlend Hodneland wrote: > > > Hi again, > > > > > > the registration looks fine in tkregister2, but is apparently wrong in > > > fslview (and also mricron). See the attached files (as link from > > > http://vedlegg.uib.no/?id=399ad2cce1a3138f8eb4f6a06f4acfc4) showing > > > screenshots of fslview and tkregister2. How can this be explained, and > > > how can we visualize the correct orientation in fslview? > > > What does this misalignment influence any further processing with > > > fnirt and concatenation of the affine transformation fields? > > > > > > This is our command we run for bbregister: > > > > > > bbregister --s subj_505 --mov vol0001.nii.gz --reg register-test.dat > > > --init-fsl --t2 --o test.nii.gz > > > > > > where vol0001 is the first volume in the fmri sequence and is flipped > > > to align with LAS (as the highres). > > > > > > Thank you for your kind help, > > > > > > Erlend Hodneland > > > > > > ean that it is in the wrong orientation? It should be in > > > the same orientation as the anatomical. How does the reg look in > > > tkregister2? Note that fslview can display volumes in odd orientations > > > even when the orientation is correct. > > > doug > > > > > > On 04/13/2012 03:31 AM, Erlend Hodneland wrote: > > > > Hi, > > > > > > > > we are trying to register fmri FEAT data (example_func.nii) to the > > > > anatomical scan (processed in Freesurfer) using bbregister to > > opt. > > > > the affine registration before running FNIRT. > > > > > > > > However, the orientation of the registered image is flipped > > around and > > > > is incorrect after applying bbregister. > > > > > > > > We have tried: > > > > > > > > 1) bbregister --s subj_501 --mov example_func.nii.gz --reg > > > > register.dat --init-header --bold --o example_func2highres-fs.nii > > > > 2) bbregister --s subj_501 --mov example_func.nii.gz --reg > > > > register.dat --init-fsl --bold --o example_func2highres-fs.nii > > > > 3) bbregister --s subj_501 --o example_func2highres-fs.nii > > --feat > > > > "myfeatdirectory" > > > > 4) tkregister2 --mov example_func.nii --regheader --reg tkreg.dat > > > > (this one looks correct) > > > > followed by > > > > bbregister --s subj_501 --mov example_func.nii.gz --reg > > register.dat > > > > --init-reg tkreg.dat --bold --o example_func2highres-fs.nii > > > > > > > > 5) reorienting to match the highres: > > > > > > > > fslorient -swaporient example_func > > > > fslswapdim example_func x -y z example_func_swap (correct > > > > orientation) > > > > > > > > followed by > > > > bbregister --s subj_501 --mov example_func_swap.nii.gz --reg > > > > register.dat --init-fsl --bold --o > > example_func_swap2highres-fs.nii > > > > > > > > with the output being flipped in wrong orientation for all > > options. > > > > > > > > We would greatly appreciate if you have any suggestions for how to > > > > overcome this problem! > > > > > > > > Cheers/Sincerly/All best > > > > > > > > Erlend Hodneland

2 1

niiRead(): unsuported datatype 64
by Clark Fisher 30 Apr '12

30 Apr '12

Hi all, I'm trying to use Freesurfer to work with a parameter map saved as a nifti volume by another package (mrVista). However, whenever I try to open it using a Freesurfer tool (tkmedit, mri_info, freeview, etc.) I get the following error : niiRead(): unsuported datatype 64 (with scl_slope = 0) in /...path to file.../ParMap.nii.gz Is it obvious what's going on? Is there anything I can do to the file or my Freesurfer configuration to work with this volume? Thanks, Clark

2 1

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