[suzumer]

I haven't gone through the whole article, but it seems to be conflating chroma and saturation. If lightness of a color is scaled by a factor c, then chroma needs to be scaled by that same factor, or saturation won't be preserved, and the color will appear more vibrant then it should.

[refulgentis]

Well, no, it's not straight up scaling.

(Not directed at you) Color science is a real field, CAM16 addresses all of the ideas and complaints that anyone could have, and yet, because it's 400 lines of code, we are robbed of principled, grounded, color. Instead people reach for the grab bag of simple algorithmic tricks

[itishappy]

> CAM16 addresses all of the ideas and complaints that anyone could have...

Here's some complaints that better color scientists than me have had about CAM16:

> Bad numerical behavior, it is not scale invariant and blending does not behave well because of its compression of chroma. Hue uniformity is decent, but other models predict it more accurately.

https://bottosson.github.io/posts/oklab/

Here's more:

> Although CAM16-UCS offers good overall perceptual uniformity it does not preserve hue linearity, particularly in the blue hue region, and is computationally expensive compared with almost all other available models. In addition, none of the above mentioned color spaces were explicitly developed for high dynamic range applications.

https://opg.optica.org/oe/fulltext.cfm?uri=oe-25-13-15131

Color is hard.

[refulgentis]

You've discovered my White Whale.

It spells out a CAM16 approximation via 2 matmuls, and you are using as an example of how CAM16 could be improved.

The article, and Oklab, is not by a color scientist. He is/was a video game developer taking some time between jobs to do something on a lark.

He makes several category errors in that article, such as swapping in "CAM16-UCS" for "CAM16", and most importantly, he blends polar opposite hues in cartesian coordinates (blue and yellow), and uses the fact this ends up in the center (gray) as the core evidence for not liking CAM16 so much.

> better color scientists than me

Are you a color scientist?!

[Sesse__]

> The article, and Oklab, is not by a color scientist. He is/was a video game developer taking some time between jobs to do something on a lark.

As a non-color scientist sometimes dealing with color, it would probably be nice if the color scientists came out sometimes and wrote articles that as readable as what Ottosson produces. You can say CIECAM16 is the solution as much you want, but just looking at the CIECAM02 page on Wikipedia makes my brain hurt (how do I use any of this for anything? The correlate for chroma is t^0.9 sqrt(1/100) J (1.64 - 0.29^n)^0.73, where J comes from some Chtulhu formula?). It's hard enough to try to explain gamma to people writing image scaling code, there's no way ordinary developers can understand all of this until it becomes more easily available somehow. :-) Oklab, OTOH, I can actually relate to and understand, so guess which one I'd pick.

[suzumer]

Mark Fairchild, one of the authors of CIECAM02, recently published a paper that heavily simplified that equation: https://markfairchild.org/PDFs/PAP45.pdf

If the link doesn't work, the paper is called: Brightness, lightness, colorfulness, and chroma in CIECAM02 and CAM16.

Also, if you want a readable introduction to color science, you can check out his book Color Appearance Models.

[jacobolus]

Thanks for the link! To anyone looking for a summary: Fairchild's paper explains the origin and nature of various arbitrary and empirically/theoretically unjustified and computationally expensive complications of CAM16 (from Hunt's models from the 80s–90s via CIECAM02 and CIECAM97s) which were apparently originated as duct-taped workarounds that are no longer relevant but were kept based on inertia. And it proposes alternatives which match empirical data better.

Mark Fairchild is great in general, and anyone wanting to learn about color science should go skim through his book and papers: he does the serious empirical work needed to justify his conclusions, and writes clearly. It was nice to drop by his office and shake his hand a few years ago.

In an email a couple years ago he explained that he had nothing to do with CAM16 specifically because the CIE wouldn't let him on their committees anymore (even as a volunteer advisor) without signing some kind of IP release giving them exclusive rights to any ideas discussed.

[octacat]

J is the lightness channel and similar to other lightness formulas in other colorspaces for SDR lightness. I.e. usually idea is to take a lightness formula, and just arrange hues/chromas for each value of J.

Yea, Jab instead of Lab in ciecam haha. Btw, ciecam is pretty bad predicting highlights, it was designed for SDR to begin with. Lightness formula in ICtCp is more interesting (and here it is "I").

But yea, difficulty of ciecam02 comes from the fact that it tries to work for different conditions, i.e. if usual colorspaces just need to worry about how everything works with one color temperature (usually 5500 or 6500K), ciecam02 tries to predict how colorspace would look like for different tempratures and for different viewing conditions (viewing conditions do not contribute much difference though).

Oh, and of course, ciecam02 defines 3 colorspaces, because it is impossible to arrange ab channels in euclidean space :) TLDR, there is metric de2000 to compare 2 colors, but this metric defines non-euclidean space. While any colorspace tries to bend that metric to fit into euclidean space. So, we have a lot of spaces that try it with different degree of success.

Cam02 is over-engeneered, but it is pretty easy to use, if you just care about cam-ucs colorspace (one of these three) and standard viewing conditions.

If you kinda just wanna see difference between colorspaces, good papers comparing colorspaces have actually nice visual graphs. If you want to compare them for color editing, I've implemented a colorgrading plugin for photoshop: colorplane (ah, kinda ad ;)).

From most interesting spaces, I would say colorspaces, optimized using machine learning are pretty interesting (papers from 2023/2024). But yeah, this means they work using tensorflow, so you need to use batching, when converting from/to RGB. But yeah, what they did, they took CieLab (yes, that old one), used L from it and stretched AB channels to better fit de2000 metric prediction. Basically, like many other colorspaces are designed, just machine learning is cool to minimise errors in half-automatic way. Heh, someday I should write a looong comparison of colorspaces in an easy language with examples :)

[itishappy]

> Are you a color scientist?!

I would say yes, but if you're going to argue Björn Ottosson isn't, then no.

[refulgentis]

They called me a color scientist at work and I didn't like it much :( until I started doing it. But I don't think I could again.

I was just asking because I'm used to engineers mistaking the oklab blog for color science, but not color scientists. It's legit nothing you want to rely on, at all, clearest example I can give is the blue to yellow gradient having grey in the middle. It's a mind numbing feeling to have someone tell you that someone saying that, then making a color space "fixing" this, is something to read up on.

[jacobolus]

> CAM16 addresses all of the ideas and complaints that anyone could have

A statement this emphatic and absolute can't possibly be true.

Here's a concrete complaint that I have with CAM16: the unique hues and hue spacing it defines for its concept of hue quadrature and hue composition are nontrivially different than the ones in CIECAM02 or CIECAM97s, but those changes are not justified or explained anywhere, because the change was just an accidental oversight. (The previous models' unique hues were chosen carefully based on psychometric data.)

> because it's 400 lines of code, we are robbed

It's not really surprising that people reach for math which is computationally cheap when they need to do something to every pixel which appears in a large video file or is sent to a computer's display.

[8n4vidtmkvmk]

Then give us both. fast_decent_colormap() and slow_better_colormap() and hide away all your fancy maths.

Give me some images and the kinds of transforms each color space is good at, and let me pick one, already implemented in a library in a couple different languages.

What's the best color space if I want pretty gradients between 2 arbitrary colors?

What's the best color space if want 16 maximally perceptually unique colors?

What color space do I use for a heat map image?

What color space do I use if I want to pick k-means colors from an image or down sample an image to 6 colors?

[refulgentis]

This is a category error question and that's what makes these hard to answer. There's very good & clear answers, but you see the reaction to them in this thread. I wish I could share the tools I made these problems visible at BigCo, and thus easy to resolve, but alas.

TL;DR: A color space just tells you where a color is in relation to others. From there, focus on your domain (eg. mine was "~all software", 2D phone apps) and apply. Ex. the gentleman above talking about specularity and CAM16 is wildly off-topic for my use case, but, might be crucially important for 3D (idk). In general, it's bizarre to be using something besides CAM16, and if that's hard to wrap your mind around, fall back to Lab*, (HCL) and make sure you're accounting for gamut mapping if you're changing one of the components.

[8n4vidtmkvmk]

Is it a category error? I can see that if I blend linearly in one color space vs another space I'll get a different result. And if a try to cluster colors using one color space vs another I'll get different results. Surely the color space is relevant and my questions aren't completely non-sensical?

CAM16 can't be the best answer to all of them, can it? It's possible but I'd think some color spaces are better suited for some tasks than others.

Which CAM16 are we even talking about? A quick Google reveals CAM16 UCS, SCD and LCD.

CIELAB I've heard good things about but then OKLAB became all the rage and now I don't know what's better.

[SideQuark]

While CAM16 helps, it doesn't address all the ideas and complaints. The field that brought you CAM 16 has many more advanced models to address shortcomings, and there's papers published nearly daily addressing flaws in those models.

It's by no means a solved problem or field.

[creata]

Like most people, I think, I'm just using Oklab for interpolation between colors on my screen, and in color pickers that feel a little easier to use than the usual HSV one. As you mentioned, it's easy to throw in anywhere.

Is there a reason why it would be more appropriate to use CAM16 for those use cases?

I think an even simpler approximation than Oklab might be appropriate for these cases - it'd be nice if the sRGB gamut was convex in Oklab, or at least didn't have that slice cut out of it in the blue region.