-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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. | ||
|
||
- 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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
++++++++++++++ | ||
:: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe use the plot directive here so we display the result? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
++++++++++++++++++++ |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -21,3 +21,4 @@ The Matplotlib Developers' Guide | |
release_guide.rst | ||
transformations.rst | ||
add_new_projection.rst | ||
color_changes |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...There was a problem hiding this comment.
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, ...)