I would agree that this suggests a FreeSurfer issue. Usually it tries to avoid crossing the midline, but for some reason has still done this in this particular case.
Peace, Matt. From: <[email protected]<mailto:[email protected]>> on behalf of Timothy Coalson <[email protected]<mailto:[email protected]>> Date: Monday, November 7, 2016 at 5:49 PM To: Simon Baker <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [HCP-Users] Custom parcellation for HCP data I think someone else will have to answer about whether that is within expected error. The surfaces themselves cross over each other in those captures, so I think freesurfer just couldn't decide where the cortex ended. Any idea how often this happens (how many subjects, how much overlap)? Tim On Mon, Nov 7, 2016 at 4:25 PM, Simon Baker <[email protected]<mailto:[email protected]>> wrote: Hi Tim, Have you had a chance to look into this issue? Thanks, Simon On 18 October 2016 at 15:15, Simon Baker <[email protected]<mailto:[email protected]>> wrote: Hi Tim, Using FreeView, I loaded HCP subject 101410's MNINonLinear/T1w_restore_brain, MNINonLinear/aparc+aseg, and MNINonLinear/aparc.a2009s+aseg volumes, as well as our custom parcellation of the right hemisphere (custom_R) and left hemisphere (custom_L). Then I loaded the following surfaces: MNINonLinear/101410.R.pial.164k_fs_LR.surf.gii; MNINonLinear/101410.L.pial.164k_fs_LR.surf.gii. After that, I located a voxel near to where the right and left pial surfaces overlap: [130, 222, 92] (this is the location of the cursor in the attached SCREENSHOTS.pdf). The first row of data in the below table shows the value of this voxel in each parcellation. coordinates aparc+aseg aparc.a2009s+aseg custom_R custom_L [130, 222, 92] 2026 12106 2069 1094 [131, 222, 92] 2026 12106 0 1094 [132, 222, 92] 2026 12106 0 1094 [133, 222, 92] 2026 12106 0 1094 [134, 222, 92] 1026 11106 0 1094 As you can see, this voxel is labelled as 2026 in aparc+aseg and 12106 in aparc.a2009s+aseg. You can also see that this voxel is labelled 2069 in custom_R and 1094 in custom_L, indicating that it has been included in our custom parcellation of the right hemisphere as well as our custom parcellation of the left hemisphere. This is an example of overlap issue we are concerned about. When we move to a neighbouring voxel (i.e., [131, 222, 92]), which is one voxel to the left of the starting voxel and within an area enclosed by the left pial surface (not the right pial surface), the value remains unchanged in all parcellations except custom_R, wherein the voxel is labelled as 0. This pattern is repeated as we move to a 2nd voxel (i.e., [132, 222, 92]) and a 3rd voxel (i.e., [133, 222, 92]) to the left of the starting voxel. It is not until we move to a 4th voxel (i.e., [134, 222, 92]) to the left of the starting voxel that the voxel is universally labelled as part of a structure in the left hemisphere: 1026 in aparc+aseg, 11106 in aparc.a2009s+aseg, 0 in custom_R, and 1094 in custom_L. Why are voxels that are clearly outside the pial surface of the right hemisphere labelled as part of a structure in the right hemisphere? Is there a problem with the aparc+aseg and aparc.a2009s+aseg parcellations in this regard? Or does the apparent mislabelling fall within an acceptable margin for error? And if so, is it possible that the accuracy of our custom parcellation is acceptable, despite the fact there is some overlap between the right hemisphere and left hemisphere? Simon Baker Brain & Mental Health Laboratory Monash Institute of Cognitive & Clinical Neurosciences Monash University On 5 October 2016 at 07:56, Timothy Coalson <[email protected]<mailto:[email protected]>> wrote: You might want to compare them to the T1 in an example subject (and perhaps also volume surface outline for pial), to see what is really going on. The pial surfaces of the two hemispheres shouldn't overlap outside the medial wall. Are you mapping to the structural volume resolution, or to the fMRI resolution? Larger voxels makes this problem harder to resolve. The label to volume mapping is also a bit greedy, as partial-volumed voxels are labeled unconditionally (the "unlabeled" value can win out, if the data from the label file suggests more volume in a voxel for "unlabeled", but the partial volume that lies outside the surfaces is ignored, even if it dominates). As such, if it is only a few voxels, and only the very edges, it may not really matter how you resolve the overlap. Tim On Tue, Oct 4, 2016 at 12:44 AM, Simon Baker <[email protected]<mailto:[email protected]>> wrote: Hi Tim, Thanks for your email. To clarify, when I said voxels on the medial wall, I was referring to voxels near the sagittal midline of the brain (i.e., I wasn't referring to voxels that have been labelled as medial wall). As such, these voxels have been labelled as part of a structure in the left hemisphere and also labelled as part of a structure in the right hemisphere. In which case, how do you suggest we deal with the overlap issue? Thanks again, Simon On 4 October 2016 at 13:02, Timothy Coalson <[email protected]<mailto:[email protected]>> wrote: Note that this command just makes the left hemisphere take precedence - you said the overlap was in medial wall, which is more of an artifact of processing than a structure of importance, so this should be fine. The surfaces shouldn't have any overlap on real structures, so ribbon constrained surface to volume mapping should prevent any other serious overlaps. Tim On Mon, Oct 3, 2016 at 8:56 PM, Timothy Coalson <[email protected]<mailto:[email protected]>> wrote: Assuming that your label values don't have any overlap (each integer uniquely identifies not only the area but also the hemisphere), you can do the math part with wb_command -volume-math: wb_command -volume-math 'L + (L == 0) * R' ${Subject}.custom_raw.nii.gz -var L ${Subject}.L.custom.nii -var R ${Subject}.R.custom.nii You can then make the combined label names text file and use it to reimport the label file: wb_command -volume-label-export-table ${Subject}.L.custom.nii 1 ${Subject}.L.custom.txt wb_command -volume-label-export-table ${Subject}.R.custom.nii 1 ${Subject}.R.custom.txt cat ${Subject}.L.custom.txt ${Subject}.R.custom.txt > ${Subject}.custom.txt wb_command -volume-label-import ${Subject}.custom_raw.nii.gz ${Subject}.custom.txt ${Subject}.custom.nii.gz I also suggest using .nii.gz, label files compress very well. Unlike FSL, workbench doesn't have an environment variable controlling the output format, you must specify full filenames. Tim On Mon, Oct 3, 2016 at 8:29 PM, Simon Baker <[email protected]<mailto:[email protected]>> wrote: Hi all, We want to use our own custom parcellation with the connectome project data. Ultimately the parcellation needs to be a NIFTI volume. We mapped our own custom parcellation from fsaverage (.annot file in FreeSurfer space) onto an HCP subject (GIFTI surface .label.gii file in ${Subject}/MNINonLinear space) separately for each hemisphere, and we would like to convert the GIFTI surface files into a NIFTI volume file. Although this can be done with the following commands . . . [MNINonLinear]$ wb_command -label-to-volume-mapping ${Subject}.L.custom.164k_fs_LR.label.gii ${Subject}.L.sphere.164k_fs_LR.surf.gii T1w.nii.gz ${Subject}.L.custom.nii -ribbon-constrained ${Subject}.L.white.164k_fs_LR.surf.gii ${Subject}.L.pial.164k_fs_LR.surf.gii [MNINonLinear]$ wb_command -label-to-volume-mapping ${Subject}.R.custom.164k_fs_LR.label.gii ${Subject}.R.sphere.164k_fs_LR.surf.gii T1w.nii.gz ${Subject}.R.custom.nii -ribbon-constrained ${Subject}.R.white.164k_fs_LR.surf.gii ${Subject}.R.pial.164k_fs_LR.surf.gii [MNINonLinear]$ fslmaths ${Subject}.L.custom.nii -add ${Subject}.R.custom.nii ${Subject}.custom.nii . . . we have found that some voxels on the medial wall are labelled as both a left hemisphere region and a right hemisphere region. Using wb_command, how can we generate a NIFTI volume file containing both the left hemisphere parcellation and the right hemisphere parcellation and ensure that each voxel is labelled as only one region? Kind regards, Simon Baker Brain & Mental Health Laboratory Monash Institute of Cognitive & Clinical Neurosciences Monash University _______________________________________________ HCP-Users mailing list [email protected]<mailto:[email protected]> http://lists.humanconnectome.org/mailman/listinfo/hcp-users _______________________________________________ HCP-Users mailing list [email protected]<mailto:[email protected]> http://lists.humanconnectome.org/mailman/listinfo/hcp-users ________________________________ The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. _______________________________________________ HCP-Users mailing list [email protected] http://lists.humanconnectome.org/mailman/listinfo/hcp-users
