Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What every coder should know about gamma (2016)

blog.johnnovak.net

Post reply on HN
Print view View original

41–50 of 50 posts

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

#41

Post by arghwhat »

adrian_b wrote: post #39
arghwhat wrote: post #38

Earlier quoted context omitted.

Just a nit: Post-CRTs, there is no longer a "standard gamma curve", but many different transfer functions and many errors stem from misunderstanding this. Even within "SDR"/"sRGB", many mistakes crop up from people erroneously mixing content encoded with the piecewise sRGB transfer function with content encoded according to a plain gamma 2.2 transfer function. And this is before we are getting into e.g., incorrect bl…

That is why I said "standard gamma curves", and not "standard gamma curve", as each standard specifies a slightly different curve, for various reasons. Such differences in standards already existed in analog television, because, depending on how they were made, the CRTs also had slightly different transfer curves from grid voltage (where the video signal was applied) to anode current (which is proportional with the l…

Grid voltage had no real impact, but the field rate of early monochrome broadcasts were locked to mains frequency, hence regional differences in frame rate.

NTSC was gamma 2.2, and PAL/SECAM was gamma 2.8, which was indeed initially partly caused by local manufacturing differences before international brands took over, but neither "standard" was really followed by anyone. In the end, concluding that it was all a total mess, we split the difference in the early 90's by formally defining both to gamma 2.4 in BT.709. As such, their curves are the same.

(Manufacturing derivation was outside the scope, as manufacturers did whatever was convenient or sold sets, going all over the place with their response curves regardless of what region they were from or targeted. This remains true today - see any new TVs standard color response.)

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

#42

Post by 20k »

penteract wrote: post #40
20k wrote: post #31

Earlier quoted context omitted.

>When antialiasing, I think you do want to model light: a fully black object occluding 40% of a pixel should cause it to emit 40% less light. Linear intensity representations of colour should therefore be used. The antialiasing value you get represents how much the pixel is covered by the glyph in question, and directly represents a desired change in perceptual brightness. There's no physical underlying lighting proc…

> There's no physical underlying lighting process, so it doesn't make sense to use physical light units. I disagree with you here. Text rendering specifically is incredibly complicated, but for antialiasing in other contexts, the problem can be seen as trying to approximate what would be seen if the display had higher resolution and the viewer has blurry eyesight. In this model, a linear color space makes sense - if…

>if 60% of the pixels within a region on a higher dpi display would be lit, then that is best approximated* by a single pixel emitting the same number of photons as those pixels would (which is 60% as many photons as there should be in the situation where all pixels on the higher dpi display would be lit).

This assumes that the output from the coverage process represents a semi transparent line with a light shining through it, which isn't what font rendering outputs. It outputs a perceptual brightness, because if a cell is 50% covered, we want it to be 50% dark. Not emitting 50% of the photons

>Whatever color space you do your blending in, 40% black onto white should look the same as 60% white onto black.

What you want is 40% black onto white to have a similar difference in intensity as 40% white onto black, otherwise your darkmode font will look significantly different at the same intensity as your lightmode font. This is why it doesn't make sense to do it in a linear colourspace

Note that the wikipedia article is wrong, given that photoshop uses a nontrivial gamma exponent

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

#43

Post by Const-me »

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

Can’t reproduce. Tested on two monitors on my desk, designer-targeted Benq and cheap laptop. On the Benq, darkest 3 segments are indistinguishable, the 4-th one barely distinguishable. On the laptop, darkest 4 segments are indistinguishable, the 5-th barely distinguishable. However, on the “emitted light intensity” all bars are clearly visible.

> Image resizing

“Unsurprisingly, C gives the correct result” On my computers B very similar to A, just a tiny bit darker. While the “correct” C result is a lot lighter than A.

Also from the same section:

> B the result of resizing the pattern by 50% directly in sRGB-space (using bicubic interpolation)

Bicubic interpolation is only applicable when enraging images; downsampling is very different problem from interpolation.

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

#44

Post by penteract »

20k wrote: post #42
penteract wrote: post #40

Earlier quoted context omitted.

> There's no physical underlying lighting process, so it doesn't make sense to use physical light units. I disagree with you here. Text rendering specifically is incredibly complicated, but for antialiasing in other contexts, the problem can be seen as trying to approximate what would be seen if the display had higher resolution and the viewer has blurry eyesight. In this model, a linear color space makes sense - if…

>if 60% of the pixels within a region on a higher dpi display would be lit, then that is best approximated* by a single pixel emitting the same number of photons as those pixels would (which is 60% as many photons as there should be in the situation where all pixels on the higher dpi display would be lit). This assumes that the output from the coverage process represents a semi transparent line with a light shining t…

> What you want is 40% black onto white to have a similar difference in intensity as 40% white onto black, otherwise your darkmode font will look significantly different at the same intensity as your lightmode font. This is why it doesn't make sense to do it in a linear colourspace

Thanks for putting this clearly. I had not given this argument enough thought and respect previously. Would you agree if I said this is about maximizing the amount of useful information given to the reader (even if it deviates from approximating a printed page) and a perceptual colour space is the way to measure that information?

I should mention that I can find plenty of resources that suggest you should use a different font for dark-on-light vs light-on-dark (although I'm aware I'm not a good judge of the quality of said resources). This is not necessarily opposed to your point, since your reasoning can be extended to conclude that identically shaped printed text subject to blurring in linear colour space would be perceived differently depending on whether it's light-on-dark or dark-on-light (including when it's naturally blurred due to imperfect eyesight).

> Note that the Wikipedia article is wrong, given that photoshop uses a nontrivial gamma exponent

If we set text rendering aside, and consider something like games which prioritize photorealism rather than legibility, would you agree that linear colour space is the sensible one to do antialiasing in? This is for essentially the same reason you should do image resizing in linear color space, for which Wikipedia's citation [6] provides a convincing demonstration.

[6] https://www.ericbrasseur.org/gamma.html?i=1

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

#45

Post by nomel »

LoganDark wrote: post #36
account42 wrote: post #35

Earlier quoted context omitted.

Doesn't really matter if the light is emitted or reflected, it still affects your perception.

Perceptual color accuracy is usually handled at the display manager or operating system level; wherever monitor color calibration is applied. You don't usually have to worry about it, unless your target audience puts you especially in charge of it. (Certain applications on Windows and Linux do this for color-grading workflows.)

> unless your target audience puts you especially in charge of it.

In which case the color space you would work with would have "no emission" that's not at 0, accurately answering the original question. I don't expect a tech forum like this to be limited to the application layer.

After doing a bit of digging, ambient light correction, on higher end monitors (like MacBooks) do seem to mix ambient reflectance in! Neat!

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

#46

Post by HappMacDonald »

Dwedit wrote: post #29
evilturnip wrote: post #25

I work on the open-sourced Jedi Academy game engine, which is based on id tech 3. It has special logic to specifically adjust the gamma of the physical monitor during launch, then restore it upon exit. This is why when these older games crashed on your PC, the monitor would look all washed out due to the manual gamma adjustments the game made that didn't get restored.

This kind of thing is why you need a separate watchdog process that gets notified when the other process terminates.

Erlang/Elixir coder identified :)

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

#47

Post by LoganDark »

nomel wrote: post #45
LoganDark wrote: post #36

Earlier quoted context omitted.

Perceptual color accuracy is usually handled at the display manager or operating system level; wherever monitor color calibration is applied. You don't usually have to worry about it, unless your target audience puts you especially in charge of it. (Certain applications on Windows and Linux do this for color-grading workflows.)

> unless your target audience puts you especially in charge of it. In which case the color space you would work with would have "no emission" that's not at 0, accurately answering the original question. I don't expect a tech forum like this to be limited to the application layer. After doing a bit of digging, ambient light correction, on higher end monitors (like MacBooks) do seem to mix ambient reflectance in! Neat!

> In which case the color space you would work with would have "no emission" that's not at 0, accurately answering the original question. I don't expect a tech forum like this to be limited to the application layer.

That depends on whether your idea of pixels is as emitted by the application or as transmitted to the display.

Since the latter is hardly relevant to the majority of cases, I left it out. Maybe on simplistic platforms like Windows you'd have to care. But if you're a run-of-the-mill application developer making a game or web app or something... in no world do you have awareness of nor control over what's transmitted to the display.

So bringing up analog signals or OS-level color management as a 'gotcha' is being unnecessarily pedantic.

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

#49

Post by nitwit005 »

dheera wrote: 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.

I felt the same, and I saw multiple people did back in 2016 as well: https://news.ycombinator.com/item?id=12554887

Edit: Looking at the raw pixel data, the cells seem to be (0, 0, 0), (0, 0, 0), (1, 1, 1), (8, 8, 8), so there is indeed no practical difference between the first three.

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

#50

Post by tobr »

account42 wrote: post #33
tobr wrote: post #13

Earlier quoted context omitted.

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

No it's because #000 isn't actually black on a physical monitor, especially a backlit one so you loose contrast which affects the lower end of the range more than it does the brighter colors.

I disagree. If the monitor is mostly black (as close as it can be reproduced), shades of near-black gray are easy to distinguish, while shades of near-white gray blend together.
Post reply on HN