Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changed datashader default colormap to fit HV defaults #2078

Merged
merged 2 commits into from
Nov 3, 2017
Merged

Conversation

jbednar
Copy link
Member

@jbednar jbednar commented Nov 2, 2017

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:

image

@jlstevens
Copy link
Contributor

jlstevens commented Nov 2, 2017

@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
Copy link
Member Author

jbednar commented Nov 2, 2017

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.

image

@philippjfr
Copy link
Member

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

Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 25, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants