Re: [Matplotlib-users] imshow size limitations?
--- On Sun, 2/28/10, David Goldsmith d_l_goldsm...@yahoo.com wrote: Question 2) is there some way I can add pieces of the array incrementally to the image into their proper place, i.e., modify the following code: ax.imshow(image[0:ny/2+1, 0:nx/2+1]) # upper left corner of image ax.hold(True) ax.imshow(argW[ny/2+1:-1, 0:nx/2+1]) # lower left corner of image ax.imshow(argW[0:ny/2+1, nx/2+1:-1]) # upper right corner of image ax.imshow(argW[ny/2+1:-1, nx/2+1:-1]) # lower right corner of image Try the extents keyword argument. It let's you specify the corners of the image in data coordinates. Ryan Hi, Ryan, thanks! Can you be a little more specific as to how I should try that? I tried: ax.imshow(argW[0:ny/2+1, 0:nx/2+1], cmap_name, extent=(0,nx/2,ny/2,0)) ax.hold(True) ax.imshow(argW[ny/2+1:-1, 0:nx/2+1], cmap_name, extent=(0,nx/2,ny,ny/2)) ax.imshow(argW[0:ny/2+1, nx/2+1:-1], cmap_name, extent=(nx/2,nx,ny/2,0)) ax.imshow(argW[ny/2+1:-1, nx/2+1:-1], cmap_name, extent=(nx/2,nx,ny,ny/2)) which didn't work (I only got one corner - the last one, I think - i.e., I think it's still just putting subsequent images on top of prior ones). Based on just a quick look, I'd make sure: 1) To set the x and y limits appropriately: ax.set_xlim(0, nx) ax.set_ylim(ny, 0) I'll try it out and report back. Nope, still only getting the last corner. Let me give a little more of my code: import numpy as N from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas from matplotlib.figure import Figure w, h, DPI = (8.2, 6.2, 50) fig = Figure(figsize=(w, h), dpi=DPI, frameon=False) ax = fig.add_subplot(1,1,1) canvas = FigureCanvas(fig) nx, xmin, xmax = (int(w*DPI), -0.5, 0.5) ny, ymin, ymax = (int(h*DPI), 0.6, 1.2) W = N.zeros((ny,nx),N.complex) ## Generate non-trivial W; unnecessary for code to run, I think argW = N.angle(W) ax.set_xlim(0, nx) ax.set_ylim(ny, 0) ax.imshow(argW[0:ny/2, 0:nx/2], extent=(0, nx/2 - 1, ny/2 - 1, 0)) ax.hold(True) ax.imshow(argW[ny/2:-1, 0:nx/2], extent=(0, nx/2 - 1, ny, ny/2)) ax.imshow(argW[0:ny/2, nx/2:-1], extent=(nx/2, nx, ny/2 - 1, 0)) ax.imshow(argW[ny/2:-1, nx/2:-1], extent=(nx/2, nx, ny, ny/2)) canvas.print_figure(fid, dpi=DPI) DG -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Optimal positioning of text
Hi Jae-Joon All,
On 28 February 2010 03:09, Jae-Joon Lee wrote:
If I read your correctly,
for l, b in zip(x, y):
# And here I work with data coordinates (!)
dashBox = Bbox.from_bounds(l, b, width+5, height+5)
badness = 0
for line in lines:
if line.intersects_bbox(dashBox):
badness += 1
x, y (therefore l, b) in data coordinate.
width, height?? this seems to be some wx specific coordinate, i have no idea.
lines (therefore line) in display coordinate.
converting x,y to display coordinate should straight forward. But I'm
not sure what kind of coordinate width and height has. Is it a method
of some class derived from matplotlib's Text?? If then, the extent of
the text can be measured using the get_window_extent method. This
requires a renderer instance, which should be known if the method is
called during the drawing time.
Again, post a complete but simple(!) code.
OK, I think I got a complete code. Not super-simple, but simple enough
I believe. After you run it you'll see a bunch of points and lines
with some text. If you left-click inside the axis this will start the
calculations for the optimal positioning. There are a couple of
problems:
1) The code I have looks only for optimal positioning with respect to
lines in the plot, it doesn't include texts (I don't know how to do
it); You'll see what I mean if you run the code, the optimally
positioned texts overlap with other text in the plot, and with
themselves too (i.e., one optimally positioned text overlap with
another optimally positioned text);
2) The code as it stands it's very slow. On my (relatively fast)
computer, it takes almost 6 seconds to optimally position 14 labels.
In order to run the code, you'll also need the lines.txt file, which
contains the main lines coordinates. Sorry about this extra file but I
wanted it to be as close as possible to my use-case.
Thank you in advance for your suggestions.
Andrea.
Imagination Is The Only Weapon In The War Against Reality.
http://xoomer.alice.it/infinity77/
http://thedoomedcity.blogspot.com/
import wx
import numpy
import matplotlib
import time
matplotlib.use(WXAGG)
from matplotlib.transforms import Bbox
from matplotlib.pyplot import figure, show
x = [71, 75, 56, 61, 42, 73, 89, 17, 70, 89, 26.2, 77, 82, 80, 53, 47,
54, 46, 84, 29, 26, 89, 50, 71, 62, 69, 75, 76, 66, 70, 71, 85, 60]
y = [42, 31, 42, 43, 34, 31, 13, 39, 58, 47, 42.5, 39, 25, 12, 34, 46,
13, 17.7, 59, 26, 33, 57, 40, 22, 47, 40, 45, 17, 55, 51, 63, 24, 16.5]
pointNames = [Point_%d%indx for indx in xrange(1, len(x)+1)]
fid = open(lines.txt, rt)
xLines = eval(fid.readline().strip())
yLines = eval(fid.readline().strip())
fid.close()
lineNames = [Line_%d%indx for indx in xrange(1, len(xLines)+1)]
lineText = MODEL 1: %0.6g\nMODEL 2: %0.6g
multValues = numpy.random.random((len(x), 2))
def button_press_callback(event):
if event.inaxes is not None:
start = time.clock()
ax = event.inaxes
position_labels(ax)
print \nElapsed Time:, time.clock() - start
ax.get_figure().canvas.mpl_disconnect('button_press_event')
def position_labels(ax):
dc = wx.MemoryDC()
dc.SelectObject(wx.EmptyBitmap(1, 1))
font = wx.SystemSettings_GetFont(wx.SYS_DEFAULT_GUI_FONT)
font.SetPointSize(8)
dc.SetFont(font)
inv = ax.transData.inverted()
count = 0
for xl, yl in zip(xLines, yLines):
name = lineText%(multValues[count][0], multValues[count][1])
txt = ax.text(xl[0], yl[0], name, fontsize=8, withdash=True,
dashdirection=1,
dashlength=10, rotation=0, dashrotation=90, dashpush=10)
txt.set_backgroundcolor((1, 1, 1))
txt.set_multialignment(left)
ox, oy = position_annotation(dc, ax, name, txt, xl, yl)
ox1, oy1 = inv.transform((ox, oy))
txt.set_position((ox1, oy1))
count += 1
dc.SelectObject(wx.NullBitmap)
ax.get_figure().canvas.draw()
def position_annotation(dc, ax, name, txt, xl, yl):
lines = []
for handle in ax.lines:
path = handle.get_path()
trans = handle.get_transform()
tpath = trans.transform_path(path)
lines.append(tpath)
width, height, dummy = dc.GetMultiLineTextExtent(name)
candidates = []
values = ax.transData.transform(zip(xl, yl))
for l, b in values:
dashBox = Bbox.from_bounds(l, b, width, height)
badness = 0
for line in lines:
if line.intersects_bbox(dashBox):
badness += 1
if badness == 0:
return l, b
candidates.append((badness, (l, b)))
# rather than use min() or list.sort(), do this so that we are assured
# that in the case of two equal badnesses, the one first considered is
# returned.
# NOTE: list.sort() is stable.But leave as it is for now. -JJL
candidates.sort()
ox,
Re: [Matplotlib-users] imshow size limitations?
David Goldsmith wrote: --- On Sun, 2/28/10, David Goldsmith d_l_goldsm...@yahoo.com wrote: Question 2) is there some way I can add pieces of the array incrementally to the image into their proper place, i.e., modify the following code: ax.imshow(image[0:ny/2+1, 0:nx/2+1]) # upper left corner of image ax.hold(True) ax.imshow(argW[ny/2+1:-1, 0:nx/2+1]) # lower left corner of image ax.imshow(argW[0:ny/2+1, nx/2+1:-1]) # upper right corner of image ax.imshow(argW[ny/2+1:-1, nx/2+1:-1]) # lower right corner of image Try the extents keyword argument. It let's you specify the corners of the image in data coordinates. Ryan Hi, Ryan, thanks! Can you be a little more specific as to how I should try that? I tried: ax.imshow(argW[0:ny/2+1, 0:nx/2+1], cmap_name, extent=(0,nx/2,ny/2,0)) ax.hold(True) ax.imshow(argW[ny/2+1:-1, 0:nx/2+1], cmap_name, extent=(0,nx/2,ny,ny/2)) ax.imshow(argW[0:ny/2+1, nx/2+1:-1], cmap_name, extent=(nx/2,nx,ny/2,0)) ax.imshow(argW[ny/2+1:-1, nx/2+1:-1], cmap_name, extent=(nx/2,nx,ny,ny/2)) which didn't work (I only got one corner - the last one, I think - i.e., I think it's still just putting subsequent images on top of prior ones). Based on just a quick look, I'd make sure: 1) To set the x and y limits appropriately: ax.set_xlim(0, nx) ax.set_ylim(ny, 0) I'll try it out and report back. Nope, still only getting the last corner. Let me give a little more of my code: David: Just add ax.set_xlim(0,nx) ax.set_ylim(0,ny) after you imshow calls. The axes limits are being automatically set to match your last invocation of imshow. -Jeff import numpy as N from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas from matplotlib.figure import Figure w, h, DPI = (8.2, 6.2, 50) fig = Figure(figsize=(w, h), dpi=DPI, frameon=False) ax = fig.add_subplot(1,1,1) canvas = FigureCanvas(fig) nx, xmin, xmax = (int(w*DPI), -0.5, 0.5) ny, ymin, ymax = (int(h*DPI), 0.6, 1.2) W = N.zeros((ny,nx),N.complex) ## Generate non-trivial W; unnecessary for code to run, I think argW = N.angle(W) ax.set_xlim(0, nx) ax.set_ylim(ny, 0) ax.imshow(argW[0:ny/2, 0:nx/2], extent=(0, nx/2 - 1, ny/2 - 1, 0)) ax.hold(True) ax.imshow(argW[ny/2:-1, 0:nx/2], extent=(0, nx/2 - 1, ny, ny/2)) ax.imshow(argW[0:ny/2, nx/2:-1], extent=(nx/2, nx, ny/2 - 1, 0)) ax.imshow(argW[ny/2:-1, nx/2:-1], extent=(nx/2, nx, ny, ny/2)) canvas.print_figure(fid, dpi=DPI) DG -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] using the symbol font in TeX plots
Gökhan Sever wrote: Thanks again. I didn't know it was complete :) For the second idea you mean something as generic as plotting such markers? plt.plot(range(10), linestyle='None', marker=u'※ ') Yes -- but it can't be quite this simple, since there is already a set of strings that have specific meanings for markers, and we wouldn't want to change that behavior. In order to use an arbitrary character or string, we'd need additional syntax to indicate that's what you want to do. For example: plt.plot(range(10), linestyle='None', marker=u'(※)') But I'm hoping someone can suggest a more obvious way to do it. Mike On Fri, Feb 26, 2010 at 2:56 PM, Michael Droettboom md...@stsci.edu mailto:md...@stsci.edu wrote: SVN trunk has support for mathtext as symbol markers -- plot(range(10), linestyle='None', marker=r'$\clubsuit$') We could support arbitrary (non-math) text, too, fairly easily. We just need to invent a syntax for it. Mike Gökhan Sever wrote: Thanks Mike. The Greek symbols become visible when I make the changes as you suggested. DejaVu Sans has been installed in my system (Fedora 12). We might put a note on the documentation stating to get wider Unicode coverage people could install additional fonts --DejaVu Sans being one of them instead of shipping the fonts with matplotlib. With my working unicode example, now I have three ways to show u^-2 on labels. See the code at: http://code.google.com/p/ccnworks/source/browse/trunk/various/threemus.py Not heavy Latex users like me might find unicode fonts much easier to create their labels. Especially using units like #/cm^3. There are so many nice looking symbols in the DejaVu Sans samples at http://dejavu.sf.net/samples/DejaVuSans.pdf Is it possible in matplotlib to use those symbols as replacement for regular markers while plotting? I recall someone was asking about using Latex symbols as markers, but not sure about the fate of his question. Thanks On Fri, Feb 26, 2010 at 10:13 AM, Michael Droettboom md...@stsci.edu mailto:md...@stsci.edu mailto:md...@stsci.edu mailto:md...@stsci.edu wrote: Thanks for the reminder. Sorry this fell through the cracks. The reason this worked for me and not for you is that I had set (and later forgotten) font.sans-serif to the following: font.sans-serif : DejaVu Sans, Bitstream Vera Sans, Lucida Grande, Verdana, Geneva, Lucid, Arial, Helvetica, Avant Garde, sans-serif DejaVu Sans is the successor to Vera Sans that includes much larger Unicode coverage, including the Greek characters here. Vera Sans (at least the version shipped with matplotlib) does not include these characters. It's an open question whether we want to ship the larger DejaVu fonts with matplotlib (and annoy the distro packagers even further who already dislike some of matplotlib's redundancy). A less disruptive change may be to change the rc defaults to put DejaVu in front of Vera, even though we don't ship DejaVu. This will help the majority of Linux users on modern distros (where DejaVu is almost always installed by default, I suspect), and still have our own Vera as a fallback (albeit with a more limited character set). Especially since DejaVu and Vera are basically the same font, and substituting one for the other would not change the appearance of plots, I think this a reasonably safe thing to do -- but I'd appreciate feedback in case I haven't thought through all the issues. Mike Gökhan Sever wrote: On Fri, Jan 29, 2010 at 7:43 AM, Michael Droettboom md...@stsci.edu mailto:md...@stsci.edu mailto:md...@stsci.edu mailto:md...@stsci.edu mailto:md...@stsci.edu mailto:md...@stsci.edu mailto:md...@stsci.edu mailto:md...@stsci.edu wrote: On 01/28/2010 08:08 PM, Gökhan Sever wrote: #!/usr/bin/python # -*- coding: utf-8 -*- from pylab import * plot([1]*5) xlabel(u'μ = 50') ylabel(u'σ = 1.5') show() It works for me. Can you provide a screenshot and the output from matplotlib with verbose.level : debug-annoying in your matplotlibrc? Mike Mike, Attached are the
Re: [Matplotlib-users] using the symbol font in TeX plots
Gökhan Sever wrote: For the second idea you mean something as generic as plotting such markers? plt.plot(range(10), linestyle='None', marker=u'※ ') On 3/1/2010 8:33 AM, Michael Droettboom wrote: Yes -- but it can't be quite this simple, since there is already a set of strings that have specific meanings for markers, and we wouldn't want to change that behavior. In order to use an arbitrary character or string, we'd need additional syntax to indicate that's what you want to do. Perhaps naively, I do not see why. A small number of strings have predefined meanings. Just keep documenting that and then test if the provided string is in this set. Otherwise, use the provided string. This seems very nice. If that is too implicit, then adding a markerstr keyword argument seems the right way to go. It would override the marker argument, and any string could be used, getting rid of the above problem. Cheers, Alan Isaac (just a user) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] using the symbol font in TeX plots
Alan G Isaac wrote: Gökhan Sever wrote: For the second idea you mean something as generic as plotting such markers? plt.plot(range(10), linestyle='None', marker=u'※ ') On 3/1/2010 8:33 AM, Michael Droettboom wrote: Yes -- but it can't be quite this simple, since there is already a set of strings that have specific meanings for markers, and we wouldn't want to change that behavior. In order to use an arbitrary character or string, we'd need additional syntax to indicate that's what you want to do. Perhaps naively, I do not see why. A small number of strings have predefined meanings. Just keep documenting that and then test if the provided string is in this set. Otherwise, use the provided string. This seems very nice. If that is too implicit, then adding a markerstr keyword argument seems the right way to go. It would override the marker argument, and any string could be used, getting rid of the above problem. Cheers, Alan Isaac (just a user) What if you want to use the letter 'o' as a marker? That to me seems like a potential source of confusion, as well as a little bit limiting. What would the escaping syntax be to use the letter 'o'? As you suggest, adding an additional kwarg is also a way forward. In that case, though, I would suggest that providing both a marker and markerstr argument should raise an exception. Having implicit overriding rules can often lead to confusion. One downside of the additional kwarg is that you occasionally see code like this: markers = ['o', '.', 'h', 'x'] for data, marker in zip(datasets, markers): plot(data, marker=marker) If one wanted to mix built-in with non-built-in markers that idiom would become much more complex. That's why I proposed sticking to a purely string representation -- I'm just not sure of the best or most obvious one. Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] using the symbol font in TeX plots
On 3/1/2010 9:36 AM, Michael Droettboom wrote: What if you want to use the letter 'o' as a marker? That to me seems like a potential source of confusion, as well as a little bit limiting. What would the escaping syntax be to use the letter 'o'? Maybe: allow only unicode strings as string markers and test with `is`:: 'o' is 'o' True 'o' is u'o' False Alan Isaac -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] Max Size of an Attachment?
See Subject. Is it 40K? -- Wayne Watson (Watson Adventures, Prop., Nevada City, CA) (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39° 15' 7 N, 121° 2' 32 W, 2700 feet Stop the illegal killing of dolphins and porpoises. http://www.takepart.com/thecove Wrest the control of the world's fisheries from Japan. Web Page:www.speckledwithstars.net/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Max Size of an Attachment?
On Mon, Mar 1, 2010 at 9:45 AM, Wayne Watson sierra_mtnv...@sbcglobal.net wrote: See Subject. Is it 40K? The max size of the message body is 200K. If you are sending attachments, they will be mime encoded, so they encoding may be larger than the file size, and the limit applies to the encoded size. I am the list moderator and will often approve messages over the limit if * they are not too far over the limit * they are topical and relevant I usually moderate the messages once a day. Many people use free drop services for larger attachments, eg http://drop.io JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Max Size of an Attachment?
I use Tbird, and I think any jpg file I send is encoded in an acceptable format for e-mail delivery. Aside from using attachments here, I recently noticed another Python list only allows 40K. On 3/1/2010 7:58 AM, John Hunter wrote: On Mon, Mar 1, 2010 at 9:45 AM, Wayne Watson sierra_mtnv...@sbcglobal.net wrote: See Subject. Is it 40K? The max size of the message body is 200K. If you are sending attachments, they will be mime encoded, so they encoding may be larger than the file size, and the limit applies to the encoded size. I am the list moderator and will often approve messages over the limit if * they are not too far over the limit * they are topical and relevant I usually moderate the messages once a day. Many people use free drop services for larger attachments, eg http://drop.io JDH -- Wayne Watson (Watson Adventures, Prop., Nevada City, CA) (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39° 15' 7 N, 121° 2' 32 W, 2700 feet Stop the illegal killing of dolphins and porpoises. http://www.takepart.com/thecove Wrest the control of the world's fisheries from Japan. Web Page:www.speckledwithstars.net/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] Contour with locator=FixedLocator(...) drops first and last contours from the list.
This is a bug report. I am using matplotlib 0.99.1 on Windows. When using contour with the keyword argument locator=ticker.FixedLocator(levels), the plot is always dropping the first and last contour level. If there are less than 3 levels, contour.py throws an exception. My workaround is to duplicate the first and last levels when using the fixed locator: e.g. my argument becomes locator=FixedLocator( [levels[0]] + levels + [levels[-1]] ) I have traced the problem to the last line in contour.py, method _autolev() which strips the first and last levels if the contours are not filled: return lev[1:-1] This line occurs at line 682 in my version of contour.py which came with the 0.991 installation. I realize that I could specify the levels in the argument V and this does work. However this code is embedded in GUI-ness which allows the user to choose how the contours are selected. Passing the locator seems to be the best option code-wise. Thank you, Dave Smith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] Memory leak
Hello
I have encountered memory leak when using pylab.figure(), pylab.show(),
pylab.close(). I expected pylab.close() to flush the memory but this was not
the case. what am i doing wrong? Thanks in advance
Below is simple example
import os, sys, time
import gc
import matplotlib
matplotlib.use('TKAgg')
import pylab
import matplotlib.cbook as cbook
pid = os.getpid()
a2 = os.popen('ps -p %d -o vsz' % pid).readlines()
print 'memory before all figures the figure is drawn: ' + str(a2[1])
pylab.ion()
fig_list = []
for i in range(10):
fig_list.append(pylab.figure())
val = cbook.report_memory(i)
print i, val
pylab.show()
for fig in fig_list:
pylab.close(fig)
gc.collect()
print 'uncollectable list:', gc.garbage
a2 = os.popen('ps -p %d -o vsz' % pid).readlines()
print 'memory after all figures are closed : ' + str(a2[1])
**results**
memory before all figures the figure is drawn: 35424
0 4981
1 4981
2 5493
3 6005
4 6005
5 6517
6 6517
7 7029
8 7541
9 7541
uncollectable list: []
memory after all figures are closed : 80808
thanks
kwabena
--
View this message in context:
http://old.nabble.com/Memory-leak-tp27741668p27741668.html
Sent from the matplotlib - users mailing list archive at Nabble.com.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Transparency with fig.canvas.mpl_connect
Thanks so much John! That does the trick.
I'm just a new user of mpl, so your question about whether the default
behavior of draw should be changed is probably above my pay grade. I just
don't know the API well enough to comment intelligently about it. That
said, I would suggest that this behavior be documented (either in the
tutorial page I originally accessed, the documentation for canvas.draw(),
both locations, or some other appropriate place).
Thanks again from a very satisfied mpl user,
Brian
John Hunter-4 wrote:
On Fri, Feb 26, 2010 at 5:14 PM, brianjpetersen
brianjpeter...@gmail.com wrote:
Hi All,
I'm a new matplotlib user on a Windows XP machine running mpl0.99.0 under
Python 2.5. I'm using the default rc file.
While reading through the excellent matplotlib how-to tutorial
(http://matplotlib.sourceforge.net/faq/howto_faq.html), I came across two
useful scripts: one to save a figure with a transparent background, and
one
to resize axes automatically so that labels aren't cut off. I was able
to
run both these examples given on the how-to successfully.
However, I ran into trouble when trying to combine them as follows:
=
import matplotlib.pyplot as plt
import matplotlib.transforms as mtransforms
fig = plt.figure()
ax = fig.add_subplot(111)
ax.plot(range(10))
ax.set_yticks((2,5,7))
labels = ax.set_yticklabels(('really, really, really', 'long', 'labels'))
def on_draw(event):
bboxes = []
for label in labels:
bbox = label.get_window_extent()
# the figure transform goes from relative coords-pixels and we
# want the inverse of that
bboxi = bbox.inverse_transformed(fig.transFigure)
bboxes.append(bboxi)
# this is the bbox that bounds all the bboxes, again in relative
# figure coords
bbox = mtransforms.Bbox.union(bboxes)
if fig.subplotpars.left bbox.width:
# we need to move it over
fig.subplots_adjust(left=1.1*bbox.width) # pad a little
fig.canvas.draw()
return False
fig.canvas.mpl_connect('draw_event', on_draw)
plt.savefig('test.png', transparent=True)
=
In this case, the saved png file is transparent, but the original set of
axes, labels, and plot are visible as well (basically, I have two
identical
plots shifted over one another on a transparent background).
Is there a way to suppress the original output (something akin to
fig.canvas.erase() or fig.canvas.clear(), but I can't seem to figure
it
out) so that the output png only shows the shifted axes and not both
sets?
Interesting! That one really surprised me. It turns out mpl is not
clearing the pixel buffer from the previous draw command. Normally
you don't see this because the call to draw the figure.patch blanks
out the pixel buffer with the background color, but since your figure
patch is transparent you can see the legacy. A call to
renderer.clear() before drawing again will erase the old image
(perhaps we should be doing this by default?)
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
import matplotlib.transforms as mtransforms
fig = plt.figure()
ax = fig.add_subplot(111)
ax.plot(range(10))
ax.set_yticks((2,5,7))
labels = ax.set_yticklabels(('really, really, really', 'long', 'labels'))
def on_draw(event):
bboxes = []
for label in labels:
bbox = label.get_window_extent()
# the figure transform goes from relative coords-pixels and we
# want the inverse of that
bboxi = bbox.inverse_transformed(fig.transFigure)
bboxes.append(bboxi)
# this is the bbox that bounds all the bboxes, again in relative
# figure coords
bbox = mtransforms.Bbox.union(bboxes)
if fig.subplotpars.left bbox.width:
# we need to move it over
fig.subplots_adjust(left=1.1*bbox.width) # pad a little
fig.canvas.get_renderer().clear()
fig.canvas.draw()
return False
fig.canvas.mpl_connect('draw_event', on_draw)
plt.savefig('test.png', transparent=True)
JDH
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
--
View this message in context:
http://old.nabble.com/Transparency-with-fig.canvas.mpl_connect-tp27724532p27738002.html
Sent from the matplotlib - users mailing list archive at Nabble.com.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
[Matplotlib-users] how to increase tick thickness
Dear matplolib users, I am wondering if anyone knows how to increase the tick thickness, that is the tick linewidth? Mine are too thin. Thanks Goekhan and JJ for the help previously on how to increase the tick size, to fix the xtick.major.size in the matplotlib rc. That did make my ticks longer, but I still don't know how to make them 'fatter'. Thanks, Matthew -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] how to increase tick thickness
On Mon, Mar 1, 2010 at 2:27 PM, Matthew MacLeod macl...@eefus.colorado.eduwrote: Dear matplolib users, I am wondering if anyone knows how to increase the tick thickness, that is the tick linewidth? Mine are too thin. Thanks Goekhan and JJ for the help previously on how to increase the tick size, to fix the xtick.major.size in the matplotlib rc. That did make my ticks longer, but I still don't know how to make them 'fatter'. Thanks, Matthew -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users Hi Matthew, JJ's suggestion should work to make the ticks bolder: http://matplotlib.sourceforge.net/users/artists.html#axis-containers (See the lines at the very bottom) In your code you should import matplotlib.pyplot as plt plt.plot(range(10) ax = plt.gca() #for each axis or whichever axis you want you should for line in ax.xaxis.get_ticklines(): line.set_markeredgewidth(3) This makes the x-ticks substantially visible. -- Gökhan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] using the symbol font in TeX plots
On Mon, Mar 1, 2010 at 8:36 AM, Michael Droettboom md...@stsci.edu wrote: Alan G Isaac wrote: Gökhan Sever wrote: For the second idea you mean something as generic as plotting such markers? plt.plot(range(10), linestyle='None', marker=u'※ ') On 3/1/2010 8:33 AM, Michael Droettboom wrote: Yes -- but it can't be quite this simple, since there is already a set of strings that have specific meanings for markers, and we wouldn't want to change that behavior. In order to use an arbitrary character or string, we'd need additional syntax to indicate that's what you want to do. Perhaps naively, I do not see why. A small number of strings have predefined meanings. Just keep documenting that and then test if the provided string is in this set. Otherwise, use the provided string. This seems very nice. If that is too implicit, then adding a markerstr keyword argument seems the right way to go. It would override the marker argument, and any string could be used, getting rid of the above problem. Cheers, Alan Isaac (just a user) What if you want to use the letter 'o' as a marker? That to me seems like a potential source of confusion, as well as a little bit limiting. What would the escaping syntax be to use the letter 'o'? As you suggest, adding an additional kwarg is also a way forward. In that case, though, I would suggest that providing both a marker and markerstr argument should raise an exception. Having implicit overriding rules can often lead to confusion. One downside of the additional kwarg is that you occasionally see code like this: markers = ['o', '.', 'h', 'x'] for data, marker in zip(datasets, markers): plot(data, marker=marker) If one wanted to mix built-in with non-built-in markers that idiom would become much more complex. That's why I proposed sticking to a purely string representation -- I'm just not sure of the best or most obvious one. To me it seems like having only one keyword marker is easier for the sake of simplicity as you have already demonstrated with an example. (Having one keyword to handle all special markers, unicode symbols and strings.) However probably this will need more coding to handle all the cases properly. Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Gökhan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] imshow size limitations?
2010/2/27 David Goldsmith d_l_goldsm...@yahoo.com: ax.imshow(image[0:ny/2+1, 0:nx/2+1]) # upper left corner of image ax.imshow(argW[ny/2+1:-1, 0:nx/2+1]) # lower left corner of image ax.imshow(argW[0:ny/2+1, nx/2+1:-1]) # upper right corner of image ax.imshow(argW[ny/2+1:-1, nx/2+1:-1]) # lower right corner of image Some tiny improvement: ax.imshow(argW[:ny/2+1, :nx/2+1]) ax.imshow(argW[ny/2+1:, :nx/2+1]) ax.imshow(argW[:ny/2+1, nx/2+1:]) ax.imshow(argW[ny/2+1:, nx/2+1:]) The main advantage is that you do not cut off the last pixel row/column by indicing [:-1], which will run until the last index *before* the index -1. a = numpy.asarray([1, 2, 3]) a[:-1] array([1, 2]) Friedrich -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] half-filled markers, two-colors
On Mon, Mar 1, 2010 at 8:12 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: John and T J, L1587 at lines.py def set_mfc(self, val): 'alias for set_markerfacecolor' self.set_markerfacecolor(val, alt=alt) alt is not defined and it currently raises an exception. Fixed -- thanks for the catch. By the way, I noticed that the current approach is to implement fillstyle for EVERY markers. An alternative approach would be using a big enough circle for fillstyle and clip it with the full marker path. The number, of draw_markers call increases but the code will be much simplified and more easy to maintain. Just a thought. We do some significant optimizations in the agg backend in RendererAgg::draw_markers with cached rendered markers, so some extra machinery would have to be pushed into the backend to continue supporting this optimization if we wanted to follow this suggestion. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] half-filled markers, two-colors
John and T J, L1587 at lines.py def set_mfc(self, val): 'alias for set_markerfacecolor' self.set_markerfacecolor(val, alt=alt) alt is not defined and it currently raises an exception. By the way, I noticed that the current approach is to implement fillstyle for EVERY markers. An alternative approach would be using a big enough circle for fillstyle and clip it with the full marker path. The number of draw_markers call increases but the code will be much simplified and more easy to maintain. Just a thought. Regards, -JJ On Tue, Feb 16, 2010 at 9:39 PM, John Hunter jdh2...@gmail.com wrote: On Mon, Feb 15, 2010 at 8:28 PM, T J tjhn...@gmail.com wrote: On Mon, Feb 15, 2010 at 5:22 PM, John Hunter jdh2...@gmail.com wrote: Very nice and thorough work. I think this should be included, but I'll wait to hear from other developers before committing. Could you confirm that the unit tests pass? import matplotlib matplotlib.test() Confirmed on rev 8133: Ran 124 tests in 341.585s FAILED (KNOWNFAIL=2, errors=2) and the errors were something to do with hexbin extents and the figimage method. Great -- I committed this patch in r8138 I think the markerangle would also be a useful contribution, though it would render some of the markers redundant (eg triangle left, right, etc, would all just be triangles with different angles...) That was a concern I had as well, but I suppose ^ v (etc) could just be considered shortcuts to particular angles. Presumably, we would not be removing them. Correct? Also, is the standard to have the angle specified in degrees? So what is more useful: markerangle or markerdeg? We would definitely be leaving these as shortcuts and for backward compatibility. And yes the standard is to use degrees -- for consistency with the text rotation property, we may want markerrotation specified in degrees. The other difference is that when one specifies fillstyle='left', then it would only apply to the marker at 0 degrees. Whereas, marker='v', fillstyle='left', markerangle=0 would correspond to marker='^', fillstyle='right', markerangle=180 (or something like that). You can think about what the right way to do this is. My first inclination is that that left, right, etc, apply to the unrotated marker, and then you apply the rotation. So 'd' with markerrotation=0 and fillstyle='left' would be identical to 'd' with fillstyle='right' and markerrotation=180. But any convention you want to apply would probably be fine as long as it is documented. Note I am not sure this is a terribly useful feature, but it might be marginally useful and it seems like something that could be implemented unobtrusively. So don't kill yourself on it. Thanks again for the nice work. JDH -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] Polar Photometry Plots?
I'd like to be able to generate type C photometry plots with matplotlib. The standard co-ordinate system for these has 0 degrees at the bottom (nadir) of the plot, with values increasing counterclockwise. Is there anyway I can transform the co-ordinates that matplotlib uses to do this? -- Randolph Fritz design machine group, architecture department, university of washington rfr...@u.washington.edu -or- rfritz...@gmail.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
