Hi Tim,
Have you had a chance to look into this issue?
Thanks,
Simon
On 18 October 2016 at 15:15, Simon Baker <simonteba...@gmail.com> 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 <tsc...@mst.edu> 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 <simonteba...@gmail.com>
>> 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 <tsc...@mst.edu> 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 <tsc...@mst.edu> 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 <simonteba...@gmail.com>
>>>>> 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
>>>>>> HCP-Users@humanconnectome.org
>>>>>> http://lists.humanconnectome.org/mailman/listinfo/hcp-users
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
HCP-Users mailing list
HCP-Users@humanconnectome.org
http://lists.humanconnectome.org/mailman/listinfo/hcp-users
