Skip to content

New rcParams requests #5618

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.

Sign up for GitHub

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

Jump to bottom
Closed
notmatthancock opened this issue Dec 4, 2015 · 4 comments
Closed

New rcParams requests #5618

notmatthancock opened this issue Dec 4, 2015 · 4 comments
Milestone
v2.0.0

Comments

@notmatthancock
Copy link
Contributor

Request 1: imshow should have separate rcParams for removing ticks and grid.

The image key should take additional parameters, so that x and y ticks are not present by default, and the grid is not overlaid by default if axes.grid is True. For example image.axis: False would be ideal. To me, it quite reasonable to want axes.grid: True as the default for numerical plots as well a separate default for imshow since they have very different use cases.

Here is an example:

import matplotlib
matplotlib.rcdefaults()
matplotlib.use('qt4agg') # or whatever
matplotlib.rcParams['axes.grid'] = True
matplotlib.rcParams['axes.axisbelow'] = True
matplotlib.rcParams['grid.linestyle'] = '--'
matplotlib.rcParams['grid.color'] = 'red'
matplotlib.rcParams['grid.linewidth'] = 2.0

import matplotlib.pyplot as plt
from numpy import zeros,cos,linspace

x = linspace(0,6.28,100)

fig = plt.figure(figsize=(12,6))

ax1 = fig.add_subplot(121)
ax1.plot(x,cos(x+2*cos(2*x)),lw=3)
ax1.set_title('Ticks and grid are a nice\ndefault for numerical plots.')

ax2 = fig.add_subplot(122)
ax2.imshow(zeros((100,100)), cmap=plt.cm.gray)
ax2.set_title('Ticks and grid are not a nice\ndefault for image plots.')

plt.show()

image-axis

Request 2: Fix inconsistent rcParams behavior with regard to plots that add patches.

Some plots that use patches follow the axes.prop_cycle, while others do not. For example hist obeys both axes.prop_cycle and patch.edgecolor, but ignores patch.facecolor (even if axes.prop_cycle is not set); however, violinplot ignores everything except patch.edgecolor, which is not apparent due to the default alpha setting for violinplot (why is this default??). Here is an example:

import matplotlib
from cycler import cycler

matplotlib.rcdefaults()
matplotlib.use('qt4agg')
matplotlib.rcParams['axes.prop_cycle'] = cycler('color', ['pink','purple','salmon'])
matplotlib.rcParams['patch.facecolor'] = 'pink'
matplotlib.rcParams['patch.edgecolor'] = 'blue'

import matplotlib.pyplot as plt
from numpy.random import randn

fig = plt.figure(figsize=(12,6))

X = randn(100)

ax = fig.add_subplot(121)
for i in range(3):
    ax.hist(X+2*i)

ax = fig.add_subplot(122)
for i in range(3):
    ax.violinplot(X+2*i)

plt.show()

violinplot-color-test
@tacaswell tacaswell added this to the next major release (2.0) milestone Dec 4, 2015
@tacaswell
Copy link
Member

request 1 is a bit tricky, what should it do in the case where you have lines and images? I suggest using the style context manager to control this based on the context you are plotting.

Request 2 is definitely on our radar for the upcoming 2.0 release.

@notmatthancock
Copy link
Contributor Author

request 1 is a bit tricky, what should it do in the case where you have lines and images?

Here's my opinion:

  • Combination image + line plots aren't done nearly as often as image and line plots separately.
  • Combination image + line plots will most likely need additional customization (frame limits, etc...), anyhow, so the default behavior isn't as important here, as it will most likely be overridden.

I think the default behavior for combinations of lines and images would be more-or-less arbitrary. For example, it could just take the default axes.grid behavior if the grid for plotted images followed the axes.axisbelow rule (which it doesn't seem to follow currently).

More importantly, I think the convenience of an image.axis default would outweigh any inconvenience of combination image+lines not behaving as expected.

@efiring
Copy link
Member

efiring commented Dec 4, 2015

I really worry about rcParams getting ever more complicated and convoluted. I do not support request #1.

@tacaswell
Copy link
Member

request 2 will be addressed in 2.0 (see #5674 ) however we will not make rcparams conditional on the type of artists being added to the axes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
v2.0.0
Development

No branches or pull requests
3 participants
@efiring @tacaswell @notmatthancock