Using color collections for gradients

[mkborregaard]

With the addition of the ocean gradient schemes there are now a lot of cool new colors in PlotUtils. However, these colors are designed for oceanography - for other scientific uses other colors may be ideal. I would thus suggest sorting color gradients in collections - apart from a :default collection (with :magma, :plasma etc.), and an :ocean collection (with the ocean colours) I could imagine :elevation, :monochromes, :ColorBrewer, :HCLwizard, :colorblind etc.

The idea is similar to swatch libraries in Adobe Illustrator. An advantage is that it would allow PlotUtils to make available a big library of color gradients without cluttering the workspace with names.

Collections may be required to specify keywords :sequential, :diverging, for easy convenience. They may also specify :individual color schemes for when different series have different colors.

This is part of the enhancement suggest in #3. I would be willing to find and define some collections if people like the idea.

[cormullion]

Would be good to see a thought-out approach to gradients in JuliaGraphics. (I posted JuliaLang/julia#19004 in the wrong place...:))

[mkborregaard]

@cormullion That's a really funny coincidence. I promised to open this issue in a Gitter chat a few weeks back and only got around to it now.
I agree this would be great, of course. Did you also see the other issue (#3) ? That uses the Plots.jl syntax but a good way of dealing with colormaps needs this functionality as well IMHO.
I am happy to keep discussing this where most appropriate, and to contribute to a ColorMaps.jl package instead (which shouldn't need dependencies (other than Colors.jl) or be heavy as some seem to fear); especially if @tbreloff would be interested in using this for Plots.jl (which is my favourite plotting package).

[mkborregaard]

There is a PR now for this: #5

[mkborregaard]

@cormullion I have followed your links and thought a lot about this, and my conclusion is I don't need Julia to have more support for building color gradients automatically for scientific plotting (though I love ColorSchemes.jl, what a great idea). In the conversation you linked, @randyzwitch said that "all he needed was trivial data loading packages made up of Dicts of string literals", and I have come to agree with that. The reason is that color-scheme building is IMHO a complex thing well done by humans, and the best we can do for scientific plotting is to use existing, well-established high-quality color schemes. So my PR referenced above provides the infrastructure for that in PlotUtils.

[cormullion]

Cool stuff, looks good. I know we all use Plots.jl (😀) but wasn't sure how independent of it PlotUtils.jl is, thus my original thoughts about making color gradient support independent of any one package, and part of JuliaGraphics org, like Colors.jl (and NamedColors.jl). But organizational stuff isn't for me, so if it belongs better with Plots.jl/PlotUtils.jl that's great.

Don't forget to add some usage information and documentation! 😀 And some thoughts as to discoverability for newcomers...

[mkborregaard]

Good point, I agree with that. I didn't really add that much new, though, just adjusted PlotUtils.jl to use collections, so there isn't that much in the PR that would be relevant to a general package, though all three of the current collections (matplotlib, cmocean and colorbrewer) are completely general and would live best collectively. The best way I could think of would be to have a package which is just a library of color gradients and really basic code to access them (and a simple way of ensuring correct attribution). PlotUtils could keep all of its code and just depend on that for the actual gradient data instead of having them stored in the gradients directory, a dependency which would essentially come at no cost.

All of the three gradients are on a license that would allow just putting them in such a package. I have no idea whether @tbreloff would think it was a good idea to let PlotUtils do that though?

(Edited 4 Nov, PlotRecipes --> PlotUtils, sorry for the mistyping.)

[mkborregaard]

Regarding discoverability, my hope would be that Tom would use this functionality in Plots. From there it should be discovered quickly, even by people who prefer other plotting packages.

[tbreloff]

Of course you mean PlotUtils, not PlotRecipes. PlotUtils is small,
lightweight, and independent from Plots. I think it's a very appropriate
place to consolidate colormap access. And yes it will be discoverable
because Plots depends on it.

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

Regarding discoverability, my hope would be that Tom would use this
functionality in Plots. From there it should be discovered quickly, even by
people who prefer other plotting packages.

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

[mkborregaard]

Oh sorry, I mean PlotUtils clearly. Let me just edit.

[mkborregaard]

If that is your intention, and I am fully in favour of that, this and the related issue should be a nice step on the way :-) I think it's a very appropriate place to consolidate colormap access.

[tbreloff]

One thing I may do is add a :plots ColorLibrary which is merged dictionaries of default/matplotlib/etc. I'd do this from Plots. The important thing for me is that I don't want to force an extra step for the common gradients, and I'm also weary of "switching libraries" so that all of a sudden the standard gradients no longer work. So from Plots I may introduce something like add_gradients(lib) which merge that ColorLibrary into the :plots library.

[mkborregaard]

Yes, I thought of that. For now, I actually just added the matplotlib gradients directly into defaults to not break the Plots default. But separating that bit into Plots is better.

[mkborregaard]

This was fixed in #7