Repository navigation
Shared colorscales/colorbars aka coloraxes #3431
Description
Activity
- changed the title
[-]Shared colorscales/colorbars[/-][+]Shared colorscales/colorbars aka coloraxes[/+]on Feb 20, 2019 Quick question:
What should happen when traces that don't have the same colorbar visuals (e.g a heatmap and contour trace) share the same color axis?
In JSON form, this would be something like:
var data = [{ type: 'heatmap', z: [[1,2,3], [2,3,3]], coloraxis: 'coloraxis' }, { type: 'contour', z: [[2,3,1], [2,4,0]] coloraxis: 'coloraxis' }] var layout = { // e.g. some optional color-axis settings coloraxis: { colorscale: 'Viridis' } }
then should we show two colorbars? A "combined" version (not sure how this would look like)? Maybe we could show a colorbar only if all traces have compatible color bar visuals? Or should color axes not have control over color bars at all? In other words, traces with the same
coloraxiswould sharecmin/cmax/cmidandcolorscalevalues - it would up the user to setshowscaleand the colorbar options accordingly in their trace(s).Could we unify these color scales with a new attr like “discrete” or something? And then they could share
To be clearer: “discrete” would default based on the first trace that shares it, so contour-only would default to discrete and heatmap-only would not, and mixed would default to the first one but be overrideable
Contours with
coloring: 'heatmap'would work just fine already - the colorbar would have lines on it for the contours I guess, which wouldn't match the heatmap, but that's probably OK. And contours withcoloring: 'lines'(or'none') I don't see any sense allowing to share a colorbar with heatmaps. So we're only talking aboutcoloring: 'fills'. But since we have to exclude'lines'and'none'already, I'd argue for excluding'fills'too - and only allow contours withcoloring: 'heatmap'to share a scale with a heatmap - until we manage to do "discrete" right.FWIW "discrete" itself has two variants that we need to be careful about. The version used in contour plots defines data values at the edges of each color - where the contour lines are. Much of the time heatmaps (and choropleths, scatter marker colors...) with discrete colors don't do that kind of mapping, they simply have discrete data and they map a single value to a single color. As far as the colorbar is concerned the main distinction is where the labels go: at the color boundaries vs midpoints. For the boundaries case we will need changes to trace rendering code, for the discrete data case we'll need changes to the colorbar rendering (and maybe trace rendering changes, if we want to also collapse multiple values onto one color)
Reacted by etpinard- What does “exclude”/“not allow” look like?…On Wed, Apr 17, 2019 at 20:38 alexcjohnson ***@***.***> wrote: Contours with coloring: 'heatmap' would work just fine already - the colorbar would have lines on it for the contours I guess, which wouldn't match the heatmap, but that's probably OK. And contours with coloring: 'lines' (or 'none') I don't see any sense allowing to share a colorbar with heatmaps. So we're only talking about coloring: 'fills'. But since we have to exclude 'lines' and 'none' already, I'd argue for excluding 'fills' too - and only allow contours with coloring: 'heatmap' to share a scale with a heatmap - until we manage to do "discrete" right. FWIW "discrete" itself has two variants that we need to be careful about. The version used in contour plots defines data values at the edges of each color - where the contour lines are. Much of the time heatmaps (and choropleths, scatter marker colors...) with discrete colors don't do that kind of mapping, they simply have discrete data and they map a single value to a single color. As far as the colorbar is concerned the main distinction is where the labels go: at the color boundaries vs midpoints. For the boundaries case we will need changes to trace rendering code, for the discrete data case we'll need changes to the colorbar rendering (and *maybe* trace rendering changes, if we want to also collapse multiple values onto one color) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3431 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABRWA2E4UP3JFHRTSLKMRTPQ67IBANCNFSM4GPTMLDQ> .
it probably looks like rejecting that coloraxis value from the latter trace, and giving it a separate colorscale and bar.
Hmm. Is there any
xaxis/yaxisprecedent for this kind of rejecting? If two incompatible traces declarecoloraxis: "coloraxis1"would we force a second color axis to exist and map one trace onto it, despite the figure spec?I feel like we do this in a bunch of situations, but one that comes to mind right now is
scaleanchor, we'll ignore it if the referenced axis is the wrong type.If we reject a
coloraxissetting, that trace would have nocoloraxisso it would behave like all traces do right now - the trace defines its own colorscale and colorbar.Reacted by etpinard- Works for me…On Wed, Apr 17, 2019 at 21:55 alexcjohnson ***@***.***> wrote: I feel like we do this in a bunch of situations, but one that comes to mind right now is scaleanchor, we'll ignore it if the referenced axis is the wrong type. If we reject a coloraxis setting, that trace would have no coloraxis so it would behave like all traces do right now - the trace defines its own colorscale and colorbar. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3431 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABRWA3ZTFJUI22X67GX4XTPQ7IHZANCNFSM4GPTMLDQ> .
Did we end up doing anything to move from
cmin/cmaxtorange? It doesn't look like it... would this be a good time to introduce this? I.e. when usingcoloraxisyou have to userangeinstead ofcmin/cmax?Was that a requirement?
No, it was just something I remember talking about: #3549 (comment)
Ok, well if someone has a strong opinion on
// the current layout.coloraxis.cmin / layout.coloraxis.cmax // vs layout.coloraxis.crange // or vs layout.coloraxis.rangeyou have about one week to speak up, before v1.48.0 is set for 🚀
Right now traces can share axes but not colorbars. It would be nice if they could, something like
data[].coloraxis = "color1"withlayout.coloraxis1 = { ... }and all bounds-computations could include the union of the data of the traces, etc