Freesurfer

freesurfer@nmr.mgh.harvard.edu

21 participants
30070 discussions

Control point in WM regions
by Shane Schofield 17 Apr '17

17 Apr '17

Hello Freesurfer Team, I am trying to recover thin WM strands in the temporal lobe by using control points but to no avail (screenshot) Any suggestions please? These regions also appear to be classified as WM (wm.mgz) but why are the surfaces inaccurate? Thanks for your help. Best Wishes,Shane

1 0

ERROR
by Damien MARIE 17 Apr '17

17 Apr '17

Hi, Just a follow-up about the message I posted. Problem is solved. I just moved freesurfer/ outside of the Applications folder (from /Users/me/Applications/freesurfer to /Users/me/freesurfer ). So now I can work with my macbook on subjects previously processed with another system. Probably an issue with mac os (10.11.6 ?) and copy pasting files in a subdirectory of the Applications folder… Thanks, Damien _______________________________________________ Damien MARIE <http://www.mail-archive.com/search?l=freesurfer@nmr.mgh.harvard.edu&q=from:…> Sat, 15 Apr 2017 06:22:31 -0700 <http://www.mail-archive.com/search?l=freesurfer@nmr.mgh.harvard.edu&q=date:…> Hi, I ran recon-all on a server where Ubuntu is running. Recently I installed separately freesurfer on a macbook, it is working (e.g. tkmedit bert), I moved my processed subjects to freesurfer/subjects on the macbook but I can not work with them. I have the below error. I changed the permission to 777, it is still not working. Now what is really strange is that, using the finder I do not see the files in freesurfer/subjects but by doing ls -l in a terminal, I can see them… Please note that SUBJECT_DIR is defined. Any idea is welcome. Thank you and best, Damiens-MacBook-Pro-2:subjects dmarie2$ tkmedit hires_ct_pp1_N4_bet_MP2RAGEcorr/ brainmask.mgz -aux T1.mgz ERROR: cannot find subject hires_ct_pp1_N4_bet_MP2RAGEcorr/ in /Applications/freesurfer/subjects or it is not readable by you Damien _______________________________________________

1 0

Corrupted annot file
by Das S. 16 Apr '17

16 Apr '17

Hi, I have created an .annot file from label files using mris_label2annot command. mris_label2annot --s 100307 --h lh --no-unknown --ctab 100307/label/eq_parcellation_ label/MyColorLUTnew.txt --a eqnew40aparc --ldir 100307/label/eq_parcellation_label/ Then I have created a .gcs file from the above .annot file. mris_ca_train -t 100307/label/eq_parcellation_label/MyColorLUT.txt lh 100307/surf/lh.sphere.reg 100307/label/lh.left40aparc.annot 100307 100307/label/lh.reg40aparc.gcs Then from the .gcs file I have another .annot file. mris_ca_label -l 100307/label/lh.cortex.label -aseg 100307/mri/aseg.presurf.mgz 100307 lh 100307/surf/lh.sphere.reg 100307/label/lh.eqnew40aparc.gcs 100307/label/lh.aparc.annot The 2nd annot file is corrupted and showing a big gray patch.While checking the annotation file in matlab, found that the those vertex on the .annot file were not assigned any colorcode from colortable. Here is the content of MyColorLUTnew.txt: 0 unknown 1 1 1 0 1 node1 70 130 180 0 2 node2 245 245 245 0 3 node3 205 62 78 0 4 node4 120 18 134 0 5 node5 196 58 250 0 6 node6 0 148 0 0 7 node7 220 248 164 0 8 node8 230 148 34 0 9 node9 0 118 14 0 10 node10 70 118 14 0 11 node11 122 186 220 0 12 node12 236 13 176 0 13 node13 12 48 255 0 14 node14 204 182 142 0 15 node15 42 204 164 0 16 node16 119 159 176 0 17 node17 220 216 20 0 18 node18 103 255 255 0 19 node19 80 196 98 0 20 node20 60 58 210 0 21 node21 160 58 210 0 22 node22 120 58 210 0 23 node23 40 58 210 0 24 node24 60 120 60 0 25 node25 255 100 0 0 26 node26 250 165 0 0 27 node27 0 255 127 0 28 node28 165 42 42 0 29 node29 135 206 235 0 30 node30 160 32 240 0 31 node31 0 200 200 0 32 node32 100 50 100 0 33 node33 135 50 74 0 34 node34 122 135 50 0 35 node35 51 50 135 0 36 node36 74 155 60 0 37 node37 120 62 43 0 38 node38 74 155 60 0 39 node39 122 135 50 0 40 node40 70 130 180 0 Any help will be much appreciated, why the file is getting corrupted in the 2nd step? Thanks Sarbani

2 1

Missing S_interm_prim-Jensen??
by Kevin Japardi 16 Apr '17

16 Apr '17

Hello Freesurfer group, I'm going through my Destrieux Atlas data (?h.aparc.a2009s.annot), with a total group N of 91, and there is a single person without a row for S_interm_prim-Jensen for Left Hemisphere ONLY. Any thoughts on why this would be? I reran recon-all with autorecon3, seeing as the file is created during this stage block. The issue unfortunately didn't resolve itself. Any feedback would be greatly appreciated. Find it odd. Everyone was run using the same Freesurfer version and around the same month/ish. Thank you! Kevin Japardi

2 1

Ascii file of thickness overlay with vertex index and coordinates
by Michael Kranz 16 Apr '17

16 Apr '17

Hi, I was wondering how I would go about getting the vertex index and coordinates in one ascii file for a thickness overlay file. With mri_convert using the --asci+crsf option it outputs the vertex index only. Now I want to get the coordinates of each index...Is this possible? I may be misunderstanding something.... Could this info be extracted with converting a surface (e.g., inflated) with mris_convert? If so, where can I find info on how to read the ascii surface files. In other words, what I'm trying to do is for each vertex: <vertex index> <vertex coordinate x> <vert coord y> <vert coord z> <thickness intensity> Best, Mike -- Michael Kranz Graduate Research Assistant |Beckman Institute University of Illinois 314-323-1329

2 1

New to freesurfer Needhelp to install in Ubuntu 16 lts
by Ramesh Babu 15 Apr '17

15 Apr '17

Dear Expert, I am new member of this freesurfer mailing list. I just downloaded freesurfer package and installed in /usr/local/freesurfer. I am trying to follow the command given in the freesurfer web page. $> export FREESURFER_HOME=/usr/local/freesurfer $> source $FREESURFER_HOME/SetUpFreeSurfer.sh But I could not figure out the .sh file in the freesurfer folder. Instead there is .csh file. Can I change it as "$> source $FREESURFER_HOME/SetUpFreeSurfer.csh". Since I have started using Ubuntu recently, I am not not sure whether I can change it. Need your help to install freesurfer in my pc. Thanks in advance Ramesh

2 2

Problem with TR and FS-FAST (fcMRI)
by stdp82＠virgilio.it 14 Apr '17

14 Apr '17

Hi list,for some subjects fcMRI with FS-FAST produce the error reported below.I'm sure that the TR is 3.0 s, as well as for the subjects that are running correctly . Which is the cause of this inconsistency?ThanksStefano ERROR: TR mismatch between analysis and data analysis TR = 3, data TR = 43.01 ans = 1 >> ------------------------------------------

1 0

freesurfer 6 hippocampal longitudinal processing workflow question, more LH than RH files
by Salil Soman 13 Apr '17

13 Apr '17

Hi, I have run a number of cases through the FS6 hippocampal longitudinal processing steps listed at https://surfer.nmr.mgh.harvard.edu/fswiki/LongitudinalHippocampalSubfields and https://surfer.nmr.mgh.harvard.edu/fswiki/LongitudinalProcessing It seems that all steps completed, but when it came time to collect the results, I find I have many more lh.hippoSfVolumes-T1.long.v10.txt (67) than rh.hippoSfVolumes-T1.long.v10.txt files (25). Any suggestions on what I may be doing incorrectly? Thanks! Salil Soman

1 0

Re: [Freesurfer] Fwd: wm edits not incorporated
by Antonin Skoch 13 Apr '17

13 Apr '17

Dear Octavian, the current philosophy with wm.mgz edits is not to directly affect voxel values in original T1 image. The wm.mgz serves as starting point for the white surface estimation. The ?h.white surface is estimated according gradient in voxel values in brain.finalsurfs.mgz (which is, basically, preprocessed T1 image) using basically preprocessed surfaces obtained from wm.mgz (?h.orig) as a starting position where to search for intensity gradient. The editing of wm.mgz helps to find out the GM/WM itensity gradient and properly place ?h.white there. Therefore, where there is insufficient GM/WM contrast, the wm.mgz cannot help out. I think that there is no change in the behavior between v5.3 and v6.0 in this aspect. I have seen many cases where wm.mgz edit does not help to improve ?h.white surfaces in the data processed by v5.3. There is an -overlay option in mris_make_surfaces which explicitly modifies voxel values in input image for mris_make_surfaces (brain.finalsurfs.mgz as default in recon-all). However, this option only works for cases when wm.mgz is extended, not deleted: In voxels which have value 255 in wm.mgz, it replaces current voxel value in input image by desired value of white matter. This option is currently not used in recon-all. I would opt for implementation of similar option for deletion of voxels in wm.mgz: Where wm.mgz voxel values equal 1, to replace input image voxel values by desired values of GRAY matter. This should force ?h.white to directly follow edits of wm.mgz As for editing of 001.mgz, beware the pitfall with editing images with mutually different geometry in FreeView I posted today: http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52729.html Antonin Skoch Dear All, Regarding wm.mgz edits not incorporated into wm surface, which seems to have been reported on by several of us with FS 6.00. I followed Antonin's idea of editing 001.mgz by switching wm-intensity voxels clearly not wm (mostly in the subtemporal regions, at times close to bright dural portions in the crown) to gm intensities and ran recon-all -all, and this time all was OK. So it seems that the problem is that on re-initializing during -autorecon2-wm rerun, the routine does not edit out high intensity voxels even if manually excluded in wm.mgz. This seems to be different to some extent with how FS 5.3 was reacting, although I did not look at this systematically. There may be a reason that manual editing is just part of the story during rerun and does not automatically override the recon stream, but I do not know it. Octavian ---------- Forwarded message ---------- From: Octavian Lie <octavian....(a)gmail.com> Date: Sun, Apr 2, 2017 at 7:59 PM Subject: wm edits not incorporated To: octavian lie <octavian....(a)gmail.com> Dear Bruce, I just transferred subject r02.tar.gz. Again, wm.mgz edits (all deleted voxels, no additions) are not incorporated on reruns using any of the recon-all -autorecon-wm -aitorecon3 recon-all -autorecon2 -autorecon3 recon-all -make all FOr example, the complete command line for a rerun is recon-all -autorecon2-wm -autorecon3 -3T -bigventricles -cw256 -subjid r02 -parallel > output.txt & Here are some of the edited voxels which are not excluded from the wm on rerun: -40.14, -2.67, 116.29 coronal slice 132 12.73, -23.67, 126.16 coronal slice 171 14.05, 12.33, 11.61 coronal slice 147

2 1

Re: [Freesurfer] Freeview - corrupted pixel values after saving volume (via save as) when images with mutually different geometry are simultaneously loaded
by Antonin Skoch 13 Apr '17

13 Apr '17

Dear Ruopeng, thank you for the feedback. Yes, the behavior is exacly like you described. I suspected that this has something to do with resampling but I was not sure. The stripes were result of nearest-neighbor interpolation. Antonin Hi Antonin, When you load two images like that, the second image will be resampled, using nearest neighbor method by default. And when you save, it will be resampled back to its original space. So there will be shifted voxels depending how oblique it is to the first image. So I think what you observe makes sense. That is also why you should always edit volumes in their local space. I didn't find any screenshots in your last email but my guess is the oblique strip is due to nearest neighbor resampling. You can choose "-trilinear" or "-cubic" in the command line when you load the images. Best, Ruopeng On 04/13/2017 12:28 PM, Antonin Skoch wrote: Dear experts, I encountered following issue with freeview: When two images with mutually different geometry are simultaneously loaded and one of them is saved (via save as), its pixel values get somewhat corrupted. There are strips in image with modified pixel values. It seems to affect only the latter image in the pair. Example (001.mgz and brainmask.mgz have different geometry): freeview brainmask.mgz orig/001.mgz Then I saved 001.mgz as 001_2.mgz (using "save as") and loaded 001_2.mgz to freeview. The attached screenshots show original 001.mgz and 001_2.mgz with corrupted pixels. Note new oblique strips. This is not only display issue. The mri_diff 001.mgz 001_2.mgz outputs: diffcount 287447 Volumes differ in pixel data maxdiff 966.00000000 at 171 255 30 0 I am using recent development version of freesurfer from 04/2017. Regards, Antonin Skoch

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