matplotlib-devel Mailing List for matplotlib (Page 5)

Oops, no idea this was already implemented.
I recalled discussion about the topic from way back I guess.
I'll give it a shot.
To get back to the real topic: it would indeed be even nicer if we didn't
have to convert to rgba.

On 5/10/06, Eric Firing <ef...@ha...> wrote:
>
> John Hunter wrote:
> >>>>>>"Mark" =3D=3D Mark Bakker <ma...@gm...> writes:
> >
> >
> >     Mark> Eric - If you are going to make changes here, would it be
> >     Mark> possible to pass a sequence of colors, one for each line
> >     Mark> segment in the collection.  You can check, for example,
> >     Mark> whether the length of the sequence is equal to the number of
> >     Mark> segments.  Would be very helpful for some people, as I have
> >     Mark> seen requests for this possibility several times on the
> >     Mark> list.
> >
> > Unless, I am misunderstanding you, you can already do that.  For
> > example, this is what scatter and polor do to make each element of the
> > collection a different color.
> >
> > Eric is talking about a convenience function so that you can pass
> > arbitrary colors arguments rather than rgba, ie the equivalent of
> >
> >   from matplotlib.colors import colorConverter
> >   colors =3D [colorConverter.to_rgba(x) for x in 'yellow', 0.5, (1,0,0,=
0.5
> )]
> >
> > you can then pass colors to a collection with three elements and get
> > the three colors yellow, gray and transparent red
>
> Exactly.  The convenience function already exists--it is
> Collection._get_color()--and it is already used in all the
> set_facecolor() and similar methods, but not in processing the
> initializer argument list.  What I have in mind is simply using it at
> initialization time.  I have not thought it through carefully yet,
> though; it is just something that came up while working on a new
> colorbar, and for the moment I am concentrating on the latter.
>
> Eric
>
>
>

John Hunter wrote:
>>>>>>"Mark" == Mark Bakker <ma...@gm...> writes:
> 
> 
>     Mark> Eric - If you are going to make changes here, would it be
>     Mark> possible to pass a sequence of colors, one for each line
>     Mark> segment in the collection.  You can check, for example,
>     Mark> whether the length of the sequence is equal to the number of
>     Mark> segments.  Would be very helpful for some people, as I have
>     Mark> seen requests for this possibility several times on the
>     Mark> list.
> 
> Unless, I am misunderstanding you, you can already do that.  For
> example, this is what scatter and polor do to make each element of the
> collection a different color.
> 
> Eric is talking about a convenience function so that you can pass
> arbitrary colors arguments rather than rgba, ie the equivalent of
> 
>   from matplotlib.colors import colorConverter
>   colors = [colorConverter.to_rgba(x) for x in 'yellow', 0.5, (1,0,0,0.5)]
> 
> you can then pass colors to a collection with three elements and get
> the three colors yellow, gray and transparent red

Exactly.  The convenience function already exists--it is 
Collection._get_color()--and it is already used in all the 
set_facecolor() and similar methods, but not in processing the 
initializer argument list.  What I have in mind is simply using it at 
initialization time.  I have not thought it through carefully yet, 
though; it is just something that came up while working on a new 
colorbar, and for the moment I am concentrating on the latter.

Eric

>>>>> "Mark" == Mark Bakker <ma...@gm...> writes:

    Mark> Eric - If you are going to make changes here, would it be
    Mark> possible to pass a sequence of colors, one for each line
    Mark> segment in the collection.  You can check, for example,
    Mark> whether the length of the sequence is equal to the number of
    Mark> segments.  Would be very helpful for some people, as I have
    Mark> seen requests for this possibility several times on the
    Mark> list.

Unless, I am misunderstanding you, you can already do that.  For
example, this is what scatter and polor do to make each element of the
collection a different color.

Eric is talking about a convenience function so that you can pass
arbitrary colors arguments rather than rgba, ie the equivalent of

  from matplotlib.colors import colorConverter
  colors = [colorConverter.to_rgba(x) for x in 'yellow', 0.5, (1,0,0,0.5)]

you can then pass colors to a collection with three elements and get
the three colors yellow, gray and transparent red

JDH

Eric -

If you are going to make changes here, would it be possible to pass a
sequence of colors, one for each line segment in the collection.
You can check, for example, whether the length of the sequence is equal to
the number of segments.
Would be very helpful for some people, as I have seen requests for this
possibility several times on the list.

Thanks, Mark



> --__--__--
>
> Message: 3
> Date: Tue, 09 May 2006 14:44:07 -1000
> From: Eric Firing <ef...@ha...>
> Organization: University of Hawaii
> To: John Hunter <jdh...@ni...>
> CC: matplotlib development list <mat...@li...>
> Subject: [matplotlib-devel] color argument to collections
>
> John,
>
> Collections would be easier to use if they did not have the restriction
> (from the docstring):
>
>      All color args to a collection are sequences of rgba tuples
>
> It would be easy to remove this restriction; shall I do it, or is there
> a reason to leave the restriction in place?  (The error message that
> results from violating the restriction is not helpful, and it would be
> as easy to remove the restriction as to improve the error handling.)
>
> Eric
>
>
>
>

Hi. A long while ago I had sent out an email asking if anyone was 
interested in an XML library for plotting with matplotlib. It seemed the 
general consensus was no, though it might be nice as a backend for 
saving files. So I developed the XML library for my own purposes, and 
have been using it for some time.

I thought I might as well clean it up, package it, and release it in the 
wild. I'm not sure if this would even qualify as an alpha release, 
perhaps more of a RFC, but if anyone is interested, and wants to give 
some comments, let me know. While it has gotten a good amount of use 
(including a soon to be published paper), it has evolved to fit my needs 
more than anything else. So in the clean up, I tried to refractor some 
saneness into it, and had to fix some things in the process. I tried to 
test as much of it as possible, but I'm sure I forgot some obvious 
things as well.

It is trying to serve 3 purposes:
(1) Framework for making publishable figures easy
(2) Provide an easy way to allow pylab figures to be saveable/loadable 
and editable by human
(3) Provide a general framework for a higher level plotting library

I'm hoping to in the near future write the backend to pylab to save in 
the XML format. It should (hopefully) be fairly trivial..

It can be found (this includes some documentation and examples):
www.cns.nyu.edu/~abes/xmlplot.tar.gz

Thanks,

Abe

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> John, Collections would be easier to use if they did not
    Eric> have the restriction (from the docstring):

    Eric>      All color args to a collection are sequences of rgba
    Eric> tuples

    Eric> It would be easy to remove this restriction; shall I do it,
    Eric> or is there a reason to leave the restriction in place?
    Eric> (The error message that results from violating the
    Eric> restriction is not helpful, and it would be as easy to
    Eric> remove the restriction as to improve the error handling.)

I think it's fine to remove it, but note that you have to be careful
to avoid ambiguity.  How would you interpret

  color = (0.25, 0.5, 0.75, 1.0)

Is this one rgba color or 4 grayscales?  

Because mpl accepts lots of different types of args for colors, there
will probably be some ambiguous cases, thought these will be very rare
corner cases.  Just document what the behavior is, and everyone should
be happy.  I think you could do the same for the linewidths, etc.  Eg
if scalar, interpret as a single linewidth for all elements of the
collection?

Or were you intending to preserve the requirement that one pass
sequences, but allow versatile color args in the sequence?

JDH

John,

Collections would be easier to use if they did not have the restriction 
(from the docstring):

     All color args to a collection are sequences of rgba tuples

It would be easy to remove this restriction; shall I do it, or is there 
a reason to leave the restriction in place?  (The error message that 
results from violating the restriction is not helpful, and it would be 
as easy to remove the restriction as to improve the error handling.)

Eric

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
>     Eric> John (Hunter), Paul (Kienzle), Alex (Mont), I have fixed
>     Eric> some of the problems with pcolormesh reported by George
> 
> I think some of these changes are not playing well with numarray

Or with Numeric.

It is fixed in svn now.  I needed to use Travis's ma.getmaskorNone() trick.

I will breathe a sigh of relief on that happy day when we can drop 
support for Numeric and numarray...

Eric

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> John (Hunter), Paul (Kienzle), Alex (Mont), I have fixed
    Eric> some of the problems with pcolormesh reported by George

I think some of these changes are not playing well with numarray

peds-pc311:~/mpl/examples> python image_demo_na.py
Traceback (most recent call last):
  File
  "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", line 283, in expose_event
    self._render_figure(self._pixmap, w, h)
  File
  "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py", line 72, in _render_figure
    FigureCanvasAgg.draw(self)
  File
  "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py", line 389, in draw
    self.figure.draw(renderer)
  File "/usr/lib/python2.4/site-packages/matplotlib/figure.py", line
  529, in draw
    for a in self.axes: a.draw(renderer)
  File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line
  972, in draw
    im.draw(renderer)
  File "/usr/lib/python2.4/site-packages/matplotlib/image.py", line
  184, in draw    im = self.make_image()
  File "/usr/lib/python2.4/site-packages/matplotlib/image.py", line
  115, in make_image
    x = self.to_rgba(self._A, self._alpha)
  File "/usr/lib/python2.4/site-packages/matplotlib/cm.py", line 56,
  in to_rgba
    x = self.norm(x)
  File "/usr/lib/python2.4/site-packages/matplotlib/colors.py", line
  657, in __call__
    mask=val.mask)
  File
  "/home/jdhunter/debs/numarray/usr/lib/python2.4/site-packages/numarray/ma/MA.py", line 649, in __init__
    self._mask = make_mask (mask, flag=ss)
  File
  "/home/jdhunter/debs/numarray/usr/lib/python2.4/site-packages/numarray/ma/MA.py", line 185, in make_mask
    result = Numeric.array(filled(m,1), MaskType, savespace=1)
  File
  "/home/jdhunter/debs/numarray/usr/lib/python2.4/site-packages/numarray/ma/MA.py", line 230, in filled
    return Numeric.array(a)
  File
  "/home/jdhunter/debs/numarray/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 411, in array
    return fromlist(sequence,type,shape)
  File
  "/home/jdhunter/debs/numarray/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 247, in fromlist
    if not len(seq) and type is None:
TypeError: len() of unsized object
peds-pc311:~/mpl/examples>

John (Hunter), Paul (Kienzle), Alex (Mont),

I have fixed some of the problems with pcolormesh reported by George 
Nurser on May 4, but the remaining problems appear to involve Agg 
rendering with alpha != 1.  To see the problem, run 
examples/quadmesh_demo.py, and resize the window a few times, or zoom on 
the masked region of the RH subplot.  You will see that the redraw does 
not erase what was under the region that is masked in the redraw.  The 
masked region is transparent by default.  A bit of uncommenting and 
commenting in quadmesh_demo.py allow you to make the masked region any 
color and alpha; you will find that if alpha is 1.0, this problem does 
not occur.

Second question: Why does QuadMesh.draw() *not* call 
update_scalarmappable()?  The draw method seems like the logical place 
to do this, as other collection classes do.

Thanks.

Eric

Tennessee Leeuwenburg <ten...@te...> writes:

> TypeError: Bbox::update_numerix expected numerix array
 [...]
> As I'm passing in simple python types, I don't see how this is the
> fault of my code. I tried passing in various flags (--numpy,
> --numarray, --Numeric) but I just got the exact same error message.

I don't know anything about mplot3D, but have you tried wrapping the
arguments in nx.asarray (where nx is obtained from "from matplotlib
import numerix as nx)?

-- 
Jouni

Hi all,

My problem includes the use of mplot3D, so I'm not sure if this is the 
appropriate venue...

The last n lines of my program are :

        xs = tuple(xs)
        ys = tuple(ys)
        zs = tuple(zs)

        fig = p.figure()
        ax = p3d.Axes3D(fig)
        ax.scatter3D(xs,ys,zs)
        fig.add_axes(ax)
        p.show()

and my error message is

Traceback (most recent call last):
  File "grid.py", line 56, in ?
    ax.scatter3D(xs,ys,zs)
  File "/usr/lib/python2.4/site-packages/mplot3d/mplot3d.py", line 997, 
in scatter3D
    self.auto_scale_xyz(xs,ys,zs, had_data)
  File "/usr/lib/python2.4/site-packages/mplot3d/mplot3d.py", line 736, 
in auto_scale_xyz
    self.zz_dataLim.update_numerix(z, z, not had_data)
TypeError: Bbox::update_numerix expected numerix array


As I'm passing in simple python types, I don't see how this is the fault 
of my code. I tried passing in various flags (--numpy, --numarray, 
--Numeric) but I just got the exact same error message.

Ideas appreciated!

Cheers,
-T