-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Improve formatting of imshow() cursor data independently of colorbar. #20949
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.
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense to me.
d280424
to
b00423f
Compare
lib/matplotlib/_api/__init__.py
Outdated
@@ -297,3 +298,20 @@ def warn_external(message, category=None): | |||
break | |||
frame = frame.f_back | |||
warnings.warn(message, category, stacklevel) | |||
|
|||
|
|||
def g_sig_digits(value, delta): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function is not API related. I think it should be cbook._g_sig_digits
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anybody can merge after CI pass.
@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. |
@meeseeksdev backport to v3.5.x |
…ata independently of colorbar.
…949-on-v3.5.x Backport PR #20949 on branch v3.5.x (Improve formatting of imshow() cursor data independently of colorbar.)
Improve formatting of imshow() cursor data independently of colorbar.
Improve formatting of imshow() cursor data independently of colorbar.
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
pytest
passes).flake8
on changed files to check).flake8-docstrings
and 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).