matplotlib-users Mailing List for matplotlib

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
>