Skip to content

[ENH]: UnitizedNorm #27706

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

Open
story645 opened this issue Jan 26, 2024 · 2 comments
Open

[ENH]: UnitizedNorm #27706

story645 opened this issue Jan 26, 2024 · 2 comments

Comments

@story645
Copy link
Member

story645 commented Jan 26, 2024

NOTE: This is very much in the discussion nobody should actually attempt it phase. Especially since #27721 is a probably better solution to the same meta problem.

Problem

Lots of requests for colormapping unitized data, such as #7383, #25062, #23991, #19476, #17447

Proposed solution

Since the number -> number that can be colormapped conversion is done in the norm, proposing that we make an explicit Norm for handling units:

UnitizedNorm:

Create a new norm object UnitizedNorm:

  • maps data to numbers using {Convertor}.convert
  • labels colorbar using the formatters from {Convertor}.axisinfo

The hard work here is integrating this into the existing color-mapping pipeline, particularly the interpolation pipeline. One approach may be to add a flag indicating whether the unit can participate in existing schemes or whether it provides its own interpolation methods. If this works, then .UnitizedNorm can be shimmed in to act as an analogue to NoNorm

UnitizedNorm(Normalize)

I don't know if this is actually possible, or remotely worth the effort given @ksunden's work, but a follow on proposal is that UnitizedNorm acts as a wrapper around Normalize objects so that the norms can take in unitized inputs, where UnitizedNorm(NoNorm) == UnitizedNorm() is the default described above. The objective would be to allow support for things like
`UnitizedNorm(BoundaryNorm(['2011-01-01', '2011-02-01', '2011-03-01']))' or "UnitizedNorm(Normalize(vmin=Pint(10))"

Pretty sure that if this is possible, it ends up being some sorta dynamic monkeypatching of the existing class. But also if possible then it can be written as a decorator and that would be nice to have for custom Norms.

@dstansby
Copy link
Member

I'm not sure I follow the need for a new norm - what does that add above storing units and a converter on ScalarMappable, then using the current conversion machinary to convert the data to floating point values before going through existing norms?

FWIW I tried this in #20962, didn't have time to finish it off, but in the last week I've been working on resurrecting that work at https://github.com/dstansby/matplotlib/tree/image-units. That branch is specifically for images, but the same approach does work for other ScalarMappables like contours and scatter colours. Hopefully I can have a proof-of-concept PR open in the next week or so.

@story645
Copy link
Member Author

story645 commented Jan 29, 2024

what does that add above storing units and a converter on ScalarMappable, then using the current conversion machinary to convert the data to floating point values before going through existing norms?

Just an alternative approach, idea being very explicit opt in & I wrote this up as a potential GSOC project cause it seemed like an easier way to do this. I really like the put units on the ScalarMappable solution - are you threading units through the norms the way they're thread through axes limits so that the norm params can be specified in units?

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

No branches or pull requests

2 participants