Freesurfer May 2013

freesurfer@nmr.mgh.harvard.edu

174 participants
299 discussions

Re: [Freesurfer] error loading volume brainmask.gcut.mgz
by Claudia Dacquino 30 May '13

30 May '13

Yes I did run mri_info, these are the results: Volume information for brainmask.gcuts.mgz type: MGH dimensions: 256 x 256 x 256 voxel sizes: 1.0000, 1.0000, 1.0000 type: INT (1) fov: 256.000 dof: 0 xstart: -128.0, xend: 128.0 ystart: -128.0, yend: 128.0 zstart: -128.0, zend: 128.0 TR: 7.92 msec, TE: 0.00 msec, TI: 0.00 msec, flip angle: 0.00 degrees nframes: 1 PhEncDir: UNKNOWN ras xform present xform info: x_r = -1.0000, y_r = 0.0000, z_r = -0.0000, c_r = 8.4909 : x_a = -0.0000, y_a = 0.0000, z_a = 1.0000, c_a = -0.4031 : x_s = 0.0000, y_s = -1.0000, z_s = -0.0000, c_s = -34.1638 talairach xfm : Orientation : LIA Primary Slice Direction: coronal voxel to ras transform: -1.0000 0.0000 -0.0000 136.4909 -0.0000 0.0000 1.0000 -128.4031 0.0000 -1.0000 -0.0000 93.8362 0.0000 0.0000 0.0000 1.0000 voxel-to-ras determinant -1 ras to voxel transform: -1.0000 -0.0000 -0.0000 136.4909 -0.0000 -0.0000 -1.0000 93.8362 -0.0000 1.0000 -0.0000 128.4031 0.0000 0.0000 0.0000 1.0000 Cheers 2013/5/30 Claudia Dacquino <claudia.dacquino(a)gmail.com> > Yes I did run mri_info, these are the results: > > Volume information for brainmask.gcuts.mgz > type: MGH > dimensions: 256 x 256 x 256 > voxel sizes: 1.0000, 1.0000, 1.0000 > type: INT (1) > fov: 256.000 > dof: 0 > xstart: -128.0, xend: 128.0 > ystart: -128.0, yend: 128.0 > zstart: -128.0, zend: 128.0 > TR: 7.92 msec, TE: 0.00 msec, TI: 0.00 msec, flip angle: 0.00 > degrees > nframes: 1 > PhEncDir: UNKNOWN > ras xform present > xform info: x_r = -1.0000, y_r = 0.0000, z_r = -0.0000, c_r = > 8.4909 > : x_a = -0.0000, y_a = 0.0000, z_a = 1.0000, c_a = > -0.4031 > : x_s = 0.0000, y_s = -1.0000, z_s = -0.0000, c_s = > -34.1638 > > talairach xfm : > Orientation : LIA > Primary Slice Direction: coronal > > voxel to ras transform: > -1.0000 0.0000 -0.0000 136.4909 > -0.0000 0.0000 1.0000 -128.4031 > 0.0000 -1.0000 -0.0000 93.8362 > 0.0000 0.0000 0.0000 1.0000 > > voxel-to-ras determinant -1 > > ras to voxel transform: > -1.0000 -0.0000 -0.0000 136.4909 > -0.0000 -0.0000 -1.0000 93.8362 > -0.0000 1.0000 -0.0000 128.4031 > 0.0000 0.0000 0.0000 1.0000 > > Cheers > > > 2013/5/30 Bruce Fischl <fischl(a)nmr.mgh.harvard.edu> > >> did you run out of disk space? Can you run mri_info on it? >> On Thu, 30 May 2013, Claudia Dacquino wrote: >> >> Hi Freesurfers,I'm trying to remove some dura which affect my surfaces >>> with >>> >>> the command >>> >>> recon-all -skullstrip -clean-bm -gcut -subjid >>> >>> but then I can't use tkmedit to check that. >>> The message I get is: >>> >>> Error: Loading volume brainmask.gcut.mgz Couldn't read the anatomical >>> volume. Tkmedit couldn't read the volume you specified. This could be >>> because the image format wasn't recognized, or it couldn't find the >>> proper >>> header, or the file(s) were unreadable, or it was the wrong size. >>> >>> Actually I did check in brainmask.gcut.mgz directory properties, and I >>> saw >>> the size of image is something like 150 KB, instead of 1 MB like is >>> brainmask.mgz. >>> >>> What is the problem? >>> >>> Thanks, >>> Claudia >>> >>> >>> >> >> 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<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

error loading volume brainmask.gcut.mgz
by Claudia Dacquino 30 May '13

30 May '13

Hi Freesurfers, I'm trying to remove some dura which affect my surfaces with the command recon-all -skullstrip -clean-bm -gcut -subjid but then I can't use tkmedit to check that. The message I get is: Error: Loading volume brainmask.gcut.mgz Couldn't read the anatomical volume. Tkmedit couldn't read the volume you specified. This could be because the image format wasn't recognized, or it couldn't find the proper header, or the file(s) were unreadable, or it was the wrong size. Actually I did check in brainmask.gcut.mgz directory properties, and I saw the size of image is something like 150 KB, instead of 1 MB like is brainmask.mgz. What is the problem? Thanks, Claudia

2 1

Problem with recon-all
by Andrea Tateo 30 May '13

30 May '13

Dear FS experts, I have a problem with the command "recon-all". In many cases when I use it on the same brain's MRI, on the CLUSTER COMPUTING INFRASTRUCTURE, about 40% of my jobs finish without erros while the other are killed at the command "nu_currect", as you can see from the file.log in attachment. Do you have any suggestions? Thanks a lot for your help. Best regardes, Andrea

1 0

Rejoindre mon réseau sur LinkedIn
by Liang Wang 29 May '13

29 May '13

LinkedIn ------------ Liang Wang souhaite se connecter à vous sur LinkedIn : ------------------------------------------ Je vous invite à faire partie de mon réseau professionnel en ligne sur le site LinkedIn. Accepter l'invitation de Liang Wang http://www.linkedin.com/e/-qq80um-hhbdhqae-4h/qaAr-Z_86TRZ5lXG-dA9kZQ49qSe5… Voir le profil de Liang Wang http://www.linkedin.com/e/-qq80um-hhbdhqae-4h/rso/123403676/7qP4/name/66471… ------------------------------------------ Vous recevez des invitations par e-mail. Cet e-mail est destiné à Freesurfer List. Découvrez pourquoi nous avons inclus ceci : http://www.linkedin.com/e/-qq80um-hhbdhqae-4h/plh/http%3A%2F%2Fhelp%2Elinke… (c) 2012, LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

1 0

mris_divide_parcellation color table error
by Tina Jeon 29 May '13

29 May '13

Hello freesurfers, I am trying to create a figure similar to the Hagmann et al 2008 paper with 998 rois overlaid onto the surface, however, I am finding that there is no random, unique color for each parcellation unit like described in the help file for mris_divide_parcellation. I have attached a snapshot of my annotation file overlaid onto the surface, as you can see, the color iterates the same/similar color for a particular label. Can you tell me what I am doing wrong? Is there a pre-existing atlas as described in the Hagmann paper? My input: mris_ca_label -t ./FreeSurferColorLUT.txt subject_name lh ./lh.sphere.reg $FREESURFER_HOME/average/lh.curvature.buckner40.filled.desikan_killany.2010-03-25.gcs ./lh.aparc.998rois.annot mris_divide_parcellation subject_name lh ./lh.aparc.998rois.annot ./splittable.txt ./lh.annotation.998rois_26.annot Many thanks, Tina Jeon, MS UT Southwestern Medical Center '14 ________________________________ UT Southwestern Medical Center The future of medicine, today.

3 4

R: Re: very slow analysis with recon-all
by stdp82＠virgilio.it 29 May '13

29 May '13

Bruce and Sebastian thank you very much. I have checked the files but they are all wrong. These are the image info: data_type FLOAT32dim1 280dim2 240dim3 240dim4 1datatype 16pixdim1 0.5999984741pixdim2 1.0416666269pixdim3 1.0416666269pixdim4 0.0000000000cal_max 0.0000cal_min 0.0000file_type NIFTI-1+ Waiting for your feedback. Thank you very much. Stefano ----Messaggio originale---- Da: sebastian.moeller1(a)rwth-aachen.de Data: 26-mag-2013 21.31 A: "Bruce Fischl"<fischl(a)nmr.mgh.harvard.edu> Cc: <stdp82(a)virgilio.it>, <freesurfer(a)nmr.mgh.harvard.edu> Ogg: Re: [Freesurfer] very slow analysis with recon-all Hi Stefano, hi Bruce, sorry to partly high-jack your thread Stafano. In my experience with NHPs I often encounter problems like included cerebellum, so I routinely check the filled.mgz before actually running the surface recon, to confirm that the cerebellum (or other non-white matter) is NOT part of either hemisphere. (In my cases typically I then have to either edit the wm.mgz, the brain mask, or the pons cutting plane, but I guess that is NHP specific). Now wouldn't that filled.mgz check not also work for human recons? best Sebastian On May 26, 2013, at 21:13 , Bruce Fischl wrote: > Hi Stefano > > a defect with over 60K vertices is more than 1/2 the size of a typical hemisphere, so something has gone badly wrong. Have you checked the skull stripping? The aseg? The talairach? There shouldn't be a defect that big - you will need to figure out why > > cheers > Bruce > On Sun, 26 May 2013, stdp82(a)virgilio.it wrote: > >> Hi list, >> I'm running recon-all on two T1 but the command is for two days >> on CORRECTING DEFECT 11 (vertices=55538, convex hull=7811). >> Is it ok? What's happen? >> Thanks, >> Stefano >> > _______________________________________________ > 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.

2 1

no hippocampal stats despite running FS 5.3 with -hippo-subfields
by Salil Soman 29 May '13

29 May '13

Dear Freesurfer Experts, I have been running freesurfer 5.3 without any reported errors using the following command: recon-all -i SPGR/*.gz -s SUBJECTIDENTIFIER -nuintensitycor-3T -nocanorm -openmp 50 -hippo-subfields -all However, when I look for any of the hippocampal subfield stats (as described on http://ftp.nmr.mgh.harvard.edu/fswiki/HippocampalSubfieldSegmentation) I do not find any of them. Any suggestions on what I am doing incorrectly? Best wishes, Salil Soman, MD, MS

2 2

R: R: Re: very slow analysis with recon-all
by stdp82＠virgilio.it 29 May '13

29 May '13

I apologize. This is the correct info:data_type INT16dim1 280dim2 240dim3 240dim4 1datatype 4pixdim1 0.5999984741pixdim2 1.0416666269pixdim3 1.0416666269pixdim4 0.0000000000cal_max 0.0000cal_min 0.0000file_type NIFTI-1+ ----Messaggio originale---- Da: stdp82(a)virgilio.it Data: 30-mag-2013 0.30 A: <sebastian.moeller1(a)rwth-aachen.de>, "Bruce Fischl"<fischl(a)nmr.mgh.harvard.edu> Cc: <freesurfer(a)nmr.mgh.harvard.edu> Ogg: [Freesurfer] R: Re: very slow analysis with recon-all Bruce and Sebastian thank you very much. I have checked the files but they are all wrong. These are the image info: data_type FLOAT32dim1 280dim2 240dim3 240dim4 1datatype 16pixdim1 0.5999984741pixdim2 1.0416666269pixdim3 1.0416666269pixdim4 0.0000000000cal_max 0.0000cal_min 0.0000file_type NIFTI-1+ Waiting for your feedback. Thank you very much. Stefano ----Messaggio originale---- Da: sebastian.moeller1(a)rwth-aachen.de Data: 26-mag-2013 21.31 A: "Bruce Fischl"<fischl(a)nmr.mgh.harvard.edu> Cc: <stdp82(a)virgilio.it>, <freesurfer(a)nmr.mgh.harvard.edu> Ogg: Re: [Freesurfer] very slow analysis with recon-all Hi Stefano, hi Bruce, sorry to partly high-jack your thread Stafano. In my experience with NHPs I often encounter problems like included cerebellum, so I routinely check the filled.mgz before actually running the surface recon, to confirm that the cerebellum (or other non-white matter) is NOT part of either hemisphere. (In my cases typically I then have to either edit the wm.mgz, the brain mask, or the pons cutting plane, but I guess that is NHP specific). Now wouldn't that filled.mgz check not also work for human recons? best Sebastian On May 26, 2013, at 21:13 , Bruce Fischl wrote: > Hi Stefano > > a defect with over 60K vertices is more than 1/2 the size of a typical hemisphere, so something has gone badly wrong. Have you checked the skull stripping? The aseg? The talairach? There shouldn't be a defect that big - you will need to figure out why > > cheers > Bruce > On Sun, 26 May 2013, stdp82(a)virgilio.it wrote: > >> Hi list, >> I'm running recon-all on two T1 but the command is for two days >> on CORRECTING DEFECT 11 (vertices=55538, convex hull=7811). >> Is it ok? What's happen? >> Thanks, >> Stefano >> > _______________________________________________ > 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

Reposition Surface
by Derin J Cobia 29 May '13

29 May '13

Just a question about the Tools --> Reposition Surface... feature in Freeview. Is that up and running? Is there any accompanying documentation? Thanks. -Derin

1 0

Re: [Freesurfer] SUMA and FSFAST
by Douglas N Greve 29 May '13

29 May '13

Thanks Ziad, looks like it is similar to FSFAST. doug On 05/29/2013 11:50 AM, Ziad Saad wrote: > Hi Joe, > > As Doug guessed, I never used FSFAST so I can't really tell you much > about how they differ. > > SUMA will require you use FreeSurfer to create the surfaces and warp > them to standard spherical space. For the analysis stream, the one > difference that comes to mind is that we recreate standard-mesh > versions of FreeSurfer's surfaces (via sphere.reg) to make all > surfaces isotopic across all the subjects. After that, and aside from > the surface-specific procedures such as smoothing or clustering, all > level-I and level-II voxel-wise computations can be carried out on > surface-based data. > A recent description of the analysis stream is in this paper > http://afni.nimh.nih.gov/pub/dist/papers/Saad_SUMA_2011.pdf . > > cheers, > z > > > On May 29, 2013, at 09:44 AM, Douglas Greve wrote: > >> >> sorry, I've never used SUMA. Maybe Ziad can chime in (though he's >> probably never used FSFAST!) >> doug >> >> >> On 5/28/13 8:57 PM, Joseph Dien wrote: >>> I was wondering if someone could give me a summary as to how SUMA >>> and FSFAST differ? In other words, user interface aside, what would >>> be reasons to use one or the other? >>> >>> Joe >>> >>> >>> -------------------------------------------------------------------------------- >>> >>> Joseph Dien, >>> Senior Research Scientist >>> University of Maryland >>> >>> E-mail: jdien07(a)mac.com <mailto:jdien07@mac.com> >>> Phone: 301-226-8848 >>> Fax: 301-226-8811 >>> http://joedien.com// >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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. >> > -- Douglas N. Greve, Ph.D. MGH-NMR Center greve(a)nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422 Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
30
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 May 2013