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

31–40 of 50 posts

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

#31

Post by 20k »

vektorsigma wrote: post #24
20k wrote: post #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…

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. When doing a smooth fade-to-black in video, you may want to gradually decrease the amount of emitted light from the whole frame in a way that is smooth to a human. Here I think you should consider how a percept…

>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 process, so it doesn't make sense to use physical light units

Blending in linear RGB models different strength lights being mixed together. This is why you do want to blend images together in linear RGB, but not fonts - because its not an underlying light based transport process

To take a direct example: Imagine two cases

1. We blend a white font on a black background

2. We blend a black font on a white background

Using perceptual blending, the antialiasing will be exactly the same efficacy in both cases. Using blending in linear space, these two test cases will look very different and render incorrectly!

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

#32

Post by adrian_b »

20k wrote: post #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…

As you, say the original purpose of gamma was strictly to compensate the non-linearity of CRTs.

The reason why gamma has been preserved in digital television even after CRTs have become obsolete is that it happens to perform a dynamic range compression that allows the use of 8 bits for luminance or for color components without making too visible the steps between adjacent color values.

If you want to encode the color components linearly, you need to use more than 8 bits, preferably the FP16 format, which was originally introduced in GPUs especially for this purpose.

So today the only purpose of gamma is as a method of data size compression that is specific to images, by allowing the reduction of the number of bits per pixel, while keeping acceptable the degradation of the image quality.

It is probable that the standard gamma curves are not optimal for data compression, but the slight improvements in image quality that could have been attained with other curves are not worth the complications that would have been created by abandoning the compatibility with legacy recordings.

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

#33

Post by account42 »

tobr wrote: post #13
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.

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.

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

#35

Post by account42 »

LoganDark wrote: post #30
Someone wrote: post #9

Earlier quoted context omitted.

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.

That isn't light emission , though.

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

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

#36

Post by LoganDark »

account42 wrote: post #35
LoganDark wrote: post #30

Earlier quoted context omitted.

That isn't light emission , though.

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

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

#37

Post by brookst »

20k wrote: post #31
vektorsigma wrote: post #24

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. When doing a smooth fade-to-black in video, you may want to gradually decrease the amount of emitted light from the whole frame in a way that is smooth to a human. Here I think you should consider how a percept…

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

Also consider blending different levels of grey. Blending 20% to 0% versus 40% to 60% versus 80% to 100% will look wildly different.

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

#38

Post by arghwhat »

adrian_b wrote: post #32
20k wrote: post #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…

As you, say the original purpose of gamma was strictly to compensate the non-linearity of CRTs. The reason why gamma has been preserved in digital television even after CRTs have become obsolete is that it happens to perform a dynamic range compression that allows the use of 8 bits for luminance or for color components without making too visible the steps between adjacent color values. If you want to encode the color…

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 blending spaces or mismatched primaries.

But yes, it is purely a matter of compression, with many options for exactly what dynamic range you need and how you want your content defined (e.g., sRGB, gamma2.2, scRGB, HLG, PQ, ...), with linear light primarily reserved as an intermediate space for color conversions and blending - something your display server and any software working with arbitrary color spaces will be using.

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

#39

Post by adrian_b »

arghwhat wrote: post #38
adrian_b wrote: post #32

Earlier quoted context omitted.

As you, say the original purpose of gamma was strictly to compensate the non-linearity of CRTs. The reason why gamma has been preserved in digital television even after CRTs have become obsolete is that it happens to perform a dynamic range compression that allows the use of 8 bits for luminance or for color components without making too visible the steps between adjacent color values. If you want to encode the color…

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 luminance of the pixel component), and the regional TV standards accounted for the dominant manufacturers of the CRTs sold in that region.

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

#40

Post by penteract »

20k wrote: post #31
vektorsigma wrote: post #24

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. When doing a smooth fade-to-black in video, you may want to gradually decrease the amount of emitted light from the whole frame in a way that is smooth to a human. Here I think you should consider how a percept…

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

See https://en.wikipedia.org/wiki/Spatial_anti-aliasing#Anti-ali... .

*there are better filters if you're looking at more than one pixel at once

> Using perceptual blending, the antialiasing will be exactly the same efficacy in both cases. Using blending in linear space, these two test cases will look very different and render incorrectly!

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

Post reply on HN