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
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 perceptual space can help.
>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!
> 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).
*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.
>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
> 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.
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.
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.
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.
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.)
>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