I’ve implemented[1] some of these algorithms into @texel/color, a modern JS color library, and it also supports gamut mapping to certain wide gamut color spaces (Display P3, Rec2020, Adobe 1998) rather than just sRGB.
Many popular color libraries (Colorjs.io, culori) attempt to match CSS gamut mapping spec, which is an order of magnitude slower than the approach in Ottosson’s blog post, and also less accurate (CSS gamut mapping may not fall neatly on the gamut boundary).
[1] “Ported” might be a better term as I used a combination of Ottosson’s own JS OKHSL picker, Colorjs.io code, and Coloraide (Python), and adjusted it for performance, more gamuts, and smaller bundle sizes.
It's a good generalization of several techniques. The main thing I want to know is this: how does it look with actual HDR exposures, not the synthetic ones made by "increasing exposure and colorfulness significantly"? We shouldn't choose a method based on how natural the result is, when there is a "stretching" step like this that is not at all natural.
I think any kind of hard clipping approach which takes each pixel independently is going to necessarily create some significant artifacts, though as the examples here make clear, some directions of clipping work better than others. The most important part to preserve for the image to look reasonable is lightness contrast, as when it gets crunched away the image loses visible detail, and the better methods demonstrated in this post manage to save at least some lightness contrast. But all of the methods here end up blowing out / compressing away chroma contrast in some regions where it existed in the original image.
What I'd like to see someone try is do is record the relative lightness and chroma, and (adaptation/context dependent) color relationships from the original image, and then try to preserve those to the extent practical even when bringing out-of-gamut colors into gamut. This will necessarily require modifying in-gamut colors to some extent as well.
This is what good Photoshop users do when they manually adjust the color of an image from one display medium to another, but it involves some amount of careful conscious choice and skill.
OMG, it's Mike Herf! I even linked your "give me a gigabyte" article randomly yesterday to someone complaining of an application using 1gb on his 64gb machine, and remember most of your website off by heart still, in particular the soft shadows / roundrects, all the way to random funny things like SreeD :) Thanks so much for the great articles <3
Those ideas fail for anyone with a modern screen, which goes far beyond sRGB and it's ancient 80 nits brightness. I doubt there's a phone, laptop, PC monitor, or TV made with such low limits now.
Ah so that's why so many movies, shows and even videogames got so dark you can barely see a thing, unless you're viewing them on a relatively recent TV?
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.
(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
> 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.
> 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.
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.
> 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.
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.
> 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.
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 - 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.
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.
Color management is such a shit show on PCs. Most phones these days support a large percentage of DCI-P3 and are configured for it.
But even if you have a monitor that supports DCI-P3 you have to slog through modes, profiles, and blog posts to get it setup.
Should you always have HDR on? Why does SDR content always look "wrong" when HDR is on? Oh, it's because the peak brightness and color saturation blah blah blah.
Gamma 2.0, 2.2, or 2.4?
Now you learn the hard way the "desktop" is not color managed, it's the individual applications.. If they want to be. Maybe they'll use the windows configured profile, maybe not.
What is it about Hacker News that causes posters to just randomly free-associate based on the headline? It's so annoying when I expect to see an in-depth discussion of the article and its contents (about adapting colors between different gamuts), and instead get a random unrelated surface-level rant about color management in operating systems.
Maybe because others interested in color management, including how it works in modern tech, could be attracted to this topic. Then it makes sense to put related things here.
If you don't like this comment, which seems pretty useful to get discussion, perhaps even solving the users issues, then don't engage it.
https://github.com/texel-org/color
Many popular color libraries (Colorjs.io, culori) attempt to match CSS gamut mapping spec, which is an order of magnitude slower than the approach in Ottosson’s blog post, and also less accurate (CSS gamut mapping may not fall neatly on the gamut boundary).
[1] “Ported” might be a better term as I used a combination of Ottosson’s own JS OKHSL picker, Colorjs.io code, and Coloraide (Python), and adjusted it for performance, more gamuts, and smaller bundle sizes.
What I'd like to see someone try is do is record the relative lightness and chroma, and (adaptation/context dependent) color relationships from the original image, and then try to preserve those to the extent practical even when bringing out-of-gamut colors into gamut. This will necessarily require modifying in-gamut colors to some extent as well.
This is what good Photoshop users do when they manually adjust the color of an image from one display medium to another, but it involves some amount of careful conscious choice and skill.
The exposure parameter is usually dynamically chosen by using the average brightness of a previous frame.
[1]: http://filmicworlds.com/blog/filmic-tonemapping-operators/
(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
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.
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?!
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.
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.
I would say yes, but if you're going to argue Björn Ottosson isn't, then no.
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.
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.
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 - 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.
It's by no means a solved problem or field.
But even if you have a monitor that supports DCI-P3 you have to slog through modes, profiles, and blog posts to get it setup.
Should you always have HDR on? Why does SDR content always look "wrong" when HDR is on? Oh, it's because the peak brightness and color saturation blah blah blah.
Gamma 2.0, 2.2, or 2.4?
Now you learn the hard way the "desktop" is not color managed, it's the individual applications.. If they want to be. Maybe they'll use the windows configured profile, maybe not.
On Windows and probably Linux.
MacOS is fully color managed which has its pros and cons since so much of desktop users are on Windows which simply assumes sRGB.
At least P3 and sRGB have the same gamma. People working with video are so confused about uploading rec709 content to youtube with 2.4 gamma.
If you don't like this comment, which seems pretty useful to get discussion, perhaps even solving the users issues, then don't engage it.
Others will find it useful and topical.