Hacker News Reader

> If graphics system coders in the late 1980-ies and early 1990-ies would have bothered to just think [...] the APIs we're using today would expect colors in linear contact color space.

Nope. As you point out, if you use 8-bit integers to represent colors, you absolutely want to use a gamma-encoded color space. Otherwise you’re wasting most of your bits and your images will look like crap. In the 80s/90s, extra bits per pixel were expensive.

Linear encoding only starts to be reasonable with 12+ bit integers or a floating point representation.

> The most robust choice would have been CIE1931

RGB or XYZ doesn’t make any difference to “robustness”, if we’re just adding colors together. These are just linear transformations of each other.

> (the L component is linear as well) [...] from a image processing and manipulation point of view doing linear operations also on the ab components of Lab will actually yield the "expected" results.

This is not correct.

It is true that the errors you get from taking affine combinations of colors in CIELAB space are not quite as outrageous as the errors you get from doing the same in gamma-encoded RGB space.

> RGB or XYZ doesn’t make any difference to “robustness”, if we’re just adding colors together. These are just linear transformations of each other.

What I meant was, that there are so many different RGB color spaces, that just converting to "RGB" is not enough. One picture may have been encoded in Adobe RGB, another one in sRGB. And even after linearization they're not exactly the same. Yes, one can certainly bring them into a common RGB. But then you can as well transform into a well defined contact color space like XYZ.

> It is true that the errors you get from taking affine combinations of colors in CIELAB space are not quite as outrageous as the errors you get from doing the same in gamma-encoded RGB space.

That's what I meant with "expected" results. In general Lab is a very convenient to work with color space. I was wrong though about L being linear. It's nonlinear as well, but not in such a nasty way as sRGB is.

Care to elaborate on the technical inaccuracies you spotted in the article? I would like to correct them, that's why I'm asking.

The explanation of why there this kind of gamma mapping was introduced in the first place is inaccurate. An often cited explanation is the nonlinear sensual response of human vision; if you wanted to accurately model that you'd need a logarithmic mapping. The true reason for the need of gamma correction is the nonlinear behaviour of certain kinds of image sensors and display devices. CRT displays, be the very physics they are based on have an inherent nonlinearity that's approximated by a gamma=2.2. When LCDs got introduced they of course were made to approximate the behaviour of CRT displays, so that you could substitute them without further ado.

Another important aspect to consider is, that using just gamma is not the most efficient way to distribute the bits. You want a logarithmic mapping for that; which also has the nice side effect, that a power law gamma value ends up as a constant scaling factor to the logarithmic values.

Now, it's also important to understand that these days the bread-and-butter colorspace is sRGB and that complicates things. sRGB has the somewhat inconvenient property that for the lower range of values its actually _linear_ and only after a certain threshold it continues (differentiable) with a power law curve. That's kind of annoying, because with that you no longer can remap logarithmically. And of course converting from and to sRGB can be a bit annoying because of that threshold value; you certainly can no longer write it as a convenient one-liner in a GPU shader for example. That's why modern OpenGL profiles also have special sRGB framebuffer and image formats and reading from and writing to them will perform the right linearization-mapping.

However either way what the explanation for gamma is, the important takeaway is, that to properly do image processing the values have to be converted into a linear color space for things to work nicely. Ideally a linear contact color space.

Wow. May I ask how/where you learned all that?

If you want to learn about color, the best source on the web is http://www.handprint.com/LS/CVS/color.html

There are some (in my opinion) better explanations in books, but it’s hard to link people to books. :-)

The L component of CIE Lab is not linear, it has a similar non-linearity to sRGB due to one of the aims of the design of the CIE Lab space is to be perceptually uniform.

Yes, but you can certainly linearize that for image operations and much easier than sRGB (which has a nasty change of mapping functions midway).