Changed datashader default colormap to fit HV defaults

[jbednar]

Currently, holoviews.operation.datashade.shade() and holoviews.operation.datashade.datashade() use a default colormap of fire, originally chosen to match the default Image colormap in HoloViews. This made sense at first, because datashader produces images. However, a datashader plot is rarely a dense image covering every pixel; instead it tends to have many transparent pixels, and is thus much more like a line or points plot in HoloViews. When using datashade() on an hv.Points(), etc. object using the HV/Jupyter/browser default white page background, a fire colormap is inappropriate, because the highest value maps to the page color. This resulted in bits of datashader plots disappearing, which appeared to be a bug in datashader but was simply the result of using a colormap ending in white on a white page. These bits sometimes disappear in the initial rendering, if there happen to be isolated pixels at the highest strength, or more often when zooming in far enough that a single color becomes visible, at which point the entire plot disappears.

This PR selects a colormap designed to be thematically compatible with the HV default blue color for lines and points:

[jlstevens]

@philippjfr @jbednar I'm ok with this as long as you are!

If we merge this PR now, I wouldn't want to change the colormap used here till 2.0. Using ["deepskyblue","black"] fixes the issue Jim described above but it is also a little simplistic, especially when compared to the effort that went into developing the fire colormap for instance!

[jbednar]

The fire colormap is excellent for black backgrounds, but I am not aware of a colormap for white backgrounds that is both perceptually intuitive (where increasing values are interpreted unambiguously by most people), and has high dynamic range. Now reverted to the original default of None, which uses the default Datashader colormap of ["lightblue","darkblue"], which is always ok against a white background, is thematically compatible with HoloViews (though not quite as much as the one above), and also looks ok for points plots (unlike the one above, which had odd color banding and low definition around dark values). Seems like the reasonable default choice, and restores behavior from HV 1.8.0.

[philippjfr]

Okay, these transients are getting out of hand but the push build passed, so I'm merging.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.