matplotlib-users Mailing List for matplotlib

Hello,
I have an issue rendering with basemap on a Debian server using Agg. I have confirmed that matplotlib does render using the following example.
# do this before importing pylab or pyplot
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
fig = plt.figure()
ax = fig.add_subplot(111)
ax.plot([1,2,3])
fig.savefig('test.png')
However, I receive the following results when using basemap
Traceback (most recent call last):
 File "testImageGen.py", line 117, in <module>
 setCommonBaseMapProperties(m)
 File "/home/forecast/sgWaveModel/sgUtil.py", line 34, in setCommonBaseMapProperties
 bmap.drawcoastlines(color=[15./255., 53./255.,73./255.], linewidth=0.15)
 File "/usr/lib/python2.5/site-packages/mpl_toolkits/basemap/__init__.py", line 1479, in drawcoastlines
 self.set_axes_limits(ax=ax)
 File "/usr/lib/python2.5/site-packages/mpl_toolkits/basemap/__init__.py", line 2607, in set_axes_limits
 and not ax.get_autoscalex_on()
AttributeError: 'AxesSubplot' object has no attribute 'get_autoscalex_on'
I am using matplotlib.use('Agg') as the first call in the script. The call to bmpa.drawcoastlines is the first call to basemap I make in my scripts. This works on a system with a windowing toolkit. Any ideas?
- steve

John Hunter wrote:
> On Mon, Jul 12, 2010 at 5:58 PM, João Luís Silva <js...@fc...> wrote:
>> Hi,
>>
>> I've finally created a small script that demonstrates a bug that I've been
>> enduring for a long time. I haven't seen it reported before, so I may be
>> doing something wrong. The bug is as follows: Under certain conditions, in
>> an embedded gtk application, when selecting an area with the "Zoom to
>> rectangle" button from the toolbar the whole graph will jump upward
>> temporarily, corrupting the screen and making it hard to select the proper
>> area. The attached example is an extreme version of this (the effect would
>> be smaller for a reasonably sized combo box).
>>
>> Tested on Linux (Debian Squeeze).
> 
> 
> You have this line:
> 
> from widgets import Widgets
> 
> what is "widgets" ?
> 
> JDH
> 
Sorry, I forgot to delete it. It's just a small helper class I use to 
load files from glade. By the way, I just tested the script on Windows 
(after deleting that line) and it doesn't have the bug (Python 2.5 + mpl 
1.0.0)
JLS

On Mon, Jul 12, 2010 at 5:58 PM, João Luís Silva <js...@fc...> wrote:
> Hi,
>
> I've finally created a small script that demonstrates a bug that I've been
> enduring for a long time. I haven't seen it reported before, so I may be
> doing something wrong. The bug is as follows: Under certain conditions, in
> an embedded gtk application, when selecting an area with the "Zoom to
> rectangle" button from the toolbar the whole graph will jump upward
> temporarily, corrupting the screen and making it hard to select the proper
> area. The attached example is an extreme version of this (the effect would
> be smaller for a reasonably sized combo box).
>
> Tested on Linux (Debian Squeeze).
You have this line:
 from widgets import Widgets
what is "widgets" ?
JDH

On Mon, Jul 12, 2010 at 5:11 PM, Jeffrey Blackburne <je...@mi...> wrote:
> Actually, I have been able to do it like this:
>
> mpl.rcParams['patch.linewidth'] = 0.2
>
> Hope that helps, and sorry I didn't reply sooner.
Of course this will affect any other patches in your figure (eg
Rectangles from histogram plots, etc).
I am not opposed to adding some legend.frame rc parameters. Part of
the purpose of the rc file is to work like a style sheet, so if you
are writing a book or an article with a bunch of figures, and you want
them all the have the same look-and-feel, you can customize the
defaults externally w/o a bunch of boilerplate in your scripts that
can be difficult to maintain. It seems like the legend frame
properties fit into this category. In particular, the frame alpha is
one I almost always set to semi-transparent so you can see data behind
the legend, which is boilerplate I might be happy to do away with if I
had an rc param.
I would be amenable to adding:
 legend.frame.facecolor : 'white'
 legend.frame.edgecolor : 'white'
 legend.frame.linewidth : 1.0
 legend.frame.alpha : 1.0
but I'd like to hear from others (Eric?) who are already not happy
with the size of our rc file. Although this change would increase the
line count, it doesn't increase the complexity much if at all in my
view and is somewhat useful. It would imply some mild potential
breakage, because currently the legend face and edge colors use the
axes colors (which is why it would be nice if we had
containment/inheritance for our rc params so they could inherit from
parent) so if someone has tweaked their old axes.facecolor, they would
need to add legend.frame.facecolor under this change to remain
compatible.
JDH

Hi,
I've finally created a small script that demonstrates a bug that I've 
been enduring for a long time. I haven't seen it reported before, so I 
may be doing something wrong. The bug is as follows: Under certain 
conditions, in an embedded gtk application, when selecting an area with 
the "Zoom to rectangle" button from the toolbar the whole graph will 
jump upward temporarily, corrupting the screen and making it hard to 
select the proper area. The attached example is an extreme version of 
this (the effect would be smaller for a reasonably sized combo box).
Tested on Linux (Debian Squeeze).
Regards,
João Luís Silva

On Jul 12, 2010, at 5:45 PM, Janne Blomqvist wrote:
>>> a.legend()
>>
>> Change this to
>>
>> lg = a.legend()
>> fr = lg.get_frame()
>> fr.set_lw(0.2)
>
> Thanks, this solved it. A bit annoying that it can't be done with rc
> params, but hey, at least it works.
Hi Janne,
Actually, I have been able to do it like this:
mpl.rcParams['patch.linewidth'] = 0.2
Hope that helps, and sorry I didn't reply sooner.
-Jeff

On 2010年07月12日 23:17:19 +0200, John Hunter said:
> On Mon, Jul 12, 2010 at 4:06 PM, K.-Michael Aye 
> <kmi...@gm...> wrote:
>> Dear all,
>> 
>> I'm not sure if this is by design or a problem:
>> 
>> In a pylab session, if I repeatedly call imshow with the same image,
>> memory increases each time.
>> This does not happen if i go the 'Artists' way (fig = .., ax =
>> fig.add---, im = ax.imshow)
>> Is there a way to avoid memory consumption like this in the pylab style?
>> Even a clf() does not release the memory.
>> My config is the latest Enthought distribution in 32-bit mode for MacOS.
>> 
> 
> 
> Can you post a complete free-standing script that we can run which
> exposes the problem? Also please report your version numbers -- we
> could look them up from enthought perhaps but you can help us :-)
Of course, sorry.
But because I don't know how to read out Python's memory consumption 
from within python, these lines should be run successively in Ipython, 
so that one can see, how the 'Real Mem' system indicator grows each 
time.
l = [28.1]
arr = ones((1500,1500,3))
l.append(79.7)
imshow(arr)
l.append(172.0)
imshow(arr)
l.append(249.0))
l.append(249.0)
imshow(arr)
l.append(326.3))
l.append(326.3)
imshow(arr)
l.append(404.4)
imshow(arr)
l.append(482.4)
This was run in an ipython session started with the -pylab flag.
The numbers in the l array are the MBs I read of Mac's Activity Monitor 
for the Python task.
Here is the resulting plot:
http://dl.dropbox.com/u/139035/mem_growth.png
Here's my system info:
Darwin paradigm.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 
18:28:53 PDT 2010; root:xnu-1504年7月4日~1/RELEASE_I386 i386
In [25]: print matplotlib.__version__
-------> print(matplotlib.__version__)
0.99.3
Enthought Python Distribution -- http://code.enthought.com
Python 2.6.5 |EPD 6.2-2 (32-bit)| (r265:79063, May 28 2010, 15:13:03)
my matplotlibrc (some adaptations):
http://dl.dropbox.com/u/139035/matplotlibrc
Hope this is all you need?
BR,
Michael
> 
> http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#troubleshooting
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first

On Sat, Jul 10, 2010 at 18:42, Jouni K. Seppänen <jk...@ik...> wrote:
> Janne Blomqvist <blo...@gm...> writes:
>
>> The problem I'm having is that as the figure is then pretty small, I
>> can scale font sizes, axis sizes, line widths etc., but what I've been
>> unable to figure out is how to scale dashed or dotted lines, as well
>> as the thickness of the legend border box.
>
> It seems that there are no rc settings for these, but you can adjust
> them as follows:
>
>> a.plot(x, y, '--', label='foo bar')
>
> Change this to
>
> a.plot(x, y, '--', label='foo bar', dashes=(2,2))
>
> The value of dashes is the number of points of ink followed by the
> number of points of whitespace. It defaults to (6,6) for the '--'
> linestyle (found in the dashd dictionary of backend_bases.py).
>
>> a.legend()
>
> Change this to
>
> lg = a.legend()
> fr = lg.get_frame()
> fr.set_lw(0.2)
Thanks, this solved it. A bit annoying that it can't be done with rc
params, but hey, at least it works.
-- 
Janne Blomqvist

On Mon, Jul 12, 2010 at 4:06 PM, K.-Michael Aye <kmi...@gm...> wrote:
> Dear all,
>
> I'm not sure if this is by design or a problem:
>
> In a pylab session, if I repeatedly call imshow with the same image,
> memory increases each time.
> This does not happen if i go the 'Artists' way (fig = .., ax =
> fig.add---, im = ax.imshow)
> Is there a way to avoid memory consumption like this in the pylab style?
> Even a clf() does not release the memory.
> My config is the latest Enthought distribution in 32-bit mode for MacOS.
>
Can you post a complete free-standing script that we can run which
exposes the problem? Also please report your version numbers -- we
could look them up from enthought perhaps but you can help us :-)
http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#troubleshooting

Dear all,
I'm not sure if this is by design or a problem:
In a pylab session, if I repeatedly call imshow with the same image, 
memory increases each time.
This does not happen if i go the 'Artists' way (fig = .., ax = 
fig.add---, im = ax.imshow)
Is there a way to avoid memory consumption like this in the pylab style?
Even a clf() does not release the memory.
My config is the latest Enthought distribution in 32-bit mode for MacOS.
BR,
Michael

Hi,
Is there a way to get the current colorbar (or a list of colorbars) for the
current axes and update the mappable property? If an update is not possible,
i would like to replace the current colorbar with a new one.
I've tried something similar to the following:
import pylab as plt
fig = plt.figure()
ax = fig.add_subplot(111)
x = range(10)
y = range(10)
z = range(10)
scatter1 = ax.scatter(x,y,c=z,visible=False)
cbar = fig.colorbar(scatter1)
z = range(10,20)
scatter2 = ax.scatter(x,y,c=range(10,20),visible=True)
cbar.mappable = scatter2
plt.show()
but the colorbar is still on the range 0...9.
Also, is there a way to control the visibility of the colorbar?
Thanks,
Aman

Ah, I misread your original post and thought you were talking about pcolor.
I will take a look at plot_surface and see if there is a possible reason for
your issue. I have an idea of what is happening, but I have to see the code
when I get back to my office tomorrow.
Ben Root
On Sun, Jul 11, 2010 at 8:43 PM, Jeremy Conlin <jlc...@gm...> wrote:
> On Friday, July 9, 2010, Benjamin Root <ben...@ou...> wrote:
> > Jeremy,
> >
> > I believe that 0.99.1 is fairly old. I don't know when Axes3D came
> along, but I am sure you can find it in 0.99.3. It is most definitely in
> 1.0, but you might not need to go that far if your distro does not provide
> it.
>
> Wince my first post, I have upgraded to 1.0 which definitely has
> Axes3D. The trouble is that the plot_surface function does not deal
> with masked arrays like color does. That is what I need and I haven't
> found a way around it.
>
> Jeremy
>

Hello,
I am getting a permission error when trying to open a figure or 
plotting using matplotlib.
	TclError: couldn't open "/Library/Frameworks/Python.framework/ 
Versions/2.6/lib/python2.6/site-packages/matplotlib/mpl-data/images/ 
home.ppm": permission denied
Attached is a test log file.
Isaac Salazar
W-13: ADVANCED ENGINEERING ANALYSIS
TA-03, Building 1400, Room 2229
MS A142
if...@la...
phone: 667 9225

On Sun, Jul 11, 2010 at 12:52 PM, Preben Randhol <ra...@pv...> wrote:
>> If you could create a minimal example starting with
>> embedding_in_gtk3.py that replicates your problem, we're more likely
>> to be able to help.
Thanks for posting the example. This runs fine for me (I can pan,
zoom, zoom to rect, the zoom to rect rubberband is drawn). Here is my
version info; what do you have for same?
 johnh@udesktop191:tmp> uname -a
 SunOS udesktop191 5.10 Generic_139556-08 i86pc i386 i86pc
j ohnh@udesktop191:tmp> python -c 'import gtk; print gtk.pygtk_version'
 (2, 6, 0)
Also, if you know the persion of gtk you are running, that might help.
Finally, you say you are running mpl 1.0, but your traceback says
 "/usr/lib/pymodules/python2.6/matplotlib/backends/backend_gtk.py", line
 606, in idle_draw drawable.draw_image(gc, imageBack, 0, 0, *lastrect)
 TypeError: Gdk.Drawable.draw_image() argument 2 must be gtk.gdk.Image,
 not None
but line 606 in backend_gtk in mpl 1.0.0 is not what this traceback
says. Are you sure you are picking up the right version? I suggest
flushing all your matplotlib* files and dirs in site-packages and
doing a clean install, and then running your test script with
--verbose-debug so we can get a better look at what is happening.
Please post the output which is logged to the terminal.
JDH

On Mon, Jul 12, 2010 at 9:35 AM, Ademir Francisco da Silva
<Ade...@in...> wrote:
> Hello John ...,
>
> I was thinking about our speech by email yesterday and I am not sure that
> the problem is in that unofficial compilation I am really surmising about
> those several changes in Python 2.7, anyway is worthy to verify
> compatibility about matplotlib code( specifically widgets' module, please )
> and the new version of the Python program.
>
> You have asked me about to paste a output from my script of my systems when
> I pass it in the verbose but in this case there no one, what really happend
> is that my code( according my last email ) did not show widgets.Cursor
> anymore and the widgets.Button have appeared but it is completely
> inactivated, I mean it do not do nothing, whether my code is the same what
> is this estrange behavior ???
>
> I know, I know ..., I will wait for the official matplotlib's version for
> win64_Py2.7, but ...
This is not what we recommend. Christoph builds the official win32
binaries for matplotlib and as he said, it is likely that whatever
problems you see now you would see in the official builds. That is
why we want to fix the problem now and not later. And it is why we
have both asked you to post a complete example that we can run that
replicates your problem. And I have asked you to run the code with
--verbose-helpful and post the entire output. You have *described*
what did or would happen but this is not the same as providing us with
the information we requested. There is a lot of output emitted by
verbose-helpful that will aid us in debugging your problem.
In case I am not being clear:
 * write a script that factors out stuff specific you your system
that we can run that exposes the problem. As often as not the bug is
in your code, not matplotlib, and we can't debug your code w/o seeing
it. Nor do we want to wade through 5000 lines of code that is
specific to your problem which we can't run. In the process of
simplifying your example to something that exposes the problem which
we can run, you will often find the problem yourself. A well-written
help query to the mailing list often solves the problem you are trying
to address. "It doesn't work and here is a snippet of my code" rarely
does.
 * run the script as in 'python myscript.py --verbose-helpful'
 * paste the output into the email in which you've attached the code.
Sorry to be blunt but this is the 4th email you have gotten from a
developer trying to help you and we have made no progress.
Finally, please respond to the existing threads rather than starting
new ones on the same subject as it makes it easier for developers who
are following the thread to do so, and it makes it possible for
archival services such as nabble to properly thread the conversation.
JDH

On 2010年7月11日 13:39:05 -1000
Eric Firing <ef...@ha...> wrote:
> On 07/11/2010 07:52 AM, Preben Randhol wrote:
> 
> >>
> >> Also, are you using backend_gtk or backend_gtkagg (and does it
> >> matter for your problem?)
> >
> > I use GTKAgg and it works. GTK doesn't.
> >
> 
> backend_gtk has limitations that backend_gtkagg does not, although I 
> don't know that your zooming problem should be one of them. Are you 
> sure you *need* to use backend_gtk instead of backend_gtkagg?
But I am using gtkagg. I only tested backend_gtk because I was asked
to. gtkagg still has problem with zooming/panning
Preben

Hello everybody,
My question is in the title !
Say that I have the following code:
f = pylab.figure()
f.plot([1,2,3,4,5])
pylab.show()
and that, once I destroyed the figure by clicking on the top-right corner red button, I would like to redisplay it in the state it was just before I closed it. Is there way to do this ? There might be one as the variable f is still assigned as a figure object with all its attributes and methods still available.
Thank you very much
Eric
 

On Friday, July 9, 2010, Benjamin Root <ben...@ou...> wrote:
> Jeremy,
>
> I believe that 0.99.1 is fairly old. I don't know when Axes3D came along, but I am sure you can find it in 0.99.3. It is most definitely in 1.0, but you might not need to go that far if your distro does not provide it.
Wince my first post, I have upgraded to 1.0 which definitely has
Axes3D. The trouble is that the plot_surface function does not deal
with masked arrays like color does. That is what I need and I haven't
found a way around it.
Jeremy