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.

[seankmartin]

Hey @jbms, thanks again for the suggestions and review on this PR so far

We updated a few things based on this:

1. There is no longer a setting to turn on/off the colour legend, instead the top bar shows it as a background color to save space. The layer list panel continues to show the circle for the colour.
2. Segmentation layers can show up to 6 selected colors. It's a single var that configures this if we want to bump that limit up or down. Past this value though it does show the generic kind of rainbow instead though.
3. Archived layers completely hide the color indicator. Though the / over it is kept for consistency. Could remove that too if desired

Just a note that in that the annotation color is coming from the default color tool spawned by the shader code

Very open to thoughts, and thank you again

One thing (edit) -- aware of a bug that prevents the top bar updating, working a fix for that

[jbms]

Thanks.

Overall this looks really nice.

A few comments:

• In the layer list panel the rainbow (non specific) color indicator looks good but in the layer bar it is kind of distracting --- maybe it would be better to just not show the rainbow in the top bar. Not sure...
• For segmentation layers, if there is a fixed color specified in the "Render" tab and no per-segment colors in the map, then it should be displayed as a single color.
• In the layer list panel, perhaps the color indicator could also be the visibility toggle so that we save some horizontal space. Some sort of hover indication plus tooltip could make it clearer to users. Not sure if this is worth the loss of discoverability.

[seankmartin]

Thank you Jeremy,

Sorry on the second point - missed that the fixed color wasn't behaving quite right, and forgot to account for the combination of manually mapped seg IDs to colours. Changed the logic to account for more combinations in the segmentation, hopefully that accounts for the situations now but happy to iterate further

As for point 1 and 3, really appreciate the suggestions! For point 1 honestly I'm not 100% sure but I think it's reasonable to not show the colour in the top bar for rainbow -- I think we make this change and we can roll back if needed.
On the last point I like the idea to save space, but my initial inclination would be that the eye icon should still be somewhere, e.g. in the section that shows on hover. Potentially, clicking on the color widget could still function like the visibility icon though.