override matplotlib rcParams to give more consistent plots

[eteq]

I've noticed that when I do something in ginga that uses matplotlib, the axes labels are often strange sizes, and in general my plots are hard to see (@ejesche, I think I showed this to you in person last month). I traced this to the fact that ginga is using my ~/.matplotlib/matplotlibrc when making matplotlib plots, which I have set to have bigger labels in general. But that's not good for ginga.

So this PR just overrides whatever the user's matplotlibrc file might say, and instead uses the defaults built-in to matplotlib. Now the plots look much more reasonable and fit inside e.g. the plugin window on the standard ginga layout.

There is a possible downside to this (very simple) implementation, though: it means that on-import (at least of the Plot modules), ginga will silently override anyone's matplotlibrc. This means that if they just import ginga for some other reason (e.g. just to have a ginga window), they might unexpectedly see their matplotlibrc file ignored. I can think of a variety of possible solutions for this, but I figured I should see what @ejesche thinks about this first.

[ejeschke]

Hmm..I think that having the user's matplotlibrc silently overridden by importing ginga is destined to confuse and confound users.

As an experiment, what happens if you add your code fragment:

import matplotlib
matplotlib.rcParams.update(matplotlib.rcParamsDefault)

to the top of the pre_gui_config() function in your .ginga/ginga_config.py. Does it then fix the settings for all matplotlib plots everywhere in the program? This way at least the user has control over it.

If this works, then another possibility would be to add this to the ginga startup preamble as the default, with an option to let the user override it.

[eteq]

Yep, your suggestion in pre_gui_config does indeed do the trick @ejeschke. But I like your second suggestion better - to have it default to overriding the config, but have an option to turn it off. I also think it would be better to have it only do this when you're launching the ginga application, rather than when it's in "interactive" mode (ipg and such), as the interactive mode is much more likely to involve the user making their own separate plots.

An slightly more involved (but less heavy-handed) approach might be to wrap all of ginga's matplotlib plotting commands in the rc context. E.g.

with matplotlib.rc_context(**matplotlib.rcParamsDefault):
    ... ginga plotting ...

This would be a pain of there are a lot of plotting commands, but if there's just a few places this is necessary, it might be a good option. I can replace this PR with one doing that if you can point me to where the key places are.

[pllim]

I come across this outstanding issue. If it still applies...

As a user who does not care where my matplotlib settings are but it is working fine, I am against anything that overrides my matplotlib settings without my consent. So I prefer not overriding by default. Also, even if override happens, I want a way to revert it to pre-Ginga settings.

[ejeschke]

Hmm. Ginga is already overriding some (but not very many) matplotlib rc params settings. I think I agree with @eteq here that having the user's settings be used by default may cause the plots to look very strange or possibly even unusable under ginga. Maybe we can simply make a general.cfg setting (something like override_matplotlibrc) indicating whether to override or not and the default would be True, so the user could turn it off if desired.

Glue must have to deal with this same issue, I would assume. I'll see if I can figure out how they handle that.

[ejeschke]

We don't have a lot of cases of customized .matplolibrc where ginga has been used here at Subaru, so this issue hasn't been much on my radar. Is it still the case that plots look off, @eteq?

@pllim, I am noticing that the recent change to use tight_layout() is breaking some plots for us under gtk, which makes me worry that under some conditions the same thing may happen under qt. The error I get is something like "Falling back to XXXAgg rendering", with a failure to plot.

[pllim]

@ejeschke ... 😱 Ops! If we go ahead with this solution instead, then maybe we can undo #253?

[ejeschke]

That might be a a good idea, but I'd like to understand the failure first. The tight layout does improve the look of things. I need to be able to consistently reproduce the error under gtk, and right now it only happens sporadically so I have a local branch that disables the tight layout.

[ejeschke]

Here's the error I'm getting:

2015-12-29 11:38:31,948 | W | tight_layout.py:225 (get_renderer) | /usr/lib/pymodules/python2.7/matplotlib/tight_layout.py:225: UserWarning: tight_layout : falling back to Agg renderer
  warnings.warn("tight_layout : falling back to Agg renderer")

[ejeschke]

Oh, and I don't see this under python 3, FWIW

[ejeschke]

This is fixed under commit a0b1366. Unfortunately this does revert your #253 PR @pllim. However on the bright side the tight_layout() is done in a cleaner way in one place. And this fixes the Pick layout as well.

I found this matplotlib issue very helpful in diagnosing and fixing the problem.

[pllim]

No problem, @ejeschke ! I'll double check if this works on my end when I get the chance. Thank you!

[pllim]

@ejeschke , the plots look good to me! 👍

[pllim]

This PR is now 5 years old and can apply for kindergarten education. Is this still relevant? If so, please rebase. Else, please close. Thanks!