The terms "linearization" vs "calibration"

[bjanes]

And this is why I've kept this fine post from Lars on the controversial subject of this kind of calibration (which at the time it was posted, to this day, hasn't been addressed by the Lstar proponents):

Lab attempts to be perceptually uniform but it's really not....

Quite true, but neither is a gamma function with an exponent of 1/2.2 or 1/2.5. Light contamination (flare) is present whether your monitor is calibrated to 1/2.2 or 1/2.5 as well as with L*a*b. In fact, if the images are viewed in a bright surround, Poynton suggests that an exponent of 1.1 or 1.2 would be more appropriate (Gamma FAQ). AdobeRGB uses 1/2.2 and ProPhotoRGB uses 1/1.8. The ProPhotoRGB spec assumes 0.5 to 1% viewing flare and the sRGB spec stipulates 1% viewing flare and a typical ambient illumination of 200 lux. I don't know about L*a*b assumes, if anything.

In developing his BetaRGB space, Bruce Lindbloom concluded, " 'What value for gamma gives a companding function that most closely represents the CIE L* function (i.e. a uniform perceptual scale)?' We can explore this question by setting the input to L* and the output to Gamma 1 (or Gamma 2). A perfect match would be a straight line drawn on the diagonal. You can see that a gamma value of 2.2 is not too bad of a compromise because it roughly follows the diagonal:"

In practice I don't think it makes much difference whether you calibrate your monitor to L*a*b or 1/2.2. 1/2.2 if fine with me and is what I use since that is what Spectraview uses.

Regards,

Bill

[digitaldog]

Quite true, but neither is a gamma function with an exponent of 1/2.2 or 1/2.5.

It doesn't promise to be AFAIK.

In practice I don't think it makes much difference whether you calibrate your monitor to L*a*b or 1/2.2. 1/2.2 if fine with me and is what I use since that is what Spectraview uses.

Exactly but the Lstar calibration proponents seem to disagree without proving it.

[bjanes]

[quote author=Doug Gray link=topic=110235.msg908499#msg908499 date=1462804672
L*a*b* is much closer to a gamma encode like Adobe RGB than it is to a log encode. It's even more similar to sRGB which has a significant linear lead in ramp though L*a*b* has both a higher gamma (3.0) and larger lead in ramp than sRGB.
[/quote]

L*a*b approximated by gamma = 3. I don't think so. According to Bruce Lindbloom it is closer to 2.2

[Doug Gray]

[quote author=Doug Gray link=topic=110235.msg908499#msg908499 date=1462804672
L*a*b* is much closer to a gamma encode like Adobe RGB than it is to a log encode. It's even more similar to sRGB which has a significant linear lead in ramp though L*a*b* has both a higher gamma (3.0) and larger lead in ramp than sRGB.


L*a*b approximated by gamma = 3. I don't think so. According to Bruce Lindbloom it is closer to 2.2

And Bruce is right that L* approximates a pure gamma 2.2.

L* is a linear ramp tacked onto a gamma=3 scale. It has a bigger linear ramp than sRGB which is why the approximate gamma as compared to a gamma only curve is close to 2.2.  In much the same way sRGB more closely matches a gamma=2.2 curve in spite of actually being a gamma 2.4 tacked onto a linear ramp. sRGB isn't as affected as L* because it has a smaller linear ramp than L*.

[Doug Gray]

I have already noted the limitations of gamma and L*a*b encodings as documented below, and you are quoting me out of context in an attempt to prove your point. The same limitation applies to a log encoding, but then zero luminance rarely occurs in practical photographic situations and the minimum value possible in a log encoding is sufficiently close to zero for practical use. Log encodings are successfully used for HDR along with floating point. Did you take the trouble to read the article by Greg Ward?

Regards,

Bill

I'm not uncomfortable with log scaling. It's the basis for floating point representation in essentially all computer architectures. And it does provide consistent, relative error performance. I just don't believe it is necessary in photography or printing.

You were the one that pointed out that the slope of gamma curves becomes infinite at 0 as if that was significant. I was just noting that log scales have no value, let alone slope, at 0. At some point you have to truncate (or clip) a log scale. Neither of these facts impairs the ability of either to function. It would be interesting to construct an analysis of log scale (say, using 16 bit floats) v 16 bit, gamma 4 over possible HDR ranges. I think both would serve quite well.

And yes, gamma curves do not have a constant relative error per step change. Certainly 8 bit discrete, gamma encoding is not going to work for HDR work. Either in synthetic images or real image captures. But 16 bits does. With or without a linear front end ramp though I do not like linear front end ramps on a gamma scale as a simple scale factor change can alter colors and that is not the case with pure gamma encoding.

Constant relative error is a useful property but it does not represent actual light physics. Shot noise magnitude, for instance, tracks the square root of luminance thus intrinsically will not produce constant relative error. Multi exposure HDR techniques can produce more constant relative error which allows wider adjustments in post. Still, it would be a rare 16 bit gamma encoded image where even an HDR image could not be encoded with errors below the physical shot noise limit. Unlike L* or sRGB scales, which are mixed linear/gammas, both log and gamma scales provide easy luminance scaling without shifting color. Gamma scales by simply multiplying RGBs by a factor while log scales accomplish the same thing by adding a factor.