What every coder should know about Gamma Correction

ICC profiles present a similar problem and remarkably Instagram, ostensibly a photo-sharing web-site, does not respect them when scaling images (or at least it didn't a few years ago when I started posting photos to it from my PC); when I uploaded full-resolution SLR-resolution originals the skin-tones would get all screwed up. If I exported at the final resolution, even with the same ICC profile, they were fine.

for lot of image processing linearizing srgb is only half-way measure, and you might want to reach for a better colorspace altogether. cielab is obvious example, or maybe oklab/jzazbz/xyb/something else.

I wonder why we use something polynomial-based instead of something exponential-based like the decibel scale?

> On which image does the gradation appear more even? It’s the second one!

I felt the first one looked more even. On the first I could tell the difference between every two adjacent bars. On the second one I couldn't tell any difference between the first 4-5 bars.

there isn't much that is "arcane" about gamma correction itself (as in, the math itself is really simple).

at the fundamental level, if a surface is illuminated with one lightbulb and we add another light bulb, the difference is exteremely noticeable to the human eye. if we add one more lightbulb to a surface that is already illuminated by a hundred light bulbs, there will be no perceptible difference. the exact response can be modeled with a pretty simple power law (with a modification in the low range, as the article mentions).

that's all there really is to "gamma correction". it's a hack that exploits this quirk of the human visual system in order to more efficiently allocate bits for encoding different "lightness" values.

all of the confusion and bugs stem from one or more of the systems in the chain that forms the final image, making an incorrect assumption about what the others are doing. it's a bit like coordinate spaces in that regard.

> Pixels with RGB values of (128, 128, 128) emit about half as much light as pixels with RGB values of (255, 255, 255).

Technically, this is not always incorrect, if your working color space is linear and 0 is no light. The problem only comes if you hand that same data to routines or surfaces expecting sRGB or another nonlinear color space (or one where 0 is not no light).