facelessuser / coloraide-extras Goto Github PK

http://www.progmat.uaem.mx:8080/artVol2Num2/Articulo3Vol2Num2.pdf
https://compression.ru/download/articles/color_space/ch03.pdf

The above document describes the color spaces and the transform to YIQ. It also covers a ∆Eyiq which we could implement. It seems reasonably easy to implement, so maybe worth doing it.

I can't recall where we came up with our ka kb calculation, but it's not correct. I've figured out what it should be, and we now match locally the ka kb values as dictated by the Hunter Lab spec. We weren't super far off, but still noticably so.

Really just YIQ rotated by 33˚

I was considering implementing RYB, but I'm currently unsure.

1. The most popular algorithm that is used at times is the one laid out by Gosset and Chen, which highly favors more paint-like colors. It doesn't actually have a true black, but kind of a very dark reddish color. It also doesn't contain the entire sRGB spectrum.

   It also isn't reversible. Well, I say isn't reversible, but with some extensive calculations, you could probably reverse it, there just aren't any that are readily available or at least none that cleanly round trip, and even if they did, they do not contain the full sRGB gamut. But I guess they are not attempting to, so 🤷🏻 .

2. Another attempt that can be found is this one, which can only be found using the Wayback machine, though there are implementations using it here and there. This seems to do an okay job and is reversible. I'm not 100% sure about its accuracy, but there is no formal spec, so 🤷🏻.

3. Another attempt is found in some scientific papers. It advertises the approach as being reversible and is similar to option (2.).

   • http://nishitalab.org/user/UEI/publication/Sugita_IWAIT2015.pdf
   • http://nishitalab.org/user/UEI/publication/Sugita_SIG2015.pdf

4. There are numerous other attempts out there that are less common where people take on of the above approaches and try to "fix" them to meet the requirements they think they should meet.

Without an official spec, it makes it hard to really settle. Its main advantage is its ability to match (or more closely match) people's preference for it to mix color in a more paint-like manner. It's a funny little color space. I mocked up option (3.):

I'm not sure if I'm adding this, some other approach, or skipping it altogether.

We've implemented HCT, the space as described in https://material.io/blog/science-of-color-design. The actual implementation that Material uses, does some "clever things" though.

1. Lightness is clamped between 0 - 100. This makes sense as the conversion back to an SDR color space is easy-ish as the L* range of 0 - 100 maps to the J range of CAM16 of 0 - 100, not exactly mind you, but the range is the same. This means you can set your low and high to 0 and 100 and bisect to convert L* back to a suitable J. HDR range is more unpredictable as the J value can exceed the current L*. Limiting to SDR isn't that bad.
2. Chroma gets clamped when it exceeds the sRGB gamut. This means that for every set of hue, chroma, or lightness, Material is recalculating the color and reduces lightness and chroma. We do not as we do not want to limit the color space to sRGB only. We live in the modern world, and modern color spaces are wide gamut. We also don't really have those kinds of hooks. We can do a simple range clamp, but not dynamic at this time. Also, dynamic range clamping that requires us to calculate what the actual max chroma can be for a given lightness and hue would be expensive to do on every set.

What this means is that if you take the color red in HCT, and adjust its tone, the chroma may not be in gamut for sRGB, Display P3, or whatever color space you plan to convert back to. You will not get the same result that the Material library would give you for tones. But there is a way to allow us to get those values.

In order to match what the Material library does, we'd need to reduce chroma in HCT until the color is within some other gamut, in the case of Material, sRGB. This is exactly what we already do with the default gamut mapping algorithm that uses LCh and the CSS proposed algorithm that uses OkLCh.

We should create a variant gamut mapping algorithm that can reduce chroma while in HCT. This would only work for SDR colors and would clip anything above SDR. I'm not sure if it is less expensive to use ∆E 2000 or use CAM16 which is designed for CAM16-based color spaces (which HCT basically is). Either way, doing this would preserve chroma and lightness and allow us to give the same or nearly the same results.

Obviously, this way is expensive to calculate, but so is HCT in general, so I see no issues. People should be able to generate very similar colors and palettes.

https://graphics.stanford.edu/~boulos/papers/orgb_sig.pdf

I actually have a prototype up and running:

What the document doesn't tell you is that you need to mirror the logic for both above and below the yellow/blue axis. I mean, they kind of allude to it, but don't outright say it.

Colorjs.io implemented it. I guess maybe considering it for HDR maybe. They have an implementation, but I'd like to dig up the spec somewhere and take a look (as long as it's not behind a paywall 🙃).

It's technically already implemented, might as well throw it in here as well 🙂. It's a pretty limited color space, but no sense throwing away work.