Road color scripts depend on unmaintained colormath module

[imagico]

Our python scripts for generating the road color sequence (https://github.com/gravitystorm/openstreetmap-carto/blob/master/scripts/generate_road_colours.py) and the unpaved road patterns (https://github.com/gravitystorm/openstreetmap-carto/blob/master/scripts/generate_unpaved_patterns.py) depend on the python colormath module - which is now unmaintained.

For the AC-Style i have written a srgb-to-lab and back conversion derived from MIT licensed javascript code i found (https://github.com/imagico/osm-carto-alternative-colors/blob/d39d061ec793d79c5abe602287fadb79b237b615/scripts/generate_unpaved_patterns.py#L41) - which is all that is needed for the unpaved patterns. The road color sequence generation uses some additional functions which would need to be implemented (LCH-space conversion and deltaE calculation).

[pnorman]

I've been using Chroma.js for color stuff lately, but don't want to add another language. Sticking with python, I looked at the following

• https://www.colour-science.org/ looks to be the best option. You have to explicitly go through CIE XYZ and CIE Lab. Unfortunately it brings a lot of spectral stuff that doesn't matter for us, and has heavy dependencies
• LuxPy has similar dependencies, but doesn't do Lab to Lch so you have to do that yourself.
• colorzero is simple, but has no lch support
• colour has no Lab support at all
• colorspacious looks to do everything we need and little more, but the API isn't great

colorspacious looks to be the best option.

Given that colormath is in Debian stable, I don't see any particular urgency.

[imagico]

Given that colormath is in Debian stable, I don't see any particular urgency.

My main concern is that as is working on the road colors is essentially inaccessible to developers without a substantial amount of hand fiddling (like installing Debian or some other old distribution in a virtual environment).

colorspacious looks relatively clean and without much bloat - i have not checked if it implements an unclipped sRGB color space (which would be necessary to do the out-of-gamut test the way we do it right now).

[pnorman]

My main concern is that as is working on the road colors is essentially inaccessible to developers without a substantial amount of hand fiddling (like installing Debian or some other old distribution in a virtual environment).

Why would they need to do that?

[imagico]

Why would they need to do that?

How do you install colormath on a system that does not support it any more?

Yes, you probably can manually install an older version of numpy and the last colormath release available - but that is massive hand fiddling in my book (and nothing i would want to do on a system that is also used for other things).

[pnorman]

How do you install colormath on a system that does not support it any more?

pip install colormath, ideally in a venv.

It's pure python with three requirements. The only difficult requirement would be numpy since I believe the others are pure python, and that would only break if numpy 2.0 came out and changed the APIs that colormath uses. Even then you could force an install of numpy<=2.0, and that would only stop working once 1.x stopped being released and the last 1.x release stopped working.

I'm not saying we shouldn't move - it is after all unmaintained and bugs will not be fixed. I'm saying that installing it with the standard python methods still works like before, and will continue to work for years.

We don't document how to set up the python environment to run any of the scripts but the standard method of a venv and then pip install for the dependencies works fine. Maybe we should ship a requirements.txt to make that easier?