Freesurfer

freesurfer@nmr.mgh.harvard.edu

30132 discussions

Re: [Freesurfer] fsaverage rh to fsaverage_sym lh question
by Douglas N Greve 21 Oct '11

21 Oct '11

Oh, you should not be running xhemireg (or anything else) on fsaverage. doug Ritobrato Datta wrote: > it is where it is choking...saying nu.mgz and norm.mgz not found > > mri_convert fsaverage/mri/nu.mgz fsaverage/xhemi/mri/nu.mgz --left-right-reverse > mri_convert fsaverage/mri/norm.mgz fsaverage/xhemi/mri/norm.mgz --left-right-reverse > > > > ----- Original Message ----- > From: "Douglas N Greve" <greve(a)nmr.mgh.harvard.edu> > To: "Ritobrato Datta" <ridatta(a)mail.med.upenn.edu> > Sent: Friday, October 21, 2011 5:12:26 PM > Subject: Re: fsaverage rh to fsaverage_sym lh question > > what is it that needs those files? > > Ritobrato Datta wrote: > >> that ok but it cant find the nu.mgz and norm.mgz in fsaverage/mri >> >> it needs those files to flip them left right reverse. >> >> >> ----- Original Message ----- >> From: "Douglas N Greve" <greve(a)nmr.mgh.harvard.edu> >> To: "Ritobrato Datta" <ridatta(a)mail.med.upenn.edu>, "freesurfer" <freesurfer(a)nmr.mgh.harvard.edu> >> Sent: Friday, October 21, 2011 4:44:29 PM >> Subject: Re: fsaverage rh to fsaverage_sym lh question >> >> I think it just needs something there to get the volume geometry from. >> Does orig.mgz exist? If not, re-download fsaverage_sym.tar.gz and >> re-install it (the new version has an orig.mgz). >> doug >> >> Ritobrato Datta wrote: >> >> >>> Hi Doug, >>> >>> I am trying to apply ur scripts to register fsaverage rh to fsaverage_sym lh and the script fails saying it cant find nu.mgz >>> >>> Looks like two files that are missing in >>> >>> fsaverage/mri >>> >>> are >>> >>> nu.mgz and norm.mgz >>> >>> How can I create them in fsaverage ? >>> >>> >>> or any other suggestions how to get fsaverage rh to fsaverage_sym lh ? >>> >>> Thanks a lot >>> >>> Rito >>> >>> >>> >>> >>> >> >> > > -- 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

map of vertices (by number) within an R01
by Polly Dhond 21 Oct '11

21 Oct '11

Hi FS, Is there a way to map the loction of several vertices with (numbers as labels) in an ROI ? For example I have a small R0I with 30 vetices in it, i have their numbers as a list but i want to see how they map with respect to one another (all at once). thanks -- Rupali P. Dhond, Ph.D. Dept. of Radiology, MGH-HMS Martinos Center for Biomedical Imaging Rm 2301, Bldg 149, 13th Street Charlestown, MA 02129 e-mail: polly(a)nmr.mgh.harvard.edu phone: 617-726-6542

2 1

Re: [Freesurfer] fsaverage rh to fsaverage_sym lh question
by Douglas N Greve 21 Oct '11

21 Oct '11

I think it just needs something there to get the volume geometry from. Does orig.mgz exist? If not, re-download fsaverage_sym.tar.gz and re-install it (the new version has an orig.mgz). doug Ritobrato Datta wrote: > Hi Doug, > > I am trying to apply ur scripts to register fsaverage rh to fsaverage_sym lh and the script fails saying it cant find nu.mgz > > Looks like two files that are missing in > > fsaverage/mri > > are > > nu.mgz and norm.mgz > > How can I create them in fsaverage ? > > > or any other suggestions how to get fsaverage rh to fsaverage_sym lh ? > > Thanks a lot > > Rito > > > -- 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

Freesurfer Error Message in running autorecon2 & autorecon3
by Vy Dinh 21 Oct '11

21 Oct '11

Dear Experts, I ran the wm.mgz corrections and pial corrections using the command: -autorecon2 –autorecon3 –subjid sub2 However, Freesurfer exited the program with the following message: SUBJECTS_DIR /Users/subdir FREESURFER_HOME Applications/freesurfer Loading source label. No such file or directory fsaverage/label/lh.BA1.label ERROR reading /Users/subdir/ fsaverage/label/lh.BA1.label Darwin mso00820bg.rush.edu<http://mso00820bg.rush.edu> 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 recon-all -s sub2 exited with ERRORS at Thu Oct 20 05:12:34 CDT 2011. Can someone please explain what this error message means regarding whether I need to rerun the autorecon processes with the fsaverage folder within my current subjects folder? I copied fsaverage/ from freesurfer/ to my designated SUBJECTS_DIR but have not run the recon. It seems that the pial surfaces were regenerated while the white matter segment was not corrected for this one subject. I ran other subjects within this SUBJECTS_DIR (before I copied the fsaverage folder) but the white matter segment and pial surfaces were regenerated for them. Looking forward to your responses. Thank you, Vy T.U. Dinh Research Assistant, Neurological Sciences Rush University Medical Center Phone: (312) 563-3853 Fax: (312) 563-4660 Email: Vy_dinh(a)rush.edu<mailto:Vy_dinh@rush.edu>

2 10

Re: [Freesurfer] trac-all results
by Anastasia Yendiki 21 Oct '11

21 Oct '11

Hi Ping-Hong, Yes, you can set usemaskanat = 0 in your dmrirc, and then the brain mask will be extracted from the DWI data by the bet tool, instead of using the aparc+aseg. But, and this is a big but, TRACULA uses the aparc+aseg to constrain the tractography solutions, i.e. the aparc+aseg is where the UnderLying Anatomy in TRACULA comes from. So the quality of the trac-all results depend on the quality of the aparc+aseg regardless of where your mask came from. a.y On Fri, 14 Oct 2011, Ping-Hong Yeh wrote: > Hi Anastasia, > > Can trac-all just use the mask in diffusion native space (by setting > "usemaskanat = 0"? ) so I get around the T1 segmentation problem from > FS recon? > > It seems that there is no quick answer on fixing the aparc+aseg? > > Thank you, > p > > > > > On Tue, Oct 11, 2011 at 10:35 PM, Anastasia Yendiki > <ayendiki(a)nmr.mgh.harvard.edu> wrote: >> >> I'll have to refer you back to the freesurfer list for that one. There are >> people with much more expertise than me on troubleshooting the recon-all >> stream. >> >> Once you get your recons fixed, you'll have to rerun all trac-all steps >> except 1.1 (image corrections). >> >> On Tue, 11 Oct 2011, Ping-Hong Yeh wrote: >> >>> The original aparc+aseg are not good, at least for these two cases. So >>> which parameters in recon-all should be tweaked? >>> >>> On Tue, Oct 11, 2011 at 5:38 PM, Anastasia Yendiki >>> <ayendiki(a)nmr.mgh.harvard.edu> wrote: >>>> >>>> Is the original aparc+aseg from the freesurfer recon not good either >>>> (from >>>> mri/aparc+aseg.mgz)? Or is it messed up only after registration into >>>> diffusion space (dlabel/diff/aparc+aseg.flt.nii.gz, >>>> dlabel/diff/aparc+aseg.bbr.nii.gz)? This will determine if the freesurfer >>>> recon needs to be fixed or if the registration needs to fixed. >>>> >>>> On Tue, 11 Oct 2011, Ping-Hong Yeh wrote: >>>> >>>>> yeap, the aparc+aseg_masks are not good. >>>>> Any way to fix this? Thanks. >>>>> >>>>> On Tue, Oct 11, 2011 at 5:00 PM, Anastasia Yendiki >>>>> <ayendiki(a)nmr.mgh.harvard.edu> wrote: >>>>>> >>>>>> I see, the mask may be the answer to the initialization failures! It >>>>>> seems >>>>>> like the fmajor you sent me also has its endings masked out? That'd >>>>>> cause >>>>>> it >>>>>> to fail. I wish I'd thought of this earlier! >>>>>> >>>>>> With usemaskanat = 1, the mask that's used is a slightly dilated >>>>>> version >>>>>> of >>>>>> the aparc+aseg from the FS recon, mapped to diffusion space. So if the >>>>>> aparc+aseg has those parts missing, or if the diffusion-anatomical >>>>>> registration is not good, parts will be masked out that shouldn't. The >>>>>> anatomical mask can be found in dlabel/diff/aparc+aseg_mask* (if you've >>>>>> run >>>>>> both flirt and bbregister registrations, there'll be 2 of them). Does >>>>>> this >>>>>> mask look like something went wrong? >>>>>> >>>>>> On Tue, 11 Oct 2011, Ping-Hong Yeh wrote: >>>>>> >>>>>>> I used the default, i.e. set usemaskanat =1, but it looks that tracts >>>>>>> were not reconstructed at the place where it was masked out (see the >>>>>>> cross-bar at L_unc.png). >>>>>>> >>>>>>> I still have no luck in fixing the initialization issue (see >>>>>>> fmajor.png for example). >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> >>>>>>> On Tue, Oct 11, 2011 at 3:19 PM, Anastasia Yendiki >>>>>>> <ayendiki(a)nmr.mgh.harvard.edu> wrote: >>>>>>>> >>>>>>>> Hi Ping - If you're using the anatomical brain as a mask (set >>>>>>>> usemaskanat >>>>>>>> = >>>>>>>> 1, which is the default), then the diffusion-based mask won't have an >>>>>>>> effect >>>>>>>> on your outputs. >>>>>>>> >>>>>>>> BTW, have you had any luck with your initialization issues? Sorry I >>>>>>>> haven't >>>>>>>> had another chance to look at your data since we last emailed, I got >>>>>>>> bogged >>>>>>>> down with some other stuff. >>>>>>>> >>>>>>>> a.y >>>>>>>> >>>>>>>> On Tue, 11 Oct 2011, Ping-Hong Yeh wrote: >>>>>>>> >>>>>>>>> Hi Anastasia, >>>>>>>>> >>>>>>>>> I'd like to lower the bet threshold value by "set thrbet = 0.01" for >>>>>>>>> skull-stripping because some of the brains have been cut, but it >>>>>>>>> does >>>>>>>>> not seem to make any changes (see attached). >>>>>>>>> >>>>>>>>> Any suggestion? Thank you, >>>>>>>>> >>>>>>>>> Ping >>>>>>>>> >>>>>>>>> On Fri, Sep 30, 2011 at 12:09 PM, Anastasia Yendiki >>>>>>>>> <ayendiki(a)nmr.mgh.harvard.edu> wrote: >>>>>>>>>> >>>>>>>>>> Yes! Please add the "set reinit = 1" to the file that you pass with >>>>>>>>>> -c. >>>>>>>>>> >>>>>>>>>> On Fri, 30 Sep 2011, Ping-Hong Yeh wrote: >>>>>>>>>> >>>>>>>>>>> so I should pass with the -c argument instead? >>>>>>>>>>> >>>>>>>>>>> On Fri, Sep 30, 2011 at 12:04 PM, Anastasia Yendiki >>>>>>>>>>> <ayendiki(a)nmr.mgh.harvard.edu> wrote: >>>>>>>>>>>> >>>>>>>>>>>> That file gets overwritten by whatever is in the file that you >>>>>>>>>>>> pass >>>>>>>>>>>> with >>>>>>>>>>>> the >>>>>>>>>>>> -c argument to trac-all. Sorry for the confusion. >>>>>>>>>>>> >>>>>>>>>>>> On Fri, 30 Sep 2011, Ping-Hong Yeh wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I edited the file under scripts/dmrirc.local >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Sep 30, 2011 at 12:00 PM, Anastasia Yendiki >>>>>>>>>>>>> <ayendiki(a)nmr.mgh.harvard.edu> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Ping - Thanks for trying that. When you say in the >>>>>>>>>>>>>> dmrirc.local, >>>>>>>>>>>>>> do >>>>>>>>>>>>>> you >>>>>>>>>>>>>> mean that you edit the file under scripts/dmrirc.local, or the >>>>>>>>>>>>>> file >>>>>>>>>>>>>> that >>>>>>>>>>>>>> you >>>>>>>>>>>>>> pass to trac-all as "-c dmrirc"? >>>>>>>>>>>>>> >>>>>>>>>>>>>> a.y >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, 30 Sep 2011, Ping-Hong Yeh wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Anastasia, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've rerun NCNC0047, the one I sent you, and another one, but >>>>>>>>>>>>>>> it >>>>>>>>>>>>>>> does >>>>>>>>>>>>>>> not help fixing the tracts. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I redone trac-all -prior with "set reinit =1" in the >>>>>>>>>>>>>>> dmrirc.local >>>>>>>>>>>>>>> file >>>>>>>>>>>>>>> and then trac-all -path >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Any further suggestions? Thanks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ping >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Sep 29, 2011 at 5:58 PM, Anastasia Yendiki >>>>>>>>>>>>>>> <ayendiki(a)nmr.mgh.harvard.edu> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I wonder if the problem is with the replacement executables >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> snow >>>>>>>>>>>>>>>> leopard. They should not have a time stamp of April 14th, I >>>>>>>>>>>>>>>> don't >>>>>>>>>>>>>>>> know >>>>>>>>>>>>>>>> how >>>>>>>>>>>>>>>> that could've happened. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Can you please try copying the version that I'm attaching and >>>>>>>>>>>>>>>> running >>>>>>>>>>>>>>>> first >>>>>>>>>>>>>>>> trac-all -prior and then trac-all -path with it? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If this version works, I'll have to reupload it and let >>>>>>>>>>>>>>>> everyone >>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> list >>>>>>>>>>>>>>>> know. Thanks! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thu, 29 Sep 2011, Ping-Hong Yeh wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The dmri_* files in the $freesurfer/bin are all after May, >>>>>>>>>>>>>>>>> 2011 >>>>>>>>>>>>>>>>> (see >>>>>>>>>>>>>>>>> attached). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think the one version, which failed on the MAC, has been >>>>>>>>>>>>>>>>> replaced >>>>>>>>>>>>>>>>> by >>>>>>>>>>>>>>>>> the newer version. Is there a way to make sure the old >>>>>>>>>>>>>>>>> version >>>>>>>>>>>>>>>>> has >>>>>>>>>>>>>>>>> been deleted? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, Sep 29, 2011 at 4:28 PM, Anastasia Yendiki >>>>>>>>>>>>>>>>> <ayendiki(a)nmr.mgh.harvard.edu> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The problem would be if the programs that trac-all runs >>>>>>>>>>>>>>>>>> (dmri_*) >>>>>>>>>>>>>>>>>> were >>>>>>>>>>>>>>>>>> from a >>>>>>>>>>>>>>>>>> version earlier than the stable 5.1 release, which was made >>>>>>>>>>>>>>>>>> public >>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>> late >>>>>>>>>>>>>>>>>> May. Do you think you might have a different version on >>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>> machine >>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>> whatever reason? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Thu, 29 Sep 2011, Ping-Hong Yeh wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, Anastasia, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Most of the T1 segmentation results were done on another >>>>>>>>>>>>>>>>>>> machine >>>>>>>>>>>>>>>>>>> using >>>>>>>>>>>>>>>>>>> V4.4.0, but the one running trac-all is on the machine >>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>> "freesurfer-i686-apple-darwin9.8.0-stable5-20110525". Can >>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>> cause >>>>>>>>>>>>>>>>>>> the problem? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> p >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Thu, Sep 29, 2011 at 1:43 PM, Anastasia Yendiki >>>>>>>>>>>>>>>>>>> <ayendiki(a)nmr.mgh.harvard.edu> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, Ping, I got the files. The Apr 14th build time >>>>>>>>>>>>>>>>>>>> stamp >>>>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>> suspicious, >>>>>>>>>>>>>>>>>>>> since the official 5.1 release was a month later, and >>>>>>>>>>>>>>>>>>>> these >>>>>>>>>>>>>>>>>>>> initialization >>>>>>>>>>>>>>>>>>>> issues were mostly what I was debugging during that >>>>>>>>>>>>>>>>>>>> month. >>>>>>>>>>>>>>>>>>>> When >>>>>>>>>>>>>>>>>>>> was >>>>>>>>>>>>>>>>>>>> your >>>>>>>>>>>>>>>>>>>> version of freesurfer installed? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Thu, 29 Sep 2011, Ping-Hong Yeh wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi Anastasia, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I followed the instruction on >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> http://surfer.nmr.mgh.harvard.edu/fswiki/FtpFileExchange >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> see if you can find the file there. Indeed I've re-run >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>> sent >>>>>>>>>>>>>>>>>>>>> you last night, now it seems OK for that particular >>>>>>>>>>>>>>>>>>>>> case. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I've loaded another one to the >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> https://www.nmr.mgh.harvard.edu/facility/filedrop/index.html >>>>>>>>>>>>>>>>>>>>> (still >>>>>>>>>>>>>>>>>>>>> loading while writing this email), which has severe >>>>>>>>>>>>>>>>>>>>> ventricular >>>>>>>>>>>>>>>>>>>>> dilatation and the result of right anterior thalamic >>>>>>>>>>>>>>>>>>>>> radiation >>>>>>>>>>>>>>>>>>>>> path >>>>>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>> not right. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I've attached the picture of another case failed at >>>>>>>>>>>>>>>>>>>>> forceps >>>>>>>>>>>>>>>>>>>>> major >>>>>>>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>>>>>> the first attempt, and the snapshot after manually >>>>>>>>>>>>>>>>>>>>> picking >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> initial >>>>>>>>>>>>>>>>>>>>> points. The gray scale intensity is still not right, >>>>>>>>>>>>>>>>>>>>> i.e. >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> initial >>>>>>>>>>>>>>>>>>>>> path is very high (yellow), the others are significantly >>>>>>>>>>>>>>>>>>>>> low, >>>>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>> not I've usually seen. Does the gray scale still >>>>>>>>>>>>>>>>>>>>> represent >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> likelihood (probability) of path or something else now? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Here is the output of dmri_train --all-info: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ProgramName: dmri_train ProgramArguments: --all-info >>>>>>>>>>>>>>>>>>>>> ProgramVersion: >>>>>>>>>>>>>>>>>>>>> $Name: $ TimeStamp: 2011/09/29-16:41:32-GMT >>>>>>>>>>>>>>>>>>>>> BuildTimeStamp: >>>>>>>>>>>>>>>>>>>>> Apr >>>>>>>>>>>>>>>>>>>>> 14 >>>>>>>>>>>>>>>>>>>>> 2011 15:35:19 CVS: User: twbrkmp2 Machine: >>>>>>>>>>>>>>>>>>>>> twbrkmp2s-Mac-Pro-5.local Platform: Darwin >>>>>>>>>>>>>>>>>>>>> PlatformVersion: >>>>>>>>>>>>>>>>>>>>> 10.8.0 >>>>>>>>>>>>>>>>>>>>> CompilerName: GCC CompilerVersion: 40200 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thank you, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Ping >>>>>>>>>>>>>>>>>>>>> On Thu, Sep 29, 2011 at 11:37 AM, Anastasia Yendiki >>>>>>>>>>>>>>>>>>>>> <ayendiki(a)nmr.mgh.harvard.edu> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi Ping - Did you try to attach it to your email? I >>>>>>>>>>>>>>>>>>>>>> didn't >>>>>>>>>>>>>>>>>>>>>> get >>>>>>>>>>>>>>>>>>>>>> anything. >>>>>>>>>>>>>>>>>>>>>> Please try our file drop site: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> https://www.nmr.mgh.harvard.edu/facility/filedrop/index.html >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> a.y >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Wed, 28 Sep 2011, Ping-Hong Yeh wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Anastasia, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I've loaded the file, pingforAY.tar.gz >>>>>>>>>>>>>>>>>>>>>>> This example data set failed in forceps major in flt >>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>> L >>>>>>>>>>>>>>>>>>>>>>> slfp >>>>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>> bbr. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thank you very much. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Ping >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Wed, Sep 28, 2011 at 6:17 PM, Anastasia Yendiki >>>>>>>>>>>>>>>>>>>>>>> <ayendiki(a)nmr.mgh.harvard.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Hi Ping - You can upload your data if you want me to >>>>>>>>>>>>>>>>>>>>>>>> take >>>>>>>>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>>>>>>> look >>>>>>>>>>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>>>>>>>>> it. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 1. The initial points ideally should be along the >>>>>>>>>>>>>>>>>>>>>>>> midline >>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> pathway, >>>>>>>>>>>>>>>>>>>>>>>> starting from one end region of the pathway and going >>>>>>>>>>>>>>>>>>>>>>>> all >>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> way >>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> other end region. (The default number is 5 control >>>>>>>>>>>>>>>>>>>>>>>> points >>>>>>>>>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>>>>>>>> "set >>>>>>>>>>>>>>>>>>>>>>>> ncpts = ..." in your dmrirc to change that.) >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 2. You can look in >>>>>>>>>>>>>>>>>>>>>>>> $FREESURFER_HOME/bin/dmrirc.example >>>>>>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>> how >>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>> specify >>>>>>>>>>>>>>>>>>>>>>>> the field map inputs. They don't need to have the >>>>>>>>>>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>>>>>>>>>> matrix >>>>>>>>>>>>>>>>>>>>>>>> size >>>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>> resolution as the DWIs. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 3a. If it's the initialization that's failed, the >>>>>>>>>>>>>>>>>>>>>>>> output >>>>>>>>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> initial path and nothing else (which is I think what >>>>>>>>>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>>>>>>>> mean >>>>>>>>>>>>>>>>>>>>>>>> by >>>>>>>>>>>>>>>>>>>>>>>> "fewer >>>>>>>>>>>>>>>>>>>>>>>> voxels"). >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 3b. The diffusion model used here is the same as the >>>>>>>>>>>>>>>>>>>>>>>> ball-and-stick >>>>>>>>>>>>>>>>>>>>>>>> model >>>>>>>>>>>>>>>>>>>>>>>> that FSL uses. If the threshold you're referring to >>>>>>>>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> minimum >>>>>>>>>>>>>>>>>>>>>>>> volume >>>>>>>>>>>>>>>>>>>>>>>> fraction for the anisotropic compartments of that >>>>>>>>>>>>>>>>>>>>>>>> model, >>>>>>>>>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>>>>>>>> "set >>>>>>>>>>>>>>>>>>>>>>>> fmin = >>>>>>>>>>>>>>>>>>>>>>>> ..." in your dmrirc to choose one. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I hope this helps a bit! >>>>>>>>>>>>>>>>>>>>>>>> a.y >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, 28 Sep 2011, Ping-Hong Yeh wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi Anastasia, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I've tried both options, the choice 1 fixed some of >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> cases, >>>>>>>>>>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>>>>>> not all; and the choice 2 did not work at all. Maybe >>>>>>>>>>>>>>>>>>>>>>>>> I've >>>>>>>>>>>>>>>>>>>>>>>>> missed >>>>>>>>>>>>>>>>>>>>>>>>> something here. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Few more questions: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 1. Will the initial points have to include the >>>>>>>>>>>>>>>>>>>>>>>>> points >>>>>>>>>>>>>>>>>>>>>>>>> around >>>>>>>>>>>>>>>>>>>>>>>>> start, >>>>>>>>>>>>>>>>>>>>>>>>> way, and end points of the tracts need to be >>>>>>>>>>>>>>>>>>>>>>>>> segmented? >>>>>>>>>>>>>>>>>>>>>>>>> Can >>>>>>>>>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>>>>>>>>> enter the points in the main stem of tracts? >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 2. Will EPI distortion correction, like using field >>>>>>>>>>>>>>>>>>>>>>>>> map, >>>>>>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> preprocessing steps help co-registration and thus >>>>>>>>>>>>>>>>>>>>>>>>> improving >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> labeling? So far more than 80% (4 out of 5 data >>>>>>>>>>>>>>>>>>>>>>>>> sets) >>>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> data >>>>>>>>>>>>>>>>>>>>>>>>> have at least one suboptimal tract, either in flt or >>>>>>>>>>>>>>>>>>>>>>>>> bbr. >>>>>>>>>>>>>>>>>>>>>>>>> (BTW, >>>>>>>>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>>>>>>>> flag will call B0 fieldmaps (or phase and magnitude >>>>>>>>>>>>>>>>>>>>>>>>> images) >>>>>>>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>>> distortion correction? Do the fieldmap images need >>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>>>>>>>>>>> matrix size and resolution as DWI? ) >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 3. I wonder why these suboptimal segmented tracts >>>>>>>>>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>> terribly >>>>>>>>>>>>>>>>>>>>>>>>> off the white matter paths but just fewer voxels? >>>>>>>>>>>>>>>>>>>>>>>>> Would >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> probabilistic tractography implemented in FSL be >>>>>>>>>>>>>>>>>>>>>>>>> good >>>>>>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>> working >>>>>>>>>>>>>>>>>>>>>>>>> around this problem by lowering the threshold for >>>>>>>>>>>>>>>>>>>>>>>>> tract >>>>>>>>>>>>>>>>>>>>>>>>> segmentation? >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Ping >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Sep 22, 2011 at 1:18 PM, Anastasia Yendiki >>>>>>>>>>>>>>>>>>>>>>>>> <ayendiki(a)nmr.mgh.harvard.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ping - There are 2 possibilities: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> 1. You can try to fiddle with the initialization >>>>>>>>>>>>>>>>>>>>>>>>>> points >>>>>>>>>>>>>>>>>>>>>>>>>> yourself >>>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>> make >>>>>>>>>>>>>>>>>>>>>>>>>> sure they're well in the CST. The point coordinates >>>>>>>>>>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>>>>>>>> saved >>>>>>>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>>>>>>>>> text >>>>>>>>>>>>>>>>>>>>>>>>>> file >>>>>>>>>>>>>>>>>>>>>>>>>> - look at the --init argument of the dmri_paths >>>>>>>>>>>>>>>>>>>>>>>>>> command >>>>>>>>>>>>>>>>>>>>>>>>>> line, >>>>>>>>>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>>>>>>>>>> find in trac-all.log. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> 2. You can let trac-all select a different >>>>>>>>>>>>>>>>>>>>>>>>>> initialization >>>>>>>>>>>>>>>>>>>>>>>>>> by >>>>>>>>>>>>>>>>>>>>>>>>>> adding >>>>>>>>>>>>>>>>>>>>>>>>>> "set >>>>>>>>>>>>>>>>>>>>>>>>>> reinit = 1" to your dmrirc file, then running >>>>>>>>>>>>>>>>>>>>>>>>>> trac-all >>>>>>>>>>>>>>>>>>>>>>>>>> -prior >>>>>>>>>>>>>>>>>>>>>>>>>> again. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Once you change the initialization by doing either >>>>>>>>>>>>>>>>>>>>>>>>>> 1. >>>>>>>>>>>>>>>>>>>>>>>>>> or >>>>>>>>>>>>>>>>>>>>>>>>>> 2. >>>>>>>>>>>>>>>>>>>>>>>>>> above, >>>>>>>>>>>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>>>>>>>>>> need >>>>>>>>>>>>>>>>>>>>>>>>>> to run trac-all -path to reconstruct this path >>>>>>>>>>>>>>>>>>>>>>>>>> again. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> You can change the pathlist in dmrirc to do only >>>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> path >>>>>>>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>>>>>> failed. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> We jump through various hoops to make sure this >>>>>>>>>>>>>>>>>>>>>>>>>> sort >>>>>>>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>>>>>>> thing >>>>>>>>>>>>>>>>>>>>>>>>>> doesn't >>>>>>>>>>>>>>>>>>>>>>>>>> happen >>>>>>>>>>>>>>>>>>>>>>>>>> but in a few cases it can't be prevented, >>>>>>>>>>>>>>>>>>>>>>>>>> unfortunately. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Let me know if this has helped or if you have any >>>>>>>>>>>>>>>>>>>>>>>>>> other >>>>>>>>>>>>>>>>>>>>>>>>>> questions! >>>>>>>>>>>>>>>>>>>>>>>>>> a.y >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, 22 Sep 2011, Ping-Hong Yeh wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Anastasia, >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> The both ends were not terribly off of the white >>>>>>>>>>>>>>>>>>>>>>>>>>> matter, >>>>>>>>>>>>>>>>>>>>>>>>>>> though >>>>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>> lower end was a bit off at the level of >>>>>>>>>>>>>>>>>>>>>>>>>>> decussation. >>>>>>>>>>>>>>>>>>>>>>>>>>> any >>>>>>>>>>>>>>>>>>>>>>>>>>> suggestion >>>>>>>>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>>>> fixing this? >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> ping >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Sep 22, 2011 at 12:51 PM, Anastasia >>>>>>>>>>>>>>>>>>>>>>>>>>> Yendiki >>>>>>>>>>>>>>>>>>>>>>>>>>> <ayendiki(a)nmr.mgh.harvard.edu> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ping - It looks like the path initialization >>>>>>>>>>>>>>>>>>>>>>>>>>>> may >>>>>>>>>>>>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>>>>>>>>>>> failed. >>>>>>>>>>>>>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>>>>>>>>>>>>>> algorithm needs an initial guess for the path and >>>>>>>>>>>>>>>>>>>>>>>>>>>> iterates >>>>>>>>>>>>>>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>>>>>>>>>>>>> there. >>>>>>>>>>>>>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>>>>>>>>>>>>> initial guess is chosen based on the tracts in >>>>>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>> atlas >>>>>>>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>>>>>>>>>>>>> your >>>>>>>>>>>>>>>>>>>>>>>>>>>> subject >>>>>>>>>>>>>>>>>>>>>>>>>>>> is not perfectly aligned with the atlas this >>>>>>>>>>>>>>>>>>>>>>>>>>>> initial >>>>>>>>>>>>>>>>>>>>>>>>>>>> guess >>>>>>>>>>>>>>>>>>>>>>>>>>>> might >>>>>>>>>>>>>>>>>>>>>>>>>>>> end >>>>>>>>>>>>>>>>>>>>>>>>>>>> up >>>>>>>>>>>>>>>>>>>>>>>>>>>> going off the white matter for example. Does the >>>>>>>>>>>>>>>>>>>>>>>>>>>> blue >>>>>>>>>>>>>>>>>>>>>>>>>>>> line >>>>>>>>>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>>>>> your >>>>>>>>>>>>>>>>>>>>>>>>>>>> snapshot >>>>>>>>>>>>>>>>>>>>>>>>>>>> look like it may not coincide well with you >>>>>>>>>>>>>>>>>>>>>>>>>>>> subject's >>>>>>>>>>>>>>>>>>>>>>>>>>>> CST, >>>>>>>>>>>>>>>>>>>>>>>>>>>> going >>>>>>>>>>>>>>>>>>>>>>>>>>>> off >>>>>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>> white matter close to the end, etc? >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> a.y >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, 22 Sep 2011, Ping-Hong Yeh wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The segmented left CST tracts of one of our 3T >>>>>>>>>>>>>>>>>>>>>>>>>>>>> data >>>>>>>>>>>>>>>>>>>>>>>>>>>>> was >>>>>>>>>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>>>>>> satisfactory, which has only few voxels with >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1000 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> gray >>>>>>>>>>>>>>>>>>>>>>>>>>>>> values >>>>>>>>>>>>>>>>>>>>>>>>>>>>> (see >>>>>>>>>>>>>>>>>>>>>>>>>>>>> attached snapshot pictures for "trac-all" and >>>>>>>>>>>>>>>>>>>>>>>>>>>>> "cst_prob"). >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>>>>>>>>>>>>>>> manually tracking using deterministic >>>>>>>>>>>>>>>>>>>>>>>>>>>>> tractography >>>>>>>>>>>>>>>>>>>>>>>>>>>>> seems >>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK >>>>>>>>>>>>>>>>>>>>>>>>>>>>> (see >>>>>>>>>>>>>>>>>>>>>>>>>>>>> cst_stremline). Any suggestions on which step >>>>>>>>>>>>>>>>>>>>>>>>>>>>> may >>>>>>>>>>>>>>>>>>>>>>>>>>>>> go >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong >>>>>>>>>>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>>>>>> trac-all? >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you, >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ping >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 6

pial surface voxel shift
by Pernille Iversen 21 Oct '11

21 Oct '11

Hi After running several subjects (using trio siemens dicomfiles) with recon-all -all -nowmsa, we have observed an apparent shift of approximately one voxel to the left of the pial surface as compared to the brainmask.mgz in the TkMedit coronal view. This was observed in all of our subjects. Do you have any explanation for this - are there any corrections we need to do to avoid this? Thanks, Pernille

3 3

making a new label and binary mask
by Michelle Umali 21 Oct '11

21 Oct '11

Hi Freesurfers, I would like to make a custom V1 and V2 label based on my fieldsign results and then later use aseg2feat and fslmaths to make binary masks based on this label to later use in an FSL feat analysis. I made the additions to a a modified (and differently named) version of each subject's aparc.annot.ctab, marked vertices and used custom fill in tksurfer, removed the existing labels. I know i have to use the new labels and export a new annotation file, but can aparc2feat use this new annotation file or does it require the standard annotation files automatically generated from recon-all? Thanks. Michelle

2 1

Re: [Freesurfer] Group Average of Retinotopy Results
by Michelle Umali 21 Oct '11

21 Oct '11

Hi Doug, Thank you for your help with this. So when I looked at the maps, two issues arose. 1) The fieldsign map looks like it needs lots of smoothing. When I ran the individual subjects on the surface, I smoothed by 20 during fieldsign-sess. Is it still appropriate/can one smooth at the mri_fieldsign step below? 2)Results ended up on the lateral side and way anterior from the occipital lobe. Do I perform a separate registration between the individual subject and fsaverage somewhere along the line? Is this because I ran the individual subject analyses on a flattened fsaverage occipital patch and not on lh.sphere? Thanks! Michelle On Wed, Oct 19, 2011 at 7:34 PM, Michelle Umali <mumali01(a)gmail.com> wrote: > Hi Doug, > Two problems happened (I'm attaching a picture). > 1) The fieldsign map looks like it needs lots of smoothing. When I ran the > individual subjects on the surface, I smoothed by 20 during fieldsign-sess. > Is it still appropriate/can one smooth at the mri_fieldsign step below? > > 2)Results ended up on the lateral side and way anterior from the occipital > lobe. Do I perform a separate registration between the individual subject > and fsaverage somewhere along the line? Is this because I ran the > individual subject analyses on a flattened fsaverage occipital patch and not > on lh.sphere? > > Thanks! > Michelle > > > On Wed, Oct 19, 2011 at 5:30 PM, Douglas N Greve < > greve(a)nmr.mgh.harvard.edu> wrote: > >> Hi Michelle, try this: >> >> isxconcat-sess -sf sessidlist -a rtopy.fsaverage.lh -call -o retgroup >> cd retgroup/rtopy.fsaverage.lh >> >> mri_glmfit --y eccen/ces.000.nii.gz --osgm --o eccen/glm.real --surface >> fsaverage lh >> mri_glmfit --y eccen/ces.001.nii.gz --osgm --o eccen/glm.imag --surface >> fsaverage lh >> mri_glmfit --y polar/ces.000.nii.gz --osgm --o polar/glm.real --surface >> fsaverage lh >> mri_glmfit --y polar/ces.001.nii.gz --osgm --o polar/glm.imag --surface >> fsaverage lh >> >> mri_fieldsign --fs lh.fieldsign.mgh \ >> --eccen eccen/glm.real/osgm/gamma.mgh eccen/glm.imag/osgm/gamma.mgh \ >> --polar polar/glm.real/osgm/gamma.mgh polar/glm.imag/osgm/gamma.mgh \ >> --s fsaverage --hemi lh --sphere --old >> >> tksurfer fsaverage lh inflated -aparc -ov lh.fieldsign.mgh -fthresh .5 >> >> >> >> Michelle Umali wrote: >> >>> Hi Doug and the Freesurfers, >>> Thanks for your help. I have 2 questions.: >>> >>> 1) I did the retinotopy analysis on the fsaverage surface as you >>> suggested below and then ran isxconcat-sess for my eccen and polar data: >>> e.g. isxconcat-sess -analysis rtopy.fsaverage.lh -contrast polar -sf >>> sessid -o group_polar_lh >>> but how do you do this for the fieldsign analysis, since the cess.nii >>> and other files don't exist? >>> >>> 2) So when trying to run a group mri_glmfit on the polar and eccen maps >>> with: >>> mri_glmfit --y ces.nii.gz --wls cesvar.nii.gz --osgm --surface fsaverage >>> lh --glmdir group_eccen_lh.wls --nii.gz >>> >>> I got an error, because I have two ces.nii.gz and cesvar.nii.gz files >>> each. I am not sure how this happened. I only have one run each of polar >>> and wedge data. What may have generated these two files and which one do I >>> use? >>> >>> >>> Thanks. >>> Michelle >>> >>> >>> On Thu, Oct 13, 2011 at 11:36 AM, Douglas N Greve < >>> greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu>>> >>> wrote: >>> >>> When you run preproc-sess use -surface fsaverage lhrh instead of >>> -surface self lhrh. Then create a new analysis with the same >>> parameters, except use -surface fsaverage lh instead of -surface >>> self lh. >>> doug >>> >>> Michelle Umali wrote: >>> >>> Hi Doug, >>> I'm a little confused as to how to assign functional data to >>> the fsaverage space. >>> 1) Do you mean just change each subject's subjectname file to >>> fsaverage and then do the same thing as before for each person? >>> 2) Also, when I specify the analysis do I change >>> -rtopy.self.lh to rtopy.fsaverage.lh, i.e. will isconcat later >>> be sensitive to analysis name? >>> >>> e.g. mkanalysis-sess -a rtopy.self.lh -surface self lh -TR 2 >>> -retinotopy 48 -paradigm rtopy.par -nskip 4 -fwhm 0 -fsd bold >>> -force >>> >>> then the same for selxavg3-sess and fieldsign-sess >>> >>> and then isxconcat-sess would be: >>> isxconcat-sess -sf sessid -analysis rtopy.fsaverage.lh -o group_lh >>> >>> >>> Thanks. >>> Michelle >>> >>> On Wed, Oct 12, 2011 at 3:54 PM, Douglas N Greve >>> <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu> >>> > >>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>> >>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>>>> >>> wrote: >>> >>> If you want to combine across subjects, then you need to >>> run the >>> analysis on fsaverage (ie, rerun preproc-sess, create a new >>> analysis, run selxavg3-sess, and then isxconcat-sess). >>> doug >>> >>> Michelle Umali wrote: >>> >>> Dear Freesurfers, >>> I've generated individual polar, eccentricity, and >>> fieldsign >>> maps for each of my subjects. I would like to generate >>> group >>> average maps of these that I can visualize on the >>> fsaverage brain. >>> >>> When I ran: >>> isxconcat-sess -sf sessid -analysis rtopy.self.lh -o >>> group_lh >>> >>> I got: >>> ERROR: analysis space is self surface, not supported >>> >>> How do I do a group average for the 3 different maps? >>> >>> Thanks. >>> Michelle >>> >>> For each person I ran recon-all and flattened occipital >>> patches. >>> Then: >>> mkanalysis-sess -a rtopy.self.lh -surface self lh -TR 2 >>> -retinotopy 48 -paradigm rtopy.par -nskip 4 -fwhm 0 >>> -fsd bold >>> -force >>> mkanalysis-sess -a rtopy.self.rh -surface self rh -TR 2 >>> -retinotopy 48 -paradigm rtopy.par -nskip 4 -fwhm 0 >>> -fsd bold >>> -force >>> >>> preproc-sess -surface self lhrh -fwhm 5 -per-run -s >>> sjXX -fsd >>> bold -force >>> >>> selxavg3-sess -a rtopy.self.lh -s sjXX -force >>> selxavg3-sess -a rtopy.self.rh -s sjXX -force >>> >>> fieldsign-sess -a rtopy.self.lh -occip -fwhm 20 -s sjXX >>> fieldsign-sess -a rtopy.self.rh -occip -fwhm 20 -s sjXX >>> >>> ------------------------------** >>> ------------------------------**------------ >>> >>> ______________________________**_________________ >>> Freesurfer mailing list >>> Freesurfer(a)nmr.mgh.harvard.edu >>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>> > >>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>> >>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>> >> >>> >>> https://mail.nmr.mgh.harvard.** >>> edu/mailman/listinfo/**freesurfer<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 <greve(a)nmr.mgh.harvard.edu>> >>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>> >>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)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<http://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<http://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<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<greve(a)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> >>> <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<http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> >>> > >>> >>> >>> ------------------------------**------------------------------** >>> ------------ >>> >>> ______________________________**_________________ >>> 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> >>> >> >> -- >> 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<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> >> >> >

2 3

WM lesion volumes
by Sindhuja Tirumalai Govindarajan 20 Oct '11

20 Oct '11

Hi all, I am trying to find the volumes of lesions present in the white matter. Would 'WM-hypointensities' in aseg.stats give me this value? (A similar label is also found in wmparc.stats, but the values are not the same) Also, does the tot-cerebral-white-matter volume include the WM-hypointensities volume as well? Kindly let me know. Thanks and regards, Sindhuja

2 1

Re: [Freesurfer] MCSRCH ERROR
by Bruce Fischl 20 Oct '11

20 Oct '11

I just took a look at it, and I think it's still running. How long has it been? There looks like there is a very large topological defect, that will take a long time to correct. The correction has complexity that is quadratic in the convex hull of the largest defect, so large ones can take a *long* time. Usually when there is one this big though it means something failed. Check the rh.inflated.nofix and rh.orig.nofix files to see if there is a connection to the skull or something else. If you have trouble fixing this, upload the subject and we'll take a look. cheers Bruce On Thu, 20 Oct 2011, Kenichiro Tanaka wrote: > Dear Bruce, > > I emailed you the recon-all.log. > Please check it and tell me how wrong something is? > > Thanks, > > Kenichiro Tanaka. > > (2011/10/19 21:26), Bruce Fischl wrote: >> ok, why don't you tar and gzip the subject and put it on our ftp site. You >> can also just email me the recon-all.log and I'll take a look >> Bruce >> On Wed, 19 Oct 2011, Kenichiro Tanaka wrote: >> >> > Dear Bruce, >> > >> > I think they are error. >> > The number of output files is not complete. >> > For example, there are only lh.aparc.a2009s.stats, lh.aparc.stats and >> > lh.curv.stats on stats directory. >> > >> > Thanks, >> > >> > Kenichiro Tanaka. >> > >> > >> > >> > (2011/10/18 21:30), Bruce Fischl wrote: >> > Are you sure they are errors? We see this mysterious message >> > sometimes, but I don't think it is really an error, and usually >> > things are fine >> > >> > cheers >> > Bruce >> > >> > On Tue, 18 Oct 2011, Kenichiro Tanaka wrote: >> > >> > Hello All, >> > >> > While processing a brain image data(.mgz) through >> > ver5.0.0, I got the >> > following errors. >> > I have no idea how to resolve them. >> > I need outputs in stats directory, there are only >> > lh.aparc.a2009s.stats, >> > lh.aparc.stats, and lh.curv.stats. >> > What caused them? >> > How should I resolve them? >> > >> > IFLAG= -1 LINE SEARCH FAILED. SEE DOCUMENTATION OF >> > ROUTINE MCSRCH ERROR >> > RETURN OF LINE SEARCH: INFO= 3 POSSIBLE CAUSES: >> > FUNCTION OR GRADIENT ARE >> > INCORRECT OR INCORRECT TOLERANCESoutof >> > QuasiNewtonEMA: 005: -log(p) = >> > 10318.1 tol 0.000010 >> > . >> > . >> > . >> > inflating to sphere (rms error < 2.00) >> > 000: dt: 0.0000, rms radial error=175.699, avgs=0 >> > 005/300: dt: 0.9000, rms radial error=175.446, >> > avgs=0 >> > 010/300: dt: 0.9000, rms radial error=174.904, >> > avgs=0 >> > 015/300: dt: 0.9000, rms radial error=174.193, >> > avgs=0 >> > 020/300: dt: 0.9000, rms radial error=173.383, >> > avgs=0 >> > 025/300: dt: 0.9000, rms radial error=172.518, >> > avgs=0 >> > 030/300: dt: 0.9000, rms radial error=171.620, >> > avgs=0 >> > 035/300: dt: 0.9000, rms radial error=170.706, >> > avgs=0 >> > 040/300: dt: 0.9000, rms radial error=169.784, >> > avgs=0 >> > 045/300: dt: 0.9000, rms radial error=168.860, >> > avgs=0 >> > 050/300: dt: 0.9000, rms radial error=167.935, >> > avgs=0 >> > 055/300: dt: 0.9000, rms radial error=167.012, >> > avgs=0 >> > 060/300: dt: 0.9000, rms radial error=166.092, >> > avgs=0 >> > 065/300: dt: 0.9000, rms radial error=165.175, >> > avgs=0 >> > 070/300: dt: 0.9000, rms radial error=164.262, >> > avgs=0 >> > 075/300: dt: 0.9000, rms radial error=163.352, >> > avgs=0 >> > 080/300: dt: 0.9000, rms radial error=162.447, >> > avgs=0 >> > 085/300: dt: 0.9000, rms radial error=161.547, >> > avgs=0 >> > 090/300: dt: 0.9000, rms radial error=160.651, >> > avgs=0 >> > 095/300: dt: 0.9000, rms radial error=159.759, >> > avgs=0 >> > 100/300: dt: 0.9000, rms radial error=158.871, >> > avgs=0 >> > 105/300: dt: 0.9000, rms radial error=157.989, >> > avgs=0 >> > 110/300: dt: 0.9000, rms radial error=157.110, >> > avgs=0 >> > 115/300: dt: 0.9000, rms radial error=156.236, >> > avgs=0 >> > 120/300: dt: 0.9000, rms radial error=155.367, >> > avgs=0 >> > 125/300: dt: 0.9000, rms radial error=154.502, >> > avgs=0 >> > 130/300: dt: 0.9000, rms radial error=153.642, >> > avgs=0 >> > 135/300: dt: 0.9000, rms radial error=152.786, >> > avgs=0 >> > 140/300: dt: 0.9000, rms radial error=151.934, >> > avgs=0 >> > 145/300: dt: 0.9000, rms radial error=151.087, >> > avgs=0 >> > 150/300: dt: 0.9000, rms radial error=150.245, >> > avgs=0 >> > 155/300: dt: 0.9000, rms radial error=149.407, >> > avgs=0 >> > 160/300: dt: 0.9000, rms radial error=148.573, >> > avgs=0 >> > 165/300: dt: 0.9000, rms radial error=147.744, >> > avgs=0 >> > 170/300: dt: 0.9000, rms radial error=146.919, >> > avgs=0 >> > 175/300: dt: 0.9000, rms radial error=146.098, >> > avgs=0 >> > 180/300: dt: 0.9000, rms radial error=145.282, >> > avgs=0 >> > 185/300: dt: 0.9000, rms radial error=144.470, >> > avgs=0 >> > 190/300: dt: 0.9000, rms radial error=143.663, >> > avgs=0 >> > 195/300: dt: 0.9000, rms radial error=142.860, >> > avgs=0 >> > 200/300: dt: 0.9000, rms radial error=142.061, >> > avgs=0 >> > 205/300: dt: 0.9000, rms radial error=141.266, >> > avgs=0 >> > 210/300: dt: 0.9000, rms radial error=140.476, >> > avgs=0 >> > 215/300: dt: 0.9000, rms radial error=139.693, >> > avgs=0 >> > 220/300: dt: 0.9000, rms radial error=138.914, >> > avgs=0 >> > 225/300: dt: 0.9000, rms radial error=138.140, >> > avgs=0 >> > 230/300: dt: 0.9000, rms radial error=137.370, >> > avgs=0 >> > 235/300: dt: 0.9000, rms radial error=136.604, >> > avgs=0 >> > 240/300: dt: 0.9000, rms radial error=135.842, >> > avgs=0 >> > 245/300: dt: 0.9000, rms radial error=135.085, >> > avgs=0 >> > 250/300: dt: 0.9000, rms radial error=134.332, >> > avgs=0 >> > 255/300: dt: 0.9000, rms radial error=133.583, >> > avgs=0 >> > 260/300: dt: 0.9000, rms radial error=132.838, >> > avgs=0 >> > 265/300: dt: 0.9000, rms radial error=132.098, >> > avgs=0 >> > 270/300: dt: 0.9000, rms radial error=131.362, >> > avgs=0 >> > 275/300: dt: 0.9000, rms radial error=130.629, >> > avgs=0 >> > 280/300: dt: 0.9000, rms radial error=129.901, >> > avgs=0 >> > 285/300: dt: 0.9000, rms radial error=129.177, >> > avgs=0 >> > 290/300: dt: 0.9000, rms radial error=128.456, >> > avgs=0 >> > 295/300: dt: 0.9000, rms radial error=127.740, >> > avgs=0 >> > 300/300: dt: 0.9000, rms radial error=127.028, >> > avgs=0 >> > >> > spherical inflation complete. >> > . >> > . >> > . >> > epoch 4 (K=1280.0), pass 1, starting sse = 541.21 >> > taking momentum steps... >> > taking momentum steps... >> > taking momentum steps... >> > pass 1 complete, delta sse/iter = 0.32/19 = 0.01710 >> > finalwriting spherical brain to >> > ../surf/lh.qsphere.nofix >> > spherical transformation took 0.10 hours >> > distance error %100000.00 >> > . >> > . >> > . >> > pass 1: epoch 1 of 3 starting distance error %21.36 >> > pass 1: epoch 2 of 3 starting distance error %21.04 >> > unfolding complete - removing small folds... >> > starting distance error %20.80 >> > removing remaining folds... >> > final distance error %20.81 >> > 364: 0 negative triangles >> > . >> > . >> > . >> > >> > >> > Thanks, >> > >> > Kenichiro Tanaka. >> > >> > _______________________________________________ >> > 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

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