Ranges for color space values

Question

Ranges for color space values

MichaelMauderer opened this issue 10 years ago · 16 comments

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.

Answer 1 · 2014-08-08T14:56:01.000Z

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?

Answer 2 · 2014-08-08T20:53:13.000Z

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.

Answer 3 · 2014-08-08T20:55:11.000Z

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.

Answer 4 · 2014-08-08T21:01:18.000Z

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.

Answer 5 · 2014-08-08T21:54:11.000Z

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.

Answer 6 · 2014-08-11T14:35:05.000Z

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.

Answer 7 · 2015-01-12T05:22:43.000Z

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.

Answer 8 · 2016-03-04T09:59:26.000Z

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?

Answer 9 · 2016-04-10T12:05:25.000Z

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

Answer 10 · 2018-12-28T19:05:46.000Z

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?

Answer 11 · 2019-02-12T01:23:43.000Z

I also wonder.

Answer 12 · 2019-03-10T00:55:36.000Z

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].

Answer 13 · 2019-10-30T12:43:53.000Z

Any updates about the range of LAB values that is expected by the library?

Answer 14 · 2019-10-30T20:21:46.000Z

CIE Lab does not impose limits besides that of the Standard Observer. HDR colours, even though CIE Lab is not well suited to represent them, can go way beyond L=100, and the a and b are only bounded by the Visible Spectrum and will change depending on your current working RGB colourspace as seen in this notebook cell: https://colab.research.google.com/drive/1NRcdXSCshivkwoU2nieCvC3y14fx1X4X#scrollTo=_Ggl1OAuST-B

Answer 15 · 2019-11-04T20:58:26.000Z

I don't think that is the point of this issue, at least it wasn't to me. What we need is documentation on how the range is scaled. I.e. is it 0..1 or 0..100 for the common range of L?

PS: Your notebook requires a log-in.

Answer 16 · 2019-11-04T22:32:55.000Z

There are 10 participants to this issue asking different questions. L* should be 0-100 for practical purposes, a and b, don't really have practical ranges, 0-100 is fine, even though they will go higher.

The notebook should be readable without sign-in, I just tried on 2 different computers without being logged in them. Same is true when using the incognito mode.