3 ms·

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 e

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.

arghwhat 4mo ago
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.
- adrian_b 4mo ago
  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.
  - arghwhat 4mo ago
    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.)

arghwhat 4mo ago

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.

adrian_b 4mo ago
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.
- arghwhat 4mo ago
  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.)