Annotation Coordinates - Revision history

Chris: /* But my coordinates are embedded in .annot files! */

2021-06-03T14:22:19Z

But my coordinates are embedded in .annot files!

← Older revision		Revision as of 10:22, 3 June 2021
Line 15:		Line 15:

	== But my coordinates are embedded in .annot files! ==		== But my coordinates are embedded in .annot files! ==
	This will require a preparatory step: We must first decompile the .annot files into a series of .label files. Suppose we have lh and rh .annot files for some functionally-defined labels (e.g., from a group-wise GLM contrast), and the contrast results are saved in cache.th13.neg.sig.ocn.annot for each hemisphere.		This will require a preparatory step: We must first decompile the .annot files into a series of .label files. Suppose we have lh and rh .annot files for some functionally-defined labels (e.g., from a group-wise GLM contrast), and the contrast results are saved in cache.th13.neg.sig.ocn.annot for each hemisphere (the exact names of the contrast annotation files will depend on the thresholding and tails applied to the group-level analysis).

	The first thing you will need to do is copy them to the same temporary working directory, renaming them in the process (otherwise they will overwrite each other because the files have the same names!). In this example, I am going to rename my .annot files to <span style="color:purple">''functional_mask''</span>		The first thing you will need to do is copy them to the same temporary working directory, renaming them in the process (otherwise they will overwrite each other because the files have the same names!). In this example, I am going to rename my .annot files to <span style="color:purple">''functional_mask''</span>

Chris: /* But my coordinates are embedded in .annot files! */

2021-06-03T14:20:42Z

But my coordinates are embedded in .annot files!

← Older revision		Revision as of 10:20, 3 June 2021
Line 17:		Line 17:
	This will require a preparatory step: We must first decompile the .annot files into a series of .label files. Suppose we have lh and rh .annot files for some functionally-defined labels (e.g., from a group-wise GLM contrast), and the contrast results are saved in cache.th13.neg.sig.ocn.annot for each hemisphere.		This will require a preparatory step: We must first decompile the .annot files into a series of .label files. Suppose we have lh and rh .annot files for some functionally-defined labels (e.g., from a group-wise GLM contrast), and the contrast results are saved in cache.th13.neg.sig.ocn.annot for each hemisphere.

	The first thing you will need to do is copy them to the same temporary working directory, renaming them in the process (otherwise they will overwrite each other because the files have the same names!)		The first thing you will need to do is copy them to the same temporary working directory, renaming them in the process (otherwise they will overwrite each other because the files have the same names!). In this example, I am going to rename my .annot files to <span style="color:purple">''functional_mask''</span>
	mkdir ${SUBJECTS_DIR}/blobs		mkdir ${SUBJECTS_DIR}/blobs
	cp ${SUBJECTS_DIR}/RFX/my_analysis.<span style="color:red">lh</span>/my_contrast/glm.wls/osgm/cache.th13.neg.sig.ocn.annot ${SUBJECTS_DIR}/blobs/<span style="color:red">lh</span>.<span style="color:purple">''functional_mask''</span>.annot		cp ${SUBJECTS_DIR}/RFX/my_analysis.<span style="color:red">lh</span>/my_contrast/glm.wls/osgm/cache.th13.neg.sig.ocn.annot ${SUBJECTS_DIR}/blobs/<span style="color:red">lh</span>.<span style="color:purple">''functional_mask''</span>.annot

Chris: /* But my coordinates are embedded in .annot files! */

2021-06-03T14:20:00Z

But my coordinates are embedded in .annot files!

← Older revision		Revision as of 10:20, 3 June 2021
Line 15:		Line 15:

	== But my coordinates are embedded in .annot files! ==		== But my coordinates are embedded in .annot files! ==
	This will require a preparatory step: We must first decompile the .annot files into a series of .label files. Suppose we have lh and rh .annot files for some functionally-defined labels (e.g., from a group-wise GLM contrast), and we saved ~~these labels~~ to ?h.~~p001_blobs~~.annot		This will require a preparatory step: We must first decompile the .annot files into a series of .label files. Suppose we have lh and rh .annot files for some functionally-defined labels (e.g., from a group-wise GLM contrast), and the contrast results are saved in cache.th13.neg.sig.ocn.annot for each hemisphere.
	ANNOTATION=~~p001_blobs~~
			The first thing you will need to do is copy them to the same temporary working directory, renaming them in the process (otherwise they will overwrite each other because the files have the same names!)
			mkdir ${SUBJECTS_DIR}/blobs
			cp ${SUBJECTS_DIR}/RFX/my_analysis.<span style="color:red">lh</span>/my_contrast/glm.wls/osgm/cache.th13.neg.sig.ocn.annot ${SUBJECTS_DIR}/blobs/<span style="color:red">lh</span>.<span style="color:purple">''functional_mask''</span>.annot
			cp ${SUBJECTS_DIR}/RFX/my_analysis.<span style="color:red">rh</span>/my_contrast/glm.wls/osgm/cache.th13.neg.sig.ocn.annot ${SUBJECTS_DIR}/blobs/<span style="color:red">rh</span>.<span style="color:purple">''functional_mask''</span>.annot

			Now, we go into our temporary working directory to convert the annotation files into a series of .label files:
			cd ${SUBJECTS_DIR}/blobs
			ANNOTATION=<span style="color:purple">''functional_mask''</span>
	for HEMI in ( lh rh ); do		for HEMI in ( lh rh ); do
	mri_annotation2label --subject fsaverage --hemi ${HEMI} --outdir ${HEMI} --annotation ${ANNOTATION}		mri_annotation2label --subject fsaverage --hemi ${HEMI} --outdir ${HEMI} --annotation ${ANNOTATION}

Chris: /* getSegCoords.m */

2018-11-06T17:16:50Z

getSegCoords.m

← Older revision		Revision as of 13:16, 6 November 2018
Line 28:		Line 28:
	Called this way, without any parameters, the script will assume that the paired ''lh'' and ''rh'' files and directories have names that differ only with respect to the '?h' characters (by default, the ''automatch'' option is set to true). You will be prompted to first identify the label directory (i.e., the directory that contains the ''?h.segment_id.label'' files) for the left hemisphere. The right hemisphere directory will be figured out automatically. The function then calls parseFSSegments.m for each hemisphere, which requires you to identify the '*.sum.txt' files that contain the individual segment names.		Called this way, without any parameters, the script will assume that the paired ''lh'' and ''rh'' files and directories have names that differ only with respect to the '?h' characters (by default, the ''automatch'' option is set to true). You will be prompted to first identify the label directory (i.e., the directory that contains the ''?h.segment_id.label'' files) for the left hemisphere. The right hemisphere directory will be figured out automatically. The function then calls parseFSSegments.m for each hemisphere, which requires you to identify the '*.sum.txt' files that contain the individual segment names.

	Source code for this MATLAB function can be found [[GetSegCoords.m here]].		Source code for this MATLAB function can be found [[GetSegCoords.m \| here]].

	== vertex_key.m ==		== vertex_key.m ==

Chris: /* getSegCoords.m */

2018-11-06T17:16:34Z

getSegCoords.m

← Older revision		Revision as of 13:16, 6 November 2018
Line 27:		Line 27:
	[xyz, hemi, segnames]=getSegCoords		[xyz, hemi, segnames]=getSegCoords
	Called this way, without any parameters, the script will assume that the paired ''lh'' and ''rh'' files and directories have names that differ only with respect to the '?h' characters (by default, the ''automatch'' option is set to true). You will be prompted to first identify the label directory (i.e., the directory that contains the ''?h.segment_id.label'' files) for the left hemisphere. The right hemisphere directory will be figured out automatically. The function then calls parseFSSegments.m for each hemisphere, which requires you to identify the '*.sum.txt' files that contain the individual segment names.		Called this way, without any parameters, the script will assume that the paired ''lh'' and ''rh'' files and directories have names that differ only with respect to the '?h' characters (by default, the ''automatch'' option is set to true). You will be prompted to first identify the label directory (i.e., the directory that contains the ''?h.segment_id.label'' files) for the left hemisphere. The right hemisphere directory will be figured out automatically. The function then calls parseFSSegments.m for each hemisphere, which requires you to identify the '*.sum.txt' files that contain the individual segment names.

			Source code for this MATLAB function can be found [[GetSegCoords.m here]].

	== vertex_key.m ==		== vertex_key.m ==

Chris: /* Finding Label Overlap */

2018-09-13T18:55:11Z

Finding Label Overlap

← Older revision		Revision as of 14:55, 13 September 2018
Line 119:		Line 119:
	Now you might want to use these labels to determine the indices (e.g., rows, columns) that you want to keep for some sort of analysis (e.g., reduce an adjacency matrix to include only those regions). The MATLAB <code>ismember</code> function will help here:		Now you might want to use these labels to determine the indices (e.g., rows, columns) that you want to keep for some sort of analysis (e.g., reduce an adjacency matrix to include only those regions). The MATLAB <code>ismember</code> function will help here:
	nodes_to_keep=find(ismember(lausanne_labels, keylabels));		nodes_to_keep=find(ismember(lausanne_labels, keylabels));
	This will return a vector of the node indices that you will want to retain:		This will return a vector of the node indices where the lausanne_label name matches the keylabel name. These are the node indices that you will want to retain:
	ReducedAdjacency=ADJ(nodes_to_keep, nodes_to_keep); %The 1000 x 1000 ADJ matrix is now a 255 x 255 matrix!		ReducedAdjacency=ADJ(nodes_to_keep, nodes_to_keep); %The 1000 x 1000 ADJ matrix is now a 255 x 255 matrix!

	[[Category: Manuscript Preparation]]		[[Category: Manuscript Preparation]]

Chris: /* Finding Label Overlap */

2018-09-13T18:54:09Z

Finding Label Overlap

@@ Line 111: / Line 111: @@
 # Optionally determine how many vertices are present in the annotation of interest (in this example, how many vertices are present in each of the lausanne labels)
 #*You can use these values to determine the proportion of overlap. In my experiment, I chose to keep only regions where 0.75 or more of the total number of vertices for a label were shared with the significant cluster labels.
 [[Category: Manuscript Preparation]]

Chris: /* Finding Label Overlap */

2018-09-13T18:31:28Z

Finding Label Overlap

← Older revision		Revision as of 14:31, 13 September 2018
Line 105:		Line 105:
	== Finding Label Overlap ==		== Finding Label Overlap ==
	Problem: I had a bunch of labels from the Lausanne parcellation, and I had a significance-thresholded volume from a group-level analysis. I wished to see which of the labels overlapped with the significant clusters. I decided to use a combination of MATLAB, FreeSurfer tools and a MySQL database:		Problem: I had a bunch of labels from the Lausanne parcellation, and I had a significance-thresholded volume from a group-level analysis. I wished to see which of the labels overlapped with the significant clusters. I decided to use a combination of MATLAB, FreeSurfer tools and a MySQL database:
	*# Extract the vertices using vertex_key.m from the ?h.lausanne.annot files		# Extract the vertices using vertex_key.m from the ?h.lausanne.annot files
	*# The mri_glmfitsim output produces .annot files that cover the regions in the thresholded volumes. Extract the vertices from those files in the same way.		# The mri_glmfitsim output produces .annot files that cover the regions in the thresholded volumes. Extract the vertices from those files in the same way.
	*# Import the .csv vertex information into two tables in MySQL (I'm obviously glossing over the steps of downloading and installing MySQL and MySQL Workbench on your computer, and having a basic understanding of SQL queries)		# Import the .csv vertex information into two tables in MySQL (I'm obviously glossing over the steps of downloading and installing MySQL and MySQL Workbench on your computer, and having a basic understanding of SQL queries)
	*# Use an INNER JOIN query to find all vertices in both tables, and I recommend using COUNT and GROUP BY to reduce the number of rows returned and get more useful results		# Use an INNER JOIN query to find all vertices in both tables, and I recommend using COUNT and GROUP BY to reduce the number of rows returned and get more useful results
	*# Optionally determine how many vertices are present in the annotation of interest (in this example, how many vertices are present in each of the lausanne labels)		# Optionally determine how many vertices are present in the annotation of interest (in this example, how many vertices are present in each of the lausanne labels)
	#You can use these values to determine the proportion of overlap. In my experiment, I chose to keep only regions where 0.75 or more of the total number of vertices for a label were shared with the significant cluster labels.		#*You can use these values to determine the proportion of overlap. In my experiment, I chose to keep only regions where 0.75 or more of the total number of vertices for a label were shared with the significant cluster labels.

	[[Category: Manuscript Preparation]]		[[Category: Manuscript Preparation]]

Chris at 18:30, 13 September 2018

2018-09-13T18:30:29Z

← Older revision		Revision as of 14:30, 13 September 2018
Line 102:		Line 102:
	fclose(outfile);		fclose(outfile);
	end		end

			== Finding Label Overlap ==
			Problem: I had a bunch of labels from the Lausanne parcellation, and I had a significance-thresholded volume from a group-level analysis. I wished to see which of the labels overlapped with the significant clusters. I decided to use a combination of MATLAB, FreeSurfer tools and a MySQL database:
			*# Extract the vertices using vertex_key.m from the ?h.lausanne.annot files
			*# The mri_glmfitsim output produces .annot files that cover the regions in the thresholded volumes. Extract the vertices from those files in the same way.
			*# Import the .csv vertex information into two tables in MySQL (I'm obviously glossing over the steps of downloading and installing MySQL and MySQL Workbench on your computer, and having a basic understanding of SQL queries)
			*# Use an INNER JOIN query to find all vertices in both tables, and I recommend using COUNT and GROUP BY to reduce the number of rows returned and get more useful results
			*# Optionally determine how many vertices are present in the annotation of interest (in this example, how many vertices are present in each of the lausanne labels)
			#You can use these values to determine the proportion of overlap. In my experiment, I chose to keep only regions where 0.75 or more of the total number of vertices for a label were shared with the significant cluster labels.

	[[Category: Manuscript Preparation]]		[[Category: Manuscript Preparation]]

Chris: /* vertex_key.m */

2018-09-12T20:11:37Z

vertex_key.m

← Older revision		Revision as of 16:11, 12 September 2018
Line 31:		Line 31:
	Another MATLAB function that you might find useful for working with vertices and labels from your decompiled .annot files, <code>vertex_key.m</code>, will parse all the .label files in a given directory, and concatenate all the vertex information into a single .csv file. This file may be useful for finding the overlap between two sets of labels, so long as both sets of labels represent the same surface space (e.g., fsaverage). There may be some other useful applications, but i intend to use this to determine which Lausanne labels are overlapping with significant clusters from a GLM analysis. The MATLAB file should be in the ubfs/Scripts/Matlab folder, but here's the code as yet another programming example:		Another MATLAB function that you might find useful for working with vertices and labels from your decompiled .annot files, <code>vertex_key.m</code>, will parse all the .label files in a given directory, and concatenate all the vertex information into a single .csv file. This file may be useful for finding the overlap between two sets of labels, so long as both sets of labels represent the same surface space (e.g., fsaverage). There may be some other useful applications, but i intend to use this to determine which Lausanne labels are overlapping with significant clusters from a GLM analysis. The MATLAB file should be in the ubfs/Scripts/Matlab folder, but here's the code as yet another programming example:

	function vertex_key(directory, outfilename)		'''function vertex_key(directory, outfilename)'''
	% function vertex_key(DIRECTORY, OUTFILENAME)		% function vertex_key(DIRECTORY, OUTFILENAME)
	% Optional parameters:		% Optional parameters: