Repository navigation
[ENH] Unit support for ScalarMappables #7383
Description
In #6934 (categorical colormapping), I'm trying to add support for imshow visualizing arrays of strings ('cause strings are data...) and then creating the associated colorbar and eventually a legend.
What I've run headlong into (and has created spaghetti code) is that imshow doesn't support unit conversions, which sort of makes sense as norms dictate how things should be colored but it also creates this weird circular dependencies of sorts on how the data gets coded when it's time to also set up the colorbars 'cause of how ticks/locators are done there (still super confused on all that).
I'd really like to add that sort of "unit" knowledge to imshow (or its underlying object).
The plan is to:
- extend the AxisInfo object in units.py with the default norm, colormap, and cbar locators/formatters or to create another object SMInfo or something that stores that info.
Edit: Can't decide the name 'cause this is an issue for anything that takes a colorbar, which is both the AxesImage objects and stuff like scatter.
2) use units in the underlying imshow code in the manner it's currently used in the plot code.
I think this could also maybe be used to later refactor the colorbar code or norms or something. And possibly codifying what's the defaults for floats and ints and the like-basically unit becomes a stylesheet of sorts for data.
Activity
[-][ENH] Unit support for ScalerMappables[/-][+][ENH] Unit support for AxesImage[/+][-][ENH] Unit support for AxesImage[/-][+][ENH] Unit support for ScalerMappables[/+]kahnchana commentedon Mar 31, 2017
I'm trying to work on this. So I went through units.py and also pyplot.py with imshow function implementations. Is there anything special I should know before trying this? I am currently going through the colormap and normalization documentation as well.
story645 commentedon Mar 31, 2017
Look through the normalization, colormap, and colorbar code.
kahnchana commentedon Mar 31, 2017
Should I fork the matplotlib code or the code you've worked on when doing this?
story645 commentedon Mar 31, 2017
matplotlib
story645 commentedon Feb 4, 2018
@jklymak I dunno if this should be thought through as part of a units MEP or built on top of one, but mostly fyi.
jklymak commentedon Feb 4, 2018
Cool. OTOH I personally think this should just be its own method versus something that gets tacked into
imshow, so I wouldn't write that part of the MEP 😉 But thats just my vote....story645 commentedon Feb 4, 2018
it's not about imshow but about all scalermappable. A fairly popular request is to natively get categories working in scatter plots (no loops) and that would kind of come for free with any solution that's generalizable to scalermappables. It can sort of be solved just via a categorical norm, but that doesn't fit with the idea of it being a magically handled type. (Also part of this would be to hook in legends)
13 remaining items
dopplershift commentedon Mar 27, 2018
I kind of like the idea of a
CategoryNorm...but would that get the automated labels for the colorbar?story645 commentedon Mar 27, 2018
So I tried doing that in #6934 and it quickly became spaghetti...
Yeah, that's what I wonder too...and legends even more so...maybe the code is the same? CategoryNorm creates a list of labels, and I guess falls back to the cmap if there's no list of colors for legend to work on?
jklymak commentedon Mar 27, 2018
Automatic labels for a colorbar are pretty hard to implement anyway - I think the call would be for a legend like above? It seems writing a legend subclass would be possible as well.
dopplershift commentedon Mar 28, 2018
Well, if the
CategoryNormhad the inverse mapping, you could run the tick values back through it...story645 commentedon Mar 28, 2018
And then going off @jklymak 's suggestion, use something like ax.sclegend() (yes have no idea how to name this) that subclassess legend and will generate off norm and cmap info? I'm tentatively not opposed to that approach...
efiring commentedon Mar 28, 2018
I really think the colorbar is the wrong tool for this, and a specialized legend (a separate function that calls legend, not more kwargs for the existing legend) is the appropriate tool. Similarly, I am strongly opposed to trying to pile any more functionality of this sort directly into imshow and similar functions.
story645 commentedon Mar 28, 2018
I agree that colorbar is the wrong tool, but I tink his wouldn't actually require any new kwargs to be passed to legend since the cmap and norm can be obtained via handle or axes inspection, same as current legend.
When thinking through this on the unit side, the implementation would probably be on the norm/cmap side of things any which way since that's probably the way to generalize it to all ScalerMappable. But what I'd want on the units side is a "default norm" of sorts, like the locator and formatter. So if people are using categorical data, they're also using categorical norm unless they explicitly change it. That would give me the "norming for free" and probably wouldn't require any changes to AxesImage or the like.
efiring commentedon Mar 28, 2018
I presume the norm would map a list of strings to consecutive integers starting at zero, so that these integers would directly index into a discrete colormap. The user would have to choose a map with a suitable (presumably small) number of well-distinguished colors--something like one of the color sets used for plotting lines. There would be no concept of "over" and "under"; strings not in the list supplied to the norm would be in the "bad" category, for which a color (or full transparency) can be specified in the colormap.
story645 commentedon Jul 12, 2019
So thinking through this even more, the most straightforward way to do this at first would probably be to attach a convertor to NoNorm
jklymak commentedon Jul 31, 2020
Carrying on the discussion in #18139: it seems to me the sticking point is still that I've never seen someone store a 2-D array of strings. If I have seen two-D arrays of "categories" they have been integer arrays with appropriate metadata stating the integer-category mapping.
Are 2-D arrays of string objects something anyone has actually wanted to work with? It seems working this up as a standalone package would help show its utility for the core library. I don't see what's preventing a standalone package that is at least of proof of concept.
github-actions commentedon Apr 2, 2023
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!