Ranges for color space values

[MichaelMauderer]

I just noticed that color spaces do not all document the ranges of expected values and are somewhat inconsistent, e.g., XYZColor seems to assume values scaled from 0...1 and LChab assumes values from 0...100 (for L and C). The current implementation of the CAMs then again expects XYZ values from 0...100.

So at the very least this should be documented everywhere, and then maybe things should be made consistent in the future (but this is of course a backwards compatibility problem).

I will definitely adjust the CAMs, so they don't produce unexpected behavior when used with the values from XYZColor objects.

[gtaylor]

We're going to be doing somewhat of a major release next, it may make sense to go on ahead and get this standardized now.

I think RGB is 0...1 now, and I have rarely every seen 0...100 for XYZ out in the wild. I have seen a good deal of L values 0...100, though.

Given the choice between the two, 0...1 makes the most sense to me. Thoughts?

[MichaelMauderer]

I agree. 0...1 it is. (Assuming no one else complains).

I might have some time to go over this tomorrow, I'll start with documenting the current state in order to get an overview of what is used where.

[gtaylor]

Sounds good. As a side note, if we can think of anything else backwards incompatible that needs doing, let's figure out what those things are. This is going to be a pretty big release, so it's an opportune time to get the dirty work done.

I'm not at all afraid of breaking backwards compatibility if it is for the best, though. This is a period of rapid and sweeping changes, but once we get things settled and stabilized, I think we're going to be way better off.

[MichaelMauderer]

I'll give it a thought.

There are a few more feature related things that I will (or want to) have a look at, I'll open a few tickets for those, just so there is a record of things to expect.

[MichaelMauderer]

Since the change will not necessarily noticeable break, we could give warnings for implausible high values (for the next version at least). I'd hate to see someone upgrade and suddenly have subtle bugs in important computations.

[gtaylor]

We can definitely include warning level log messages at the very least. We could raise exceptions for values that are out-of-this-world high, but I'm not sure I like the idea of doing so for some but not all values that are out of range.

[gtaylor]

I just released 2.1.0, which had a good deal of new stuff in it. With that landing out in the wild, we should start getting some feedback on those changes.

That'll free us up to work on this range re-jiggering, which is going to be pretty disruptive. Perhaps enough to jump to 3.x.

[nlgranger]

The range for a and b in Lab color space is not documented either. Could anyone indicated the ranges here until it gets fixed in the documentation please?

[fnorf]

I came here looking for the same. What are the L, a, b ranges? L seems to be 0 to 100.

[chalmersgit]

I came here with the same question about Lab ranges. I can't find anything on it in the documentation.

According to Wikipidia, L = [0,100], a = [-128,127] and b = [-128,127]
https://en.wikipedia.org/wiki/CIELAB_color_space

But it also says that this depends on the specific implementation, and those above values are usually for 8-bit precision (colormath supports 16-bit).

Using the example:
https://python-colormath.readthedocs.io/en/latest/delta_e.html#example

I tried messing around with various numbers (such as above 100 or below 0 for L, but no warning was shown).

Can anyone let me know what these ranges are?

[earthbound19]

I also wonder.

[escalonn]

This issue affected me too. The values given by colormath agree empirically with the ones at this converter site online, suggesting that this project uses L = [0,100], a = [-128,128] and b = [-128,128].