matplotlib-devel Mailing List for matplotlib

>     Jordan> Here's a reference talking about the different coordinate
>     Jordan> systems accessible in matplotlib:
>
>     Jordan> http://www.scipy.org/Cookbook/Matplotlib/Transformations
>
>     Jordan> I think what we need is to set the coordinate transform to
>     Jordan> be in and absolute, instead of relative, coordinate
>     Jordan> system, or to build one ourselves.  But I don't know
>     Jordan> enough about matplotlib's internals to know if this is
>     Jordan> right.  Comments?
>
> This is probably what you want to do.  You want to define your arrow
> in something like points, then do a rotation, and then apply one of
> the transformation offsets to place your arrow at an x,y location.
> Note there is a bug in some version of matplotlib in the affine code
> which is fixes in SVN -- this arrow should have it's base at 0.5, 0.5
> and be pointing NW and measure 2 inches from base to tip.  The arrow
> size is independent of zoom and figure window size, which may or may
> not be desirable....
>   
Wow, that's service.  Yeah, that's almost exactly what we want... but 
you are right, it would be better if the arrow scaled with the figure 
size, but maintained it's aspect ratio.  I'll try to play around with 
your example and figure out how to make it work.  Thanks a lot.

Jordan

John Hunter wrote:
>     Jordan> I think what we need is to set the coordinate transform to
>     Jordan> be in and absolute, instead of relative, coordinate
>     Jordan> system,

> This is probably what you want to do.  You want to define your arrow
> in something like points, then do a rotation, and then apply one of
> the transformation offsets to place your arrow at an x,y location.

This sounds a lot like what a I did a while ago (following suggested 
code form JDH), and posted here. My intent is to clean it up so that it 
can get included in MPL, but I haven't had the chance. Meanwhile, here 
it is again. Use it as you will.

-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...

>>>>> "Jordan" == Jordan Dawe <jdawe@u.washington.edu> writes:

    Jordan> Here's a reference talking about the different coordinate
    Jordan> systems accessible in matplotlib:

    Jordan> http://www.scipy.org/Cookbook/Matplotlib/Transformations

    Jordan> I think what we need is to set the coordinate transform to
    Jordan> be in and absolute, instead of relative, coordinate
    Jordan> system, or to build one ourselves.  But I don't know
    Jordan> enough about matplotlib's internals to know if this is
    Jordan> right.  Comments?

This is probably what you want to do.  You want to define your arrow
in something like points, then do a rotation, and then apply one of
the transformation offsets to place your arrow at an x,y location.
Note there is a bug in some version of matplotlib in the affine code
which is fixes in SVN -- this arrow should have it's base at 0.5, 0.5
and be pointing NW and measure 2 inches from base to tip.  The arrow
size is independent of zoom and figure window size, which may or may
not be desirable....

from matplotlib.transforms import Affine, Value, zero
from matplotlib.patches import Polygon
from pylab import figure, show, nx


fig = figure()
ax = fig.add_subplot(111, xlim=(0,1), ylim=(0,1), autoscale_on=False)

sx = 144/72.*fig.dpi.get()  # 2 inches
sy = 144/72.*fig.dpi.get()
theta = 45*nx.pi/180.

# arrow drawn in pixels
trans = Affine(
    Value(sx*nx.cos(theta)),
    Value(sx*nx.sin(theta)),
    Value(-sy*nx.sin(theta)),
    Value(sy*nx.cos(theta)),
    zero(),
    zero())

verts = [
    (-0.05,0.75),
    (0, 1.),
    (0.05,0.75),
    (0.05,0),
    (-0.05,0),
    ]

# offset in data coords
trans.set_offset((0.5, 0.5), ax.transData)
poly = Polygon(verts, transform=trans)

ax.add_patch(poly)
show()

Gary Ruben wrote:
> Hi Jordan,
> When I zoom, if the x and y zooms are not locked you will still get 
> the problem you mention with my modified arrows. They're still just 
> patches locked to the current x and y coordinates.
> I've attached my modified Arrow() in case you want to look at it. It 
> requires a change to quiver in axes.py too to add the arrowstyle 
> parameter and pass it through but you can just ignore that stuff and 
> remove the arrowstyle references if you want to try it out. The 
> changes just keep the arrow head length fixed and adjust the length of 
> the arrow shaft until it gets so short that it becomes necessary to 
> start scaling down the width in proportion with the length (I'm not 
> sure if that makes sense).
> Gary
That makes a lot of sense.  I've just been changing this line:

    arrow[:,1] *= width

to

    arrow[:,1] *= L*width

but this, of course, ends up with some weird looking arrows at the ends 
of the data range

The main problem with quiver as it currently exists is that, if say you 
plot:

quiver(ones([1,2]),ones([1,2]))

You end up with arrows that are twice as tall as they are wide, instead 
of 45 degree arrows.  This is definitely a bug, not a feature.

Here's a reference talking about the different coordinate systems 
accessible in matplotlib:

http://www.scipy.org/Cookbook/Matplotlib/Transformations

I think what we need is to set the coordinate transform to be in and 
absolute, instead of relative, coordinate system, or to build one 
ourselves.  But I don't know enough about matplotlib's internals to know 
if this is right.  Comments?

Jordan

Hi Jordan,
When I zoom, if the x and y zooms are not locked you will still get the 
problem you mention with my modified arrows. They're still just patches 
locked to the current x and y coordinates.
I've attached my modified Arrow() in case you want to look at it. It 
requires a change to quiver in axes.py too to add the arrowstyle 
parameter and pass it through but you can just ignore that stuff and 
remove the arrowstyle references if you want to try it out. The changes 
just keep the arrow head length fixed and adjust the length of the arrow 
shaft until it gets so short that it becomes necessary to start scaling 
down the width in proportion with the length (I'm not sure if that makes 
sense).
Gary

Jordan Dawe wrote:
<snip>
> Wow, serendipitously I'm working on exactly the same thing at the 
> moment.  Question: when you zoom, do you ensure that the x-direction in 
> your window is the same length as the y-direction?  My current theory on 
> this is the distorted arrows are the result of quiver measuring 
> everything in the x-y space of the plot, instead of in absolute terms.  
> Setting axis('equal') or axis('scaled') seems to improve the arrow 
> appearance...
> 
> Jordan

Hi John,
I'll have a look at this over the weekend.
 From the link and example you provided I'm not yet sure that subpixel 
rendering is the problem, but it could well be - What I'm getting is the 
vertices displaced away from the expected position by quite a way, but 
I'll see if the patch you made is at the Python level, in which case I 
can try it easily, or if at the C level, it may be time to try my Ubuntu 
installation out and finally learn to build from source.
thanks,
Gary

>>>>> "Gary" == Gary Ruben <gr...@bi...> writes:

    Gary> I've been rewriting the Arrow class in patches.py to improve
    Gary> the look of quiver plots and am getting generally good
    Gary> results. The problems with current quiver plots are that
    Gary> arrows representing very small values are scaled along their
    Gary> length but not in width and also that arrowheads are not of
    Gary> a constant size. I have addressed both of these problems and
    Gary> getting results much more like Matlab quiver plots
    Gary> now. However, now that I am scaling arrow patches down to
    Gary> very small sizes, I see weird shaped arrows at some zoom
    Gary> levels but when I zoom in close enough to see the shape
    Gary> properly they look nicely formed. Is there a known problem,
    Gary> perhaps with Agg doing some fancy truncation in order to
    Gary> achieve good speed, where patches are distorted if their
    Gary> vertices are very close together at a particular
    Gary> magnification? I can provide code and graphic examples if it
    Gary> would help.

My guess is that this has something to do with subpixel rendering, and
it has cropped up in a number of circumstances.  Unfortunately, I
don't know of an easy answer.  If you tell agg to draw a line from 0,0
to 1,1, the line will look different than a line from .5,.5 to 1.5,1.5

See
http://antigrain.com/tips/line_alignment/line_alignment.agdoc.html#PAGE_LINE_ALIGNMENT

One way to confirm that this is your problem is to turn antialiasing
off

  patch.set_antialiased(False)

but I just noticed that the agg draw_polygon method does not respect
the aa setting, so I just committed changes to svn to fix this.  Do
you have access to svn?

With svn in the example below, the green polygon should look more
jaggy than the yellow one.  My guess is that this weirdness for small
arrows will go away with antialiasing off, but then you will have
crappy, aliased arrows.  Not sure what the right answer is...

from matplotlib.patches import RegularPolygon
from pylab import figure, show

p1 = RegularPolygon((1,1), 5, antialiased=True, facecolor='yellow', linewidth=5)
p2 = RegularPolygon((0,0), 5, antialiased=False, facecolor='green', linewidth=5, alpha=0.5)

fig = figure()
ax = fig.add_subplot(111, xlim=(-6,6), ylim=(-6,6), autoscale_on=False)
ax.add_patch(p1)
ax.add_patch(p2)
show()



JDH

Gary Ruben wrote:
> I've been rewriting the Arrow class in patches.py to improve the look 
> of quiver plots and am getting generally good results. The problems 
> with current quiver plots are that arrows representing very small 
> values are scaled along their length but not in width and also that 
> arrowheads are not of a constant size. I have addressed both of these 
> problems and getting results much more like Matlab quiver plots now. 
> However, now that I am scaling arrow patches down to very small sizes, 
> I see weird shaped arrows at some zoom levels but when I zoom in close 
> enough to see the shape properly they look nicely formed. Is there a 
> known problem, perhaps with Agg doing some fancy truncation in order 
> to achieve good speed, where patches are distorted if their vertices 
> are very close together at a particular magnification? I can provide 
> code and graphic examples if it would help.

Wow, serendipitously I'm working on exactly the same thing at the 
moment.  Question: when you zoom, do you ensure that the x-direction in 
your window is the same length as the y-direction?  My current theory on 
this is the distorted arrows are the result of quiver measuring 
everything in the x-y space of the plot, instead of in absolute terms.  
Setting axis('equal') or axis('scaled') seems to improve the arrow 
appearance...

Jordan

I've been rewriting the Arrow class in patches.py to improve the look of 
quiver plots and am getting generally good results. The problems with 
current quiver plots are that arrows representing very small values are 
scaled along their length but not in width and also that arrowheads are 
not of a constant size. I have addressed both of these problems and 
getting results much more like Matlab quiver plots now. However, now 
that I am scaling arrow patches down to very small sizes, I see weird 
shaped arrows at some zoom levels but when I zoom in close enough to see 
the shape properly they look nicely formed. Is there a known problem, 
perhaps with Agg doing some fancy truncation in order to achieve good 
speed, where patches are distorted if their vertices are very close 
together at a particular magnification? I can provide code and graphic 
examples if it would help.

Gary R.