[Matplotlib-users] annotate arrow drawn slightly off
I've been trying to track down a problem in the arrows where the arrow
seems to be off by a little bit. I've narrowed down the problem to a
small example:
import matplotlib.patches as mpatches
import matplotlib.pyplot as plt
fig=plt.figure()
ax = fig.add_subplot(111, xlim=(.98,1.02), ylim=(.98,1.02),aspect='equal')
from matplotlib.patheffects import Stroke
ax.annotate('', (1,1),
(0,0),
arrowprops=dict(arrowstyle="-|>",
fc="w", ec="k",lw=30,
path_effects=[Stroke(joinstyle='miter')]),)
ax.plot([0,1],[1,1])
ax.plot([1,1],[0,1])
ax.plot([0,1.02],[0,1.02])
fig.savefig('test.png')
I've used a miter join above because it illustrates the problem better.
Notice that the arrowhead tip is just below the line, but should be
right on the line. Any clue about what the problem is?
Thanks,
Jason
--
Jason Grout
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] text element just above previous text element
Finally figured it out after pulling some hear. Using "axes.annotate" instead of "axes.text" worked for me, i.e. something like this: axes.annotate(hstr, xy=(xCorr, yCorr), xytext=(0, 5), textcoords='offset points') instead of what I did originally. Werner On 08/11/2010 16:21, Werner F. Bruhin wrote: > I like to have 2 or 3 text elements "stacked" on top of each other on > top of a bar. > > Currently it works for the first text element by doing: > > height = bar.get_height() > xCorr = bar.get_x() > yCorr = 0.20 + height > > txtax = axes.text(xCorr, yCorr, hstr) > > trying to add the second text just above the previous one I tried this: > > pCorr = yCorr + txtax.get_size() + 0.4 > txtax = axes.text(xCorr, pCorr, hstrPerc) > > It looks like my problem is that get_x() returns a value in ticks and > txtax.get_size() is in pixels and I can't find a way to get at the > height of the text element in ticks. > > Can anyone please push me in the right direction. > > Werner > > > > > -- > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > ___ > Matplotlib-users mailing list > Matplotlib-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] annotate arrow drawn slightly off
Thanks for tracking down this.
It turned out to be a silly error while adjusting the line end-point.
I'm attaching the patch. Please test the patch if you can.
I'll commit the change sometime tomorrow.
Regards,
-JJ
On Tue, Nov 9, 2010 at 9:15 PM, Jason Grout wrote:
> I've been trying to track down a problem in the arrows where the arrow
> seems to be off by a little bit. I've narrowed down the problem to a
> small example:
>
> import matplotlib.patches as mpatches
> import matplotlib.pyplot as plt
> fig=plt.figure()
> ax = fig.add_subplot(111, xlim=(.98,1.02), ylim=(.98,1.02),aspect='equal')
> from matplotlib.patheffects import Stroke
>
> ax.annotate('', (1,1),
> (0,0),
> arrowprops=dict(arrowstyle="-|>",
> fc="w", ec="k",lw=30,
> path_effects=[Stroke(joinstyle='miter')]),)
> ax.plot([0,1],[1,1])
> ax.plot([1,1],[0,1])
> ax.plot([0,1.02],[0,1.02])
>
> fig.savefig('test.png')
>
>
> I've used a miter join above because it illustrates the problem better.
> Notice that the arrowhead tip is just below the line, but should be
> right on the line. Any clue about what the problem is?
>
> Thanks,
>
> Jason
>
> --
> Jason Grout
>
>
> --
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> ___
> Matplotlib-users mailing list
> Matplotlib-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
arrow.patch
Description: Binary data
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] annotate arrow drawn slightly off
On 11/9/10 9:21 AM, Benjamin Root wrote: > I just tested out the patch, and while it did seem to fix the problem for me > on the test script, I am not 100% certain that it is properly lined up > (maybe an off-by-one-pixel error?). Anyway, I tried zooming in to see which > kind of error it was and I got a very weird image. I am not certain exactly > what triggers it, but I think if the rubber-banding does not incorporate the > entire arrow-head, then the distortion appears. I was also able to > reproduce the distortion without the patch (although I think it was easier > to cause with the patch). If it looks like an off-by-one pixel error, make sure you are doing: import matplotlib matplotlib.rcParams['path.snap'] = False to turn off the pixel-snapping that happens with horizontal and vertical lines in png images, or make sure you are seeing the off-by-one in a vector graphic format like pdf. For me, saving a pdf with the slanted line a linewidth of .01 showed that the arrow is right on it now. I did notice one thing that did seem a little off, though. I see that the tip of the arrow just barely projects over the corner of the box. The arrow is supposed to go to (1,1), and the linewidth is 30, so I'm thinking that the miter join should project a long ways over the box (because the centers of the lines are at (1,1), and the line width is very large). If I change the path_effects argument to: path_effects=[Stroke(joinstyle='miter'),Stroke(linewidth=1,foreground='w',joinstyle='miter')] so that I see more clearly where the actual line center is, it appears that the line center is far off of (1,1). I guess at this point, I'm confused about how the arrow is supposed to be representing the segment between (0,0) and (1,1). Is the tip of the arrow (after the miter join) supposed to hit (1,1), or is the center of the line supposed to hit (1,1)? Or maybe the tip of the joinstyle='round' arrow (the default) is supposed to hit (1,1)? I noticed this bug when I was trying to figure out a way to have the actual drawn arrow end at a specific point (maybe using miter join, so that we had a sharp arrow) for Sage. It would be nice if there was some sort of option that would do the math to shorten the arrow by the necessary amount. Of course, if that's not an option, I could do that math myself in Sage's "arrow" wrapper command. Thanks, Jason -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] fill_between with drawstyle steps?
Hello ExPyrts; I'm trying to do a fill-between part of a spectrum and its continuum value. I would strongly prefer the drawstyle to be steps, since each data point represents a bin (or pixel, to be precise). Attached is a picture illustrating my problem. Isn't it possible to fill between my step graph and the hline? Cheers; Emil <> signature.asc Description: This is a digitally signed message part -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] python v ipython problem in imshow()
I'm using the following code to plot some grided data fig1=pylab.figure() contents1=fig1.add_subplot(111) stuff=contents1.imshow(mydata,origin='lower',aspect='equal') and I find that if I launch the code with 'ipython' the data looks as expected but if I use 'python' then the x-axis annotations are OK but the data is still plotted with the origin in the top left hand corner. I'm using the enthought 6.1 distribution and the version of matplotlib and pylab imported in both cases is the same. I guess one indicator of a major difference is that ipython has the icon bar for the plot at the bottom of the screen but python has the icon bar at the top of the screen. Any clues ... I'd happily just use ipython but I distribute the code to others so I'd like to get it sorted. -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] python v ipython problem in imshow()
On Tue, Nov 9, 2010 at 4:33 PM, Garry Willgoose wrote: > I'm using the following code to plot some grided data > > fig1=pylab.figure() > contents1=fig1.add_subplot(111) > stuff=contents1.imshow(mydata,origin='lower',aspect='equal') > > and I find that if I launch the code with 'ipython' the data looks as > expected but if I use 'python' then the x-axis annotations are OK but the > data is still plotted with the origin in the top left hand corner. I'm using > the enthought 6.1 distribution and the version of matplotlib and pylab > imported in both cases is the same. I guess one indicator of a major > difference is that ipython has the icon bar for the plot at the bottom of the > screen but python has the icon bar at the top of the screen. Any clues ... > I'd happily just use ipython but I distribute the code to others so I'd like > to get it sorted. Sounds like a backend problem (see http://matplotlib.sourceforge.net/faq/installing_faq.html#what-is-a-backend and http://matplotlib.sourceforge.net/users/customizing.html) First thing you'll want to do is put import matplotlib print matplotlib.rcParams['backend'] at the top of your script and run it in both environments and report what you find. My guess is one of the environments has a backend that does not support the image origin argument. JDH -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] annotate arrow drawn slightly off
On Wed, Nov 10, 2010 at 12:21 AM, Benjamin Root wrote:
> On Tue, Nov 9, 2010 at 7:24 AM, Jae-Joon Lee wrote:
>>
>> Thanks for tracking down this.
>> It turned out to be a silly error while adjusting the line end-point.
>> I'm attaching the patch. Please test the patch if you can.
>> I'll commit the change sometime tomorrow.
>>
Thanks. I can reproduce the problem.
aa = ax.annotate('', (1,1),
(-10,-10),
arrowprops=dict(arrowstyle="-|>",
fc="w", ec="k",lw=30,
path_effects=[Stroke(joinstyle='miter')])
)
The erroneous behavior happens when one tries to draw a path that
connects points far outside of the canvas (point 10,10 in above
example). And this is a AGG-specific issue. The erroneous behavior
goes away if we clip the path.
aa.arrow_patch.set_clip_box(ax.figure.bbox)
I try to reproduce the problem with simple plot command, but couldn't.
Maybe this happens only for rendering bezier splines?
Michael, any idea?
One thing I may do to prevent it is to set the clip_path of the arrow
to the figure.bbox by default.
I'll think about it.
Regards,
-JJ
>> Regards,
>>
>> -JJ
>>
>>
>> On Tue, Nov 9, 2010 at 9:15 PM, Jason Grout
>> wrote:
>>>
>>> I've been trying to track down a problem in the arrows where the arrow
>>> seems to be off by a little bit. I've narrowed down the problem to a
>>> small example:
>>>
>>> import matplotlib.patches as mpatches
>>> import matplotlib.pyplot as plt
>>> fig=plt.figure()
>>> ax = fig.add_subplot(111, xlim=(.98,1.02),
>>> ylim=(.98,1.02),aspect='equal')
>>> from matplotlib.patheffects import Stroke
>>>
>>> ax.annotate('', (1,1),
>>> (0,0),
>>> arrowprops=dict(arrowstyle="-|>",
>>> fc="w", ec="k",lw=30,
>>> path_effects=[Stroke(joinstyle='miter')]),)
>>> ax.plot([0,1],[1,1])
>>> ax.plot([1,1],[0,1])
>>> ax.plot([0,1.02],[0,1.02])
>>>
>>> fig.savefig('test.png')
>>>
>>>
>>> I've used a miter join above because it illustrates the problem better.
>>> Notice that the arrowhead tip is just below the line, but should be
>>> right on the line. Any clue about what the problem is?
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> --
>>> Jason Grout
>>>
>>>
>>> --
>>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>>> David G. Thomson, author of the best-selling book "Blueprint to a
>>> Billion" shares his insights and actions to help propel your
>>> business during the next growth cycle. Listen Now!
>>> http://p.sf.net/sfu/SAP-dev2dev
>>> ___
>>> Matplotlib-users mailing list
>>> Matplotlib-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>>
>> --
>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>> David G. Thomson, author of the best-selling book "Blueprint to a
>> Billion" shares his insights and actions to help propel your
>> business during the next growth cycle. Listen Now!
>> http://p.sf.net/sfu/SAP-dev2dev
>> ___
>> Matplotlib-users mailing list
>> Matplotlib-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>
> Jae-Joon,
>
> I just tested out the patch, and while it did seem to fix the problem for me
> on the test script, I am not 100% certain that it is properly lined up
> (maybe an off-by-one-pixel error?). Anyway, I tried zooming in to see which
> kind of error it was and I got a very weird image. I am not certain exactly
> what triggers it, but I think if the rubber-banding does not incorporate the
> entire arrow-head, then the distortion appears. I was also able to
> reproduce the distortion without the patch (although I think it was easier
> to cause with the patch).
>
> Ben Root
>
>
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] IndexError' too many indices' in basemap contour
On 11/5/10 5:08 AM, Basedow Sünnje Linnéa wrote: Hi! I try to plot some interpolated data on a map and get an error saying there are too many indices. When I use contour in matplotlib without basemap I don't get the error. Also the map without a contour plot on it works. Maybe some of you know what I do wrong? Here is my code: - import numpy as np import matplotlib.pyplot as plt from matplotlib.mlab import griddata from mpl_toolkits.basemap import Basemap yi = np.linspace(min(Lat),max(Lat),100) xi = np.linspace(min(Lon),max(Lon),50) lon,lat,var = np.array(Lon), np.array(Lat), np.array(Var) zi = griddata(lon,lat,var,xi,yi) map = Basemap(projection='cyl', llcrnrlat=67, urcrnrlat=73,\ llcrnrlon=4, urcrnrlon=20, resolution='h') map.drawcoastlines() map.drawmeridians(np.arange(0,360,1)) map.drawparallels(np.arange(-90,90,1)) xlon, ylat = map(xi,yi) cs = map.contour(xlon,ylat,zi) plt.show() --- and this is the error message: cs = map.contour(xlon,ylat,zi) File "/usr/local/lib/python2.6/dist-packages/mpl_toolkits/basemap/__init__.py", line 2820, in contour xx = x[x.shape[0]/2,:] IndexError: too many indices Any help appreciated! Sünnje Sunnje: xlon, xlat must be 2d arrays (with the same shape as zi) when used with the contourf basemap method. You can make them into 2d arrays with meshgrid. -Jeff -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] annotate arrow drawn slightly off
On Wed, Nov 10, 2010 at 1:01 AM, Jason Grout
wrote:
> Is the tip of the arrow (after the miter join) supposed to hit (1,1), or is
> the center of the line supposed to hit (1,1)? Or maybe the tip of the
> joinstyle='round' arrow (the default) is supposed to hit (1,1)?
>
The tip of the arrow is meant to hit (1,1), which is done by the
underlying arrow class adjusting the end point of the path during the
drawing time. This only happens for arrowstyle "->" and etc.
However, there was an incorrect arithmetic which I think is fixed now.
The patch is attached (it also fixes dpi-related issues).
I'm not sure it would be better if this could be optionally turned
off. Any suggestion?
Let me know of any (persisting or other) issues.
FYI, path is shortened by small amount by default. This is controlled
by *shrink* parameter (shrinkA and shrinkB shortens the line begin and
the line end respectively.)
aa = ax.annotate('', (1,1), (0,0),
arrowprops=dict(arrowstyle="-|>",
fc="k", ec="k",lw=50,
shrinkB=0,
path_effects=[Stroke(joinstyle='miter')]
)
Also, I noticed that the arrow head is not correctly filled when
path_effects are in use. This is now fixed.
Regards,
-JJ
arrow.patch
Description: Binary data
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] annotate arrow drawn slightly off
On 11/9/10 8:44 PM, Jae-Joon Lee wrote: > On Wed, Nov 10, 2010 at 1:01 AM, Jason Grout > wrote: >> Is the tip of the arrow (after the miter join) supposed to hit (1,1), or is >> the center of the line supposed to hit (1,1)? Or maybe the tip of the >> joinstyle='round' arrow (the default) is supposed to hit (1,1)? >> > > The tip of the arrow is meant to hit (1,1), which is done by the > underlying arrow class adjusting the end point of the path during the > drawing time. This only happens for arrowstyle "->" and etc. > However, there was an incorrect arithmetic which I think is fixed now. > The patch is attached (it also fixes dpi-related issues). > I'm not sure it would be better if this could be optionally turned > off. Any suggestion? > Let me know of any (persisting or other) issues. Wow. You're amazing. Thanks for all the work you put into this right away! When I set shrinkB to zero, that arrow is right on the money. > > FYI, path is shortened by small amount by default. This is controlled > by *shrink* parameter (shrinkA and shrinkB shortens the line begin and > the line end respectively.) > Right. In Sage, we're using the shrinkA and shrinkB options quite a bit. For example, we use it in drawing vertex-and-edge graphs (so the arrows go to the edges of the vertex circles), and right now we use it by default to shrink by the linewidth (though I think I'm going to turn off Sage's default shrinking and just leave that up to the user). This latest patch seems to take care of the problems I was seeing. Thanks again! Jason -- Jason Grout -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
