Freesurfer

freesurfer@nmr.mgh.harvard.edu

1 participants
30089 discussions

Re: [Freesurfer] How to use aparcstats2table and asegstats2table for rois generated from QDEC group analyses
by Vy Dinh 17 May '12

17 May '12

Thanks for the suggestion Josh! I have definitely thought about this, but since I'm a total novice bash programmer, I thought that it would be quicker to learn which option to add to asegstats2table and aparcstats2table. I would really appreciate it if you could help me come up with this code? What shell function could I use to open each .stats file? How do I use grep to call, say line 53 in the stats file? Many thanks, Vy On Thu, May 17, 2012 at 4:19 PM, Joshua Lee <jkilee(a)ucdavis.edu> wrote: > Why not use a bash or csh script that loops through your subjects stat > files, and use grep read the appropriate lines to a single text file > with >>. > > - > Josh > > > On Thu, May 17, 2012 at 1:04 PM, Vy Dinh <vy_dinh(a)rush.edu> wrote: > > Dear Freesurfer Experts, > > > > I've created a couple of ROIs from qdec comparisons of thickness and > volume > > between two groups. We extracted the data from these ROIs for each > subject > > using mris_anatomical_stats. > > > > The stat files are located within each subjects folder: > > sub/stats/rh.roi.stats > > > > Now, we would like to combine the data from each stat file to a text file > > using aparcstats2table and asegstats2table (for volume measures). I > already > > have batch scripts that call these functions for multiple subjects. The > > script basically concatenates all of the subject ids and inputs the > > concatenated string into the aparcstats2table (or asegstats2table) > command. > > > > EX: > > asegstats2table -s s1 -s s2 -s s3 -s s4 --hemi lh --meas volume > -tablefile > > test_stats.txt > > > > I would like to modify my script so that I can extract the data from the > > roi.stats file. This is only a matter of entering the correct inputs for > > aparcstats2table and asegstats2table but I have tried with little > success. > > The problems with each command are explained below. > > > > For asegstats2table: > > According to documentation > > (http://surfer.nmr.mgh.harvard.edu/fswiki/asegstats2table) I have tried > > running "asegstats2table $STRING --meas volume --skip --tablefile > > $OUTFILE " where string is "-i s1/stats/lh.roi.stats -i > > s2/stats/lh.roi.stats ......etc" but get the error message: > > > > Building the table.. > > Traceback (most recent call last): > > File > > > "/Users/skip/Desktop/harlow_mount/apps/fmri_progs/freesurfer_v51/freesurfer/bin/asegstats2table", > > line 513, in <module> > > rows, columns, table = sanitize_table(options, pretable) > > File > > > "/Users/skip/Desktop/harlow_mount/apps/fmri_progs/freesurfer_v51/freesurfer/bin/asegstats2table", > > line 412, in sanitize_table > > _specs, _id_name_map, _measl = _t[0] > > IndexError: list index out of range > > > > > > For aparcstats2table: > > when I run the command: > > > > aparcstats2table $STRING --hemi lh --parc roi_name --skip --tablefile > > $OUTFILE > > > > where string is "-s s1 -s s2 -s s3 ", I get a text file with 3 columns. > The > > first column lists the subject ids, but what are the values for the 2nd > and > > 3rd columns? Also, is it possible to input more than 2 .stats file for > the > > command? > > > > > > Looking forward to your responses, > > > > > > Vy > > > > > > Vy T.U. Dinh > > Neurological Sciences > > Rush University Medical Center > > Phone: (312) 563-3853 > > Fax: (312) 563-4660 > > Email: Vy_dinh(a)rush.edu > > > > > > _______________________________________________ > > 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

Re: [Freesurfer] aseg.stats not matching up
by Joshua Lee 17 May '12

17 May '12

Yes, I'm glad that Bruce confirmed this. Good. The majority had deviations that were in the range of 20-40 voxels which seems intuitively in the right range. The ones that concerned me were those that inexplicably deviated in the range of 600 to 1000 voxels out of 4000 or so voxels in the hippocampus. Notably, the large deviations occurred in subjects with some motion artifacts says my colleague, although the hippocampal segmentation itself seemed fairly representative of Freesurfer. However this last point seems different that the one raised in my first post, since we are getting deviations with the exact same voxels after relabeling. I hope Doug gets a chance to chime in; our lab is somewhat concerned about this right now because we are in the middle of a revision for a journal submission. Best, and thank you, Joshua - Joshua Lee Graduate Student Center for Mind and Brain & Department of Psychology University of California, Davis 530.747.3805 Joshua On Thu, May 17, 2012 at 2:05 PM, Joshua . <nimzodisaster(a)gmail.com> wrote: > Yes. Good. The majority had deviations that were in the range of 20-40 > voxels which seems intuitively in the right range. The ones that concerned > me were those that inexplicably deviated in the range of 600 to 1000 voxels > out of 4000 or so voxels in the hippocampus. Notably, the large deviations > occurred in subjects with some motion artifacts says my colleague, although > the hippocampal segmentation itself seemed fairly representative of > Freesurfer. > > However this last point seems different that the one raised in my first > post, since we are getting deviations with the exact same voxels after > relabeling. I hope Doug gets a chance to chime; our lab is somewhat > concerned about this right now because we are in the middle of a revision > for a journal submission. > > Best, and thank you, > > Joshua > > > On Thu, May 17, 2012 at 12:39 PM, Bruce Fischl <fischl(a)nmr.mgh.harvard.edu> > wrote: >> >> yes, that is a consequence of partial volume correction. If you have a 3 >> class boundary (two of which are hippocampal subdivisions), we will compute >> different partial volume fractions than if you have a 2 class boundary. I >> wouldn't expect it to be a huge effect, but they definitely won't be >> identical >> >> >> >> On Thu, 17 May 2012, Joshua Lee wrote: >> >>> We discovered this while subdividing the hippocampus into several >>> subregions using tkmedit to relabel voxels, and finding that these >>> subregions were not adding up to the original volume. I expected some >>> differences, but many deviated more than I had expected. This led me to the >>> test I discussed at the beginning of the thread. >>> >>> >>> Joshua >>> >>> >>> >>> >>> >>> >>> On May 16, 2012, at 1:55 PM, Bruce Fischl <fischl(a)nmr.mgh.harvard.edu> >>> wrote: >>> >>>> hmmm, that is convincing. I don't think there's anything in mri_segstats >>>> that knows about the meaning of any of the indices, but maybe Doug can >>>> correct me? >>>> >>>> On Wed, 16 May 2012, Joshua Lee wrote: >>>> >>>>> Hi Bruce, >>>>> First, let me add that if I run the mri_segstats without the --pv flag, >>>>> the >>>>> two will have identical volumes. This indicates to me that we captured >>>>> all >>>>> the voxels into the new label. >>>>> Joshua >>>>> - >>>>> Joshua Lee >>>>> Graduate Student >>>>> Center for Mind and Brain & >>>>> Department of Psychology >>>>> University of California, Davis >>>>> 530.747.3805 >>>>> On Wed, May 16, 2012 at 1:38 PM, Bruce Fischl >>>>> <fischl(a)nmr.mgh.harvard.edu> >>>>> wrote: >>>>> Hi Joshua >>>>> >>>>> probabilities are computed internally, but not stored nor used >>>>> in volume calcualtions. Are you actually doing a 3D fill? I >>>>> don't think the hippocampus label is guaranteed to be connected. >>>>> Can you try instead replacing every voxel in matlab with the >>>>> hippocampus index to your new one? That I think should give you >>>>> the same results. >>>>> >>>>> cheers >>>>> Bruce >>>>> >>>>> On Wed, 16 May 2012, Joshua Lee wrote: >>>>> >>>>> Suppose I were to open a subject aseg.mgz in >>>>> tkmedit, and use the 3D fill >>>>> tool to relabel the entire left hippocampus >>>>> segmentation to >>>>> 'MyNewImaginaryLabel'. If I then re-run the aseg >>>>> stats, should the left >>>>> hippocampus volume from the original aseg.stats be >>>>> identical to the volume >>>>> of MyImaginaryLabel in the newly generated >>>>> aseg.stats? >>>>> >>>>> Every voxel from the prior label is now assigned to >>>>> the new label; yet, I >>>>> am getting different results (by about 100 voxels in >>>>> the ones I've tried). >>>>> >>>>> The command Im using to recalculate: >>>>> mri_segstats --seg >>>>> /usr/local/freesurfer/subjects/s02/new_MRI/new/aseg.auto.mgz >>>>> --sum >>>>> >>>>> /usr/local/freesurfer/subjects/s02/stats/NEWmethod1aseg_Hipp.stats >>>>> --pv >>>>> /usr/local/freesurfer/subjects/s02/mri/norm.mgz >>>>> --excludeid 0 >>>>> --brain-vol-from-seg --brainmask >>>>> /usr/local/freesurfer/subjects/s02/mri/brainmask.mgz >>>>> --in >>>>> /usr/local/freesurfer/subjects/s02/mri/norm.mgz >>>>> --in-intensity-name norm >>>>> --in-intensity-units MR --etiv --surf-wm-vol --ctab >>>>> /usr/local/freesurfer/8regions.txt --subject s02; >>>>> >>>>> Now if I were to relabel 'MyNewImaginaryLabel' to >>>>> 'AthirdLabel', and again >>>>> changing every voxel in 'MyNewImaginaryLabel' to the >>>>> new label, the computed >>>>> volumes do not change. This led me to suspect that >>>>> aseg.mgz contains >>>>> probability estimates at each voxel that are then >>>>> subsequently overwritten >>>>> by my tkmedits. However, per a previous conversation >>>>> from a year ago or so >>>>> with Bruce and also the relevant Freesurfer >>>>> documentation this does not seem >>>>> to be the case. Partial volume information is not >>>>> contained within the >>>>> aseg.mgz (right!?), but is computed by mri_segstats >>>>> by comparing border >>>>> voxels with intensities in the norm.mgz. So I am at >>>>> a loss on why these >>>>> should be different. >>>>> >>>>> This has been replicated in version 4.5 and 5.1 >>>>> - >>>>> Joshua Lee >>>>> Graduate Student >>>>> Center for Mind and Brain & >>>>> Department of Psychology >>>>> University of California, Davis >>>>> 530.747.3805 >>>>> 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

Re: [Freesurfer] aseg.stats not matching up
by Bruce Fischl 17 May '12

17 May '12

yes, that is a consequence of partial volume correction. If you have a 3 class boundary (two of which are hippocampal subdivisions), we will compute different partial volume fractions than if you have a 2 class boundary. I wouldn't expect it to be a huge effect, but they definitely won't be identical On Thu, 17 May 2012, Joshua Lee wrote: > We discovered this while subdividing the hippocampus into several subregions using tkmedit to relabel voxels, and finding that these subregions were not adding up to the original volume. I expected some differences, but many deviated more than I had expected. This led me to the test I discussed at the beginning of the thread. > > > Joshua > > > > > > > On May 16, 2012, at 1:55 PM, Bruce Fischl <fischl(a)nmr.mgh.harvard.edu> wrote: > >> hmmm, that is convincing. I don't think there's anything in mri_segstats that knows about the meaning of any of the indices, but maybe Doug can correct me? >> >> On Wed, 16 May 2012, Joshua Lee wrote: >> >>> Hi Bruce, >>> First, let me add that if I run the mri_segstats without the --pv flag, the >>> two will have identical volumes. This indicates to me that we captured all >>> the voxels into the new label. >>> Joshua >>> - >>> Joshua Lee >>> Graduate Student >>> Center for Mind and Brain & >>> Department of Psychology >>> University of California, Davis >>> 530.747.3805 >>> On Wed, May 16, 2012 at 1:38 PM, Bruce Fischl <fischl(a)nmr.mgh.harvard.edu> >>> wrote: >>> Hi Joshua >>> >>> probabilities are computed internally, but not stored nor used >>> in volume calcualtions. Are you actually doing a 3D fill? I >>> don't think the hippocampus label is guaranteed to be connected. >>> Can you try instead replacing every voxel in matlab with the >>> hippocampus index to your new one? That I think should give you >>> the same results. >>> >>> cheers >>> Bruce >>> >>> On Wed, 16 May 2012, Joshua Lee wrote: >>> >>> Suppose I were to open a subject aseg.mgz in >>> tkmedit, and use the 3D fill >>> tool to relabel the entire left hippocampus >>> segmentation to >>> 'MyNewImaginaryLabel'. If I then re-run the aseg >>> stats, should the left >>> hippocampus volume from the original aseg.stats be >>> identical to the volume >>> of MyImaginaryLabel in the newly generated >>> aseg.stats? >>> >>> Every voxel from the prior label is now assigned to >>> the new label; yet, I >>> am getting different results (by about 100 voxels in >>> the ones I've tried). >>> >>> The command Im using to recalculate: >>> mri_segstats --seg >>> /usr/local/freesurfer/subjects/s02/new_MRI/new/aseg.auto.mgz >>> --sum >>> /usr/local/freesurfer/subjects/s02/stats/NEWmethod1aseg_Hipp.stats >>> --pv >>> /usr/local/freesurfer/subjects/s02/mri/norm.mgz >>> --excludeid 0 >>> --brain-vol-from-seg --brainmask >>> /usr/local/freesurfer/subjects/s02/mri/brainmask.mgz >>> --in >>> /usr/local/freesurfer/subjects/s02/mri/norm.mgz >>> --in-intensity-name norm >>> --in-intensity-units MR --etiv --surf-wm-vol --ctab >>> /usr/local/freesurfer/8regions.txt --subject s02; >>> >>> Now if I were to relabel 'MyNewImaginaryLabel' to >>> 'AthirdLabel', and again >>> changing every voxel in 'MyNewImaginaryLabel' to the >>> new label, the computed >>> volumes do not change. This led me to suspect that >>> aseg.mgz contains >>> probability estimates at each voxel that are then >>> subsequently overwritten >>> by my tkmedits. However, per a previous conversation >>> from a year ago or so >>> with Bruce and also the relevant Freesurfer >>> documentation this does not seem >>> to be the case. Partial volume information is not >>> contained within the >>> aseg.mgz (right!?), but is computed by mri_segstats >>> by comparing border >>> voxels with intensities in the norm.mgz. So I am at >>> a loss on why these >>> should be different. >>> >>> This has been replicated in version 4.5 and 5.1 >>> - >>> Joshua Lee >>> Graduate Student >>> Center for Mind and Brain & >>> Department of Psychology >>> University of California, Davis >>> 530.747.3805 >>> 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

Slice Viewer
by Antonella Kis 17 May '12

17 May '12

Dear FS experts, I was using FreeView to see all my FA's clusters position from my DTI data that survived after correction by multiple comparisons. This clusters are locate in different slices and I would like to know if there is a way to print out in the same time different slices not only one by one so I can save this image for an article. If this is not possible using FreeView can you please recommend me any software which I can use? I know there is xjview for SPM but is there any software that will allow me to have a similar view (image with multiple slices) for my DTI data? Many thanks, Antonella

2 2

New data point for longitudinal processing.
by Zheng Hui 17 May '12

17 May '12

2 1

Re: [Freesurfer] Freesurfer 1mm Isotropic standard and the Future
by Michael Waskom 16 May '12

16 May '12

Oops i just realized I only sent this to Bruce: Thanks! It looks like this involves some manual intervention. Matt., I assume you're not manually making control points on 1000s of subjects (I imagine this is for the human connectcome project). Is your code public somewhere? Cheers, Michael On Tue, May 15, 2012 at 7:36 PM, Michael Waskom <mwaskom(a)stanford.edu>wrote: > Thanks! It looks like this involves some manual intervention. Matt., I > assume you're not manually making control points on 1000s of subjects (I > imagine this is for the human connectcome project). Is your code public > somewhere? > > Cheers, > Michael > > > On Tue, May 15, 2012 at 9:14 AM, Bruce Fischl <fischl(a)nmr.mgh.harvard.edu>wrote: > >> sure, here's mine. Matt's is probably a lot more polished as they intend >> to run it on hundreds or thousands of subjects >> >> On Tue, 15 May 2012, Michael Waskom wrote: >> >> Hi Bruce, >>> Sounds cool, I'd be very interested in checking out the script. >>> >>> Cheers, >>> Michael >>> >>> On Tue, May 15, 2012 at 5:29 AM, Bruce Fischl < >>> fischl(a)nmr.mgh.harvard.edu> >>> wrote: >>> you need to call mris_make_surfaces directly. It's a bit >>> complicated as you need to intensity normalize and register the >>> hires volume to the surfaces first. I have an example script if >>> anyone is interested, but no one has used it yet but me I don't >>> think (unless Matt Glasser has gotten his version working, which >>> on second thought he probably has) >>> >>> On Mon, 14 May 2012, Michael Waskom wrote: >>> >>> Hi Bruce, >>> Is there a flag for this on recon-all? Or do you >>> need to use >>> mri_make_surfaces directly? >>> >>> Best, >>> Michael >>> >>> On Mon, May 14, 2012 at 2:09 PM, Bruce Fischl >>> <fischl(a)nmr.mgh.harvard.edu> >>> wrote: >>> Hi Joshua >>> >>> yes, we already have upgraded >>> mris_make_surfaces to take higher >>> res data >>> and refine the surfaces with it. Haven't tried >>> it on the aseg >>> yet, but if >>> you upload a sample dataset I could see how >>> hard it is. >>> >>> cheers >>> Bruce >>> On Mon, 14 May 2012, >>> Joshua Lee wrote: >>> >>> > Dear Freesurfers, >>> > >>> > Over the last years, MR imaging technology >>> hasimproved such >>> that sub 1-mm >>> > isotropic scans can be obtained with good >>> signal to noise >>> characteristics. >>> > For example, our lab uses 0.7mm isotropic >>> structural MR >>> images. I understand >>> > that the Freesurfer pipeline will up-sample >>> these to 1mm >>> isotropic, but it >>> > seems a shame that so much information is >>> left unused which >>> could be used to >>> > improve the accuracy of sub-cortical and >>> cortical >>> segmentation. My question >>> > is whether there are any plans at Freesurfer >>> to change the >>> reference >>> > standard resolution from 1mm isotropic, or >>> provide another >>> solution that can >>> > help researchers make the most of your >>> technology. >>> > >>> > Sincerely, >>> > >>> > >>> > Joshua >>> > - >>> > Joshua >>> > >>> > >>> > >>> ______________________________**_________________ >>> Freesurfer mailing list >>> Freesurfer(a)nmr.mgh.harvard.edu >>> https://mail.nmr.mgh.harvard.**edu/mailman/listinfo/** >>> freesurfer<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<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

Problem in building FreeSurfer from source
by Akio Yamamoto 16 May '12

16 May '12

I'm having a problem in building FreeSurfer from the source codes (both 'stable5' and 'release_5_1_0') downloaded from the CVS repository. When I run 'make', it stopped with the following error message: mri_convert.c:39:40: error: unwarpGradientNonlinearity.h: No such file or directory mri_convert.c: In function 'main': mri_convert.c:1158: error: 'unwarp_flag' undeclared (first use in this function) mri_convert.c:1158: error: (Each undeclared identifier is reported only once mri_convert.c:1158: error: for each function it appears in.) ...... I actually could not find the file "unwarpGradientNonlinearity.h" in the distribution, and am wondering if the open source distribution is confirmed to be successfully built without any modification. Are there additional things that I need to do before running 'make'? Or, is a newer version of the source code available? Thanks, Akio -- Akio Yamamoto Research Associate, The University of Tokyo

1 0

aseg.stats not matching up
by Joshua Lee 16 May '12

16 May '12

Suppose I were to open a subject aseg.mgz in tkmedit, and use the 3D fill tool to relabel the *entire* left hippocampus segmentation to 'MyNewImaginaryLabel'. If I then re-run the aseg stats, should the left hippocampus volume from the original aseg.stats be identical to the volume of MyImaginaryLabel in the newly generated aseg.stats? Every voxel from the prior label is now assigned to the new label; yet, I am getting different results (by about 100 voxels in the ones I've tried). The command Im using to recalculate: mri_segstats --seg /usr/local/freesurfer/subjects/s02/new_MRI/new/aseg.auto.mgz --sum /usr/local/freesurfer/subjects/s02/stats/NEWmethod1aseg_Hipp.stats --pv /usr/local/freesurfer/subjects/s02/mri/norm.mgz --excludeid 0 --brain-vol-from-seg --brainmask /usr/local/freesurfer/subjects/s02/mri/brainmask.mgz --in /usr/local/freesurfer/subjects/s02/mri/norm.mgz --in-intensity-name norm --in-intensity-units MR --etiv --surf-wm-vol --ctab /usr/local/freesurfer/8regions.txt --subject s02; Now if I were to relabel 'MyNewImaginaryLabel' to 'AthirdLabel', and again changing every voxel in 'MyNewImaginaryLabel' to the new label, the computed volumes do not change. This led me to suspect that aseg.mgz contains probability estimates at each voxel that are then subsequently overwritten by my tkmedits. However, per a previous conversation from a year ago or so with Bruce and also the relevant Freesurfer documentation this does not seem to be the case. Partial volume information is not contained within the aseg.mgz (right!?), but is computed by mri_segstats by comparing border voxels with intensities in the norm.mgz. So I am at a loss on why these should be different. This has been replicated in version 4.5 and 5.1 - Joshua Lee Graduate Student Center for Mind and Brain & Department of Psychology University of California, Davis 530.747.3805

2 3

FsFastIndividual Retinotopy - Polar Only
by Daniel Cole 16 May '12

16 May '12

Hello, I have some questions regarding the FsFastIndividual pipeline. I hope you can take a look at the commands I have run and give me some insight into what the problem might potentially be. I have 5 rotating wedge stimuli runs 1. I set up my subject's directories according to the freesurfer tutorial powerpoint and declare my environmental variables using- <*export FREESURFER_HOME=/Volumes/RCBI/freesurfer* *export SUBJECTS_DIR=/Volumes/rcbiUsers/dcole/Retinotopy* *source $FREESURFER_HOME/SetUpFreeSurfer.sh*> Bold data renamed to f.nii.gz and placed into run folders (001, 002, etc) rtopy.par=" stimtype polar direction neg" 2. I then reconstruct the strucutural data using- <*recon-all -i /Volumes/rcbiUsers/dcole/Retinotopy/VG01/raw/VGP01_001.dcm -subjid VG01*> 3. I create the subjectname file, run preprocessing, and make the analysis files. <*preproc-sess -surface self lhrh -fwhm 5 -sf sessid -fsd bold* *mkanalysis-sess -analysis rtopy.self.lh -surface self lh -TR 1.2 -abblocked 38.4 -fsd bold -fwhm 5* *mkanalysis-sess -analysis rtopy.self.rh -surface self rh -TR 1.2 -abblocked 38.4 -fsd bold -fwhm 5*> 4. Then I run the analysis using- <*selxavg3-sess -analysis rtopy.self.lh -sf sessid* *selxavg3-sess -analysis rtopy.self.lh -sf sessid*> ~This step was giving me an error until I added "faux" eccentricity run folders with runs 1-5 functional data copied and rtopy.par files with stimtype eccen. Rerunning these 2 steps with the faux eccentricity data fixed the error message. 5. Create occipital patch with (http://www.alivelearn.net/?p=65) as guideline. Flatten patch using- <*mris_flatten -w 0 -distances 20 7 lh.occip.patch.3d lh.occip.patch.flat* *mris_flatten -w 0 -distances 20 7 rh.occip.patch.3d rh.occip.patch.flat*> And create fieldsign map using- <*fieldsign-sess -a rtopy.self.lh -occip -sf sessid* *fieldsign-sess -a rtopy.self.rh -occip -sf sessid*> ~Error that analysis isn't retinotopy (because I used -abblocked), retrying step 3 with -retinotopy allowed me to create the fieldsign map. --- For the -abblocked and -retinotopy analysis I am able to look at the results using <*tksurfer-sess -a rtopy.self.lh -sf sessid*>*.* My questions are: - Should I be using -abblocked or -retinotopy for a polar only design? - Is it ok to create "faux" eccentricity folders and then only look at the polar data? - Why is it for either of these analyses I can't view the angle map using <*tksurfer-sess -a rtopy.self.?h -s sessid -map angle*>? In fact the angle file is not created. Thanks so much for your time and help. Daniel * * -- Daniel Cole University of Rochester Brain and Cognitive Sciences dcole10(a)u.rochester.edu

2 4

Flip brain
by Tadeu Kubo 16 May '12

16 May '12

Dear FS experts, How can I flip hemispheres? I read the mail list and Doug said that (2010): The problem with this is that you will get different results when you use the left hemi and the right-flipped-to-left hemi as compared to the right hemi and the left-flipped-to-right hemi. You'll actually get different areas that appear to be significant. This is because the right-flipped-to-left is registered to the left template target and it does not register as well as the left registered to the left template target (and the same in the other direction). I'm sure it means something, but I don't know how to interpret it. doug I'm specially interesting because we're studying MTS. The status of this procedure remains the same or it is possible to do it ? Thank you, Tadeu

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