Repository navigation
Should imshow display a grid when axes.grid is set in rcParams? #3946
Description
The default style of seaborn sets axes.grid to True in the rc, which is generally useful but (I believe) not so much when just displaying an image with imshow (cf mwaskom/seaborn#401). Perhaps it would be useful to either 1. ignore axes.grid when an Axes object only contains image artists (but we'd need a way to bypass this and force a grid), or 2. have three possible values for axes.grid, "never", "not-over-images" and "always".
Activity
tacaswell commentedon Dec 24, 2014
A major challenge with getting this to work is that the rcparams for the grid are read at
Axes/Axiscreation time (or when you callcla) so you don't know if you will have an image or not.Looking up the default value at creation time is a feature which allows us to have context managers for rcparams.
I suspect getting this to work will require inserting a whole bunch of heuristics at draw time or have
imshowhave side effects other than adding an artist. I am not convinced that it will be worth the added complexity. I would also argue that if those heuristics to get implemented, they should live inseaborn, not in the core library.I see that @mwaskom already covered using a seaborn context manager, mpl also has two context managers for dealing with rcparams (
matplotlib.rc_contextandmatplotlib.style.context).You can just turn the grid off via
ax.grid(False).mwaskom commentedon Dec 24, 2014
But couldn't
imshowjust turn off the grid on the Axes it's plotting onto (perhaps with a kwarg to prevent this if you really want the grid), or do you prefer not to do that kind of manipulation in your plotting functions?tacaswell commentedon Dec 24, 2014
I am wary of putting side effects like that into the plotting functions.
The added complexity (magic global state changes and yet another kwarg on
imshow) do not seem worth the pay off (not needing a call to
ax.grid(False)in the case where you have told the library put grids onyour axes by default).
On Wed Dec 24 2014 at 3:35:39 PM Michael Waskom notifications@github.com
wrote:
anntzer commentedon Dec 25, 2014
I understand (and somewhat approve, too) the dislike for magic here -- I just wanted to mention the issue but please close it if you don't think it's worth it.
WeatherGod commentedon Dec 30, 2014
You have competing settings here. "yes, I want grids", "but, I never want
grids for images", and "j/k, I am a sucker for grids!". Having a keyword
argument to imshow (and don't forget the other image functions!) to
override a side-effect in imshow which overrides a setting in the rcParams
would probably just infuriate users who has that setting there for a reason.
There is definitely something that needs fixing, but I am currently not
clever enough to figure out a way to fix it (or even properly articulate
the requirements for new behavior). Inconsistent evaluation of rcParams is
another problem, but that is tangential to this discussion. I am -1 on this
idea, especially if seaborn has already implemented a workaround to its own
problems (I don't like to razz on seaborn because it does do some awesome
things, but in this case, this is its own mess).
On Thu, Dec 25, 2014 at 3:26 AM, Antony Lee notifications@github.com
wrote:
mwaskom commentedon Dec 30, 2014
Assuming you mean
pcolorandpcolormesh, this is actually an inconsistency in thatpcolorandpcolormeshdon't show a grid with seaborn defaults.?. They're matplotlib's rc parameters and it's a matplotlib function.
mwaskom commentedon Dec 30, 2014
Given that there are a number of
imagespecific rc paramters that control more dramatic departures from typical Axes behavior (likeaspect="equal", the matplotlib default), it seems like the most obvious thing to do would be to add animage.gridrc parameter.WeatherGod commentedon Dec 31, 2014
Actually, I was thinking of figimage() and matshow(), but you are right,
pcolor() and pcolormesh() can be considered image functions as well. Also,
don't forget tripcolor().
There is nothing wrong with our rc parameters or our functions (in this
respect). I said it is seaborn's mess because it is seaborn's objective to
provide its vision of the ideal plotting aesthetics, and it was their
decision to turn on the axes grid by default for their style. I am not
saying whether it is a good idea or not for them to do that, but it is
their responsibility to manage it according to their tastes. If there is
anything that Matplotlib can do to make that management easier, they are
more than welcome to write up a MEP or even submit a PR.
As for the suggestion of an image.grid rc parameter, I might be amendable
to that. I see it as a tri-state parameter, where the default is None,
which would be to defer to the axes.grid parameter. It would need to be
thought out a bit, like which functions are considered image functions, and
what to do when mixing plotting and image functions that have contradicting
settings.
On Tue, Dec 30, 2014 at 5:52 PM, Michael Waskom notifications@github.com
wrote:
mwaskom commentedon Dec 31, 2014
I guess I'll let you answer this one.
WeatherGod commentedon Dec 31, 2014
??? There isn't really any contradiction here. Perhaps it would be clearer if I had said "improved" instead of "fixing"? I tend to see them as the same thing.