Menu
▾
▴
matplotlib-users — Discussion related to using matplotlib
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(12) |
Sep
(12) |
Oct
(56) |
Nov
(65) |
Dec
(37) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(59) |
Feb
(78) |
Mar
(153) |
Apr
(205) |
May
(184) |
Jun
(123) |
Jul
(171) |
Aug
(156) |
Sep
(190) |
Oct
(120) |
Nov
(154) |
Dec
(223) |
| 2005 |
Jan
(184) |
Feb
(267) |
Mar
(214) |
Apr
(286) |
May
(320) |
Jun
(299) |
Jul
(348) |
Aug
(283) |
Sep
(355) |
Oct
(293) |
Nov
(232) |
Dec
(203) |
| 2006 |
Jan
(352) |
Feb
(358) |
Mar
(403) |
Apr
(313) |
May
(165) |
Jun
(281) |
Jul
(316) |
Aug
(228) |
Sep
(279) |
Oct
(243) |
Nov
(315) |
Dec
(345) |
| 2007 |
Jan
(260) |
Feb
(323) |
Mar
(340) |
Apr
(319) |
May
(290) |
Jun
(296) |
Jul
(221) |
Aug
(292) |
Sep
(242) |
Oct
(248) |
Nov
(242) |
Dec
(332) |
| 2008 |
Jan
(312) |
Feb
(359) |
Mar
(454) |
Apr
(287) |
May
(340) |
Jun
(450) |
Jul
(403) |
Aug
(324) |
Sep
(349) |
Oct
(385) |
Nov
(363) |
Dec
(437) |
| 2009 |
Jan
(500) |
Feb
(301) |
Mar
(409) |
Apr
(486) |
May
(545) |
Jun
(391) |
Jul
(518) |
Aug
(497) |
Sep
(492) |
Oct
(429) |
Nov
(357) |
Dec
(310) |
| 2010 |
Jan
(371) |
Feb
(657) |
Mar
(519) |
Apr
(432) |
May
(312) |
Jun
(416) |
Jul
(477) |
Aug
(386) |
Sep
(419) |
Oct
(435) |
Nov
(320) |
Dec
(202) |
| 2011 |
Jan
(321) |
Feb
(413) |
Mar
(299) |
Apr
(215) |
May
(284) |
Jun
(203) |
Jul
(207) |
Aug
(314) |
Sep
(321) |
Oct
(259) |
Nov
(347) |
Dec
(209) |
| 2012 |
Jan
(322) |
Feb
(414) |
Mar
(377) |
Apr
(179) |
May
(173) |
Jun
(234) |
Jul
(295) |
Aug
(239) |
Sep
(276) |
Oct
(355) |
Nov
(144) |
Dec
(108) |
| 2013 |
Jan
(170) |
Feb
(89) |
Mar
(204) |
Apr
(133) |
May
(142) |
Jun
(89) |
Jul
(160) |
Aug
(180) |
Sep
(69) |
Oct
(136) |
Nov
(83) |
Dec
(32) |
| 2014 |
Jan
(71) |
Feb
(90) |
Mar
(161) |
Apr
(117) |
May
(78) |
Jun
(94) |
Jul
(60) |
Aug
(83) |
Sep
(102) |
Oct
(132) |
Nov
(154) |
Dec
(96) |
| 2015 |
Jan
(45) |
Feb
(138) |
Mar
(176) |
Apr
(132) |
May
(119) |
Jun
(124) |
Jul
(77) |
Aug
(31) |
Sep
(34) |
Oct
(22) |
Nov
(23) |
Dec
(9) |
| 2016 |
Jan
(26) |
Feb
(17) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(8) |
Jul
(6) |
Aug
(5) |
Sep
(9) |
Oct
(4) |
Nov
|
Dec
|
| 2017 |
Jan
(5) |
Feb
(7) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(10) |
2
(3) |
|
3
(5) |
4
(7) |
5
(18) |
6
(4) |
7
(15) |
8
(7) |
9
(10) |
|
10
(4) |
11
(18) |
12
(15) |
13
(11) |
14
(11) |
15
(4) |
16
(28) |
|
17
(17) |
18
(22) |
19
(12) |
20
(19) |
21
(17) |
22
(14) |
23
(4) |
|
24
(3) |
25
(6) |
26
(8) |
27
(13) |
28
(11) |
29
(21) |
30
(3) |
|
31
(5) |
|
|
|
|
|
|
|
From: belinda t. <bt...@cs...> - 2006-12-29 21:06:19
|
Hi, I'm using matplotlib w/numerix set to numpy (as described in my prior post). What I am wondering is in what situations one would want to: import pylab import numpy together, because there is matlab-style stuff (e.g. matrices, arrays, cumprod, fft, arange etc.) by importing the pylab package alone. On a related note, in trying to get a better idea of how math vs. plot functionality is handled in matplotlib, I looked at mlab.py and pylab.py; it doesn't seem there is a clear separation of these functions, but perhaps I'm missing something? Thanks! --b |
|
From: Eric F. <ef...@ha...> - 2006-12-29 19:38:13
|
Petr Danecek wrote: > Hello, > first of all: thanks for the great software!! After the years of > struggling with gnuplot, i really enjoy making my graphs with > matplotlib. > > I'd like to ask, if it is possible to create a contour graph using polar > coordinates? If not, can someone give me some pointers about how to > implement it? John has said that he plans to improve polar coordinate handling in the next month or two. If it turns out that changes are also needed in contour.py, I will be happy to make them. So, if all goes well, within a few months we should have contouring and other things working well with polar coordinates. In the meantime, I am glad Jeff has provided a workaround. (I took a stab at making contouring work to a useful degree with present polar coordinates--given that pcolor works, it should be possible--but I couldn't quite get it. Maybe I will try again later.) Eric |
|
From: Eric E. <ems...@ob...> - 2006-12-29 19:35:49
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
sorry for all this. I guess I don't fully understand the bbox thing....<br>
<br>
Anyway it works great except for 2 things:<br>
** now the x,y coordinates in the toolbar are VERY SLOWLY updated... In
fact as the mouse moves, the coordinates do not show up and are only
updated when it is stopped.<br>
** my text does not appear fully (some part is blanked, and changing
the bbox does not seem to do much)<br>
<br>
Eric<br>
<br>
John Hunter wrote:
<blockquote cite="mid...@pe..."
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">"Eric" == Eric Emsellem <a class="moz-txt-link-rfc2396E" href="mailto:ems...@ob..."><ems...@ob...></a> writes:
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->
Eric> great! but one question though: I need to put the text with
Eric> figtext and thus use figure coordinates (instead of pixel
Eric> coord). So how would I replace the :
Eric> matplotlib.transforms.lbwh_to_bbox
It shouldn't matter which way you create the text instance.
JDH
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
====================================================================
Eric Emsellem <a class="moz-txt-link-abbreviated" href="mailto:ems...@ob...">ems...@ob...</a>
Centre de Recherche Astrophysique de Lyon
9 av. Charles-Andre tel: +33 (0)4 78 86 83 84
69561 Saint-Genis Laval Cedex fax: +33 (0)4 78 86 83 86
France <a class="moz-txt-link-freetext" href="http://www-obs.univ-lyon1.fr/eric.emsellem">http://www-obs.univ-lyon1.fr/eric.emsellem</a>
====================================================================
</pre>
</body>
</html>
|
|
From: Jeff W. <js...@fa...> - 2006-12-29 19:19:51
|
Petr Danecek wrote:
> Beautiful! The grid lines must be drawn manually?
>
> On Thu, 2006-12-28 at 13:32 -0700, Jeff Whitaker wrote:
>
>> Here's a slightly prettier version of my previous example:
>>
>> from pylab import *
>> deltatheta = 2.*pi/100.
>> theta = arange(0.,2.*pi+0.5*deltatheta,deltatheta)
>> R = arange(0.,pi,deltatheta)
>> r,t = meshgrid(R, theta)
>> Z = sin(r)*sin(3.*t)
>> X = r*cos(t)
>> Y = r*sin(t)
>> ax = subplot(111)
>> cs = ax.contourf(X,Y,Z)
>> # make sure aspect ratio preserved
>> ax.set_aspect('equal')
>> # turn off rectangular frame.
>> ax.set_frame_on(False)
>> # turn off axis ticks.
>> ax.set_xticks([])
>> ax.set_yticks([])
>> # draw a circle around the edge of the plot.
>> rmax = max(R)
>> ax.plot(rmax*cos(theta),rmax*sin(theta),'k')
>> title('Polar contours')
>> show()
>>
>>
>
>
Petr: Here's yet another way to do it, using the basemap toolkit. This
way you get axis grid lines.
from matplotlib.toolkits.basemap import Basemap
import pylab
theta = pylab.linspace(0.,2.*pylab.pi,101)
R = pylab.linspace(0.,pylab.pi,101)
lat,lon = pylab.meshgrid(R, theta)
Z = pylab.sin(lat)*pylab.sin(4*lon) + pylab.exp(-(lat**2/4))
# convert radial coordinate to latitude, with r=0 being north pole
# and r=rmax being equator.
# convert r and theta to degrees.
lat = (180./pylab.pi)*0.5*lat[::-1,:]
lon = (180./pylab.pi)*lon
m = Basemap(boundinglat=0.,lon_0=0.,resolution=None,projection='npaeqd')
X,Y = m(lon,lat)
CS = m.contourf(X,Y,Z,15)
m.drawparallels(pylab.arange(0,90,20),labels=[1,1,1,1])
m.drawmeridians(pylab.arange(0,360,60),labels=[1,1,1,1])
pylab.show()
-Jeff
--
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328
|
|
From: belinda t. <bt...@cs...> - 2006-12-29 18:54:07
|
Hi,
I'm unable to use matplotlib when I have the following line in my
matlabplotrc file: numerix Numeric.
There is no problem when I use: numerix numpy
Here's my setup: Mac G5 w/OS X 10.4.8, using MacPython 2.4,
numpy.__version__ is 1.0, matplotlib.__version__ 0.87.7 and
Numeric.__version__ 24.2
I append below the errors I get when trying to use numerix Numeric
via python and ipython.
Is this a bug?
--b
VIA IPYTHON:
====================
6 % ipython -pylab
Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
Type "copyright", "credits" or "license" for more information.
IPython 0.7.2 -- An enhanced Interactive Python.
? -> Introduction to IPython's features.
%magic -> Information about IPython's 'magic' % functions.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
Welcome to pylab, a matplotlib-based Python environment.
For more information, type 'help(pylab)'.
In [1]: plot([1,2,3])
------------------------------------------------------------------------
---
exceptions.TypeError Traceback (most
recent call last)
/Users/bthom/belinda/mills/aicourse/tic-tac-toe/<ipython console>
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-
packages/matplotlib/pylab.py in plot(*args, **kwargs)
2025 hold(h)
2026 try:
-> 2027 ret = gca().plot(*args, **kwargs)
2028 draw_if_interactive()
2029 except:
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-
packages/matplotlib/axes.py in plot(self, *args, **kwargs)
2129 lines = [line for line in lines] # consume the
generator
2130
-> 2131 self.autoscale_view(scalex=scalex, scaley=scaley)
2132 return lines
2133
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-
packages/matplotlib/axes.py in autoscale_view(self, tight, scalex,
scaley)
983 if xl[1] < xl[0]:
984 XL = XL[::-1]
--> 985 self.set_xlim(XL)
986 if scaley:
987 yl = self.get_ylim()
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-
packages/matplotlib/axes.py in set_xlim(self, xmin, xmax, emit)
1225 xmax += 1e-38
1226
-> 1227 self.viewLim.intervalx().set_bounds(xmin, xmax)
1228 if emit: self._send_xlim_event()
1229 return xmin, xmax
TypeError: only length-1 arrays can be converted to Python scalars.
.pdbrc.py started
.pdbrc.py finished
> /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/
site-packages/matplotlib/axes.py(1227)set_xlim()
1226
-> 1227 self.viewLim.intervalx().set_bounds(xmin, xmax)
1228 if emit: self._send_xlim_event()
VIA PYTHON:
=================
3 % python
Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
history mechanism set up
>>> import pylab
>>> pylab.plot([1,2,3])
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/site-packages/matplotlib/pylab.py", line 2027, in plot
ret = gca().plot(*args, **kwargs)
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/site-packages/matplotlib/axes.py", line 2131, in plot
self.autoscale_view(scalex=scalex, scaley=scaley)
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/site-packages/matplotlib/axes.py", line 985, in autoscale_view
self.set_xlim(XL)
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/site-packages/matplotlib/axes.py", line 1227, in set_xlim
self.viewLim.intervalx().set_bounds(xmin, xmax)
TypeError: only length-1 arrays can be converted to Python scalars.
|
|
From: John H. <jdh...@ac...> - 2006-12-29 18:53:55
|
>>>>> "Eric" == Eric Emsellem <ems...@ob...> writes:
Eric> great! but one question though: I need to put the text with
Eric> figtext and thus use figure coordinates (instead of pixel
Eric> coord). So how would I replace the :
Eric> matplotlib.transforms.lbwh_to_bbox
It shouldn't matter which way you create the text instance.
JDH
|
|
From: Eric E. <ems...@ob...> - 2006-12-29 18:50:35
|
great! but one question though: I need to put the text with figtext and thus use figure coordinates (instead of pixel coord). So how would I replace the : matplotlib.transforms.lbwh_to_bbox ? thanks Eric John Hunter wrote > def ondraw(event): > l,b,w,h = t.get_window_extent(event.renderer).get_bounds() > > figw, figh = fig.figwidth.get(), fig.figheight.get() > # expand the rectangle to account for larger text; coords are pixel space > ondraw.bbox = matplotlib.transforms.lbwh_to_bbox( > l-10, b-10, w+200, h+20) > ondraw.background = fig.canvas.copy_from_bbox(ondraw.bbox) > ondraw.background = None > ondraw.bbox = None > |
|
From: Christopher B. <Chr...@no...> - 2006-12-29 18:26:48
|
Achim Gaedke wrote: > For a print button in matplotlib it is necessary to find implementations > for other widget sets: > * tk > * wx > * qt wx has pretty good print support. However, with the wx back-end, you'd need to decide if you want to send the bitmap Agg created to the printer, or revert to using wx Drawing calls. And someone still has to write the code --- -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
|
From: John H. <jdh...@ac...> - 2006-12-29 18:03:36
|
>>>>> "Eric" == Eric Emsellem <ems...@ob...> writes:
Eric> Hi, thanks for this useful and quick answer. I am (always)
Eric> using GTKAgg (hope it is a good choice). I understand the 40
Eric> Mb part then, but not the 150-200 Mb... (this happens when I
Eric> move the cursor within the figure window only and things get
Eric> worse when I reload the data with a new imshow).
Eric> Two things from what you say:
Eric> * first : should I do something before redoing another
Eric> imshow? (when I cycle many times through the 3 commands,
Eric> connect, disconnect, imshow, the mouse event updating gets
Eric> really slow, and in fact it seems only the "imshow" really
Eric> makes things worse..). Maybe I need to "flush" the old
Eric> data/image/imshow ?
If you are doing multiple imshows and not clearing the axes in between
then you may be overplotting multiple images. Make sure you clear
your axes before plotting a new image
ax.cla()
Eric> * second: I tried to understand what you mentioned in your
Eric> email about the blit thing. I understand the "principle",
Eric> reading the wiki, and going into mpl examples, but I didn"t
Eric> manage to implement it in practice (see my pathetic attempt
Eric> below). I guess the main reason is that I am not sure what
Eric> should be the "background" in the case of a figtext... (not
Eric> ax.bbox I guess but then what?)
You would want to pick a rectangle large enough to hold any text you
may want to plot to an area, and the copy and blit just that region.
Here are two examples: the first redraws the entire figure as you are
doing but reports memory. I find that memory grows for a while but
them stabilizes, and if you throw in a gc.collect() it is rock solid.
Uncomment gc.collect to compare
The second script uses the blitting technique -- you'll appreciate the
performance boost!
### script one, draw the whole thing every time
import os, sys, time, gc
import matplotlib
#matplotlib.interactive(True)
#matplotlib.use('Cairo')
matplotlib.use('GTKAgg')
import matplotlib.transforms
from pylab import figure, show, nx
def report_memory(i):
pid = os.getpid()
a2 = os.popen('ps -p %d -o rss,sz' % pid).readlines()
print i, ' ', a2[1],
return int(a2[1].split()[1])
fig = figure()
ax = fig.add_subplot(111)
X = nx.mlab.randn(100,100)
ax.imshow(X)
t = ax.text(20,20,'test: 0')
def onmove(event):
mem = report_memory(onmove.cnt)
t.set_text('test: %d mem=%d'%(onmove.cnt, mem))
fig.canvas.draw_idle()
onmove.cnt +=1
#gc.collect()
onmove.cnt = 0
fig.canvas.mpl_connect('motion_notify_event', onmove)
show()
### script two, just blit the text region
import os, sys, time
import matplotlib
#matplotlib.interactive(True)
#matplotlib.use('Cairo')
matplotlib.use('GTKAgg')
import matplotlib.transforms
from pylab import figure, show, nx
def report_memory(i):
pid = os.getpid()
a2 = os.popen('ps -p %d -o rss,sz' % pid).readlines()
print i, ' ', a2[1],
return int(a2[1].split()[1])
fig = figure()
ax = fig.add_subplot(111)
X = nx.mlab.randn(100,100)
ax.imshow(X)
t = ax.text(20,20,'test: 0', animated=True)
def ondraw(event):
l,b,w,h = t.get_window_extent(event.renderer).get_bounds()
figw, figh = fig.figwidth.get(), fig.figheight.get()
# expand the rectangle to account for larger text; coords are pixel space
ondraw.bbox = matplotlib.transforms.lbwh_to_bbox(
l-10, b-10, w+200, h+20)
ondraw.background = fig.canvas.copy_from_bbox(ondraw.bbox)
ondraw.background = None
ondraw.bbox = None
def onmove(event):
mem = report_memory(onmove.cnt)
t.set_text('test: %d mem=%d'%(onmove.cnt, mem))
if ondraw.background is not None:
fig.canvas.restore_region(ondraw.background)
ax.draw_artist(t)
fig.canvas.blit(ondraw.bbox)
onmove.cnt +=1
onmove.cnt = 0
fig.canvas.mpl_connect('motion_notify_event', onmove)
fig.canvas.mpl_connect('draw_event', ondraw)
show()
JDH
|
|
From: Jeff W. <js...@fa...> - 2006-12-29 17:10:28
|
Petr Danecek wrote:
> Beautiful! The grid lines must be drawn manually?
>
> On Thu, 2006-12-28 at 13:32 -0700, Jeff Whitaker wrote:
>
>> Here's a slightly prettier version of my previous example:
>>
>> from pylab import *
>> deltatheta = 2.*pi/100.
>> theta = arange(0.,2.*pi+0.5*deltatheta,deltatheta)
>> R = arange(0.,pi,deltatheta)
>> r,t = meshgrid(R, theta)
>> Z = sin(r)*sin(3.*t)
>> X = r*cos(t)
>> Y = r*sin(t)
>> ax = subplot(111)
>> cs = ax.contourf(X,Y,Z)
>> # make sure aspect ratio preserved
>> ax.set_aspect('equal')
>> # turn off rectangular frame.
>> ax.set_frame_on(False)
>> # turn off axis ticks.
>> ax.set_xticks([])
>> ax.set_yticks([])
>> # draw a circle around the edge of the plot.
>> rmax = max(R)
>> ax.plot(rmax*cos(theta),rmax*sin(theta),'k')
>> title('Polar contours')
>> show()
>>
>>
Petr: Another option might be to use pcolor, it does work wit polar axes.
import pylab
# make color-filled plot of polar coordinate data array.
# define coordinates.
theta = pylab.linspace(0.,2.*pylab.pi,101)
R = pylab.linspace(0.,pylab.pi,101)
Y,X = pylab.meshgrid(R, theta)
# data to plot.
Z = pylab.sin(Y)*pylab.sin(4*X) + pylab.exp(-(Y**2/4))
# create subplot.
ax = pylab.subplot(111,polar=True)
# mesh fill.
ax.pcolormesh(X,Y,Z)
# make sure aspect ratio preserved
ax.set_aspect('equal')
pylab.show()
-Jeff
--
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328
|
|
From: Eric E. <ems...@ob...> - 2006-12-29 16:13:20
|
Hi again, thinking about the module I am writing which will include a "move mouse event" to get the intensity of the pixel in an imshow provided in the figure I am wondering: - would it make any sense to DIRECTLY include such a facility (intensity of pixel provided for an imshow, figimage...) NEXT to the coordinates x & Y which are already there (in the lower right) in mpl figures ???? To me (at least) it would make a LOT of sense, since x,y are already provided for any plot, or imshow-like commands. The third axis (intensity) would then only appear when there is a third dimension is available of course (imshow, etc). I can imagine that such a facility could be turned on or off (I guess...). no? Eric |
|
From: Eric E. <ems...@ob...> - 2006-12-29 16:01:52
|
Hi,
thanks for this useful and quick answer. I am (always) using GTKAgg
(hope it is a good choice). I understand the 40 Mb part then, but not
the 150-200 Mb... (this happens when I move the cursor within the figure
window only and things get worse when I reload the data with a new imshow).
Two things from what you say:
* first : should I do something before redoing another imshow? (when I
cycle many times through the 3 commands, connect, disconnect, imshow,
the mouse event updating gets really slow, and in fact it seems only the
"imshow" really makes things worse..). Maybe I need to "flush" the old
data/image/imshow ?
* second: I tried to understand what you mentioned in your email about
the blit thing. I understand the "principle", reading the wiki, and
going into mpl examples, but I didn"t manage to implement it in practice
(see my pathetic attempt below). I guess the main reason is that I am
not sure what should be the "background" in the case of a figtext...
(not ax.bbox I guess but then what?)
Any help is welcome (or a hint, since doing it myself is I guess the
best way to learn ...)
thanks again
Eric
#===================================================
# This script is not working... something I didn't understand in
blitting....
#===================================================
import numpy as num
import matplotlib as mpl
import matplotlib.pylab as plab
data = num.random.rand(200,200)
xy = [num.arange(0.,20,.1), num.arange(0.,20,.1)]
fig = plab.figure()
canvas = fig.canvas
im = plab.imshow(data, extent=[0.,20.,0.,20.])
ftext = plab.figtext(0.9,0.9,"", animated=True)
ax = plab.gca()
background = canvas.copy_from_bbox(ax.bbox)
def whichpix_inframe(coord) :
indw = num.zeros(2, num.int32)
if len(coord) == 2 :
indw[0] = num.sort(xy[0]).searchsorted(coord[0])
indw[1] = num.sort(xy[1]).searchsorted(coord[1])
return indw
def mouse_move(event) :
if event.inaxes :
canvas.restore_region(background)
ftext.set_text(str(data[tuple(whichpix_inframe([event.xdata,
event.ydata]))]))
ax.draw_artist(ftext)
canvas.blit(ax.bbox)
# canvas.draw()
id = canvas.mpl_connect('motion_notify_event', mouse_move)
canvas.mpl_disconnect(id)
John Hunter wrote:
> Eric> 2/ When I now use the mouse_move event, it can go up to 150
> Eric> Mb of memory usage!! Again: is that normal?
>
> In your example code below, I notice you are drawing on every mouse
> motion. I believe there is a Tkinter specific leak in TkAgg if memory
> serves, but it's outside of mpl. What backend are you using? Does
> the problem go away with a different backend?
...
> The basic idea is to capture the background as a pixel buffer,
> identify the rectangle region you want to draw the text into, draw the
> background, update the text, redraw only the text rectangle etc....
> See
>
> http://www.scipy.org/Cookbook/Matplotlib/Animation
|
|
From: Jeff W. <js...@fa...> - 2006-12-29 16:00:02
|
Petr Danecek wrote:
> Beautiful! The grid lines must be drawn manually?
>
> On Thu, 2006-12-28 at 13:32 -0700, Jeff Whitaker wrote:
>
>> Here's a slightly prettier version of my previous example:
>>
>> from pylab import *
>> deltatheta = 2.*pi/100.
>> theta = arange(0.,2.*pi+0.5*deltatheta,deltatheta)
>> R = arange(0.,pi,deltatheta)
>> r,t = meshgrid(R, theta)
>> Z = sin(r)*sin(3.*t)
>> X = r*cos(t)
>> Y = r*sin(t)
>> ax = subplot(111)
>> cs = ax.contourf(X,Y,Z)
>> # make sure aspect ratio preserved
>> ax.set_aspect('equal')
>> # turn off rectangular frame.
>> ax.set_frame_on(False)
>> # turn off axis ticks.
>> ax.set_xticks([])
>> ax.set_yticks([])
>> # draw a circle around the edge of the plot.
>> rmax = max(R)
>> ax.plot(rmax*cos(theta),rmax*sin(theta),'k')
>> title('Polar contours')
>> show()
>>
>>
>
>
Petr: Yes. matplotlib has polar axes for some kinds of plots, but not
for contour plots.
-Jeff
--
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328
|
|
From: Petr D. <da...@uc...> - 2006-12-29 15:47:22
|
Beautiful! The grid lines must be drawn manually?
On Thu, 2006-12-28 at 13:32 -0700, Jeff Whitaker wrote:
> Here's a slightly prettier version of my previous example:
>
> from pylab import *
> deltatheta = 2.*pi/100.
> theta = arange(0.,2.*pi+0.5*deltatheta,deltatheta)
> R = arange(0.,pi,deltatheta)
> r,t = meshgrid(R, theta)
> Z = sin(r)*sin(3.*t)
> X = r*cos(t)
> Y = r*sin(t)
> ax = subplot(111)
> cs = ax.contourf(X,Y,Z)
> # make sure aspect ratio preserved
> ax.set_aspect('equal')
> # turn off rectangular frame.
> ax.set_frame_on(False)
> # turn off axis ticks.
> ax.set_xticks([])
> ax.set_yticks([])
> # draw a circle around the edge of the plot.
> rmax = max(R)
> ax.plot(rmax*cos(theta),rmax*sin(theta),'k')
> title('Polar contours')
> show()
>
|
|
From: John H. <jdh...@ac...> - 2006-12-29 14:44:31
|
>>>>> "Eric" == Eric Emsellem <ems...@ob...> writes:
Eric> Questions and problems: 1/ when I load the image the first
Eric> time (first imshow command in the script), I see that,
Eric> although the amount of data is very small,
Eric> ipython/matplotlib already uses more than 40 Mb of memory!
Eric> Is that normal?
It seems high, but looks inline with the size of the mpl extension
code (though some of which is redunant numpy/numeric/numarray extensions
that shouldn't all be loaded)
peds-pc311:~/mpl/build> du -h
20M ./lib.linux-i686-2.4/matplotlib/backends
8.0K ./lib.linux-i686-2.4/matplotlib/toolkits
8.0K ./lib.linux-i686-2.4/matplotlib/numerix/mlab
8.0K ./lib.linux-i686-2.4/matplotlib/numerix/ma
8.0K ./lib.linux-i686-2.4/matplotlib/numerix/linear_algebra
8.0K ./lib.linux-i686-2.4/matplotlib/numerix/random_array
8.0K ./lib.linux-i686-2.4/matplotlib/numerix/fft
64K ./lib.linux-i686-2.4/matplotlib/numerix
40K ./lib.linux-i686-2.4/matplotlib/enthought/traits/ui/null
252K ./lib.linux-i686-2.4/matplotlib/enthought/traits/ui
632K ./lib.linux-i686-2.4/matplotlib/enthought/traits
28K ./lib.linux-i686-2.4/matplotlib/enthought/resource
12K ./lib.linux-i686-2.4/matplotlib/enthought/util
676K ./lib.linux-i686-2.4/matplotlib/enthought
40M ./lib.linux-i686-2.4/matplotlib
40M ./lib.linux-i686-2.4
40M
Eric> 2/ When I now use the mouse_move event, it can go up to 150
Eric> Mb of memory usage!! Again: is that normal?
In your example code below, I notice you are drawing on every mouse
motion. I believe there is a Tkinter specific leak in TkAgg if memory
serves, but it's outside of mpl. What backend are you using? Does
the problem go away with a different backend?
If there is a leak under our control we will certainly find it an fix
it to the best of our abilities. Our canonical memory leak checking
script (which does an imshow and more) is running rock solid on the
Agg backend so if there is a leak it is probably backend specific.
I noticed in your example script that you are only modifiying a text
entry on mouse motion. Your performance will dramatically improve if
you use the blitting techniques described in the animation tutorial.
The basic idea is to capture the background as a pixel buffer,
identify the rectangle region you want to draw the text into, draw the
background, update the text, redraw only the text rectangle etc....
See
http://www.scipy.org/Cookbook/Matplotlib/Animations
After you've read through this if you get stuck let me know and I'll
put together a small demo for you.
JDH
|
|
From: Eric E. <ems...@ob...> - 2006-12-29 13:31:50
|
Hi,
I am writing a small module to easily load images and interact with
them. I now face a memory usage +CPU problem, which may in fact be the
result of a normal behaviour of matplotlib (but more certainly something
I am not doing right), but I really like to be sure here because if
confirmed, it would mean that this module is almost not usable for large
images...
Below is a (very simplified) example of what I am doing, that script
showing a similar behaviour than the real full module.
Questions and problems:
1/ when I load the image the first time (first imshow command in the
script), I see that, although the amount of data is very small,
ipython/matplotlib already uses more than 40 Mb of memory!
Is that normal?
2/ When I now use the mouse_move event, it can go up to 150 Mb of memory
usage!! Again: is that normal?
3/ When I do successive cycles of connect, disconnect, imshow (reloading
the figure), the memory usage seems to grow slightly, but more
importantly the capturing event (writing the data intensity on the top
right corner of the figure) gets REALLY SLOW.. Try a series of 10 imshow
with the same data..
So maybe I should "clean" some structure somewhere to allow a fast
interaction, or maybe the code below is rubish. But so far I haven't
found a cure, and this is very annoying to say the least.
Thanks for any tip on this problem.
Eric
P.S.: and for the sake of tempering the questions above (certainly
caused by my ignorance): matplotlib + numpy is just an amazing
combination!!!
P.P.S: set up for me is:
Suse 10.1
matplotlib version 0.87.7
numerix numpy 1.0.2.dev3491
Python 2.4.2 (#1, May 2 2006, 08:13:46)
IPython 0.7.4.svn.r2010 -- An enhanced Interactive Python.
## ===============================
## Below is a small script to illustrate memory and CPU pbs
## It loads some rand data, with coordinates given in xy
## and the mouse event allows to write the intensity of
## the image in the top right corner of the figure
## ===============================
import numpy as num
import matplotlib as mpl
import matplotlib.pylab as plab
data = num.random.rand(200,200)
xy = [num.arange(0.,20,.1), num.arange(0.,20,.1)]
fig = plab.figure()
canvas = fig.canvas
plab.imshow(data, extent=[0.,20.,0.,20.])
ftext = plab.figtext(0.9,0.9,"")
def whichpix_inframe(coord) :
indw = num.zeros(2, num.int32)
if len(coord) == 2 :
indw[0] = num.sort(xy[0]).searchsorted(coord[0])
indw[1] = num.sort(xy[1]).searchsorted(coord[1])
return indw
def mouse_move(event) :
if event.inaxes :
ax = event.inaxes
ftext.set_text(str(data[tuple(whichpix_inframe([event.xdata,
event.ydata]))]))
canvas.draw()
id = canvas.mpl_connect('motion_notify_event', mouse_move)
## then we can go on and cycle through the next 3 lines...: it shows the
CPU+memory pb getting worse
# canvas.mpl_disconnect(id)
# plab.imshow(data, extent=[0.,20.,0.,20.])
# id = canvas.mpl_connect('motion_notify_event', mouse_move)
|
|
From: Eric F. <ef...@ha...> - 2006-12-29 08:14:42
|
John Hunter wrote: >>>>>> "Eric" == Eric Firing <ef...@ha...> writes: > Eric> either, indistinguishably from the way it does now. The > Eric> problem is that with a linear axis we want the axis to start > Eric> at zero by default, but with a log axis we want it to start > > With ymin at 1e-100, the default (linear) locator should choose 0 as > ymin. If it doesn't it looks like a bug. Is either the log or linear > autoscaler broken for bottom=something-really-small ? > > JDH The problem is not the linear case but the log, and it is not a problem with the locators or with the autoscaling methods. Rather, for the log scale we want the autoscaling to ignore the bottom of the patches at 1e-100 and instead pick a lower value for plotting based on the tops of the patches (or the bottom of the errorbars, if present). This is what I have it doing now via the somewhat clumsy method of adjusting the dataLim after the patches have been added. To make the transition to a log scale work correctly after bar has been called with a linear scale, some such adjustment would have to be made. This is the sort of thing that could be done by registering a callback, but we don't have the machinery in place. Maybe this is a place where traits would help? I've never used them, but I seem to recall seeing that they include callback functionality. Eric |
|
From: Eric E. <ems...@ob...> - 2006-12-29 07:39:49
|
ok thanks for the check. Since it seems like a personal setting pb, I
have now restarted from a clean matplotlibrc and set up my prefered option.
It now works (no clue why it didn't...)
sorry for the trouble and thanks for doing that test.
cheers
Eric
Eric Firing wrote:
> It works on my machine (linux) with svn, but I don't see anything
> about this in CHANGELOG.
>
> Eric
>
> Eric Emsellem wrote:
>> hi,
>>
>> I am trying to have text written on 2 lines, but everything is written
>> on a single line. Is that normal?
>>
>> here is an example:
>>
>> plot(arange(10))
>> ylabel('this is vertical \n test')
>> text(0.5,0.5,"this is a test \n but does not work")
>>
>> thanks
>> Eric
>> =======================
>> Suse 10.1
>> matplotlib version 0.87.7
>> numerix numpy 1.0.2.dev3491
>> Python 2.4.2 (#1, May 2 2006, 08:13:46)
>> IPython 0.7.4.svn.r2010 -- An enhanced Interactive Python.
>>
>>
|
|
From: John H. <jdh...@ac...> - 2006-12-29 05:52:55
|
>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
Eric> either, indistinguishably from the way it does now. The
Eric> problem is that with a linear axis we want the axis to start
Eric> at zero by default, but with a log axis we want it to start
With ymin at 1e-100, the default (linear) locator should choose 0 as
ymin. If it doesn't it looks like a bug. Is either the log or linear
autoscaler broken for bottom=something-really-small ?
JDH
|
|
From: Eric F. <ef...@ha...> - 2006-12-29 05:40:49
|
Diwaker Gupta wrote:
>> Examples:
>>
>> This makes a sensible plot that behaves well under zooming and panning:
>> hist(randn(1000), log=True)
>> show()
>
> Thanks! However...
>
>> The following still generates an exception:
>> hist(randn(1000))
>> gca().set_yscale('log')
>> show()
>
> I think this makes the API more confusing. As an end user, I want the
> API to be consistent and intuitive. Its weird if I can set log scale
> after all plot commands, but not after calling hist. And yet, log
> scale DOES work with that keyword arg. I might even think things were
> broken had I not been following this thread.
>
> Anyways, thanks for looking into this!
I agree that it is not optimal, but I have not figured out any simple
way of making bar (which is the underlying plot command) do the right
thing without knowing beforehand whether it is dealing with a log or a
linear axis. It simply has to make different choices for the patch
(rectangle) corners and the data limits that are used for autoscaling.
For this to work correctly in an interactive mode with
set_yscale('log') called after the hist or bar command would require a
mechanism for undoing and then redoing the hist or bar command. Such a
mechanism could be developed, but it would require some structural
changes in mpl (or maybe some very ugly hacks), and I don't see that
this particular problem is bad enough to motivate such changes.
Actually, I think the sticking point is the autoscaling, not the
patches. For the default "bottom=None" case, we could set bottom to
1e-100 for both the log and linear axes, and for all practical purposes
it would work correctly for either, indistinguishably from the way it
does now. The problem is that with a linear axis we want the axis to
start at zero by default, but with a log axis we want it to start a bit
below the lowest bar, so the autoscaling is inherently different and
needs to be based on a different dataLim bounding box.
Maybe in time we will figure out better solutions.
Eric
|
|
From: Diwaker G. <diw...@gm...> - 2006-12-29 02:25:23
|
> Examples:
>
> This makes a sensible plot that behaves well under zooming and panning:
> hist(randn(1000), log=True)
> show()
Thanks! However...
> The following still generates an exception:
> hist(randn(1000))
> gca().set_yscale('log')
> show()
I think this makes the API more confusing. As an end user, I want the
API to be consistent and intuitive. Its weird if I can set log scale
after all plot commands, but not after calling hist. And yet, log
scale DOES work with that keyword arg. I might even think things were
broken had I not been following this thread.
Anyways, thanks for looking into this!
--
Web/Blog/Gallery: http://floatingsun.net/blog
|
