Freesurfer January 2017

freesurfer@nmr.mgh.harvard.edu

123 participants
215 discussions

V6beta: recon-all --noasegfusion does not initialize using longbase aseg.mgz; how to handle aseg edits in longitudinal stream
by Antonin Skoch 17 Jan '17

17 Jan '17

Dear experts, I am testing the longitudinal stream with V6beta version. The recon-all -help says for -noasegfusion: Do not create 'fused' aseg from the longbase timepoints, which would normally be used to initialize the ca_labeling. Instead, initialize using the longbase aseg.mgz. As I looked to recon-all code it seems that in case of -noasegfusion there is no use of -r and -ri parameters and therefore no "initialization". Could you please comment on? My second query is regarding manual edits: In one subject the manual editing of aseg was necessary due to ventricle mislabeling. I edited the aseg.presurf in base template and subsequently run longitudinal stream via recon-all -long tpID templateID -noasegfusion -all >From the last sentence of -noasegfusion help I (wrongly) expected that my aseg.presurf edits in base template would be incorporated for -long recon. However, this was not the case, the edits have not been incorporated at all. Looking at the recon-all code the aseg.presurf from base is never used for -long. I thought that I could incorporate manual edits from base by manual copying of aseg.presurf from base to long directory. As I looked for the way how the manual aseg edits are handled in recon-all, they are identified by using the difference between the files aseg.auto and aseg.manedit which contains manual edits. Therefore I think that the copying from base is not an option, I expect that this would replace segmentations not only in manual edit regions, but in all regions where the aseg.auto of base and aseg.auto of -long differs (they do not have the same input) which is undesirable. So I think I do not have any other option than to edit aseg.presurf in -long again. Could you please comment on how to optimally handle such situations? Regards, Antonin Skoch

2 1

T2 voxel size needed for recon_all
by Erik O'Hanlon 17 Jan '17

17 Jan '17

2 2

Re: [Freesurfer] Brighter image at baseline vs. follow up using longitudinal processing stream
by Tamara Tavares 16 Jan '17

16 Jan '17

Hi Dr. Reuter. Thank you again for your help. I ran the following command: "mri_robust_register --mov rawavg_1.mgz --dst rawavg_2.mgz --lta v1to2.lta --affine --satit" on the two rawavg.mgz images; one from each time point from the cross-sectional outputs. I have attached the information from the terminal and the output. Are these outputs appropriate to find the scaling information? If so, where can I find it? I am not very familiar with transformations, thus any information or directions to resources I can use would be very much appreciated. Thank you in advance for you help. Best, Tamara Message: 6 Date: Tue, 10 Jan 2017 21:18:34 +0100 From: Martin Reuter <mreuter(a)nmr.mgh.harvard.edu> Subject: Re: [Freesurfer] Brighter image at baseline vs. follow up using longitudinal processing stream To: Freesurfer support list <freesurfer(a)nmr.mgh.harvard.edu> Message-ID: <9BCB373D-D368-4B36-B607-69E6A14AF952(a)nmr.mgh.harvard.edu> Content-Type: text/plain; charset="us-ascii" Hi Tamara, mvoing in and popping out sounds like a scaling problem. We do only rigid transforms, so the scaling would already be in your original inputs. If that is the case, it could mean that there was a scanner calibration or something that caused scaled images and that would not be good. It should however appear in all images that have the calibration in between time points. You can try to use mri_robust_register with the affine flag to see if any scaling is present in the rawavg.mgz images between the two time points (it should report scaling separately on the screen output), else use lta_diff with the appropriate flags. You can also look at the affininely registered images and see if it looks better. Anyway if there is global scaling in the images, I would try to investigate a where this comes from and also drop that image from the study. Best, Martin

2 2

createMorph & applyMorph: unexpected results
by Stefano Zappalà 16 Jan '17

16 Jan '17

Hello FreeSurfer Developers, I'm attempting to apply the CVS output transformation "final_CVSmorph_toSynthF.m3z" to an image different to the one that was used for its estimation. I followed the steps reported at the bottom of the page https://surfer.nmr.mgh.harvard.edu/fswiki/mri_cvs_register, adjusting the lines for the output files that I obtained from mri_cvs_register. So I called for createMorph --out fullCVSmorph.tm3d --template MniNick.mgz --subject w_MniNick.mgz --in gcam final_CVSmorph_toSynthF.m3z morph el_reg_toSynthF.mgz and applyMorph --template MniNick.mgz --transform fullCVSmorph.tm3d vol w_MniNick.mgz outputvol.nii trilinear but I encountered the following output when running createMorph: setting orig areas to linear transform determinant scaled 1.00 atlas geometry = 256 , 256 , 256 image geometry = 256 , 256 , 256 vox 2 ras atlas = -1.00000 0.00000 0.00000 127.00000; 0.00000 0.00000 1.00000 -145.00000; 0.00000 -1.00000 0.00000 147.00000; 0.00000 0.00000 0.00000 1.00000; ras 2 vox image = -1.00000 -0.00000 -0.00000 90.00000; -0.00000 1.00000 -0.00000 126.00000; -0.00000 -0.00000 1.00000 72.00000; -0.00000 -0.00000 -0.00000 1.00000; product = 1.00000 0.00000 0.00000 -37.00000; 0.00000 0.00000 1.00000 -19.00000; 0.00000 -1.00000 0.00000 219.00000; 0.00000 0.00000 0.00000 1.00000; transform at origin -37.00000; -19.00000; 219.00000; 1.00000; invalid voxel count = 0 extension = mgz terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted (core dumped) I've searched the mailing list and no similar errors have been reported. The recon-all and mri_cvs_register calls seemed to have correctly terminated. Does anyone have any thoughts on how to trouble-shoot this one? 1) FreeSurfer version: freesurfer-Linux-centos6_x86_64-dev-20161130-24fa2c9 2) Platform: ubuntu 16.04 LTS 3) In the attachment: 3.1) log files of the mri_cvs_register execution; 3.2) log file of the recon-all executions on the moving and fixed images. Thank you for your consideration. Stefano.

2 2

3d brush in freeview
by Chris Adamson 15 Jan '17

15 Jan '17

Is there a 3d option for the editing brush in freeview ala tkmedit? Dr Chris Adamson Senior Research Officer Developmental Imaging, Clinical Sciences Murdoch Childrens Research Institute The Royal Children's Hospital Flemington Road, Parkville, VIC 3052 Australia E chris.adamson(a)mcri.edu.au<mailto:chris.adamson@mcri.edu.au> www.mcri.edu.au<http://www.mcri.edu.au/> This e-mail and any attachments to it (the "Communication") are, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Murdoch Childrens Research Institute (MCRI) ABN 21 006 566 972 or any of its related entities. MCRI does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication. P Please consider the environment before printing this email ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________

1 0

ribbon volumes
by Zhivago 15 Jan '17

15 Jan '17

Hi, Are the lh.ribbon & rh.ribbon volumes the GM estimate from reconall? Can I used these as GM voxels? Thanks, Zhivago...

3 2

Re: [Freesurfer] Reviewer questions...
by Antonin Skoch 13 Jan '17

13 Jan '17

Dear Jerome, I think I could chime in with my opinion: The Schoemaker et al paper results are based on hippocampus/amygdala segmentations in FreeSurfer 4.4. Hippocampal subfields segmentation module from development version you used should be more precise than 4.4. version and also the anatomical landmarks are well specified in paper Iglesias et al, 2015: https://www.ncbi.nlm.nih.gov/pubmed/25936807 I think this paper can be used as a good basis for arguments to your reviewer. Concerning the reliability of estimation of particular hippocampal subfields, I think it also depend on what resolution was your input images, and whether you used additional high-resolution T2. The effect of various image resolution on the reliability of results is also well discussed in above-mentioned paper I think. Regards, Antonin Skoch

3 2

surface based analysis (projfrac)
by John Anderson 13 Jan '17

13 Jan '17

3 11

QDEC table import issue
by Paul Rowley 13 Jan '17

13 Jan '17

Good morning, I’m experiencing issues importing data into QDEC. When I upload the table, this is the error I receive: Loading data table /Applications/freesurfer/subjects/qdec/qdec.table.dat... Number of columns: 10 fsid column: 1 Number of factors: 9 Number of subjects: 19 ERROR: QdecSubject::GetContinuousFactor failure: could not find factor name: L_temporalpole_thickavg for subject NV_002_V1 I’ve attached the table and would greatly appreciate any advice on resolving this issue. Thanks in advance for your help, Paul

2 2

Re: [Freesurfer] Brighter image at baseline vs. follow up using longitudinal processing stream
by Tamara Tavares 13 Jan '17

13 Jan '17

Hi Martin, Thank you for the clarification. I assume this participant should be removed? As a rule of thumb, should I exclude participants who have a total of 3% scaling? Is there a way to check potential scaling problems (e.g. looking into the recon-all.log to see scaling or checking alignment between the longitudinal time points)? Thank you again for your help. Best, Tamara Message: 7 Date: Thu, 12 Jan 2017 16:20:11 +0100 From: Martin Reuter <mreuter(a)nmr.mgh.harvard.edu> Subject: Re: [Freesurfer] Brighter image at baseline vs. follow up using longitudinal processing stream To: Freesurfer support list <freesurfer(a)nmr.mgh.harvard.edu> Message-ID: <2D4D7B7C-9915-454C-9A41-AA9FDE9D3C46(a)nmr.mgh.harvard.edu> Content-Type: text/plain; charset="us-ascii" Hi Tamara, that information is in the screen output: Determinant : 1.03358 also Scale = diag([ 1.0109774487584 1.0113715685396 1.0108915357302 ]) so it finds some scaling (approx 1% in each axis direction, so a total of 3%). This can happen in individual cases, but if it is consistent I would be worried. Best, Martin > On 11 Jan 2017, at 21:21, Tamara Tavares <ttavare(a)uwo.ca> wrote: > > Hi Dr. Reuter. > > Thank you again for your help. > > I ran the following command: "mri_robust_register --mov rawavg_1.mgz --dst rawavg_2.mgz --lta v1to2.lta --affine --satit" on the two rawavg.mgz images; one from each time point from the cross-sectional outputs. I have attached the information from the terminal and the output. Are these outputs appropriate to find the scaling information? If so, where can I find it? I am not very familiar with transformations, thus any information or directions to resources I can use would be very much appreciated. > > Thank you in advance for you help. > > Best, > Tamara

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
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