distorted patches

[John_Hunter1]

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?

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()

[_Chris.Barker]

John Hunter wrote:

    > I think what we need is to set the coordinate transform to
    > be in and absolute, instead of relative, coordinate
    > 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

VecPlot.py (2.4 KB)

···

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

Chris.Barker@...236...

[Jordan_Dawe3]

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

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

[Jordan_Dawe3]

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

Ok, I've done a bunch of work on making quiver work without distorting the arrows. I have a lot of questions. I've been playing with the transforms functions all weekend and I still don't understand the different transforms between figure, axes, and absolute space. Or how to get access to the 'width' and 'height' Values that are mentioned in the comments of transform.py.

The arrow size in quiver() should not be independent of zoom; it should scale with the figure and axis size. Ideally by default quiver() should ensure that the largest arrow doesn't overlap the 'gridbox' of the arrows next to it. The problem is that in order to ensure the arrow is rotated properly, the rotation must take place in absolute coordinates, but the length scaling should take place in data coordinates. Furthermore, the scaling should be a conditional: it should see if the x or the y axis is most 'in danger' of having an arrow larger than its box in data space, and then scale both the x and y coordinates equally in absolute space to ensure the arrow isn't distorted. I'm not sure this is even possible with Values; I think it would require at least a greater_than BinOp, but I don't really understand all the transform functionality or how to get access to it. Is there a way to do this?

After looking at all the files this weekend, I'm still not even sure what matplotlib considers to be 'first-class' primitives. Is it patches, lines, etc? What should a call to quiver() return? A list of polygons? It's returning a collection in svn, but I don't think you can set each object in a collection to a different transform. When should a collection be used?

I don't know if I'm making any sense here; I'm fairly frustrated after a weekend with little progress. Is there any hidden documentation that could help me?

Jordan

[Eric_Firing2]

Jordan,

I have committed changes in color handling that allow the collection initializers to accept the usual flexible mpl color specifications. Your message about quiver prompted me to try examples/quiver_demo.py, which is not run by backend_drivers.py, and which I had therefore not tested. It doesn't work now--and it doesn't make any sense to me, either. (E.g., what on earth is "color=True" supposed to mean?) That is, it is not clear to me what the quiver invocations in the demo are supposed to do based on the quiver doc string. The simplest quiver invocation works, but it looks to me like the argument handling beyond that is broken, and I don't think it is entirely the fault of my recent changes. I can help straighten it out, given a clear specification of what quiver is actually supposed to do with various argument combinations. Let me know if and when this would be useful.

Eric

[Eric_Firing2]

Jordan Dawe wrote:

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

Ok, I've done a bunch of work on making quiver work without distorting the arrows. I have a lot of questions. I've been playing with the transforms functions all weekend and I still don't understand the different transforms between figure, axes, and absolute space. Or how to get access to the 'width' and 'height' Values that are mentioned in the comments of transform.py.

The arrow size in quiver() should not be independent of zoom; it should scale with the figure and axis size. Ideally by default quiver() should ensure that the largest arrow doesn't overlap the 'gridbox' of the arrows next to it. The problem is that in order to ensure the arrow is rotated properly, the rotation must take place in absolute coordinates, but the length scaling should take place in data coordinates. Furthermore, the scaling should be a conditional: it should see if the x or the y axis is most 'in danger' of having an arrow larger than its box in data space, and then scale both the x and y coordinates equally in absolute space to ensure the arrow isn't distorted. I'm not sure this is even possible with Values; I think it would require at least a greater_than BinOp, but I don't really understand all the transform functionality or how to get access to it. Is there a way to do this?

After looking at all the files this weekend, I'm still not even sure what matplotlib considers to be 'first-class' primitives. Is it patches, lines, etc? What should a call to quiver() return? A list of polygons? It's returning a collection in svn, but I don't think you can set each object in a collection to a different transform. When should a collection be used?

I think your questions here have two aspects. The first is, exactly what functionality should quiver have? I have always thought Matlab's quiver was ugly and fairly useless for my own purposes, so I don't advocate copying it. Have you written out a docstring or other specification of what quiver should do and what its API should be? The second part is, what should Axes plotting methods return? There are two styles: contour returns a whole ContourSet object; most (all?) other methods return only the Artists (e.g. a Line or a Collection.) When I changed contour to return the ContourSet, and more recently when I did a little reorganization of axes.py, John mentioned that it might be desirable to make other methods behave similarly, but I don't think there has been any more recent discussion, and I have not gotten back to it myself. Returning higher-level objects does fit in with moving more complicated functionality out of axes.py, which I would still like to do--eventually.

I don't know if I'm making any sense here; I'm fairly frustrated after a weekend with little progress. Is there any hidden documentation that could help me?

I made some scratch-paper notes for myself, but never considered my understanding complete, and it fades fast. Parts are covered quite well in the transforms.py docstring, but a good overview, clearly laying out the various coordinate systems (with a good naming convention) and where and how transformations are made would be a big help. This is something I might be able to work on, but it might not be very efficient for me to do it. And I might not be able to do it fast enough to help with your present quivering.

Eric

[Jordan_Dawe3]

Eric Firing wrote:

I have committed changes in color handling that allow the collection initializers to accept the usual flexible mpl color specifications. Your message about quiver prompted me to try examples/quiver_demo.py, which is not run by backend_drivers.py, and which I had therefore not tested. It doesn't work now--and it doesn't make any sense to me, either. (E.g., what on earth is "color=True" supposed to mean?) That is, it is not clear to me what the quiver invocations in the demo are supposed to do based on the quiver doc string. The simplest quiver invocation works, but it looks to me like the argument handling beyond that is broken, and I don't think it is entirely the fault of my recent changes. I can help straighten it out, given a clear specification of what quiver is actually supposed to do with various argument combinations. Let me know if and when this would be useful.

I believe "color=True" is intended to give the arrows a color value based upon the arrow length. Calling quiver with color=True fails because looks_like_color( ) now treats True as a mistaken grey specification; it raises a warning saying to enclose True in brackets. quiver wants looks_like_color(True) to simply return a False.

for 'color' quiver appears to want either:

a) Something that looks_like_color(), in which case all arrows are that color
b) A True, in which case arrows are colored by length
c) An array the same size as the first data array, in which case the arrows are the colors specified in the array
d) Anything else, which makes them black.

I don't know if this is a good use of color=... because I don't know how uniform you want the matplotlib interface to be in its keyword use. We could set up a "color_by_length=True" keyword for quiver that would override the color setting, that would probably be my fix the problem.

Jordan

[Eric_Firing2]

Jordan,

Thanks for the explanation. It makes some sense now, but doesn't impress me as a good API. Having color track arrow length does not seem to me to warrant its own special and slightly bizarre syntax ("color=True"--completely non-intuitive). It would make more sense for the user to simply provide an array to be mapped; if the user wants that array to be the arrow length (hence redundant), the user can do that calculation and provide that array.

What I would like to see is a reconsideration of the API and corresponding docstring, as part of your massive re-write. This is a good opportunity to think about what would constitute a clean and consistent interface.

Jordan Dawe wrote:

Eric Firing wrote:

I have committed changes in color handling that allow the collection initializers to accept the usual flexible mpl color specifications. Your message about quiver prompted me to try examples/quiver_demo.py, which is not run by backend_drivers.py, and which I had therefore not tested. It doesn't work now--and it doesn't make any sense to me, either. (E.g., what on earth is "color=True" supposed to mean?) That is, it is not clear to me what the quiver invocations in the demo are supposed to do based on the quiver doc string. The simplest quiver invocation works, but it looks to me like the argument handling beyond that is broken, and I don't think it is entirely the fault of my recent changes. I can help straighten it out, given a clear specification of what quiver is actually supposed to do with various argument combinations. Let me know if and when this would be useful.

I believe "color=True" is intended to give the arrows a color value based upon the arrow length. Calling quiver with color=True fails because looks_like_color( ) now treats True as a mistaken grey specification; it raises a warning saying to enclose True in brackets. quiver wants looks_like_color(True) to simply return a False.

Aha! This is an example of why we are deprecating float-as-grayscale.

for 'color' quiver appears to want either:

a) Something that looks_like_color(), in which case all arrows are that color
b) A True, in which case arrows are colored by length
c) An array the same size as the first data array, in which case the arrows are the colors specified in the array
d) Anything else, which makes them black.

It also looks to me like the argument parsing can incorrectly interpret a scale factor as a color. Maybe this also used to work, but if so, it was at best fragile.

I don't know if this is a good use of color=... because I don't know how uniform you want the matplotlib interface to be in its keyword use. We could set up a "color_by_length=True" keyword for quiver that would override the color setting, that would probably be my fix the problem.

The length of that proposed keyword is a warning flag that it may also be a bad design. Again, I would say either eliminate built-in support for color-by-length, or implement it via "color='length'", and then intercept that non-standard 'length' specification inside quiver so that it never gets passed to the standard color-handling routines.

Now that you have explained it, I am inclined to either do a quick-fix of the present quiver so that it works again roughly as-is, or change the example so that it does not use the undocumented(?) "color=True" syntax; is one of these alternatives OK with you? Do you have a preference? Or do you already have an improved version that we can substitute now? One way or another, I don't want to leave a non-functioning demo in svn.

Eric

[Jordan_Dawe3]

The length of that proposed keyword is a warning flag that it may also be a bad design. Again, I would say either eliminate built-in support for color-by-length, or implement it via "color='length'", and then intercept that non-standard 'length' specification inside quiver so that it never gets passed to the standard color-handling routines.

Now that you have explained it, I am inclined to either do a quick-fix of the present quiver so that it works again roughly as-is, or change the example so that it does not use the undocumented(?) "color=True" syntax; is one of these alternatives OK with you? Do you have a preference? Or do you already have an improved version that we can substitute now? One way or another, I don't want to leave a non-functioning demo in svn.

I would remove it; if we want a quiver function with color as length, we could create a wrapper function to do that. I would lean towards making people generate their own color array based on the array length. I'm not going to have a new quiver anytime soon I think--a friend of mine today pointed out that matlab distorts quiver arrows just like matplotlib does. In matlab it isn't as noticable, however, since matlab impliments quiver as lines instead of as polygons. In the short term, I'm seriously tempted to just make matplotlib do the same.

Jordan

[_gary_ruben1]

I did a tiny bit of work on this over the weekend too and decided to try to use a LineCollection instead of patches inspired by Chris Barker's code, but removing his polar coordinate stuff. Lines seemed a more promising way to go for the arrows, although the width should scale down when the arrows get small so that they're never wider than their length. Using a line collection may not permit this. I also haven't got it working yet. FWIW, Jordan's explanations of expected behaviour have been spot on so far. Also, I'd be happy to see the API fixed up a bit.

Gary R.

Jordan Dawe wrote:

···

The length of that proposed keyword is a warning flag that it may also be a bad design. Again, I would say either eliminate built-in support for color-by-length, or implement it via "color='length'", and then intercept that non-standard 'length' specification inside quiver so that it never gets passed to the standard color-handling routines.

Now that you have explained it, I am inclined to either do a quick-fix of the present quiver so that it works again roughly as-is, or change the example so that it does not use the undocumented(?) "color=True" syntax; is one of these alternatives OK with you? Do you have a preference? Or do you already have an improved version that we can substitute now? One way or another, I don't want to leave a non-functioning demo in svn.

I would remove it; if we want a quiver function with color as length, we could create a wrapper function to do that. I would lean towards making people generate their own color array based on the array length. I'm not going to have a new quiver anytime soon I think--a friend of mine today pointed out that matlab distorts quiver arrows just like matplotlib does. In matlab it isn't as noticable, however, since matlab impliments quiver as lines instead of as polygons. In the short term, I'm seriously tempted to just make matplotlib do the same.

Jordan

[Rob_Hetland]

It might make some sense to rethink the quiver API, especially since it seems there are a few people working toward the same goal (I will help, too, if someone can give me some tasks…).

Here’s a strawman quiver API:

quiver(x, y, u, v, color=‘b’, scale=1.0, scale_to_grid=False, **kwargs)

x, y - quiver should be able to handle random (x, y) points (right now, it seems to expect meshed positions – it seems this is an unnecessary constraint.)

color - could be a plot-style color (e.g., ‘b’, ‘k’, ‘m’), a tuple, or an array the same size as x and y to be mapped using the colormap.

scale - is a multiplier for the vector length.

scale_to_grid - is a boolean that specifies whether the vectors should be in grid coordinates (True), or scaled to fit nicely (False – vectors are scaled to fit nice, then multiplied by scale).

Plus all the normal kwargs (e.g., cmap).

Other potential things to consider include scaling the aspect of the vectors so that the grid can have an aspect ratio unequal to one, but the vectors still scale correctly (i.e., u and v have the same length, even when x is twice y).

Finally, I have always wanted an easy way to do curly vectors – similar to streaklines – but this might be beyond the scope of the simple quiver command.

-Rob

···

On May 23, 2006, at 2:02 PM, Eric Firing wrote:

I have committed changes in color handling that allow the collection initializers to accept the usual flexible mpl color specifications. Your message about quiver prompted me to try examples/quiver_demo.py, which is not run by backend_drivers.py, and which I had therefore not tested. It doesn’t work now–and it doesn’t make any sense to me, either. (E.g., what on earth is “color=True” supposed to mean?) That is, it is not clear to me what the quiver invocations in the demo are supposed to do based on the quiver doc string. The simplest quiver invocation works, but it looks to me like the argument handling beyond that is broken, and I don’t think it is entirely the fault of my recent changes. I can help straighten it out, given a clear specification of what quiver is actually supposed to do with various argument combinations. Let me know if and when this would be useful.

---

Rob Hetland, Assistant Professor

Dept of Oceanography, Texas A&M University

p: 979-458-0096, f: 979-845-6331

e: hetland@…345…, w: http://pong.tamu.edu

[_gary_ruben1]

Looks good, but I think it also needs a 'width' or 'weight' kwarg.
I was also thinking of putting at least a couple of different arrow styles in via an 'arrowstyle' kwarg, so I'd pass those through to the Arrow LineCollection.

Gary R.

Rob Hetland wrote:

···

It might make some sense to rethink the quiver API, especially since it seems there are a few people working toward the same goal (I will help, too, if someone can give me some tasks..).

Here's a strawman quiver API:

quiver(x, y, u, v, color='b', scale=1.0, scale_to_grid=False, **kwargs)

  x, y - quiver should be able to handle *random* (x, y) points (right now, it seems to expect meshed positions -- it seems this is an unnecessary constraint.)

  color - could be a plot-style color (e.g., 'b', 'k', 'm'), a tuple, or an array the same size as x and y to be mapped using the colormap.

  scale - is a multiplier for the vector length.

  scale_to_grid - is a boolean that specifies whether the vectors should be in grid coordinates (True), or scaled to fit nicely (False -- vectors are scaled to fit nice, then multiplied by scale).

  Plus all the normal kwargs (e.g., cmap).

Other potential things to consider include scaling the aspect of the vectors so that the grid can have an aspect ratio unequal to one, but the vectors still scale correctly (i.e., u and v have the same length, even when x is twice y).

Finally, I have always wanted an easy way to do curly vectors -- similar to streaklines -- but this might be beyond the scope of the simple quiver command.

-Rob