matplotlib-users Mailing List for matplotlib

Hi, folks! I'm again encountering the problem - imshow generating a
MemoryError exception trying to image a very large array - discussed in this
thread I started almost a year and a half ago.
Question 1) has anything changed in MPL in that time interval which would
provide an "easy" solution?
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
so that each subsequent imshow doesn't cover up the previous imshow and is
placed in the right place relative to each of the other pieces?
Question 3) Would such incremental addition work to get around the memory
limit, or does the fact (if the following statement is in fact correct) that
eventually the entire too-large image needs to be handled doom this strategy
to failure?
Question 4) would I have this problem if I was running 64 bit (i.e., OS, as
well as 64 bit builds of Python, numpy, MPL, etc.), i.e., is it most likely
a memory addressing problem?
Question 5) can anyone suggest any other work-around(s)?
Thanks!
DG
On Sat, Sep 6, 2008 at 4:00 PM, David Goldsmith <d_l...@ya...>wrote:
> Ah, Ich verstehe now. I'll try RGBA-ing it; in the meantime, let me know
> if the colormapping conversion gets changed to 32 bit. Thanks again!
>
> DG
>
> --- On Sat, 9/6/08, Eric Firing <ef...@ha...> wrote:
>
> > From: Eric Firing <ef...@ha...>
> > Subject: Re: [Matplotlib-users] imshow size limitations?
> > To: d_l...@ya...
> > Cc: mat...@li...
> > Date: Saturday, September 6, 2008, 3:13 PM
> > David Goldsmith wrote:
> > > Thanks, Eric!
> > >
> > > --- On Sat, 9/6/08, Eric Firing
> > <ef...@ha...> wrote:
> > >
> > > -- snip OP --
> > >
> > >> It looks to me like you simply ran out of
> > memory--this is
> > >> not an imshow
> > >> problem as such. Your array is about 1e8
> > elements, and as
> > >> floats that
> > >> would be close to a GB--just for that array alone.
> > Do you
> > >
> > > Well, I anticipated that, so I do initialize the
> > storage for the numpy array as numpy.uint8 and have
> > confirmed that the data in the array returned by the
> > function which creates it remains numpy.uint8, so it should
> > "only" be ~100MB (indeed, the .na file into which
> > I tofile it is 85,430 KB, just as it should be for a 10800 x
> > 8100 array of uint8 elements). And the ax.imshow statement
> > doesn't (directly) cause the crash (but I don't know
> > that it isn't making either a float copy or an in-place
> > conversion of the array). So, AFAIK, right up until the
> > statement:
> > >
> > > canvas.print_figure('HiResHex')
> > >
> > > the data being imaged are all numpy.uint8 type.
> >
> > Yes, but it looks to me like they are still getting
> > color-mapped, and
> > this requires conversion to numpy.float. This may be a bad
> > aspect of
> > the mpl design, but it is quite deeply embedded. I suspect
> > the best we
> > could do would be to use float32 instead of float64;
> > certainly for color
> > mapping one does not need 64 bits.
> >
> > Using numpy.uint8 helps only if you are specifying RGBA
> > directly,
> > bypassing the colormapping.
> >
> > >
> > >> really need
> > >> all that resolution?
> > >
> > > Well, there's the rub: I fancy myself a fractal
> > "artist" and I have
> > > access to an HP DesignJet 500ps plotter with a maximum
> > resolution of
> > > 1200 x 600 dpi. For the size images I'm trying to
> > make (I'm hoping to go
> > > even bigger than 36" x 27", but I figured
> > that as a good starting point)
> > > even I regard _that_ resolution as too much - I was
> > thinking of 300 x
> > > 300 dpi (which is its "normal" resolution)
> > as certainly worthy of giving
> > > a try. :-)
> >
> > >> If you do, you will probably have to
> > >> get a much
> > >> more capable machine.
> > >
> > > Possible, but I was hoping to generate at least one
> > "proof" first to determine how hard I'd need
> > to try.
> > >
> > >> Otherwise, you need to knock down
> > >> the size of
> > >> that array before trying to plot or otherwise
> > manipulate
> > >> it.
> > >
> > > Forgive me, but I'd like a more detailed
> > explanation as to why: I
> > > have
> > > ample (~35 GB, just on my built-in disc, much more
> > than that on external
> > > discs) harddisc space - isn't there some way to
> > leverage that?
> >
> > I don't know enough about virtual memory
> > implementations--especially on
> > Win or Mac--to say. In practice, I suspect you would find
> > that as soon
> > as you are doing major swapping during a calculation, you
> > will thrash
> > the disk until you run out of patience.
> >
> >
> > >> With respect to imshow, probably you can get it to
> > handle
> > >> larger images
> > >
> > > Again, imshow doesn't appear to be the culprit
> > (contrary to my
> > > original subject line), rather it would appear to be
> > > canvas.print_figure. (While I'm on the subject of
> > canvas.print_figure,
> > > isn't there some way for MPL to "splash"
> > the image directly to the
> > > screen, without first having to write to a file? I
> > didn't ask this
> > > before because I did eventually want to write the
> > image to a file, but I
> > > would prefer to do so only after I've had a look
> > at it.)
> >
> > It is imshow in the sense that most of the action in mpl
> > doesn't happen
> > when you call imshow or plot or whatever--they just set
> > things up. The
> > real work is done in the backend when you display with
> > show() or write
> > to a file.
> >
> >
> > >> if you feed them in as NxMx4 numpy.uint8 RGBA
> > arrays--but I
> > >> doubt this
> > >> is going to be enough, or the right approach, for
> > your
> > >> present situation.
> > >
> > > Right: I don't see how that would be better than
> > having a single 8
> > > bit
> > > datum at each point w/ color being determined from a
> > color map (which is
> > > how I'd prefer to do it anyway).
> >
> > The way it is better is that it avoids a major operation,
> > including the
> > generation of the double-precision array. The rgba array
> > can go
> > straight to agg.
> >
> > Eric
> >
> >
> > > Thanks again,
> > >
> > > DG
> > >> Eric
> > >>
> > >>> Platform Details: MPL 0.91.2 (sorry, I
> > didn't
> > >> realize I was running such an old version, maybe I
> > just need
> > >> to upgrade?), Python 2.5.2, Windows XP 2002 SP3,
> > 504MB
> > >> physical RAM, 1294MB VM Page size (1000MB init.,
> > 5000MB max)
> > >>> Thanks!
> > >>>
> > >>> DG
>
>
>
>

Hi All,
 I am trying to visualize some more text in an already rather
crowded 2D plot. As this new information I want to display is optional
(it depends on a use choice) but possibly very useful as information,
I would like to add it as text inside my plot, and possibly to add it
in a "smart" way (i.e., with minimum or no overlapping between this
new text and the rest of the plot, like legend does with loc=0).
Now, I have tried to steal the code from legend.py but I am not
getting anywhere, also because I am mixing display coordinates, data
coordinates and wx.DC text extents and I am getting crazy :-(
This is the code I have so far:
 def PositionAnnotation(self, dc, label, dash, x, y):
 """
 Position a matplotlib text instance without overlapping with
the rest of the data.
 :param `dc`: an instance of wx.ClientDC;
 :param `label`: the label to display (2 lines of text);
 :param `dash`: the actual TextWithDash matplotlib class to position
 :param `x`: a list of possible x location (this is fixed)
 :param `y`: a list of possible y location (this is fixed)
 """
 # Stolen from legend.py
 lines = []
 # Here I work with display coordinates (!)
 for handle in self.leftaxis.lines:
 path = handle.get_path()
 trans = handle.get_transform()
 tpath = trans.transform_path(path)
 lines.append(tpath)
 # End of stolen from legend.py
 # Here I work with screen/character coordinates (!)
 width, height, dummy = dc.GetMultiLineTextExtent(label)
 candidates = []
 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
 ox, oy = l, b
 if badness == 0:
 return ox, oy
 candidates.append((badness, (l, b)))
 # Stolen from legend.py
 # 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
 minCandidate = candidates[0]
 for candidate in candidates:
 if candidate[0] < minCandidate[0]:
 minCandidate = candidate
 ox, oy = minCandidate[1]
 return ox, oy
This code is not doing anything useful as I always get a badness of 0,
although I can see that the new text overlaps quite a lot of other
artists.
Does anyone have some suggestion on how to improve the code?
Thank you in advance.
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
http://thedoomedcity.blogspot.com/

http://www.friedrichromstedt.org/python/pyclip/a01.Zerteilung.pdf
(It's unfortunately in german, but the graphics are self-explaining)
A school mate working together with me on the project has worked that out.
H = number of corners of the front triangle lying inside of the back triangle
V = number of corners of the back triangle lying inside of the front triangle
S = number of the collinear edges of the two triangles
Z = number of intersection points of the two tringles' edges, minus
the number of those occuring because of collinear edges.
Red: front triangle
Black: back triangle
Green: subdivision lines in the back triangle.
I will check my implementation in C++ today. I will maybe need some
advice in making a Python module out of it.
Friedrich

Hi,
I am a fan of the STIX sans serif typeface for mathtext, but I was
wondering if it was possible to use this typeface for non-mathtext
text as well. My main use for this is ticklabels, which seem to render
in the non-mathtext font no matter what I do. I have tried using
ax.xaxis.set_major_formatter(P.ScalarFormatter(useMathText=True))
to force the (scalar) major ticks to use mathtext and thus stixsans,
but this does not work. Am I doing something wrong here?
A better solution (for me) would be to use STIX sans serif faces as
the regular font, ie something like
rcParams["font.sans-serif"] = 'stixsans'
I know this is possible for serif fonts, and I know that a post to the
list back in 2008 noted that it was not (at that time) possible for
sans-serifs. I am curious to know if there has been any progress on
allowing STIX sans-serifs in non-mathtext text.
thanks,
Jeff Oishi

All,
On: http://matplotlib.sourceforge.net/users/artists.html
In the Axes Container section, you can see in what follows that I got some very different responses than what is shown on the page:
In [1]: fig=figure()
In [3]: ax=fig.add_subplot(111)
In [4]: rect=matplotlib.patches.Rectangle((1,1),width=5,height=12)
In [5]: print rect.get_axes()
------> print(rect.get_axes())
None
In [6]: print rect.get_transform()
------> print(rect.get_transform())
BboxTransformTo(Bbox(array([[ 1., 1.],
 [ 6., 13.]])))
In [7]: ax.add_patch(rect)
Out[7]: <matplotlib.patches.Rectangle object at 0x2144db0>
In [8]: print rect.get_axes()
------> print(rect.get_axes())
Axes(0.125,0.1;0.775x0.8)
In [9]: print rect.get_transform()
------> print(rect.get_transform())
CompositeGenericTransform(BboxTransformTo(Bbox(array([[ 1., 1.],
 [ 6., 13.]]))), CompositeGenericTransform(TransformWrapper(BlendedAffine2D(IdentityTransform(),IdentityTransform())), CompositeAffine2D(BboxTransformFrom(TransformedBbox(Bbox(array([[ 0., 0.],
 [ 1., 1.]])), TransformWrapper(BlendedAffine2D(IdentityTransform(),IdentityTransform())))), BboxTransformTo(TransformedBbox(Bbox(array([[ 0.125, 0.1 ],
 [ 0.9 , 0.9 ]])), BboxTransformTo(TransformedBbox(Bbox(array([[ 0., 0.],
 [ 8., 6.]])), Affine2D(array([[ 80., 0., 0.],
 [ 0., 80., 0.],
 [ 0., 0., 1.]])))))))))
In [10]: print ax.transData
-------> print(ax.transData)
CompositeGenericTransform(TransformWrapper(BlendedAffine2D(IdentityTransform(),IdentityTransform())), CompositeAffine2D(BboxTransformFrom(TransformedBbox(Bbox(array([[ 0., 0.],
 [ 1., 1.]])), TransformWrapper(BlendedAffine2D(IdentityTransform(),IdentityTransform())))), BboxTransformTo(TransformedBbox(Bbox(array([[ 0.125, 0.1 ],
 [ 0.9 , 0.9 ]])), BboxTransformTo(TransformedBbox(Bbox(array([[ 0., 0.],
 [ 8., 6.]])), Affine2D(array([[ 80., 0., 0.],
 [ 0., 80., 0.],
 [ 0., 0., 1.]]))))))))
In [11]: print ax.get_xlim()
-------> print(ax.get_xlim())
(0.0, 1.0)
In [12]: print ax.dataLim.get_bounds()
-------> print(ax.dataLim.get_bounds())
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
/Library/Frameworks/Python.framework/Versions/6.0.0/Examples/matplotlib-0.99.1.1/event_handling/<ipython console> in <module>()
AttributeError: 'Bbox' object has no attribute 'get_bounds'
In [13]: ax.autoscale_view()
In [14]: print ax.get_xlim()
-------> print(ax.get_xlim())
(1.0, 6.0)
In [15]: ax.figure.canvas.draw()
David.

On Fri, Feb 26, 2010 at 6:35 PM, mikey <abc...@go...> wrote:
> Sorry a rather stupid question as there are '.'s available. Although I
> wouldn't mind knowing if it's possible to tinker with the sizes of
> 'o's and '.'s.
See the "markersize" parameter
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.plot
JDH

On Fri, Feb 26, 2010 at 6:29 PM, mikey <abc...@go...> wrote:
> Hi there,
>
> I've just made script for displaying discrete data clustered in boxes
> on my graph. The plots are plotted with plt.plot(x,y,'o') and the 'o's
> seem a reasonable size on screen but when I render it to file they
> look huge so I'd like to reduce their size. Does anyone know how this
> is done?
>
> Regards,
>
> Mikey
>
>
Hey,
Try:
I[1]: plt.plot(range(100), "o", markersize=100)
I[2]: plt.plot(range(100), "o", markersize=1)
I[3]: plt.figure(); plt.plot(range(100), "o", ms=1)
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
-- 
Gökhan

> -----Original Message-----
> From: mikey [mailto:abc...@go...]
> Sent: Friday, February 26, 2010 4:29 PM
> To: mat...@li...
> Subject: [Matplotlib-users] Change the size of the plotted 'o's ?
> 
> Hi there,
> 
> I've just made script for displaying discrete data clustered in boxes
> on my graph. The plots are plotted with plt.plot(x,y,'o') and the 'o's
> seem a reasonable size on screen but when I render it to file they
> look huge so I'd like to reduce their size. Does anyone know how this
> is done?
Mike,
There are a couple of ways. See below:
# untested, might have typos ~~~~
import numpy as np
import matplotlib.pyplot as pl
x = np.random.randn(20)
fig = pl.figure()
ax = pl.add_subplot(1,1,1)
# you can specify the marker size two ways directly:
ax.plot(x, 'ko', markersize=4) # size in points
ax.plot(x, 'bs', ms=4) % ms is just an alias for markersize
# or you can specify it after the plotting:
X = ax.plot(x, 'ko') # X is a *list* of line2d objects...
X[0].set_markersize(4) # set_ms works too
# or...
pl.setp(Y, markersize=4) # again, ms works.
# ~~~~~~~~
For a list of all the properties you can tweak, type:
pl.getp(<object>)
HTH,
-paul

Hi there,
I've just made script for displaying discrete data clustered in boxes
on my graph. The plots are plotted with plt.plot(x,y,'o') and the 'o's
seem a reasonable size on screen but when I render it to file they
look huge so I'd like to reduce their size. Does anyone know how this
is done?
Regards,
Mikey

Sorry a rather stupid question as there are '.'s available. Although I
wouldn't mind knowing if it's possible to tinker with the sizes of
'o's and '.'s.
Thanks,
Mikey
On 27 February 2010 00:29, mikey <abc...@go...> wrote:
> Hi there,
>
> I've just made script for displaying discrete data clustered in boxes
> on my graph. The plots are plotted with plt.plot(x,y,'o') and the 'o's
> seem a reasonable size on screen but when I render it to file they
> look huge so I'd like to reduce their size. Does anyone know how this
> is done?
>
> Regards,
>
> Mikey
>