Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

DOC/API : color map change documentation #4238

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

Merged
merged 2 commits into from
Mar 18, 2015
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
133 changes: 133 additions & 0 deletions 133 doc/devel/color_changes.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,133 @@
.. _color_changes:

*********************
Default Color changes
*********************

As discussed at length elsewhere [insert links], ``jet`` is an
empirically bad color map and should not be the default color map.
Due to the position that changing the appearance of the plot breaks
backward compatibility, this change has been put off for far longer
than it should have been. In addition to changing the default color
map we plan to take the chance to change the default color-cycle on
plots and to adopt a different color map for filled plots (``imshow``,
``pcolor``, ``contourf``, etc) and for scatter like plots.


Default Heat Map Colormap
-------------------------

The choice of a new color map is fertile ground to bike-shedding ("No,
it should be _this_ color") so we have a proposed set criteria (via
Nathaniel Smith) to evaluate proposed color maps.

- it should be a sequential colormap, because diverging colormaps are
really misleading unless you know where the "center" of the data is,
and for a default colormap we generally won't.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imho for signed data, a diverging colormap centered at 0 is a good default choice. But I understand that behavior might be too magical for some.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for me, it ain't just about the 0, but also the data around 0. I have in some of my plots for simplicity sake forced the colormap to go between -A and +A where A = np.max(np.abs(data)), but then if the data say goes from -10 to +100, then it comes a bit more complicated so as to avoid the -10 looking quite faint...

This, I think, comes under the realm of the Normalize class, perhaps we need a few more normalisation classes and think about which one to use as default...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is #3858 which adds a normalizer for dealing with that situation.

Picking anything about the diverging color map (if to use it, where to center it, if the upper/lower limits should be symmetric) requires knowing something about the meaning of the data which is a business mpl should not be in (as it is too widely used). This sort of domain-specific defaults should be the job of down-stream packages (ex scikit-image, pandas, seaborn, ...)


- it should be perceptually uniform, i.e., human subjective judgments
of how far apart nearby colors are should correspond as linearly as
possible to the difference between the numerical values they
represent, at least locally.

- it should have a perceptually uniform luminance ramp, i.e. if you
convert to greyscale it should still be uniform. This is useful both
in practical terms (greyscale printers are still a thing!) and
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes! Particularly in dead tree publications!

because luminance is a very strong and natural cue to magnitude.

- it should also have some kind of variation in hue, because hue
variation is a really helpful additional cue to perception, having
two cues is better than one, and there's no reason not to do it.

- the hue variation should be chosen to produce reasonable results
even for viewers with the more common types of
colorblindness. (Which rules out things like red-to-green.)

- For bonus points, it would be nice to choose a hue ramp that still
works if you throw away the luminance variation, because then we
could use the version with varying luminance for 2d plots, and the
version with just hue variation for 3d plots. (In 3d plots you
really want to reserve the luminance channel for lighting/shading,
because your brain is *really* good at extracting 3d shape from
luminance variation. If the 3d surface itself has massively varying
luminance then this screws up the ability to see shape.)

- Not infringe any existing IP

Example script
++++++++++++++

Proposed Colormaps
++++++++++++++++++

Default Scatter Colormap
------------------------

For heat-map like applications it can be desirable to cover as much of
the luminence scale as possible, however when color mapping markers,
having markers too close to white can be a problem. For that reason
we propose using a different (but maybe related) color map to the
heat map for marker-based. The design parameters are the same as
above, only with a more limited luminence variation.


Example script
++++++++++++++
::
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe use the plot directive here so we display the result?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was the plan eventually. The goal is to get a gallery of this script run on all of the proposed color maps.

import numpy as np
import matplotlib.pyplot as plt

np.random.seed(1234)

fig, (ax1, ax2) = plt.subplots(1, 2)

N = 50
x = np.random.rand(N)
y = np.random.rand(N)
colors = np.random.rand(N)
area = np.pi * (15 * np.random.rand(N))**2 # 0 to 15 point radiuses

ax1.scatter(x, y, s=area, c=colors, alpha=0.5)


X,Y = np.meshgrid(np.arange(0, 2*np.pi, .2),
np.arange(0, 2*np.pi, .2))
U = np.cos(X)
V = np.sin(Y)
Q = ax2.quiver(X, Y, U, V, units='width')
qd = np.random.rand(np.prod(X.shape))
Q.set_array(qd)

Proposed Colormaps
++++++++++++++++++

Color Cycle / Qualitative color map
-----------------------------------

When plotting lines it is frequently desirable to plot multiple lines
or artists which need to be distinguishable, but there is no inherent
ordering.


Example script
++++++++++++++
::
import numpy as np
import matplotlib.pyplot as plt

fig, (ax1, ax2) = plt.subplots(1, 2)

x = np.linspace(0, 1, 10)

for j in range(10):
ax1.plot(x, x * j)


th = np.linspace(0, 2*np.pi, 1024)
for j in np.linspace(0, np.pi, 10):
ax2.plot(th, np.sin(th + j))

ax2.set_xlim(0, 2*np.pi)

Proposed Color cycle
++++++++++++++++++++
1 change: 1 addition & 0 deletions 1 doc/devel/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -21,3 +21,4 @@ The Matplotlib Developers' Guide
release_guide.rst
transformations.rst
add_new_projection.rst
color_changes
Morty Proxy This is a proxified and sanitized view of the page, visit original site.