Repository navigation
Errorbar does not plot errorbars centered on the marker #3400
Description
Using errorbar does not properly center the errorbar on the marker. See the following example and output. The issue persists in the legend as well. The errorbar is a few pixels off center and changing the linewidth does not solve the issue. snap kwarg has no effect either. I have reproduced this using matplotlib 1.2.1 and 1.3.1 on Mac OSX 10.8.4.
import matplotlib.pyplot as plt
plt.errorbar([1],[1],[0.1],fmt='k^',capsize=5,capthick=2,ms=9,markerfacecolor='none',mew=2)
plt.show()
Activity
jenshnielsen commentedon Aug 22, 2014
I can reproduce this in the gui Qt4 and Mac OSx backends. It does look correct in saved png and pdf files thou.
Edit: This is with 1.4rc4
quovatis commentedon Aug 22, 2014
It persists in my saved png files. In fact, the images I uploaded were from a saved png.
fcolas commentedon Aug 25, 2014
On ubuntu, using Qt4agg, the line appears also shifted but on the other side.
But on closer inspection, it's rather the markers that are shifted since the line is aligned with the ticks.
When saving from the gui (or using
savefig()), it doesn't happen.(Also, I don't understand why the marker is shown twice in the legend.)
jenshnielsen commentedon Aug 25, 2014
The legend normally shows two points connected by the line style used. You can customise that with the numpoints argument to legend
WeatherGod commentedon Aug 25, 2014
IIRC, there was some work during SciPy 2013 to deal with positioning issues
of vertical and horizontal lines (at the time, it was primarially to deal
with spine alignment with ticks). Perhaps markers got left behind in this
effort?
On Mon, Aug 25, 2014 at 10:17 AM, Jens H Nielsen notifications@github.com
wrote:
mdboom commentedon Aug 25, 2014
The issue is this (and it's a tricky one to solve). matplotlib includes a feature called "pixel snapping" which helps to avoid fuzzy-looking anti-aliasing by aligning to pixels. When you have a line with a width that is an odd number of pixels, it is aligned to pixel centers. When you have a line with a width that is an even number of pixels, it is aligned to pixel edges. In this example, the line is an odd width (1), while the marker line is an even width (2). So their alignment is a half pixel different. How this is should probably work is that the alignment is determined by the line, and never by the marker. Unfortunately, as it stands now, the marker drawing doesn't know about the width of the line that it's associated with (only the width of the marker edge itself). So that will require some reorganization of code to get right.
In the meantime, as a workaround: you can (a) set the marker edge width to the same as the line edge width or (b) output to any of the vector formats which do not have this snapping behavior (since something else ultimately does the rendering later).
quovatis commentedon Aug 25, 2014
I get the same behavior using the same marker edge width and line width, so I don't accept that explanation. Upon inspection it is indeed the line and not the marker that is off. The marker aligns with the tickmarks, but the error line is 1 pixel off.
What vector formats do not have this snapping behavior?
tacaswell commentedon Aug 25, 2014
I thought I tried to turn snapping off and it didn't make a difference.
WeatherGod commentedon Aug 25, 2014
Which backend are you using? Also, which version of matplotlib. This might
be backend-specific as I am able to reproduce what Francis reports.
SVG, EPS and PDF are all vector formats that saves the raw vector data. It
would then be up to their respective viewers to render that data correctly.
Our renderer appears to be incorrect in some cases.
On Mon, Aug 25, 2014 at 12:42 PM, quovatis notifications@github.com wrote:
quovatis commentedon Aug 25, 2014
As was in my initial post, I'm using matplotlib 1.3.1 and MacOSX. I've tried various combinations of marker edge widths and line widths, and the problem persists in all combinations.
tacaswell commentedon Aug 25, 2014
I can reproduce this on master.
4 remaining items
Knusper commentedon Sep 6, 2017
Is this bug still relevant? I see it in 1.5.3 on my work machine. However, when saving the figure as PDF it is not there....
anntzer commentedon Sep 6, 2017
See #3400 (comment).
I think this is due (as usual) to stamping -- looks like mpl_cairo does not display the issue (if snapping is turned off).
quovatis commentedon Mar 1, 2018
Still present in 2.1. Tested macosx, wx, and tkagg backends, and it's present in all of them. Issue is not present in Cairo.
dstansby commentedon Oct 26, 2018
Still an issue in 3.0.1
github-actions commentedon Mar 6, 2023
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
jklymak commentedon Mar 6, 2023
This is pixel snapping -
plt.errorbar([1],[1],[0.1],fmt='k^',capsize=5,capthick=2,ms=9,markerfacecolor='none',mew=2, label='a', snap=False)is centered appropriately, and this will not be apparent with high DPI or vector formats. I'll close, but feel free to re-open if folks disagree.