Fix contour level color mapping with explicit limits#599
Conversation
There was a problem hiding this comment.
Pull request overview
This PR fixes contour colormap normalization so that explicitly provided vmin/vmax are respected when manual levels are supplied, and ensures line contours use continuous normalization to keep level-to-color mapping one-to-one.
Changes:
- Preserve explicit
vmin/vmaxthrough contour level parsing and intoDiscreteNorm. - Update
DiscreteNormto only “stretch” bins to the full colormap range whenvmin/vmaxmatch the level bounds (default behavior), otherwise honor explicit limits. - Add regression tests covering explicit-limit behavior, default stretching, and explicit per-level contour line colors.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
ultraplot/axes/plot.py |
Thread vmin/vmax through level parsing and prevent DiscreteNorm binning for line contours (min_levels == 1). |
ultraplot/colors.py |
Adjust DiscreteNorm to respect explicit normalization limits and only apply the prior level-driven stretching by default. |
ultraplot/tests/test_2dplots.py |
Add regression tests for explicit limits with manual levels, default stretching, and line contour level color mapping. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # Generate DiscreteNorm for filled-contour style bins. For line contours | ||
| # (`min_levels == 1`) levels represent contour values, so keep the | ||
| # continuous normalizer to preserve one-to-one value->color mapping. | ||
| center_levels = _not_none(center_levels, rc["colorbar.center_levels"]) |
There was a problem hiding this comment.
The _parse_level_norm docstring says it returns a DiscreteNorm/BoundaryNorm, but with the new min_levels == 1 behavior it can return the original continuous Normalize (line contours). Please update the Returns section to reflect the possible return types so users don't rely on an incorrect contract.
There was a problem hiding this comment.
@copilot open a new pull request to apply changes based on this feedback
|
@cvanelteren I've opened a new pull request, #600, to work on those changes. Once the pull request is ready, I'll request review from you. |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…600) * Initial plan * Update _parse_level_norm docstring Returns section to reflect possible return types Co-authored-by: cvanelteren <19485143+cvanelteren@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Casper van Elteren <caspervanelteren@gmail.com> Co-authored-by: cvanelteren <19485143+cvanelteren@users.noreply.github.com>
|
Hmmm something funky going on with some of the categorical colorbars -- will need to fix this another time. |
Closes #329
This PR fixes the contour normalization behavior when manual levels are provided. The core problem was that explicit vmin and vmax were being discarded in the level-parsing path and then effectively overridden again inside
DiscreteNorm, socontourf(..., levels=..., vmin=..., vmax=...)did not respect the user’s intended range. In the same area, line contours were also being routed through discrete binning logic that is appropriate for filled contours but not for level lines, which could cause adjacent line levels to resolve to the same color even when explicit colors were supplied. The change preserves explicit normalization limits when they are provided, keeps the existing default level-driven stretching when they are not, and keeps line contours on a continuous mapping path so level colors remain one-to-one with the requested values. Regression tests were added to lock in all three behaviors.