[rnvannatta]

It's not astonishing to me, because I believe the author is not entirely correct about color being broken.

sRGB color is not the perfect color space, but in general it's better for UI than using linear color, which the author seems to be advocating for. The web is primarily UI. Not only that, but sRGB is the color space of probably 95% or more of devices, and of all low end computer monitors. sRGB is designed to balance perceptual linearity with encoding cost. It's very cheap to encode, and perceptual-enough that you can store a channel in 8 bits with high quality (linear value needs 16 bits to be comparable, and it's still worse unless you use half floats instead of unorm. It's common to go as low as 5 bit sRGB channels for albedo in computer graphcis.)

I am a graphics engineer, I've had a lot of colleagues learn the aphorism "don't do math in linear" once they get first burned.

> Unfortunately, by calling it a "color space", we've misled the vast majority of developers into believing that you can do math on sRGB colors

That belief is an over-correction in my opinion. The examples that the author shows are all about achieving physically correct lighting. The Rubik's cube image blended with 25% white doesn't look physically plausible because it's not being done in linear color.

But the goal with UI is visibility, not physical plausibility. If you want to cover something with a UI element at 50% transparency, you want 50% of the UI and 50% of the background, not a physical model of some transparent medium.

sRGB does however suck for defining gradients, but I think that's more to do with it being RGB. For this what I generally advocate is a luma/chroma model. Other posters have mentioned Oklab which is great, though even plain YCbCr will get you 80% of the way there while being cheap to convert to. You still want to do that in gamma/perceptual space though, not linear. The author didn't show gradients between white and black. Gradients between colors of 2 different luminances look awful in linear^.

However I totally agree with the author on zoom. Web browsers should be doing zoom/image resampling in linear space. Images shouldn't qualitatively change based on their zoom level.

^ https://external-preview.redd.it/voeyOYu6Ds-fLLU7nR4kABmFgUE...

[redox99]

> I am a graphics engineer, I've had a lot of colleagues learn the aphorism "don't do math in linear" once they get first burned.

I'm not sure what you mean by this. I work with game engines and everything is calculated with linear color. Not only anything else would be completely physically inaccurate, it would be unfeasible for modern HDR rendering which supports extreme dynamic ranges with physical units (ie 100000 lux sun).

Maybe you work with mobile devices, where they still haven't fully moved to HDR?

[rnvannatta]

I do cross platform development, I have to keep mobile/console in mind though most of my work in on PC, other people work on mobile/console and tell me when the shaders I write are too slow or break mobile :).

You work with 100,000 lux sun? Damn! We did physical values for sun/moon lighting when I did flight simulator stuff but that painfully required full float rendertargets, which is fine when you can tell Uncle Sam the minspec gpu is a 1080, but unacceptable for console and mobile.

Anyway we do full linear HDR for the 3D scene of course, as it's simulating physical light transport. Though not exact sun/moon values as we want to do half float rendertargets.

The UI does compositing in SDR sRGB.

Some of our textures are tinted with this rather cursed lab model I cooked up for speed, which is gamma encoded srgb linearly transformed so that 'l' = average of rgb and 'chroma' is rgb equally weighted but placed 120 degrees apart in the unit circle. Was designed to make HSV transforms linear operations (ie matrix multiply) and have great performance with acceptable quality with not too many imaginary colors. Nicer color spaces were too expensive, and it works good enough to make the artists like it.