Freesurfer

freesurfer@nmr.mgh.harvard.edu

19 participants
30088 discussions

Generation of brodmann area label and statistics..
by Gonzalo Rojas Costa 15 Nov '13

15 Nov '13

Hi: I have some freesurfer processed studies.... I used 5.1 version, and now I found that it don't has the brodmann area labels and statistics generated in some studies... How can I create it without doing again the complete recon-all ?.... Sincerely, -------------------------------- 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

2 2

Newest freeview version...
by Gonzalo Rojas Costa 15 Nov '13

15 Nov '13

Hi: Which is the freeview newest version ?... the one that is included in freesurfer 5.3.0 package ?... 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] Is transformation matrix in .nii (nifti) header applied by FS?
by Douglas N Greve 14 Nov '13

14 Nov '13

you will see some differences due to reslicing and interpolation. These differences should be somewhat random, so they might be difficult to detect in a group analysis. But in general, you should treat all your data the same. On 11/14/2013 03:40 PM, cabe(a)uos.de wrote: > thanks, that was already helpful. > > But does the fact that the transformation is carried out affect the results? > I mean, the images has to be resliced and interpolated during this > transformation. So intensities change slightly. If i would process the > same subject, once with and once without an reorientation in the beginning > as start input data, would you expect a difference? > > Or in other words, if you would compare groups, where one group was AC-PC > aligned with SPM before freesurfer processing and the other was not, could > any of the differences be attributed to the different input files > (transformation matrix in the nii header). > > Chris > >> There are two matrices in the nifti file (qform and sform). By default >> we use the qform. The qform is 6 dof and so is probably not appropriate >> for your talairach transform. Bottom line is that the sform is probably >> being ignored. >> >> doug >> >> >> On 11/14/2013 07:18 AM, cabe(a)uos.de wrote: >>> Hello, >>> >>> I have a question regarding nifti (.nii) input files. I have .nii image >>> files, which are aligned to AC-PC with SPM. The actual (original) data >>> in >>> this file is not changed, but the transformation matrix is saved in the >>> .nii file. >>> >>> When displaying the freesurfer reconstructed results with tkmedit, the >>> images are tilted (AC-PC aligned). So it seems that freesurfer reads and >>> applies the transformation saved in the nii file. >>> >>> Is that true? and if yes at which step? >>> >>> When using the recon-all -i command to create the starting folders and >>> mgz >>> files before starting the actual freesurfer processing, is the >>> transformation matrix used to realign the images during this first >>> process, and the following processing is done on the reoriented image? >>> or >>> is it just used for display? Or is the fact that the image appears >>> tilted >>> a result of the Talairach transform and the nii header was not read at >>> all? >>> >>> I am asking because, I have subjects which were SPM aligned, and subject >>> which were not. I am wondering if it makes any difference, since due to >>> an >>> initial reorientation data will be interpolated and maybe a bit >>> smoothed, >>> compared to data which was not aligned before. >>> >>> Does anybody have any experience with that and a feeling if an >>> reorientation beforehand would have an effect on the outcome for >>> cortical >>> thickness maesures? >>> >>> Thaks for any comments, >>> Chris >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Freesurfer mailing list >>> Freesurfer(a)nmr.mgh.harvard.edu >>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> >> -- >> Douglas N. Greve, Ph.D. >> MGH-NMR Center >> greve(a)nmr.mgh.harvard.edu >> Phone Number: 617-724-2358 >> Fax: 617-726-7422 >> >> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting >> FileDrop: 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/ >> >> _______________________________________________ >> 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. >> >> > > -- 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/

1 0

Re: [Freesurfer] Seg fault with mri_segstats?
by Douglas N Greve 14 Nov '13

14 Nov '13

Hmmm, I can't replicate this error. This is 5.3 I assume? doug On 11/12/2013 06:02 PM, Michael Waskom wrote: > sorry, unclear why the original email wasn't included in the reply. > copied here: > > > I'm running into a strange seg fault when trying to use mri_segstats > (it's actually ocurring within mri_glmfit-sim, but I can reproduce it > manually) > > This is the line that fails (stripping the leading paths for readability): > > mri_segstats --seg cache.th20.pos.sig.ocn.mgh --exclude 0 --i > concat_output.nii.gz --sum mri_glmfit-sim.junk.84357 --avgwf > cache.th20.pos.y.ocn.dat > > With the log: > > $Id: mri_segstats.c,v 1.75.2.9 2013/02/16 00:09:33 greve Exp $ > cwd > cmdline mri_segstats --seg > /Users/mwaskom/Studies/PUnCH/cache/punch-switch_control/fsaverage_group/_l1_contrast_decision_neg/_hemi_lh/glmfit/_glm_results/osgm/cache.th20.pos.sig.ocn.mgh > --exclude 0 --i > /Users/mwaskom/Studies/PUnCH/cache/punch-switch_control/fsaverage_group/_l1_contrast_decision_neg/_hemi_lh/glmfit/_glm_results/concat_output.nii.gz > --sum mri_glmfit-sim.junk.84357 --avgwf cache.th20.pos.y.ocn.dat > sysname Darwin > hostname ben-octocore.stanford.edu <http://ben-octocore.stanford.edu/> > machine i386 > user mwaskom > UseRobust 0 > Loading > /Users/mwaskom/Studies/PUnCH/cache/punch-switch_control/fsaverage_group/_l1_contrast_decision_neg/_hemi_lh/glmfit/_glm_results/osgm/cache.th20.pos.sig.ocn.mgh > Loading > /Users/mwaskom/Studies/PUnCH/cache/punch-switch_control/fsaverage_group/_l1_contrast_decision_neg/_hemi_lh/glmfit/_glm_results/concat_output.nii.gz > Voxel Volume is 1 mm^3 > Generating list of segmentation ids > Found 5 segmentations > Computing statistics for each segmentation > 1 1 10934 10934.000 > 2 2 2409 2409.000 > 3 3 1620 1620.000 > 4 4 2044 2044.000 > > Reporting on 4 segmentations > Computing spatial average of each frame > 0 1 2 3Segmentation fault > > > Intriguingly, it does not segfault if I remove the --avgwf parameter > OR the --exclude 0 parameter. It does segfault if I use --avgwfvol > instead of --avgwf > > I'm not too sure what's going on, I can otherwise read the > segmentation file and --y file and do statistical operations on them, > and I can write other files to the directory I'm testing this in. > > Here's my system info: > > FREESURFER_HOME: /usr/local/freesurfer/5.3.0 > > Build stamp: freesurfer-Darwin-snowleopard-i686-stable-pub-v5.3.0 > > Kernel info: Darwin 10.8.0 i386 > > Any thoughts? > > > On Tue, Nov 12, 2013 at 1:36 PM, Douglas N Greve > <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>> wrote: > > sorry, what is this in response to? > > > > On 11/06/2013 08:13 PM, Michael Waskom wrote: > > Hi Doug, > > I can't discern anything off about these images, but I hope > it's easy to figure out! They can be downloaded from here ; I > figured that was easiest. > > Michael > > > -- > Douglas N. Greve, Ph.D. > MGH-NMR Center > greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> > Phone Number: 617-724-2358 <tel:617-724-2358> > Fax: 617-726-7422 <tel:617-726-7422> > > Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting > <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> > FileDrop: 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> > Outgoing: > ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ > > > > 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/

1 0

Is transformation matrix in .nii (nifti) header applied by FS?
by cabe＠uos.de 14 Nov '13

14 Nov '13

Hello, I have a question regarding nifti (.nii) input files. I have .nii image files, which are aligned to AC-PC with SPM. The actual (original) data in this file is not changed, but the transformation matrix is saved in the .nii file. When displaying the freesurfer reconstructed results with tkmedit, the images are tilted (AC-PC aligned). So it seems that freesurfer reads and applies the transformation saved in the nii file. Is that true? and if yes at which step? When using the recon-all -i command to create the starting folders and mgz files before starting the actual freesurfer processing, is the transformation matrix used to realign the images during this first process, and the following processing is done on the reoriented image? or is it just used for display? Or is the fact that the image appears tilted a result of the Talairach transform and the nii header was not read at all? I am asking because, I have subjects which were SPM aligned, and subject which were not. I am wondering if it makes any difference, since due to an initial reorientation data will be interpolated and maybe a bit smoothed, compared to data which was not aligned before. Does anybody have any experience with that and a feeling if an reorientation beforehand would have an effect on the outcome for cortical thickness maesures? Thaks for any comments, Chris

2 1

Error when using --mask flag in mri_glmfit
by Suzanne Oosterwijk 14 Nov '13

14 Nov '13

Hello all, I want to run a Monte Carlo simulation within a volume ROI and I am running into a problem when I use the --mask flag while running glmfit. My question is very similar to the question asked in "[Freesurfer] Volume-based Monte Carlo Restricted to a within mask area" but I could not find the response to this question. Here is my code. First, I created a volume mask with mri_binarize: mri_binarize --match 18 --i home/sooster1/Desktop/FALSE_FEEDBACK_imaging/DATA/feedback_structural/fsaverage/mri/aseg.mgz --o /home/sooster1/Desktop/FALSE_FEEDBACK_imaging/DATA/feedback_structural/ROI_handmade_labels/amygdala_lh.mgz I checked the mask and it looked good. Then I use the mask in glmfit. mri_glmfit --y ces.nii.gz --osgm --glmdir glm.amygdala_lh --mask /home/sooster1/Desktop/FALSE_FEEDBACK_imaging/DATA/feedback_structural/ROI_handmade_labels/amygdala_lh.mgz When I do this, I get the following error: ERROR: dimension mismatch 1 between y and mask I guess this means that the ces.nii.gz file and mask file don't match, but I have no idea how to solve this. Any thoughts? Thanks! Suzanne -- Suzanne Oosterwijk, Ph.D. Postdoctoral Researcher Department of Social Psychology University of Amsterdam s.oosterwijk@u <s.oosterwijk(a)neu.edu>va.nl https://sites.google.com/site/suzanneoosterwijk/

2 5

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

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