Freesurfer

freesurfer@nmr.mgh.harvard.edu

30132 discussions

qdec
by dgw 14 Nov '13

14 Nov '13

Hello, I sent the message below yesterday. I can confirm that I am also having problems visualizing with qdec using the standard nmr center install over nx. Everytime I click generate stats table, I get the error below. Is there a non-gui version, which I can use? Does anyone have a way to use this over nx or vnc? Thank You, Dan I am having trouble running qdec over an NX session. I downloaded a FreeSurfer installation (5.3.0) to a network drive (/cluster/neuromind/dwakeman/software/freesurfer/). The installation has no trouble running recon-all; however, when I try to run qdec, I get vtk errors (see below): ERROR: In /usr/pubsw/packages/KWWidgets/CVS-vtk560/KWWidgets/vtkKWTkUtilities.cxx, line 230 vtkKWQdecApp (0x27454520): Script: vtkTemp2 GenerateStatsDataTables Returned Error on line 1: Uncaught exception: command failed: asegstats2table --common-segs --meas volume --tablefile /autofs/cluster/neuromind/dwakeman/study/qdec/stats_tables/aseg.volume.stats.dat --statsfile=aseg.stats --subjects ead_01 ead_02 ead_03 ead_04 ead_11 ead_12 ead_13 ead_14 Stack trace: Uncaught exception: command failed: asegstats2table --common-segs --meas volume --tablefile /autofs/cluster/neuromind/dwakeman/study/qdec/stats_tables/aseg.volume.stats.dat --statsfile=aseg.stats --subjects ead_01 ead_02 ead_03 ead_04 ead_11 ead_12 ead_13 ead_14 while executing "vtkTemp2 GenerateStatsDataTables" help(a)nmr.mgh.harvard.edu told me that I shouldn't need vglrun (as indicated on the wiki). Is there something I need to do to fix the installation, or do I need vglrun? Thank You, Dan Wakeman

2 1

Re: [Freesurfer] mri_glmfit-sim with conjunction maps but without pre-cached data
by Caspar M. Schwiedrzik 14 Nov '13

14 Nov '13

Hi again, I keep getting segmentation fault errors (this time with the centOS4 version). After 1153 iterations, I get 78.91 0 ./cache_csd_surface.script: line 10: 18061 Segmentation fault ~/bin/mri_mcsim --surface avg_monkey rh --fwhm-max 10 --o csd --base mcz --nreps 10000 --no-label This version also signaled "ERROR: ld.so: object '/space/opt/libGL.so.1' from LD_PRELOAD cannot be preloaded: ignored" when it started. With the centOS4 64bit version, I got a segmentation fault error with the first iteration, or even before. Caspar 2013/11/1 Caspar M. Schwiedrzik <cschwiedrz(a)rockefeller.edu> > just a quick update. I just saw that the centOS4 version threw the > following error message: > ERROR: ld.so: object '/space/opt/libGL.so.1' from LD_PRELOAD cannot be > preloaded: ignored. > Do I need to worry about this? > Thanks, Caspar > > > > 2013/11/1 Caspar M. Schwiedrzik <cschwiedrz(a)rockefeller.edu> > > Hi Zeke, >> thanks for making these available. The centOS4 version seems to work so >> far, for the >> centOS4_x86_64 version I got the following error message: >> ./cache_csd_surface.script: line 10: 17763 Segmentation fault >> Caspar >> >> >> >> 2013/11/1 Z K <zkaufman(a)nmr.mgh.harvard.edu> >> >>> Casper, >>> >>> This email thread is kinda long and Im not able to clearly decipher what >>> has been tried and what hasn't, so Im sending you a link to all 3 dev >>> versions of mri_mcsim that we build. >>> >>> ftp://surfer.nmr.mgh.harvard.**edu/transfer/outgoing/fsdev/** >>> zkaufman/casper/<ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/fsdev/zkaufman/casper/> >>> >>> >>> This includes the following: >>> >>> -centOS4 >>> -centOS4_x86_64 >>> -centOS6_x86_64 >>> >>> Unfortunately we do not have a centOS5 build of that binary. >>> >>> -Zeke >>> >>> >>> >>> >>> On 11/01/2013 08:09 AM, Caspar M. Schwiedrzik wrote: >>> >>>> Hi Doug, Nick, and Zeke, >>>> just following up: Is there a version of mri_mcsim >1.17 that is >>>> compatible with centos5? >>>> >>>> Thanks! >>>> Caspar >>>> >>>> >>>> >>>> 2013/10/30 Douglas N Greve <greve(a)nmr.mgh.harvard.edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>>> >>>> >>>> >>>> >>>> Nick/Zeke, do we have anything that will run under CentoOS5? >>>> >>>> >>>> >>>> On 10/30/2013 12:00 PM, Caspar M. Schwiedrzik wrote: >>>> >>>> Hi Doug, >>>> with the new version, I am now getting the following error >>>> (excerpt): >>>> after it dispalys the average vertex area, >>>> *** glibc detected *** .../bin/mri_mcsim: malloc(): smallbin >>>> double linked list corrupted: 0x00000000281efc40 *** >>>> followed by a backtrace and a memory map. >>>> This did not happen when I ran it with --checkopts. >>>> Caspar >>>> >>>> >>>> >>>> 2013/10/30 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 >>>> >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >>> >>>> >>>> >>>> OK, I put a centos4 build there, that should work >>>> >>>> >>>> On 10/30/2013 11:05 AM, Caspar M. Schwiedrzik wrote: >>>> >>>> Hi Doug, >>>> >>>> that would be Red Hat Enterprise Linux Server release >>>> 5.9 >>>> (Tikanga) >>>> Caspar >>>> >>>> >>>> >>>> >>>> 2013/10/30 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 >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >>>> >>>> >>>> >>>> what OS platform are you using? >>>> >>>> On 10/30/2013 11:00 AM, Caspar M. Schwiedrzik >>>> wrote: >>>> >>>> Hi Doug, >>>> >>>> thanks for the advice. >>>> When I try to use the new mri_mcscim, I get the >>>> following >>>> error messages: >>>> /usr/lib64/libstdc++.so.6: version >>>> `GLIBCXX_3.4.11' >>>> not found >>>> /usr/lib64/libstdc++.so.6: version >>>> `GLIBCXX_3.4.9' >>>> not found >>>> /lib64/libc.so.6: version `GLIBC_2.7' not >>>> found >>>> Caspar >>>> >>>> >>>> 2013/10/30 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 >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >>> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >> >>>> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 10/30/2013 08:51 AM, Caspar M. >>>> Schwiedrzik wrote: >>>> >>>> Hi Doug, >>>> thank you very much! >>>> I have two follow-up questions for >>>> your two >>>> suggestions: >>>> 1) If I want to use mri_glmfit-sim but >>>> my >>>> conjunctions >>>> are not >>>> from contrasts that are all from the >>>> same GLM, >>>> I guess >>>> I can >>>> still do what you suggested but I will >>>> have to >>>> come up >>>> with a >>>> fwhm.dat for the conjunction, correct? >>>> Is there a way to compute this from the >>>> conjunction >>>> sig map, >>>> or should I use the average or the max >>>> or the >>>> min of the >>>> contrasts that go into the conjunction? >>>> This >>>> is for >>>> functional >>>> data. >>>> >>>> If they are not from the same GLM, then I >>>> would >>>> use the >>>> larger of >>>> the two FWHMs. >>>> >>>> >>>> 2) It seems that there is a version of >>>> mri_mcsim that >>>> allows >>>> one to specify a range of FWHM with the >>>> flag >>>> --fwhm-max; >>>> however, version 1.17 that comes with >>>> the 5.1 >>>> and 5.3 >>>> releases >>>> does bot have that option. Is the >>>> version of >>>> mri_mcsim >>>> that >>>> understands --fwhm-max available? >>>> >>>> Try >>>> ftp://surfer.nmr.mgh.harvard._**_edu/transfer/outgoing/flat/__* >>>> *greve/mri_mcsim >>>> >>>> <ftp://surfer.nmr.mgh.harvard.**edu/transfer/outgoing/flat/** >>>> greve/mri_mcsim<ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/mri_mcsim> >>>> > >>>> doug >>>> >>>> >>>> Thanks again, Caspar >>>> >>>> >>>> >>>> 2013/10/24 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 >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >>> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >>>> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >>> >>>> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >>>>>> >>>> >>>> >>>> >>>> Hi Caspar, there are a couple of >>>> things >>>> you can do: >>>> >>>> 1. Go into the mri_glmfit folder >>>> used to >>>> create >>>> the input >>>> contrasts to >>>> the conjunction. Create a >>>> subfolder. Save the >>>> conjunction as >>>> sig.mgz and >>>> create a file called "C.dat" (it >>>> can be >>>> empty) in >>>> this folder. >>>> Then run >>>> mri_glmfit-sim specifying to do the >>>> simulation >>>> rather than >>>> using >>>> cached >>>> data. >>>> >>>> 2. Create cached data by running >>>> mri_mcsim. This >>>> may take >>>> longer than >>>> #1, but once you have the cached >>>> data you >>>> do not >>>> need to >>>> run it again, >>>> which could be useful if you are >>>> going to >>>> do more >>>> analyses >>>> with this >>>> template >>>> >>>> doug >>>> >>>> >>>> On 10/23/2013 02:55 PM, Caspar M. >>>> Schwiedrzik wrote: >>>> > Hi, >>>> > I have a question regarding >>>> cluster size >>>> thresholding using >>>> > mri_glmfit-sim. Namely, I have a >>>> sig.nii >>>> conjunction map >>>> that I made >>>> > with mri_concat. >>>> > The analyses that serve as input >>>> to the >>>> conjunction map >>>> are done >>>> on a >>>> > custom surface template. >>>> > If I want to run mri_glmfit-sim, >>>> how >>>> would that >>>> work? I >>>> obviously do >>>> > not have precached data. >>>> > Thanks, Caspar >>>> > >>>> > >>>> > >>>> > >>>> > >>>> ______________________________**___________________ >>>> >>>> > 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.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> >>> >>>> >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu <http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> >>>> >>>> >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu <http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> >>> >>>> >>>> >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu <http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://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<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 >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >>> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >>>> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >>> >>>> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@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>> <tel: >>>> 617-724-2358 >>>> <tel:617-724-2358> <tel:617-724-2358 <tel:617-724-2358>>> >>>> <tel:617-724-2358 <tel:617-724-2358> >>>> <tel:617-724-2358 <tel:617-724-2358>> <tel:617-724-2358 >>>> <tel:617-724-2358> >>>> <tel:617-724-2358 <tel:617-724-2358>>>> >>>> <tel:617-724-2358 <tel:617-724-2358> >>>> <tel:617-724-2358 <tel:617-724-2358>> >>>> <tel:617-724-2358 <tel:617-724-2358> <tel:617-724-2358 >>>> <tel:617-724-2358>>> <tel:617-724-2358 <tel:617-724-2358> >>>> <tel:617-724-2358 <tel:617-724-2358>> >>>> <tel: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>> >>>> <tel:617-726-7422 <tel:617-726-7422> <tel:617-726-7422 >>>> <tel:617-726-7422>>> >>>> <tel:617-726-7422 <tel:617-726-7422> >>>> <tel:617-726-7422 <tel:617-726-7422>> <tel:617-726-7422 >>>> <tel:617-726-7422> >>>> <tel:617-726-7422 <tel:617-726-7422>>>> >>>> <tel:617-726-7422 <tel:617-726-7422> <tel:617-726-7422 >>>> <tel:617-726-7422>> >>>> >>>> <tel:617-726-7422 <tel:617-726-7422> >>>> <tel:617-726-7422 <tel:617-726-7422>>> >>>> >>>> <tel:617-726-7422 <tel:617-726-7422> >>>> <tel:617-726-7422 <tel:617-726-7422>> >>>> <tel: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.__harva**rd.edu/fswiki/__BugReporting<http://harvard.edu/fswiki/__BugReporting> >>>> <http://surfer.nmr.mgh.**harvard.edu/fswiki/**BugReporting<http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >>>> >> >>>> >>>> <http://surfer.nmr.mgh.__harva**rd.edu/fswiki/__BugReporting<http://harvard.edu/fswiki/__BugReporting> >>>> <http://surfer.nmr.mgh.**harvard.edu/fswiki/**BugReporting<http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >>>> >> >>>> >>>> <http://surfer.nmr.mgh.__harva**rd.edu/fswiki/__BugReporting<http://harvard.edu/fswiki/__BugReporting> >>>> <http://surfer.nmr.mgh.**harvard.edu/fswiki/**BugReporting<http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >>>> >> >>>> >>>> <http://surfer.nmr.mgh.__harva**rd.edu/fswiki/__BugReporting<http://harvard.edu/fswiki/__BugReporting> >>>> <http://surfer.nmr.mgh.**harvard.edu/fswiki/**BugReporting<http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >>>> >> >>>> FileDrop: >>>> https://gate.nmr.mgh.harvard._**_edu/filedrop2 >>>> <https://gate.nmr.mgh.harvard.**edu/filedrop2<https://gate.nmr.mgh.harvard.edu/filedrop2> >>>> > >>>> 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 <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 >>>> <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>>> >>>> >>>> Outgoing: >>>> ftp://surfer.nmr.mgh.harvard._**_edu/transfer/outgoing/flat/__* >>>> *greve/ >>>> <ftp://surfer.nmr.mgh.harvard.**edu/transfer/outgoing/flat/** >>>> greve/ <ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/> >>>> > >>>> >>>> >>>> ______________________________**___________________ >>>> >>>> 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.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> >>> >>>> >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu <http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> >>>> >>>> >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu <http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> >>> >>>> >>>> >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu <http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.**harvard.edu<Freesurfer(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:Freesurfer@nmr.mgh.__h**arvard.edu<http://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<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> >>>> >>>> <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> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >>> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@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>> >>>> <tel:617-724-2358 <tel:617-724-2358> <tel:617-724-2358 >>>> <tel:617-724-2358>>> >>>> <tel:617-724-2358 <tel:617-724-2358> >>>> <tel:617-724-2358 <tel:617-724-2358>> <tel: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>> >>>> <tel:617-726-7422 <tel:617-726-7422> <tel:617-726-7422 >>>> <tel:617-726-7422>>> <tel:617-726-7422 <tel:617-726-7422> >>>> <tel:617-726-7422 <tel:617-726-7422>> >>>> <tel: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.__harva**rd.edu/fswiki/__BugReporting<http://harvard.edu/fswiki/__BugReporting> >>>> <http://surfer.nmr.mgh.**harvard.edu/fswiki/**BugReporting<http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >>>> >> >>>> >>>> <http://surfer.nmr.mgh.__harva**rd.edu/fswiki/__BugReporting<http://harvard.edu/fswiki/__BugReporting> >>>> <http://surfer.nmr.mgh.**harvard.edu/fswiki/**BugReporting<http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >>>> >> >>>> >>>> <http://surfer.nmr.mgh.__harva**rd.edu/fswiki/__BugReporting<http://harvard.edu/fswiki/__BugReporting> >>>> <http://surfer.nmr.mgh.**harvard.edu/fswiki/**BugReporting<http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >>>> >> >>>> FileDrop: >>>> https://gate.nmr.mgh.harvard._**_edu/filedrop2 >>>> <https://gate.nmr.mgh.harvard.**edu/filedrop2<https://gate.nmr.mgh.harvard.edu/filedrop2> >>>> > >>>> 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 <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 <http://www.nmr.mgh.harvard.** >>>> edu/facility/filedrop/index.**html<http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> >>>> >> >>>> Outgoing: >>>> ftp://surfer.nmr.mgh.harvard._**_edu/transfer/outgoing/flat/__* >>>> *greve/ >>>> >>>> <ftp://surfer.nmr.mgh.harvard.**edu/transfer/outgoing/flat/** >>>> greve/ <ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/> >>>> > >>>> >>>> >>>> >>>> -- 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 >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> >> >>>> <mailto:greve@nmr.mgh.harvard.**__edu >>>> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >>>> > >>>> <mailto:greve@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>> >>>> <tel: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>> <tel: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.__harva**rd.edu/fswiki/__BugReporting<http://harvard.edu/fswiki/__BugReporting> >>>> <http://surfer.nmr.mgh.**harvard.edu/fswiki/**BugReporting<http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >>>> >> >>>> >>>> <http://surfer.nmr.mgh.__harva**rd.edu/fswiki/__BugReporting<http://harvard.edu/fswiki/__BugReporting> >>>> <http://surfer.nmr.mgh.**harvard.edu/fswiki/**BugReporting<http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >>>> >> >>>> FileDrop: >>>> https://gate.nmr.mgh.harvard._**_edu/filedrop2 >>>> <https://gate.nmr.mgh.harvard.**edu/filedrop2<https://gate.nmr.mgh.harvard.edu/filedrop2> >>>> > >>>> 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 <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>>> >>>> Outgoing: >>>> ftp://surfer.nmr.mgh.harvard._**_edu/transfer/outgoing/flat/__* >>>> *greve/ >>>> >>>> <ftp://surfer.nmr.mgh.harvard.**edu/transfer/outgoing/flat/** >>>> greve/ <ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/> >>>> > >>>> >>>> >>>> >>>> -- 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 >>>> >>>> <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.__harva** >>>> rd.edu/fswiki/__BugReporting <http://harvard.edu/fswiki/__BugReporting> >>>> <http://surfer.nmr.mgh.**harvard.edu/fswiki/**BugReporting<http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >>>> >> >>>> FileDrop: https://gate.nmr.mgh.harvard._**_edu/filedrop2 >>>> <https://gate.nmr.mgh.harvard.**edu/filedrop2<https://gate.nmr.mgh.harvard.edu/filedrop2> >>>> > >>>> 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 <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html>>> >>>> Outgoing: >>>> ftp://surfer.nmr.mgh.harvard._**_edu/transfer/outgoing/flat/__* >>>> *greve/ >>>> >>>> <ftp://surfer.nmr.mgh.harvard.**edu/transfer/outgoing/flat/** >>>> greve/ <ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/> >>>> > >>>> >>>> >>>> >>>> -- >>>> 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: https://gate.nmr.mgh.harvard._**_edu/filedrop2 >>>> <https://gate.nmr.mgh.harvard.**edu/filedrop2<https://gate.nmr.mgh.harvard.edu/filedrop2> >>>> > >>>> 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> >>>> > >>>> Outgoing: >>>> ftp://surfer.nmr.mgh.harvard._**_edu/transfer/outgoing/flat/__** >>>> greve/ >>>> <ftp://surfer.nmr.mgh.harvard.**edu/transfer/outgoing/flat/**greve/<ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/> >>>> > >>>> >>>> >>>> >> >

2 8

Re: [Freesurfer] MNI305 to MNI152 coordinates
by Anita van Loenhoud 14 Nov '13

14 Nov '13

It worked, thanks. I tried to invert it but the coordinates didn't fully correspond; I must have made an error. Thanks for helping me out!

1 0

Re: [Freesurfer] How do you create labels from binary masks?
by Douglas N Greve 13 Nov '13

13 Nov '13

Hi Marcos, I have found and fixed the problem. As you suspected, the orig surface was being loaded instead of the surface you need. The fix is here (for centos6): ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/mris_label2an… Use the --surf option to specify your surface (without hemi designation, eg, surfHippo ) If you need it for another platform, let me know and I'll put it on-line after our nightly build doug On 11/06/2013 12:07 PM, Marcos Martins da Silva wrote: > Hi, Doug > Thank you for fast feedback. > Answering your question, the annotation file I produced works but it > is not adequate because it has lots of unmapped vertices and this > generates thousands of warning lines when using freeview or tksurfer. > And generating all this terminal output steals some time. So a bit of > each of your options you asked about. Investigating the problem I > noticed that: > 1- The first lines output on terminal during mris_annot2label includes > this one: *Loading /home/marcos/freesurfer/subjects/suj1/surf/lh.orig* > 2- I guessed this confirmed my suspicions that mris_annot2label was > considering another file besides my labels when generating the annot file > 3- Since it was not possible to use something like --ref to point to > lh.surfHippo, I tried a workaround. I know it was a dirty and low blow > but... it worked great. I saved lh.orig as real_lh.orig and copied > lh.surfHippo to lh.orig. This way, mris_annot2label would be > considering my hippo surface instead of lh.orig while creating the > annotation file. Using this approach mris_info says the annot file and > the surface have the same number of vertices. Both Freeview and > tksurfer loaded the surface and the annot files with no warning > messages and ad quick as it should be. > 4- Checking > https://github.com/neurodebian/freesurfer/blob/master/mris_label2annot/mris… > , I confirmed that ?h.orig is hardcoded: > > // Read the surf > sprintf(tmpstr,"%s/%s/*surf/%s.orig*",SUBJECTS_DIR,subject,hemi); > printf("Loading %s\n",tmpstr); mris = MRISread(tmpstr); > > Just as a suggestion, perhaps you could add a --ref parameter to > mris_label2annot, while keeping ?h.orig as default. That would allow > a consistent pathway (vol2surf -> cor2label -> label2annot ->freeview) > with all steps considering the same files. > > I guess the command and warning lines I mentioned in my last message > and you asked are no more necessary but they follow anyway. I just > restricted the terminal output to final lines for simplicity it would > be really huge. > > freeview -f lh.surfHippo:annot=$SUBJECTS_DIR/suj1/label/lh.Hippo > > MRISreadAnnotationIntoArray: vertex index out of range: 122882 > i=00000000, in_array_size=11627 > annot file: /home/marcos/freesurfer/subjects/suj1/label/lh.Hippo.annot > MRISreadAnnotationIntoArray: vertex index out of range: 122883 > i=00000000, in_array_size=11627 > annot file: /home/marcos/freesurfer/subjects/suj1/label/lh.Hippo.annot > MRISreadAnnotationIntoArray: vertex index out of range: 122884 > i=00000000, in_array_size=11627 > annot file: /home/marcos/freesurfer/subjects/suj1/label/lh.Hippo.annot > MRISreadAnnotationIntoArray: vertex index out of range: 122885 > i=00000000, in_array_size=11627 > annot file: /home/marcos/freesurfer/subjects/suj1/label/lh.Hippo.annot > reading colortable from annotation file... > colortable with 4 entries read (originally ../label/Hippo.ctab) > colortable with 4 entries read (originally ../label/Hippo.ctab) > ippo.annot > in_array_size=11627 > > Thank you very much, Doug > Cheers, > Marcos > > > Em Qua, 2013-11-06 às 10:25 -0500, Douglas N Greve escreveu: >> So is the problem that the annotation does not look good or is the >> problem that you are getting a lot of warnings about unmapped vertices. >> Please send the command lines that generate the warnings (and the >> terminal output) >> doug >> >> >> On 11/06/2013 10:05 AM, Marcos Martins da Silva wrote: >> > Hi, Doug >> > Thanks again for your help. >> > I am really glad to say I managed to get the labels and annotation >> > file I wanted. See attached screenshot for result. There is one final >> > problem I will explain ahead. The parameter that made this possible >> > was *--ref*. So the final mri_vol2surf that made the trick was: >> > >> > mri_vol2surf --src binLeftHippoTail.mgz --out LeftHippoTail_surf.mgh >> > --out_type mgh --hemi lh --regheader suj1 --surf surfHippo >> > --projdist-max -2 0 .1 *--ref* binLeftHippoTail.mgz >> > >> > This way, using my binary mask both as source and reference I got the >> > correct surface overlay to use as input in: >> > >> > mri_cor2label --i LeftHippoTail_surf.mgh --surf suj1 lh surfHippo --id >> > 1 --l lh.HippoTail.label >> > >> > The --projdist parameter you suggested resulted in a a better image so >> > I kept. Repeating this sequence for head and body I got what I wanted. >> > It seems the problem was related to differences in space among the >> > hipocampal subfields filesand orig.mgz (the default reference) perhaps >> > because the first files are 0.5 x 0.5 x 0.5 mm^3 and orig.mgz is 1 x 1 >> > x 1 mm^3 or because the hippocampal subfields are generated from a >> > strict region around the original hippocampal segments you find in >> > aseg.mgz. >> > Both Freeview and tksurfer can load the labels with no error message. >> > Both can load the annotation file too. But at terminal window they >> > show lots of vertices out of index (that is, present in lh.hippo.annot >> > and absent in lh.surfHippo). Labels seem ok with about 12000 vertices >> > if I sum the number of vertices in the 3 files because some vertices >> > are present in more than 1 label but annot includes a huge amount of >> > vertices mapped to unknown. It follows mris_info output. >> > >> > *mris_info --s suj1 lh surfHippo --a ../label/lh.Hippo.annot * >> > *ERROR: ../label/lh.Hippo.annot has 122886 vertices, while >> > /home/marcos/freesurfer/subjects/suj1/surf/lh.surfHippo has 11627 >> > vertices* >> > >> > It seems that mris_label2annot include a lot of unnecessary unknown >> > vertices not present in my surface nor in the labels during its >> > processing. It does not avoid using the annotation file but produces a >> > huge amount of warning lines at terminal window. I guess >> > mris)label2annot is using some other file as reference and seeing a I >> > did not see any parameter I could add to restrict this behavior. I >> > guess if I had something equivalent to --ref parameter as seem in >> > mri_vol2surf I could have a better result. Alternatively, if I could >> > process the annot file to trim the unmapped vertices I guess it would >> > work too. >> > This is the mris_label2annot I am using: >> > >> > *mris_label2annot --s suj1 --h lh --ctab ../label/Hippo.ctab --a Hippo >> > --l ../label/lh.HippoHead.label --l ../label/lh.HippoBody.label --l >> > ../label/lh.HippoTail.label --maxstatwinner* >> > >> > I hope you can help me in this final issue so we can finnish this >> > thread. Thank you once more for your attention >> > Cheers, >> > Marcos. >> > Em Seg, 2013-11-04 às 18:28 -0500, Douglas N Greve escreveu: >> >> That vol2surf command might miss the values you want to sample. Try >> >> adding --projdist-max -2 0 .1 >> >> This will sample from 2mm into the hippo out to the surface in .1mm >> >> increments and then take the maximum value it finds >> >> doug >> >> >> >> On 10/30/2013 03:08 PM, Marcos Martins da Silva wrote: >> >> > Hi, Doug. >> >> > Thanks again for all your attention. >> >> > I am trying to show the head, body and tail segments on the >> >> > hippocampal surface. Each with one color. I thought the best way to do >> >> > it would be creating an annot file with 3 surface labels one for each >> >> > segment. The approach, concatenation of hippo-subfields -> binarize -> >> >> > tesselation -> smooth, I used gave me a realistic hippocampal surface. >> >> > I could also segment that concatenated volume into head, body and tail >> >> > but I do not know how to convert these segments into surface labels. >> >> > >> >> > Unfortunately mapping on the hippo surface did not work too, unless I >> >> > did something wrong. Could you please check if the following commands >> >> > are correct? Perhaps all I need is to add or remove one parameter. >> >> > >> >> > *mri_vol2surf --src binLeftHippoBody.mgz --out LeftHippoBody_surf.mgh >> >> > --out_type mgh --hemi lh --regheader suj1 --surf surfHippo* >> >> > *mri_cor2label --i LeftHippoBody_surf.mgh --surf suj1 lh surfHippo >> >> > --id 1 --l lh.HippoBody.label* >> >> > >> >> > Cheers, >> >> > Marcos. >> >> > >> >> > >> >> > Em Qua, 2013-10-30 às 10:47 -0400, Douglas N Greve escreveu: >> >> >> I've lost track of what you are trying to do. Can you just sample it on >> >> >> to your hippo surface? >> >> >> doug >> >> >> >> >> >> >> >> >> >> >> >> On 10/29/2013 08:05 PM, Marcos Martins da Silva wrote: >> >> >> > I did several tests but I got no luck. But, I guess I know the reason: >> >> >> > when you use mri_vol2surf the tool needs a reference surface (lh.white >> >> >> > is default, if you do not use --surf argument). The problem is that >> >> >> > lh.white, lh.orig and lh.pial all exclude hippocampus. I loaded a >> >> >> > volume (orig.mgz) with the p-labels corresponding to left hippocampal >> >> >> > head, body and tail. Then I alternatively loaded the surfaces lh.orig, >> >> >> > lh.pial and lh.surfhippo. I am attaching screenshots with lh.orig and >> >> >> > lh.surfhippo. Registering seems good among volumes, surfaces and >> >> >> > p-labels. But hippocampus is completely excluded from lh.orig while >> >> >> > lh.pial includes just a few vertices in hippocampal region. On the >> >> >> > other side the lh.surfhippo perfectly matches the hippocampus. >> >> >> > So, I guess I would need a different approach or a different surface >> >> >> > file that includes the hippocampus. I hope you can help me solve this. >> >> >> > Thank you for all your attention. >> >> >> > BTW, I am not sending the lh.pial screenshot due to list's 500 K >> >> >> > restriction, but I can send you if you want to see. >> >> >> > Cheers, >> >> >> > Marcos >> >> >> > Em Qui, 2013-10-24 às 19:39 -0400, Douglas N Greve escreveu: >> >> >> >> areyou loading the label (output of mri_cor2label) or did you create an >> >> >> >> annotation? Try loading the label. Then try loading >> >> >> >> LeftHippoBody_surf.mgh. If that does not look ok, check the registration >> >> >> >> between binLeftHippoBody.mgz and subj1 with --regheader >> >> >> >> >> >> >> >> doug >> >> >> >> >> >> >> >> On 10/24/2013 06:40 PM, Marcos Martins da Silva wrote: >> >> >> >> > Hi, Doug >> >> >> >> > Thanks again for your help. >> >> >> >> > Using the command tksurfer suj1 lh surfHippo, I get the surface loaded >> >> >> >> > in tksurfer in the same way that I get in freeview. The only >> >> >> >> > difference is that the terminal window output is more verbose and that >> >> >> >> > is valuable when investigating this kind of situation. I am attaching >> >> >> >> > a screenshot. I got this just after I used tksurfer to import an >> >> >> >> > annotation (lh.surfHippo + hippo.annot.png). >> >> >> >> > The screenshot show just a few vertices with color. Indeed this is >> >> >> >> > similar to what we see in freeview, except that in this last tool all >> >> >> >> > vertices not in label appears in black and tksurfer preserves the gray >> >> >> >> > color. >> >> >> >> > At terminal output we can see tksurfer expects the surface refers to >> >> >> >> > lh.white. That is not the case, I guess. I think it helps explain the >> >> >> >> > terminal window output we see in freeview and also in tksurfer when I >> >> >> >> > try to load the annot file. It seems we have lots of vertices in annot >> >> >> >> > file that both tools cannot find in surface file and at the same time >> >> >> >> > we have lots of vertices in my surface file not described in the annot >> >> >> >> > files. At least now I can understand the situation. It puzzles me >> >> >> >> > because the surface, binary masks, labels and annotations were created >> >> >> >> > from the same source: the posterior*.mgz files created by recon-all >> >> >> >> > --hippo-subfields. But, well, I probably misunderstood something in >> >> >> >> > documentation and lost my way in some point. I hope you can help me >> >> >> >> > with the correct steps to be followed. I still dream of showing the >> >> >> >> > hippocampus in a similar way we do with cortex when we load lh.pial >> >> >> >> > and lh.aparc.annot. >> >> >> >> > Thank you for your help and attention. >> >> >> >> > Cheers, >> >> >> >> > Marcos. >> >> >> >> > Em Qui, 2013-10-24 às 12:40 -0400, Douglas N Greve escreveu: >> >> >> >> >> Can you load it properly in tksurfer? >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 10/23/2013 12:44 AM, Marcos Martins da Silva wrote: >> >> >> >> >> > >> >> >> >> >> > Hi, Doug >> >> >> >> >> > Sorry for this late feedback. >> >> >> >> >> > Just so you can understand what is binLeftHippoBody.mgz I will explain >> >> >> >> >> > its origin. >> >> >> >> >> > 1) recon-all --hippo-subfields >> >> >> >> >> > 2) mri_concat the posterior*.mgz to get the whole hippocampus >> >> >> >> >> > 3) a custom octave routine to segment the whole hippocampus into head, >> >> >> >> >> > body and tail. This routine preserves the probability values of the >> >> >> >> >> > original posterior*.mgz >> >> >> >> >> > 4) mri_binarize the whole hippocampus and its segments. So >> >> >> >> >> > binLeftHippoBody.mgz is the binary mask of left hippocampal body. >> >> >> >> >> > 5) mri-tesselate and mris_smooth the whole hippocampus binary mask to >> >> >> >> >> > create a surface (lh.surfHippo) >> >> >> >> >> > >> >> >> >> >> > Now that is the reason I would like to get the surface labels for >> >> >> >> >> > head, body and tail. I would like to build a annot in order to display >> >> >> >> >> > the colored segments over the whole hippocampus surface. >> >> >> >> >> > Your last tip was great and now I have vertex numbers at the labels >> >> >> >> >> > files and mris_label2annot works. It follows the commands I used to >> >> >> >> >> > process the hippocampal body: >> >> >> >> >> > mri_vol2surf --src binLeftHippoBody.mgz --out LeftHippoBody_surf.mgh >> >> >> >> >> > --out_type mgh --hemi lh --regheader suj1 --surf surfHippo >> >> >> >> >> > mri_cor2label --i LeftHippoBody_surf.mgh --surf suj1 lh surfHippo --id >> >> >> >> >> > 1 --l lh.HippoBody.label >> >> >> >> >> > >> >> >> >> >> > I put the --surf parameter pointing to lh.surfHippo because, if not, >> >> >> >> >> > it would use lh.white (default). As I said it works but the results >> >> >> >> >> > are not visually correct (see attached file). The surface loads on >> >> >> >> >> > freeview with no problem but if I try to load the label representing >> >> >> >> >> > the body or the annot with the 3 segments they do not appear. It seems >> >> >> >> >> > only a small part of the vertices appears in blue. I also get the >> >> >> >> >> > following output at the terminal window I used to start freeview: >> >> >> >> >> > >> >> >> >> >> > MRISreadAnnotationIntoArray: vertex index out of range: 122882 >> >> >> >> >> > i=00000000, in_array_size=11627 >> >> >> >> >> > annot file: ../label/lh.Hippo.annot >> >> >> >> >> > MRISreadAnnotationIntoArray: vertex index out of range: 122883 >> >> >> >> >> > i=00000000, in_array_size=11627 >> >> >> >> >> > annot file: ../label/lh.Hippo.annot >> >> >> >> >> > MRISreadAnnotationIntoArray: vertex index out of range: 122884 >> >> >> >> >> > i=00000000, in_array_size=11627 >> >> >> >> >> > annot file: ../label/lh.Hippo.annot >> >> >> >> >> > MRISreadAnnotationIntoArray: vertex index out of range: 122885 >> >> >> >> >> > i=00000000, in_array_size=11627 >> >> >> >> >> > annot file: ../label/lh.Hippo.annot >> >> >> >> >> > reading colortable from annotation file... >> >> >> >> >> > colortable with 4 entries read (originally ../label/Hippo.ctab) >> >> >> >> >> > colortable with 4 entries read (originally ../label/Hippo.ctab) >> >> >> >> >> > =00000000, in_array_size=11627 >> >> >> >> >> > >> >> >> >> >> > Since the posterior*.mgz files are 0.5 x 0.5 x 0.5 mm I also tried to >> >> >> >> >> > use mri_convert --vs 1 1 1, but it did not worked too. >> >> >> >> >> > I guess, or at least, I hope I am closer the image I want but I guess >> >> >> >> >> > some more steps are necessary. >> >> >> >> >> > Thank you for any help. >> >> >> >> >> > Marcos >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > Em Qui, 2013-10-17 às 22:19 -0400, Douglas Greve escreveu: >> >> >> >> >> >> >> >> >> >> >> >> Is *binLeftHippoBody.mgz a volume label or a surface label? If a >> >> >> >> >> >> volume label, map it onto the surface with mri_vol2surf, the run >> >> >> >> >> >> mri_cor2label *specifying --surf >> >> >> >> >> >> >> >> >> >> >> >> doug >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 10/17/13 5:00 PM, Marcos Martins da Silva wrote: >> >> >> >> >> >> >> >> >> >> >> >>> Hi, Doug >> >> >> >> >> >>> Thank you for your answer. >> >> >> >> >> >>> >> >> >> >> >> >>> I am trying cor2label as you suggested. First of all I am afraid to >> >> >> >> >> >>> say that website documentation and help from the own command are a >> >> >> >> >> >>> bit different so I got a little confused. But the following command >> >> >> >> >> >>> worked: *mri_cor2label --i binLeftHippoBody.mgz --id 1 --l 2.leftBody* >> >> >> >> >> >>> >> >> >> >> >> >>> Using freeview I could load the hippocampus volume and 2.leftBody as >> >> >> >> >> >>> a ROI. I attached a screenshot that also included 1.leftHead and >> >> >> >> >> >>> 3.leftTail, generated in the same way. >> >> >> >> >> >>> When I tried to concatenate the 3 labels into an annot file I got an >> >> >> >> >> >>> error: >> >> >> >> >> >>> >> >> >> >> >> >>> *mris_label2annot --s bert --h lh --ctab HippoColorLUT.txt --l >> >> >> >> >> >>> 1.leftHead.label --l 2.leftBody.label --l 3.leftTail.label --a >> >> >> >> >> >>> lefthippo* >> >> >> >> >> >>> *Loading /home/marcos/freesurfer/subjects/bert/surf/lh.orig* >> >> >> >> >> >>> *1 16711680 leftHead* >> >> >> >> >> >>> *ERROR: 1.leftHead.label, n=0, vertex -1 out of range* >> >> >> >> >> >>> >> >> >> >> >> >>> When I checked label file generated by mri_cor2label the first >> >> >> >> >> >>> collumn (vertex number) contains only *-1* as value. >> >> >> >> >> >>> It seems that when you use mri_cor2label it does not preserve or >> >> >> >> >> >>> even recover the vertex number. It also seems I need the correct >> >> >> >> >> >>> vertex number in label file to use mris_label2annot >> >> >> >> >> >>> Just to rule out a problem with the hippocampal subfield files I >> >> >> >> >> >>> tried the example command (extracted from command help): >> >> >> >> >> >>> mri_cor2label --i aseg.mgz --id 12 --l left-putamen.label >> >> >> >> >> >>> This label also shows only -1 as vertex number. >> >> >> >> >> >>> >> >> >> >> >> >>> Could you please explain me what do I need to do to get the vertex >> >> >> >> >> >>> numbers in the label file as output of mri_cor2label? >> >> >> >> >> >>> >> >> >> >> >> >>> Cheers, >> >> >> >> >> >>> Marcos >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> Em Qua, 2013-10-16 às 20:34 -0400, Douglas Greve escreveu: >> >> >> >> >> >>>> I think you need to use mri_cor2label (not very well named:) >> >> >> >> >> >>>> doug >> >> >> >> >> >>>> >> >> >> >> >> >>>> >> >> >> >> >> >>>> On 10/16/13 4:24 PM, Marcos Martins da Silva wrote: >> >> >> >> >> >>>> >> >> >> >> >> >>>>> Hi, Freesurfers. >> >> >> >> >> >>>>> I need to create some labels from binary masks. Sometime ago I >> >> >> >> >> >>>>> read a post >> >> >> >> >> >>>>> (https://mail.nmr.mgh.harvard.edu/pipermail//freesurfer/2013-October/033783.… >> >> >> >> >> >>>>> ) and, unless I am wrong, it seemed to me that mri_label2vol could >> >> >> >> >> >>>>> be the tool to get it. If so, could you please explain how? I >> >> >> >> >> >>>>> read documentation on wiki and help from the command itself and >> >> >> >> >> >>>>> could not see how to accomplish that. I could only find how to >> >> >> >> >> >>>>> create a volume from a label. What I need to do is to get a mask >> >> >> >> >> >>>>> like the binLeftHippoHead.mgz (attached) and create a label. >> >> >> >> >> >>>>> Assuming it is possible, I could also make labels for Hippocampal >> >> >> >> >> >>>>> body and head, merge the 3 labels into an annot file. This way i >> >> >> >> >> >>>>> can use Freeview to load the whole hippocampal surface and >> >> >> >> >> >>>>> discriminate the 3 segments by colors with the annot file. >> >> >> >> >> >>>>> Thanks in advance for any help. >> >> >> >> >> >>>>> Cheers, >> >> >> >> >> >>>>> Marcos. >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> _______________________________________________ >> >> >> >> >> >>>>> Freesurfer mailing list >> >> >> >> >> >>>>>Freesurfer(a)nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu> >> >> >> >> >> >>>>>https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >> >> >> >>>> >> >> >> >> >> >>>> _______________________________________________ >> >> >> >> >> >>>> Freesurfer mailing list >> >> >> >> >> >>>>Freesurfer(a)nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu> >> >> >> >> >> >>>>https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >> >> >> >>>> >> >> >> >> >> >>>> >> >> >> >> >> >>>> The information in this e-mail is intended only for the person to whom it is >> >> >> >> >> >>>> addressed. If you believe this e-mail was sent to you in error and the e-mail >> >> >> >> >> >>>> contains patient information, please contact the Partners Compliance HelpLine at >> >> >> >> >> >>>>http://www.partners.org/complianceline . If the e-mail was sent to you in error >> >> >> >> >> >>>> but does not contain patient information, please contact the sender and properly >> >> >> >> >> >>>> dispose of the e-mail. >> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> > >> > -- Douglas N. Greve, Ph.D. MGH-NMR Center greve(a)nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422 Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/

2 1

acquisition in 1 session vs 2 sessions
by Daniel Ferreira 13 Nov '13

13 Nov '13

Thanks a lot Doug, We have followed your suggestion and now fMRI is the third sequence. Both patients and controls will have two sessions too. Best Daniel ---------------------------------------------------------------------- Message: 1 Date: Sat, 09 Nov 2013 12:50:39 -0500 From: Douglas Greve <greve(a)nmr.mgh.harvard.edu> Subject: Re: [Freesurfer] acquisition in 1 session vs 2 sessions To: freesurfer(a)nmr.mgh.harvard.edu Message-ID: <527E75EF.2070807(a)nmr.mgh.harvard.edu> Content-Type: text/plain; charset="iso-8859-1" I think the only thing you would have to worry about is the fMRI since the way the subject reacts to the task (or state of subject during rest) might change depending upon how long he/she has been in the scanner. Why not do the fMRI at #3? Then each population would be in the scanner for the same amount of time. If the T1 and FLAIR are bandwidth matched, I'd do them in the same session. The only other confound could be that your controls might move more in the last couple of scans since they will have been in the scanner for a while at that point. Depending on your patient population, there might be difference in movement anyway. There should not be any problems with analyzing the data regardless of how you slice it up. doug On 11/9/13 3:56 AM, Daniel Ferreira wrote: Dear experts, We are designing a study including a long MR protocol: 1) Localizer 2) Cal 3) T1-FSPGR 4) FLAIR 3D 5) DTI 1 6) DTI 2 7) fMRI Due to patients characteristics we were thinking on splitting the acquisition in two different sessions (session 1: sequences 1, 2, 3, 4; session 2: sequences 1, 2, 5, 6, 7). Do you think we should do the same for the healthy controls or we can scan them in just one single session? I wonder how system session-related artifacts could differentially affect the two kinds of protocol (spitted vs. single). I also wonder how FreeSurfer processing can be affected by this issues. Thanks a lot. Daniel Ferreira _______________________________________________ Freesurfer mailing listFreesurfer@nmr.mgh.harvard.eduhttps://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

1 0

(no subject)
by Gonzalo Rojas Costa 13 Nov '13

13 Nov '13

Hi: Which is the optimal parameters for a morphometric sequence (fspgr?) n a 1.5 T MR OPTIMA 450w GE MRI equipment ?... Because, we are using an fspgr 1mm isotropic sequence, but we got wrong defined borders in some structures... for example, hypocampus, cortex-wm... I think it could be because the GE images appears smoothed in comparison with the Siemens Avanto mprage images that we also use... Any comments ?.... Sincerely, Gonzalo Rojas Costa -------------------------------- Gonzalo Rojas Costa Laboratory for Advanced Medical Image Processing Department of Radiology Clínica las Condes Lo Fontecilla 441, Las Condes, Santiago, Chile. Tel: 56-2-2105170 Cel: 56-9-97771785 www.clc.cl

1 0

Re: [Freesurfer] bvecs and bvals don't have the same number of entries
by Anastasia Yendiki 12 Nov '13

12 Nov '13

The problem is that your original TLR108.bvec file is still in 3 rows, not 3 columns. You need to transpose the rows into columns. Yes, there's an example config file that comes with the 5.3 distribution and it's as usual in $FREESURFER_HOME/bin/dmrirc.example. It's also described on the wiki, where all the info reflects the latest version of the software. http://surfer.nmr.mgh.harvard.edu/fswiki/Tracula Please include freesurfer(a)nmr.mgh.harvard.edu in these emails so that the full thread is archived. Thanks! a.y On Tue, 12 Nov 2013, Laura Christine Anderson wrote: > Attached are bvecs and bvals files from dmri directory. Thanks for the > advice on Freesurfer 5.3- is there a sample config file for Tracula for > that version? > > Laura C. Anderson, B.A. > Graduate Student > Clinical & Developmental Psychology > University of Maryland > College Park, MD 20742 > BPS 0112 > > > > > On 11/12/13 11:52 AM, "Anastasia Yendiki" <ayendiki(a)nmr.mgh.harvard.edu> > wrote: > >> >> Thanks. What do these files look like? >> /export/data/brain1/RSTOM/TLR108/dmri/bvecs >> /export/data/brain1/RSTOM/TLR108/dmri/bvals >> >> These are the ones that the error message in trac-all.log is about, so >> something probably goes wrong with the conversion from your original >> files. >> >> Also, I recommend very strongly that you use the latest version of >> tracula >> (from freesurfer 5.3). It's improved on both speed and performance. >> >> >> On Tue, 12 Nov 2013, Laura Christine Anderson wrote: >> >>> Hi Anastasia, I have version 5.1. Attached are bvecs and bvals files >>> with >>> 3 and 1 columns respectively as well as the trac-all.log file. >>> >>> Thanks! >>> Laura >>> >>> Laura C. Anderson, B.A. >>> Graduate Student >>> Clinical & Developmental Psychology >>> University of Maryland >>> College Park, MD 20742 >>> BPS 0112 >>> >>> >>> >>> >>> On 11/11/13 9:00 PM, "Anastasia Yendiki" <ayendiki(a)nmr.mgh.harvard.edu> >>> wrote: >>> >>>> >>>> Hi Laura - First of all, which version of freesurfer do you have? It >>>> looks >>>> to me like you've based your config file on the old example file that >>>> came >>>> with version 5.1. >>>> >>>> Second, could you please convert your bvecs and bvals files to 3 >>>> columns >>>> and 1 column, respectively, then run trac-all and send the trac-all.log >>>> file that shows the errors that you get? >>>> >>>> Thanks! >>>> a.y >>>> >>>> On Mon, 11 Nov 2013, Laura Christine Anderson wrote: >>>> >>>>> Hi Anastasia, I am still struggling with this same error message, >>>>> despite >>>>> having rearranged the bval and bvec files in many different >>>>> configurations >>>>> (and making sure that each value in these files had the same number of >>>>> digits, which I am not sure even matters). I am attaching my most >>>>> recent >>>>> bval and bvec files as well as the config file to see if you have any >>>>> advice. >>>>> >>>>> Thanks so much for your help! >>>>> >>>>> Laura C. Anderson, B.A. >>>>> Graduate Student >>>>> Clinical & Developmental Psychology >>>>> University of Maryland >>>>> College Park, MD 20742 >>>>> BPS 0112 >>>>> >>>>> >>>>> >>>>> >>>>> On 10/15/13 11:17 AM, "Anastasia Yendiki" >>>>> <ayendiki(a)nmr.mgh.harvard.edu> >>>>> wrote: >>>>> >>>>>> >>>>>> Hi Laura - This means that there is only 1 line in each of the files, >>>>>> so >>>>>> the end-of-line characters aren't recognized. I'd make sure that the >>>>>> file >>>>>> is saved as plain text. >>>>>> >>>>>> a.y >>>>>> >>>>>> On Tue, 15 Oct 2013, Laura Christine Anderson wrote: >>>>>> >>>>>>> When I run "wc -l" on the bvec and bval files, I get "1" for both. >>>>>>> Running >>>>>>> just "wc" gives "1 279 3312" for bvec and "1 93 456" for bval >>>>>>> >>>>>>> Laura C. Anderson, B.A. >>>>>>> Graduate Student >>>>>>> Clinical & Developmental Psychology >>>>>>> University of Maryland >>>>>>> College Park, MD 20742 >>>>>>> BPS 0112 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 10/14/13 5:18 PM, "Anastasia Yendiki" >>>>>>> <ayendiki(a)nmr.mgh.harvard.edu> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> Hi Laura - I don't think the error "bvecs and bvals don't have the >>>>>>>> same >>>>>>>> number of entries" should have to do with interspersed zero >>>>>>>> b-values. >>>>>>>> When >>>>>>>> you run "wc -l" on the bvecs and bvals files, what do you get? >>>>>>>> >>>>>>>> a.y >>>>>>>> >>>>>>>> On Mon, 14 Oct 2013, Laura Christine Anderson wrote: >>>>>>>> >>>>>>>>> Hi Anastasia, the bval/bvec files were created on a Mac and not >>>>>>>>> with >>>>>>>>> excel. I am not seeing the ^M character when I view the files in >>>>>>>>> unix >>>>>>>>> with >>>>>>>>> the more command or in gedit perhaps when I sent you the files, >>>>>>>>> something >>>>>>>>> became corrupted? I am wondering if my issue has something to do >>>>>>>>> with >>>>>>>>> the >>>>>>>>> fact that there are 3 sets of 30 rows with a b0 image before each >>>>>>>>> of >>>>>>>>> the 3 >>>>>>>>> sets. In the examples I have seen, the b0 images all seem to be at >>>>>>>>> the >>>>>>>>> beginning of the bvec and bval files. I am attaching a screenshot >>>>>>>>> of >>>>>>>>> the >>>>>>>>> bvec and bval files as I see them in case that is helpful. If you >>>>>>>>> would >>>>>>>>> rather me send the actual files again, what is the best way to do >>>>>>>>> that >>>>>>>>> without the formatting getting messed up? Before, I was using a >>>>>>>>> free >>>>>>>>> fileshare program. >>>>>>>>> >>>>>>>>> Thank you! >>>>>>>>> Laura >>>>>>>>> >>>>>>>>> Laura C. Anderson, B.A. >>>>>>>>> Graduate Student >>>>>>>>> Clinical & Developmental Psychology >>>>>>>>> University of Maryland >>>>>>>>> College Park, MD 20742 >>>>>>>>> BPS 0112 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/11/13 2:38 PM, "Anastasia Yendiki" >>>>>>>>> <ayendiki(a)nmr.mgh.harvard.edu> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Laura - Were these bval/bvec files created on windows or with >>>>>>>>>> excel >>>>>>>>>> by >>>>>>>>>> any chance? When you view them in unix (with the more command for >>>>>>>>>> example) >>>>>>>>>> you'll see an "^M" character instead of every end-of-line. Can >>>>>>>>>> you >>>>>>>>>> try >>>>>>>>>> editing these files in a unix editor to fix that? Let me know if >>>>>>>>>> this >>>>>>>>>> solves the problem. >>>>>>>>>> >>>>>>>>>> a.y >>>>>>>>>> >>>>>>>>>> On Fri, 11 Oct 2013, Laura Christine Anderson wrote: >>>>>>>>>> >>>>>>>>>>> Hi Anastasia, >>>>>>>>>>> Thanks so much for your help! Attached are bvec, bval and >>>>>>>>>>> trac-all.log >>>>>>>>>>> files. >>>>>>>>>>> >>>>>>>>>>> I have been stuck at one of the preprocessing steps (trac all) >>>>>>>>>>> for >>>>>>>>>>> some >>>>>>>>>>> time and keep getting the >>>>>>>>>>> error: bvecs and bvals don't have the same number of entries. I >>>>>>>>>>> saw >>>>>>>>>>> a >>>>>>>>>>> couple blogs online about >>>>>>>>>>> this, but did not see any resolution. I am wondering if it is >>>>>>>>>>> because >>>>>>>>>>> the B0 images are >>>>>>>>>>> interspersed? (see attached bvec file). If you have any >>>>>>>>>>> insight, I >>>>>>>>>>> would love some feedback >>>>>>>>>>> whenever you get the chance. >>>>>>>>>>> >>>>>>>>>>> Laura >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 2

Lower age limit
by Victor Kovac 12 Nov '13

12 Nov '13

Hello Freesurfers, I am just wondering if there is a generally accepted lower age limit for running recon-all and getting reliable results? Lack of myelination in most children below the age of 3 has caused segmentation issues in our dataset. Is this common? And, if so, has anything been published attesting to this? Thanks! Victor

2 1

freesurfer upgrade
by Octavian Lie 12 Nov '13

12 Nov '13

Dear All, We use freesurfer in an automatic routine mainly for brain extraction/ parcellation schemes. I want to upgrade from 5.2 to 5.3 on a linux (ubuntu, 64bit) computer, but without surprises. So: 1. When extracting files/installing freesurfer tar.gz, would the update override the 5.2 files if I want to keep the same path, or I have to delete 5.2 first? I obviously want to preserve '/subjects' data already processed. 2. Freesurfer distribution contains some CUDA files. On the computer, I have CUDA 5.5 version. Do you see any incompatibility issues (5.2 worked ok in this respect). 3. Could you send me the T1 and T2 space MR protocols you use for assistance with getting pial recon optimized. Thank you, Octavian

2 1

Questions regarding stats file
by pfotiad＠nmr.mgh.harvard.edu 12 Nov '13

12 Nov '13

Hi, I am using FS v5.3 and I had two questions regarding the calculation of cortical thickness in the stats files: 1) Is the average cortical thickness of each structure (i.e. precuneus) calculated by averaging the cortical thickness values of each location in that structure? 2) Is the mean thickness calculated in the *h.aparc.stats (or in the other aparc stats files) calculated by averaging the cortical thickness values of all the structures in that hemisphere, or by using a weighted average of the cortical thicknesses of the structures included in that hemisphere? Thanks, Panos

2 4

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