HN Theater @HNTheaterMonth

There is a related video by minute physics about how the RGB color space stores the square root of the brightness of each color channel, because human color perception is roughly logarithmic. Bad color blending is therefore pretty commonplace because it uses the average of square roots instead of the square root of the average of the original brightness values. See: https://www.youtube.com/watch?v=LKnqECcg6Gw

⬐ Asooka

If you blend values in linear space, you'll linearly interpolate from the starting physical intensity to the ending physical intensity. This is a very reasonable default, corresponding to an objective physical measure. Also it makes your gradient appear roughly the same to people with reduced colour perception. Other modes would be useful too, maybe something that goes through HSB colour space, but I suspect designers would find it easier to design their desired gradient in a program of their choosing that then outputs a piecewise linear approximation.

⬐ BeFlatXIII

This is still an issue on iPhones today. When you have a notification icon and start to pull your Home Screen to make it blurry, the border of the red circle gets inexplicably dark. Whatever happened to Apple’s famed attention to detail. This has been the case since the iPhone 6 was new, if not earlier.

Related video: https://www.youtube.com/watch?v=LKnqECcg6Gw

⬐ marcan_42

This needs to be higher up. It's not just about color interpolation - this is a problem with nonlinear color spaces. If you interpolate in a proper linear colorspace, you still get a desaturated color in the middle, but it's the proper brightness and it looks a lot better.

Gamma correction is the bane of computer graphics, and in 2022 there is absolutely no excuse for not using linear colorspaces for all image processing. We have the RAM. 8-bit non-linear colorspaces are a compression technique and should be only used for file formats, not image processing, ever. So many things would look much better and correct if we stopped trying to incorrectly process images in a compressed representation without uncompressing them first.

For comparison: nobody has used A-law or mu-law audio compression ever since digital POTS lines, and we certainly don't process audio in that form, ever. It's the same exact concept as storing pixel values in 8-bits with a gamma function. But somehow we think we can get away with processing images in that domain. I guess it's because if you try to do that with audio, the result is obviously wrong to any human ear, while if you try to do it with images it only looks somewhat wrong, not completely wrong...

>This is in the same category of error as most programmers thinking that sRGB uses a linear light model. They try to do arithmetic like blending or blurring on the raw image data this inevitably does the wrong thing.

Relevant: https://www.youtube.com/watch?v=LKnqECcg6Gw

The classic video for this: https://www.youtube.com/watch?v=LKnqECcg6Gw

Minute physics did a great video on this topic a while back: https://youtu.be/LKnqECcg6Gw

⬐ kzrdude

Did instagram fix it after this video? It should have gotten some attention.

I misunderstood what you mean. Please ignore. On a side note, by colorspace I mainly meant that we can just stick with one with ultra-wide gamut. There are indeed other reasons to have different color spaces.

(Below is my original comment for transparency.)

-------------

Gamma isn't really about CRT; or I should say, they're two different things. The fact CRT has a somewhat physical "gamma" (light intensity varies nonlinearly with the voltage) is likely just a coincidence with the gamma we're talking here.

The reason gamma is used in sRGB is because human eyes are more sensitive to changes in darker area, i.e. if the light intensity changes linearly, it feels more "jumpy" in darker end (which causes perceptible bandings). This is especially an issue with lower color depth. To solve this, we invented gamma space to give darker end more bits/intensity intervals to smooth the perceptive brightness.

>it's not needed to understand the difference between linear and non-linear colorspaces

It absolutely should, since any gamma space would have problem with "averaging", as explained by the GP. Actually, it's so bad that almost all the image editing/representing tasks we have today are doing it wrong (resizing, blurring, mixing..).

This topic has been discussed extensively on Internet, so I'm not going to go into detail too much. A good start point is [1][2].

[1] https://www.youtube.com/watch?v=LKnqECcg6Gw [2] http://blog.johnnovak.net/2016/09/21/what-every-coder-should...

⬐ magicalhippo

> It absolutely should

The GP just pointed out that the CRT link is not needed to motivate the talk about linear vs non-linear.

⬐ fireattack

You're right, I misunderstood (overlooked the CRT part in OP's article.)

If we're on the "watch this YouTube video if you work with colours" train, here's a great explanation of why gradients usually have a dark band in the middle, on the MinutePhysics channel:

https://youtu.be/LKnqECcg6Gw

In short: the RBG values in an image are not actually the intensity of light, but some nonlinear function of intensity. To do a weighted average of two colours you need to first undo that nonlinearity, then do the averaging, then reapply the function. Most software doesn't do that so the colours end up wrong. This also applies to resizing images.

⬐ mrob

Resizing in sRGB has the advantage of obscuring ringing artifacts when enlarging images, because the nonlinearity puts more of them in the highlights than the shadows, where they're less obvious to human vision. You can get perceptually even better results when enlarging by using a sigmoidized colorspace. See:

https://www.imagemagick.org/Usage/filter/nicolas/

For another clear example of the problems of resizing in linear colorspace, see "Catch #3" here:

https://entropymine.com/imageworsener/gamma/

⬐ mantap

Pretty much the first thing you learn in game development (OK not the first thing), is the difference between linear-RGB and sRGB and the need to do lighting calculations in linear space in your shaders. It's crazy that professional graphics software doesn't get this right.

⬐ martin_a

> It's crazy that professional graphics software doesn't get this right.

"Professional graphics software" does what it's supposed to be and sRGB is an inferior standard in most use-cases of that software. Its gamut is simply not large enough, but it's a nice smallest-possible commond ground.

⬐ marcan_42

This isn't a gamut problem, it's a bad coding problem.

"Professional graphics software" (i.e. Photoshop) absolutely does the wrong thing for color blending with the default settings. It's not a problem of being limited to the sRGB color space, it's about the math in use being outright wrong for use on that color space. You need to go into the settings and tick some checkbox to have some hope of it doing the right thing ("Blend RGB colors using gamma"), and even then I bet it only applies to some operations like blending itself, not scaling and other filters.

This is because all non-linear image encoding modes, like sRGB or straight gamma, should be viewed as compression. You don't perform mathematical operations on compressed data. It's like trying to mix together two MP3 files by literally taking the bytes and averaging them out. That's madness and does not work. You need to go into a linear format, like raw PCM, to be able to do that (with the right word size). Same with images: you need to convert from sRGB to linear light to be able to do math on them. But 95% of software, including "pro" software, doesn't do this, it just blindly does math on compressed (gamma encoded) data, and the result is ugly (we're just used to it).

Of couse, with Photoshop you can set your image mode to linear light and then things work fine... but that's not because linear light is required to make this stuff work, it's because Photoshop is broken when not using linear light and doesn't compensate for the encoding.

Meanwhile GIMP, a few versions ago, fixed this whole mess and actually applies blending and filtering in linear light (regardless of what mode your image is using in memory), making its blending and filtering much more pleasant and correct than Photoshop's. So yeah, it may not support CMYK or other "pro" features... but for a good chunk of basic editing in RGB space, you're actually going to get more correct and visually appealing results if you use GIMP than Photoshop.

⬐ marcan_42

It irks me to no end that in 2020 we are still using outright incorrect math for image processing, practically everywhere, with visible consequences (another one: this can also be blamed for a good chunk of the moiré artifacts when resizing images containing patterns, it's not just about subpar filters).

Ironically, Photoshop does this wrong by default, but the open source GIMP does it correctly (in current versions).

Mind you, that's a JPG you are editing, so in the 8 bit sRGB color space. That means manipulations can lead to errors and illusions due to the color space being non-linear and clipped[0].

The original data was likely linear and at a much higher precision. If the source was a 16 bit linear grayscale PNG for example you could be much more assured you're not seeing the effects of JPG compression and things that were actually measured.

EDIT: Found better sources:

16-bit sRGB PNG: https://eventhorizontelescope.org/files/eht/files/20190410-7...

180 MiB original TIFF: https://www.eso.org/public/images/eso1907a/

[0] https://www.youtube.com/watch?v=LKnqECcg6Gw

⬐ localhostdotdev

Thanks a lot for the explanation and the better sources, the TIFF image should probably be a torrent because it's not downloading very fast, the PNG image does give much nicer renders: https://i.imgur.com/zZcD5Na.jpg

This one produces much nicer result [1] - try green to red gradient [2]

[1] https://mycolor.space/gradient?ori=to+right&hex=%2300FF00&he...

[2] https://youtu.be/LKnqECcg6Gw?t=148

The same phenomenon also applies to color blending. In a modern context this phenomenon is especially visible in UI elements that blur the background: Up until recently many UIs did not get the blurring right, resulting in greyish dark spots between different colors. I think CSS blurring in most browsers still gets it wrong.

https://www.youtube.com/watch?v=LKnqECcg6Gw (Computer Color is Broken, MinutePhysics)

⬐ zokier

Well color blending is whole another can of worms; there are no easy answers there. Mixing RGB values even in linear space does not yield always "correct" results. More problematic, I'm not sure if there is even well-defined correct result for generalized color mixing/blending.

⬐ mark-r

Even something as simple as a proper gradient between two colors is surprisingly difficult. I think I finally cracked that one though: https://stackoverflow.com/a/49321304/5987

Color mixing is easy if you're mixing light, just add together the linear intensities. Color mixing of pigments is a different order of complexity, because you have to consider that pigments are both transmissive and reflective and there are other effects like dot gain and spectral lines to consider.

⬐ notthemessiah

tl;dr: Humans perceive color logarithmically, and RGB channel values have only 8 bits of information, so computers take the square root of the brightness to efficiently store it, but most blurring algorithms take a naive average of RGB values resulting in blurring that is darker than it should be.

Good reminder about these persisting blending issues in the linear interpretation of RGB values, which was well explained to non-coders as well here in a quite popular MinutePhysics video: https://www.youtube.com/watch?v=LKnqECcg6Gw

As others commented the gamma scaling issues seem even more relevant.

Just please, don't use RGB color space for generating gradients. In fact, it's ill fitted for most operations concerning the perception of colors as is.

chroma.js: https://vis4.net/blog/posts/mastering-multi-hued-color-scale...

D3: https://bl.ocks.org/mbostock/3014589

Interesting excursion: historically the default viewing gammas seem to have lowered, because broadcasting defaulted to dimly lit rooms, while today's ubiquitous displays are usually in brighter environments.

https://www.w3.org/Graphics/Color/sRGB.html

I'd already seen most of this in a video (courtesy of Henry, aka MinutePhysics, https://m.youtube.com/watch?v=LKnqECcg6Gw), but it was nice to see a programmer-oriented explanation, nonetheless.

I'm calling it pedantic, because as far as I can see nobody cares outside of people doing movie VFX and the like, where it is actually really really important that you get it right. Your GUI for example doesn't care - elements are blended assuming a linear colourspace, which means that all font rendering is just slightly off. Even Apple don't care to make their blur effects correct - see https://www.youtube.com/watch?v=LKnqECcg6Gw . Even photoshop doesn't do it correctly by default. Almost everybody is perfectly happy treating the values as linear colour intensity.

The bottom line is that sRGB is hideously hard to work in. You really want to only use it for storage and only if you really must. It's an optimisation to allow you better range on the low end, at the expense of the high intensity end, to match human colour vision. However, that means using 48bit RGB and that's not a price everyone wants to pay. People who do professional graphics work simply use 32bit floats per colour channel - 128bit RGBA, or even 192bit RGBRaGaBa (separate alpha for each channel) and have workstations with 32 or 64GB of RAM. However, your normal everyday GUI application needs to run on a phone with about 1GB of RAM. Or going back farther, it has to run on an Intel 486 with 16MB of RAM. That kind of explains where the culture of "just treat it as linear, it's not that wrong" came from :) .

⬐ pavel_lishin

Your link points to the middle of the video.