Live data from Hacker News

What every coder should know about gamma (2016)

blog.johnnovak.net

11–20 of 50 posts

Re: What every coder should know about gamma (2016)

#11

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 resp…

general rule of thumb is that you never want gamma-corrected values if you intend to be doing any sort of math with them. the only exception is when you want to match the behavior of softwares that actually do all the math with pixel values in sRGB space (I think that's what photoshop does but don't quote me on that).

Re: What every coder should know about gamma (2016)

#12
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.

Re: What every coder should know about gamma (2016)

#13
post #6

> 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.

Probably because it’s displayed on a white background. A gray or black background would have shown the difference more clearly.

Re: What every coder should know about gamma (2016)

#15
post #9
post #3

Earlier quoted context omitted.

> or one where 0 is not no light Oh, interesting. What's an example of this? Some sort of log space?

I would think the color spaces of most displays have that, don’t they? The bevel of a black iPhone is darker than its screen, even when powered off. Similarly, switched off CRT displays aren’t truly black.

[deleted]

Re: What every coder should know about gamma (2016)

#16
post #14

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

A power function seamlessly maps 0 to 0 and 1 to 1, easy for black to white.

An exponential/log function requires arbitrary clamping or offsets because you cannot represent pure black, 0, on a pure log scale without hitting negative infinity.

Basically, it fits better, aside from a good map of human perception

Re: What every coder should know about gamma (2016)

#18
post #7

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.

Depends. Many times a linear colorspace is exactly what you want.

Re: What every coder should know about gamma (2016)

#19
This article contains some pretty major errors, which is kind of surprising to see!

>The transformation used to represent the physically linear intensity data either generated synthetically via an algorithm or captured by a linear device (such as a CMOS of a digital camera or a scanner) with the discrete values of the perceptually linear scale is called gamma encoding.

This isn't super correct, and it underscores the biggest issue in this article:

sRGB (and its gamma encoding function) has absolutely nothing to do with perceptual linearity. sRGB is not perceptually linear! The original gamma encoding as far as I'm aware was made to compensate for the nonlinear transfer function of CRTs back in ye olde days. Its true that human vision is nonlinear, but sRGB is not a particularly good match to the perceptual linearity of human vision. Its a really common error to make, and leads to people wondering why we can't use sRGB to blend in if the reason why it was invented is because its perceptually linear

The article goes to compound on this mistake, which is why this is such a problematic misconception:

> Interestingly, Photoshop antialiases text using γ=1.42 by default, and this indeed seems to yield the best looking results (middle image). The reason for this is that most fonts have been designed for gamma-incorrect font rasterizers, hence if you use linear space (correctly), then the fonts will look thinner than they should.

This is where the mistakes start to add up

Consider what you're trying to achieve during antialiasing: when rasterising a line, lets say we discover that a pixel is only 40% covered and want to darken it. This means that we want our pixel's brightness to decrease by 40% to a human being. We don't want to emit 40% less light, because that's not what antialiasing is trying to achieve!

Both sRGB and linear colour are the wrong colour spaces to use. You want to blend in a perceptually linear colourspace, and photoshop's 1.42 gamma exponent probably maps better to human vision than 2.2 or 1.0 while being cheaper than a LUV conversion

>The standard gamma (γ) value to use in computer display systems is 2.2. The main reason for this is because a gamma of 2.2 approximately matches the power law sensitivity of human vision

The gamma transfer functions are also wrong. Its worth getting hung up on because it actually causes nontrivial errors, especially in the age of hardware accelerated sRGB conversions where doing it correctly is free

Re: What every coder should know about gamma (2016)

#20
> [...] the only reason to use gamma encoding for digital images is because it allows us to store images more efficiently on a limited bit-length [...]

It's interesting how this part of the trade-off changes when using float16 for color components (as is common when HDR is involved) rather uint8.

Good timing that Safari 27 adds support for srgb-linear and display-p3-linear color spaces.

Post reply on HN