On Friday, May 25, 2012, Jerzy Karczmarczuk wrote:
> Tony Yu:
>
> # rc definitions for dark backgrounds
>
> lines.color: white
> patch.edgecolor: white
>
> ...
>
> don't forget to lighten the colours in axes.color_cycle (unless blue on
> black, etc. suits you). This is used by plot and was one o
Tony Yu:
# rc definitions for dark backgrounds
lines.color: white
patch.edgecolor: white
...
don't forget to lighten the colours in axes.color_cycle (unless blue on
black, etc. suits you). This is used by plot and was one of my numerous
mistakes two days ago...
Jerzy Karczmarczuk
On Fri, May 25, 2012 at 4:07 PM, Tom Aldcroft wrote:
> Is there a simple way to essentially invert the default plotting color
> scheme so that the figure background is black and all text, ticks,
> axes, axis labels, etc are white? I think what I want is to redefine
> the RGB definitions of the s
Is there a simple way to essentially invert the default plotting color
scheme so that the figure background is black and all text, ticks,
axes, axis labels, etc are white? I think what I want is to redefine
the RGB definitions of the standard color values 'b', 'y', 'k', etc so
that I can make a pl
Hi,
same problem with ipython 0.12 and matplotlib 1.1.1rc.
To recall, I'm trying to add a QT4 widget to a matplotlib figure (MPL is
using Qt4 as backend). However, in the attached example the widget callback
(or slot) is not called. Oddly, if I add the qt4 widget manually calling
qt4_interface()
> It seems that setting `interpolation='none'` is significantly slower than
> setting it to 'nearest' (or even 'bilinear'). On supported backends (e.g.
> any Agg backend) the code paths for 'none' and 'nearest' are different:
> 'nearest' gets passed to Agg's interpolation routine, whereas 'none' do
I wrote:
mpl.rcParams['lines.color'] = 'r'
...
...the line is still blue.
BR answers:
Plot() doesn't use lines.color. I don't remember the exact name, but
it uses an rcparam for color cycling. Just change make the list of
colors be just 'r'.
[*!#!!%*!!]
Of course I found tha
