Freesurfer

freesurfer@nmr.mgh.harvard.edu

14 participants
30083 discussions

qdec and left mouse button
by Michael Harms 11 Dec '08

11 Dec '08

Hello, In the QDEC in the current FS distribution (v4.1.0), attempting to rotate the surface (via left mouse button) automatically also opens the scatterplot of the individual values at the vertex where you clicked (or an empty plot if you click in the background). Is there a way to turn off this behavior, so that one can simply rotate the surface without the scatterplot opening and obscuring the screen? In the QDEC with previous FS versions (e.g., v4.0.2), one had to do Control+left mouse to get the scatterplot (which was fine by me)... cheers, Mike H. -- Michael Harms, Ph.D. -------------------------------------------------------------------- Conte Center for the Neuroscience of Mental Disorders Washington University School of Medicine Department of Psychiatry, Box 8134 Renard Hospital, Room 6615 Tel: 314-747-6173 660 South Euclid Ave. Fax: 314-747-2182 St. Louis, MO 63110 Email: mharms(a)wustl.edu --------------------------------------------------------------------

2 1

Fwd: HELP!
by Saud Alhusaini 11 Dec '08

11 Dec '08

---------- Forwarded message ---------- From: <freesurfer-owner(a)nmr.mgh.harvard.edu> Date: Wed, Dec 10, 2008 at 4:08 PM Subject: HELP! To: saud.alhusaini(a)gmail.com You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at freesurfer-owner(a)nmr.mgh.harvard.edu. ---------- Forwarded message ---------- From: "Saud Alhusaini" <saud.alhusaini(a)gmail.com> To: freesurfer(a)nmr.mgh.harvard.edu Date: Wed, 10 Dec 2008 16:07:57 +0000 Subject: HELP! Hi, I have been trying to install the latest version of FreeSurfer. I was able to follow the steps as outlined in FS wiki website. I had a problem however when I wanted to test the installation. I typed in the command: tkmedit bert orig.mgz (as recommended) - after setev SUBJECTS_DIR I kept getting the following error line: tkmedit.bin: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Can you please help me. Regards, Saud

2 1

qcache error and recon-all -make all
by Burmicz, Ryzarda 11 Dec '08

11 Dec '08

Hello, When running recon-all -qcache -s <subject> with a view to running qdec analyses I get the following error message, which I think I understand, however I am having trouble with the -make all option of recon-all that is recommended in a previous thread: "Reading curvature file /PICKACARDB01/surf/lh.jacobian_white ERROR: number of vertices in /PICKACARDB01/surf/lh.jacobian_white does not match surface (150934, 150818) ERROR: reading curvature file recon-all exited with ERRORS at Tue Dec 9 ..." This subject was originally run on 4.0.1 (Linux-centos4_x86_64 version) And then corrected and rerun on 4.0.3 (Linux-centos4_x86_64 version) (I understand that this is not always a good thing to do rerunning on a different version so don't know if this has anything to do with it..). I think I am correct in saying that they problem might be due to rerunning portions of recon-all (in this case we reran from -autorecon2-wm to correct a wm error) such that the new surface vertices do not match such that the lh.jacobian_white file in this case is now invalid. My query is as follows: I have experimented with running "recon-all -s <subject> -make all" to fix the above problem but it seems to be going through the entirety of the recon-all processing stream... I thought it only ran the parts that were missing, or in the case that dependency files are older than a particular file. Have I misunderstood this flag, or is it running through the whole of recon-all simply because we are running it on 4.0.3, so it is updating all of the recon-all files up to autorecon2-wm that were created from version 4.0.1? It is interesting that the error happens in this case only on the jacobian_white surface, in other subjects it has occurred for all smoothing surface files on a single hemisphere (.e.g. volume, sulc, curv, thickness, jacobian_white ..) and in many just the .volume files are missing... it is confusing. Naturally I would love to avoid reprocessing these subjects from scratch! But I can see how this might not be possible. Thanks very much for your time, Rysia

2 1

RE: qcache error and recon-all -make all
by Burmicz, Ryzarda 11 Dec '08

11 Dec '08

Hello, I forgot to mention another query regarding recon-all -make all: If I do end up running this command on the subjects that fail the qcache processing (so effectively rerunning the whole recon-all stream), will any edits I have made to fix errors (such as control points, wm.mgz edits and pial edits) be erased, or will they be incorporated into the new reconstruction? Many thanks (again), Rysia From: Burmicz, Ryzarda Sent: 11 December 2008 15:19 To: 'freesurfer(a)nmr.mgh.harvard.edu' Cc: Santo, Susan Subject: qcache error and recon-all -make all Hello, When running recon-all -qcache -s <subject> with a view to running qdec analyses I get the following error message, which I think I understand, however I am having trouble with the -make all option of recon-all that is recommended in a previous thread: "Reading curvature file /PICKACARDB01/surf/lh.jacobian_white ERROR: number of vertices in /PICKACARDB01/surf/lh.jacobian_white does not match surface (150934, 150818) ERROR: reading curvature file recon-all exited with ERRORS at Tue Dec 9 ..." This subject was originally run on 4.0.1 (Linux-centos4_x86_64 version) And then corrected and rerun on 4.0.3 (Linux-centos4_x86_64 version) (I understand that this is not always a good thing to do rerunning on a different version so don't know if this has anything to do with it..). I think I am correct in saying that they problem might be due to rerunning portions of recon-all (in this case we reran from -autorecon2-wm to correct a wm error) such that the new surface vertices do not match such that the lh.jacobian_white file in this case is now invalid. My query is as follows: I have experimented with running "recon-all -s <subject> -make all" to fix the above problem but it seems to be going through the entirety of the recon-all processing stream... I thought it only ran the parts that were missing, or in the case that dependency files are older than a particular file. Have I misunderstood this flag, or is it running through the whole of recon-all simply because we are running it on 4.0.3, so it is updating all of the recon-all files up to autorecon2-wm that were created from version 4.0.1? It is interesting that the error happens in this case only on the jacobian_white surface, in other subjects it has occurred for all smoothing surface files on a single hemisphere (.e.g. volume, sulc, curv, thickness, jacobian_white ..) and in many just the .volume files are missing... it is confusing. Naturally I would love to avoid reprocessing these subjects from scratch! But I can see how this might not be possible. Thanks very much for your time, Rysia

2 1

spatial AR1
by Michael Harms 11 Dec '08

11 Dec '08

Hello, What is the role of the spatial AR1 that is automatically computed as part of a QDEC analysis? thanks, Mike H. -- Michael Harms, Ph.D. -------------------------------------------------------------------- Conte Center for the Neuroscience of Mental Disorders Washington University School of Medicine Department of Psychiatry, Box 8134 Renard Hospital, Room 6615 Tel: 314-747-6173 660 South Euclid Ave. Fax: 314-747-2182 St. Louis, MO 63110 Email: mharms(a)wustl.edu --------------------------------------------------------------------

2 1

LGI question
by Tricia Merkley 11 Dec '08

11 Dec '08

Hi, Would there need to be any special considerations when calculating lgi with microcephalic brains? Could TIV ever affect the results and need to be accounted for? (It doesn't seem like it should, but just wanted to verify.) Thanks, Tricia Merkley

2 1

qdec bug
by Michael Harms 11 Dec '08

11 Dec '08

Hello, I've noticed a behavior in QDEC (v1.1 under FS v4.1.0) that appears to be a bug regarding the "slopes" output to the terminal, and the corresponding regression lines displayed in the scatterplot, when using more than one continuous covariate. I ran an analysis on cortical thickness on a group of patients using just age and duration of illness as continuous covariates (and listed in that order on the 'Design' tab). Looking at the map for "Does the correlation between thickness and age, accounting for duration_of_illness, differ from zero?", the blue blobs are reported to have negative slopes, and the red blobs have positive slopes, as expected. (This is based on the slope reported to the terminal, as well as the physical slope of the dashed regression line in the scatterplot when I click on a vertex). However, looking at the map for "Does the correlation between thickness and duration_of_illnes, accounting for age, differ from zero?", I found that when I clicked on a vertex in a blue blob the slope reported to the terminal was usually POSITIVE. That is, vertices in blue blobs in this case typically have a slope REPORTED as positive, ACCORDING to the output to the terminal as well as the slope of the regression line in the scatterplot. And vice-versa for vertices in red blobs. Upon further investigation it appears that the bug is that the output to the terminal, and the regression line in the scatterplot, are using the slope value from the first of the two continuous variables regardless of which correlation is actually selected as the active map. An analogous bug exists if you add a class variable to the mix. That is, the "slopes" output to the terminal for each class (using DODS), and used in the regression line of the scatterplot, are from the first of the two continuous variables, regardless of the active map. cheers, -Mike H. P.S. In the process of this, I found stumbled across the following: If you use the "Subject Exclusions" feature to exclude some subjects based on a discrete (class) variable, and attempt to run a DOSS analysis using a different discrete factor in combination with two continuous covariates, Qdec crashes with the following message: *** glibc detected *** free(): invalid next size (fast): 0x11303558 *** Abort But, if you attempt a DOSS analysis using just one of the two continuous covariates instead, no problem... -- Michael Harms, Ph.D. -------------------------------------------------------------------- Conte Center for the Neuroscience of Mental Disorders Washington University School of Medicine Department of Psychiatry, Box 8134 Renard Hospital, Room 6615 Tel: 314-747-6173 660 South Euclid Ave. Fax: 314-747-2182 St. Louis, MO 63110 Email: mharms(a)wustl.edu --------------------------------------------------------------------

1 0

Discrepancy between sig.nii and .w files
by Jesse Friedman 11 Dec '08

11 Dec '08

Hi, I'm using paint-sess to create .w files from a contrast's sig map (I need the .w files for use with MNE). When I view the sig.nii file in tksurfer, the activation differs subtly but noticeably from the .w files. For example, I'll run a command like: paint-sess -analysis EC -contrast eVc -offset 5 -s subjects/RMCON005 When I load RMCON005/bold/EC/eVc/sig-5-lh.w into tksurfer, the activation is slightly different than when I load RMCON005/bold/EC/eVc/sig.nii and view that hemisphere at that offset. Is this discrepancy to be expected? If so, is there a way to create .w files that have identical activation to the sig.nii file? -- Jesse Friedman, B.A. Massachusetts General Hospital Martinos Center, Manoach Lab Psychiatric Neuroimaging 149 13th Street #2613 Charlestown, MA 02129 Phone: (617) 726-1908 Fax: (617) 726-4078 jessef(a)nmr.mgh.harvard.edu

2 1

Problem with mri_ca_train
by Jason S. Minamora 10 Dec '08

10 Dec '08

Hello, I asked about this issue about a month ago, but haven't gotten a response. I'm trying to build a new GCA using the rebuild_gca_atlas.csh script, with checking disabled (no `-check' flag). My subjects are completely acallosal, and each of the edited segmentation volumes that the script wants (seg_edited.mgz) were created by converting the corresponding aseg.mgz to one-file gzipped NIFTI (aseg.nii.gz), "stamping" manually-labeled ventricle masks on it, with the command fslmaths aseg.nii.gz -mul left-lat-inverse-mask.nii.gz -mul right-lat-inverse-mask.nii.gz -add left-lat-mask-4.nii.gz -add right-lat-mask-43.nii.gz seg_edited.nii.gz (here "4" and "43" mean that each of the *-lat-mask-* files contain voxels with the respective value, based on the entries in FreeSurferColorLUT.txt) and finally converting the edited segmentation volume back to MNI format with `mri_convert -odt uchar -ns 1 seg_edited.nii.gz seg_edited.mgz'. I then copied the seg_edited.mgz into $SUBJECTS_DIR/<subj-id>/mri, and embedded the talairach transformation matrix in it using `mri_add_xform_to_header transform/talairach.xfm seg_edited.mgz'. The first stage of the script worked OK, but the second stage (which includes a call to mri_ca_train), didn't finish: ============ mri_ca_train using all subjects, using talairach_one.m3z, producing /Users/j sm/work/subjects/average/RB_all_2008-12-10.gca... reading input 0: /Users/jsm/work/subjects/a36/mri/norm.mgz spacing priors every 2.0 mm spacing nodes every 4.0 mm using MR volume brain.mgz to mask input volume... reading segmentation from subject's mri/seg_edited.mgz directory reading xform from talairach_one.m3z reading T1 data from subject's mri/norm.mgz directory training on 5 subject and writing results to /Users/jsm/work/subjects/averag e/RB_all_2008-12-10.gca *************************************************************************** processing subject a36, 1 of 5... reading volume /Users/jsm/work/subjects/a36/mri/brain.mgz for masking... gunzip -c /Users/jsm/work/subjects/a36/mri/transforms/talairach_one.m3z reading input 0: /Users/jsm/work/subjects/A59/mri/norm.mgz 15129 prior holes filled *************************************************************************** processing subject A59, 2 of 5... reading volume /Users/jsm/work/subjects/A59/mri/brain.mgz for masking... gunzip -c /Users/jsm/work/subjects/A59/mri/transforms/talairach_one.m3z reading input 0: /Users/jsm/work/subjects/f10/mri/norm.mgz 15304 prior holes filled *************************************************************************** processing subject f10, 3 of 5... reading volume /Users/jsm/work/subjects/f10/mri/brain.mgz for masking... gunzip -c /Users/jsm/work/subjects/f10/mri/transforms/talairach_one.m3z reading input 0: /Users/jsm/work/subjects/f18/mri/norm.mgz 851 prior holes filled *************************************************************************** processing subject f18, 4 of 5... reading volume /Users/jsm/work/subjects/f18/mri/brain.mgz for masking... gunzip -c /Users/jsm/work/subjects/f18/mri/transforms/talairach_one.m3z reading input 0: /Users/jsm/work/subjects/f20/mri/norm.mgz 36063 prior holes filled *************************************************************************** processing subject f20, 5 of 5... reading volume /Users/jsm/work/subjects/f20/mri/brain.mgz for masking... gunzip -c /Users/jsm/work/subjects/f20/mri/transforms/talairach_one.m3z GCAupdateNodeCovariance(21, 33, 6, 42): could not find label ================= This problem _doesn't_ occur when I only use one subject. Any advice? Thanks, Jason

2 4

I cannot get tutorial data
by 卯野賢太 10 Dec '08

10 Dec '08

Hi, Mr. and Mrs I want Tutorial file of fsfast. But I didin't get it from the following pass. ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/fsfast-tutori… If you know about that please let me know. Thank you for your help. Best regards, Kenta

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