juliagraphics / colorschemes.jl Goto Github PK

@rafaqz Do you think this is now OK to release as 3.14.0, with your improvements to underlying type use?

@JuliaRegistrator register()

The URL of this package does not match that stored in METADATA.jl.
cc: @cormullion

julia > using ColorSchemes, Colors

julia> get(ColorSchemes.magma, N0f16(1.0))
RGB{Float64}(0.987053,0.991438,0.749504)

julia> get(ColorSchemes.magma, Gray(N0f16(1.0)))
ERROR: MethodError: no method matching get(::ColorScheme, ::Gray{Normed{UInt16,16}})
Closest candidates are:
  get(::ColorScheme, ::Any, ::Any) at /home/tlnagy/.julia/packages/ColorSchemes/c0hLF/src/ColorSchemes.jl:161
  get(::REPL.Terminals.TTYTerminal, ::Any, ::Any) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/REPL/src/Terminals.jl:176
  get(::ColorScheme, ::Union{AbstractRange{#s14} where #s14<:Real, Array{#s15,N} where N where #s15<:Real, #s16} where #s16<:Real) at /home/tlnagy/.julia/packages/ColorSchemes/c0hLF/src/ColorSchemes.jl:204
  ...
Stacktrace:
 [1] top-level scope at REPL[20]:1

ColorSchemes.jl is great and I like using it with Images.jl, but it would be great to handle Gray wrapped values by default.

@JuliaRegistrator register()

Request: (diverging) bipolar colormaps

I'd like to suggest the addition of diverging bipolar colormaps, such as those mentioned in matplotlib/matplotlib#6033 that ended up being encoded in https://github.com/endolith/bipolar-colormap I think, for example. What do you think?

Copying images in the ReadMe of https://github.com/endolith/bipolar-colormap for issue reader's convenience below. 😄

Subrequest

I'd like to also suggest some more freedom on these, in particular remove the part which swaps colors depending on the neutral (central) color, so that one could make a cyan-darkblue-white-darkred-yellow colormap for example. FWIW, the swapping comes from the MATLAB bipolar colormap, on which https://github.com/endolith/bipolar-colormap is built, AFAICT. And from the MATLAB function's docs:

% The colormap goes from cyan-blue-neutral-red-yellow if neutral is < 0.5
% (the default) and from blue-cyan-neutral-yellow-red if neutral > 0.5.

Workaround?

Alternatively, maybe this is better achieved by hand using, e.g., ColorSchemeTools, but I'm sure by doing this I'm not including all the nice details and thinking that went into https://github.com/endolith/bipolar-colormap to make his colormaps, so maybe someone has some better ideas?

Some examples I tried with ColorSchemeTools.jl 😃:

Hi,

I have generated and used some basic colormaps for color science studies. These include:

LMS Cone Isolating colors

DKL Cone-Opponent colors

DKL Isoluminance Hues

and other variants.

I am wandering if these colormaps are of more general interests, so anyone can easily get access to them if they were included in the predefined colorschemes.

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

There's some discussion going on in PlotUtils about switching to ColorSchemes as a provider of color gradients. However, there are some overlaps in PlotUtils' gradient names; for example,:rainbow exists in misc and colorcet.

It would be nice to have a way we all agree on to handle that; either by manually ensuring that there are no namespace conflicts, or some other system.

(Also, quick question - is the library threadsafe? It looks like all the colorschemes are stored in a global Dict, which may lead to some issues. I'll test it in a bit.)

@JuliaRegistrator register()

@JuliaRegistrator register()

Hello I am trying to create colorscheme that I want to use in the heatmap of makie for now I use greys and It works quite well but

I would like to implement windows
so pixels below given value a should be black
all above given value b should be white
different shades of grey for all values between a and b and proportional to those values

How to achieve this?

Thank you for help!

Below What Is already achieved but without windows

@JuliaRegistrator register()

Wondering if anyone has comments on the display of colorschemes; now that Documenter.jl can do multiple SVGs easily I've changed the code a bit.

Proposal:

https://juliagraphics.github.io/ColorSchemes.jl/latest/basics/#cmocean

@JuliaRegistrator register()

@JuliaRegistrator register()

@JuliaRegistrator register()

For some legacy fun, it would be nice to have access to the web-safe color palette.
The full color table can be found here.

@JuliaRegistrator register()

Hi, I couldn't find a solution for the ColorSchemes building.

When running using ColorSchemes I get the following error:
Error: Error building ImageMagick:
│ ERROR: LoadError: UndefVarError: is_linux not defined
│ Stacktrace:

I had force _ is_linux _ to false, but it did not solve the issue.

I am using Version 1.0.0 (2018-08-08)

thanks

Hi! I came across the need to convert a heatmap image to an Array of continuous values, and in the process discovered this cool package. ColorSchemes is exactly what I wanted to represent with code the continuous semantics humans put on a heatmap. Thanks!

But in my case, I already had pixels, and I wanted to find out where each pixel lies on the this continuous ColorScheme, rather than the other way around (the functionality provided by get(cscheme, x).

I've done this before in JavaScript via d3 to create a map legend you can mouse over:

var legendScale = d3.scale.log()
      .domain([minValue,maxValue])
      .range([0,legend.width()]);
// ...
$(legend).mousemove(function(e){
  offset = $(this).offset();
  xPos = e.pageX - offset.left;
  value = prettifyNum(parseFloat(legendScale.invert(xPos).toPrecision(2)));
  mouseovertext[0].textContent=value;
});

So anyway, this is a Feature Request to be able to do the same thing with ColorScheme.jl! 😸

I should've checked to see if this functionality already exists somewhere else, or if it's even a thing people would want, but I got carried away and I wrote it myself... I put the functionality in this package here:
https://github.com/NHDaly/ColorSchemesInvert.jl/blob/master/README.ipynb

If this is something people think makes sense, I can open a pull request to merge that functionality into this package. What do you think?

I just saw the following blog post from the google AI blog which looks like it might fit nicely into this package:

https://ai.googleblog.com/2019/08/turbo-improved-rainbow-colormap-for.html

1. If you click on "edit on Github" at https://docs.juliaplots.org/latest/generated/colorschemes/, it takes you to the broken link: https://github.com/JuliaPlots/PlotDocs.jl/blob/master/docs/src/generated/colorschemes.md
2. If you search like so: https://docs.juliaplots.org/latest/search/?q=Colorschemes, you get several links where the spelling is Colorschemes instead of ColorSchemes. See: https://docs.juliaplots.org/latest/colorschemes/#Colorschemes. I don't think it's intended. It caused me to incorrectly try Pkg.add("Colorschemes").

Hi,

I needed to iterate over a color scheme object in order to perform an operation for every color, when I noticed this strange behaviour

julia> [c for c ∈ ColorSchemes.Dark2_3]
3-element Array{Any,1}:
 ColorTypes.RGB{Float64}[RGB{Float64}(0.106,0.62,0.467), RGB{Float64}(0.851,0.373,0.008), RGB{Float64}(0.459,0.439,0.702)]
 RGB{Float64}(0.106,0.62,0.467)
 RGB{Float64}(0.851,0.373,0.008)

the first entry is an array containg all three colors of the color scheme, the second and third entry are the first and second color respectively.

On julia 0.5, when I try to install this package, it fails:

julia> Pkg.add("ColorSchemes")
INFO: Cloning cache of Clustering from https://github.com/JuliaStats/Clustering.jl.git
INFO: Cloning cache of ColorSchemes from https://github.com/cormullion/ColorSchemes.jl.git
ERROR: Cannot clone ColorSchemes from https://github.com/cormullion/ColorSchemes.jl.git. Invalid reference name 'refs/tags/v"1.2.0"'.
 in prefetch(::String, ::String, ::Array{String,1}) at .\pkg\cache.jl:56
 in resolve(::Dict{String,Base.Pkg.Types.VersionSet}, ::Dict{String,Dict{VersionNumber,Base.Pkg.Types.Available}}, ::Dict{String,Tuple{VersionNumber,Bool
}}, ::Dict{String,Base.Pkg.Types.Fixed}, ::Dict{String,VersionNumber}, ::Set{String}) at .\pkg\entry.jl:512
 in resolve(::Dict{String,Base.Pkg.Types.VersionSet}, ::Dict{String,Dict{VersionNumber,Base.Pkg.Types.Available}}, ::Dict{String,Tuple{VersionNumber,Bool
}}, ::Dict{String,Base.Pkg.Types.Fixed}) at .\pkg\entry.jl:476
 in edit(::Function, ::String, ::Base.Pkg.Types.VersionSet, ::Vararg{Base.Pkg.Types.VersionSet,N}) at .\pkg\entry.jl:30
 in (::Base.Pkg.Entry.##2#5{String,Base.Pkg.Types.VersionSet})() at .\task.jl:360
 in sync_end() at .\task.jl:311
 in macro expansion at .\task.jl:327 [inlined]
 in add(::String, ::Base.Pkg.Types.VersionSet) at .\pkg\entry.jl:51
 in (::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#add,Tuple{String}})() at .\pkg\dir.jl:31
 in cd(::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#add,Tuple{String}}, ::String) at .\file.jl:48
 in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String, ::Vararg{Any,N}) at .\pkg\dir.jl:31
 in add(::String) at .\pkg\pkg.jl:100

The important part is Invalid reference name 'refs/tags/v"1.2.0"'.
I see 3 tags referring to 1.2.0:

V1.2.0
v"1.2.0"
v1.2.0

The last one is in the expected format. Could you remove the first two tags? GitHub allows you to delete the releases in the web interface, but not the tags. These can be removed with git tag -d tagname and pushed with git push origin :refs/tags/tagname. Do check that you don't accidentally remove the last one because of the terminal treating the " differently.

Thanks for putting together this package!

@JuliaRegistrator register()

It should be possible to have a colormap gallery similar to what MakieGallery does. The only real work to be done is in the web UI...

How about splitting the ColorSchemes.jl package into two separate packages?

1: ColorSchemes.jl - providing just the color schemes and the accessor functions

2: a new package ColorSchemeTools.jl - providing the tools for extracting color schemes from images, saving to images, conversion, sorting. etc.

I originally made ColorSchemes.jl simply to group sets of related colors together, avoiding dependencies on plotting packages (since I rarely plot). Ironically it now relies on Images.jl and Clustering.jl, which make the package a bit more dependency-heavy than the basic functionality might suggest.

After the split it should be possible for anyone to more easily add their preferred functionality to either of the ColorSchemes.jl or ColorSchemeTools.jl packages, such as libraries, lists, catalogues and categories, traits (whatever those are), interfaces, or anything else that people need, in order to steer the packages in the directions that people want to go. ... I'd prefer to at least keep the current basic usage unchanged, though:

using ColorSchemes
get(ColorSchemes.leonardo, 0.75)

since that's my primary use... :)

(I think this proposal could be either a temporary alternative to bike-shedding a brand new package design, or a useful thing to do anyway, even if a new package is ultimately the best way forward.)

@mkborregaard @chakravala @tpapp

@JuliaRegistrator register()

On my machine, using latest tag, there's a failing test:

misc tests: Test Failed at /gnu/store/vjn5iayr1iz6mb40qck86xxr9mpbqiz8-julia-colorschemes-3.10.2/share/julia/packages/ColorSchemes/test/runtests.jl:105
Expression: y2 == y[1]
Evaluated: RGB{Float64}(0.17442110750186596,0.10479916072572365,0.07055654401306825) == RGB{Float64}(0.17442110750186593,0.10479916072572365,0.07055654401306825)

Assembling the previews of the schemes manually isn't ideal, so I'm going to make them be generated and inserted automatically during the Documenter pass.

As @KristofferC just mentioned in #33 we could use a tuple instead of a Vector for colors chemes, and remove the StaticArrays.jl dependency.

Is there any reason colors need to be in a Vector ? I (probably wrongly) assumed there was when I added the dependency to StaticArrays.jl to speed up color-scheme indexing. Tuples are cleaner and would improve package load time a lot, and the load time of other packages like Gaston.jl.

I'll write the PR if there is no problem with making the change.

@JuliaRegistrator register()

It conflicts with the color, which has caused some problems.

@JuliaRegistrator register()

@JuliaRegistrator register()

If all array values are equal, using get with the :extrema option gives an error.

get(colorschemes[:sunset], fill(0.3,20,20), :extrema)

ERROR: InexactError: trunc(Int64, NaN)

It would be nice if this edge case was handled.

@JuliaRegistrator register()

Not sure about how it should be named, but this palette could be a nice addition for many categories I guess:

Link to poster: http://mkweb.bcgsc.ca/biovis2012/krzywinski-visualizing-biological-data.pdf

Not sure about copyright either.

From python seaborn module.
The work is partially done here
https://github.com/isentropic/PlotThemes.jl/blob/master/src/seaborn.jl
https://github.com/isentropic/PlotThemes.jl/blob/master/src/seaborn_color_gradients.jl
Perhaps someone who knows the conventions of ColorSchemes could implement those

it seems that the collection of colorcet palettes is not complete, I'm looking for glasbey_bw_minc_20_minl_30 and its not available, it will be possible to increase the amount of colormaps ? otherwise, what would be the way to define a custom colormap with ColorSchemes with a set of colorants?, in the documentation there is one example but only with two colorants (I did not find a way to make it work for more).

cheers!

I'm using colorschemes for output in DynamicGrids.jl. But in some case converting simulation output to color can take more time than running the simulation.

It would be good to have a high-performance version of get that is always type-stable and doesn't clamp values when they don't need to be clamped.

Passing nothing for rangescale would probably be adequate to do this. Also using StaticArrays may help indexing performance.

We could also specialise on type - types like Bool have some obvious optimisations we could use.

Any thoughts before I put something together?

get(ColorSchemes.Reds_9, range(0, stop=1, length=10))

fails with

ERROR: MethodError: get(::Array{ColorTypes.RGB{Float64},1}, ::StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}}, ::Tuple{Float64,Float64}) is ambiguous. Candidates:
  get(cscheme::Array{C,1}, x, rangescale::Tuple{Number,Number}) where C<:ColorTypes.Colorant in ColorSchemes at /Users/tlienart/.julia/packages/ColorSchemes/I9lua/src/ColorSchemes.jl:289
  get(cscheme::Array{C,1}, x, rangescale) where C<:ColorTypes.Colorant in ColorSchemes at /Users/tlienart/.julia/packages/ColorSchemes/I9lua/src/ColorSchemes.jl:253
  get(A::AbstractArray, I::AbstractRange, default) in Base at abstractarray.jl:1186
Possible fix, define
  get(::Array{C<:ColorTypes.Colorant,1}, ::AbstractRange, ::Tuple{Number,Number})

adding collect fixes this

get(ColorSchemes.Reds_9, collect(range(0, stop=1, length=10)))

Happy to try to do a PR for this if deemed worthwhile

PS: 1.1.0-DEV.720, Colorschemes 2.0.0

I am currently checking my favourite colours and maps in Julia; I saw that from here

https://personal.sron.nl/~pault/

a lot of colormaps are covered since they are from colorbrewer, though he states that some are “tweaked”. Also he has a discrete rainbow and a sunset as well as the ground colormap. Would it be of interest to add them here, too or are they maybe already covered?

@JuliaRegistrator register()

The tag name "v"1.4.0"" is not of the appropriate SemVer form (vX.Y.Z).
cc: @cormullion