Resolve #60, #56 - Allow multiple aliases, update colormaps from colorcet.m (second attempt)

[randallpittman]

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
  #

[randallpittman]

After a lot of second-guessing I think I'm going to press the proverbial big red button now. Hopefully no more commits now!

[jbednar]

Thanks for all your hard work here! I'll review it as soon as I get a chance.

[jbednar]

If preserving the ordering requires miracles, then I guess what's sufficient is a script we can paste into this PR with its output, where the script imports the new version here and the latest released version of colorcet and reports whether any floating-point values differ for any previously defined colormap.

[randallpittman]

@jbednar:

If preserving the ordering requires miracles, then I guess what's sufficient is a script we can paste into this PR with its output, where the script imports the new version here and the latest released version of colorcet and reports whether any floating-point values differ for any previously defined colormap.

These scripts and this PR do not modify or replace any existing colormaps. Only new maps were added, as well as some new aliases for existing maps that were found in colorcet.m.

That said, I think I could probably modify CET_merge.py to preserve the previous order. I'll give it a bit of time and get back to you.

EDIT: The original order is dependent on the order returned by os.listdir, as the maps are put into __init__.py by traversing through the folders of CSVs. That said, I think I can hack a workaround to preserve the existing order.

[randallpittman]

@jbednar

I could re-work this so only one short name is kept per map.

Come to think of it, one thing that isn't ideal about the existing implementation the varying filenames for colormap CSV files. They really should all be named with the "descriptor name", e.g. linear_kryw_0-100_c71, as that is the full identity of the colormap.

Again, I'll think about it and get back to you.

[jbednar]

The CSV files really should all be named with the "descriptor name", e.g. linear_kryw_0-100_c71

Agreed. That's the full, canonical name, as far as colorcet is concerned, even if upstream has shifted to a different naming style.

These scripts and this PR do not modify or replace any existing colormaps. Only new maps were added, as well as some new aliases for existing maps that were found in colorcet.m.

Right; just need to demonstrate that equality here in this PR before merging, either by preserving the original ordering (in which case git will be able to diff __init__.py) or by separately pasting an example of comparing before and after numerically.

I think examples/assets/images/named.png needs to be updated, but I couldn't get examples/assets/write_named.py it to run right on my machine. I got these warnings and the maps didn't plot right at all:

To run that file it should be sufficient to do conda install -c pyviz holoviews bokeh selenium ; conda install -c conda-forge firefox geckodriver. It did need updates to match a recent change in Panel, so I added linked_axes=False and balanced the columns of output (since their lengths differed now) and pushed the revised script and its current PNG output to your PR. If the colormap names change, it will still need updating, but I can do that after this PR is merged if it's difficult for you to run the script locally.

BTW, studying named.png, rainbow2 seems visually identical to rainbow, though I can see from the parameters it differs slightly. Unless there is a very strong reason to retain it I'd remove the short name to avoid confusion; people will wonder why there are two nearly identical colormaps for them to choose from. rainbow3 and rainbow4 are clearly distinct, and thus deserve short names.

Overall, I'm not sure it's helpful to include the CET_L3 style names as aliases; they are neither canonical in terms of the underlying algorithm by which they were generated (as names like linear_kryw_0_100_c71 are) nor are they easy to remember and distinguish (as names like "fire" are). So I continue to prefer publishing only one short name per colormap except in some special well-justified cases, and that short name should (in the absence of a strong reason otherwise) should be the name the colormap has always had in colorcet.

[randallpittman]

Oi, this has gotten complicated.

Ok, I think I want to go back to scratch in another PR. I think my approach here has muddied things too much. Here's the new approach I propose:

1. All CETperceptual CSV files be "git mv" renamed to their algorithmic name and merged into a single folder. I made a script that counted 37 of the CET-*.csv files being redundant with the "v1" CSV files. After this, mapping in CET_to_py.py is no longer necessary.
2. I'll rework make_csvs_from_colorcet.m to just generate new CSVs for colormaps we don't already have. These will be named with the algorithmic name found in colorcet.m.
3. Regarding aliases, I think there's an argument to be made for keeping the CET-* names, and that being that these are the shorthand names most used by Peter at colorcet.com in the gallery and user guide. Beyond those, however, I think it's fine to keep just one "colloquial" alias, and make sure it points to the same thing it has always pointed to.

[jbednar]

Ok, I think I want to go back to scratch in another PR. I think my approach here has muddied things too much. Here's the new approach I propose:

Whatever you think is best, since you're doing the work! :-)

All CETperceptual CSV files be "git mv" renamed to their algorithmic name and merged into a single folder. I made a script that counted 37 of the CET-*.csv files being redundant with the "v1" CSV files. After this, mapping in CET_to_py.py is no longer necessary.

That makes sense, and should probably have been done for v2 originally. Alas!

I'll rework make_csvs_from_colorcet.m to just generate new CSVs for colormaps we don't already have. These will be named with the algorithmic name found in colorcet.m.

Ok

Regarding aliases, I think there's an argument to be made for keeping the CET-* names, and that being that these are the shorthand names most used by Peter at colorcet.com in the gallery and user guide. Beyond those, however, I think it's fine to keep just one "colloquial" alias, and make sure it points to the same thing it has always pointed to.

I think that's an argument for documenting that mapping online, so that colorcet users can crossreference with Peter's work. But I'm concerned with the cost to what I think is a larger group of users who just want to use these in Python and aren't concerned with how the maps appear in other docs or in other languages. I'd favor keeping things simple for the casual Python users, while documenting the mapping somewhere (e.g. in a lookup dictionary we publish that translates the CET-* name to the underlying algorithmic name) rather than making the CET names appear everywhere.