matplotlib-users Mailing List for matplotlib

I tried pcolor, but it seems to have much higher memory usage ... the
data set I'm using renders the map using contourf(x,y,z,100)
relatively quickly (~10 sec) and with reasonable memory usage, and
will imshow(z) even faster (although, as I said, without projection) ,
but pcolor(x,y,z) fails with a MemoryError after running for ~5
minutes.

On Fri, Sep 5, 2008 at 6:00 AM, Michael Droettboom <md...@st...> wrote:
> Erik Tollerud wrote:
>>
>> I've been playing with some of the projections in matplotlib,
>> recently, and have some questions/noticed some odd behavior:
>>
>> 1. Is there any way to activate a projection mode with the pyplot
>> interface other than the subplot(111,projection='whatever') method a
>> la /examples/api/custom_projection_example.py ?  Along these same
>> lines, is the projection feature documented in greater detail
>> somewhere?  About everything I've figured out has come from
>> custom_projection_example.py ...
>>
>
> There is some additional documentation in the new documentation here:
>
> http://matplotlib.sourceforge.net/doc/html/devel/add_new_projection.html
>>
>> 2. I have a skymap I would like to plot using a particular projection
>> - what I've been doing so far is specifying x and y coordinates using
>> mgrid and calling contourf(x,y,data,100) to approximate this.  But
>> what I'd rather do is something like
>> imshow(data,extent=[-pi,pi,-pi/2,pi/2]) ... when I call that with a
>> projection axis activated, the projection isn't honored - the image
>> just appears as a regular square box.  Is there any way to get imshow
>> to respect the projection?
>>
>
> As Jae-Joon suggested, try pcolor.  It will be slower (and there are no
> interpolation options), but it should use the custom projection.  imshow is
> really optimized for uniform, rectilinear images.
>
> Cheers,
> Mike
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>



-- 
Erik Tollerud
Graduate Student
Center For Cosmology
Department of Physics and Astronomy
2142 Frederick Reines Hall
University of California, Irvine
Office Phone: (949)824-2587
Cell: (651)307-9409
eto...@uc...

 

Hello. I made a figure from the Postscript backend. Everything works fine except the fontweight property. I tried to set fontweight="bold" in both pylab.suptitle and pylab.text, but both of them remains in normal weight. What makes it worse is, if the title is "ubuntu-desktop", in the .ps file the title becomes just "ubuntu". However, if I set rcParam["font.weight"] in the beginning of the python file, everything becomes bold. I checked out the latest version from SVN but no luck.

The fontweight property works fine in Agg backend.

Thanks!

_________________________________________________________________
See how Windows Mobile brings your life together—at home, work, or on the go.
http://clk.atdmt.com/MRT/go/msnnkwxp1020093182mrt/direct/01/

Johann Cohen-Tanugi wrote:
> thanks Eric! Could you provide me with an executive summary as to 
> pcolorfast vs imshow? Is it essentially a matter of speed?

It is more generality than speed.

imshow is for genuine image data: an array of pixel values, with the 
assumption that the pixels are square.  imshow supports interpolation.

pcolorfast works for any rectilinear grid, and depending on the 
characteristics of that grid, it uses the same underlying code as 
imshow, or a slightly slower but more general code for irregular 
rectangular grids (NonUniformImage), or the considerably slower quadmesh 
code if the grid is not rectangular.  Detection of the kind of grid, and 
therefore the algorithm to use, is based mainly on the presence and 
dimensionality of the X and Y input arrays.

pcolorfast does not support interpolation; it always displays 
quadrilaterals of uniform color.

pcolorfast differs from pcolor and pcolormesh in that it does not 
support drawing grid boundaries, it is much faster with *agg backends, 
and there are some differences in the way input arguments are handled. 
Also, there is as yet no pyplot interface to it; I thought that some api 
changes might still be in order, and do not want to put pcolorfast into 
pyplot until its api is stable.


> Also, I tried to add a colorbar but failed. What is the correct invocation?

Here is one way:

import numpy as np
x, y = np.random.randn(2, 100000)
H, xedges, yedges = np.histogram2d(x, y, bins=50)
fig = figure()
ax = fig.add_subplot(111)
im = ax.pcolorfast(xedges, yedges, H)
cb = fig.colorbar(im)
draw()

Eric

> That said, there has been for some time experimental functionality to
> support drawing some elements "pre-rasterized" (meaning as images) to
> save on file size.  This is actually already working in some backends
> (including PDF), it just hasn't been exposed to the user in a nice way
> yet.  Eric Bruning had an elegant solution to add pre/post draw
> callbacks that would have really helped with this [1], but I don't know
> where all that ended.

The precursor thread to the one Mike linked:
http://www.mail-archive.com/mat...@li.../msg02659.html

I had proposed a get/set_rasterized method on each artist, and then
some internal details to make sure the rasterized property was checked
before the artist was drawn. That allowed raster rendering on a
per-artist basis. The patch in the thread above shows the changes
needed, which weren't many, so you could try to apply them if you
build matplotlib yourself.

I think the discussion wound up trailing off with nothing merged to
trunk since there were some broader design decisions needed on event
handling, etc.

-Eric

> It would be great to pick that ball up and get it
> going again.  If nothing else, it should be an easy fix to add a
> "rasterized" kwarg to pcolormesh -- but I don't recall if that's the
> interface that we arrived at the last time this came up.
>
> [1]
> http://www.mail-archive.com/mat...@li.../msg03490.html
>
> Cheers,
> Mike
>
> Jose Gómez-Dans wrote:
>> Hi,
>> In a previous email I pointed out that I was having problems with pcolormesh
>> output as a PDF: the files are really big and impractical even for smallish
>> arrays (1000x1000 pixels). I don't have that problem using imshow, which
>> presumably resamples the image or somesuch wizardry :) Here's an example
>>
>> import pylab
>> data = pylab.randn((512*512)).reshape((512,512))
>> #First imshow. I use the dpi keyword "just in case"
>> pylab.imshow ( data, interpolation='nearest')
>> pylab.savefig ("/tmp/imshow_72.pdf",dpi=72)
>> pylab.savefig ("/tmp/imshow.pdf")
>> #Now pcolormesh
>> pylab.pcolormesh ( data )
>> pylab.savefig ("/tmp/pcolor_72.pdf",dpi=72)
>> pylab.savefig ("/tmp/pcolor.pdf")
>>
>> This results in the following files:
>> 166K /tmp/imshow_72.pdf
>> 307K /tmp/imshow.pdf
>> 2.6M /tmp/pcolor_72.pdf
>> 2.7M /tmp/pcolor.pdf
>>
>> So: in the imshow case, the dpi keyword makes a difference (good!), but if you
>> compare the pcolormesh and imshow filesizes you immediately notice a large
>> difference. The rendering of the pcolor files is also very slow, line-by-line
>> sort of thing. I presume that the different patches are stored as vectors,
>> and that's why there's no change with setting dpi to 300 or to 72.
>>
>> Is this the expected behaviour?
>> Thanks,
>> J

Well, I've figured out half of it: the RGB data appears to be in <cmap>._segmentdata, an RGB-keyed dictionary of tuples of triples, but, looking at this for the jet cmap, e.g., I'm confused, 'cause the red and and blue tuples have five such triples, but the green tuple has six triples, so how exactly are these remapped to an RGB array?  Thanks!

DG
--- On Tue, 9/9/08, David Goldsmith <d_l...@ya...> wrote:

> From: David Goldsmith <d_l...@ya...>
> Subject: Re: [Matplotlib-users] Next problem: pixel-to-pixel alpha variation
> To: mat...@li...
> Date: Tuesday, September 9, 2008, 9:15 AM
> Thanks, John and Michael.
> 
> Yeah, Michael, that's what I'm doing now, but
> eventually (like, now) I'd like to do what John implies
> is possible, i.e., "invert" a cm back to its RGB
> table - John (or anyone) can you short-cut the learning
> process for me w/ a code example of how to do this? :-) 
> Thanks!
> 
> DG
> --- On Tue, 9/9/08, Michael Droettboom
> <md...@st...> wrote:
> 
> > From: Michael Droettboom <md...@st...>
> > Subject: Re: [Matplotlib-users] Next problem:
> pixel-to-pixel alpha variation
> > To: d_l...@ya...
> > Cc: mat...@li...
> > Date: Tuesday, September 9, 2008, 7:22 AM
> > David Goldsmith wrote:
> > > Hi, folks.  OK, I'm trying to set the alpha
> > channel, pixel by pixel, using figimage w/ the data
> being of
> > the "luminance" type (i.e., an MxN array). 
> The
> > Users Guide indicates that figimage takes an alpha=
> keyword
> > argument, and it doesn't crash when I pass an
> array for
> > this value, but subsequently when I try to draw it
> using
> > fig.draw(canvas.get_renderer()), I get:
> > >
> > >   
> > >>>> fig.draw(canvas.get_renderer())
> > >>>>         
> > > Traceback (most recent call last):
> > >   File "<stdin>", line 1, in
> > <module>
> > >   File
> >
> "C:\python25\lib\site-packages\matplotlib\figure.py",
> > line 607, in draw
> > >     im.draw(renderer)
> > >   File
> >
> "C:\python25\lib\site-packages\matplotlib\image.py",
> > line 597, in draw
> > >     im = self.make_image()
> > >   File
> >
> "C:\python25\lib\site-packages\matplotlib\image.py",
> > line 583, in make_im
> > > age
> > >     x = self.to_rgba(self._A, self._alpha)
> > >   File
> >
> "C:\python25\lib\site-packages\matplotlib\cm.py",
> > line 76, in to_rgba
> > >     x = self.cmap(x, alpha=alpha, bytes=bytes)
> > >   File
> >
> "C:\python25\lib\site-packages\matplotlib\colors.py",
> > line 423, in __call
> > > __
> > >     alpha = min(alpha, 1.0) # alpha must be
> between 0
> > and 1
> > > ValueError: The truth value of an array with more
> than
> > one element is ambiguous.
> > >  Use a.any() or a.all()
> > >
> > > which to me "smells" as if the
> array-valued
> > alpha is the problem.  
> > >
> > > Clearly (?) I can do what I'm after if I use
> MxNx4
> > data, but is that the only way to have a varying
> alpha?
> > >   
> > The alpha parameter always takes only a single
> (global)
> > value, and the 
> > only way to do pixel-by-pixel alpha is an MxNx4 array.
>  It
> > should be 
> > fairly straightforward to create this array by
> > concatenating together 
> > three copies of the luminance and one copy of your
> alpha,
> > though.
> > 
> > Something like:
> > 
> >   # lum is MxN, alpha is MxN
> >   lum = lum.reshape((M, N, 1))
> >   alpha = alpha.reshape((M, N, 1))
> >   rgba = numpy.concatenate((lum, lum, lum, alpha))
> > 
> > (There might be an even more straightforward way ---
> > I'm not much of a 
> > numpy expert...)
> > 
> > Cheers
> > Mike
> > 
> > -- 
> > Michael Droettboom
> > Science Software Branch
> > Operations and Engineering Division
> > Space Telescope Science Institute
> > Operated by AURA for NASA
> 
> 
>       
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users


      

Thanks, John and Michael.

Yeah, Michael, that's what I'm doing now, but eventually (like, now) I'd like to do what John implies is possible, i.e., "invert" a cm back to its RGB table - John (or anyone) can you short-cut the learning process for me w/ a code example of how to do this? :-)  Thanks!

DG
--- On Tue, 9/9/08, Michael Droettboom <md...@st...> wrote:

> From: Michael Droettboom <md...@st...>
> Subject: Re: [Matplotlib-users] Next problem: pixel-to-pixel alpha variation
> To: d_l...@ya...
> Cc: mat...@li...
> Date: Tuesday, September 9, 2008, 7:22 AM
> David Goldsmith wrote:
> > Hi, folks.  OK, I'm trying to set the alpha
> channel, pixel by pixel, using figimage w/ the data being of
> the "luminance" type (i.e., an MxN array).  The
> Users Guide indicates that figimage takes an alpha= keyword
> argument, and it doesn't crash when I pass an array for
> this value, but subsequently when I try to draw it using
> fig.draw(canvas.get_renderer()), I get:
> >
> >   
> >>>> fig.draw(canvas.get_renderer())
> >>>>         
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in
> <module>
> >   File
> "C:\python25\lib\site-packages\matplotlib\figure.py",
> line 607, in draw
> >     im.draw(renderer)
> >   File
> "C:\python25\lib\site-packages\matplotlib\image.py",
> line 597, in draw
> >     im = self.make_image()
> >   File
> "C:\python25\lib\site-packages\matplotlib\image.py",
> line 583, in make_im
> > age
> >     x = self.to_rgba(self._A, self._alpha)
> >   File
> "C:\python25\lib\site-packages\matplotlib\cm.py",
> line 76, in to_rgba
> >     x = self.cmap(x, alpha=alpha, bytes=bytes)
> >   File
> "C:\python25\lib\site-packages\matplotlib\colors.py",
> line 423, in __call
> > __
> >     alpha = min(alpha, 1.0) # alpha must be between 0
> and 1
> > ValueError: The truth value of an array with more than
> one element is ambiguous.
> >  Use a.any() or a.all()
> >
> > which to me "smells" as if the array-valued
> alpha is the problem.  
> >
> > Clearly (?) I can do what I'm after if I use MxNx4
> data, but is that the only way to have a varying alpha?
> >   
> The alpha parameter always takes only a single (global)
> value, and the 
> only way to do pixel-by-pixel alpha is an MxNx4 array.  It
> should be 
> fairly straightforward to create this array by
> concatenating together 
> three copies of the luminance and one copy of your alpha,
> though.
> 
> Something like:
> 
>   # lum is MxN, alpha is MxN
>   lum = lum.reshape((M, N, 1))
>   alpha = alpha.reshape((M, N, 1))
>   rgba = numpy.concatenate((lum, lum, lum, alpha))
> 
> (There might be an even more straightforward way ---
> I'm not much of a 
> numpy expert...)
> 
> Cheers
> Mike
> 
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA


      

Adam,

I needed a same thing a while ago and I ended up with a custom class.
Although this need some more work, try and see if it fits your need in
case you want to avoid the little arithmetic that John mentioned.
The python file and a example plot are attached.

I wanted the padding between the subaxes is conserved even if the
figure size changes (and something more), so the implementation got
little bit hackish and much longer than I initially expected, but it
works for me.
A simple use case is included in the file (I'm afraid that there are
not much documentation).


Briefly,


import matplotlib.pyplot as plt
from mpl_multiaxes import MultiPane_Subplot

F = plt.figure(1)
F.clf()

mp = MultiPane_Subplot(F, subplot_pos=(1, 1, 1),
                       nrows_ncols = (3, 2),
                       n_pane=5,
                       pane_direction="row", # or "column"
                       axes_pad_inch=0.0,
                       )

F.add_subplot(mp)


In the above example, MultiPane_Subplot is a subclass of the Subplot
which contains subaxes. You set number of rows and columns for your
subaxes grid. If the number of subaxes is smaller than nrows*ncols,
you explicitly set it with n_pane.

After this, each subaxes is accessed as mp[0], mp[1], and so on. They
are subclass of Axes. So you may use any drawing method that Axes
class has. As mp is subclass of Subplot, it is also an axes. I
consider it as a kind of master axes. Anything you plot in this axes
is also drawn in all of its subaxes.  Also note that xaxis and yaxis
are shared among these subaxes, therefore they have same xlim, ylim.
etc.

Regards,

-JJ


On Tue, Sep 9, 2008 at 8:12 AM, Adam <ada...@gm...> wrote:
>
> John,
>
>> By default, matplotlib will resize your axes to preserve the aspect
>> ratio of your image, which in the case of your 23x25 images is not
>> equal.  You can override this behavior by setting aspect='auto'
>>
>> for i in range(6):
>>  fig1.add_subplot(2,3,i+1)
>>  pylab.imshow(data, aspect='auto')
>
> This gets rid of the blank space, but at the expense of the aspect ratio, as
> you mention.  Isn't there away to preserve the aspect ratios of the
> individual
> sub-images, and just remove the white space between them?  I really to not
> want to mess with the images themselves.
>
> cheers,
> adam.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Ok, I'm stupid, changing the resolution value and all goes right.
Sorry

Lionel Roubeyrie a écrit :
> Hi all,
> the new polar projection gives me a strange behavour by interpolating 
> each simple line between two consecutives points. Where I just want 
> points at specified coordinates and lines connecting them, between each 
> pairs appears a interpolated line in polar projection with multiple points.
> Looking in the documentation doesn't give an alternative. Is there a way 
> to have just "simples" lines?
> thanks
> 
> ##################
> from pylab import *
> theta = arange(0, 360, 36)
> r = [5,1] * (len(theta)/2)
> polar(radians(theta), r, 'o-')
> show()
> ##################
> 

-- 
Lionel Roubeyrie - lro...@li...
Chargé d'études et de maintenance
LIMAIR - la Surveillance de l'Air en Limousin
http://www.limair.asso.fr

pcolormesh is outputting the data as vectors, since the mesh can be 
non-rectilinear, that's really the only thing that PDF supports.  
Besides, that's the only way to get a truly resolution-independent PDF.  
Since imshow is limited to uniform, rectilinear images, and PDF has 
built-in support for those, the file is much smaller and the drawing 
more efficient.

That said, there has been for some time experimental functionality to 
support drawing some elements "pre-rasterized" (meaning as images) to 
save on file size.  This is actually already working in some backends 
(including PDF), it just hasn't been exposed to the user in a nice way 
yet.  Eric Bruning had an elegant solution to add pre/post draw 
callbacks that would have really helped with this [1], but I don't know 
where all that ended.  It would be great to pick that ball up and get it 
going again.  If nothing else, it should be an easy fix to add a 
"rasterized" kwarg to pcolormesh -- but I don't recall if that's the 
interface that we arrived at the last time this came up.

[1] 
http://www.mail-archive.com/mat...@li.../msg03490.html

Cheers,
Mike

Jose Gómez-Dans wrote:
> Hi,
> In a previous email I pointed out that I was having problems with pcolormesh 
> output as a PDF: the files are really big and impractical even for smallish 
> arrays (1000x1000 pixels). I don't have that problem using imshow, which 
> presumably resamples the image or somesuch wizardry :) Here's an example
>
> import pylab
> data = pylab.randn((512*512)).reshape((512,512))
> #First imshow. I use the dpi keyword "just in case"
> pylab.imshow ( data, interpolation='nearest')
> pylab.savefig ("/tmp/imshow_72.pdf",dpi=72)
> pylab.savefig ("/tmp/imshow.pdf")
> #Now pcolormesh
> pylab.pcolormesh ( data )
> pylab.savefig ("/tmp/pcolor_72.pdf",dpi=72)
> pylab.savefig ("/tmp/pcolor.pdf")
>
> This results in the following files:
> 166K /tmp/imshow_72.pdf
> 307K /tmp/imshow.pdf
> 2.6M /tmp/pcolor_72.pdf
> 2.7M /tmp/pcolor.pdf
>
> So: in the imshow case, the dpi keyword makes a difference (good!), but if you 
> compare the pcolormesh and imshow filesizes you immediately notice a large 
> difference. The rendering of the pcolor files is also very slow, line-by-line 
> sort of thing. I presume that the different patches are stored as vectors, 
> and that's why there's no change with setting dpi to 300 or to 72.
>
> Is this the expected behaviour? 
> Thanks,
> J
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi all,
the new polar projection gives me a strange behavour by interpolating 
each simple line between two consecutives points. Where I just want 
points at specified coordinates and lines connecting them, between each 
pairs appears a interpolated line in polar projection with multiple points.
Looking in the documentation doesn't give an alternative. Is there a way 
to have just "simples" lines?
thanks

##################
from pylab import *
theta = arange(0, 360, 36)
r = [5,1] * (len(theta)/2)
polar(radians(theta), r, 'o-')
show()
##################

-- 
Lionel Roubeyrie - lro...@li...
Chargé d'études et de maintenance
LIMAIR - la Surveillance de l'Air en Limousin
http://www.limair.asso.fr

Hi,
In a previous email I pointed out that I was having problems with pcolormesh 
output as a PDF: the files are really big and impractical even for smallish 
arrays (1000x1000 pixels). I don't have that problem using imshow, which 
presumably resamples the image or somesuch wizardry :) Here's an example

import pylab
data = pylab.randn((512*512)).reshape((512,512))
#First imshow. I use the dpi keyword "just in case"
pylab.imshow ( data, interpolation='nearest')
pylab.savefig ("/tmp/imshow_72.pdf",dpi=72)
pylab.savefig ("/tmp/imshow.pdf")
#Now pcolormesh
pylab.pcolormesh ( data )
pylab.savefig ("/tmp/pcolor_72.pdf",dpi=72)
pylab.savefig ("/tmp/pcolor.pdf")

This results in the following files:
166K /tmp/imshow_72.pdf
307K /tmp/imshow.pdf
2.6M /tmp/pcolor_72.pdf
2.7M /tmp/pcolor.pdf

So: in the imshow case, the dpi keyword makes a difference (good!), but if you 
compare the pcolormesh and imshow filesizes you immediately notice a large 
difference. The rendering of the pcolor files is also very slow, line-by-line 
sort of thing. I presume that the different patches are stored as vectors, 
and that's why there's no change with setting dpi to 300 or to 72.

Is this the expected behaviour? 
Thanks,
J

David Goldsmith wrote:
> Hi, folks.  OK, I'm trying to set the alpha channel, pixel by pixel, using figimage w/ the data being of the "luminance" type (i.e., an MxN array).  The Users Guide indicates that figimage takes an alpha= keyword argument, and it doesn't crash when I pass an array for this value, but subsequently when I try to draw it using fig.draw(canvas.get_renderer()), I get:
>
>   
>>>> fig.draw(canvas.get_renderer())
>>>>         
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "C:\python25\lib\site-packages\matplotlib\figure.py", line 607, in draw
>     im.draw(renderer)
>   File "C:\python25\lib\site-packages\matplotlib\image.py", line 597, in draw
>     im = self.make_image()
>   File "C:\python25\lib\site-packages\matplotlib\image.py", line 583, in make_im
> age
>     x = self.to_rgba(self._A, self._alpha)
>   File "C:\python25\lib\site-packages\matplotlib\cm.py", line 76, in to_rgba
>     x = self.cmap(x, alpha=alpha, bytes=bytes)
>   File "C:\python25\lib\site-packages\matplotlib\colors.py", line 423, in __call
> __
>     alpha = min(alpha, 1.0) # alpha must be between 0 and 1
> ValueError: The truth value of an array with more than one element is ambiguous.
>  Use a.any() or a.all()
>
> which to me "smells" as if the array-valued alpha is the problem.  
>
> Clearly (?) I can do what I'm after if I use MxNx4 data, but is that the only way to have a varying alpha?
>   
The alpha parameter always takes only a single (global) value, and the 
only way to do pixel-by-pixel alpha is an MxNx4 array.  It should be 
fairly straightforward to create this array by concatenating together 
three copies of the luminance and one copy of your alpha, though.

Something like:

  # lum is MxN, alpha is MxN
  lum = lum.reshape((M, N, 1))
  alpha = alpha.reshape((M, N, 1))
  rgba = numpy.concatenate((lum, lum, lum, alpha))

(There might be an even more straightforward way --- I'm not much of a 
numpy expert...)

Cheers
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Tue, Sep 9, 2008 at 9:03 AM, Michael Droettboom <md...@st...> wrote:
> You're right: multi-column legends aren't implemented.
>
> There have been a number of points raised lately around the layout of
> legends (such as baseline alignment), that are starting to add up to a
> push for a (partial) rewrite of the legend code.  Unfortunately, I don't
> think anyone has stepped up with time available to work on it.  But I
> think this should go on the list of things to consider, assuming we can
> come up with a nice clean interface to present to the user.  It would be
> helpful to collect use cases for that.  For example, would an option
> "numcols" be enough (and the legend would just layout the text in that
> number of columns), or would you want/need more control over where
> individual elements are placed?
>
> Of course, we're always looking for new developers, and if you have the
> motivation to work on this, I'm sure the various people on this list
> would be happy to help you work through it.
>
> Cheers,
> Mike

I'd be willing to put some time in on that... I've not ever
contributed code for anything though, so I'll be on a learning curve.
I've had this problem myself.  I would think a number of columns or a
number of rows argument either would work.. just restrict based on one
or the other, and if both are given... not sure about that one.
What's a sensible way to ignore one or the other?

On Tue, Sep 9, 2008 at 2:02 AM, Eric Firing <ef...@ha...> wrote:

> Evan Mason wrote:
>
>> Hi, wonder if anyone can help me with path and bbox.  I have a set of
>> ocean drifter tracks and I want to know if they pass through a particular
>> boxed area.  This is straightforward to do but I wanted to try to do it with
>> matplotlib.transforms and matplotlib.path, which look well-suited to this
>> kind of task using 'intersects_bbox'.
>>
>> The essence of my code is below.  I have a single drifter track (lon, lat)
>> and have defined a boxed area.  At no time does the drifter approach or
>> enter the box - however, the final line,
>>
>>    print track.intersects_bbox(bbox)
>>
>> returns True, which it shouldn't.  In total I have 340 tracks.  My code
>> says 74 pass though the box, but by counting there should be only about 9.
>>  Any help appreciated, thanks, Evan
>>
>>
>> import numpy as N
>> import numpy.ma <http://numpy.ma> as MA
>> import matplotlib.transforms as BB
>> import matplotlib.path as PP
>>
>> In [200]: lon
>> Out[200]:
>> masked_array(data = [-15.52 -15.521 -15.541 ..., -- -- --],
>>      mask = [False False False ...,  True  True  True],
>>      fill_value=1e+20)
>>
>> In [201]: lat
>> Out[201]:
>> masked_array(data = [29.2 29.2 29.196 ..., -- -- --],
>>      mask = [False False False ...,  True  True  True],
>>      fill_value=1e+20)
>>
>> In [202]: len(lon), len(lat)
>> Out[202]: (3750, 3750)
>>
>> track = MA.transpose([lon, lat])
>> track = PP.Path(track)
>> bbox = BB.Bbox.from_extents(-15.95, 29.6, -15.9, 29.65)
>>
>> In [206]: print track.intersects_bbox(bbox)
>> 1
>>
>
> Evan,
>
> Can you strip the problem down more?  That is, find one track that is
> misdiagnosed, and then try to find the shortest segment of it that still
> gets misdiagnosed.  You could try subsampling and/or chopping chunks off the
> ends.  If you can get it down to a track with only a few points, so that you
> can email a very short but complete script with illustrative data, that
> would make it much easier for someone to figure out what is going on.
>
> I suspect it is related to the masked values.  If you strip the masked
> points out of your lon and lat arrays, do you get the same result?
> Try making an example with only 3 points, say with the middle one masked,
> and then unmasked.
>
> Eric
>


Eric, I tried what you say about masked values, and that has helped.
However there are still a few tracks that creep through.  Below is a short
script that shows what I mean.  It loads in a matfile with the drifter
track, which I will send to you separately.

# %run path_example.py

import pylab as P
import numpy as N
from scipy import io
from matplotlib.transforms import Bbox as BB
import matplotlib.path as PP

P.close('all')
# Load drifter track (lon, lat)
lonlat = io.loadmat('lonlat')
lon    = N.squeeze(lonlat.values()[1])
lat    = N.squeeze(lonlat.values()[0])

# Set up box
box = BB.from_extents(-16.6, 28.05, -15.65, 28.15)
bx = [box.xmin, box.xmax, box.xmax, box.xmin, box.xmin]
by = [box.ymin, box.ymin, box.ymax, box.ymax, box.ymin]

track_all = N.transpose([lon, lat])
track_1   = N.transpose([lon[81:295], lat[81:295]])
track_2   = N.transpose([lon[81:290], lat[81:290]])

track_all = PP.Path(track_all)
track_1   = PP.Path(track_1)
track_2   = PP.Path(track_2)

# Test if drifter passes thru box (it doesn't so should be 0)
print track_all.intersects_bbox(box), 'Should be 0'
print   track_1.intersects_bbox(box), 'Should be 0'
print   track_2.intersects_bbox(box), 'Should be 0'

P.figure()
P.plot(lon, lat, 'r', lw=0.3)
P.plot(lon[81:290], lat[81:290], 'g', lw=0.5)
P.plot(bx, by, 'b')

P.show()

You're right: multi-column legends aren't implemented.

There have been a number of points raised lately around the layout of 
legends (such as baseline alignment), that are starting to add up to a 
push for a (partial) rewrite of the legend code.  Unfortunately, I don't 
think anyone has stepped up with time available to work on it.  But I 
think this should go on the list of things to consider, assuming we can 
come up with a nice clean interface to present to the user.  It would be 
helpful to collect use cases for that.  For example, would an option 
"numcols" be enough (and the legend would just layout the text in that 
number of columns), or would you want/need more control over where 
individual elements are placed?

Of course, we're always looking for new developers, and if you have the 
motivation to work on this, I'm sure the various people on this list 
would be happy to help you work through it.

Cheers,
Mike

Jose Gómez-Dans wrote:
> Hi!
> About a year ago, Jouni Seppänen indicated how to put a number of patches in a 
> legend. So far so good. Now, it turns out that I do have quite a lot of 
> patches to throw into this legend, and it would be nice, rather than to have 
> a single column, to have the possibility to arrange these patches (and 
> associated labels) into columns. I have looked at the legend object, but 
> there is nothing suggesting that things can be shuffled around within the 
> legend box itself, some sort of "subplot()" for the legend patches. Am I 
> correct in assuming this doesn't exist (yet!). I am running 0.91.2, maybe 
> it's already been implemented, but I thought I'd ask!
>
> Cheers!
> J
>
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Tue, Sep 9, 2008 at 12:40 AM, David Goldsmith
<d_l...@ya...> wrote:

> Clearly (?) I can do what I'm after if I use MxNx4 data, but is that the only way to have a varying alpha?

Yep, currently that is the only way.  If you start with luminance, you
can use the colormapping code to generate RGB, and then attach an
alpha mask for RGBA and pass that to figimage or imshow.

JDH

On Tue, Sep 9, 2008 at 7:12 AM, Adam <ada...@gm...> wrote:

> This gets rid of the blank space, but at the expense of the aspect ratio, as
> you mention.  Isn't there away to preserve the aspect ratios of the
> individual
> sub-images, and just remove the white space between them?  I really to not
> want to mess with the images themselves.

Yes, but you will need to use the "axes" command rather than the
"subplot" command, to position the axes where you want them.  This
will take a little arithmetic, since the axes parameters are fractions
of the figure parameters.  So you will want to create a figsize and
axes that in combination have the right aspect ratio, and issue the
axes commands such that there is no space between them.

JDH

I just added a test of intersects_bbox to SVN that seems to be working 
correctly for short paths containing masked values.  It would appear 
that masked values *should* be dealt with correctly (that is, in exactly 
the same way as they are drawn) by the intersection code.  However, 
there is probably a side case here that I'm missing.  As Eric suggests, 
see if you can break it down into a simple example that fails and 
hopefully the problem and/or solution will be more obvious from that.

Cheers,
Mike

Eric Firing wrote:
> Evan Mason wrote:
>   
>> Hi, wonder if anyone can help me with path and bbox.  I have a set of 
>> ocean drifter tracks and I want to know if they pass through a 
>> particular boxed area.  This is straightforward to do but I wanted to 
>> try to do it with matplotlib.transforms and matplotlib.path, which look 
>> well-suited to this kind of task using 'intersects_bbox'.
>>
>> The essence of my code is below.  I have a single drifter track (lon, 
>> lat) and have defined a boxed area.  At no time does the drifter 
>> approach or enter the box - however, the final line,
>>
>>     print track.intersects_bbox(bbox)
>>
>> returns True, which it shouldn't.  In total I have 340 tracks.  My code 
>> says 74 pass though the box, but by counting there should be only about 
>> 9.  Any help appreciated, thanks, Evan
>>
>>
>> import numpy as N
>> import numpy.ma <http://numpy.ma> as MA
>> import matplotlib.transforms as BB
>> import matplotlib.path as PP
>>
>> In [200]: lon
>> Out[200]:
>> masked_array(data = [-15.52 -15.521 -15.541 ..., -- -- --],
>>       mask = [False False False ...,  True  True  True],
>>       fill_value=1e+20)
>>
>> In [201]: lat
>> Out[201]:
>> masked_array(data = [29.2 29.2 29.196 ..., -- -- --],
>>       mask = [False False False ...,  True  True  True],
>>       fill_value=1e+20)
>>
>> In [202]: len(lon), len(lat)
>> Out[202]: (3750, 3750)
>>
>> track = MA.transpose([lon, lat])
>> track = PP.Path(track)
>> bbox = BB.Bbox.from_extents(-15.95, 29.6, -15.9, 29.65)
>>
>> In [206]: print track.intersects_bbox(bbox)
>> 1
>>     
>
> Evan,
>
> Can you strip the problem down more?  That is, find one track that is 
> misdiagnosed, and then try to find the shortest segment of it that still 
> gets misdiagnosed.  You could try subsampling and/or chopping chunks off 
> the ends.  If you can get it down to a track with only a few points, so 
> that you can email a very short but complete script with illustrative 
> data, that would make it much easier for someone to figure out what is 
> going on.
>
> I suspect it is related to the masked values.  If you strip the masked 
> points out of your lon and lat arrays, do you get the same result?
> Try making an example with only 3 points, say with the middle one 
> masked, and then unmasked.
>
> Eric
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

You can use

    def ticklabel_format(self, **kwargs):
        """
        Convenience method for manipulating the ScalarFormatter
        used by default for linear axes.

        Optional keyword arguments:

          =======   =====================================
          Keyword   Description
          =======   =====================================
          *style*   [ 'sci' (or 'scientific') | 'plain' ]
                    plain turns off scientific notation
          *axis*    [ 'x' | 'y' | 'both' ]
          =======   =====================================

        Only the major ticks are affected.
        If the method is called when the
        :class:`~matplotlib.ticker.ScalarFormatter` is not the
        :class:`~matplotlib.ticker.Formatter` being used, an
        :exc:`AttributeError` will be raised with no additional error
        message.

        Additional capabilities and/or friendlier error checking may
        be added.

        """

anirudh vij wrote:
> Hi,
>
> How can I plot numbers on the x and y axes in scientific notation?
>  I have very large values on the y axis which I'd like to show as 1e9 
> and not 1 followed by 9 zeros.
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John,

By default, matplotlib will resize your axes to preserve the aspect
> ratio of your image, which in the case of your 23x25 images is not
> equal.  You can override this behavior by setting aspect='auto'
>
> for i in range(6):
>  fig1.add_subplot(2,3,i+1)
>   pylab.imshow(data, aspect='auto')


This gets rid of the blank space, but at the expense of the aspect ratio, as
you mention.  Isn't there away to preserve the aspect ratios of the
individual
sub-images, and just remove the white space between them?  I really to not
want to mess with the images themselves.

cheers,
adam.

On Tue, Sep 9, 2008 at 6:26 AM, Adam <ada...@gm...> wrote:

> I thought the desired result could be achieved by the following code, but
> there is
> still blank space (in the vertical-direction) between the subplots:

By default, matplotlib will resize your axes to preserve the aspect
ratio of your image, which in the case of your 23x25 images is not
equal.  You can override this behavior by setting aspect='auto'

for i in range(6):
  fig1.add_subplot(2,3,i+1)
  pylab.imshow(data, aspect='auto')

JDH

Hello, I am trying to plot a 2x3 matrix of (sub)images, with no spacing in
between.

I thought the desired result could be achieved by the following code, but
there is
still blank space (in the vertical-direction) between the subplots:

#--------------
import pylab
from scipy import randn

data=randn(575)
data.shape=(23,25)


fig1 = pylab.figure()

for i in range(6):
  fig1.add_subplot(2,3,i+1)
  pylab.imshow(data)

fig1.subplots_adjust(wspace=0,hspace=0.0)

pylab.show()
#--------------


I guess I am asking in general the proper way to display an NxM matrix of
images with no spaces in between,
as the above code is not working.

Thank you for the help!
-adam.

thanks Eric! Could you provide me with an executive summary as to 
pcolorfast vs imshow? Is it essentially a matter of speed?
Also, I tried to add a colorbar but failed. What is the correct invocation?
thanks a gain,
Johann

Eric Firing wrote:
> Johann Cohen-Tanugi wrote:
>> thanks Johan,
>> I posted to scipy because of histogram2d being in numpy, sorry about 
>> that.
>> Now the stupid question, why can't imshow directly parse histogram2d, 
>> without the transitory extent object?
>
> imshow is a general image display function; it would not make sense to 
> customize it to match histogram2d.
>
> You may want to use Axes.pcolorfast instead.  Example using ipython 
> -pylab:
>
> In [1]:import numpy as np
>
> In [2]:x, y = np.random.randn(2, 100000)
>
> In [3]:H, xedges, yedges = np.histogram2d(x, y, bins=50)
>
> In [4]:fig = figure()
>
> In [5]:ax = fig.add_subplot(111)
>
> In [6]:ax.pcolorfast?
>
> In [7]:ax.pcolorfast(xedges, yedges, H)
> Out[7]:<matplotlib.image.AxesImage object at 0x8bf0ecc>
>
> In [8]:draw()
>
> Eric
>
>> Anyway, I am happy that there is a simple way as explained below!
>>
>> thanks again,
>> Johann
>>
>> John Hunter wrote:
>>> On Fri, Sep 5, 2008 at 10:36 AM, Johann Cohen-Tanugi
>>> <co...@sl...> wrote:
>>>  
>>>> hi, I hope someone can quickly point me to some doc.
>>>> I can do imshow(histogram2d(x,y)[0]) but then I miss the x and y 
>>>> binning
>>>> correct labels.
>>>> If I do imshow(histogram2d(x,y)) I get:
>>>> ERROR: An unexpected error occurred while tokenizing input
>>>> The following traceback may be corrupted or invalid
>>>> The error message is: ('EOF in multi-line statement', (115, 0))
>>>>     
>>> matplotlib questions are best addressed to the matplotlib-users 
>>> mailing list at
>>>
>>>    http://lists.sourceforge.net/mailman/listinfo/matplotlib-users
>>>
>>> histogram2d returns H, xedges and yedges.  The first argument should
>>> be passed to imshow, and the second two can be used to get the extents
>>>
>>> In [26]: x, y = np.random.randn(2, 100000)
>>>
>>> In [27]: H, xedges, yedges = np.histogram2d(x, y, bins=50)
>>>
>>> In [28]: extent = [xedges[0], xedges[-1], yedges[0], yedges[-1]]
>>>
>>> In [29]: imshow(H, extent=extent)
>>> Out[29]: <matplotlib.image.AxesImage object at 0x9377bcc>
>>>

Hi, folks.  OK, I'm trying to set the alpha channel, pixel by pixel, using figimage w/ the data being of the "luminance" type (i.e., an MxN array).  The Users Guide indicates that figimage takes an alpha= keyword argument, and it doesn't crash when I pass an array for this value, but subsequently when I try to draw it using fig.draw(canvas.get_renderer()), I get:

>>> fig.draw(canvas.get_renderer())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python25\lib\site-packages\matplotlib\figure.py", line 607, in draw
    im.draw(renderer)
  File "C:\python25\lib\site-packages\matplotlib\image.py", line 597, in draw
    im = self.make_image()
  File "C:\python25\lib\site-packages\matplotlib\image.py", line 583, in make_im
age
    x = self.to_rgba(self._A, self._alpha)
  File "C:\python25\lib\site-packages\matplotlib\cm.py", line 76, in to_rgba
    x = self.cmap(x, alpha=alpha, bytes=bytes)
  File "C:\python25\lib\site-packages\matplotlib\colors.py", line 423, in __call
__
    alpha = min(alpha, 1.0) # alpha must be between 0 and 1
ValueError: The truth value of an array with more than one element is ambiguous.
 Use a.any() or a.all()

which to me "smells" as if the array-valued alpha is the problem.  

Clearly (?) I can do what I'm after if I use MxNx4 data, but is that the only way to have a varying alpha?

Thanks!

DG





      

Evan Mason wrote:
> Hi, wonder if anyone can help me with path and bbox.  I have a set of 
> ocean drifter tracks and I want to know if they pass through a 
> particular boxed area.  This is straightforward to do but I wanted to 
> try to do it with matplotlib.transforms and matplotlib.path, which look 
> well-suited to this kind of task using 'intersects_bbox'.
> 
> The essence of my code is below.  I have a single drifter track (lon, 
> lat) and have defined a boxed area.  At no time does the drifter 
> approach or enter the box - however, the final line,
> 
>     print track.intersects_bbox(bbox)
> 
> returns True, which it shouldn't.  In total I have 340 tracks.  My code 
> says 74 pass though the box, but by counting there should be only about 
> 9.  Any help appreciated, thanks, Evan
> 
> 
> import numpy as N
> import numpy.ma <http://numpy.ma> as MA
> import matplotlib.transforms as BB
> import matplotlib.path as PP
> 
> In [200]: lon
> Out[200]:
> masked_array(data = [-15.52 -15.521 -15.541 ..., -- -- --],
>       mask = [False False False ...,  True  True  True],
>       fill_value=1e+20)
> 
> In [201]: lat
> Out[201]:
> masked_array(data = [29.2 29.2 29.196 ..., -- -- --],
>       mask = [False False False ...,  True  True  True],
>       fill_value=1e+20)
> 
> In [202]: len(lon), len(lat)
> Out[202]: (3750, 3750)
> 
> track = MA.transpose([lon, lat])
> track = PP.Path(track)
> bbox = BB.Bbox.from_extents(-15.95, 29.6, -15.9, 29.65)
> 
> In [206]: print track.intersects_bbox(bbox)
> 1

Evan,

Can you strip the problem down more?  That is, find one track that is 
misdiagnosed, and then try to find the shortest segment of it that still 
gets misdiagnosed.  You could try subsampling and/or chopping chunks off 
the ends.  If you can get it down to a track with only a few points, so 
that you can email a very short but complete script with illustrative 
data, that would make it much easier for someone to figure out what is 
going on.

I suspect it is related to the masked values.  If you strip the masked 
points out of your lon and lat arrays, do you get the same result?
Try making an example with only 3 points, say with the middle one 
masked, and then unmasked.

Eric