add default colorscale attribute
#2493
Conversation
t-bltg
force-pushed
the
log_cbar
branch
2 times, most recently
from
080dfd7
to
21a0966
Compare
t-bltg
changed the title
Colorbar scale
t-bltg
force-pushed
the
log_cbar
branch
2 times, most recently
from
6ac03c8
to
1f08f95
Compare
t-bltg
changed the title
|
Thanks for taking a look at this again. It looks great already. I can help with more examples just to be sure, the more the merrier. using GLMakie
using Random: seed!
seed!(123)
x = y = 1:100
z = rand(1:100, 100,100)
fig = Figure()
ax = Axis(fig[1,1], aspect = 1, xscale = log10, yscale = log10)
hm = heatmap!(ax, x, y, z; colormap = :gist_stern)
Colorbar(fig[1,2], hm, scale = log10)
fig
Expected output: using Gnuplot
@gp x y z "w image pixels notit" "set auto fix" "set size square" :-
@gp :- yrange = (0.5,100) :-
@gp :- "set logscale x" "set logscale y" "set logscale cb" :-
@gp :- xlab = "x" ylab = "y" "set cblabel 'z'" palette(:gist_stern)
Gnuplot.save(term="pngcairo size 600,400", output="logs_gnuplot.png")
|
|
Thanks for the feedback. Yes, before I work further on this PR, I want to make sure that the approach is also valid with @SimonDanisch and @jkrumbiegel. I've only modified Here is what I obtain for your example with the using CairoMakie
import Random
Random.seed!(123)
x = y = 1:100;
z = rand(2:100, 100, 100); # NOTE: starting at 2, to avoid undefined (log10 ∘ log10)(1), I think we should add a `colorscale` argument instead !
fig = Figure();
ax = Axis(fig[1, 1], aspect=1, xscale=log10, yscale=log10);
hm = heatmap!(ax, x, y, z; colormap=:gist_stern);
Colorbar(fig[1, 2], hm, scale=log10);
display(fig)
Makie.save("stern.png", fig)
On second thought I think we should add a With a using CairoMakie
import Random
Random.seed!(123)
x = y = 1:100;
z = rand(1:100, 100, 100);
fig = Figure();
ax = Axis(fig[1, 1], aspect=1, xscale=log10, yscale=log10);
hm = heatmap!(ax, x, y, z; colormap=:gist_stern, colorscale=log10); # NOTE: added `colorscale` attr
Colorbar(fig[1, 2], hm); # inherits `scale = p.colorscale` by default
display(fig)
Makie.save("stern.png", fig)
fig
And gnuplot: |
t-bltg
changed the title
colorscale argument
t-bltg
force-pushed
the
log_cbar
branch
3 times, most recently
from
6c499ea
to
0b4c020
Compare
t-bltg
force-pushed
the
log_cbar
branch
3 times, most recently
from
9e0c9fe
to
755fc2b
Compare
|
Yes I think this one needs to be planned well so that it's feasible for all backends. For example, the transformations on points are all done on the CPU but I'm not sure if we could leverage the GPU for the color transforms, and how that would change the approach. |
|
The |
|
As it needs to work on all backends, at least some planning or thinking about it seems necessary. I can't really offer a glmakie perspective, from a user perspective I think passing a colorscale attribute seems reasonable. Although I never really liked how color is handled via multiple separate attributes that sometimes go together and sometimes not. This also makes it such that you cannot use colormaps with strokes on scatter, because that stuff is only defined for the fill. But isn't that separation pretty arbitrary? Other recipes have multiple things to be colored, so the "one colormap, one colorrange" idea breaks down anyway. I would probably prefer putting all this into one object but not sure how that would play with updating only colormap or only colorrange like you currently can. |
|
Thanks both for the comments.
I have also thought about using a mutable
Yes, this is why Simon's global view or comments might be helpful here, before I can try updating
I think |
|
The example adapted from #2496 (comment) with an arbitrary using CairoMakie
himmelblau(x, y) = (x^2 + y - 11)^2 + (x + y^2 - 7)^2
x = y = range(-6, 6; length=100)
z = himmelblau.(x, y')
levels = 10.0.^range(0.3, 3.5; length=10)
f, ax, ct = contour(x, y, z; levels, colormap=:hsv, colorscale=x -> x^0.01)
display(f)
This is exactly the level of control that is suited to these plots. |
|
Just in case is relevant, I just noticed that hexbin has already a scale argument,
but not sure if the colormap is correct. |
|
Since But of course this needs to be carefully checked. ==> done, see below. |
|
Based on the example in https://docs.makie.org/stable/examples/plotting_functions/hexbin/#changing_the_scale_of_the_number_of_observations_in_a_bin, the following is the output on this branch, replacing using CairoMakie
x = randn(10_000);
y = randn(10_000);
fig = Figure();
hexbin(fig[1, 1], x, y; bins = 40, axis = (aspect = DataAspect(), title = "scale = identity"));
hexbin(fig[1, 2], x, y; bins = 40, axis = (aspect = DataAspect(), title = "colorscale = log10"), colorscale = log10);
display(fig)
save("hexb.png", fig)
As a consequence, I'd say that |
|
@SimonDanisch, maybe I assume that this PR is going in the right direction, and that you don't have any objection to the approach ? Your answer would allow me to start working on adapting |
|
Thanks, will try to get to it next! |
|
Dropping by to voice my support for this PR! I've been waiting eagerly to have this merged! 😂 Please let me know if you want help to get things tested, etc. |
I'm sure there will be (corner case) bugs, so if there are use cases that we didn't think of (and interactive usages), we'd be glad to hear those ;) |
|
It's looking quite good! Great that you fixed the last bugs I found, sorry to say I got another for you :) brain = load(assetpath("brain.stl"))
color = [abs(tri[1][2]) for tri in brain for i in 1:3]
fig, ax, m = mesh(brain; color, colorscale=identity)
mesh(fig[1, 2], brain; color, colorscale=log10)
display(fig)
##
m.colorscale = log10Only when displaying first, then changing the colorscale on
|
Fixed: for interactivity in Question: what does |
|
As a last thing, would you mind changing the new reference tests a little in order to check that the observable updates work. One simple way would be to take the examples where you constructed two plots, one with |
|
If think the best container for these tests is to use a |
|
Ah WGLMakie fails due to a too strictly typed observable, nice that the test caught this :) |
|
Yeah, I cannot debug |
|
@jkrumbiegel, do you have an idea where the attributes are set in EDIT: |
|
So I don't really think I can go much further on the I tried to fix |
|
Ok thank you, hopefully @SimonDanisch can take a look at this stage as I'm also not the person to ask about WGLMakie internals. From my side fixing this would be the last blocker to getting this merged, all the other stuff seemed to work pretty well at my level of testing. |
|
@SimonDanisch please, it will be good not to let this one get behind again. Sorry, I know, too many things. |
|
Is there any update on this? To me, this PR is quite important. |
|
Yes, the backend implementation had a few bugs since every backend has their own way to deal with colormaps and i decided to implement the backend logic more cleanly in #2900. |
|
Hi all, I am wondering this Thanks! |
|
See #2900. |
Description
Partiallyfix #1405.First example
old approach
test CairoMakiepasses locally.I also believe that the user shouldn't be responsible for scaling height values (i.e. using(x, y) -> xshould be scaled byxscaleandyscale, maybe as suggested by adding acscaleorzscalefor 2DAxis, but this is left for another issue / discussion).Unscale theColorbaraxis limits, such that the following yields a correctly scaled colorbar:Add a
colorscaleattribute, and make colorbar inherit this attribute by default. The rationale is that the colorbar colors are linked to the plot colors (orzvalues, heights). Consequently, only setting thescaleattribute of the colorbar when creating it is not sufficient to correctly render scaled colors. This PR makes Makie consistent with other libraries such asgnuplotorpyplot.new approach
Python version
Second example
I'm going to rework this PR using theexample from @lazarusA on discourse:TODO:
Type of change
Delete options that do not apply:
Checklist