Freesurfer January 2017

freesurfer@nmr.mgh.harvard.edu

123 participants
215 discussions

hippo-subfields analysis 6.0v
by stdp82＠virgilio.it 25 Jan '17

25 Jan '17

Hi list,I'm performing hippo-subfields analysis on T1 having the followed parameters: data_type INT32dim1 170dim2 256dim3 256dim4 1datatype 8pixdim1 1.200005pixdim2 1.000000pixdim3 1.000000pixdim4 1.000000cal_max 0.0000cal_min 0.0000file_type NIFTI-1+ Does my result will be reliable also whether I avoid to add the T2 scan? Thanks Stefano

2 1

Freesurfer 6 - Segfault - mri_ca_register
by Florian Krismer 24 Jan '17

24 Jan '17

Dear FreeSurfer Developers, I'm attempting to run recon-all on a test subject (through recon-all –all –subjid test001 in Freesurfer 6). Recon-all hangs at the mri_ca_register command throwing a Segfault error. This is the corresponding part of the recon-all.log: ------------------------------------------------------------------------------- mri_ca_register -rusage /usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat -nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca transforms/talairach.m3z not handling expanded ventricles... using previously computed transform transforms/talairach.lta renormalizing sequences with structure alignment, equivalent to: -renormalize -regularize_mean 0.500 -regularize 0.500 using MR volume brainmask.mgz to mask input volume... == Number of threads available to mri_ca_register for OpenMP = 1 == reading 1 input volumes... logging results to talairach.log reading input volume 'norm.mgz'... reading GCA '/usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca'... label assignment complete, 0 changed (0.00%) det(m_affine) = 1.26 (predicted orig area = 6.3) Segmentation fault ------------------------------------------------------------------------------- When debugging the error through gdb I get the following, additional information: ------------------------------------------------------------------------------- [florian@freesurfer]$ gdb --args mri_ca_register -rusage /usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat -nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca transforms/talairach.m3z GNU gdb (GDB) Red Hat Enterprise Linux (7.2-90.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/freesurfer/bin/mri_ca_register...(no debugging symbols found)...done. (gdb) run Starting program: /usr/local/freesurfer/bin/mri_ca_register -rusage /usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat -nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca transforms/talairach.m3z warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000 [Thread debugging using libthread_db enabled] not handling expanded ventricles... using previously computed transform transforms/talairach.lta renormalizing sequences with structure alignment, equivalent to: -renormalize -regularize_mean 0.500 -regularize 0.500 using MR volume brainmask.mgz to mask input volume... == Number of threads available to /usr/local/freesurfer/bin/mri_ca_register for OpenMP = 1 == reading 1 input volumes... logging results to talairach.log reading input volume 'norm.mgz'... reading GCA '/usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca'... freeing gibbs priors...done. average std[0] = 5.0 label assignment complete, 0 changed (0.00%) det(m_affine) = 1.26 (predicted orig area = 6.3) Program received signal SIGSEGV, Segmentation fault. _int_free (av=0x7ffff6bb4120, p=0x619a5f30, have_lock=0) at malloc.c:5000 5000 if (__builtin_expect (!prev_inuse(nextchunk), 0)) (gdb) ------------------------------------------------------------------------------- I run the command on a virtual machine (using XEN as hypervisor software) with 2 cores and 8gb RAM assigned to the virtual machine. Some basic information about the platform: 1) FreeSurfer version: freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0 (download date 24-Jan-17) 2) Platform: CentOS release 6.8 (Final) 3) uname –a: Linux 4.4.27-x86_64-jb1 #1 SMP Thu Oct 27 13:51:17 CEST 2016 x86_64 x86_64 x86_64 GNU/Linux 4) mri_ca_register –all-info: ProgramName: mri_ca_register ProgramArguments: -all-info ProgramVersion: $Name: $ TimeStamp: 2017/01/24-17:30:37-GMT BuildTimeStamp: Dec 29 2016 17:01:05 CVS: $Id: mri_ca_register.c,v 1.96.2.3 2016/10/27 22:25:10 zkaufman 5) libgcc.i686 4.4.7-17.el6 Does anyone have any thoughts on how to trouble-shoot this one? The funny thing is that if I remove the –align-after flag, the command works like a charm (I couldn’t find any documentation describing the purpose of –align-after?). Many thanks for your support & best wishes, Florian

2 7

Re: [Freesurfer] longitudinal stream v 5.3 - transfer edits of the wm.mgz from cross to base?
by Antonin Skoch 24 Jan '17

24 Jan '17

Dear Martin, thanks for the feedback. We had to edit cross due to the fact that 1. our dataset is involved also in cross-sectional studies 2. we are continuously acquiring timepoints but want to do some analyses with data we already have Therefore only editing the base was not an option for us. I was thinking (to save time spent on edits) of transferring the INTERSECTION of wm edits from all cross points to base. I think this should work, the only issue I see here is how to handle resampling from space of cross to the space of base. What do you think? And, regarding the v6.0 is currently released, would you recommend to re-process our cross-sectional data (originally processed with v5.3) with v6.0? Would you expect any issues with cross-sectional edits made on v 5.3? Most of the edits are on the wm.mgz, some on brainmask.mgz or brain.finalsurfs.manedit.mgz. Regards, Antonin Hi Antonin, in most cases it should be sufficient to only edit wm.mgz in the base, instead of editing all time points. This is a big time saving especially if you have many time points.I don’t think merging edits from cross will work well, as there could be atrophy and lots of non-linear deformations in some of the fast progressing brains. Best, Martin > On 23 Jan 2017, at 23:11, Antonin Skoch <a...(a)ikem.cz> wrote: > > Dear experts, > > I am currently starting longitudinal analysis of data I previously corrected > in cross-sectional stream (FreeSurfer v5.3). > The analysis comprises quite large number of subjects - approx 150 subjects, > each scanned twice. > All subjects are already inspected and errors corrected in cross-sectional > analysis. Some of them needed quite large edits, mainly to the wm.mgz and the > whole process took large time. > > As I read the documentation, the wm.mgz edits in cross are not currently > transferred to base. However, wm.mgz has to be correct in base in order to > estimate surfaces correctly. From this it implies to me that I would need to > edit all wm.mgz errors in base again. > Do you think that it could be possible/reasonable to transfer some wm.mgz > edits from cross to base, for example to make intersection of edits of all > cross timepoints and to transfer it to the base? This could significantly > reduce time spent on edits. Does it make sense? > > Regards, > > Antonin Skoch

2 1

Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
by Sneha Pandya 24 Jan '17

24 Jan '17

Thank you so much Andrew, I indeed looked into that. FLAIR volume used were acquired in the same session, however not sure of different geometry. I had to also fix the origins for FLAIRraw.mgz as their origins were outside the brain (not sure if that would be contributing to different geometry, I guess not so much). In addition to bbr-init-header I independently tried bbregister with bbr-init-fsl and bbr-init-spm. bbregister only worked with bbr-init-spm resulting in non-empty and properly registered FLAIR.prenorm.mgz and non-empty FLAIR.mgz volume in the mri_normalize step. I tried this with only one case, so not sure if it will be successful for others as well. Do you suggest I run them with bbr-init-spm or registering with FLAIRraw to the orig as you suggested. If bbr-init-spm is fine then with which step of recon should I run? I tried running it with autorecon3 step with bbr-init-spm and FLAIRpial flags, but it did not overwrite FLAIR.prenorm.mgz and FLAIR.mgz volumes. Thanks, Sneha ________________________________ From: Hoopes, Andrew <AHOOPES(a)mgh.harvard.edu> Sent: Tuesday, January 24, 2017 12:20:03 PM To: Freesurfer support list; Sneha Pandya Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header Hi Sneha, I took a look at your issue. Was the FLAIR volume acquired in a different scan session than the other volumes? FLAIRraw.mgz has a much different geometry than 001.mgz and 002.mgz, and so bbregister (the first step of -FLAIRpial) could not register the FLAIRraw to the orig volume, resulting in empty FLAIR.prenorm.mgz and FLAIR.mgz files. Before rerunning autorecon3, I suggest registering the FLAIRraw to the orig, and then applying the resulting transform so that the FLAIRraw geometry is initially in alignment with the other volumes: cd 1_S_5002_snp_bbr-init-header/mri/orig mri_robust_register --mov FLAIRraw.mgz --dst ../orig.mgz --lta FLAIRorig.lta --satit cp FLAIRraw.mgz FLAIRcopy.mgz mri_vol2vol --mov FLAIRraw.mgz --lta FLAIRorig.lta --targ ../orig.mgz --o FLAIRraw.mgz --no-resample This should do the trick. best, Andrew ________________________________ From: freesurfer-bounces(a)nmr.mgh.harvard.edu <freesurfer-bounces(a)nmr.mgh.harvard.edu> on behalf of Sneha Pandya <snp2003(a)med.cornell.edu> Sent: Thursday, January 19, 2017 1:42:06 PM To: Freesurfer support list Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header Hi Bruce, Any luck with what went wrong? Thanks, Sneha ________________________________ From: freesurfer-bounces(a)nmr.mgh.harvard.edu <freesurfer-bounces(a)nmr.mgh.harvard.edu> on behalf of Sneha Pandya <snp2003(a)med.cornell.edu> Sent: Wednesday, January 18, 2017 2:43:01 PM To: Freesurfer support list Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header I transferred file using ftp transfer. Thanks, Sneha ________________________________ From: freesurfer-bounces(a)nmr.mgh.harvard.edu <freesurfer-bounces(a)nmr.mgh.harvard.edu> on behalf of Bruce Fischl <fischl(a)nmr.mgh.harvard.edu> Sent: Wednesday, January 18, 2017 1:58:11 PM To: Freesurfer support list Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header oh, something else went wrong, it's not a memory issue.If you upload the subject we will take a look Bruce On Wed, 18 Jan 2017, Sneha Pandya wrote: > > Sure, please find it attached. > > > Thanks, > > Sneha > > > ____________________________________________________________________________ > From: freesurfer-bounces(a)nmr.mgh.harvard.edu > <freesurfer-bounces(a)nmr.mgh.harvard.edu> on behalf of Bruce Fischl > <fischl(a)nmr.mgh.harvard.edu> > Sent: Wednesday, January 18, 2017 12:20 PM > To: Freesurfer support list > Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header > hmmm, can you send us the recon-all.log file? > > On Wed, 18 Jan 2017, Sneha Pandya wrote: > > > > > Hi Bruce, > > > > > > Total is 231111108 kB from /proc/meminfo and flair vozel size is 1.0000, > > 0.9766, 0.9766. > > > > > > I ran quite a few recon-all after this one failed and it did not complain. > > It just fails when I run recon-all -autorecon3 with -bbr-init-header flag. > > > > > > Thanks, > > Sneha > > > >___________________________________________________________________________ > _ > > From: freesurfer-bounces(a)nmr.mgh.harvard.edu > > <freesurfer-bounces(a)nmr.mgh.harvard.edu> on behalf of Bruce Fischl > > <fischl(a)nmr.mgh.harvard.edu> > > Sent: Wednesday, January 18, 2017 11:09:36 AM > > To: Freesurfer support list > > Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header > > Hi Sneha > > > > how much RAM do you have in your machine? And what is the resolution of > > your data? > > > > cheers > > Bruce > > On Wed, 18 Jan 2017, Sneha Pandya wrote: > > > > > > > > Hi all, > > > > > > > > > I have successfully ran recon-all on my subjects with multiple T1s. We > > want > > > to use flair to refine pial surfaces as for all the subjects pial > surfaces > > > are messy and will demand lots of control point edits. > > > > > > > > > > > > After successfully running entire recon-all stream I am running > following > > > command to incorporate flair: > > > > > > > > > recon-all -autorecon3 \ > > > -s SUBJ \ > > > -bbr-init-header \ > > > -FLAIRpial \ > > > -bigventricles \ > > > -openmp 12 \ > > > -qcache > > > > > > When I run above command recon-all exits while implementing > > > mris_make_surfaces with an error "Cannot allocate memory" > > > > > > Can someone guide what is happening? Is it that there are large > > topological > > > error or bbr-init-header flag will only run if I run recon-all from > > > autorecon1 to autorecon3 stage? > > > > > > Thanks, > > > > > > Sneha > > > > > > > > > > > > > > > > > > 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.

3 4

trac-all bug: using #!/bin/sh instead of #!/bin/bash in scripts which use bash-only syntax extensions
by Parzer, Peter 24 Jan '17

24 Jan '17

Hi, there is a bug in the scripts bedpostx_mgh and fsl_sub_mgh. Both use code that do not conform to the standard shell syntax and work only with bash. This does not work in system that do not link /bin/sh to /bin/bash (as is the case in Ubuntu). Both scripts must use #!/bin/bash as the interpreter command in the first line. Peter

2 1

R: Re: recon-all -all FS6.0
by stdp82＠virgilio.it 24 Jan '17

24 Jan '17

Thanks! >----Messaggio originale---- >Da: "Bruce Fischl" <fischl(a)nmr.mgh.harvard.edu> >Data: 24-gen-2017 21.45 >A: <stdp82(a)virgilio.it>, "Freesurfer support list"<freesurfer(a)nmr.mgh.harvard. edu> >Ogg: Re: [Freesurfer] recon-all -all FS6.0 > >Hi Stefano > >that's a warning burried in the depths of some open source quasi-newton >optimization code that doesn't seem to matter - it can be safely ignored I >believe > >cheers >Bruce >On Tue, 24 Jan 2017, >stdp82(a)virgilio.it wrote: > >> Hi list,I wonder whether the recon-all -all processing are running >> correctly. >> I'm noting the follow lines >> Thanks >> >> Stefano >> >> nsamples 3243 >> >> Quasinewton: input matrix >> >> 1.05460 -0.04529 -0.00589 -5.39976; >> >> 0.04715 1.21082 0.14343 -52.53261; >> >> 0.00057 -0.10515 0.95251 8.62344; >> >> 0.00000 0.00000 0.00000 1.00000; >> >> IFLAG= -1 LINE SEARCH FAILED. SEE DOCUMENTATION OF ROUTINE MCSRCH ERROR >> RETURN OF LINE SEARCH: INFO= 3 POSSIBLE CAUSES: FUNCTION OR GRADIENT ARE >> INCORRECT OR INCORRECT TOLERANCESoutof QuasiNewtonEMA: 011: -log(p) = >> -0.0 tol 0.000010 >> >> Resulting transform: >> >> 1.05460 -0.04529 -0.00589 -5.39976; >> >> 0.04715 1.21082 0.14343 -52.53261; >> >> 0.00057 -0.10515 0.95251 8.62344; >> >> 0.00000 0.00000 0.00000 1.00000; >> >> >>_______________________________________________ >Freesurfer mailing list >Freesurfer(a)nmr.mgh.harvard.edu >https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > >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

recon-all -all FS6.0
by stdp82＠virgilio.it 24 Jan '17

24 Jan '17

Hi list,I wonder whether the recon-all -all processing are running correctly.I'm noting the follow linesThanks Stefano nsamples 3243 Quasinewton: input matrix 1.05460 -0.04529 -0.00589 -5.39976; 0.04715 1.21082 0.14343 -52.53261; 0.00057 -0.10515 0.95251 8.62344; 0.00000 0.00000 0.00000 1.00000; IFLAG= -1 LINE SEARCH FAILED. SEE DOCUMENTATION OF ROUTINE MCSRCH ERROR RETURN OF LINE SEARCH: INFO= 3 POSSIBLE CAUSES: FUNCTION OR GRADIENT ARE INCORRECT OR INCORRECT TOLERANCESoutof QuasiNewtonEMA: 011: -log(p) = -0.0 tol 0.000010 Resulting transform: 1.05460 -0.04529 -0.00589 -5.39976; 0.04715 1.21082 0.14343 -52.53261; 0.00057 -0.10515 0.95251 8.62344; 0.00000 0.00000 0.00000 1.00000;

2 1

Freesurfer 6.0 and ex-vivo T1
by Trisanna Sprung-Much 24 Jan '17

24 Jan '17

Hi there I am wondering if the Freesurfer 6.0 version is more flexible with the parameters used for ex-vivo scans other than what 5.3 required, as listed here https://surfer.nmr.mgh.harvard.edu/fswiki/ExVivo. We acquired some ex-vivo scans at 0.4mm iso but not with those above parameters. many thanks! Trisanna -- Ph.D. Candidate McGill University Integrated Program in Neuroscience Psychology

2 2

How high resolution for -hires in FS6.0
by Alex Cohen 24 Jan '17

24 Jan '17

So what resolution would make sense to use? the release notes say <1.0mm but would 0.9mm isovol really cut it? -Alex ---------------------------------------------------------------- Alexander Li Cohen, M.D., Ph.D. E-mail: Alexander.Cohen2(a)childrens.harvard.edu (Medical/Science Email) E-mail: alexcohen(a)gmail.com (Lifetime Email) ----------------------------------------------------------------

2 5

Neighborhood of a vertex
by Onur Uğurlu 24 Jan '17

24 Jan '17

Hi all, I have a 'lh.thickness.asc' file which contains thickness values of each vertex. The format of the file is following; <vertex index> <x> <y> <z> <thickness> However, x,y,z are not integer. What is the unit of the x,y,z values in the file? I am trying to find all the neighborhood of any given vertex as x,y,z -> x+1,y,z etc, can you suggest a method for this problem. Sincerely yours, Onur

2 10

← Newer
1
...
5
6
7
8
9
10
11
...
22
Older →

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 January 2017