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.
Exactly this, there's rarely a single "correct" colorspace, you make a choice based on expressive goals and constraints. For example, for gradients you almost never want linear, something like Oklab is indeed much better.
The gradient examples between high-chroma colors of similar luminance are highly misleading in my opinion. In that particular case, linear just happens to do well (and device RGB of course poorly), but in other cases linear is not great. For example, blue to white is especially bad, with hue shifts as well as lightness non-uniformity.
You can experiment with this in the interactive tester in my Oklab review[1].
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 response can be modeled with a pretty simple power law (with a modification in the low range, as the article mentions).
that's all there really is to "gamma correction". it's a hack that exploits this quirk of the human visual system in order to more efficiently allocate bits for encoding different "lightness" values.
all of the confusion and bugs stem from one or more of the systems in the chain that forms the final image, making an incorrect assumption about what the others are doing. it's a bit like coordinate spaces in that regard.
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).
> 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.
> Pixels with RGB values of (128, 128, 128) emit about half as much light as pixels with RGB values of (255, 255, 255).
Technically, this is not always incorrect, if your working color space is linear and 0 is no light. The problem only comes if you hand that same data to routines or surfaces expecting sRGB or another nonlinear color space (or one where 0 is not no light).
Oh, I was just listing the constraints. I'm not directly aware of a color space where value 0 is not no light. It would however mean that even if linear, doubling a value relative to 0 wouldn't necessarily double the amount of light.
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.
Exactly this, there's rarely a single "correct" colorspace, you make a choice based on expressive goals and constraints. For example, for gradients you almost never want linear, something like Oklab is indeed much better.
The gradient examples between high-chroma colors of similar luminance are highly misleading in my opinion. In that particular case, linear just happens to do well (and device RGB of course poorly), but in other cases linear is not great. For example, blue to white is especially bad, with hue shifts as well as lightness non-uniformity.
You can experiment with this in the interactive tester in my Oklab review[1].
[1]: https://raphlinus.github.io/color/2021/01/18/oklab-critique....
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 response can be modeled with a pretty simple power law (with a modification in the low range, as the article mentions).
that's all there really is to "gamma correction". it's a hack that exploits this quirk of the human visual system in order to more efficiently allocate bits for encoding different "lightness" values.
all of the confusion and bugs stem from one or more of the systems in the chain that forms the final image, making an incorrect assumption about what the others are doing. it's a bit like coordinate spaces in that regard.
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).
> 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.
> Pixels with RGB values of (128, 128, 128) emit about half as much light as pixels with RGB values of (255, 255, 255).
Technically, this is not always incorrect, if your working color space is linear and 0 is no light. The problem only comes if you hand that same data to routines or surfaces expecting sRGB or another nonlinear color space (or one where 0 is not no light).
> 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.
Oh, I was just listing the constraints. I'm not directly aware of a color space where value 0 is not no light. It would however mean that even if linear, doubling a value relative to 0 wouldn't necessarily double the amount of light.
Most video color spaces have black at a non-zero code value.
The most common 8-bit YUV format (e.g. in MPEG-2) uses a 16-235 range for valid luma values, so black is at 16 and white is at 235.
The reason for leaving this “headroom” and “footroom” had to do both with digitizing analog signals and avoiding clipping during processing.