FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Marker edges are randomly missing · Issue #4083 · matplotlib/matplotlib · GitHub

Repository navigation

Marker edges are randomly missing #4083

Closed

Description

The following code, run with version 1.3 or with 1.5.dev1, sometimes produces an entirely blank plot. This happens randomly; rerunning the script multiple times eventually produces the right output. This is on Linux, running python 3.4.0.

If the markers have a color, that color always appears. The edge sometimes are there, and sometimes aren't.

from matplotlib import pyplot

xs = [x for x in range(10)] * 10
ys = [x % 27 for x in range(10*10)]

pyplot.scatter(xs, ys, s=100, marker='o', color="none", edgecolor="red")
pyplot.savefig("test.png")

Is there a workaround? Can I help diagnose this bug? The two pictures below were produced by running the exact same program.


Activity

  1. cpitclaudel commented on Feb 8, 2015

    Author

    Here are two traces (strace python3 test.py): edges appearing properly | edges missing

    And the two pdfs: edges appearing properly | edges missing

  2. cpitclaudel commented on Feb 8, 2015

    Author

    Extra note: This seems to happen independently of the backend

  3. cpitclaudel commented on Feb 8, 2015

    Author

    And this doesn't seem to happen when using python 2.7

  4. tacaswell commented on Feb 8, 2015

    Member

    My guess is that you are running into issues with the state-machine and not drawing to the figure you think you are drawing to.

    Can you reporduce this with

    from matplotlib import pyplot as plt
    
    xs = [x for x in range(10)] * 10
    ys = [x % 27 for x in range(10*10)]
    fig, ax = plt.subplots()
    ax.scatter(xs, ys, s=100, marker='o', color="none", edgecolor="red")
    fig.savefig("test.png")
  5. cpitclaudel commented on Feb 8, 2015

    Author

    Thanks for your answer. I get exactly the same results with your code: sometimes I get circles; sometimes not.

  6. efiring commented on Feb 8, 2015

    Member

    @cpitclaudel What is your rough estimate of the frequency: is one outcome much more common, or do they seem equally likely? (It sounds like a timing issue, as if the plotting were being done in a thread and sometimes the file is written before the thread finishes--but of course this isn't it, because we aren't doing anything like that. Everything should be strictly sequential.)

  7. WeatherGod commented on Feb 8, 2015

    Member

    The observation that this is only happening with py3.4 makes me very
    suspicious. Of what? I haven't a clue, but something is fishy. We aren't
    seeing these sorts of issues with Travis testing. Could we simplify the
    code any further? Or is this strictly a problem with marker edges?

    On Sun, Feb 8, 2015 at 2:52 PM, Eric Firing notifications@github.com
    wrote:

    @cpitclaudel https://github.com/cpitclaudel What is your rough estimate
    of the frequency: is one outcome much more common, or do they seem equally
    likely? (It sounds like a timing issue, as if the plotting were being done
    in a thread and sometimes the file is written before the thread
    finishes--but of course this isn't it, because we aren't doing anything
    like that. Everything should be strictly sequential.)

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

  8. tacaswell commented on Feb 8, 2015

    Member

    I can not reproduce this at all with py34

    import matplotlib
    import numpy as np
    from PIL import Image
    
    matplotlib.use('agg')
    from matplotlib import pyplot as plt
    
    xs = [x for x in range(10)] * 10
    ys = [x % 27 for x in range(10*10)]
    
    N = 500
    
    for j in range(N):
        fig, ax = plt.subplots()
        ax.scatter(xs, ys, s=100, marker='o', color="none", edgecolor="red")
        fig.savefig("test_{:05d}.png".format(j))
        plt.close('all')
    
    base_image = np.array(Image.open('test_00000.png'))
    for j in range(N):
        test_image = np.array(Image.open("test_{:05d}.png".format(j)))
        if np.max(base_image - test_image):
            print("frame {} is bad".format(j))

    does not print anything (which is confirmed by visually scanning the thumbnails).

    What else is going on in your scripts?

  9. cpitclaudel commented on Feb 8, 2015

    Author

    I think about equally likely. I can reproduce this on two distinct Linux Mint machines

  10. cpitclaudel commented on Feb 8, 2015

    Author

    Could this be due to a memory corruption somewhere instead of a timing issue? Valgrind produces too many errors to be useful.

  11. cpitclaudel commented on Feb 8, 2015

    Author

    There's nothing else going on in my scripts that the MWE I posted. I'm not sure if I can reduce it further The problem also appears with 3D scatter plots.

  12. cpitclaudel commented on Feb 8, 2015

    Author

    @tacaswell I ran your script. It never returns any output; the images are always consistent. Sometimes it makes 500 blank images, sometimes 500 images with circles.

  13. tacaswell commented on Feb 8, 2015

    Member

    I just re-ran my script and got 5k frames with no points shown....

    The dependency on the process makes me think than someplace we are relying on ordering in a dictionary. Making key ordering in a dictionary random is one of the python 3 related changes iirc (to avoid DoS attacks on dictionaries).

  14. cpitclaudel commented on Feb 8, 2015

    Author

    Ah, a repro! I'm glad (and a bit sorry; one might have hoped my machines were just crazy). The dictionary is something I thought about earlier too, but I wasn't sure how to force the order of keyword arguments (ordereddicts didn't seem to help) :/ I didn't realize that python2 didn't behave the same way.

  15. 7 remaining items

  16. tacaswell commented on Feb 8, 2015

    Member

    I am inclined to say that the fix for this needs to be stuck on top of the 1.4.3 rc.

  17. modified the milestones: , v1.4.3 on Feb 8, 2015
  18. tacaswell commented on Feb 8, 2015

    Member

    Yup, the dict key ordering is the issue and

    sc = ax.scatter(xs, ys, s=100, marker='o', edgecolors="red", c="none")

    seems to consistently work.

  19. cpitclaudel commented on Feb 8, 2015

    Author

    @tacaswell Indeed! It doesn't work with color instead of c, though.

  20. tacaswell commented on Feb 8, 2015

    Member
    sc = ax.scatter(xs, ys, s=100, marker='o', edgecolors="red", facecolor="none")

    should also work consistently.

    The issue is that the kwargs color and edgecolor are not explicitly handled by the ax.scatter method (but the kwarg c is) and are instead handled by a call to collection.update(kwargs) which in turn calls coll.set_color and coll.set_edgecolor. set_color sets both the face and edge color to be the same (in this case 'none'). If the keys came out in the order ['color', 'edgecolor'] it worked fine as the edge color overrides the empty color and your graph looks fine. If they come out in the other order the color value overrides the edge color and you get invisible dots.

    I take back what I said about back-porting this to 1.4.3. It as a really annoying degeneracy in the input, but not a show stopper.

  21. cpitclaudel commented on Feb 8, 2015

    Author

    Indeed, that's correct! Fascinating bug. Thanks for the explanation.

  22. self-assigned this
    on Feb 8, 2015
  23. tacaswell commented on Feb 19, 2015

    Member

    This is fixed by #4079

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


    Back | FazBrowse Home | New Git URL