Find a solution for bokeh colormaps

[philippjfr]

As part of #1484 I added support for supplying explicit lists of colors as colormaps and selecting some of the inbuilt bokeh palettes as strings. In doing this I discovered that using bokeh palettes is not sufficient, they contain at most 11 colors and do not interpolate between the colors which is not very nice for continuous values. This means for the time being we still rely on the colormaps shipped with matplotlib. I see a number of solutions:

1. Add code to interpolate between colors and generate larger colormaps on the fly, the base colors for each colormap would still have to come from somewhere though.
2. Require colorcet and only offer the colormaps it includes unless matplotlib is installed.
3. Ship a few colormaps ourselves.

[jlstevens]

I've thought a bit about this but haven't come to any firm conclusions. @jbednar What do you think is the best approach?

[jbednar]

Most bokeh palettes contain only a few colors, but bokeh does supply some 256-color palettes along with some functions to generate arbitrarily long palettes. Datashader already interpolates the palettes into a continuous range, and if the code in bokeh for handling palettes does not already include such functionality, I'd argue that the code from datashader should be added to Bokeh in a PR so that Bokeh users can handle more colors easily.

Meanwhile, I don't think this should be the responsibility of HoloViews. I think we can just rely on the four perceptually uniform ones from mpl, which are already provided with Bokeh, plus any from colorcet that are useful, and never show any examples that use a non-uniform colormap. If it turns out we only need "fire", then that can be included directly in HoloViews, but colorcet has no dependencies, so having that as a dependency seems reasonable to me.

[jlstevens]

I suppose we could have a mechanism that warns/excepts when a colormap is used that has a missing dependency (i.e colorcet or matplotlib).

[jbednar]

Sure, though relying on colorcet is trivial, whereas we'd want to avoid ever relying on mpl when mpl is not in use, due to how tricky it is to get its various backends installed.

[jlstevens]

I think we should write our code so that not having colorcet doesn't break holoviews, making it an optional dependency in the strict sense (i.e from the code's perspective) even if we do always include it when installing holoviews core.

[jbednar]

Makes sense, though it would require copying in the definition of fire for it to be valid as a default.