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

Feature request: Data cursor addition to plot and image toolbars · Issue #9957 · matplotlib/matplotlib · GitHub

Repository navigation

Feature request: Data cursor addition to plot and image toolbars #9957

Closed as not planned

Description

It would be great if you could copy the functionality as it exists in Matlab:
In the toolbar there is a 'Data Cursor' button.
This allows you to click on data points on the plot and it shows values.
It also allows you to move around the plot by using the arrow keys.
This is really helpful for scanning sample values quickly.

Activity

  1. anntzer commented on Dec 8, 2017

    Contributor

    There are (at least) two third party packages that implement this: https://github.com/joferkington/mpldatacursor/, https://github.com/anntzer/mplcursors (disclaimer: I wrote the later).
    I am not convinced that this needs to be part of the core library.

  2. eflanigan00 commented on Dec 9, 2017

    Author

    I disagree, this is in my top 3 things I significantly miss when I move from Matlab to python. And I hear other matlab users constantly comment on the lack of the feature in python.

    Most average users just want to plot and then use the tool bar to select the way they access the plot. The python toolbar has greatly improved over the years and I love using it. With that being said a default Data Cursor which also moves with the arrow keys would be a tremendous add. Otherwise it is not easy to see several exact values across the plot and/or image.

    Thanks for the links, I will try them out.

  3. dstansby commented on Dec 9, 2017

    Member

    I don't see why it shouldn't be a feature of Matplotlib!

  4. github-actions commented on Apr 27, 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!

  5. oscargus commented on May 28, 2023

    Member

    Reopening since this is a valid request (or at least should be closed by decision, not lack of response).

  6. added
    keepItems to be ignored by the “Stale” Github Action
    and removed
    status: inactiveMarked by the “Stale” Github Action
    on May 28, 2023
  7. timhoffm commented on May 28, 2023

    Member

    Semi-OT: Do we have an (efficient) „Artist under cursor“ (or more general „Artist at point“) mechanism? This would be the basis for any serious data interactivity and would IMHO need to be a core feature.

  8. anntzer commented on Jun 1, 2023

    Contributor

    You'll need to iterate over all artists anyways, and call contains() (the second item of the tuple contains the relevant info) or some reimplementation of it (mplcursors has one). For scalarmappables there's also get_cursor_data.

  9. oscargus commented on Jun 1, 2023

    Member

    This was discussed in the dev-call and the conclusion is that it seems unlikely that we will accept a PR doing this. Partly because it will be very hard to do it without any performance penalty. Hence, those that want this are referred to the third-party libraries linked above.

  10. timhoffm commented on Jun 2, 2023

    Member

    You'll need to iterate over all artists anyways, and call contains() (the second item of the tuple contains the relevant info) or some reimplementation of it.

    @anntzer Out of curiosity, would it be possible (at least for pixel backends) to create a second pixel image that encodes the Artist at that pixel? (E.g. the first artist draws all parts of itself in #000001, the second artist in #000002, etc. when you then want to know which artist is at a certain pixel, you take the color from this encoded image -if it is #000001, you know it is the first artist. The cost would be only at draw-time. I assume that this pixel map would come at a fraction of the overall draw costs since it‘s only the low-level agg calls that are duplicated. The usage would be very fast, because it‘s only a lookup. No iteration over artists and contains-checks.

  11. tacaswell commented on Jun 2, 2023

    Member

    I suspect that there are a bunch of ways to speed this up. I've thought a bit about what @timhoffm suggest here and also playing the bit-mask game so #000003 means "both artist 1 and artist 2 are in this pixel". I suspect that (atleast in Agg) it would be plausible to compute this in parallel with the actual rendering.

    If we added a way of asking "is any part of this artist in this bounding box?", then we could do things like grid the canvas up into 100x100 (or pick any number you want) and use that to filter the set of Artists you would need to look at.

    Either of these would also be very interesting for "auto blitting" as we could only clear the parts of the image that include the updated artist and detect which other artists need to be redrawn, but that is going off in a different direction.

  12. anntzer commented on Jun 3, 2023

    Contributor

    Agreed that this is indeed a cute idea. Needs a fair bit of working with the rendering internals, but seems plausible.

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions


      Back | FazBrowse Home | New Git URL