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]> 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]> 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]> 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]> >>> 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]> 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]> >>>>> 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]> >>>>>> 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] >>>>>>> http://lists.humanconnectome.org/mailman/listinfo/hcp-users >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > _______________________________________________ HCP-Users mailing list [email protected] http://lists.humanconnectome.org/mailman/listinfo/hcp-users
