Improve formatting of imshow() cursor data independently of colorbar.#20949
Merged
jklymak merged 1 commit intomatplotlib:masterfrom Sep 10, 2021
Merged
Improve formatting of imshow() cursor data independently of colorbar.#20949jklymak merged 1 commit intomatplotlib:masterfrom
jklymak merged 1 commit intomatplotlib:masterfrom
Conversation
4 tasks
anntzer
force-pushed
the
smd
branch
2 times, most recently
from
d280424 to
b00423f
Compare
timhoffm
reviewed
Sep 9, 2021
lib/matplotlib/_api/__init__.py
Outdated
| warnings.warn(message, category, stacklevel) | ||
|
|
||
|
|
||
| def g_sig_digits(value, delta): |
Member
There was a problem hiding this comment.
This function is not API related. I think it should be cbook._g_sig_digits.
Currently, when a colorbar is present, the cursor data under imshow() is
formatted using the colorbar's cursor formatter (the idea being that
that formatter should be able to "smartly" take normalization limits
into account); if no colorbar is present a fixed format string ("%0.3g")
is used.
In fact, there is a better scale that defines the number of significant
digits one should display in an imshow cursor data: it arises because
colormaps are discrete (usually with 256 colors, but in any case the
value is available as `cmap.N`). This quantization tells us, for a
given value, by how much one needs to move before the underlying color
changes (at all); that step size can be used to to determine a number
of significant digits to display. (Even if that's not necessarily
always the best number, it should at least be reasonable *given the
user's choice of normalization*.)
Also, note that because ScalarFormatter has now changed to take pixel
size into account when determining *its* number of significant digits,
the previous approach of relying on the colorbar formatter has become
a less good approximation, as that means that the number of digits
displayed for an imshow() cursor could depend on the physical size of
the associated colorbar (if present).
Also factor out and reuse some logic to compute the number of
significant digits to use in format strings for given value/error pairs,
already used by the linear and polar tickers.
timhoffm
approved these changes
Sep 9, 2021
Member
timhoffm
left a comment
timhoffm
left a comment
There was a problem hiding this comment.
Anybody can merge after CI pass.
Member
|
@meeseeksdev backport to 3.5.x |
|
Something went wrong ... Please have a look at my logs. It seem that the branch you are trying to backport to does not exists. |
Member
|
@meeseeksdev backport to v3.5.x |
meeseeksmachine
pushed a commit
to meeseeksmachine/matplotlib
that referenced
this pull request
Sep 10, 2021
…ata independently of colorbar.
timhoffm
added a commit
that referenced
this pull request
Sep 10, 2021
…949-on-v3.5.x Backport PR #20949 on branch v3.5.x (Improve formatting of imshow() cursor data independently of colorbar.)
7 tasks
tacaswell
pushed a commit
that referenced
this pull request
Oct 20, 2021
Improve formatting of imshow() cursor data independently of colorbar.
ericpre
pushed a commit
to ericpre/matplotlib
that referenced
this pull request
Oct 20, 2021
Improve formatting of imshow() cursor data independently of colorbar.
Closed
6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently (since #12459), when a colorbar is present, the cursor data under imshow() is
formatted using the colorbar's cursor formatter (the idea being that
that formatter should be able to "smartly" take normalization limits
into account); if no colorbar is present a fixed format string ("%0.3g")
is used (see #12473 for a stalled attempt to work around that).
In fact, there is a better scale that defines the number of significant
digits one should display in an imshow cursor data: it arises because
colormaps are discrete (usually with 256 colors, but in any case the
value is available as
cmap.N). This quantization tells us, for agiven value, by how much one needs to move before the underlying color
changes (at all); that step size can be used to to determine a number
of significant digits to display. (Even if that's not necessarily
always the best number, it should at least be reasonable given the
user's choice of normalization.)
Also, note that because ScalarFormatter has now changed to take pixel
size into account when determining its number of significant digits (#16776),
the previous approach of relying on the colorbar formatter has become
a less good approximation, as that means that the number of digits
displayed for an imshow() cursor could depend on the physical size of
the associated colorbar (if present).
Also factor out and reuse some logic to compute the number of
significant digits to use in format strings for given value/error pairs,
already used by the linear and polar tickers.
PR Summary
PR Checklist
pytestpasses).flake8on changed files to check).flake8-docstringsand runflake8 --docstring-convention=all).doc/users/next_whats_new/(follow instructions in README.rst there).doc/api/next_api_changes/(follow instructions in README.rst there).