The colorsys module has some simple conversions between the most famous color spaces (RGB, HSL, etc) but there are other color conventions that can be very useful. One example is the CIELAB color space.
The colormath module implements some other conversions but it’s apparently not maintained anymore. There are other interesting modules for this, like spectra but this depends on colormath.
I wonder if it could be a good idea to implement more conversions to the core colorsys module (at least CIELAB), as the bare conversion functions are very simple, and testing also.
I also could implement it myself, based on these other non-core modules, but I would like to first have an idea on whether the Python community thinks this is a sensible addition to a core library like this.
Also, indeed many libraries have these. As already noted scikit-image. Also, matplotlib, then pillow and pretty much all plotting and imaging libraries will have a superset of color spaces that exist in colorsys.
However, this does not mean that mature basic standards can not be part of standard library. After all, there is already a module for that and the reason is to have these in cases, where adding big dependencies purely for color conversion is suboptimal.
However, I think you may need to make a concrete proposal on what exactly you wish to add. Personally, I think good start would be CMY.
Regarding more exotic standards some convincing might be needed.
E.g. Why is such the best addition among all available? What does it add that can not be easily done with other color spaces? Is this the best model to provide such? What does it enable? What is your personal use case for it?
colorsys was one of the modules recently proposed for removal, because it seems to current coredevs to be peripheral and well-covered by 3rd party packages by people with appropriate knowledge and interest. In other words, it would not be added now if not present. It is certainly not needed by python itself or any of the core modules. It was of the subset not removed because there was sufficient current use that would be broken. But I believe there was no intention to expand it.
The doc could/should refer to more complete modules, especially non-obvious ones part of larger packages. Or someone could take over colormath, if really not maintained, to collect functions otherwise buried in packages. Or, if license allows, someone could mirror one of them.
That makes a lot of sense indeed! One of the main reasons why I thought it would be interesting is because I’d argue that if colorsys even exists, there’s no reason for it to be incomplete, given the ease of maintenance of something minimal as pointed out by @dg-pb.
But if it’s supposed to be removed, then in a way I’d argue this will just be solved in another way!
Generally, I think that standard library modules should have a clear scope, and it should be possible – with enough time and effort – to get “done”. That’s not always possible, but very nice when it is.
The colormath module currently sticks to “simple” colors for uncalibrated computer monitors. For example, anything involving reference illuminants (making demands on users to use the functionality correctly) or perceptual uniformity (AFAIK, still an area of active research) are left for an external library.
So rather than discussing to add CIELAB or “more conversions”, we should first talk about how the scope should expand. “Useful representations of color” is not specific enough. Maybe it could be CSS Color Module Level 4 – a specific, complete standard, though one that’s rather tricky to fully implement.
The best way to get something like that in colormath would be to first implement it in an external module and put it on PyPI, then ask again when it’s feature-complete. Even if you do that, it’ll probably turn out to be better to keep it as a third-party module.
Another option is to stick with colors for uncalibrated computer monitors, and add hwb. To me, that would be an easier sell than CIELAB, but I’m not sure it’s useful enough to bother adding it.
Is is NOT ‘supposed’ to be removed. It was proposed for removal, for reasons stated. After review, it was, along with a few other modules, removed from the removal list because of sufficient external use, but without intent for a major upgrade. It has since been bug-fixed at least once. I pretty much agree with what Petr said.