You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would be nice if we could just pass a function as a cmap, and matplotlib would just query it to get a color from a value.
example of usage:
fromcolorsysimporthsl_to_rgbimportmatplotlib.pyplotasplty= ... # some data for an histogramcmap=lambdax: hsl_to_rgb(x, .9, .5)**2plt.hist(y, cmap=cmap)
Proposed Solution
I don't know how realistic this is but I've just never seen it even suggested when googling.
It certainly feels reasonable to me but I can't tell because I don't know much about the implementation.
If this is not feasible at least this would set a record for future google queries...
We currently only have lookup-table based colormaps for continous color scales (see LinearSegmentedColormap). From a design perspective, it would be reasonable to add a FunctionColormap for this. Due to over/under/bad settings a colormap is slightly more than just the continuous mapping with a function.
Whether we implicitly create the colormap for cmap=lambda x: hsl_to_rgb(x, .9, .5) or if we require explicit creation via cmap=FunctionColormap(lambda x: hsl_to_rgb(x, .9, .5)) is still to be decided separately.
I'm in favor of this since it's the straightforward way to do discrete categorical mapping, only conceptual problem is it conflates norm w/ cmap but I dunno that that's a bad thing since the alternative (#6934) gets messy fast.
I'm in favor of this since it's the straightforward way to do discrete categorical mapping, only conceptual problem is it conflates norm w/ cmap but I dunno that that's a bad thing since the alternative (#6934) gets messy fast.
BoundaryNorm is for binning data, while categories are basically the edges of those bins (or the center) and therefore requires some hackyness since BoundaryNorm returns a color for every bin rather than for every edge. There also isn't a direct val-color mapping, that's given by separately using a listed colormap that happens to line up w/ the bins.
categorical color mapping is {'category': 'color'} - the upside also is that this would allow bypassing of the unit system for color while still getting some of the same benefits.
BoundaryNorm is for binning data, while categories are basically the edges of those bins (or the center) and therefore requires some hackyness since BoundaryNorm returns a color for every bin rather than for every edge. There also isn't a direct val-color mapping, that's given by separately using a listed colormap that happens to line up w/ the bins.
I'd still suggest this mapping is the job of a Norm. If we want to call it CategoricalNorm that would be great - it would really just be a trivial extension of BoundaryNorm.
But 'NoNorm' handles it natively - the difference is that like in this case it doesn't really make sense to split the color transform into norm and cmap steps since the value: color map is so direct.
IMHO the categorical colormap discussion is largely orthogonal to the topic of function colorbars.
Our current colormap classes are restricted to a lookup table. While you can approximate anything with a lookup table, it would be nice to have interpolation-free mapping - at least on the API level. The user should not have to care about discretizing the values by hand.
Side note: Calling the function for evaluation will usually be slower, but that's a trade-off the user will have to make. One could also add conversions like FunctionColormap(lambda x: hsl_to_rgb(x, .9, .5)).to_listedcolormap(N=256). With a little effort, it should even be possible to automatically create a lookup-table, that has a resolution below the RGB discretization threshold.
Generally, I agree that mapping from categorical values is the task of a norm. Colormaps are currently always [0, 1] -> (R, G, B) mappings. However, one might discuss if the restriction can be lifted for discrete categorical mappings. But that's another topic.
That said, there are a number of issues with the current colormap implementation (limitation to LUT, difficult create custom cmaps from data, difficult to create new colormaps from existing colormaps, ...). Function colorbars should probably discussed in a more general colormap redo.
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!
Activity
timhoffm commentedon Jan 8, 2021
We currently only have lookup-table based colormaps for continous color scales (see LinearSegmentedColormap). From a design perspective, it would be reasonable to add a
FunctionColormapfor this. Due to over/under/bad settings a colormap is slightly more than just the continuous mapping with a function.Whether we implicitly create the colormap for
cmap=lambda x: hsl_to_rgb(x, .9, .5)or if we require explicit creation viacmap=FunctionColormap(lambda x: hsl_to_rgb(x, .9, .5))is still to be decided separately.jklymak commentedon Jan 8, 2021
We also have
ListedColormapwhich can easily be generated with your function above. https://matplotlib.org/tutorials/colors/colormap-manipulation.htmlthat you could make to arbitrary resolution:
(there is probably a way to vectorize that, but...)
Given the simplicity of this I don't know that I'd be in favour of a third way to do the same thing....
story645 commentedon Jan 8, 2021
I'm in favor of this since it's the straightforward way to do discrete categorical mapping, only conceptual problem is it conflates norm w/ cmap but I dunno that that's a bad thing since the alternative (#6934) gets messy fast.
jklymak commentedon Jan 8, 2021
Isn't that what a
BoundaryNormis for?story645 commentedon Jan 8, 2021
BoundaryNorm is for binning data, while categories are basically the edges of those bins (or the center) and therefore requires some hackyness since BoundaryNorm returns a color for every bin rather than for every edge. There also isn't a direct val-color mapping, that's given by separately using a listed colormap that happens to line up w/ the bins.
categorical color mapping is {'category': 'color'} - the upside also is that this would allow bypassing of the unit system for color while still getting some of the same benefits.
jklymak commentedon Jan 8, 2021
I'd still suggest this mapping is the job of a Norm. If we want to call it
CategoricalNormthat would be great - it would really just be a trivial extension ofBoundaryNorm.story645 commentedon Jan 8, 2021
But 'NoNorm' handles it natively - the difference is that like in this case it doesn't really make sense to split the color transform into norm and cmap steps since the value: color map is so direct.
timhoffm commentedon Jan 9, 2021
IMHO the categorical colormap discussion is largely orthogonal to the topic of function colorbars.
Our current colormap classes are restricted to a lookup table. While you can approximate anything with a lookup table, it would be nice to have interpolation-free mapping - at least on the API level. The user should not have to care about discretizing the values by hand.
Side note: Calling the function for evaluation will usually be slower, but that's a trade-off the user will have to make. One could also add conversions like
FunctionColormap(lambda x: hsl_to_rgb(x, .9, .5)).to_listedcolormap(N=256). With a little effort, it should even be possible to automatically create a lookup-table, that has a resolution below the RGB discretization threshold.Generally, I agree that mapping from categorical values is the task of a norm. Colormaps are currently always
[0, 1] -> (R, G, B)mappings. However, one might discuss if the restriction can be lifted for discrete categorical mappings. But that's another topic.That said, there are a number of issues with the current colormap implementation (limitation to LUT, difficult create custom cmaps from data, difficult to create new colormaps from existing colormaps, ...). Function colorbars should probably discussed in a more general colormap redo.
[-]Colorbars from function[/-][+]Color maps from function[/+]github-actions commentedon Sep 27, 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!
story645 commentedon Sep 27, 2023
I'm kinda setting as keep but I also think this is probably more or less handled via some composition with https://matplotlib.org/devdocs/api/_as_gen/matplotlib.colors.FuncNorm.html#matplotlib.colors.FuncNorm and possibly would be useful to add an example showing that.