matplotlib-users Mailing List for matplotlib

John Hunter wrote:
> To rectify this, I've been wanting to improve the drawing model, eg
> along the line of enthought's kiva.

Have you looked at Cairo? that may be another option.

-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Dave wrote:

>
> Thanks Chris!  I'm using ipython -- why suffer with anything
> else;-) -- and I use tab completion to see namespace properties.  I
> have it set to filter out double-underscore names on the assumption
> that these are intended to be private by convention.  It seems to me
> that __version__ should not be double-underscored unless I
> misunderstand the convention.


AFAIU, in python, a leading *single* underscore means "private". Double
underscore is generally used for "special" symbols. These may be symbols
that have a special meaning for the python interpreter itself or are
just special by convention. (Documentation, meta-information etc.)

On 1/4/06, Christopher Barker <Chr...@no...> wrote:
>
> Dave wrote:
> > Also, unrelated but is there a property I can check once using
> matplotlib to
> > get the version information (something like matplotlib.version)?
>
> matplotlib.__version__
>
> this has become something of a python standard.
>

Thanks Chris!  I'm using ipython -- why suffer with anything else;-) -- and
I use tab completion to see namespace properties.  I have it set to filter
out double-underscore names on the assumption that these are intended to be
private by convention.  It seems to me that __version__ should not be
double-underscored unless I misunderstand the convention.  Anyway it works
and I will certainly remember it now.  As soon as i type matplotlib.__v(tab=
)
it shows up.  My version is 0.81 for those who can't handle suspense.

Originally my question was about how to handle line properties when using
psd and other higher-level plotting routines.  I figured out how to set the=
m
manually by keeping a reference to the axis before plotting and then
manually adjusting things one item at a time.  It's wordy but works fine. I
see now there is a setp() function that should help with this but I still
have to get the lines from the axes object first.  Directly setting these
properties in psd would be much cleaner in common use cases I think.

I looked in to how to improve this for psd and csd at least.  It turns out
to be trivial to add. I just added  '**kwargs' to the parameter lists of ps=
d
def and to it's call to plot().  this is in file axes.py.  This way the
extra keywords just get passed along.  I don't know how to submit a patch
but could this be added to psd and csd functions?  I also don't know if
there would be any side effects so it might need to be checked a bit more
carefuly.

-- Dave

John Hunter wrote:
> To rectify this, I've been wanting to improve the drawing model, eg
> along the line of enthought's kiva.

This sounds like a great idea -- why not use Kiva itself (or a fork)?

I'm looking forward this in any case.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Hi,
how would you do a scatter plot using "plusses". I see that "plot" can 
do that using '+' but then how do you change the size of these plusses? 
It seems to me that the symbol list for "scatter" is rather limited (why 
not extending it with the plot marker options?)

Thanks!
Eric

>>>>> "Graeme" == Graeme Lufkin <gra...@gm...> writes:

    Graeme>     Matplotlib wraps the Antigrain library quite nicely,
    Graeme> and now I'd like to use the bindings for my own nefarious
    Graeme> purposes.  Right now, what I'd like is to create a

There are two ways to do this (using matplotlib, Chris already pointed
you to the effbot wrappers).  One is to use the RendererAgg as you
discussed, another is to use the matplotlib.agg drawing module, which
is not currently used by matplotlib but is slated to replace backend
agg at some point to give agg users the ability to make arbitrary agg
draws on the canvas.

BackendAgg uses the GTk drawing API, as do all matplotlib backends.
This is a little unfortunate, since the GTK drawing model is not as
good as postscript, SVG, display PDF, or agg (all of which are pretty
similar).  Call it a historical accidcent by some developer who knew
GTk but not a lot about drawing APIs.

To rectify this, I've been wanting to improve the drawing model, eg
along the line of enthought's kiva.  In taking some first steps in
this direction, I exposed a good bit of agg in the matplotlib.agg
module.  Unfortunately, it is not really documented and you pretty
much have to know agg to use it.  But there is an example:

Once you've drawn your agg pixel buffer, you'll need to transfer it to
your canvas using string or buffer methods:

# this example uses the agg python module directly there is no
# documentation -- you have to know how to use the agg c++ API to use
# it
import matplotlib.agg as agg
from math import pi

## Define some colors
red = agg.rgba8(255,0,0,255)
blue = agg.rgba8(0,0,255,255)
green = agg.rgba8(0,255,0,255)
black = agg.rgba8(0,0,0,255)
white = agg.rgba8(255,255,255,255)
yellow = agg.rgba8(192,192,255,255)

## Create the rendering buffer, rasterizer, etc
width, height = 600,400
stride = width*4
buffer = agg.buffer(width, height, stride)

rbuf = agg.rendering_buffer()
rbuf.attachb(buffer)

pf = agg.pixel_format_rgba(rbuf)
rbase = agg.renderer_base_rgba(pf)
rbase.clear_rgba8(blue) 

renderer =  agg.renderer_scanline_aa_solid_rgba(rbase);
renderer.color_rgba8( red )
rasterizer = agg.rasterizer_scanline_aa()
scanline = agg.scanline_p8()

## A polygon path
path = agg.path_storage()
path.move_to(10,10)
path.line_to(100,100)
path.line_to(200,200)
path.line_to(100,200)
path.close_polygon()

# stroke it
stroke = agg.conv_stroke_path(path)
stroke.width(3.0)
rasterizer.add_path(stroke)
agg.render_scanlines_rgba(rasterizer, scanline, renderer);

## A curved path
path = agg.path_storage()
path.move_to(200,10)
path.line_to(350,50)
path.curve3(150,200)
path.curve3(100,70)
path.close_polygon()
curve = agg.conv_curve_path(path)

# fill it
rasterizer.add_path(curve)
renderer.color_rgba8( green )
agg.render_scanlines_rgba(rasterizer, scanline, renderer);

# and stroke it
stroke = agg.conv_stroke_curve(curve)
stroke.width(5.0)
rasterizer.add_path(stroke)
renderer.color_rgba8( yellow )
agg.render_scanlines_rgba(rasterizer, scanline, renderer);

## Transforming a path
path = agg.path_storage()
path.move_to(0,0)
path.line_to(1,0)
path.line_to(1,1)
path.line_to(0,1)
path.close_polygon()

rotation = agg.trans_affine_rotation(pi/4)
scaling = agg.trans_affine_scaling(30,30)
translation = agg.trans_affine_translation(300,300)
trans = rotation*scaling*translation

transpath = agg.conv_transform_path(path, trans)
stroke = agg.conv_stroke_transpath(transpath)
stroke.width(2.0)
rasterizer.add_path(stroke)
renderer.color_rgba8( black )
agg.render_scanlines_rgba(rasterizer, scanline, renderer);

## Converting a transformed path to a curve
path = agg.path_storage()
path.move_to(0,0)
path.curve3(1,0)
path.curve3(1,1)
path.curve3(0,1)
path.close_polygon()

rotation = agg.trans_affine_rotation(pi/4)
scaling = agg.trans_affine_scaling(30,30)
translation = agg.trans_affine_translation(300,250)
trans = rotation*scaling*translation
trans.flip_y()

transpath = agg.conv_transform_path(path, trans)
curvetrans = agg.conv_curve_trans(transpath)
stroke = agg.conv_stroke_curvetrans(curvetrans)
stroke.width(2.0)
rasterizer.add_path(stroke)
renderer.color_rgba8( white )
agg.render_scanlines_rgba(rasterizer, scanline, renderer);

## Copy a rectangle from the buffer the rectangle defined by
## x0,y0->x1,y1 and paste it at xdest, ydest 
x0, y0 = 10, 50
x1, y1 = 110, 190
xdest, ydest = 350, 200


widthr, heightr = x1-x0, y1-y0
strider = widthr*4
copybuffer = agg.buffer(widthr, heightr, strider)

rbufcopy = agg.rendering_buffer()
rbufcopy.attachb(copybuffer)
pfcopy = agg.pixel_format_rgba(rbufcopy)
rbasecopy = agg.renderer_base_rgba(pfcopy)

rect = agg.rect(x0, y0, x1, y1)
print rect.is_valid()
rectp = agg.rectPtr(rect)
#print dir(rbasecopy)

# agg is funny about the arguments to copy from; the last 2 args are
# dx, dy.  If the src and dest buffers are the same size and you omit
# the dx and dy args, the position of the copy in the dest buffer is
# the same as in the src.  Since our dest buffer is smaller than our
# src buffer, we have to offset the location by -x0, -y0
rbasecopy.copy_from(rbuf, rect, -x0, -y0);

# paste the rectangle at a new location xdest, ydest
rbase.copy_from(rbufcopy, None, xdest, ydest);

## Display it with PIL
s = buffer.to_string()
print len(s)
import Image
im = Image.fromstring( "RGBA", (width, height), s)
im.show()

>>>>> "Christian" == Christian Seberino <seb...@sp...> writes:

    Christian> The first method did *not* for some reason!?!? :(

    Christian> I would prefer to make the second method work because
    Christian> it lets me avoid having to define a Figure object
    Christian> /explicitly/ as above.  The problem with adding a
    Christian> subplot to a Figure object is that that many defaults
    Christian> change that I would have to fix. (e.g. grid lines
    Christian> disappear, plot dimensions are altered in strange way,
    Christian> etc.)

    Christian> How fix second way to avoid a Figure object?

This is a matplotlib bug -- in axes.py in the Axes.text function,
replace the line

        if t.get_clip_on():  t.set_clip_box(self.bbox)

with 
        if kwargs.has_key('clip_on'):  t.set_clip_box(self.bbox)

Thanks for the report!

JDH

>>>>> "Christian" == Christian Seberino <seb...@sp...> writes:

    Christian> I've notice that if I (1) create a plot vs.  e.g.
    Christian> plot([1,2,3])

    Christian> (2) explicitly add a plot to a Figure object

    Christian> e.g.  fig = Figure() p = fig.add_subplot(111)
    Christian> plot([1,2,3])

    Christian> it looks DIFFERENT?!?

Not sure what your problem is: please post complete examples.  But
it looks like you are improperly mixing pylab and the OO API.  If you
want to use a minimal set of pylab and use OO matplotlib for every
thing else, I recommend 

import matplotlib.numerix as nx
from pylab import figure, show, close  

The first command lets pylab handle figure management, the most
complex part, and the second gives you access to the numpy namespace

Here is the equivalent of the canonical pylab :

  plot([1,2,3[)

using a more pythonic style:

  from pylab import figure, show, close  
  fig = figure()
  ax = fig.add_subplot(111)
  ax.plot([1,2,3])
  show()


Note in your example:

  fig = Figure()
  p = fig.add_subplot(111)
  plot([1,2,3])


You used fig.add_subplot to create an Axes, which you named "p", but
then did not use it.  You would have wanted something like

  p.plot([1,2,3])

JDH

>>>>> "Christian" == Christian Seberino <seb...@sp...> writes:

    Christian> It appears when I use add_subplot method to add a plot
    Christian> to a Figure object that it is NOT semi-logarithmic if I
    Christian> use semilogy method later.

Works for me...


import matplotlib.numerix as nx
from pylab import figure, show
fig = figure()
ax = fig.add_subplot(111)
x = nx.arange(0.01, 5.0, 0.01)
y = nx.exp(-x)
ax.semilogy(x,y)
show()

It appears when I use add_subplot method
to add a plot to a Figure object that
it is NOT semi-logarithmic if I use
semilogy method later.

how fix?


Chris

I've notice that if I=20

(1) create a plot vs.
e.g.=20
plot([1,2,3])

(2) explicitly add a plot to a Figure object

e.g.=20
fig =3D Figure()
p =3D fig.add_subplot(111)
plot([1,2,3])

it looks DIFFERENT?!?

(2) remove grid lines and changes ratios
of axes to each other it appears.

how make (1) and (2) LOOK the same?

Chris