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

Conversation

Projects
None yet
3 participants
@jbednar
Member

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

@jbednar jbednar requested a review from philippjfr Nov 2, 2017

@jlstevens

This comment has been minimized.

Member

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

This comment has been minimized.

Member

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

This comment has been minimized.

Member

philippjfr commented Nov 3, 2017

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

@philippjfr philippjfr merged commit 718cb41 into master Nov 3, 2017

3 of 4 checks passed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
coverage/coveralls First build on ds_cmap at 81.07%
Details
s3-reference-data-cache Test data is cached.
Details

@jbednar jbednar deleted the ds_cmap branch Nov 3, 2017

@pyup-bot pyup-bot referenced this pull request Nov 3, 2017

Closed

Update holoviews to 1.9.0 #104

@pyup-bot pyup-bot referenced this pull request Nov 13, 2017

Closed

Update holoviews to 1.9.1 #120

@pyup-bot pyup-bot referenced this pull request Dec 12, 2017

Merged

Update holoviews to 1.9.2 #139

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment