Freesurfer November 2016

freesurfer@nmr.mgh.harvard.edu

120 participants
214 discussions

Re: [Freesurfer] BBR not recommended for PETSurfer?
by Douglas Greve 01 Nov '16

01 Nov '16

Hi Christopher, yes, my position on BBR for PET has changed. I ran an analysis on FDG from an HR+ using BBR and coreg, and the results were not different enough to warrant choosing one over the other. However, coreg performed better on simulated FDG HR+ data, so I'm recommending coreg over BBR, at least for typical resolution scanners like the HR+. For high res (eg, HRRT), BBR may still be better. But for data with a PSF of around 6mm or higher, I would go with coreg. BBR remains the method of choice for all MRI volumes. doug On 11/1/16 10:21 AM, Schwarz, Christopher G., Ph.D. wrote: > > Dr. Greve, > > I noticed on https://surfer.nmr.mgh.harvard.edu/fswiki/PetSurfer > <https://surfer.nmr.mgh.harvard.edu/fswiki/PetSurfer> that you’re > recommending mri_coreg instead of bbregister for PET-MRI alignment in > PETSurfer. This seems inconsistent with your 2014 NeuroImage paper > http://www.sciencedirect.com/science/article/pii/S1053811913012251 > “BBR is very robust with respect to image artifacts and so an ideal > candidate for PET-MR registration” > > Has your position on BBR for PET-MRI changed? Was mri_coreg later > found to be more robust? > > Thank you for your time, > > Christopher Schwarz > > *--* > > *Christopher G. Schwarz, Ph.D.*| Research Associate, Diagnostic > Radiology | Opus Center for Advanced Imaging Research | 507-538-4867 | > schwarz.christopher(a)mayo.edu <mailto:schwarz.christopher@mayo.edu> > > *Mayo Clinic*| 200 First Street SW | Rochester, MN 55905 | > http://mayoclinic.org <http://mayoclinic.org/> >

1 0

Freesurfer recon-all error after installing
by Lehr, Albert 01 Nov '16

01 Nov '16

Dear FreeSurfers, I just recently installed FreeSurfer and as Saeed ( http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg49263.html) had troubles running recon-all. My info: 1) FreeSurfer version: freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0 2) Linux version: Linux unanderra 4.4.0-45-generic #66-Ubuntu SMP Wed Oct 19 14:12:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux I attach my recon-all.log but I guess it is very similar to Saeed's. Also running mri_nu_correct.mni --n 1 --proto-iters 1000 --distance 50 --no-rescale --i orig.mgz --o orig_nu.mgz gives the exact output and error code as he had. I already read that downloading the Development Version should get the job done, but noticed some stuff and wanted to ask about it: Running "recon-all -s bert -all" , the following lines are shown and the build stamps do not match. INFO: FreeSurfer build stamps do not match Subject Stamp: freesurfer-Linux-centos4-stable-v5.3.0beta-20130503 Current Stamp: freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0 INFO: SUBJECTS_DIR is /usr/local/bin/freesurfer/subjects Actual FREESURFER_HOME /usr/local/bin/freesurfer -rw-r--r-- 1 albert albert 513977 Oct 31 16:30 /usr/local/bin/freesurfer/subjects/bert/scripts/recon-all.log Linux unanderra 4.4.0-45-generic #66-Ubuntu SMP Wed Oct 19 14:12:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux INFO: current FREESURFER_HOME does not match that of previous processing. Current: /usr/local/bin/freesurfer Previous: /space/freesurfer/centos4.0/stable Equally in the attached recon-all.log file "FREESURFER_HOME /space/freesurfer/centos4.0/stable Actual FREESURFER_HOME /autofs/cluster/freesurfer/centos4.0/stable5" is written and although I downloaded the centos6-version and not the centos4.0 version. Might this be a problem or is the error solely due to the new perl versions? Just wanted to bring it to your attention and hear your feedback. I am currently downloading the 6.0.0-beta version, which hopefully makes recon-all work again. Have a great day, Albert

2 1

freesurfer preproc output
by Bernardoni, Fabio 01 Nov '16

01 Nov '16

Dear all, after running a freesurfer preprocessing, in each subject subdirectory, the following files are produced: lh.avg_curv lh.curv lh.curv.pial (and the analogue for the right hemisphere) what is the content of these files? sure, I can guess they represent the local curvature. but which one? the intrinsic? the extrinsic? what is the relation with the measures: gauscurv, meancurv, foldind, curvind obtained through the aparcstats2table? It was quite surprising to me that on the wiki no precise definition is present, although one can guess that gauscurv is the intrinsic and meancurv the extrinsic curvature. what are foldind and curvind by the way? how can one get the intrinsic and extrinsic curvatures from the lh.curv files? since these are all very useful measures, it would be of much help for me and other users (I believe) if some more intormation could be written on the wiki. thanks for any help, fabio Dr. Fabio Bernardoni wiss. Mitarbeiter Psychosoziale Medizin und Entwicklungsneurowissenschaften Tel. +49 (0)351 458-5245 Fax +49 (0)351 458-7206 URL http://www.uniklinikum-dresden.de/psm; www.transdenlab.de Universitätsklinikum Carl Gustav Carus & Medizinische Fakultät an der Technischen Universität Dresden Anstalt des öffentlichen Rechts des Freistaates Sachsen Fetscherstraße 74, 01307 Dresden http://www.uniklinikum-dresden.de Vorstand: Prof. Dr. med. D. M. Albrecht (Sprecher), Wilfried E. B. Winzer Vorsitzender des Aufsichtsrates: Prof. Dr. med. Peter C. Scriba USt.-IDNr.: DE 140 135 217, St.-Nr.: 203 145 03113

1 0

tksurfer viewing issues
by Paige Scalf 01 Nov '16

01 Nov '16

Hi Bruce, I'm analyzing phase encoded retinotopy, and it is not clear to me how to load complex overlays in freeview. Perhaps I am missing something? Best, Paige Hi Paige we have stopped development and most support of tksurfer. Can you use freeview instead or is there still some functionality that you need that is unique to tksurfer? cheers Bruce On Thu, 29 Sep 2016, Paige Scalf wrote: >* Hello, *> >* I too am having trouble with tksurfer displaying the surfaces upside down *>* and back to front, but believing that they are correctly oriented (i.e. *>* Talairach coordinates change in the wrong direction wrt to the surface but *>* in the correct direction wrt the display window). I"m also running a CentOs *>* flavor. Did anyone manage to solve this issue? *> >* All the best, *>* Paige* -- Paige E. Scalf, Ph.D. Lecturer Department of Psychology Durham University Psychology Department Durham University Science Laboratories South Road DURHAM DH1 3LE

1 0

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 November 2016