Freesurfer

freesurfer@nmr.mgh.harvard.edu

19 participants
30088 discussions

Recon-all step estimate
by Pedro Paulo de Magalhães Oliveira Junior 08 Nov '11

08 Nov '11

Is there any script that I can use to estimate which step recon-all are in? My idea is to have a progress indicator for recon-all and this script would be very useful. thanks Pedro Paulo Jr

4 3

surface cnr
by Michael Harms 08 Nov '11

08 Nov '11

Hello, What is the difference between the mris_ms_surface_CNR and mri_cnr functions? (I couldn't find any descriptive info for either). And are either of them useful for identifying datasets with "poor" gray/white/csf contrast? thanks, -MH -- 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 6604 Tel: 314-747-6173 660 South Euclid Ave. Fax: 314-747-2182 St. Louis, MO 63110 Email: mharms(a)wustl.edu --------------------------------------------------------------------

2 1

Freesurfer on CentOS 6.
by SHRIKANTH KULASHEKHAR 08 Nov '11

08 Nov '11

Hi, The recommed platform for Freesurfer is CentOS 4. Can anyone advice on how stable the Freesurfer v5.1.0 will be on CentOS 6 ? We need this information to setup a new server. Thanks in advance. Shrikanth

2 1

Affine Matrix Conversions
by Matt Glasser 07 Nov '11

07 Nov '11

Hi, I am wondering what tools FreeSurfer has to convert between different affine matrix formats. For example, if I had a talairach.xfm that did a better job than talairach.lta, is there a way to convert from one to the other? What about FSL FLIRT matricies? Can these be interconverted with .lta? Thanks, Matt.

3 3

Re: [Freesurfer] different interpolation smoothing in conform step
by Irene Altarelli 07 Nov '11

07 Nov '11

Dear Martin and all, I had actually checked the RAS coordinates for all of my subjects and timepoints, and the one I mentioned is the only one in which the rotation is present. I created a uchar image from rawavg.mgz and tried to run recon-all from that without the motioncor step and without talairach (creating talairach.xfm manually from scratch using tkregister2), but recon-all crashes during mri_nu_correct (see error below). One strange observation: I had been running this subject in version 5.0 previously and noticed that, although the RAS coordinates and transform are the same as the ones I get in version 5.1, I do not see any smoothing effect when comparing rawavg.mgz and orig.mgz. I guess the best we can do at this stage is to manually edit the input nii file so that no rotation is coded in there (by changing the sform/qform as suggested by Michael Harm) - unless you have other suggestions... Thanks very much again for your help, Irene $Id: mri_convert.c,v 1.179.2.2 2011/05/16 20:53:47 greve Exp $ reading from ./tmp.mri_nu_correct.mni.22469/nu2.mnc... TR=0.00, TE=0.00, TI=0.00, flip angle=0.00 i_ras = (0, -1, 0) j_ras = (-0.0436194, 0, 0.999048) k_ras = (0.999048, 0, 0.0436194) INFO: transform src into the like-volume: orig.mgz writing to nu.mgz... mri_make_uchar nu.mgz transforms/talairach.xfm nu.mgz MRIvoxelToTalairachVoxel: unsupported slice direction 1 MRIvoxelToTalairachVoxel: unsupported slice direction 1 Numerical result out of range MRIvoxelToTalairachVoxel: unsupported slice direction 1 Numerical result out of range MRIvoxelToTalairachVoxel: unsupported slice direction 1 Numerical result out of range Le vendredi 04 novembre 2011 à 16:17 -0400, Martin Reuter a écrit : > Irene, > > I don't really know why the RAS coordinates are slightly rotated. I > checked and they are orthogonal. I don't know where this comes from > (autoalign on the scanner, but then why would it be only in one of your > volumes). > > Maybe Doug knows a trick how to avoid the interpolation as it seems > unnecessary? > > > Also, when you say you checked the other subject, did you look at the > images, or did you check the RAS coordinates in the mri_info output. It > can be that rotation is small and you won't see it the image but it is > still there. The RAS xform x_r,x_a,x_s, y_r, y_a, y_s and z_r z_a z_s > should only be +-1 or zero. > > Best, Martin > > > On Fri, 2011-11-04 at 17:46 +0100, Irene.Altarelli(a)ens.fr wrote: > > Dear Martin, > > > > I have a single scan per session, so no averaging. Also, this is the only image > > in my longitudinal data for which I am encountering this problem. I have > > checked all other subjects and none of them is rotated/smoothed. > > > > I am not sure I understand precisely why this scan needs to be rotated, is it to > > establish RAS coordinates' center and axes? Do you think there is a way I can > > fix it? I don't have many subjects in this protocol, so dropping one would be a > > real pity. > > > > Thanks very much again for your help. > > Best, > > Irene > > > > > > > > > > > > Selon Martin Reuter <mreuter(a)nmr.mgh.harvard.edu>: > > > > > Hi Irene, > > > > > > the voxel sizes are isotropic 1mm (which is good). However for some > > > reason the first image is slightly rotated while the second is perfectly > > > aligned with the axes. Therefore the first gets interpolated while the > > > second stays the same. That explains the different smoothing. > > > > > > Now the question is why is one image different. Do you collect a single > > > scan for each session or are you averaging several within-session scans? > > > You should look at other subjects and try to find out if and why > > > specific time points are slightly rotated. > > > > > > By the way this is a good example how to potentially mess up a > > > longitudinal study. If for example one of the time points is always (or > > > more frequently) rotated because of a different protocol the study would > > > be severely biased. So it is good that you are checking this. > > > > > > Best, Martin > > > > > > > > > On Fri, 2011-11-04 at 10:28 +0100, Irene.Altarelli(a)ens.fr wrote: > > > > Dear Martin, > > > > > > > > the RAS coordinates and voxel to ras transforms are indeed slightly > > > different. > > > > Should I change this and if so, how? > > > > > > > > Please find the output of mri_info for each of the two acquisitions at the > > > end > > > > of this email. > > > > > > > > Thanks again! > > > > Irene > > > > > > > > > > > > > > > > > *********************************************************************************** > > > > > > > > Volume information for gsTP1/mri/rawavg.mgz > > > > type: MGH > > > > dimensions: 256 x 256 x 176 > > > > voxel sizes: 1.0000, 1.0000, 1.0000 > > > > type: FLOAT (3) > > > > fov: 256.000 > > > > dof: 0 > > > > xstart: -128.0, xend: 128.0 > > > > ystart: -128.0, yend: 128.0 > > > > zstart: -88.0, zend: 88.0 > > > > TR: 0.00 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 = 0.0000, y_r = -0.0436, z_r = 0.9990, c_r = > > > -3.5493 > > > > : x_a = -1.0000, y_a = 0.0000, z_a = 0.0000, c_a = > > > 12.8739 > > > > : x_s = 0.0000, y_s = 0.9990, z_s = 0.0436, c_s = > > > -16.0490 > > > > > > > > talairach xfm : > > > > Orientation : PSR > > > > Primary Slice Direction: sagittal > > > > > > > > voxel to ras transform: > > > > 0.0000 -0.0436 0.9990 -85.8823 > > > > -1.0000 0.0000 0.0000 140.8739 > > > > 0.0000 0.9990 0.0436 -147.7657 > > > > 0.0000 0.0000 0.0000 1.0000 > > > > > > > > voxel-to-ras determinant -1 > > > > > > > > ras to voxel transform: > > > > -0.0000 -1.0000 -0.0000 140.8739 > > > > -0.0436 0.0000 0.9990 143.8789 > > > > 0.9990 -0.0000 0.0436 92.2460 > > > > 0.0000 0.0000 0.0000 1.0000 > > > > > > > > > > > > > > > > > > > > > > > > > *********************************************************************************** > > > > > > > > > > > > > > > > Volume information for gsTP2/mri/rawavg.mgz > > > > type: MGH > > > > dimensions: 256 x 256 x 176 > > > > voxel sizes: 1.0000, 1.0000, 1.0000 > > > > type: FLOAT (3) > > > > fov: 256.000 > > > > dof: 0 > > > > xstart: -128.0, xend: 128.0 > > > > ystart: -128.0, yend: 128.0 > > > > zstart: -88.0, zend: 88.0 > > > > TR: 0.00 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 = 0.0000, y_r = 0.0000, z_r = 1.0000, c_r = > > > -1.5339 > > > > : x_a = -1.0000, y_a = 0.0000, z_a = 0.0000, c_a = > > > 11.5254 > > > > : x_s = 0.0000, y_s = 1.0000, z_s = 0.0000, c_s = > > > -19.3390 > > > > > > > > talairach xfm : > > > > Orientation : PSR > > > > Primary Slice Direction: sagittal > > > > > > > > voxel to ras transform: > > > > 0.0000 0.0000 1.0000 -89.5339 > > > > -1.0000 0.0000 0.0000 139.5254 > > > > 0.0000 1.0000 0.0000 -147.3390 > > > > 0.0000 0.0000 0.0000 1.0000 > > > > > > > > voxel-to-ras determinant -1 > > > > > > > > ras to voxel transform: > > > > -0.0000 -1.0000 -0.0000 139.5254 > > > > -0.0000 -0.0000 1.0000 147.3390 > > > > 1.0000 0.0000 0.0000 89.5339 > > > > 0.0000 0.0000 0.0000 1.0000 > > > > > > > > > > > > > > > > > > > > Selon Martin Reuter <mreuter(a)nmr.mgh.harvard.edu>: > > > > > > > > > Hi Irene, > > > > > > > > > > since those images are not from the longitudinal runs, it really is a > > > > > cross sectional question: > > > > > > > > > > You have two images and the raw average look both similarly noisy, but > > > > > the orig (which is the first image in the recon-all stream) is smoother > > > > > for one than the other. > > > > > > > > > > That means that the conform step (that interpolates the isotropic orig > > > > > from the rawavg) introduces the different smoothing. Not sure why it is > > > > > different. > > > > > You can check (with mri_info) the voxel sizes of your rawavg and the RAS > > > > > coordinates. If they are the same, smoothing should also be the same. > > > > > > > > > > Best, Martin > > > > > > > > > > On Thu, 2011-11-03 at 17:48 +0100, Irene Altarelli wrote: > > > > > > Dear Martin, > > > > > > > > > > > > thanks for your quick reply. > > > > > > > > > > > > I am using version 5.1. I only have two timepoints per subject and I > > > > > > took the snapshots from the independent runs. What bothers me is that > > > > > > the difference is not present in the 001.mgz images, but seems to > > > appear > > > > > > later in the workflow. > > > > > > > > > > > > Thanks again, > > > > > > Irene > > > > > > > > > > > > Le jeudi 03 novembre 2011 Ãƒ 10:40 -0400, Martin Reuter a ÃƒÂ©crit : > > > > > > > Hi Irene, > > > > > > > > > > > > > > both images should be smoothed the same. You only have two time > > > points > > > > > > > in each subject? Which FreeSurfer version are you using? And these > > > > > > > images are from the *.long.base directories (or are they from the > > > > > > > independent runs)? > > > > > > > > > > > > > > -Martin > > > > > > > > > > > > > > On Thu, 2011-11-03 at 15:20 +0100, Irene Altarelli wrote: > > > > > > > > Dear Fs experts, > > > > > > > > > > > > > > > > I am running a longitudinal dataset through the longitudinal > > > pipeline, > > > > > > > > and noticed that for one subject, although we kept everything the > > > same > > > > > > > > (sequence, coil etc) the two timepoints' brainmasks look different: > > > > > > > > timepoint one (in the attached snapshot, gs_tp1) looks as if it has > > > > > been > > > > > > > > smoothed, compared to timepoint two (gs_tp2). I have checked some > > > other > > > > > > > > images from this subject, and the same seems to occur for orig.mgz, > > > but > > > > > > > > not for rawavg.mgz. > > > > > > > > > > > > > > > > Any idea on what could be causing the difference would be greatly > > > > > > > > appreciated. > > > > > > > > > > > > > > > > Thanks in advance, > > > > > > > > Irene > > > > > > > > _______________________________________________ > > > > > > > > Freesurfer mailing list > > > > > > > > Freesurfer(a)nmr.mgh.harvard.edu > > > > > > > > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Irene Altarelli Laboratoire de Sciences Cognitives et Psycholinguistique Ecole Normale Supérieure 29, rue d'Ulm 75230 Paris Cedex 05 tel. +33 (0)1 44 32 26 23

1 0

Re: [Freesurfer] mris_anatomical stats different thickness files
by Douglas N Greve 07 Nov '11

07 Nov '11

krista kelly wrote: > Thanks Doug, but would mris_fwhm still be useful if I've already added > the -qcache command while running recon all? I have smoothed files in > my subjects' surf folders (i.e. lh.area.fwhm15.fsaverage.mgh). I want > to extract the smoothed cortical thickness and surface area values for > my subjects but am not exactly sure which commands to use. If you are going to use lh.thickness and your want it to be smoothed, then you will need to smooth it. Pass the smoothed thickness as input to mris_anatomical_stats. > > Also, I know that I don't really need to use a smoothing kernel if I'm > looking for cortical thickness within certain ROIs (presumably because > I'm getting the average), but is this also ok for surface area data? I > only ask because I'm not getting an average surface area like I am > with cortical thickness, it's the total surface area. So would > smoothing be something that I should do for surface area? For individual ROI area measures, there is no need to smooth (and does not really make sense as you point out). doug > > Thanks! > > > On Mon, Oct 24, 2011 at 4:06 PM, Douglas N Greve > <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>> wrote: > > no, that would be 15 "smooth steps". If you want to smooth by > 15mm, then use mris_fwhm. > doug > > krista kelly wrote: > > Would the following code give me data smoothed with 15 fwhm > kernel? > > mris_anatomical_stats -l lh.v1.label -t lh.thickness -nsmooth > 15 -b -f BV01/stats/lh.v1_pial.stats BV01 lh pial > > > Thanks! > > > On Mon, Oct 24, 2011 at 10:40 AM, krista kelly > <krista.kelly16(a)gmail.com <mailto:krista.kelly16@gmail.com> > <mailto:krista.kelly16@gmail.com > <mailto:krista.kelly16@gmail.com>>> wrote: > > Thanks for clearing this up! It makes a lot more sense now. > > > On Mon, Oct 24, 2011 at 10:35 AM, Douglas N Greve > <greve(a)nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>>> wrote: > > > > krista kelly wrote: > > I'm looking at both cortical thickness and surface area > differences between two groups. I've been using > mris_anatomical_stats to retrieve values but had a few > questions: > > 1) Do I need to do separate mris_anatomical_stats using > different thickness files (bolded below) to get > cortical > thickness and surface area measures. For example: > > cortical thickness - mris_anatomical_stats -l > lh.v1.label > -t *lh.thickness* -b -f BV01/stats/lh.v1.stats BV01 lh > surface area - mris_anatomical_stats -l lh.v1.label -t > *lh.area *-b -f BV01/stats/lh.v1.stats BV01 lh > > > Or, since the output files include all of these > measures, > is it fine to just run one of the two? > > Just run the first one. > > > 2) The output files for both analyses run above (with > different thickness files) have identical values for > everything except for tray matter volume. Using > lh.thickness file - grayvol = 8082; using lh.area > file - > grayvol = 4029. Can anyone clarify why this happens? > > It computes the gray matter volume by thickness*area. > If you > pass it "area" as the "thickness", then you are probably > getting area*area. Though I'm surprised that the > "thickness" > values are correct. > > > 3) The default surface area values are for the white > matter surface. How do I run mri_anatomical_stats > to get > the pial surface? I've tried mris_anatomical_stats -l > lh.v1.label -t *lh.area.pial *-b -f > BV01/stats/lh.v1.stats > BV01 lh but I get identical values for everything > (except > grayvol). > > Try adding "pial" to the end of the command line (and use > lh.thickness) > doug > > > Thanks! > Krista > > ------------------------------------------------------------------------ > > _______________________________________________ > Freesurfer mailing list > Freesurfer(a)nmr.mgh.harvard.edu > <mailto:Freesurfer@nmr.mgh.harvard.edu> > <mailto:Freesurfer@nmr.mgh.harvard.edu > <mailto:Freesurfer@nmr.mgh.harvard.edu>> > > > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > > -- Douglas N. Greve, Ph.D. > MGH-NMR Center > greve(a)nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>> > Phone Number: 617-724-2358 <tel:617-724-2358> > <tel:617-724-2358 <tel:617-724-2358>> Fax: > 617-726-7422 <tel:617-726-7422> <tel:617-726-7422 > <tel:617-726-7422>> > > Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting > <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> > <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> > FileDrop: > www.nmr.mgh.harvard.edu/facility/filedrop/index.html > <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> > > <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> > > > > > 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 <mailto:greve@nmr.mgh.harvard.edu> > Phone Number: 617-724-2358 <tel:617-724-2358> Fax: 617-726-7422 > <tel:617-726-7422> > > Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting > <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> > FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html > <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> > > -- 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: www.nmr.mgh.harvard.edu/facility/filedrop/index.html

1 0

Re: [Freesurfer] Question about the orientation of input image in FreeSurfer. Thanks a lot!
by Douglas N Greve 07 Nov '11

07 Nov '11

> On Nov 4, 2011, at 10:46 PM, yaping wang <ypwang.npu(a)gmail.com > <mailto:ypwang.npu@gmail.com>> wrote: > >> Hi, Dear Dr Fischl, >> Sorry to interrupt you. >> I have a simple question to ask you. It's about the orientation of >> the input image for FreeSurfer. The version I used now is version 4.5.0. >> >> First I referred to the "README" in ${FreeSurfer_Dir}/subjects, but I >> didn't found the directory named "ernie". >> So I referred the following images for the input image orientation: >> ${FreeSurfer_Dir}/subjects/bert/mri/orig/001.mgz (002.mgz and 003.mgz) >> and >> ${FreeSurfer_Dir}/subjects/bert/mri/rawavg.mgz >> ${FreeSurfer_Dir}/subjects/bert/mri/orig.mgz >> >> I show them in "FreeSurfer_sample.JPG", the first row is the 001.mgz >> (the orientations of 002.mgz and 003.mgz are same with 001.mgz, so I >> just show 001.mgz), the second row is the the rawavg.mgz and the >> orig.mgz. >> From http://surfer.nmr.mgh.harvard.edu/fswiki/ReconAllDevTable, I >> think 001.mgz (002.mgz and 003.mgz) is the input image, and the >> rawavg.mgz and orig.mgz are the following two output images. >> >> I test out data with "RAS" orientation as input image, it also gets >> the following two output image, and the orig.mgz has the same >> orientation as the sample image of Freesurfer. I show them in >> "ourTestData.JPG". Same with the previous figure, the first row is >> our input image, and the second row is the following two output >> images. But the origin is so different. So I have the following >> questions: >> >> 1. What's the correct orientation FreeSurfer request? >> Is it correct for the orientation of the input image of our test >> data? >> I have found that it can applied to "RAS" and "LAS" direction for >> "mri_watershed". So the input image can be any orientation, is it >> correct? FreeSurfer does not require any particular orientation. The orientation information needs to be correct. Inside of FreeSurfer, it will automatically be converted to LIA. >> >> 2. Will the "mri_robust_template" or "mri_add_xform_to_header" change >> the orientation of the input image to the orientation FreeSurfer request? No. >> >> 3. What's the meaning of the origin shown in MRIcro? It comes from >> the template or ...? >> If the "orig.mgz" of our test data has reoriented to the >> orientation of FreeeSurfer, why the origin is different the >> "orig.mgz" of FreeSurfer sample data? >> And why it's changing for our test data (from the input data--> >> rawavg.mgz---> orig.mgz, it's always changing)? I don't know what MRIcro is doing. The origin usually means the xyz of the first voxel. FS changes the orientation to LIA (and voxel size to 1mm) because this is assumed in all subsequent processing. doug >> >> Thank you so much! >> >> Best. >> Yaping >> <FreeSurfer_sample.JPG> >> <ourTestData.JPG> -- 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: www.nmr.mgh.harvard.edu/facility/filedrop/index.html

1 0

Re: [Freesurfer] different lengths of runs
by Douglas N Greve 07 Nov '11

07 Nov '11

Hi Maryam, which version are you using? It should be fine to have different length runs (it was a problem in older versions). If you really need to make them the same length, using mri_convert with the --ndrop option to remove the last few time points. doug Maryam Vaziri Pashkam wrote: > Hi Doug, > > In one of my experiments I have 8 runs. 3 of these runs have 190 TRs > and 5 of them have 192 TRs. The difference is only that there is a 4 > sec fixation period in the end of the 5 longer runs which I dont > really need. Otherwise the 8 runs could potentially be combined. Is > there anyway that I could combine the runs in my experiment? The > Selxavg3 does not let me analyze the 8 runs together as they have > different lengths. Is there anyway to get rid of the last two TRs in > the 5 longer runs and combine the runs in the analysis? I had an idea > to import my .nii files to Matlab, cut off the last two TRs and then > save them as .nii files again. Would that work? Is there a better way > to do this? > > Thanks, > Maryam -- 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: www.nmr.mgh.harvard.edu/facility/filedrop/index.html

1 0

dimensions of input and annot for mri_segstats
by Linda Douw 07 Nov '11

07 Nov '11

Hi all, I have nifti files containing the surface-projected time series data of a subject (obtained using procsurffast), both lh and rh. These time series are projected onto fsaverage5, and are 3414 x 1 x 3 time points, where 3414*3 = 10242 are the number of vertices for each hemisphere. Now, I would like to extract the mean time series for 138 ROIs, which are defined in an annotation called sparc I made: mris_divide_parcellation fsaverage5 lh aparc.annot sparc.txt lh.sparc I would assume that these files are now of the same dimensions. However, when I run: mri_segstats --i /subject/surf/subject_projectedto_fsaverage5.nii.gz --avgwf /subject1/ts_lh.txt --annot fsaverage5 lh sparc it crashes because the dimensions are not the same (the segmentation is 10242 x 1 x 1). They do both overlay nicely on fsaverage5 inflated using tksurfer. What may cause this mismatch? And is there a solution? Thanks, Linda

2 1

Re: [Freesurfer] mri_cvs_register can not find
by lzollei＠nmr.mgh.harvard.edu 06 Nov '11

06 Nov '11

Hi Martin, Could you give more details? Which version of mri-cvs-register are you using? Was there a log file that you could share also? Thanks, Lilla ------Original Message------ From: Martin Kavec To: Freesurfer mailing list To: Lilla Zollei Subject: mri_cvs_register can not find Sent: Nov 4, 2011 03:44 Hi all, I am trying to run mri_cvs_register but for some reasons it always terminates with: ERROR: Can not find or read $SUBJECTS_DIR/MY_SUBJECTS/cvs/combined_tocvs_avg35__elreg_aseg.m3z My command is as follows: mri_cvs_register --mov MY_SUBJECT Indeed the file is not there, but another one with the exactly the same name, but different suffix .tm3d is there. Anybody encountered similar problem? Any idea what can be wrong? Thanks in advance, Martin Sent via BlackBerry by AT&T

2 2

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