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

Skip to content

Conversation

timhoffm
Copy link
Member

@timhoffm timhoffm commented Sep 11, 2025

This allows to explicitly state whether inputs should be handled as normalized values [0, 1] or indices into the colormap.

The value by_index='auto' is the current default and makes the interpretation dependent on the data type. Resulting in surprising behavior #28198. It is planned to deprecate this in a follow-up PR and switch to
by_index=False eventually. The standard case of float inputs will not be affected by this change. But users that want to pass indices, will then have to explicitly use by_index=True.

Note: We currently rely on the auto detection for BoundaryNorm. That will be handled by special casing BoundaryNorm in the colorizer pipeline, essentially switching cmap(norm(data)) to cmap(norm(data), by_index=isinstance(norm, BoundaryNorm)). It's better to do the special casing there rather than the type-based autodetection in Colormap.__call__. Hopefully, we can additionally get rid of that special case through #21911 (comment), but that's a separate discussion and its result does not impact the meaningfulness of this PR.

This allows to explicitly state whether inputs should be handled as
normalized values [0, 1] or indices into the colormap.

The value `by_index='auto'` is the current default and makes the
interpretation dependent on the data type. Resulting in surprising
behavior matplotlib#28198. It is planned to deprecate this in a follow-up PR and
switch to
`by_index=False` eventually. The standard case of float inputs will not
be affected by this change. But users that want to pass indices, will
then have to explicitly use `by_index=True`.
@anntzer
Copy link
Contributor

anntzer commented Sep 12, 2025

I don't really think #28198 is actually a problem and would leave the behavior as is, but if we're really going to change this (I'm only -0 but nowhere close to blocking) then I'd say that indexing should just be a new operation (cmap[idx] -- which seems best to me -- or cmap.colors[idx], as discussed in the issue thread), not a flag on __call__.

@timhoffm
Copy link
Member Author

I think #28198 is a footgun that should be removed. Needing the upper-limit color of a colormap is not completely unlikely, and intuition suggests cmap(1). It's completely non-obvious that you need to do cmap(1.).

Ideally, Colormap.__call__ would always expect values in the range [0, 1]. But we need indexing capability to support the awkward BoundaryNorm. While I'd like to get rid of that, the discussion is still open, see #21911, and anyway that'd be a more long-term project.

Since for the time being we need indexing capability, at least I want to make that explict and not decide call behavior based on the data type. You have two options for this, an additional paramter by_index, or a separate function cmap.by_index(X, alpha=None, bytes=False)(note that[idx]is not sufficient because we need to support the extra parameters to keep full functionality forBoundaryNorm` use cases).

The by_index kwarg is the simpler implementation. A by_index() function would also be possible, but needs more internal rearchitecting of Colormap.

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

Successfully merging this pull request may close these issues.

2 participants