@nicolaskruchten I think it should be included in the list of Plotly colorscales since it is an alternative to Jet. I didn’t notice Jet being used by Plotly users (probably because of its drawbacks) .
@nicolaskruchten The library scientific colormaps has at least two versions. My repo illustrates plots with colorscales derived from the first version.
The colormaps there are defined following the Kovesi idea, to ensure lightness linearity in the space CIECAM.
In 2019 when EHT Telescope released their Python library ehtplot to define colormaps for the blackhole,
I discovered an ehtplot function that asseses a colormap, i.e. whether it is perceptually uniform (i.e. it has linear lightness in the CAM2-UCS color space) or not. I used that function to test all Plotly coloscales, cmocean colormaps and a few matplotlib and scientific colormaps.
At that moment only Viridis, Plasma, Inferno, Magma and cmocean colormaps passed the test, while Kovesi colormaps, most of matplotlib and all scientific colormaps exhibited a nonlinear lightness in the CAM2-UCS space.
In a discussion on twitter with Stefan van de Walt, the co-creator of Viridis, and Fabio Crameri, the parent of scientific colorsmaps, I illustrated
with this image
that among other colormaps, the Fabio’s bamako colormap is not perceptually uniform in the above space. After this discussion Fabio released a second version. Comparing the arrays of r,g,b values in the two versions
I noticed that they do not coincide. I suspect that the second version contains perceptually uniform colormaps in the CAM2-UCS space (I haven’t checked them with ehtplot). Hence if you intend to add these colormaps to plotly colors, then their definition should be derived from the last version, 6.0, of the scientific colormaps.
Do you think this is an appropriate way of converting from 256 RGB tuples to our format?
import hawaii
import numpy as np
import plotly.express as px
px.bar(x=[1]*100, y=["hawaii"]*100, color=range(100),
color_continuous_scale = [
'#%02x%02x%02x' % tuple(x) for x in
np.clip(0, 255, np.round(np.array(hawaii.cm_data)*256)[::15].astype(int))
]
)
It’s OK, except the multilication np.array(...)*256 . I don’t understand why you don’t multiply by 255. The max element in the array of cm data is 1, and each r, g, b takes values
within {0,1,2, ... 255}. With the factor 256 you can get r, g, or b=256. np.clip restricts to the right set of values, but why you don’t define simply like this:
Do you think that using only 16 values is enough? Internally, Plotly.js does not interpolate in CIECAM or CAM2-UCS so the result will not actually be quite as good as using more values, but I also think it’s a bit overkill to use all 256
For sequential colorscales I don’t think that you need more than 11-13 colors. Viridis, Plasma and all cmocean colorscales are perceptually uniform in CAM-UCS2 space and plotly uses only 13 colors for their definition. The usual linear interpolation, as I can remember, preserves the lightness linearity.
