You are right. I found out the same using the wiki http://surfer.nmr.mgh.harvard.edu/fswiki/LabelsClutsAnnotationFiles. However, I discovered that read_annotation.m reads some labels as zeros and 'misses' labels 1639705 and 3294840 defined in the enclosed LUT while reading for example lh.aparc.annot resulting from a standard execution of the pipeline (recon-all -all).
Do you have any thoughts on this? Is this a bug (either in the stored .annot or during the reading process)?
Thanks for sharing your thoughts,
Best, Martijn
On Thu, Dec 22, 2011 at 1:20 PM, Thomas Yeo ythomas@csail.mit.edu wrote:
Hi, I am not sure if your question is about read_annotation or aparc.annot in particular.
read_annotation.m reads the labels embedded in the annotation file you passed to it. The labels embedded in the annotation file may or may not be the same as those in FreeSurferColorLUT.
I could be wrong, but in the case of aparc.annot generated by recon-all, I don't think the labels correspond to those in FreeSurferColorLUT.
--Thomas
On Thu, Dec 22, 2011 at 6:23 PM, Martijn Steenwijk martijnsteenwijk@gmail.com wrote:
Dear all,
I'm trying to read aparc.annot into Matlab using the matlab/read_annotation.m function. Is it correct that the labels read by this function do not correspond with for example the FreeSurferColorLUT?
Are the labels stored as 16 bit (unsigned)integers, or in another way?
Best, Martijn
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.