definition of plotly_diverging and plasma colorscale

[empet]

I identified a few issues in plotly templates:

1. Plotly diverging colorscale https://github.com/plotly/plotly.py/blob/master/packages/python/plotly/templategen/definitions.py#L240 has a wider whitish portion, compared with other diverging colorscales, as it can be seen in the following subplots, illustrating the same surface, colormapped to different such colorscales:

or interactive versions in chart studio: [https://plot.ly/~empet/15221(https://plot.ly/~empet/15221)

2. plasma colorscale is defined by 10 colors and this number yields many decimals digits in scale, as well as in the json file:

   [[0.0, '#0d0887'],
   [0.1111111111111111, '#46039f'],
   [0.2222222222222222, '#7201a8'],
   [0.3333333333333333, '#9c179e'],
   [0.4444444444444444, '#bd3786'],
   [0.5555555555555556, '#d8576b'],
   [0.6666666666666666, '#ed7953'],
   [0.7777777777777778, '#fb9f3a'],
   [0.8888888888888888, '#fdca26'],
   [1.0, '#f0f921']]

   With 11 colors the scale is [0, 0.1, ..., 1].

Update: since the arguments for the first issue are emipirical, I reinstalled ehtplot, and illustrated the deviation of lightness from linearity, at left and right of the central point of normalized data, and the pyramid heatmaps.

[jonmmease]

Hi @empet,

Thanks for taking a look. I believe the current diverging colorscale is PiYg (https://matplotlib.org/users/colormaps.html), but I do like your corrected one better. @nicolaskruchten what do you think? I believe you had mentioned wanting to consider an alternative diverging colorscale anyway.

If we change, I think we should give it a new name and add it to packages/python/plotly/_plotly_utils/colors/sequential.py.

Regarding the Plasma scale, @nicolaskruchten it looks like most of the scales in https://github.com/plotly/plotly.py/blob/master/packages/python/plotly/_plotly_utils/colors/sequential.py have 10 colors, do you remember where you got these definitions from? 11 colors would be a little cleaner and take up a less space, but I don't have strong feelings about it.

[empet]

Hi @jonmmease, I derived the new version from PiYg, by uniformizing its Lightness in the CIECAM-02 color space:

[[0, '#99065a'],
 [0.1, '#c31a7c'],
 [0.2, '#d65c9f'],
 [0.3, '#e48ebe'],
 [0.4, '#f3bfde'],
 [0.5, '#f6f6f5'],
 [0.6, '#b6e084'],
 [0.7, '#86c04a'],
 [0.8, '#60a22d'],
 [0.9, '#40821e'],
 [1, '#266418']]

I didn't suggest to use this one anyway. I just pointed out the drawback of that defined in the template definition, and illustrated how a surface or a pyramid heatmap look when they are colormapped to the existent diverging colorscale, and to this improved version. The plotly team can choose any other diverging colorscale, and then I'll uniformize it, to get a perceptually uniform colorscale.

[nicolaskruchten]

@alexcjohnson had some thoughts on why non-kinked diverging colorscales are good, so he might want to weigh in here. I like them with a sharp corner, so I'd be fine with changing it.

Re the fencepost problem in the existing scales, I don't think the few bytes of savings are worth making a change today :)

[gvwilson]

Hi - we are currently trying to tidy up Plotly's public repositories to help us focus our efforts on things that will help users most. Since this issue has been sitting for several years, I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our backlog. Thanks for your help - @gvwilson