Gaps in surface coloring in brainstorm

Discussions
,
1

Hi Francois,

Ken was having some weird coloring issue of ROI in BrainStorm. It seems that there are gray gaps between the rois (scouts in BrainStorm terminology). Please see the screenshot below:

image
image747×443 109 KB

I went through the BrainStorm code and it seems that each scout is made into a separate patch. Then each of these patches is colored and plotted separately.
So triangles with vertices with different labels do not get assigned to any patch and so are not plotted or colored, and stay gray.

This issue is due to the following code in BrainStorm (panel_scout.m, line 4262 onwards)
Original

% This syntax is faster but equivalent to:
% patchFaces = Faces(all(vertMask(Faces),2),:);
iFacesTmp = find(vertMask(Faces(:,1)));
iFacesTmp = iFacesTmp(vertMask(Faces(iFacesTmp,2)));
iFacesTmp = iFacesTmp(vertMask(Faces(iFacesTmp,3)));
patchFaces = Faces(iFacesTmp,:);

To try to fix it, I propose to make the following change:

patchFaces = Faces(sum(vertMask(Faces),2)>=2,:);
iScoutVert = unique(patchFaces(:));
patchVertices = GetScoutPosition(Vertices, VertexNormals, iScoutVert, 0.0002);

This way, a triangle is assigned a label if two or more of its vertices have that label. This mostly fixes the issue, except when each of the three vertices of triangle have different labels. In that case it is not assigned any label and stays gray. We could assign it a random label. Here is a screenshot.

image

With the new change, vertices on the boundary of scouts would be in both scouts.
Do you think this change would be acceptable in BrainStorm? I wanted to check with you before sending a pull request because this change seems like it might break some assumptions needed for some codes.

Is there a reason why each scout is separated into a patch? Could we make scout into sets of vertices rather than separate patches? That change might be too fundamental.

What are your thoughts on this? How should we go about the coloring issue?

Thank you,

best,
Anand

2

Hi Anand,

Indeed, this "issue" has been reported multiple times, for example:
Is it possible to change/eliminate the border between atlas scouts during a cortical parcellation?
Issues with scouts - #6 by Francois

The "scouts" in Brainstorm are not initially aimed to represent cortical parcellations or anatomical atlases.
As designed by Sylvain in the early 2000s: a scout is a list of vertices, manually picked on the cortex surface, possibly overlapping with other scouts, that are used for ROI analyses of the sources estimated on the cortex surface. The signals of the dipoles corresponding to the vertices in one scout can be averaged together to obtain only one signal.

Little by little, I extended these "scouts" to represent anatomical atlases imported from FreeSurfer/BrainVISA/BrainSuite.
The cortical parcellations (ie. textures of the surface mesh, one vertex = one label) are converted to a list of Brainstorm scouts (independent objects, possibly overlapping), but they are in essence different types of objects.
The same apply to volume scouts: https://neuroimage.usc.edu/brainstorm/Tutorials/TutVolSource#Volume_scouts

The main goal of the scouts display, considering the definition above, is to be able to identify which vertex belongs to which scout. The faces of the mesh have no existence in the scouts representation (which are only lists of vertex indices), and no use in our ROI analyses of the sources. The faces are colored only for cosmetic purposes.
I agree that it would be nicer to have 1) the cortical atlases displayed without these gaps, but the priority is to be able to 2) identify which vertices belong to a given scout and to draw scouts manually on the surface by clicking on the vertices to add. You suggested modification addresses 1) but not 2), it makes it difficult to understand where are the separations between scouts.

Left: current display / Right: your suggested modification
image image

The solution would be to extend the boundaries of the scouts not to all the neighboring vertices, but to the centers of the faces connected to the boundary of the scout. This requires a lot of recording, with two aspects: handling the vertices of the scout patches independently from the vertices of the surfaces (they would be a mix of surface vertices and centers of faces), and computation optimizations (drawing the scouts in the current way is ok but slow, adding more computations on the fly could make it too slow).

It's been on my todo list for years, but since this is already fully working, I keep on having more urgent things to fix.
But this can be an interesting project :slight_smile:

Cheers
Francois

1 Like