Color legend in the layer-bar

[aranega]

Summary

This PR introduces a new color widget in the layer bar, which reflects the color status of a layer set by the user. It indicates three states for layer colors:

Unsupported: For layers that do not have a color.
Rainbow: For layers like segmentation with multiple colors, or when a color cannot be determined while the layer supports color (e.g: annotation with non-default color).
Single Color: For layers with only one color, or when a segmentation has only one visible segment.
This feature allows users to see the current color state directly in the layer bar.

The activation of this new widget is controlled by a new entry in the global settings menu. The following screenshot shows the new menu entry, as well as the state of the layer bar and the layer panel when the option is activated.

We can observe in this screenshot the 3 states:

• unsupported for FABFB.surf.vt.gz
• single color for synapses
• multiple colors for segmentation

Currently annotation and segmentation layers are supported for automatic color detection, while image and mesh layers are not.

Motivation

Users often need to quickly identify the color status of layers, especially with segmentation layers that might have multiple colors. This widget provides an immediate visual indicator of the layer’s color configuration.

User Interaction

The color widget in the layer bar displays the current color state for each layer. Users can easily see if a layer uses multiple colors or a single color. The widget offers quick insight into the layer’s visual setup. The display of the color widgets is turned on and off via a "Enable layer color legend" setting in the settings panel, which is off by default.

Implementation

This update modifies the layer bar, and the layer panel to add the possibility to display the color widget. The two components register themselves on the layer they are targetting to get notified when a new color is computed.

Layers are modified to consider a new attribute that is stating if it can or not give a color (if it supports the feature). Two new methods defined on layers, and reified by layer type if necessary, are used to:

1. register a callback to all the necessary signals that would imply a refresh of the color widget
2. provide the actual color, depending on multiple factors in the layer's state.

Extension

Currently only few layers are supported:

1. segmentation layer
2. annotation layer

To support another layer type, e.g: img layer, the class variable supportsLayerBarColorSyncOption needs to be set to true, then the observeLayerColor function can be overriden in the reifed class of the layer to register all the signals or elements that needs to be watched. The automaticLayerBarColor method can be then implemented in the layer to find the color depending on the various information that is available in the layer.

In the case of the img layer, it would be possible to look for emitGrayscale or emitRGBA to extract the color and display it, but we intentionally didn't implement it as it requires a complex implementation if we want to have a perfect idea of what's the color used reading the code. Indeed, parsing properly the content of emitRGBA(...) calls requires to possibly track variables in case the color is encoded somewhere in a variable and used later in the emitRGBA(...) call. The same symbol resolution/variable tracking applies if we need to determine the shade of a color defined as vec4(x, 0.0, 0.0, 1.0) where x would be defined in another place in the code.

In addition to parsing the shader code, as a future possibility, the default image layer shader could be modified to add a defaultColor which would create a color widget in the image layer. This could then be used to inform the color in the automaticLayerBarColor if defaultColor is used in the shader. This would then function similarly to the setup for annotation layers in this PR.

[jbms]

This is a nice idea!

A few comments:

• Instead of taking up additional horizontal space in the layer bar, we could potentially just color the background color of the layer name, and just somehow ensure that the layer name remains visible --- e.g. switch between white and black text, as is done in the segment list, or add some sort of outline to the text. Currently, the background color for segmentation layers indicates if the layer supports "picking" --- but I think we could stop doing that because turning off picking for segmentation layers is kind of a niche feature. Then there would also be no reason to turn the feature off, so we could eliminate the config option.
• If there are a small number of segments visible in a segmentation layer, e.g. up to 3, it might be nice to show the colors, rather than limiting it to only 1.
• In the seung lab fork of neuroglancer, there was a related feature of showing a color for each layer in the layer bar, but in that case the color was taken from the annotation color of the layer. For non-annotation layers, this color applied to the bounding box for the data. I don't know whether it was common to change those colors in order to differentiate between layers, though. I think the mechanism of choosing colors used here, assuming we can also make it work in most cases for image layers, is better than relying on the default annotation colors, though.

[jbms]

This logic isn't quite correct --- segmentDefaultColor is overridden by segmentStatedColors. This should call getBaseObjectColor.

[seankmartin]

Hey @jbms, thank you for the thoughts on this one!

• Instead of taking up additional horizontal space in the layer bar, we could potentially just color the background color of the layer name, and just somehow ensure that the layer name remains visible --- e.g. switch between white and black text, as is done in the segment list, or add some sort of outline to the text. Currently, the background color for segmentation layers indicates if the layer supports "picking" --- but I think we could stop doing that because turning off picking for segmentation layers is kind of a niche feature. Then there would also be no reason to turn the feature off, so we could eliminate the config option.

We've been thinking about how to tackle primarily this bit. Removing the config sounds good, and that's good to know on the picking indication color as that was a concern we had when considering perhaps having a background color for this legend. Will update on this soon

• If there are a small number of segments visible in a segmentation layer, e.g. up to 3, it might be nice to show the colors, rather than limiting it to only 1.

This is a nice idea, we're having a look at it, hopefully we can land on something and will let you know

• In the seung lab fork of neuroglancer, there was a related feature of showing a color for each layer in the layer bar, but in that case the color was taken from the annotation color of the layer. For non-annotation layers, this color applied to the bounding box for the data. I don't know whether it was common to change those colors in order to differentiate between layers, though. I think the mechanism of choosing colors used here, assuming we can also make it work in most cases for image layers, is better than relying on the default annotation colors, though.

For non-annotation layers I think the default yellow color of the bounding box / default annotations is usually kept so I imagine it would go out of sync pretty easily with the actual color of the layer.

If we can use a defaultColor style indicator in image layers it would then feed into this legend color - and if we're thinking of how to support the color legend on image layer shaders without a defaultColor we could potentially use some heuristics on the shader.

I'd be inclined not to over complicate this PR for the color legend with also supporting image layer colors right now. But if it becomes a blocker to this PR then that is understandable and we will see what we can do, and of course open to suggestions

Thanks again

[jbms]

Thanks for your explanations. Leaving image layer support for a later time seems reasonable.