Re: [Freesurfer] overlapping labels
Hi David, it's probably the last one it encounters, but they are not supposed to overlap. cheers Bruce On Thu, 5 Jul 2012, David Grayson wrote: Hi freesurfers, Can a .annot file include labels with overlapping vertices? If not, then when using mris_label2annot, how does freesurfer decide which label to assign the vertices to? Thanks, David ___ Freesurfer mailing list 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.
Re: [Freesurfer] TkSurfer and new color table. Mislabelling
Thanks Douglas. It did work using the color table with just the included labels (I had to renumber the labels in the table) For left: 1 ctx-lh-bankssts 255 42 0 0 2 ctx-lh-caudalmiddlefrontal 255 14 0 0 3 ctx-lh-entorhinal 255 17 0 0 4 ctx-lh-paracentral 255 43 0 0 5 ctx-lh-parstriangularis 255 15 0 0 6 ctx-lh-postcentral 255 14 0 0 7 ctx-lh-superiorfrontal 255 79 0 0 8 ctx-lh-frontalpole 255 17 0 0 9 ctx-lh-temporalpole 255 14 0 0 For right: 1 ctx-rh-bankssts 255 18 0 0 2 ctx-rh-isthmuscingulate 255 39 0 0 3 ctx-rh-medialorbitofrontal 255 60 0 0 4 ctx-rh-parstriangularis 255 13 0 0 5 ctx-rh-rostralanteriorcingulate 255 40 0 0 6 ctx-rh-superiorparietal 255 48 0 0 7 ctx-rh-frontalpole 255 106 0 0 On Thu, Jul 5, 2012 at 7:14 PM, Douglas N Greve gr...@nmr.mgh.harvard.eduwrote: Hi Pedro Paulo, it is not quite the right procedure, but I'm surprised that it gave unknown for all labels. Try modifying the colortable.txt such that the first entry is the name and color for your first label, etc. doug On 07/05/2012 03:44 PM, Pedro Paulo de Magalhães Oliveira Junior wrote: Doug, I did mri_annotation2label --subject bert --hemi lh --outdir $SUBJECTS_DIR/bert/label mri_annotation2label --subject bert --hemi rh --outdir $SUBJECTS_DIR/bert/label And then mris_label2annot --s bert --hemi lh --ctab $FREESURFER_HOME/**FreeSurferColorLUT.txt --l lh.bankssts.label --l lh.caudalmiddlefrontal.label --l lh.entorhinal.label --l lh.paracentral.label --l lh.parstriangularis.label --l lh.postcentral.label --l lh.superiorfrontal.label --l lh.frontalpole.label --l lh.temporalpole.label --a myannot and mris_label2annot --s bert --hemi rh --ctab $FREESURFER_HOME/**FreeSurferColorLUT.txt --l rh.bankssts.label --l rh.isthmuscingulate.label --l rh.medialorbitofrontal.label --l rh.parstriangularis.label --l rh.rostralanteriorcingulate.**label --l rh.superiorparietal.label --l rh.frontalpole.label --a myannot If this is the right procedure I guess I'll have to modify the existing annot in matlab because all the surface is being labelled as Unknown. Thanks PPJ On Thu, Jul 5, 2012 at 4:01 PM, Douglas N Greve gr...@nmr.mgh.harvard.edu mailto:gr...@nmr.mgh.harvard.**edugr...@nmr.mgh.harvard.edu wrote: You can also break up the annot into labels ( mri_annotation2label) then recombine them with a new color table with mris_label2annot. doug On 07/05/2012 02:57 PM, Bruce Fischl wrote: Hi PPJ, I think the color lut is embedded in the aparc.annot. If you want to change it you have to change the one that's in the .annot. I would do it in matlab. cheers Bruce On Thu, 5 Jul 2012, Pedro Paulo de Magalhães Oliveira Junior wrote: I'm trying to generate an image to a paper and I have to colorize some areas of the cortex with specific colors. I have edited the FreeSurferColorLUT.txt changing the following lines: 1001 ctx-lh-bankssts 255 42 0 0 1003 ctx-lh-caudalmiddlefrontal 255 14 0 0 1006 ctx-lh-entorhinal 255 17 0 0 1017 ctx-lh-paracentral 255 43 0 0 1020 ctx-lh-parstriangularis 255 15 0 0 1022 ctx-lh-postcentral 255 14 0 0 1028 ctx-lh-superiorfrontal 255 79 0 0 1032 ctx-lh-frontalpole 255 17 0 0 1033 ctx-lh-temporalpole 255 14 0 0 2001 ctx-rh-bankssts 255 18 0 0 2010 ctx-rh-isthmuscingulate 255 39 0 0 2014 ctx-rh-medialorbitofrontal 255 60 0 0 2020 ctx-rh-parstriangularis 255 13 0 0 2026 ctx-rh-**rostralanteriorcingulate 255 40 0 0 2029 ctx-rh-superiorparietal 255 48 0 0 2032 ctx-rh-frontalpole 255 106 0 0 all other regions are 127 127 127 0 When I load the surface for some case with: tksurfer bert lh pial -annot aparc -ctab FreeSurferColorLUT.txt I get the usual coloring scheme with the labels correct. TkSurfer seems to be ignoring FreeSurferColorLUT.txt, but the labels are placed in the right spots. When I try to manually force the FreeSurferColorLUT.txt I'm visualizing an all grey image. And the surface is completely mislabeled, there is a 4th ventricle in the surface, putamen in the surface, etc. What am I doing wrong? --**--** - Pedro Paulo de Magalhães Oliveira Junior Netfilter SpeedComm Telecom-- www.netfilter.com.br http://www.netfilter.com.br -- For mobile: http://itunes.apple.com/br/**artist/netfilter/id365306441http://itunes.apple.com/br/artist/netfilter/id365306441 __**_ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu mailto:freesur...@nmr.mgh.**harvard.eduFreesurfer@nmr.mgh.harvard.edu
[Freesurfer] Bug in mri_segstats.c or MRIvoxelsInLabelWithPartialVolumeEffects in utils/mri.c
I've posted a question about a strange behavior of mri_segstats if voxel size isn't 1 mm3 and --pv option is used. I found a reason of this problem in the source code of mri_segstats.c (release_5_1_0 branch was checked out from read-only CVS source-code repository) In mri_segstats.c the return value from MRIvoxelsInLabelWithPartialVolumeEffects is used as the number of voxels; nhits = MRIvoxelsInLabelWithPartialVolumeEffects (seg, pvvol, StatSumTable[n].id, NULL, NULL); vol = nhits*voxelvolume; However, MRIvoxelsInLabelWithPartialVolumeEffects in utils/mri.c returns volume (e.g. volume += vox_vol; or volume += vox_vol * pv;), not the number of voxels. nhits value is adjusted by voxel volume in mri_segstats.c (vol = nhits*voxelvolume), so that the voxelvolume (vox_vol) is multiplied twice. The volume reported by mri_segstats, therefore, is too small if the voxel volume is less than 1 mm^3 or too large if the voxel volume is larger than 1 mm3. Note that this is not a problem when voxel volume is conformed to 1 mm3 (default option in recon-all). I think many of FreeSurfer programs do not support high-resolution ( 1mm3) image without conforming to 1 mm3 voxel, but could you fix the problem of mri_segstats? I want to use mri_segstats with partial volume correction for high-resolution MRI image. Thank you, --Masaya On 06/26/2012 08:40 AM, Masaya Misaki wrote: Hello all, I found volume size reported by mri_segstats is changed very much depending on voxel size when partial volume correction (--pv option) is used. The difference was much larger than that can be explained by the difference of image resolution. (mri_segstats version is 1.75.22 2011/4/27 in FreeSurfer v5.1.0) When I performed segmentation for high-resolution image (voxel size = 0.5 mm^3), I found all volumes of segmented regions in aseg.stats was too small; about 8 times smaller than that was estimated from 1mm^3 conformed image. So I tested the effect of voxel size on mri_segstats. At first, recon-all was run with conforming 1mm^3 voxel (default option). Then aseg.mgz and norm.mgz were conformed to small voxel size, and mri_segstats was applied to the conformed files: mri_convert aseg.mgz aseg_cs05.mgz -cs 0.5 rt nearest mri_convert norm.mgz norm_cs05.mgz -cs 0.5 mri_segstats --seg aseg_cs05.mgz --pv norm_cs05.mgz \ --ctab $FREESURFER_HOME/FreeSurferColorLUT.txt \ --nonempty --excludeid 0 --sum aseg_cs05.stats (these are just for testing the effect of voxel size, not for actual analysis) All volumes reported in aseg_cs05.stats (for 0.5mm^3 voxel) was about 8 times smaller than aseg.stats (for 1mm^3 voxel). So the reported volume was scaled with the same ratio as the voxel size. Same effect was observed when voxel size was conformed to larger one (e.g. 1.5mm^3); reported volumes were about 3 times larger than those for 1mm^3-voxel. The number of voxels in the segmented regions (Nvoxels column in aseg.stats) were similar across different voxel sizes while voxel sizes are different. When --pv option was not used, the reported volumes were almost the same across different voxel sizes. So the partial volume correction in mri_segstats seems to depend on voxel size. Can I fix this with some missed options or shouldn't I use --pv option for the image with voxel size other than 1mm^3? thanks, -- Masaya Misaki Ph.D. ___ Freesurfer mailing list 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.
[Freesurfer] Hanging during Fix Topology
Hi all, I'm running FreeSurfer v.4.0.5 (see below) and it keeps hanging during the Fix Topology sequence while correcting defects. The last few lines before it's hanging are included below - any suggestions? freesurfer-Linux-rh9-stable-pub-v4.0.5 Setting up environment for FreeSurfer/FS-FAST (and FSL) FREESURFER_HOME /share/apps/freesurfer4.0.5 FSFAST_HOME /share/apps/freesurfer4.0.5/fsfast FSF_OUTPUT_FORMAT nii SUBJECTS_DIR /home/pnlstaff/freesurfer/subjects MNI_DIR /share/apps/freesurfer4.0.5/mni CORRECTING DEFECT 67 (vertices=117, convex hull=78) After retessellation of defect 67, euler #=27 (83599,243374,159802) : difference with theory (-19) = -46 CORRECTING DEFECT 68 (vertices=19, convex hull=68) After retessellation of defect 68, euler #=28 (83608,243425,159845) : difference with theory (-18) = -46 CORRECTING DEFECT 69 (vertices=38132, convex hull=10573) Thanks! Tali -- Talis M. Swisher, BA Senior Research Assistant Psychiatry Neuroimaging Laboratory Harvard Medical School, Brigham and Women's Hospital 1249 Boylston St, 3rd Floor Boston, MA 02215 Office: (617) 525-6119 Cell: (336) 577-5071 Fax: (617) 525-6150 ___ Freesurfer mailing list 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.
Re: [Freesurfer] multiple correction
Hi, professor, I performed the statistical analysis between two groups first in left hemisphere, and got some regions which showed different. 1) so if I then do multiple correction, i don't need to run the mri_glmfit-sim command, and just press the button of the monte carlo null-z simulation in the qdec interface, am i right? 2) Whether mri_glmfit-sim --cache command line and the mc-z in qdec get the same results, or not? and as to the option --cwpvalthresh, should i choose 0.05 or 0.025? 3) And what is the difference between fdr and mc-z correction? Thanks, Meng Hi Meng, if you are doing whole hemisphere correction, it will used already computed values which should only take a few seconds to run. doug On 07/05/2012 11:03 AM, Meng Li wrote: Hi, all, I have some questions about the multiple correction in qdec. I performed group analysis using qdec. There are 5 factors in the qdec.table.dat file: 1 discrete, 4 continuous variables (covariates). When I tried to perform the multiple correction, Whether I can choose one of two ways (the fdr and monte carlo null-z simulation) only. And if I use monte carlo null-z simulation, I have to pre-run mri_glmfit-sim 1? Thanks, Meng inline: 截图1.png___ Freesurfer mailing list 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.
[Freesurfer] multiple correction
Hi, freesurfer expert, I performed the statistical analysis between two groups first in left hemisphere, and got some regions which showed different. 1) so if I then do multiple correction, i don't need to run the mri_glmfit-sim command, and just press the button of the monte carlo null-z simulation in the qdec interface, am i right? 2) Whether mri_glmfit-sim --cache command line and the mc-z in qdec get the same results, or not? and as to the option --cwpvalthresh, should i choose 0.05 or 0.025? 3) And what is the difference between fdr and mc-z correction? Thanks, Meng ___ Freesurfer mailing list 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.
Re: [Freesurfer] Hanging during Fix Topology
Hi Tali that's a giant defect. Almost 1/4 of the total normal surface area. Something must be seriously wrong. Check out the filled.mgz and see if the skull or cerebellum is attached to the wm. cheers Bruce On Fri, 6 Jul 2012, Tali Swisher wrote: Hi all, I'm running FreeSurfer v.4.0.5 (see below) and it keeps hanging during the Fix Topology sequence while correcting defects. The last few lines before it's hanging are included below - any suggestions? freesurfer-Linux-rh9-stable-pub-v4.0.5 Setting up environment for FreeSurfer/FS-FAST (and FSL) FREESURFER_HOME /share/apps/freesurfer4.0.5 FSFAST_HOME /share/apps/freesurfer4.0.5/fsfast FSF_OUTPUT_FORMAT nii SUBJECTS_DIR /home/pnlstaff/freesurfer/subjects MNI_DIR /share/apps/freesurfer4.0.5/mni CORRECTING DEFECT 67 (vertices=117, convex hull=78) After retessellation of defect 67, euler #=27 (83599,243374,159802) : difference with theory (-19) = -46 CORRECTING DEFECT 68 (vertices=19, convex hull=68) After retessellation of defect 68, euler #=28 (83608,243425,159845) : difference with theory (-18) = -46 CORRECTING DEFECT 69 (vertices=38132, convex hull=10573) Thanks! Tali -- Talis M. Swisher, BA Senior Research Assistant Psychiatry Neuroimaging Laboratory Harvard Medical School, Brigham and Women's Hospital 1249 Boylston St, 3rd Floor Boston, MA 02215 Office: (617) 525-6119 Cell: (336) 577-5071 Fax: (617) 525-6150 ___ Freesurfer mailing list 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.
