[HN Gopher] sRGB Gamut Clipping (2021)
___________________________________________________________________
sRGB Gamut Clipping (2021)
Author : Brajeshwar
Score : 70 points
Date : 2024-09-04 15:28 UTC (7 hours ago)
(HTM) web link (bottosson.github.io)
(TXT) w3m dump (bottosson.github.io)
| Rapzid wrote:
| 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.
| Jasper_ wrote:
| 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.
| Rapzid wrote:
| Don't let me stop you, no shortage of top-level comments.
| SideQuark wrote:
| 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.
|
| Others will find it useful and topical.
| jacobolus wrote:
| To be fair, it's pretty hard to perform or judge reasonable
| gamut clipping/adaptation if you don't have a well
| characterized display.
| pier25 wrote:
| > _Now you learn the hard way the "desktop" is not color
| managed_
|
| 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.
| kuschku wrote:
| At least KDE nowadays supports color management, which is how
| the steamdeck implements HDR.
| herf wrote:
| 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.
| pixelpoet wrote:
| 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
| jacobolus wrote:
| 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.
| cmovq wrote:
| In games it's common to have a tone mapping step [1] to map the
| HDR image to sRGB while maintaining pleasant colors.
|
| The exposure parameter is usually dynamically chosen by using the
| average brightness of a previous frame.
|
| [1]: http://filmicworlds.com/blog/filmic-tonemapping-operators/
| SideQuark wrote:
| 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.
| TeMPOraL wrote:
| 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?
| SideQuark wrote:
| That and overall poor color management practices. Most
| likely this will all get smoothed out as specs, knowledge,
| and ecosystems mature
| suzumer wrote:
| 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 wrote:
| 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
| SideQuark wrote:
| 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.
| jacobolus wrote:
| > _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.
| itishappy wrote:
| > 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 wrote:
| 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__ wrote:
| > 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 wrote:
| 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.
| itishappy wrote:
| > Are you a color scientist?!
|
| I would say yes, but if you're going to argue Bjorn
| Ottosson isn't, then no.
| mattdesl wrote:
| 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.
|
| 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.
___________________________________________________________________
(page generated 2024-09-04 23:00 UTC)