Provide color vector along with levels in contours?

[maxlarsen]

Hello,

Is it currently possible to provide a vector of n-1 colors along with n levels for a filled contour plot? I tried very hard but I was not able to figure it out. It seems the color= option always falls back on the gradient method which does not work for me.

Explanation: maybe my function f(x,y) takes values on [0,10] but all of the action is between 9.9 and 10, and I want "equally spaced colors" on the levels [0,5,9,9.5,9.9,9.95,9.99,10]. This is quite natural in eg. an optimization context. Right now what I managed to obtain was always an almost indistinguishable gradient on a "narrow range" (9.9-10 out of 0-10 in the example).

More generally, I think a reasonable heuristic would be to automatically define value bins such that each bin has as many points : each colored region would have approximately the same area. I understand that the current heuristic which picks more distinct colors when the values are further away is also useful, so this could be an alternative heuristic somehow. Just throwing the idea in the air, I would be very happy with a manual vector of colors already.

Amazing job on this package by the way. Thanks a lot!

Max

[tbreloff]

You can create your own gradients and vectors directly and pass them in... here's an example that I hope shows how to do this:

Hopefully this helps. I don't have the color functionality well documented, so for right now you might need to just ask for specific help here when you can't figure it out.

[maxlarsen]

Hey thanks a lot, worked flawlessly! I don't understand how it works though, would you mind shedding some light on what role the [x,y,z] argument plays exactly?

[tbreloff]

Sure. It's what you were asking for (I think)... A vector of cutoff points. The values are expected to be between 0 and 1, and correspond to bucket endpoints. So in this example a z-value of [0.975 * (maxval - minval) + minval] will be mapped to the equivalent of 75% of a "normal" gradient. Does that explain it ok?

On Jan 28, 2016, at 10:25 PM, maxlarsen notifications@github.com wrote:

Hey thanks a lot, worked flawlessly! I don't understand how it works though, would you mind shedding some light on what role the [x,y,z] argument plays exactly?

—
Reply to this email directly or view it on GitHub.

[maxlarsen]

OK so I did some more tests and for the sake of completeness and for anyone reading this it looks like ColorGradient(:heat,[x1,x2,x3,...]) is in fact ColorGradient(:heat,[0,x,1]). I was being bitten by the fact that if you give it more than 3 values, it silently ignores the input:

xx=linspace(-1,1,100)
yy=xx
ff(x,y)=pdf(MvNormal([0.,0],[3. 2;2 3]),[x,y])
gg=[ff(x,y)::Float64 for x=xx,y=yy]
qlevels=[0,.25,.5,.75,0.8,0.9,0.95,0.975,0.99,1]
levels=quantile(vec(gg),qlevels)

contour(xx,yy,gg,fill=true,levels=levels,c=:heat)
contour(xx,yy,gg,fill=true,levels=levels,c=ColorGradient(:heat,[0,0.1,0.95,1]))
contour(xx,yy,gg,fill=true,levels=levels,c=ColorGradient(:heat,[0,0.1,0.8,1]))
contour(xx,yy,gg,fill=true,levels=levels,c=ColorGradient(:heat,[0,0.8,0.95,1]))

all plot the same thing on my machine.

So if I understand correctly you cannot as of now pick m colors, m bins and apply the colors to the bins. But you can "increase the contrast" on one end or the other by feeding ColorGradient(:heat,[0,0.20,1]) or ColorGradient(:heat,[0,0.80,1]).

Given the issue title I could leave this open as a feature request. On the other hand ColorGradient(:heat,[0,0.80,1]) does the job for me and I am happy to close! Let me know. Thanks in any case.

[tbreloff]

Which backend are you using? What version of Plots?

If I understand, you want to be able to specify the exact contour levels and assign colors manually? This may be possible, but I'd need to look at the code again.

On Jan 29, 2016, at 8:37 AM, maxlarsen notifications@github.com wrote:

OK so I did some more tests and for the sake of completeness and for anyone reading this it looks like ColorGradient(:heat,[x1,x2,x3,...]) is in fact ColorGradient(:heat,[0,x,1]). I was being bitten by the fact that if you give it more than 3 values, it silently ignores the input:

xx=linspace(-1,1,100)
yy=xx
ff(x,y)=pdf(MvNormal([0.,0],[3. 2;2 3]),[x,y])
gg=[ff(x,y)::Float64 for x=xx,y=yy]
qlevels=[0,.25,.5,.75,0.8,0.9,0.95,0.975,0.99,1]
levels=quantile(vec(gg),qlevels)

contour(xx,yy,gg,fill=true,levels=levels,c=:heat)
contour(xx,yy,gg,fill=true,levels=levels,c=ColorGradient(:heat,[0,0.1,0.95,1]))
contour(xx,yy,gg,fill=true,levels=levels,c=ColorGradient(:heat,[0,0.1,0.8,1]))
contour(xx,yy,gg,fill=true,levels=levels,c=ColorGradient(:heat,[0,0.8,0.95,1]))
all plot the same thing on my machine.

So if I understand correctly you cannot as of now pick m colors, m bins and apply the colors to the bins. But you can "increase the contrast" on one end or the other by feeding ColorGradient(:heat,[0,0.20,1]) or ColorGradient(:heat,[0,0.80,1]).

Given the issue title can I leave this open as a feature request?

—
Reply to this email directly or view it on GitHub.

[maxlarsen]

pyplot() back-end and:

 - Gadfly                        0.4.2
 - Plots                         0.5.1
 - PyPlot                        2.1.1
 - UnicodePlots                  0.1.1
 - Winston                       0.11.13

Yes, I feel like:

contour(xx,yy,gg,fill=true,levels=[z1,z2,z3,z4,z5],c=uniformgradient(:heat,4))

would often be useful. (or maybe uniformpalette or something: 4 equally spaced colors along a gradient). If I have:

contour(xx,yy,gg,fill=true,levels=[z1,z2,z3,z4,z5],c=mycolorvector)

It is even more flexible and I can probably figure out an external way to come up with mycolorvector=uniformgradient(:heat,4) (although I feel like you did a great job with colors in this package so it would be great to be able to access your palettes, gradients etc.)

I would personnally very quickly wrap this in:

function qcontour(xx,yy,gg,quantilelevels)
    levels=quantile(vec(gg),quantilelevels)
    contour(xx,yy,gg,fill=true,levels=levels,color=uniformgradient(:heat,length(quantilelevels)-1))
end

Then I could call qcontour(xx,yy,gg,[0,.25,.5,.75,.9,.95,1]) and obtain 6 well-distinct colors for my bins, even when the values are very close, eg [0.9-0.95] and [0.95-1].

Finally:

econtour(xx,yy,gg,n)=qcontour(xx,yy,gg,levels=linspace(0,1,n+1))

and econtour(xx,yy,gg,6) will cut the z values in 6 bins of equal number of observations and give well-distinct colors for each of those.

Of course with those approaches I will lose the color-clue of height, but I can obtain a more precise sense of multimodalities, where the maxima are etc. even on flat regions.

[tbreloff]

I think you've uncovered a bug... I'm looking into it.

[tbreloff]

Ok I think I figured it out (and hopefully I didn't break anything else in the process!!!) I pushed up some changes to the dev branch. If you wouldn't mind, could you do a Pkg.checkout("Plots", "dev") and see if it works as expected now? Here's a slight modification of your example:

[maxlarsen]

What is it supposed to do? It clearly does provide better visibility in the example above but it does not look like it take "uniformly spaced" colors and puts them in the corresponding nlevels-1 bins:

using Plots, Distributions
xx=linspace(-1,1,100)
yy=xx
ff(x,y)=pdf(MvNormal([0.,0],[3. 2;2 3]),[x,y])
gg=[ff(x,y)::Float64 for x=xx,y=yy]
qlevels=[0,0.1,0.2,1]
levels=quantile(vec(gg),qlevels)

contour(xx,yy,gg,fill=true,levels=levels,c=:heat)    #figure 4
contour(xx,yy,gg,fill=true,levels=levels,c=ColorGradient(:heat,qlevels)) #figure 5

levels does the right thing: I have a region with the lowest 10% values, one with the next 10% lowest and the 80% rest. But Figure 5 uses the qlevels option and the colors are "less equally spaced" than without the keywords....

Didn't have time to play around much

[tbreloff]

I'll be honest that this seems more like a PyPlot idiosyncrasy. See for example this answer: http://stackoverflow.com/questions/15601096/contour-graph-in-python

In the linked graph, notice that the colors in the right hand graph are light blue and orange, which correspond to 0.25 and 0.75. You could definitely argue that those colors should correspond to 0 and 1 (dark blue and dark red), but that's not what PyPlot does.

The correct solution may be to "compress" the gradient for PyPlot and essentially trick it to use the colors we want. I don't love the idea of doing that automatically but it might work ok. I'll think on this more, and please post more examples (with a description of desired functionality) if you think of them.

On Jan 29, 2016, at 7:03 PM, maxlarsen notifications@github.com wrote:

What is it supposed to do? It clearly does provide better visibility in the example above but it does not look like it take "uniformly spaced" colors and puts them in the corresponding nlevels-1 bins:

using Plots, Distributions
xx=linspace(-1,1,100)
yy=xx
ff(x,y)=pdf(MvNormal([0.,0],[3. 2;2 3]),[x,y])
gg=[ff(x,y)::Float64 for x=xx,y=yy]
qlevels=[0,0.1,0.2,1]
levels=quantile(vec(gg),qlevels)

contour(xx,yy,gg,fill=true,levels=levels,c=:heat) #figure 4
contour(xx,yy,gg,fill=true,levels=levels,c=ColorGradient(:heat,qlevels)) #figure 5

levels does the right thing: I have a region with the lowest 10% values, one with the next 10% lowest and the 80% rest. But Figure 5 uses the qlevels option and the colors are "less equally spaced" than without the keywords....

Didn't have time to play around much

—
Reply to this email directly or view it on GitHub.

[tbreloff]

For clarity, let me expand on the ColorGradient constructor. What you are doing is setting the "anchor colors" of the gradient to new positions (this has nothing to do with contours/levels yet, as you're only building the gradient).

An example will help. Suppose there are 3 colors in the original gradient: red, green, blue. You sample from the gradient where z=0 gives you red, z=0.5 gives you green, and z=1 gives you blue. z=0.25 interpolates halfway between red and green, etc.

Now if you instantiate the gradient with new anchor points, you are "warping" the gradient. Hopefully these examples will help you understand (checkout latest dev branch for this to work... I pushed one more fix):

Gradient construction is separate from the issues of:

• PyPlot color choices for contours (need hack to fix their bad logic?)
• Helper functions to automatically find good "anchor colors" given a data distribution

[maxlarsen]

Makes sense. I guess my view is that rather than hacking the gradient functions, at some point it is more convenient to be able to feed a color vector to obtain the visualization you want. Looks like you can do it in matplolib with ListedColormap see here. I don't know if you are interested in considering this option for Plots.jl (regardless of the back-end). Cycling over colors would be a good default behavior if the number of colors is not the same as the number of bins.

[mkborregaard]

@maxlarsen check this PR on PlotUtils, I think that will allow you to do this by registering the color vector as a gradient and then use it by name for further plots.

JuliaPlots/PlotUtils.jl#5

[tbreloff]

Sadly I don't think it's this simple. (Otherwise this should be closed)
The problem is in defining specific colors for each contour level, and
circumventing the gradient mechanism.

On Monday, November 7, 2016, Michael Krabbe Borregaard <
notifications@github.com> wrote:

@maxlarsen https://github.com/maxlarsen check this PR on PlotUtils, I
think that will allow you to do this by registering the color vector as a
gradient and then use it by name for further plots.

JuliaPlots/PlotUtils.jl#5
JuliaPlots/PlotUtils.jl#5

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#118 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA492ucFNAlS0odld13SCwkxbKz4rcUfks5q7wfzgaJpZM4HO0qz
.

[mkborregaard]

You're right, I didn't understand the issue properly.
But then I think this request is related to my other issue: JuliaPlots/PlotUtils.jl#3 , where classes would take the levels attribute and gradtype would be :custom.