matplotlib-users Mailing List for matplotlib (Page 2)

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 <ald...@he...
> 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 standard color values 'b', 'y', 'k', etc so
> that I can make a plot figure with a black background using the same
> script as one for the normal white background.
>
> A spent a little while googling and didn't find anything apart from
> specifically setting different colors for every single plot element.
> This would be tiresome.
>
> Thanks in advance for any help,
> Tom
>
>
Hi Tom,

You can create a custom matplotlibrc file [1] and use that for your plots.
The settings you'd probably want to change are copied below. Note that not
all plotting elements grab colors from rc parameters (unfortunately), so
you may find that some functions will ignore these settings.

I think the simplest way (currently) to use the rc file is by putting it in
the same directory as your plotting script (or wherever you're executing
your script). There's a pending pull request [2] that adds the ability to
load rc parameters from a file. Also, I maintain a small set of matplotlib
convenience functions, including a stylesheet-like function. I added the rc
parameters below as a new style and added an example to the documentation
[3].

Hope that helps,
-Tony

[1] http://matplotlib.sourceforge.net/users/customizing.html
[2] https://github.com/matplotlib/matplotlib/pull/861
[3]
http://tonysyu.github.com/mpltools/auto_examples/style/plot_dark_background.html

# rc definitions for dark backgrounds

lines.color: white
patch.edgecolor: white

text.color: white

axes.facecolor: black
axes.edgecolor: white
axes.labelcolor: white

xtick.color: white
ytick.color: white

grid.color: white

figure.facecolor: black
figure.edgecolor: black

savefig.facecolor: black
savefig.edgecolor: black

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 plot figure with a black background using the same
script as one for the normal white background.

A spent a little while googling and didn't find anything apart from
specifically setting different colors for every single plot element.
This would be tiresome.

Thanks in advance for any help,
Tom

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() from ipython it works.

Basically I want to preserve the maplotlib+ipython interactive workflow,
but using some "enhanced" figures (i.e. mpl figure+qt4 widgets).

Thank you for any suggestion.
Antonio



2012/5/24 AI <tri...@gm...>

> Hi,
>
> I want to add a QT4 widget to a matplotlib figure, but the widget does not
> react to user input.
>
> Here it is a test case:
>
> from PyQt4 import QtGui, QtCore
> from pylab import *
>
> def test():
>     plot([1,2,3], lw=2)
>     qt4_interface(gcf())
>
> class qt4_interface:
>     def __init__(self,fig):
>         QMainWin = fig.canvas.parent()
>         toolbar = QtGui.QToolBar(QMainWin)
>         QMainWin.addToolBar(QtCore.Qt.BottomToolBarArea, toolbar)
>
>         self.line_edit = QtGui.QLineEdit(parent=toolbar)
>         self.line_edit.editingFinished.connect(self.do_something)
>         toolbar.addWidget(self.line_edit)
>
>     def do_something(self, *args):
>         f = open('l','a'); f.write('yes\n'); f.flush(); f.close()
>         #close()
>
> I run the script as "run -i qt4_test.py" from ipython. Then running test()
> I get the figure with the additional widget but the do_something method is
> never called.
>
> Incidentally if I do a plot from ipython and then I type interactively
> qt4_interface(gcf()), the qt4 widget is added to the figure and works
> properly.
>
> Any hints on how can I resolve this problem?
>
> BTW, I'm running matplotlib official package (1.0.1) included in ubuntu
> 11.10.
>
> Thanks,
> Antonio
>
>
>
>

I am a matplotlib noob, but I have searched the documentation, lists etc 
and cannot find a simple way to stop a curve being drawn once it crosses 
another curve. In the attached example, I am trying to draw the solid 
curve only until it intersects the dashed one. I have tried using the 
numpy.where() method, but it does not seem to be the right way to go 
about it- I end up having to write FOR loops and so on, and that does 
not make use of the vectorization advantages of numpy. Seems like there 
ought to be a simple way to do this.

Gordon

mport numpy as np
import matplotlib.pyplot as plt

def ig_CRM(vg,V,L,Ts):
     return ((Ts*vg/(2*L))*(1-(vg/V)))

def ig_CCM(vg,V,L,Ts,d):
     return (Ts*vg*d**2/(2*L))/(1-vg/V)

L= 110*10**-6
Ts= 10**-5
V= 400

vg= np.arange(0.0,400.0,1.0)
ig_bdry= ig_CRM(vg,V,L,Ts)
plt.plot(vg,ig_bdry,'--')
ig_d2=ig_CCM(vg,V,L,Ts,0.2)
plt.plot(vg,ig_d2)
plt.axis([0, 400, 0, 20])
plt.show()

> 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' does an
> unsampled rescale of the image (I'm just reading the code comments here).
> Could you check whether changing to `interpolation='nearest'` fixes this
> issue?

Yes, changing it really speeds-up the interactivity! The delay is now
just a few ms, you can notice it's not completely smooth, but
perfectly usable. I'll compare if when zoomed in any
artifacts/distortion appear.

Thank you!

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 that myself some time after reporting this "bug"... Sorry.
The parameter is "axes.color_cycle"

Jerzy K.

On Thursday, May 24, 2012, Jerzy Karczmarczuk wrote:

> Gurus,
>
> Windows XP, matplotlib 1.1.0. Backend Tk, but the same elsewhere.
>
> Programme:
>
> import matplotlib as mpl
> import matplotlib.pyplot as plt
> mpl.rcParams['lines.linewidth'] = 2
> mpl.rcParams['lines.color'] = 'r'
>
> x=range(800)
> y=[t for t in x]
> plt.plot(x,y)
> plt.show()
>
> # ==============================
> Linewidth OK, equal to 2, but the line is still blue. Changing "r" to
> red, or to #ff0000, or (1,0,0) doesn't change anything, still blue.
> Changing directly the matplotlibrc file (default) - the same. Leaving in
> peace the defaults, constructing another rc in the working dir - the
> same. The dictionary rcParams contains the correct value
> 'lines.color': 'r'
> (Anyway, rcsetup.py validation doesn't protest. But then, the modified
> colour is ignored).
>
> Somebody could confirm that?
>
> The best.
>
> Jerzy Karczmarczuk
> Caen, France


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'.

Ben Root

Gurus,

Windows XP, matplotlib 1.1.0. Backend Tk, but the same elsewhere.

Programme:

import matplotlib as mpl
import matplotlib.pyplot as plt
mpl.rcParams['lines.linewidth'] = 2
mpl.rcParams['lines.color'] = 'r'

x=range(800)
y=[t for t in x]
plt.plot(x,y)
plt.show()

# ==============================
Linewidth OK, equal to 2, but the line is still blue. Changing "r" to 
red, or to #ff0000, or (1,0,0) doesn't change anything, still blue. 
Changing directly the matplotlibrc file (default) - the same. Leaving in 
peace the defaults, constructing another rc in the working dir - the 
same. The dictionary rcParams contains the correct value
'lines.color': 'r'
(Anyway, rcsetup.py validation doesn't protest. But then, the modified 
colour is ignored).

Somebody could confirm that?

The best.

Jerzy Karczmarczuk
Caen, France

On Thursday, May 24, 2012, Umut Yildiz wrote:

> Dear All,
>
> I used to use griddata in order to make my contourmaps. However, after I
> updated
> my Python from 2.6 to 2.7 griddata is not working anymore.
>
> I tried some workarounds but no success.
>
> The countourmap that I produced before is here.
> http://dl.dropbox.com/u/17983476/matplotlib/contour_dT_workingbefore.png
>
> After the Python 2.7 update, it turns to the following.
> http://dl.dropbox.com/u/17983476/matplotlib/contour_dT_broken.png
>
> Here is the datafile.
> http://dl.dropbox.com/u/17983476/matplotlib/contour_dT.dat
>
> And the associated python script (which is also below).
> http://dl.dropbox.com/u/17983476/matplotlib/contour_dT.py
>
> The code that I was using before is here. I had to comment out #import
> griddata
> line because this is the only way that it continues. Is this a bug in
> griddata,
> or if there are new workarounds, I would be glad to know a new method to
> produce
> my contourplots again.
>
> Thanks a lot
>
> ----------------------------
> #! /usr/bin python
>
> import os
> import sys
> import math
> from math import *
> from numpy import *
> #import griddata
> from pylab import *
> from matplotlib.ticker import FormatStrFormatter
> params = {'axes.labelsize': 20,
>                'text.fontsize': 15,
>                'legend.fontsize': 14,
>                'xtick.labelsize': 20,
>                'ytick.labelsize': 20,
>                'text.usetex': True }
> rcParams.update(params)
>
> par1 = []
> par2 = []
> chis = []
>
> rfile = file('contour_dT.dat','r')
> line = rfile.readline()
> data = line.split()
>
> while len(data) >1:
>        par1.append(float(data[0]))
>        par2.append(float(data[1]))
>        chis.append(float(data[2]))
>        line = rfile.readline()
>        data = line.split()
>
> par1 = array(par1)
> par2 = array(par2)
> chis = array(chis)
>
> xi = linspace(3.2,7.8,50)
> yi = linspace(15,300,50)
> zi = griddata(par2,par1,chis,xi,yi)
> levels =
> [0.4,0.5,0.6,0.7,0.8,0.9,1.0,1.2,1.5,2,3,4,6,10,12,15,20,25,30,40,50]
> CS = contourf(xi,yi,zi,levels,cmap=cm.jet)
> CS2 = contour(CS, levels=CS.levels[::2],
>                        colors = 'r',
>                        hold='on')
>
> cbar = colorbar(CS)
> cbar.add_lines(CS2)
>
> savefig("contour_dT.png")
> show()
>
>
First, if you were importing griddata before like that, that it is quite
likely that it was some other module that was installed in your
python-2.6/site-packages directory that overrode numpy's griddata. When you
upgraded, that griddata module could not be found in
python-2.7/site-packages. Commenting it out allowed python to find pylab's
griddata.

Second, you really need to clean up your imports. There is no need for the
two math imports, or the numpy import (because the pylab import handles
that).

Oddly, though, your griddata import comes before the pylab import. I would
expect that the pylab griddata would have overridden the first griddata
import. And so there shouldn't have been a difference.

Did you happen to upgrade matplotlib and/or numpy as well?

Ben Root

Dear All,

I used to use griddata in order to make my contourmaps. However, after I updated
my Python from 2.6 to 2.7 griddata is not working anymore.

I tried some workarounds but no success.

The countourmap that I produced before is here.
http://dl.dropbox.com/u/17983476/matplotlib/contour_dT_workingbefore.png

After the Python 2.7 update, it turns to the following.
http://dl.dropbox.com/u/17983476/matplotlib/contour_dT_broken.png

Here is the datafile.
http://dl.dropbox.com/u/17983476/matplotlib/contour_dT.dat

And the associated python script (which is also below).
http://dl.dropbox.com/u/17983476/matplotlib/contour_dT.py

The code that I was using before is here. I had to comment out #import griddata
line because this is the only way that it continues. Is this a bug in griddata,
or if there are new workarounds, I would be glad to know a new method to produce
my contourplots again.

Thanks a lot

----------------------------
#! /usr/bin python

import os
import sys
import math
from math import *
from numpy import *
#import griddata
from pylab import *
from matplotlib.ticker import FormatStrFormatter
params = {'axes.labelsize': 20,
		'text.fontsize': 15,
		'legend.fontsize': 14,
		'xtick.labelsize': 20,
		'ytick.labelsize': 20,
		'text.usetex': True }
rcParams.update(params)

par1 = []
par2 = []
chis = []

rfile = file('contour_dT.dat','r')
line = rfile.readline()
data = line.split()

while len(data) >1:
	par1.append(float(data[0]))
	par2.append(float(data[1]))
	chis.append(float(data[2]))
	line = rfile.readline()
	data = line.split()

par1 = array(par1)
par2 = array(par2)
chis = array(chis)

xi = linspace(3.2,7.8,50)
yi = linspace(15,300,50)
zi = griddata(par2,par1,chis,xi,yi)
levels = [0.4,0.5,0.6,0.7,0.8,0.9,1.0,1.2,1.5,2,3,4,6,10,12,15,20,25,30,40,50]
CS = contourf(xi,yi,zi,levels,cmap=cm.jet)
CS2 = contour(CS, levels=CS.levels[::2],
                        colors = 'r',
                        hold='on')

cbar = colorbar(CS)
cbar.add_lines(CS2)

savefig("contour_dT.png")
show()

Seems like a good idea.  Maybe we gracefully deprecate this?  i.e. warn 
about the confusing usage now, and throw exceptions in a future version?

Mike

On 05/24/2012 10:22 AM, Benjamin Root wrote:
>
>
> On Thu, May 24, 2012 at 10:09 AM, Tony Yu <ts...@gm... 
> <mailto:ts...@gm...>> wrote:
>
>
>
>     On Thu, May 24, 2012 at 9:54 AM, Benjamin Root <ben...@ou...
>     <mailto:ben...@ou...>> wrote:
>
>         Just got bit by this and I thought I'd share to help others.
>
>         I was just quickly writing out some pyplot commands to create
>         two subplots to compare some results.  I did:
>
>         plt.subplots(1, 2, 1)
>         plt.contourf(....)
>         plt.title("Contours")
>         xlim = plt.xlim()
>         ylim = plt.ylim()
>
>         plt.subplots(1, 2, 2)
>         plt.imshow(....)
>         plt.title("Raw Image")
>         plt.xlim(xlim)
>         plt.ylim(ylim)
>
>
>         Did you see the error?  I did "subplots" instead of
>         "subplot".  Since the third argument for plt.subplot is
>         "sharex", a value of 1 or 2 appears perfectly valid to it.
>         Meanwhile, the second call to plt.subplots() throws out my
>         first subplot, and I also get the seemingly odd behavior of
>         the first subplot having the correct x limits, but the default
>         y limits (0, 1).  Of course, this makes sense once you figure
>         out the issue, but it is an extra wrinkle that can be quite
>         confusing.
>
>         I suspect this is a very easy mistake to make.  Should we
>         perhaps test the value of sharex in subplots() and warn if it
>         is anything but a python bool?  Just a thought.
>
>         Cheers!
>         Ben Root
>
>     +1 : I switch `subplots` and `subplot` quite frequently, so a
>     check would be helpful.
>
>     -Tony
>
>
> We could also do a check in the reverse case... if plt.subplot(1, 2, 
> True) is done, that should either raise an error or at least warn 
> (currently, it treats True as the first subplot and False as some 
> (probably non-existant) subplot).
>
> I will write up a PR for this.
>
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Thu, May 24, 2012 at 10:09 AM, Tony Yu <ts...@gm...> wrote:

>
>
> On Thu, May 24, 2012 at 9:54 AM, Benjamin Root <ben...@ou...> wrote:
>
>> Just got bit by this and I thought I'd share to help others.
>>
>> I was just quickly writing out some pyplot commands to create two
>> subplots to compare some results.  I did:
>>
>> plt.subplots(1, 2, 1)
>> plt.contourf(....)
>> plt.title("Contours")
>> xlim = plt.xlim()
>> ylim = plt.ylim()
>>
>> plt.subplots(1, 2, 2)
>> plt.imshow(....)
>> plt.title("Raw Image")
>> plt.xlim(xlim)
>> plt.ylim(ylim)
>>
>>
>> Did you see the error?  I did "subplots" instead of "subplot".  Since the
>> third argument for plt.subplot is "sharex", a value of 1 or 2 appears
>> perfectly valid to it. Meanwhile, the second call to plt.subplots() throws
>> out my first subplot, and I also get the seemingly odd behavior of the
>> first subplot having the correct x limits, but the default y limits (0,
>> 1).  Of course, this makes sense once you figure out the issue, but it is
>> an extra wrinkle that can be quite confusing.
>>
>> I suspect this is a very easy mistake to make.  Should we perhaps test
>> the value of sharex in subplots() and warn if it is anything but a python
>> bool?  Just a thought.
>>
>> Cheers!
>> Ben Root
>>
>>
> +1 : I switch `subplots` and `subplot` quite frequently, so a check would
> be helpful.
>
> -Tony
>

We could also do a check in the reverse case... if plt.subplot(1, 2, True)
is done, that should either raise an error or at least warn (currently, it
treats True as the first subplot and False as some (probably non-existant)
subplot).

I will write up a PR for this.

Ben Root

On Thu, May 24, 2012 at 9:54 AM, Benjamin Root <ben...@ou...> wrote:

> Just got bit by this and I thought I'd share to help others.
>
> I was just quickly writing out some pyplot commands to create two subplots
> to compare some results.  I did:
>
> plt.subplots(1, 2, 1)
> plt.contourf(....)
> plt.title("Contours")
> xlim = plt.xlim()
> ylim = plt.ylim()
>
> plt.subplots(1, 2, 2)
> plt.imshow(....)
> plt.title("Raw Image")
> plt.xlim(xlim)
> plt.ylim(ylim)
>
>
> Did you see the error?  I did "subplots" instead of "subplot".  Since the
> third argument for plt.subplot is "sharex", a value of 1 or 2 appears
> perfectly valid to it. Meanwhile, the second call to plt.subplots() throws
> out my first subplot, and I also get the seemingly odd behavior of the
> first subplot having the correct x limits, but the default y limits (0,
> 1).  Of course, this makes sense once you figure out the issue, but it is
> an extra wrinkle that can be quite confusing.
>
> I suspect this is a very easy mistake to make.  Should we perhaps test the
> value of sharex in subplots() and warn if it is anything but a python
> bool?  Just a thought.
>
> Cheers!
> Ben Root
>
>
+1 : I switch `subplots` and `subplot` quite frequently, so a check would
be helpful.

-Tony

On Thu, May 24, 2012 at 9:14 AM, Sergi Pons Freixes
<spo...@gm...>wrote:

> On Wed, May 23, 2012 at 6:27 PM, Tony Yu <ts...@gm...> wrote:
> >
> > I'm not sure what you mean by "normalize the values to an appropriate
> number
> > of bits", but I don't think setting `vmin` or `vmax` will change the data
> > type of the image. So if you have 64-bit floating point images (100+ Mb
> per
> > image), then that's what you're going to be moving/scaling when you pan
> and
> > zoom.
>
> I was just guessing that it is part of the process of converting
> actual data (32 bit floats) to images on the screen (24 bit for RGB
> (32 with transparency) or 8 bit for grayscale).
>
> I tried converting the data to 8 bit, with .astype('uint8'), and it
> keeps being poorly responsive on zooming and panning.
>
>
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' does
an unsampled rescale of the image (I'm just reading the code comments
here). Could you check whether changing to `interpolation='nearest'` fixes
this issue?

-Tony

(Note: copied to stackoverflow)

PS: These different approaches *do* give different qualitative results; for
example, the code snippet below gives a slight moiré pattern, which doesn't
appear when `interpolation='none'`. I *think* that 'none' is roughly the
same as 'nearest' when zooming in (image pixels are larger than screen
pixels) but gives a higher-order interpolation result when zooming out
(image pixels smaller than screen pixels). I think the delay comes from
some extra Matplotlib/Python calculations needed for the rescaling.

#~~~
import matplotlib.pyplot as plt
import numpy as np

img = np.random.uniform(0, 255, size=(2000, 2000)).astype(np.uint8)

plt.imshow(img, interpolation='nearest')
plt.show()

Just got bit by this and I thought I'd share to help others.

I was just quickly writing out some pyplot commands to create two subplots
to compare some results.  I did:

plt.subplots(1, 2, 1)
plt.contourf(....)
plt.title("Contours")
xlim = plt.xlim()
ylim = plt.ylim()

plt.subplots(1, 2, 2)
plt.imshow(....)
plt.title("Raw Image")
plt.xlim(xlim)
plt.ylim(ylim)


Did you see the error?  I did "subplots" instead of "subplot".  Since the
third argument for plt.subplot is "sharex", a value of 1 or 2 appears
perfectly valid to it. Meanwhile, the second call to plt.subplots() throws
out my first subplot, and I also get the seemingly odd behavior of the
first subplot having the correct x limits, but the default y limits (0,
1).  Of course, this makes sense once you figure out the issue, but it is
an extra wrinkle that can be quite confusing.

I suspect this is a very easy mistake to make.  Should we perhaps test the
value of sharex in subplots() and warn if it is anything but a python
bool?  Just a thought.

Cheers!
Ben Root

  martedì 22 maggio 2012, 18:33, Kevin Davies:

> Hi Giovanni,
> Do the labels still overlap to the same extent?  As far is the Sankey 
> code is concerned, the "center" is the center of the rectangle from 
> which the paths diverge.  That isn't necessarily the center of the 
> bounding box that encloses the entire Sankey subdiagram.  In this
> case, those "centers" are very different because the outflows diverge
> quite a bit, but the inflow doesn't diverge at all.  Does that
> explain what you are seeing?

  No, the labels are translated to the left (so approaching to the
center of the patch), but the rest of the layout it's getting worse.

> If you want to investigate further, you could turn on a debug routine
> by uncommenting a section of code that should be marked in the Sankey 
> class.  That routine will display the base points of each path.

  i can't live without patchlabel, so i've no interest in investigating
further (and probably neither the programming skill). Anyway i think
that a solution will be to calculate the centroid of the patch and use
it as a center for the label.

Thanks for explaining and four your hints!

G.

On Wed, May 23, 2012 at 6:27 PM, Tony Yu <ts...@gm...> wrote:
>
> I'm not sure what you mean by "normalize the values to an appropriate number
> of bits", but I don't think setting `vmin` or `vmax` will change the data
> type of the image. So if you have 64-bit floating point images (100+ Mb per
> image), then that's what you're going to be moving/scaling when you pan and
> zoom.

I was just guessing that it is part of the process of converting
actual data (32 bit floats) to images on the screen (24 bit for RGB
(32 with transparency) or 8 bit for grayscale).

I tried converting the data to 8 bit, with .astype('uint8'), and it
keeps being poorly responsive on zooming and panning.

http://paulaslominska.cba.pl/lnjysgcpta/395506.html

On Wednesday, May 23, 2012, Gökhan Sever wrote:

>
> On Wed, May 23, 2012 at 8:32 AM, Chao YUE <cha...@gm...<javascript:_e({}, 'cvml', 'cha...@gm...');>
> > wrote:
>
>> Dear all,
>>
>> I have two different monitors. How can I use plot command within terminal
>> in this monitor and set the figure to show defaultly in another one?
>>
>> thanks,
>>
>> Chao
>
>
> Hello,
>
> I have a similar question posted on SO ->
> http://stackoverflow.com/questions/7802366/matplotlib-window-layout-questions
>
> With few extra commands you can get your figures appearing on your second
> monitor. However, SetPosition behavior is somewhat unpredictable. When I
> pass a large x value it tendsmove the figure to my second monitor. What
> would be nice is to mpl to remember the last window position and size --say
> for instance for particular plots I always want to view figures in
> maximized window and placed on the second monitor.
>
>
>

This is more an issue with how the GUI toolkit interacts with the desktop
manager. I think there are some existing PRs (or at least wishlist items)
for supplying additional data down to the figure object. The person who did
that feature was then going to set a windowing rule of some sort for his
window manager to handle mpl figures specially.

As far as I know, the feature never got added. Maybe someone else could
resurrect that work?

Cheers!
Ben Root

>

On Mon, May 21, 2012 at 4:01 PM, Andreas Mueller
<amu...@ai...>wrote:

> **
> Hi everybody.
> I have been trying to turn off xticks and yticks and their labels in
> matplotlibrc.
> Ticks<http://matplotlib.sourceforge.net/api/axis_api.html#matplotlib.axis.Tick>have an argument "tick1On" and "label1On" but it seems I can not use these
> in the config file. Is that correct?
> Is there any other way to turn of ticks by default?
>
> Thanks,
> Andy
>
> Hi Andy,

I don't think there are any rc parameters for controlling this, but you can
call `plt.axis('off')` or `ax.set_axis_off()`. I know that's not what you
were looking for, but I thought I'd mention it.

Best,
-Tony

On Wed, May 23, 2012 at 9:04 AM, Sergi Pons Freixes
<spo...@gm...>wrote:

> On Wed, May 23, 2012 at 11:00 AM, Guillaume Gay
> <gui...@mi...> wrote:
> > Hello
> >
> >
> > What is the size of a single image file? If they are very big, it is
> > better to do everything from processing to ploting at once for each file.
>
> As stated below, each image is single-channel, of 4600x3840 pixels. As
> you can see on the code, there is not much processing, just loading
> the images and plotting them. What it's slow is not the execution of
> the code, is the interactive zooming and panning once the plots "are
> in the screen".
>
> >> It's 15 images, single-channel, of 4600x3840 pixels each.
> > This is a lot of data.  8bit or 16bit ?
>
> They are floating point values (for example, from 0 to 45.xxx). If I
> understood correctly, setting the vmin and vmax, matplotlib should
> normalize the values to an appropriate number of bits.
>
>
I'm not sure what you mean by "normalize the values to an appropriate
number of bits", but I don't think setting `vmin` or `vmax` will change the
data type of the image. So if you have 64-bit floating point images (100+
Mb per image), then that's what you're going to be moving/scaling when you
pan and zoom.

-Tony

Hi Mike,

About this question: TypeError: coercing to Unicode: need string or buffer,
dict found

The version of matplotlib that i'm using is matplotlib-0.99.1-py2.6

And how do I remove the font cache in ~ / .matplotlib / fontList.cache

My Operating System is Windows.

Thanks,

On Wed, May 23, 2012 at 11:15 AM, <
mat...@li...> wrote:

> Send Matplotlib-users mailing list submissions to
>        mat...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> or, via email, send a message with subject or body 'help' to
>        mat...@li...
>
> You can reach the person managing the list at
>        mat...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Matplotlib-users digest..."
>
>
> Today's Topics:
>
>   1. Re: Difference in show and output file (rajtendulkar)
>   2. TypeError: coercing to Unicode: need string or    buffer, dict
>      found (Wal?ria Antunes David)
>   3. Re: TypeError: coercing to Unicode: need string or buffer,
>      dict found (Michael Droettboom)
>   4. Re: barchart errorbars always in both directions (Benjamin Root)
>   5. Re: Slow imshow when zooming or panning with several synced
>      subplots (Sergi Pons Freixes)
>   6. Re: barchart errorbars always in both directions
>      (Meesters, Aesku.Kipp Institute)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 23 May 2012 02:49:05 -0700 (PDT)
> From: rajtendulkar <pra...@gm...>
> Subject: Re: [Matplotlib-users] Difference in show and output file
> To: mat...@li...
> Message-ID: <338...@ta...>
> Content-Type: text/plain; charset=us-ascii
>
>
> Just in case, if anyone needs the answer, I figured it out.
> I used the transData transform in order to draw the lines correctly.
>
> Here is the code -
>
> # The code below is to add the lines near the tick labels
> fig = barGraph.fig
> xAxisLim=barGraph.ax.xaxis.get_view_interval()
> tickLocArray = barGraph.ax.xaxis.get_majorticklocs()
> yStart=-70
> yEnd=-0.5
> line = Line2D([xAxisLim[0], xAxisLim[0]],
>              [yStart,yEnd],linewidth=2, color='black',
>               transform=barGraph.ax.transData)
>
> fig.lines.append(line)
>
> for i in xrange(11):
>    lnWidth=2
>    yStartOffset=0
>    if((i+1)%4 != 0):
>        lnWidth=1
>        yStartOffset=20
>    xOffset = tickLocArray[i] + (tickLocArray[i+1] - tickLocArray[i])/2
>    line = Line2D([xOffset, xOffset],
>              [yStart+yStartOffset,yEnd],linewidth=lnWidth, color='black',
>               transform=barGraph.ax.transData)
>    fig.lines.append(line)
>
>
> line = Line2D([xAxisLim[1], xAxisLim[1]],
>              [yStart,yEnd],linewidth=2, color='black',
>               transform=barGraph.ax.transData)
>
> fig.lines.append(line)
>
> plt.figtext(0.247, 0.05, '1')
> plt.figtext(0.523, 0.05, '2')
> plt.figtext(0.797, 0.05, '4')
>
>
> Thank You!
> Raj
>
>
> rajtendulkar wrote:
> >
> > Dear All,
> >
> > I am trying to write a program in matplotlib to generate stacked bar
> > graphs.
> > My problem is that the commands -  plt.show() and
> > self.fig.savefig(fileName) generate different outputs.
> > I tried different output formats like PDF, PNG, EPS. But the problem
> > remains the same.
> > This happens for the lines that I am trying to draw outside the plot.
> > I am trying to draw vertical lines between xticklabels.
> > I have uploaded the data file and the code file.
> >  http://old.nabble.com/file/p33893817/data.dat data.dat
> >  http://old.nabble.com/file/p33893817/matplot1.py matplot1.py
> > Could anyone explain how to resolve this problem?
> >
> > Thank You,
> > Raj
> >
>
> --
> View this message in context:
> http://old.nabble.com/Difference-in-show-and-output-file-tp33893817p33894599.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 23 May 2012 09:16:09 -0300
> From: Wal?ria Antunes David <wal...@gm...>
> Subject: [Matplotlib-users] TypeError: coercing to Unicode: need
>        string or       buffer, dict found
> To: Matplotlib Users <mat...@li...>
> Message-ID:
>        <CAEwvc_uK2icxVBzF5Aykka-_Mig4EoCNovgt2jPJHT=XQ...@ma...
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> Anyone know how to solve this error?
>
> Exception Type: TypeError Exception Value: coercing to Unicode: need string
> or buffer, dict found
>
> Can you help me??
>
> See mycode: http://dpaste.com/751460/
>
> And see my Traceback: http://dpaste.com/750773/
>
>
> Thanks,
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 3
> Date: Wed, 23 May 2012 08:29:48 -0400
> From: Michael Droettboom <md...@st...>
> Subject: Re: [Matplotlib-users] TypeError: coercing to Unicode: need
>        string or buffer, dict found
> To: <mat...@li...>
> Message-ID: <4FB...@st...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> It's a long shot, but have you tried removing the font cache in
> ~/.matplotlib/fontList.cache?  What version of matplotlib are you using?
>
> Mike
>
> On 05/23/2012 08:16 AM, Wal?ria Antunes David wrote:
> > Hi,
> >
> > Anyone know how to solve this error?
> >
> > Exception Type: TypeError Exception Value: coercing to Unicode: need
> > string or buffer, dict found
> >
> > Can you help me??
> >
> > See mycode: http://dpaste.com/751460/
> >
> > And see my Traceback: http://dpaste.com/750773/
> >
> >
> > Thanks,
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >
> >
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 4
> Date: Wed, 23 May 2012 08:55:42 -0400
> From: Benjamin Root <ben...@ou...>
> Subject: Re: [Matplotlib-users] barchart errorbars always in both
>        directions
> To: "Meesters, Aesku.Kipp Institute" <mee...@ae...>
> Cc: "mat...@li..."
>        <mat...@li...>
> Message-ID:
>        <CANNq6F=aDP...@ma...
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Wed, May 23, 2012 at 4:03 AM, Meesters, Aesku.Kipp Institute <
> mee...@ae...> wrote:
>
> > Hi,
> >
> > I'm following the example in the gallery to do a barchart plot (see
> > http://matplotlib.sourceforge.net/examples/api/barchart_demo.html ).
> >
> > In contrast to the example I would like to see the error bars only above
> > the bars, so I tried
> >
> > rects2 = ax.bar(ind+width, womenMeans, width, color='y',
> >                yerr=stds, error_kw = {'barsabove': True,
> >                                       'ecolor'   : 'k'}
> >
> > While the 'ecolor' argument gets accepted, 'barsabove' apparently has no
> > effect (error bars still point up and downwards) - yet, no warning /
> > error is triggered. Where is my mistake? Or is this a bug (still using
> > version 1.0.1) with a known work-around?
> >
> > TIA
> > Chris
> >
> >
> Chris,
>
> I don't think "barsabove" does what you want.  By "above", it means that
> the errorbar is plotted in a layer on top of the plotting symbol rather
> than in the layer under it.  Both ends will be plotted.
>
> To get what you want, you might want to try (Note: untested):
>
> rects2 = ax.bar(ind+width, womenMeans, width, color='y',
>               yerr=np.vstack([[0]*len(stds), stds]), error_kw = {'ecolor'
>  : 'k'})
>
> When yerr is a 2xN numpy array, errorbars are plotted at y-yerr[0, :] and
> y+yerr[1,:]. So, np.vstack creates a 2xN array where the first row is all
> zeros and the second row is the stds values.
>
> I hope that works for you!
> Ben Root
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 5
> Date: Wed, 23 May 2012 15:04:21 +0200
> From: Sergi Pons Freixes <spo...@gm...>
> Subject: Re: [Matplotlib-users] Slow imshow when zooming or panning
>        with several synced subplots
> To: mat...@li...
> Message-ID:
>        <CAM...@ma...
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, May 23, 2012 at 11:00 AM, Guillaume Gay
> <gui...@mi...> wrote:
> > Hello
> >
> >
> > What is the size of a single image file? If they are very big, it is
> > better to do everything from processing to ploting at once for each file.
>
> As stated below, each image is single-channel, of 4600x3840 pixels. As
> you can see on the code, there is not much processing, just loading
> the images and plotting them. What it's slow is not the execution of
> the code, is the interactive zooming and panning once the plots "are
> in the screen".
>
> >> It's 15 images, single-channel, of 4600x3840 pixels each.
> > This is a lot of data. ?8bit or 16bit ?
>
> They are floating point values (for example, from 0 to 45.xxx). If I
> understood correctly, setting the vmin and vmax, matplotlib should
> normalize the values to an appropriate number of bits.
>
> >> for f in filelist:
> > everything should happen in this loop
> >
> >> ? ? ?dataset = ncdf.Dataset(os.path.join(sys.argv[1],f), 'r')
> >> ? ? ?data.append(dataset.variables[variable][:])
> > instead of creating this big list, use a temporary array (which will be
> > overwritten)
> >> ? ? ?dataset.close()
> >> ? ? ?dates.append((f.split('_')[2][:-3],f.split('_')[1]))
>
> Why? It's true that this way at the beginning it eats a lot of RAM,
> but then it is released after each pop() (and calculating the maximum
> of all the data without plotting is needed to use the same
> normalization level on all the plots). Anyway, the slowness ocurrs
> during the interaction of the plot, not during the execution of the
> code.
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 23 May 2012 14:14:05 +0000
> From: "Meesters, Aesku.Kipp Institute" <mee...@ae...>
> Subject: Re: [Matplotlib-users] barchart errorbars always in both
>        directions
> To: "ben...@ou..." <ben...@ou...>
> Cc: "mat...@li..."
>        <mat...@li...>
> Message-ID: <1337782494.2773.10.camel@meesters>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks, Ben. This is indeed what I was looking for and gives the desired
> behavior.
>
> Thanks a lot!
> Chris
>
> On Wed, 2012-05-23 at 08:55 -0400, Benjamin Root wrote:
> >
> > On Wed, May 23, 2012 at 4:03 AM, Meesters, Aesku.Kipp Institute
> > <mee...@ae...> wrote:
> >         Hi,
> >
> >         I'm following the example in the gallery to do a barchart plot
> >         (see
> >
> http://matplotlib.sourceforge.net/examples/api/barchart_demo.html ).
> >
> >         In contrast to the example I would like to see the error bars
> >         only above
> >         the bars, so I tried
> >
> >         rects2 = ax.bar(ind+width, womenMeans, width, color='y',
> >                        yerr=stds, error_kw = {'barsabove': True,
> >                                               'ecolor'   : 'k'}
> >
> >         While the 'ecolor' argument gets accepted, 'barsabove'
> >         apparently has no
> >         effect (error bars still point up and downwards) - yet, no
> >         warning /
> >         error is triggered. Where is my mistake? Or is this a bug
> >         (still using
> >         version 1.0.1) with a known work-around?
> >
> >         TIA
> >         Chris
> >
> >
> > Chris,
> >
> > I don't think "barsabove" does what you want.  By "above", it means
> > that the errorbar is plotted in a layer on top of the plotting symbol
> > rather than in the layer under it.  Both ends will be plotted.
> >
> > To get what you want, you might want to try (Note: untested):
> >
> > rects2 = ax.bar(ind+width, womenMeans, width, color='y',
> >                yerr=np.vstack([[0]*len(stds), stds]), error_kw =
> > {'ecolor'   : 'k'})
> >
> > When yerr is a 2xN numpy array, errorbars are plotted at y-yerr[0, :]
> > and y+yerr[1,:]. So, np.vstack creates a 2xN array where the first row
> > is all zeros and the second row is the stds values.
> >
> > I hope that works for you!
> > Ben Root
> >
> >
>
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
> ------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> End of Matplotlib-users Digest, Vol 72, Issue 25
> ************************************************
>

On Wed, May 23, 2012 at 8:32 AM, Chao YUE <cha...@gm...> wrote:

> Dear all,
>
> I have two different monitors. How can I use plot command within terminal
> in this monitor and set the figure to show defaultly in another one?
>
> thanks,
>
> Chao


Hello,

I have a similar question posted on SO ->
http://stackoverflow.com/questions/7802366/matplotlib-window-layout-questions

With few extra commands you can get your figures appearing on your second
monitor. However, SetPosition behavior is somewhat unpredictable. When I
pass a large x value it tendsmove the figure to my second monitor. What
would be nice is to mpl to remember the last window position and size --say
for instance for particular plots I always want to view figures in
maximized window and placed on the second monitor.


-- 
Gökhan

Le 23/05/2012 15:04, Sergi Pons Freixes a écrit :
> On Wed, May 23, 2012 at 11:00 AM, Guillaume Gay
> <gui...@mi...>  wrote:
>> Hello
>>
>>
>> What is the size of a single image file? If they are very big, it is
>> better to do everything from processing to ploting at once for each file.
> As stated below, each image is single-channel, of 4600x3840 pixels. As
> you can see on the code, there is not much processing, just loading
> the images and plotting them. What it's slow is not the execution of
> the code, is the interactive zooming and panning once the plots "are
> in the screen".
>
>>> It's 15 images, single-channel, of 4600x3840 pixels each.
>> This is a lot of data.  8bit or 16bit ?
> They are floating point values (for example, from 0 to 45.xxx). If I
> understood correctly, setting the vmin and vmax, matplotlib should
> normalize the values to an appropriate number of bits.
>
>>> for f in filelist:
>> everything should happen in this loop
>>
>>>       dataset = ncdf.Dataset(os.path.join(sys.argv[1],f), 'r')
>>>       data.append(dataset.variables[variable][:])
>> instead of creating this big list, use a temporary array (which will be
>> overwritten)
>>>       dataset.close()
>>>       dates.append((f.split('_')[2][:-3],f.split('_')[1]))
> Why? It's true that this way at the beginning it eats a lot of RAM,
> but then it is released after each pop()
oh I didn't see the pop()...

So now then I don't know...

Do you have to show them full-scale? Maybe you can just use thumbnails 
of sort?

G.

> (and calculating the maximum
> of all the data without plotting is needed to use the same
> normalization level on all the plots). Anyway, the slowness ocurrs
> during the interaction of the plot, not during the execution of the
> code.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>