Improved handling of out-of-range values

[matthiasschabel]

I've been building a colormap browser/editor for napari that includes cmap, but has a number of extensions (see this discussion on napari chat). Wondering what the level of interest/willingness is to consider upstreaming some of these. One aspect, in particular, is the handling of OOR numbers. Given that floating point values (IEEE-754) are typical representations of much of the data in scientific visualization, a slightly richer special colors handling system would be nice. There are essentially six distinguishable cases for mapping of a float value to an indexed color: -inf, below specified lower bound, in bounds, above specified upper bound, +inf, and NaN. cmap doesn't currently offer a mechanism for specifically handling the infinities, even though those are potentially useful to discriminate (there is a discussion in the comments in the linked thread above).

[tlambert03]

so is the feature request here to add something like neg_inf and pos_inf to the existing bad values here?

cmap/src/cmap/_colormap.py

Lines 132 to 137 in 8040ef7

	under : ColorLike | None
	The color to use for values below the colormap's range.
	over : ColorLike | None
	The color to use for values above the colormap's range.
	bad : ColorLike | None
	The color to use for bad (NaN, inf) values.

i took a peak at the thread, but can you re-explain where the original concept for 5 out-of-range values (instead of 3, discriminating between over/under and over-inf/under-inf) came from? Is this something that any other libraries do? What is the real world use case? is it something that napari supports now?

[matthiasschabel]

so is the feature request here to add something like neg_inf and pos_inf to the existing bad values here?

cmap/src/cmap/_colormap.py

Lines 132 to 137 in 8040ef7

	under : ColorLike | None
	The color to use for values below the colormap's range.
	over : ColorLike | None
	The color to use for values above the colormap's range.
	bad : ColorLike | None
	The color to use for bad (NaN, inf) values.

Yes, we would have a finer-grained set : {neg_inf, pos_inf, nan, inf, bad} where the more specific values, if defined, override the more general ones (inf = {neg_inf U pos_inf}, bad = {inf U nan}).

i took a peak at the thread, but can you re-explain where the original concept for 5 out-of-range values (instead of 3, discriminating between over/under and over-inf/under-inf) came from? Is this something that any other libraries do? What is the real world use case? is it something that napari supports now?

It is not something that is widely supported - I built it into my own colormap library to support MRI data modeling. napari doesn't support it currently, but one of the maintainers (Tim Monko) is interested in working to integrate the colormap browser/editor that I built into napari. Rather than maintaining a parallel extension of cmap, if the added functionality could be upstreamed, that would simplify maintenance and avoid proliferating another colormap system... A few of the specific cases were listed in that thread : log transformed MRI signal data can have zero values, which you want to catch. Logistic regression can also give -inf/+inf values to indicate perfect prediction. More generally, this would provide comprehensive support for all representable floating point values so a user can, in principle discriminate all of the distinct numerical cases. I'd be happy to put together a PR for this.

[matthiasschabel]

cmap/src/cmap/_colormap.py

Lines 132 to 137 in 8040ef7

	under : ColorLike | None
	The color to use for values below the colormap's range.
	over : ColorLike | None
	The color to use for values above the colormap's range.
	bad : ColorLike | None
	The color to use for bad (NaN, inf) values.

As an aside, I think the documentation is incorrect - the bad color doesn't do anything with infinities, which I believe are mapped to the under/over colors?

[matthiasschabel]

On further reflection (see #148), there should probably be a masked case as well since that is a final, identifiably different case than the ones I enumerated above.