Re: [Freesurfer] Help with LGI
2020-07-11
Thread
Lab of Autism and Developmental Neuroscience, Lab of Autism and Developmental Neuroscience
External Email - Use Caution
Dear Douglas,
So to accomplish this, should I do the following through matlab?
The following code has to be in matlab’s startup.m file:
1
2
3
4
5
6
7
8
9
% FreeSurfer -%
fshome = getenv('FREESURFER_HOME');
fsmatlab = sprintf('%s/matlab',fshome);
if (exist(fsmatlab) == 7)
path(path,fsmatlab);
end
clear fshome fsmatlab;
%-%
Also, if you are getting “ERROR: Matlab is required to run
mris_compute_lgi!”, it means your have to add the Matlab path to
Freesurfer`s $PATH variable for it to run.
To do this automatically when starting FS, just edit the .tcshrc file
(assuming you run FS from TCSH) adding the location of your Matlab’s bin
folder:
1
setenv PATH "/Applications/MATLAB_R2014a.app/bin":"$PATH"
Thanks,
Alex
On Fri, Jul 10, 2020 at 10:30 AM Douglas N. Greve
wrote:
> You need to have matlab in your path so that when you type "matlab" it
> starts matlab
>
> On 7/9/2020 4:58 PM, Lab of Autism and Developmental Neuroscience, Lab of
> Autism and Developmental Neuroscience wrote:
>
> External Email - Use Caution
> Dear Freesurfer experts,
>
> I'm needing some simple help running LGI. After downloading MATLAB + Image
> processing toolbox and double checking if the ?h.pial file is located in
> the SUBJECT_DIR, the recon-all -s (subject_ID) -localGI command still
> doesn't work. The output says that I still didn't install matlab onto my
> computer, so maybe it has something to do with setting
> $FREESURFER_HOME/matlab in your matlab path setup in your ~/matlab/starup.m
> script, but I'm unsure how to do this. Please see the output below:
>
> Mac-Pro:ace_complete ajobsaid$ recon-all -s HAR30003_srs2_2 -localGI
> Subject Stamp: freesurfer-darwin-macOS-7.1.0-20200511-813297b
> Current Stamp: freesurfer-darwin-macOS-7.1.0-20200511-813297b
> INFO: SUBJECTS_DIR is /Applications/ace_complete
> Actual FREESURFER_HOME /Applications/freesurfer
> -rw-rw-r-- 1 ajobsaid 982768932 959822 Jul 9 10:50
> /Applications/ace_complete/HAR30003_srs2_2/scripts/recon-all.log
> Darwin iMac-Pro.local 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20
> 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64
> /Applications/ace_complete/HAR30003_srs2_2/mri/transforms
> /Applications/ace_complete/HAR30003_srs2_2
> /Applications/ace_complete/HAR30003_srs2_2
> #@# white curv lh Thu Jul 9 12:58:04 PDT 2020
> cd /Applications/ace_complete/HAR30003_srs2_2/mri
> mris_place_surface --curv-map ../surf/lh.white 2 10 ../surf/lh.curv
>Update not needed
> #@# white area lh Thu Jul 9 12:58:04 PDT 2020
> cd /Applications/ace_complete/HAR30003_srs2_2/mri
> mris_place_surface --area-map ../surf/lh.white ../surf/lh.area
>Update not needed
> #@# pial curv lh Thu Jul 9 12:58:04 PDT 2020
> cd /Applications/ace_complete/HAR30003_srs2_2/mri
> mris_place_surface --curv-map ../surf/lh.pial 2 10 ../surf/lh.curv.pial
>Update not needed
> #@# pial area lh Thu Jul 9 12:58:04 PDT 2020
> cd /Applications/ace_complete/HAR30003_srs2_2/mri
> mris_place_surface --area-map ../surf/lh.pial ../surf/lh.area.pial
>Update not needed
> #@# thickness lh Thu Jul 9 12:58:04 PDT 2020
> cd /Applications/ace_complete/HAR30003_srs2_2/mri
> mris_place_surface --thickness ../surf/lh.white ../surf/lh.pial 20 5
> ../surf/lh.thickness
>Update not needed
> #@# area and vertex vol lh Thu Jul 9 12:58:04 PDT 2020
> cd /Applications/ace_complete/HAR30003_srs2_2/mri
> mris_place_surface --thickness ../surf/lh.white ../surf/lh.pial 20 5
> ../surf/lh.thickness
>Update not needed
> #@# white curv rh Thu Jul 9 12:58:04 PDT 2020
> cd /Applications/ace_complete/HAR30003_srs2_2/mri
> mris_place_surface --curv-map ../surf/rh.white 2 10 ../surf/rh.curv
>Update not needed
> #@# white area rh Thu Jul 9 12:58:04 PDT 2020
> cd /Applications/ace_complete/HAR30003_srs2_2/mri
> mris_place_surface --area-map ../surf/rh.white ../surf/rh.area
>Update not needed
> #@# pial curv rh Thu Jul 9 12:58:04 PDT 2020
> cd /Applications/ace_complete/HAR30003_srs2_2/mri
> mris_place_surface --curv-map ../surf/rh.pial 2 10 ../surf/rh.curv.pial
>Update not needed
> #@# pial area rh Thu Jul 9 12:58:04 PDT 2020
> cd /Applications/ace_complete/HAR30003_srs2_2/mri
> mris_place_surface --area-map ../surf/rh.pial ../surf/rh.area.pial
>Update not needed
> #@# thickness rh Thu Jul 9 12:58:04 PDT 2020
> cd /Applications/ace_complete/HAR30003_srs2_2/mri
> mris_place_surface --thickness ../surf/rh.white ../surf/rh.pial 20 5
> ../surf/rh.thickness
>Update not needed
> #@# area and vertex vol rh Thu Jul 9 12:58:04 PDT 2020
> cd /Applications/ace_complete/HAR30003_srs2_2/mri
> mris_place_surface --thickness ../surf/rh.white ../surf/rh.pial 20 5
> ../surf/rh.thickness
>Update not needed
> /Applications/ace_complete/HAR30003_srs2_2/surf
> #
> #@# Local Gyrification Index lh Thu J
Re: [Freesurfer] discontiguous regions assigned to same label by mris_divide_parcellation
Hi Chris If you can upload this subject and let us know exactly which parcels are duplicated we will take a look Cheers Bruce From: freesurfer-boun...@nmr.mgh.harvard.edu On Behalf Of Mcnorgan, Christopher Sent: Saturday, July 11, 2020 1:55 PM To: Freesurfer Mailing List Subject: [Freesurfer] discontiguous regions assigned to same label by mris_divide_parcellation External Email - Use Caution I’ve been using the .annot files generated by group-level GLM results for functional masks for task-related functional connectivity studies. Depending on threshold and contrast, the clusters can be quite large, and I would prefer to use the mris_divide_parcellation utility to break the clusters up into smaller subregions, and generally use the size threshold to make the regions roughly equal size. One quirk of mris_divide_parcellation is that, because it divides along the longest axis, if I want my final region sizes to be small (relative to the size of the whole cluster), I often find that the subdivisions take on the form of many narrow bands perpendicular to the axis of division. I have attempted to combat this by applying the utility in two passes: in the first pass, I might call: mris_divide_parcellation fsaverage lh mycontrast.annot 1600 mycontrast_1600 This first breaks up large clusters into 1600mm2 subclusters along their longest axes If my goal is to have 400mm regions, I then call mris_divide_parcellation on the new annotation: mris_divide_parcellation fsaverage lh mycontrast_1600.annot 400 mycontrast_400 This has the desired effect of generating roughly 400mm regions that are roughly square, at least, compared to the very narrow regions I would have gotten had I just done a single pass using 400mm subdivisions from the original annotation. The problem I am having is that the subdivisions in the second pass appear to be assigning discontiguous subdivisions of the same source cluster to the same label. An example is attached. The subdivisions have the proportions I’m looking for, but two regions at opposite ends of the same cluster have the same label (there are actually three pairs of noncontiguous regions with the same label in this large cluster). I am wondering if there is any way that this can be avoided? [cid:image001.jpg@01D65793.8E8331E0] /** * Chris McNorgan * Assistant Professor * Department of Psychology * University at Buffalo, * The State University of New York * http://ccnlab.buffalo.edu/ * Office: 716.645.0236 * Lab: 716.645.0222 **/ ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
[Freesurfer] discontiguous regions assigned to same label by mris_divide_parcellation
External Email - Use Caution I’ve been using the .annot files generated by group-level GLM results for functional masks for task-related functional connectivity studies. Depending on threshold and contrast, the clusters can be quite large, and I would prefer to use the mris_divide_parcellation utility to break the clusters up into smaller subregions, and generally use the size threshold to make the regions roughly equal size. One quirk of mris_divide_parcellation is that, because it divides along the longest axis, if I want my final region sizes to be small (relative to the size of the whole cluster), I often find that the subdivisions take on the form of many narrow bands perpendicular to the axis of division. I have attempted to combat this by applying the utility in two passes: in the first pass, I might call: mris_divide_parcellation fsaverage lh mycontrast.annot 1600 mycontrast_1600 This first breaks up large clusters into 1600mm2 subclusters along their longest axes If my goal is to have 400mm regions, I then call mris_divide_parcellation on the new annotation: mris_divide_parcellation fsaverage lh mycontrast_1600.annot 400 mycontrast_400 This has the desired effect of generating roughly 400mm regions that are roughly square, at least, compared to the very narrow regions I would have gotten had I just done a single pass using 400mm subdivisions from the original annotation. The problem I am having is that the subdivisions in the second pass appear to be assigning discontiguous subdivisions of the same source cluster to the same label. An example is attached. The subdivisions have the proportions I’m looking for, but two regions at opposite ends of the same cluster have the same label (there are actually three pairs of noncontiguous regions with the same label in this large cluster). I am wondering if there is any way that this can be avoided? [cid:373867F5-ADB4-4D59-86B1-8384131E3822] /** * Chris McNorgan * Assistant Professor * Department of Psychology * University at Buffalo, * The State University of New York * http://ccnlab.buffalo.edu/ * Office: 716.645.0236 * Lab: 716.645.0222 **/ ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
[Freesurfer] mri_fieldsign error
External Email - Use Caution Hi Doug, I used FS 7.1 under WSL to analyze retinotopy data. Since the ring and wedge were presented at a different frequency, the data had to be analyzed separately for each condition. To get the field sign, I had to use the mri_fieldsign function to combine polar and eccen data. However, an error happened with running mri_fieldsign: “Segmentation fault (core dumped)”. The following is the command-line output. Thanks for your help! Xiaomin cwd /mnt/d/xyLinuxStaff/projects/wedge_amygdala cmdline mri_fieldsign --fs LOO_xy/bold/rtopy.wedge.self.rh/fieldsign/fieldsign.nii.gz --polar LOO_xy/bold/rtopy.wedge.self.rh/polar/real.nii.gz LOO_xy/bold/rtopy.wedge.self.rh/polar/imag.nii.gz --eccen ../ring_amygdala/LOO_xy/bold/rtopy.ring.self.rh/eccen/real.nii.gz ../ring_amygdala/LOO_xy/bold/rtopy.ring.self.rh/eccen/imag.nii.gz --s LOO --hemi rh --sphere sysname Linux hostname DESKTOP-SVDQE4Q machine x86_64 user xiaominyue eccen real ../ring_amygdala/LOO_xy/bold/rtopy.ring.self.rh/eccen/real.nii.gz eccen imag ../ring_amygdala/LOO_xy/bold/rtopy.ring.self.rh/eccen/imag.nii.gz polar real LOO_xy/bold/rtopy.wedge.self.rh/polar/real.nii.gz polar imag LOO_xy/bold/rtopy.wedge.self.rh/polar/imag.nii.gz patch (null) subject LOO hemirh fwhm-1.00 nsmooth -1 fieldsign LOO_xy/bold/rtopy.wedge.self.rh/fieldsign/fieldsign.nii.gz usenew 1 Reading /mnt/d/xyLinuxStaff/anatMRI_amy//LOO/surf/rh.sphere Using spherical coordinates Reading /mnt/d/xyLinuxStaff/anatMRI_amy//LOO/label/rh.aparc.annot reading colortable from annotation file... colortable with 36 entries read (originally /autofs/space/tanha_002/users/greve/fsdev.build/average/colortable_desikan_killiany.txt) Complex Ripping Zeros Rot (rad): 0 0 surfer: compute_fieldsign2() dthresh = 1.5 shape = 1 nvertices = 153801 0 0 45452 0.03 33.2224 1018 1000 39160 21.33 -18.3959 2055 2000 44734 43.26 33.0783 3148 3000 49793 65.38 0.653687 4344 4000 38626 88.16 16.7555 5529 5000 54149 110.12 -4.90118 6706 6000 61599 133.36 -5.74607 7971 7000 50134 155.88 -17.5589 9165 8000 34182 178.05 -18.9387 10591 9000 59682 200.70 -4.60514 12034 1 63856 223.18 -4.4884 13297 11000 41007 245.62 27.3489 14938 12000 27365 267.70 -1.40077 16684 13000 23615 289.10 -0.518007 18048 14000 47088 309.37 18.7017 19798 15000 21060 330.11 15.9458 21681 16000 33067 350.27 -11.1953 23173 17000 28744 371.48 -6.18747 25112 18000 27738 392.41 -6.93845 26953 19000 20538 414.47 2.99349 28903 2 80583 435.98 -0.338512 30319 21000 16251 459.83 -45.2313 32174 22000 17139 483.36 -2.31642 34093 23000 13307 507.02 19.1461 36170 24000 17826 530.65 -10.7575 37683 25000 69324 555.78 -6.17011 39666 26000 14043 583.29 -10.5151 41746 27000 76017 609.92 -0.0112556 43986 28000 84646 636.28 1.24722 46088 29000 9763 664.26 12.7035 48326 3 92161 694.30 2.03416 50431 31000 99884 724.91 1.20525 ./xy_make_wedge_fieldsign.bash: line 21: 22473 Segmentation fault (core dumped) mri_fieldsign --fs $line/bold/rtopy.wedge.self.$hemi/fieldsign/fieldsign.nii.gz --polar $line/bold/rtopy.wedge.self.$hemi/polar/real.nii.gz $line/bold/rtopy.wedge.self.$hemi/polar/imag.nii.gz --eccen ../ring_amygdala/$line/bold/rtopy.ring.self.$hemi/eccen/real.nii.gz ../ring_amygdala/$line/bold/rtopy.ring.self.$hemi/eccen/imag.nii.gz --s $subjname --hemi $hemi --sphere ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
