Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Errorbar markers not drawn in png output #3687

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
Oct 27, 2014
Merged

Errorbar markers not drawn in png output #3687

merged 2 commits into from
Oct 27, 2014

Conversation

mdboom
Copy link
Member

@mdboom mdboom commented Oct 21, 2014

Using the current master (0a96efb), no markers are drawn when calling errorbar() with either mec='None' or mew=0 and outputting to png. For some reason, pdf output seems unaffected.

The following code reproduces the error:

import matplotlib.pyplot as plt
import numpy as np

plt.rcdefaults()

x = np.arange(10)
y = x.copy()
dy = y*0.1

plt.errorbar(x, y, yerr=dy, marker='s', mew=0)
plt.errorbar(x, y+1, yerr=dy, marker='o', mec='None')

plt.savefig("test_markers.png")
plt.savefig("test_markers.pdf")

@mdboom mdboom self-assigned this Oct 21, 2014
@mdboom
Copy link
Member

mdboom commented Oct 21, 2014

May be due to the recent C++ refactor. I'll look into this. Thanks.

@WeatherGod
Copy link
Member

Probably the reason why it isn't effected in the pdf output is because you
can't have a zero-width line in pdfs, so most renderers will display that
as a minimum-width line instead. I thought we ended up working around that
by detecting such situations and avoiding adding such objects to the pdf
output. Perhaps that logic got messed up somehow?

On Tue, Oct 21, 2014 at 8:00 AM, Michael Droettboom <
[email protected]> wrote:

May be due to the recent C++ refactor. I'll look into this. Thanks.

—
Reply to this email directly or view it on GitHub
#3687 (comment)
.

@mdboom
Copy link
Member

mdboom commented Oct 21, 2014

I think I have a fix attached. The logic that determines whether a marker is outside of the image (and thus doesn't need to be drawn), was only considering the stroke, not the fill. When there is no stroke, it was just happily drawing nothing at all.

@tacaswell
Copy link
Member

@WeatherGod That fix might be just on 1.4.x now, but not on master.

@tacaswell tacaswell modified the milestones: v1.4.x, v1.5.x Oct 21, 2014
@mdboom
Copy link
Member

mdboom commented Oct 21, 2014

I'm going to modify an existing test for this case, and then I think this is good to go.

@smutch
Copy link
Author

smutch commented Oct 22, 2014

Thanks for the quick attention guys. I love open source!

@tacaswell
Copy link
Member

We really need to re-generate all of the figures with a fixed set of fonts so we can go to pixel-match image tests...

@mdboom
Copy link
Member

mdboom commented Oct 22, 2014

@tacaswell: To your aside about fonts, I agree. We already are using the same fonts everywhere for testing. The issue is the specific version of freetype. I think we need to have an optional feature that downloads a very specific version of freetype and links against that. That would also solve the "installing on a bare Mac installation" problem.

@WeatherGod
Copy link
Member

Uhm, don't we remove text in most of our tests now to avoid the freetype
version issue?

On Wed, Oct 22, 2014 at 9:56 AM, Michael Droettboom <
[email protected]> wrote:

@tacaswell https://github.com/tacaswell: To your aside about fonts, I
agree. We already are using the same fonts everywhere for testing. The
issue is the specific version of freetype. I think we need to have an
optional feature that downloads a very specific version of freetype and
links against that. That would also solve the "installing on a bare Mac
installation" problem.

—
Reply to this email directly or view it on GitHub
#3687 (comment)
.

@tacaswell
Copy link
Member

But I don't think we use different metrics on those images and the tests are tuned to pass modulo text issues.

@mdboom mdboom mentioned this pull request Oct 22, 2014
Closed
@mdboom
Copy link
Member

mdboom commented Oct 22, 2014

#3699 is a backport to v1.4.x of this. The two branches are different enough that we'll need to merge both.

@mdboom mdboom mentioned this pull request Oct 24, 2014
Closed
tacaswell added a commit that referenced this pull request Oct 27, 2014
@tacaswell
Merge pull request #3687 from mdboom/marker-edge-width
2f97af7 
BUG : Errorbar markers not drawn in png output
@tacaswell tacaswell merged commit 2f97af7 into matplotlib:master Oct 27, 2014
tacaswell added a commit that referenced this pull request Oct 27, 2014
@tacaswell
Merge pull request #3699 from mdboom/no-marker-edge-width-fix
c29a117 
BUG : Backport of #3687 to 1.4.x
@tacaswell tacaswell mentioned this pull request Nov 14, 2014
Closed
@mankoff mankoff mentioned this pull request Nov 26, 2014
Closed
@tacaswell tacaswell mentioned this pull request Dec 9, 2014
Closed
@tacaswell tacaswell mentioned this pull request Dec 30, 2014
Closed
@mdboom mdboom mentioned this pull request Feb 12, 2015
Closed
@mdboom mdboom deleted the marker-edge-width branch March 3, 2015 18:44
@tacaswell tacaswell mentioned this pull request Sep 29, 2015
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@mdboom mdboom

Labels
None yet
Projects
None yet
Milestone
v2.1
Development

Successfully merging this pull request may close these issues.
5 participants
@mdboom @WeatherGod @tacaswell @smutch @QuLogic