Drawing neighboring surface ROIs, getting overlapping areas

[Johanne]

Hi all,

We are working on defining neighboring surface ROIs in wb_view, but we’ve encountered a problem. Specifically, we’re either getting overlapping vertices between the neighboring ROIs or gaps forming between them. In other words, we end up either double-counting certain surface areas or missing some vertices entirely.

We first draw one border and create an ROI. After that, we repeat the process for the remaining ROIs. That means there are two borders between each of the neighboring ROIs.

The picture illustrates our dream scenario, and our current solution, respectively.

Are any of you familiar with a way of closing a new border with an existing border? Or, does anyone know if there is another way of drawing ROIs next to each other without encountering this problem?

Kind regards,
Johanne

[Glasser, Matthew]

I would zero out overlapping vertices and then use surface dilation to fill in the gaps programmatically.  This is what we did for the HCP’s multi-modal cortical parcellation.

 

Matt.

 

From: Johanne <iversen...@gmail.com>
Reply-To: "hcp-...@humanconnectome.org" <hcp-...@humanconnectome.org>
Date: Friday, September 26, 2025 at 8:46 AM
To: HCP-Users <hcp-...@humanconnectome.org>
Subject: [hcp-users] Drawing neighboring surface ROIs, getting overlapping areas

 

Hi all,

We are working on defining neighboring surface ROIs in wb_view, but we’ve encountered a problem. Specifically, we’re either getting overlapping vertices between the neighboring ROIs or gaps forming between them. In other words, we end up either double-counting certain surface areas or missing some vertices entirely.

We first draw one border and create an ROI. After that, we repeat the process for the remaining ROIs. That means there are two borders between each of the neighboring ROIs.

The picture illustrates our dream scenario, and our current solution, respectively.

Are any of you familiar with a way of closing a new border with an existing border? Or, does anyone know if there is another way of drawing ROIs next to each other without encountering this problem?

Kind regards,
Johanne

--
You received this message because you are subscribed to the Google Groups "HCP-Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hcp-users+...@humanconnectome.org.
To view this discussion visit https://groups.google.com/a/humanconnectome.org/d/msgid/hcp-users/fde27df8-a444-4f8e-9f49-d7e5d0385d97n%40humanconnectome.org.

 

---

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.

[Johanne]

Hi!

Thank you for getting back to us so quickly. We made a script to zero out the overlapping vertices, and tried using wb_command -label-dilate. 

However, when we looked into the specific overlapping vertices, something seemed off. We therefore ran a test, and found that the overlapping vertices in our tabular output do not match up with the graphics in wb_view. The tabular output itself is also surprising. It says that we have 0 vertices in our labels, whereas graphically we expected 6 vertices. 

Please see the illustration:

Note: 

ROI A: 17 vertices in border, 0 in label

ROI B: 12 vertices in border, 0 in label

Here is a brief explanation of what we have done:

• HCP preprocessing pipeline

• fMRI analysis in matlab

• Drawn on fsaverage 32k sphere in wb_view

  • Edit borders - Draw - Finish - Save as border file

  • Create ROI - save as dlabel

  • Save/manage files - save selected

• Use wb_command -border-to-vertices and -surface-vertex-areas to convert vertices to area. 

• Script in MATLAB to identify number of vertices, overlapping vertices, and surface area (using midthickness.32k_fs_LR.surf.gii)

We have doublechecked our findings, that we have used the same surfaces, and looked into the scripts, but we cannot see any obvious mistakes (at least not obvious to us).

Has anyone experienced something similar? Or can you think of an explanation as to why our graphics and numbers diverge?

Kind regards,

Johanne

[Tim Coalson]

-border-to-vertices will only give you the outline of an area. -border-to-rois is probably what you wanted.  Note, they output separate maps per border name, each of which are 0/1, it doesn't use the label key values.

Check your intermediate files and variables to see if they contain what you expect.

Tim

On Mon, Oct 6, 2025 at 3:29 AM Johanne <iversen...@gmail.com> wrote:

Hi!

Thank you for getting back to us so quickly. We made a script to zero out the overlapping vertices, and tried using wb_command -label-dilate. 

However, when we looked into the specific overlapping vertices, something seemed off. We therefore ran some tests, and found that the overlapping vertices in our tabular output does not match up with the graphics in wb_view. The tabular output itself is also surprising. It says that we have 0 vertices in our labels, whereas graphically we expected 6 vertices. 

Please see the illustration:

Note: 

ROI A: 17 vertices in border, 0 in label

ROI B: 12 vertices in border, 0 in labe

Here is a brief explanation of what we have done:

• HCP preprocessing pipeline

• fMRI analysis in matlab

• Drawn on fsaverage 32k sphere in wb_view

  • Edit borders - Draw - Finish - Save as border file

  • Create ROI - save as dlabel

  • Save/manage files - save selected

• Use wb_command -border-to-vertices and -surface-vertex-areas to convert vertices to area. 

• Script in MATLAB to identify number of vertices, overlapping vertices, and surface area (using midthickness.32k_fs_LR.surf.gii)

We have doublechecked our findings, that we have used the same surfaces, and looked into the scripts, but we cannot see any obvious mistakes (at least not obvious to us).

Has anyone experienced something similar? Or can you think of an explanation as to why our graphics and numbers diverge?

Kind regards,

Johanne

fredag 26. september 2025 kl. 18:23:49 UTC+2 skrev glas...@wustl.edu:

To view this discussion visit https://groups.google.com/a/humanconnectome.org/d/msgid/hcp-users/eb13e7dd-a43a-486a-b0eb-f41ead897a19n%40humanconnectome.org.

[Johanne]

Thank you so much for your replies so far.

We’re still unsure about some things. Just to give you some more context; what we are doing is drawing retinotopic maps based on the same experimental design and task as “The Human Connectome Project 7 Tesla retinotopy dataset”, using the same population receptive field analysis. Our goal is to draw V1, V2 and V3 on individual subjects and calculate the surface areas of each drawn ROI.

The input fMRI data in the pRF model is in 32k resolution, and when drawing in Workbench with this resolution the labels become quite “patchy” with large gaps in between (see pictures below). When calculating the areas (using -surface vertex areas) based on -border to rois there is no overlap between the ROIs, while when including the -incl border flag (or add the outline with -border to vertices) it becomes a lot of overlap. Is it correct that the “gaps” created between the ROIs (without the borders) are due to the uncertainty in these areas due to the “low” resolution? 

If so, what we need to figure out is how to deal with these uncertainty-gaps when we are calculating our areas. You suggest that we “zero out overlapping vertices and then use surface dilation to fill in the gaps programmatically”, what specifically do you mean with this? Is this a command? What would be the underlaying logic of which ROI specific vertices belong to?

We were also thinking of resampling to 164k resolution, as the labels then will be filled in, but then we don’t really have any control over how they are filled. What do you think?

Thank you again for your help!

[Tim Coalson]

Yes, the blockiness of the ROIs/labels is due to 32k resolution.  You can also resample the borders to 164k before turning them into ROIs.

The fundamental problem is that the tools for measuring surface area need to know how much of each vertex belongs to each area.  The transfer from borders to binary ROIs is inexact (and can't split a vertex the border gets close to between inside and outside), which may be a problem when you are looking for small areas or small differences.  But, if the borders are hand-drawn anyway, there is likely already some methodological variability in play.

Tim

[Johanne]

Thank you, that was very clarifying.

While resampling from 32k to 164k, I've become confused about how HCP handles spheres and registrations across resolutions. For example, I see these sphere files:
- T1w/Native/subject.L.sphere.MSMAll.native.surf.gii (native resolution)
- MNINonLinear/fsaverage_LR32k/subject.L.sphere.32k_fs_LR.surf.gii
- MNINonLinear/fsaverage_LR32k/subject.L.sphere.MSMSulc.32k_fs_LR.surf.gii
- MNINonLinear/subject.L.sphere.164k_fs_LR.surf.gii

Questions:
- Why is there no subject.L.sphere.MSMAll.32k_fs_LR.surf.gii or subject.L.sphere.MSMAll.164k_fs_LR.surf.gii?  Why are there no sphere files that combine MSMAll with 32k_fs_LR or 164k_fs_LR?
- Why is there no MSMSulc.164k_fs_LR sphere, given that there is an MSMSulc.32k_fs_LR sphere?
- Is subject.L.sphere.MSMAll.native.surf.gii in fs_LR space but at native resolution?
- How is subject.L.sphere.32k_fs_LR.surf.gii aligned? I’ve seen that MSMSulc should be the “default” alignment, but then why is there also a subject.L.sphere.MSMSulc.32k_fs_LR.surf.gii alongside subject.L.sphere.32k_fs_LR.surf.gii? What’s the difference?

Johanne

[Tim Coalson]

We only put registration distortions into the subject's native mesh (freesurfer) spheres.  The standard spheres don't get deformed during registration.  All of the standard spheres are defined to already be in register with each other, you can use them as-is.  You would only need the MSMAll registered sphere if you needed to go back to native mesh.

The sphere.MSMSulc.32k_fs_LR files are something weird that probably shouldn't have been put into the main fsaverage_LR32k folder, please ignore it.  Not sure exactly what it is, seems to be made by MSMAll:

https://github.com/Washington-University/HCPpipelines/blob/a3ee1a1213b0a172486624e561691ebffcd9496c/MSMAll/scripts/MSMAll.sh#L226

The simpler-named 32k and 164k spheres are actually just copies of the standard spheres (in the pipelines at global/template/standard_mesh_atlases).

Spheres aren't really in a volume space.  We put the registered native spheres in T1w/Native because other native-mesh data was there already.  The registered native spheres have a spherical deformation already applied to them that aligns the subject's data to the spherical template data.

To get MSMSulc-aligned data, we resample from the native MSMSulc sphere to the standard sphere (32k, 164k, 59k, whatever).  For MSMAll-aligned data, we resample from the native MSMAll sphere to the standard sphere.  Past that point, you resample directly from one standard sphere to the other, there are no more registration-specific spheres.  The registration is how you got to the standard mesh, and is important to keep straight on the data to not mix registrations, but once it is on a standard mesh with a given registration, the registration is "baked in" to the data and doesn't need to be specified again when going between standard meshes.

Tim