Freesurfer March 2013

freesurfer@nmr.mgh.harvard.edu

155 participants
331 discussions

selxavg3-sess illconditioned error
by Katie Bettencourt 01 Mar '13

01 Mar '13

I am having a problem with selxavg3-sess (for FS 4.5) where it is giving me an Ill-conditioned error that I can't trace out. I have 8 runs that I am running separately (same basic analysis for each run, but each run gets it's own analysis for svm purposes). Originally for this subject, I created an analysis and it ran fine for all 8 runs. I went back and changed the timewindow on the analysis (and only the timewindow) and now, while it runs fine for 7 or the 8 runs, one of them gives me an ill conditioned error during selxavg3-sess. I double checked the paradigm file and all conditions are listed, and the only change between when the analysis ran fine and when it gave me this error was changing the timewindow. The mkanalysis commands I used both times are listed below. Original analysis (worked fine): foreach r (1 2 3 4 5 6 7 8) mkanalysis-sess -analysis grating_nodist_ld_run${r} -TR 2 -paradigm grating.dat -designtype event-related -funcstem fmc -motioncor -runlistfile nodist_run${r}.txt -inorm -tpexclude tpexclude.dat -nconditions 3 -timewindow 22 -TER 2 -noautostimdur -polyfit 2 end new analysis (illconditioned on one run only): foreach r (1 2 3 4 5 6 7 8) mkanalysis-sess -analysis grating_nodist_ld_34_run${r} -TR 2 -paradigm grating.dat -designtype event-related -funcstem fmc -motioncor -runlistfile nodist_run${r}.txt -inorm -tpexclude tpexclude.dat -nconditions 3 -timewindow 34 -TER 2 -noautostimdur -polyfit 2 end Katie

3 11

(no subject)
by stdp82＠virgilio.it 01 Mar '13

01 Mar '13

Hi list, Where Can I find basic information about entorhinal cortex analysis? Thank you very much. Stefano

2 1

Question on stats analysis in Qdec
by Kristina Nalbandian 01 Mar '13

01 Mar '13

Hello, I am running qdec group analysis on my patient data. I am studying the differences between two Epilepsy onset types and have a few questions. 1) I select "subtype" as my discrete variable and "duration" as my continuous variable. In the display tab two questions appear. 1. Does the average thickness differ from zero? and 2. Does the average thickness differ between HYP and LVF (the two onset types)? What is the difference between these two questions? Mainly, can someone please explain question 1 and how that is calculated. 2) Are corrections for multiple comparisons already build into the qdec analysis? or is this something that needs to be run separately. Is permutation testing required to determine how likely the observed level of significant atrophy within each p-map would occur by chance? Thank you in advance, Kristina

2 1

Re: [Freesurfer] set path for BBR
by Chen, Xiaoyan 01 Mar '13

01 Mar '13

Dear all, Thank you so much! It works now. Helen On Mar 1, 2013, at 2:41 PM, Mark Jenkinson wrote: > Hi, > > It looks like your installation isn't right - you need FSL5.0 or higher for this to work. If not I would expect it to complain about: "Unrecognised cost function type: bbr" as it seems to do. > > Maybe you should check that you are picking up the right version of FSL, by doing: > which flirt > and > echo $FSLDIR > > Only if these are both pointing at the same place and are installations of FSL5.0 or higher, would this work. > > All the best, > Mark > > > > > On 1 Mar 2013, at 19:31, Bruce Fischl <fischl(a)nmr.mgh.harvard.edu> > wrote: > >> oh, this is the FSL reimplementation of Doug's algorithm (they loved it so much they had to have their own!). You'll need to ask them about it. I'll cc MJ so he can chime in. >> >> cheers >> Bruce >> >> >> >> >> On Fri, 1 Mar 2013, Chen, Xiaoyan wrote: >> >>> Doug, >>> epi_reg is using BBregister with FSL. In FSL5 they incorporated the tool your guys developed. The following is the error message >>> >>> [mi2b2:OAEAA005] (nmr-stable5.1-env) epi_reg --epi=meanuf-ep2d-18-0001.nii.gz --t1=MPRAGE1.nii.gz --t1brain=MPRAGE1_manual2.nii.gz --out=epi2struct.nii.gz >>> Running FAST segmentation >>> FLIRT pre-alignment >>> Running BBR >>> Unrecognised cost function type: bbr >>> Could not open matrix file epi2struct.mat >>> terminate called after throwing an instance of 'NEWMAT::IncompatibleDimensionsException' >>> /usr/pubsw/packages/fsl/5.0.1/bin/epi_reg: line 353: 47296 Aborted (core dumped) $FSLDIR/bin/applywarp -i ${vepi} -r ${vrefhead} -o ${vout} --premat=${vout}.mat --interp=spline >>> [mi2b2:OAEAA005] (nmr-stable5.1-env) epi_reg --epi=meanuf-ep2d-18-0001.nii.gz --t1=MPRAGE1.nii.gz --t1brain=MPRAGE1_manual2.nii.gz --out=epi2struct >>> Running FAST segmentation >>> FLIRT pre-alignment >>> Running BBR >>> Unrecognised cost function type: bbr >>> Could not open matrix file epi2struct.mat >>> terminate called after throwing an instance of 'NEWMAT::IncompatibleDimensionsException' >>> /usr/pubsw/packages/fsl/5.0.1/bin/epi_reg: line 353: 48263 Aborted (core dumped) $FSLDIR/bin/applywarp -i ${vepi} -r ${vrefhead} -o ${vout} --premat=${vout}.mat --interp=spline >>> >>> >>> >>> Helen >>> >>> ________________________________________ >>> From: freesurfer-bounces(a)nmr.mgh.harvard.edu [freesurfer-bounces(a)nmr.mgh.harvard.edu] on behalf of Douglas N Greve [greve(a)nmr.mgh.harvard.edu] >>> Sent: Friday, March 01, 2013 2:22 PM >>> To: freesurfer(a)nmr.mgh.harvard.edu >>> Subject: Re: [Freesurfer] set path for BBR >>> >>> what is epi_reg? Is that an FS program? >>> >>> On 03/01/2013 02:19 PM, Chen, Xiaoyan wrote: >>>> Hi, >>>> >>>> If I want to use epi_reg, what do I need to do for the environment in fsl? It says that it's not recognizing the function bbr. How do find the path to BBR in /usr/pubsw? >>>> >>>> Thank you very much. >>>> >>>> Helen >>>> _______________________________________________ >>>> Freesurfer mailing list >>>> Freesurfer(a)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 >>> 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 >>> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ >>> >>> _______________________________________________ >>> 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. >> >> >

1 0

RAS coordinates in tksurfer and matlab
by Brinkmann, Benjamin H., Ph.D. 01 Mar '13

01 Mar '13

Dear FreeSurfers, I am working on generating a functional map of electrophysiological activity on a freesurfer pial surface and I've come across something that has stumped me. I have the electrode coordinates in RAS space and I am trying to interpolate a value at each surface vertex for the color map using the RAS coordinate of each vertex. However, the RAS coordinates I read into matlab using freesurfer_read_surf.m are different from what is being displayed in tksurfer. (I'm comparing RAS coordinates by hovering the cursor in tksurfer.) Most of the time the differences are very small, but occasionally they can be large. I haven't been able to identify any kind of a constant offset or relationship between these coordinates. Should the RAS coordinates displayed in tksurfer be the same as what is read directly from the surface file? Is there a better way to approach this task? Thanks very much for any suggestions. Regards, Ben Brinkmann =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Benjamin H. Brinkmann, PhD Mayo Systems Electrophysiology Lab Alfred 9-441C, SMH 1216 Second St. SW Rochester, MN 55902

3 2

set path for BBR
by Chen, Xiaoyan 01 Mar '13

01 Mar '13

Hi, If I want to use epi_reg, what do I need to do for the environment in fsl? It says that it's not recognizing the function bbr. How do find the path to BBR in /usr/pubsw? Thank you very much. Helen

3 5

Re: [Freesurfer] FreeSurfer recon-all two sets of error
by Blessy M 01 Mar '13

01 Mar '13

I have sent the attachment mentioned in the mail below via mail drop. On Thu, Feb 28, 2013 at 4:28 PM, Blessy M <blessam(a)gmail.com> wrote: > The skull stripped image using FS did not look very good, I am not sure if > this was the result of skullt stripping or the fact that the volume was > more than 256^3 (and used -cw256). > So skull stripped it manually, and downsampled it (to be within 256^3mm). > > I am attaching the original image (nii format, is that okay?) with this > mail, I could really use some help with this. > > > > On Thu, Feb 28, 2013 at 11:21 AM, Bruce Fischl <fischl(a)nmr.mgh.harvard.edu > > wrote: > >> have you checked the skull stripping? It looked like it might be cutting >> off some brain. If you upload the subject I'll take a look (although we >> will need the volume before skull stripping). Why are you not stripping >> within FS? That might make life easier for you >> >> cheers >> Bruce >> >> p.s. I think this defect is too large - it's about 1/3 of the cortical >> surface >> >> >> On Thu, 28 Feb 2013, Blessy M wrote: >> >> The process is still running but nothing new written in the last 24 hrs. >>> >>> Excerpts from recon-all.log >>> >>> ...... >>> >>> >>> 77 defects to be corrected >>> 0 vertices coincident >>> reading input surface /home/#########/subjects/./** >>> surf/lh.qsphere.nofix... >>> reading brain volume from brain... >>> reading wm segmentation from wm... >>> >>> >>> ....... >>> >>> CORRECTING DEFECT 20 (vertices=71, convex hull=55) >>> After retessellation of defect 20, euler #=-3 (58272,166451,108176) : >>> difference with theory (-54) = -51 >>> >>> CORRECTING DEFECT 21 (vertices=17, convex hull=34) >>> After retessellation of defect 21, euler #=-2 (58273,166465,108190) : >>> difference with theory (-53) = -51 >>> >>> CORRECTING DEFECT 22 (vertices=39536, convex hull=7215) >>> >>> >>> Help! >>> >>> >>> On Wed, Feb 27, 2013 at 11:37 AM, Blessy M <blessam(a)gmail.com> wrote: >>> >>> 1. It is not contrast enhanced. >>> >>> 2. I am rerunning recon-all after giving it a manually skull >>> stripped image. Hopefully this will work. >>> >>> So basically did this: >>> >>> recon-all -subjid . -autorecon1 -noskullstrip -notal-check >>> cp T1.mgz brainmask.auto.mgz >>> ln -s brainmask.auto.mgz brainmask.mgz >>> recon-all -subjid . -autorecon2 -autorecon3 >>> >>> >>> >>> >>> On Tue, Feb 26, 2013 at 3:10 PM, Bruce Fischl >>> <fischl(a)nmr.mgh.harvard.edu> wrote: >>> thanks. I actually meant a tksurfer image, but this >>> might do. Two questions: >>> >>> 1. Is this a contrast-enhanced acquisition? That >>> will make things more difficult, although we have >>> processed them in the past. >>> >>> 2. I think the skull stripping removed some brain >>> tissue, which may be the source of your large >>> defects. Can you please check it and get back to us? >>> This also might be due to the contrast enhancement. >>> >>> cheers >>> Bruce >>> >>> >>> On Tue, 26 Feb 2013, Blessy M wrote: >>> >>> I should have send it with an extension. >>> But it is tiff, just as you asked. >>> >>> On Tue, Feb 26, 2013 at 3:03 PM, Bruce >>> Fischl <fischl(a)nmr.mgh.harvard.edu> >>> wrote: >>> Hi Blessy >>> >>> what format is this? If you don't >>> send it with an extension there is no >>> way to know.... >>> Bruce >>> On Tue, 26 Feb 2013, Blessy M >>> wrote: >>> >>> Forgot the image. please >>> find attached. >>> >>> >>> On Tue, Feb 26, 2013 at 2:45 >>> PM, Blessy M <blessam(a)gmail.com> wrote: >>> I ran this command, >>> and got the attached image >>> tkmedit ./ >>> brainmask.mgz lh.inflated.nofix >>> >>> For some reason >>> tksurfer is not looking good/complete >>> tksurfer ./ lh >>> inflated >>> >>> >>> On Tue, Feb 26, 2013 >>> at 11:53 AM, Bruce Fischl >>> <fischl(a)nmr.mgh.harvard.edu> wrote: >>> you can save a >>> tif of it and post it to the list >>> On Tue, 26 Feb >>> 2013, Blessy M wrote: >>> >>> Yes it is >>> still at defect 32. >>> >>> The tail >>> of the recon-all.log is as follows: >>> >>> CORRECTING >>> DEFECT 30 (vertices=18, convex hull=22) >>> After >>> retessellation of defect 30, euler #=-7 >>> (59491,172395,112897) : difference with >>> theory >>> (-28) = >>> -21 >>> >>> CORRECTING >>> DEFECT 31 (vertices=244, convex >>> hull=142) >>> After >>> retessellation of defect 31, euler #=-6 >>> (59502,172495,112987) : difference with >>> theory >>> (-27) = >>> -21 >>> >>> CORRECTING >>> DEFECT 32 (vertices=44865, convex >>> hull=8969) >>> >>> >>> Should I >>> attach the lh.inflated.nofix in a >>> separate email to you, Bruce? >>> >>> >>> >>> On Tue, >>> Feb 26, 2013 at 10:08 AM, Bruce Fischl >>> <fischl(a)nmr.mgh.harvard.edu> wrote: >>> is >>> it still on defect 32? What does the >>> tail of the recon-all.log say? And can >>> you >>> send us an >>> image of the >>> >>> lh.inflated.nofix (if it is the lh that >>> is running)? >>> >>> On >>> Tue, 26 Feb 2013, Blessy M wrote: >>> >>> >>> I verified lh.orig.nofix, and it looks >>> fine. But, there has been no new >>> files >>> created >>> since Saturday >>> >>> (2/23/2013). >>> >>> >>> I am considering stopping the process. >>> >>> >>> I was thinking, I had created a skull >>> stripped image, and was giving that >>> as >>> input to >>> recon-all in the >>> >>> command below: >>> >>> recon-all -subjid . -noskullstrip >>> -autorecon1 -notal-check -autorecon2 >>> >>> -autorecon3 >>> >>> >>> Should -noskullstrip flag be after >>> autorecon1? >>> >>> >>> >>> >>> On Mon, Feb 25, 2013 at 3:35 PM, Bruce >>> Fischl <fischl(a)nmr.mgh.harvard.edu> >>> wrote: >>> >>> try looking at the >>> lh.inflated.nofix or lh.orig.nofix (or >>> rh, >>> whichever >>> one is >>> running) and see if >>> >>> something is >>> >>> dramatically wrong (like skull >>> attached to brain, or hemis >>> connected, >>> etc....) >>> >>> On Mon, 25 Feb 2013, Blessy M >>> wrote: >>> >>> >>> Recon is still running. I >>> started the process on 2/21/2013. >>> Its been >>> 4 days. >>> >>> >>> I ran this command, and >>> viewed the aseg file, and that looks >>> reasonable >>> >>> tkmedit ./ brainmask.mgz >>> -aux T1.mgz -surfs -aseg >>> >>> >>> Currently it is at this >>> stage: >>> >>> >>> Correction of the Topology >>> >>> Finding true center and >>> radius of Spherical Surface...done >>> >>> Surface centered at >>> (0,0,0) with radius 100.0 in 13 >>> iterations >>> >>> marking ambiguous >>> vertices... >>> >>> 124766 ambiguous faces >>> found in tessellation >>> >>> segmenting defects... >>> >>> ...... >>> >>> >>> 61 defects to be corrected >>> >>> 0 vertices coincident >>> >>> ...... >>> >>> ...... >>> >>> CORRECTING DEFECT 31 >>> (vertices=244, convex hull=142) >>> >>> After retessellation of >>> defect 31, euler #=-6 >>> (59502,172495,112987) >>> : >>> difference with theory >>> >>> (-27) = -21 >>> >>> >>> CORRECTING DEFECT 32 >>> (vertices=44865, convex hull=8969) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Feb 22, 2013 at >>> 5:33 PM, Bruce Fischl >>> >>> <fischl(a)nmr.mgh.harvard.edu> wrote: >>> >>> I don't think either >>> one of these are errors, just >>> warnings >>> that occur >>> pretty >>> >>> frequently and I >>> >>> don't think should >>> >>> impact the results. >>> Does the recon finish? Do the >>> results look >>> ok? >>> >>> >>> On Fri, 22 Feb 2013, >>> Blessy M wrote: >>> >>> >>> >>> I am getting >>> the bottom two sets of errors while >>> doing a >>> simple >>> recon-all. >>> >>> >>> More >>> specifically while running this command: >>> >>> recon-all >>> -subjid . -noskullstrip -autorecon1 >>> >>> -notal-check -autorecon2 >>> >>> -autorecon3 >>> >>> >>> Has someone >>> encountered this kind of errors? Is >>> there a >>> fix? >>> >>> >>> 1) >>> >>> Computing MAP >>> estimate using 2772 samples... >>> >>> >>> ********************************************** >>> >>> IFLAG= -1 >>> LINE SEARCH FAILED. SEE DOCUMENTATION >>> OF >>> ROUTINE >>> MCSRCH ERROR >>> >>> RETURN OF LINE >>> SEARCH: INFO= 6 POSSIBLE CAUSES: >>> FUNCTION >>> OR >>> GRADIENT ARE >>> >>> INCORRECT OR >>> INCORRECT TOLERANCESoutof >>> QuasiNewtonEMA: >>> 011: >>> -log(p) = >>> >>> 7296.5 tol >>> 0.000010 >>> >>> ... >>> >>> ... >>> >>> >>> 2) >>> >>> unfolding >>> failed - restoring original position >>> >>> -------------------- >>> >>> 0146: >>> dt=13.779160, rms=0.814 (0.000%), neg=0, >>> >>> invalid=766 >>> >>> blurring input >>> image with Gaussian with >>> sigma=0.500... >>> >>> 0000: >>> dt=0.000, rms=0.814, neg=0, invalid=766 >>> >>> >>> gcamFindOptimalTimeStep: Complete in >>> 101542.133 ms >>> >>> iter 0, >>> gcam->neg = 801 >>> >>> >>> >>> ...................... >>> >>> >>> unfolding >>> failed - restoring original position >>> >>> -------------------- >>> >>> 0158: >>> dt=13.828393, rms=0.814 (-0.069%), >>> neg=0, >>> >>> invalid=766 >>> >>> blurring input >>> image with Gaussian with >>> sigma=0.500... >>> >>> 0000: >>> dt=0.000, rms=0.814, neg=0, invalid=766 >>> >>> >>> gcamFindOptimalTimeStep: Complete in >>> 100610.148 ms >>> >>> >>> >>> >>> >>> >>> 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

Citing bbregister in articles
by Christopher 01 Mar '13

01 Mar '13

Hi, Just a quick question to the Freesurfer creators : how could I cite the bbregister command line in an article ? I didn't find the correct article in the Freesurfer Wiki. Thanks, -- Christopher Coello, Ph.D. Preclinical PET/CT unit Institute of Basic Medical Sciences Faculty of Medicine, University of Oslo, Norway tel. +4745154516

2 1

bbregister with SPM
by Chen, Xiaoyan 01 Mar '13

01 Mar '13

Dear freesurfer experts, I have a question regarding how to incorporating bbregister coregistered mean image into the SPM batch. After realignment step, I convert the mean functional image from the analyze format to nii format (to avoid flipping brain using bbregister) Then, I use bbregister to co-register the mean functional image to subjects' surfaces using following command bbregister -- s subject_name_freesurfer -- mov mean.nii --init-spm -- bold --reg register.dat -- spm-nii After this step, is the mean.nii the coregistered image already? If it is, in SPM, shall I skip the coregistration and segmentation step? If I do skip them, in the Normalization step, is the following correct? source image: mean.nii that has been coregistered in bbregister image to write: (Dependency) realigned session1 and realigned session2 template image: EPI Thank you very much for your help. Helen

2 2

Re: [Freesurfer] Qdec
by Martin Reuter 01 Mar '13

01 Mar '13

Hi chikku. Yes all steps are necessary (see the description on the wiki). First all time points need to be processed cross sectionally. Best Martin Varghese Chikku <chikkuv(a)tcd.ie> wrote: >Martin, >Forgive my ignorance and sorry to pester you. From what you said in >the >mail, >*The base is like an additional time point so it does run from the >start and >even contains some extra steps. 12hrs are not unlikely´´ * In this >case >Do I need to run recon-all -s autorecon-all at all.If i have a >patient >can i omit the initial recon-all process and straight away go ahead >and >do recon-all -base <templateID> -tp <tp1id> -tp <tp2id> ...? >Much appreciate your feedback, >In Thanks >chikku > > >On 27 February 2013 21:30, Martin Reuter <mreuter(a)nmr.mgh.harvard.edu> >wrote: >> Hi Chikku, >> >> the -qcache command is for cross sectional processing. It is not done >in >the >> base and does not need to be done there. >> >> The base is like an additional time point so it does run from the >start >and >> even contains some extra steps. 12hrs are not unlikely. >> >> You will need to also run the recon all again on all time points with >the >> -long flag. >> >> Then, once those are processed, you have several options for the >analysis, >> see >> http://surfer.nmr.mgh.harvard.edu/fswiki/LongitudinalStatistics >> >> we recommend linear mixed effects, described here: >> http://surfer.nmr.mgh.harvard.edu/fswiki/LinearMixedEffectsModels >> but in your simple setup (2 time points for each subject), you can >also >use >> the direct analysis of atrophy. For that you'd do >> a) run some processing scripts that compute the rate of change in >each >> subject (e.g. long_mris_slopes or long_stats_slopes) >> b) use mri_glmfit or qdec to analyze those rates (one for each >subject) >> across groups etc. >> That is described here: >> http://surfer.nmr.mgh.harvard.edu/fswiki/LongitudinalTwoStageModel >> >http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/LongitudinalTutorial >> >> Best, Martin >> >> >> On 02/27/2013 11:19 AM, Varghese Chikku wrote: >>> >>> Dear all, >>> I am bit confused with the Qdec process. >>> I finished recon all for 2 time points and want to create >>> longitudinal data.From FS tutorial I learned to create >>> within-subject templates for processing,which is running now with >>> recon-all -base <templateID> -tp <tp1id> -tp <tp2id> ... -all. >>> Now,in an other link of tutorial it says ,Qdec needs each subject to >>> have a pre-computed smoothed data for the target surface ,recon-all >-s >>> <subjid> -qcache >>> So my first is question is, recon-all -base <templateID> -tp <tp1id> >>> -tp <tp2id> ... -all will do recon-all -s <subjid> -qcache along or >I >>> have to run it separately. >>> Second,recon-all -base <templateID> -tp <tp1id> -tp <tp2id> ... -all >>> is almost 12 hrs now and wondering if this is processing images >>> from the very begining. >>> Many Thanks >>> chikku >>> _______________________________________________ >>> Freesurfer mailing list >>> Freesurfer(a)nmr.mgh.harvard.edu >>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> >> >> -- >> Dr. Martin Reuter >> Assistant in Neuroscience - Massachusetts General Hospital >> Instructor in Neurology - Harvard Medical School >> MGH / HMS / MIT >> >> A.A.Martinos Center for Biomedical Imaging >> 149 Thirteenth Street, Suite 2301 >> Charlestown, MA 02129 >> >> Phone: +1-617-724-5652 >> Email: >> mreuter(a)nmr.mgh.harvard.edu >> reuter(a)mit.edu >> Web : http://reuter.mit.edu >> >> >> >> 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. >> >> -- Sent from my phone, please excuse brevity.

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 March 2013