Freesurfer

freesurfer@nmr.mgh.harvard.edu

12 participants
30095 discussions

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

Extracting significant clusters after qdec analyses
by Katherine Damme 24 Jan '17

24 Jan '17

Hello Everyone, Is there a way to extract the significant clusters as masks from significant group comparisons using qdec? All I can seem to find is mri_glmfit-sim which doesn't quite replicate the QDEC FDR 0.05 output and doesn't seem to make anything that I could extract as a label, or hand drawing an ROI. I am working with a longitudinal model of cortical thickness, and would like to extract the average thickness of each significant cluster to understand the change in thickness. Thank you. Kate Damme

3 5

FS6 recon-all hangs at mris_fix_topology
by Hibert, Matthew Louis 24 Jan '17

24 Jan '17

Hi Freesurfer Devs, I'm trying to re-process a subject who had a right temporal lobectomy using FS6 but the recon hangs at the mris_fix_topology step, saying "XL defect detected...". It continues to use a CPU for several days if allowed, but does not actually progress from that point. This scan was able to be processed in both stable 4 and stable 5.3. I've attached the recon-all log from the recon using the Martinos installation of "stable6". Any suggestions? Thanks, Matt

2 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