Heatmap visualizations don't adjust color values for dark mode

[cchaos]

The color schemas that render the heat map visualizations don't take into account whether they're in light or dark mode. So their fill color is exactly the same in both modes. This leads to misleading representation of the data since the lesser value squares are now the brightest.

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[stratoula]

@cchaos I suggest fixing this when we replace the vislib heatmap with the es-charts implementation
cc @timroes @markov00

[elasticmachine]

Pinging @elastic/datavis (Feature:ElasticCharts)

[flash1293]

@cchaos In Lens we provide the EUI palettes as well (as categorical colors for now, but soon we will use them in the same way as heatmap). I guess they will have the same issue. We have a central palette service - should it be theme aware and change the underlying palette? If yes, in all cases or just in cases like heatmap if the color is tied to an "intensity" variable of some sort?

[dej611]

Need to consider this also for #95217 .

[cchaos]

The EUI palette service has options to get darker or lighter or both so likely you just need to adjust to one direction or the other depending on the theme.

[flash1293]

Ah perfect, we should just use that in the palette service - we can also do this on a separate PR @dej611

[markov00]

If yes, in all cases or just in cases like heatmap if the color is tied to an "intensity" variable of some sort?

from https://www.carbondesignsystem.com/data-visualization/color-palettes for sequential monochromatic palettes:

In light themes, the darkest color denotes the largest values. In dark themes, the lightest color denotes the largest values.

[cchaos]

Right so the discrete visualization palette's color values work in both light and dark mode (dark mode better actually). So there's nothing to change when using it to strictly denote different series. But when create single color (quantitative) palettes whose brightness and/or saturation correlates to a data value, this must change that starting value.

[gvnmagni]

Hi all! I would love to add a few things 🙂

TL:DR yes, we need to adjust color scales for dark theme inverting the lowest and highest value. We also need (future goal) to have a slightly adjusted palette for categorical values in order to increase contrast with background.

Long (-ish) explanation

You have already pointed out what I believe is the best behaviour for color scales on light and dark background. The basic concept is really simple, we convey values through the use of color and to do that we have to visually separate the shape from the background, it’s a matter of contrast. As the values represented increase we increase the color contrast using more intense color. For light background this means getting darker colours, for dark ones this means getting lighter.

Few additional considerations though.

Color palette for categorical data
The current discrete color palette is not affected by this matter since it does not convey numerical information, only categorical. This is true but at the same time it might be interesting to considerate a slightly different palette that could keep our current colours but increasing a little bit the contrast with the background, it could help legibility and accessibility.
This is what IBM does in this case, as a reference:

Color overlapping
This is a detail we have to take in consideration when overlapping shapes. It could happen (especially in maps, area charts, heatmaps...) that we want to show when two data series overlap and we want to highlight this. A common visual way as you surely know is to go with blending modes such as Multiply, where two colours get added. Problem is that these effect works differently on light and dark background since they interact with the background color as well

So what we should do when we use these effect (if we use them, could be that we never use them) is to switch from Multiply to Screen as blending mode for dark backgrounds, this way the sum of colours will get lighter instead of darker

Sorry for the long post 🙂

[flash1293]

That's awesome, thanks! About changing palettes based on theme: On the technical side I'm not 100% sure how we would handle this - could we store the original source palette as long as the user doesn't change any colors and automatically translate them based on the theme, @dej611 ?

[dej611]

I think it is possible to handle default palette propagating palette name, which we store already in the configuration side.