Colorcet currently includes only continuous color spaces, but it was created while working on Datashader, which uses both continuous and categorical sets of colors. For rendering categorical data, Datashader requires having a distinct color per category, and it includes some ad-hoc collections of colors to try to get enough distinct colors to deal with complex datasets.

A principled approach for designing arbitrarily large sets of mutually distinct colors was presented in:

Glasbey, Chris; van der Heijden, Gerie & Toh, Vivian F. K. et al. (2007), "Colour displays for categorical images", Color Research & Application 32.4: 304-309.

"Glasbey" colors are available in ImageJ and for R, and there is a Python implementation of the method. Generating the colors with the Python code is time consuming, so it would be convenient to generate one or more large sets of Glasbey colors and distribute them in colorcet.

Here's an example of generating 257 colors, which took about 5 minutes to run:

pip install colorspacious
git clone https://github.com/taketwo/glasbey.git
cd glasbey
python glasbey.py --view 257 --format float output.csv

You can click on the image to see it in more detail. The resulting list of color triples can easily be added to colorcet:

1.000000,1.000000,1.000000
0.000000,0.000000,0.000000
0.843137,0.000000,0.000000
0.549020,0.235294,1.000000
...
0.462745,0.160784,0.286275
0.741176,0.898039,0.000000

The pyct.build package is imported and used before setup is called and so a build from a fresh python environment fails because it can't import pyct.build as it hasn't yet been installed as a build dependency.

Summary

In Dec. 2020 Peter updated the CET colormaps. This PR contains multiple changes:

1. Change aliases to a dict of lists. This simplifies the logic of finding all the aliases for a given name and makes it easy to add aliases for a given map.
2. Add new colormaps available in the Dec 2020 update to colorcet.m from Peter Kovesi, as well as at most one alias for any colormaps that do not yet have one.

Notes

• This PR depends on, and follows after, PR #64, which makes each colormap's algorithmic name AKA descriptorname the name of the CSV file.
• Resolves #60
• Resolves #56
• Since the CET_ name may in some cases be the only alias to a map, I have not removed those, though we talked about it previously. (Actually, I did at first, but then reverted the change). If someone wants to do this it's pretty easy--just remove cetnames, cetnames_flipped, and anything that references those variables from CET_to_py.py, rerun CET_to_py.py and update the tests.
• In this PR new colormap CSVs are not downloaded from Peter's site (as he doesn't have them all there anyway) but rather are generated from colorcet.m (using MATLAB/Octave script make_csvs_from_colorcet.m), since colorcet.m is the "upstream" of those CSVs. Some of the existing CSV colormaps in holoviz/colorcet don't exactly match what what's in colorcet.m but what's already here is being left as-is.
• A few CSVs have been renamed or removed as duplicates of existing CSVs with the same colormap. All CET CSVs should now have the algorithmic name (e.g. linear_kbc_5_95_c73 instead of linear_blue_5_95_c73. The old names (..._blue_...) may still be used.
• All existing aliases have been retained. New aliases have been added only for new colormaps or where aliases did not previously exist.
• Instructions for merging future additions from colorcet.m are at the top of make_csvs_from_colorcet.m and CET_merge.py.

This is a second attempt at #62.

• Resolves #60 by changing aliases in CET_to_py.py to a dict of lists. This renders aliases_v2 unnecessary. Minor changes necessary to make CET_to_py.py and then colorcet/__init__.py work with a dict of lists.
• Resolves #56 by the scripts make_csvs_from_colorcet.m and CET_merge.py, along with instructions in README_assets.md. The scripts were used to generate new CSVs for new colormaps and update CET_to_py.py which in turn were used to update colorcet/__init__.py with the new colormaps and aliases.
• aliases in CET_to_py.py is now a dict of lists. This renders the aliases_v2 dict unnecessary, as those can be added in to aliases as additional values.
• Ultimately I made sure that no existing colormaps or aliases are overridden but do allow for new aliases for existing colormap (e.g. "heat" == "fire", "gray" == "gray", etc.). Tests check out, and swatches look good in the example notebooks. This took a few iterations to figure out programmatically in CET_merge.py but I think I finally got it right.
• New maps are in assets/CETperceptual_csv_0_1_v3. It looked like for each existing cyclical colormap there was also one with 0.25 shift so I followed suit and included similarly-shifted maps along with the non-shifted maps (e.g. CET-C7s etc.)
• I think examples/assets/images/named.png needs to be updated, but I couldn't get examples/assets/write_named.py to run right on my machine. I got these warnings and the maps didn't plot right at all:

  WARNING:bokeh.io.export:There were browser warnings and/or errors that may have affected your export
  WARNING:bokeh.io.export:http://localhost:5006/static/extensions/panel/css/json.css - Failed to load resource: net::ERR_CONNECTION_REFUSED
  WARNING:bokeh.io.export:http://localhost:5006/static/extensions/panel/css/widgets.css - Failed to load resource: net::ERR_CONNECTION_REFUSED
  WARNING:bokeh.io.export:http://localhost:5006/static/extensions/panel/css/alerts.css - Failed to load resource: net::ERR_CONNECTION_REFUSED
  WARNING:bokeh.io.export:http://localhost:5006/static/extensions/panel/css/markdown.css - Failed to load resource: net::ERR_CONNECTION_REFUSED
  WARNING:bokeh.io.export:http://localhost:5006/static/extensions/panel/css/dataframe.css - Failed to load resource: net::ERR_CONNECTION_REFUSED
  WARNING:bokeh.io.export:http://localhost:5006/static/extensions/panel/css/card.css - Failed to load resource: net::ERR_CONNECTION_REFUSED
  

  It should be stated that I'm not a user of holoviews or bokeh, so I might have something set up wrong.

• I reworked get_aliases() a bit to just keep trying to get more aliases until no more are found. I hope the result is OK in terms of the order of results returned. I reworked test_get_aliases() to use sets and therefore not care about the order of the maps returned by get_aliases().
• Conflict output of CET_merge.py showing old aliases and mappings retained that are different from colorcet.m:

  #
  # ## NOTICE: Found the following aliases conflicts, with old alias assignment retained over new:
  # ## alias, old_descriptorname, new_descriptorname
  # bgyw, linear_bgyw_15_100_c68, linear_bgyw_20_98_c66
  # bmw, linear_bmw_5_95_c89, linear_bmw_5_95_c86
  # bmy, linear_bmy_10_95_c78, linear_bmy_10_95_c71
  # kbc, linear_blue_5_95_c73, linear_kbc_5_95_c73
  # kgy, linear_green_5_95_c69, linear_kgy_5_95_c69
  # rainbow, rainbow_bgyr_35_85_c73, rainbow_bgyrm_35_85_c69
  #
  # ## NOTICE: Found the following mapping conflicts, with the CET- name assigned
  # ##         to the original map over the new:
  # ## CET_name, old_descriptorname, new_descriptorname
  # CET-L16, linear_kbgyw_5_98_c62, linear_kbgyw_10_98_c63
  #
  

ALL software version info

colorcet 3.0.1 arviz 0.12.1 python 3.10/8 matplotlib 3.6.0/1 afaik introduced with recent colorcet/matplotlib release

Description of expected behavior and the observed behavior

When multiple libraries use mpl.colormaps.register(cmap, name=cmap_name) with the same cmap_name, a ValueError: A colormap named "cet_gray" is already registered. is raised. This happens e.g. for colorcet + arviz, both of which define cet_gray (see here for arviz).

What is the desired behavior -- does colorcet want to assume control of that color name, preventing others from accidentally overriding it (in which case arviz, which intends to duplicate the colorcet color, would be responsible)? Or should simultaneous overriding of the global variable be allowed.

Complete, minimal, self-contained example code that reproduces the issue

import arviz
import colorcet

or

import colorcet
import arviz

This prohibits the use of both simultaneously.

Stack traceback and/or browser JavaScript console output

Traceback (most recent call last):
 File "<string>", line 1, in <module>
 File "/home/yannik/env/env/lib/python3.10/site-packages/arviz/__init__.py", line 320, in <module>
   _mpl_cm("gray", _linear_grey_10_95_c0)
 File "/home/yannik/env/env/lib/python3.10/site-packages/arviz/__init__.py", line 317, in _mpl_cm
   register_cmap("cet_" + name, cmap=cmap)
 File "/home/yannik/env/env/lib/python3.10/site-packages/matplotlib/_api/deprecation.py", line 200, in wrapper
   return func(*args, **kwargs)
 File "/home/yannik/env/env/lib/python3.10/site-packages/matplotlib/cm.py", line 248, in register_cmap
   _colormaps.register(cmap, name=name, force=override_builtin)
 File "/home/yannik/env/env/lib/python3.10/site-packages/matplotlib/cm.py", line 149, in register
   raise ValueError(
ValueError: A colormap named "cet_gray" is already registered.

@jbednar @philippjfr I could use some feedback on this PR. I believe pytest was only run on Linux 3.7. I've opened it up to all platforms/versions so its possible that some of these are known issues that I should avoid.

Current status:
Python 3.6 - PASS
Python 3.7 - PASS

Python 2.7, Ubuntu
Some failures looking for DISPLAY env var: Invalid DISPLAY variable  https://github.com/kcpevey/colorcet/pull/1/checks?check_run_id=2042433951#step:9:489 Which I could set... but if you look at the code block where the failure is, its thinking that the ubuntu 2.7 build is X11 and its part of a qt5 backend. Which just seems wrong is several different ways. Should I just set the variable it wants or dig into why its getting there in the first place?

I see this failure on all 2.7 architectures https://github.com/kcpevey/colorcet/pull/1/checks?check_run_id=2042433951#step:9:502 Seems like the codebase is not actually supported on 2.7? It would be an easy fix to swap these around though. Should add that in as well?

For python 3.5 I'm seeing this:

  target environment location: C:\Miniconda3\envs\colorcet
  current conda version: 4.5.11
  minimum conda version: 4.9

I did some initial googling about this, but I haven't worked out a solution (or what the problem is, actually). 

Would be great to have an sdist on PyPI for the 1.0.0 release. This should help move packaging in conda-forge forward.

xref: https://github.com/conda-forge/staged-recipes/issues/4029

This is a usability question. It looks to me like all the colormaps are available via the cc.cm dictionary. However, there is no auto-complete for dictionaries in jupyter notebook, so I either need to remember the name exactly and type it out, or call cm.keys(), search for the colormap, and copy and paste the string.

Maybe there's an easier way that I don't see?

If I could use jupyters auto-complete to find the right color map, that would be much easier given your naming schemes. One way to achieve that would be to make cm be a bunch object, so that the items can be obtained with __get_attr__. If you define __dir__ right, that allows tab-completion. You could also define a sub-module that has instances of the colormaps with appropriate names (I think that's what matplotlib does?)

Thanks for these great colormaps!

The string 'pyviz' appears in a few places in the code but I don't intend to update those just yet (e.g for the conda channel). Some of the text in the README about HoloViz/PyViz should also appear on the website but that is for a separate PR.

Adding glasbey colors according to a new naming pattern with aliases for Category, Category10, and Category20.

To Do:

• [x] add assets
• [x] add to module
• [x] write tests
• [x] write up docs
• [x] add an example

Closes: #11

• Took out command line tool
• Restructuring docs to incorporate content from README
• Moving dependencies from setup.cfg to setup.py
• Adding some unit tests

Hello,

Would be very useful to have a built in function that returns asymmetric colormaps. Something that would take a min, a max, and a center, and would return a colormap that conforms to that. This would be useful when the aim is for the colormap to be centered about 0.