From the forums: Charles Poynton & Advanced Digital Colour Theory

One of the great things about fxphd are our private  forums, where members can ask followup questions of the profs who teach the classes. A great example of this interactivity comes this term from Charles Poyton’s Digital Colour Theory course. As a bonus, we thought we’d share a couple posts from the forums, as they are really great nuggets of information. These two posts cover questions from members regarding log coding and scene linear in grading as well as followups regarding radiometric vs. photometric.

We also have a free sample of one of the classes, below.

Forum Question #1
Subject: Radiometric vs Photometric
Poster: Claude C.(Paris, France)

Many thanks to fxphd and Mr Poynton for this 3rd course. I’m a little bit confused when you’re talking about scene luminance. You said many times that scene luminance is a radiometric quantity but isn’t it energy perceived by human eye or camera sensor? Photometric wouldn’t be more specific? Could you help me to clarify this issue?

Charles’ Answer:

It’s a good question. Exactly as you imply, “photometric” would be more specific. However, …

Any “radiometric” quantity is proportional to energy (power, photon count, etc.) – but, wavelength distribution is left unstated.

Any “photometric” quantity is also proportional to energy (power, photon count, etc.) – but, wavelength distribution is by definition that of the standard human luminance sensitivity. The weighting function (curve) is sometimes called the luminous efficiency function; it’s typically denoted “y-bar” or “vee-lambda”. The definition of luminance incorporates this curve.

At first glance, you’d think: A camera had better observe that curve, otherwise, the lightness of images would not properly be captured. To the first order of approximation, that’s correct. However, camera’s don’t really really closely conform to the curve; they cheat^h^h^h^h^h approximate the curve for various engineering reasons.

If we say “photometric,” we imply that the camera faithfullly follows the luminance weighting curve.

If we say “radiometric,” we leave ourselves off the hook, allowing for approximations in the camera.

When referring to a camera, I always describe the [scene-linear] image data values as “radiometric” for that reason. If I’m referring to a colour measurement (by a colorimeter, for example), THEN I’ll use the term “photometric” because I’m confident that the value is a very close representation of the proper curve.

Thanks for the question, a good one!


Forum Question #2
Subject: Log coding and scene linear in grading
Poster: Peter R. (Tegernsee, Germany)

This isn’t really a question, but I wanted to share some thoughts with the request for Charles to maybe comment on that or correct me where I’m wrong.

As the log coding mainly serves the purpose of using the available bits more efficient, I see a problem where it comes to inverting that for grading. Especially when inverting mathematically correct like in the IDT of ACES. After that I have a somewhat scene linear dataset again. But of course the alleged unnecessary values to the next 1% step are still gone. In theory there should be now all the same values until it comes to the next 1% step. Just as a model concept. If I now start grading that image by scaling it (like for reducing gain for darkening) those numbers come into an area where there should be intermediate values and therefore could show “banding”.

In other words: If I have a RAW image, with all those perceptual useless intermediate values to the next visual 1% step – they are becoming very important when the whole thing is scaled up or down. So a linear light dataset from an Log coded camera after the IDT cannot be treated like “real” scene linear material with all inbetween 1% values ready to be pushed around in heavy grading.

But for the reality check: When I capure in log with a 10bit codec – will it really be a problem that can be noticed? How far can one go in grading or ist there still so much information that it will never be a problem in the real world?

Thanks for any thoughts.

Charles’ Answer:

Peter: Log coding mainly serves the purpose of using the available bits more efficient That’s fair.

Charles: There are other big benefits: adjusting exposure can be done by just adding or subtracting a constant; white balance, adding or subtracting three constants, one for each channel. Providing the coding places optical black at code zero, the identical effect is obtained by multiplying each channel by a constant, but there is a big conceptual advantage of thinking in log space. If you take Weber’s Law at its face, we see in log space, so adjustments in that space ought to mimic perception (and to a large extent, in practice they do).

Peter: I see a problem where it comes to inverting that for grading

Charles: In log space, vision’s 1.01 ratio is represented as a fixed interval in code space; worst case, 1 code, and in better cases, several or dozens of codes per JND. For example, OpenEXR 16-bit float has 1024 steps per stop, and vision needs only about 70: It’s overquantized by a factor of 1024/70 or between about seven and fifteen (depending upon exactly where the code falls with respect to the stops coded by OpenEXR’s exponent value). You could say there are three or four bits per component in excess of what’s required by 1.01. But whether all of those 7 or 15 codes per 1.01-ratio interval are noise-free, that’s entirely another matter. In practice, there is noise.

Peter: [After recovery of scene-linear values …] In theory there should be now all the same values until it comes to the next 1% step

CharlesIn theory the linear-light values could be duplicated until the next 1.01 step; however, that’s not the way things are implemented: Instead, in practice, the deep pixel component depth accommodates lots of codes in the “band” of values within vision’s JND interval. Those are the codes in OpenEXR’s band of seven or fifteen codes within the interval of each 1.01 ratio. I don’t think of the “steps”; I think of bands of uncertainty/noise/imperceptibility that are contained within the 1.01 ratios in scene-linear space.

Peter: I see a problem where it comes to inverting that for grading

CharlesWell yes, that’s where it’s good that the implementations don’t duplicate all the values within a 1.01 band: The formerly indistinguishable (uncertain/noisy/imperceptible) codes can be squashed in grading [which cannot lead to banding or additional noise] or stretched in grading [which can lead to banding or additional noise, but that all depends upon circumstances].

Peter: If I have a RAW image, with all those perceptual useless intermediate values to the next visual 1% step – they are becoming very important when the whole thing is scaled up or down.

CharlesThis is 100% true – and it’s important.

Peter: …a linear light dataset from a Log coded camera after the IDT cannot be treated like “real” scene linear material with all in-between 1% values ready to be pushed around in heavy grading.

CharlesThis issue leads to the discussion: Where is the noise, and how much noise is there? If you want to get more sophisticated: How does the noise component depend upon scene exposure level? All of these issues need to be discussed with respect to our approximate 1.01-ratio visual JND interval. There are no simple answers here (I’m working on some simplifications in my PhD work). The quick answer is that a quasilog function matches sensor characteristics well AND matches visual performance well. Quasilog was invented by the Grass Valley guys (Viper designers), but not with that name. It is perhaps most easily understood in the form expressed by David Newman in a CineForm Insider blog post 10‑bit log vs 12‑bit linear.

quasilog90

The equation is:

signalcode = Log90(1 + 89·exposure)

(If you don’t have, or have trouble with, base-90 logarithm, the equation above is equivalent to

signalcode = Log10(1 + 89·exposure) / log10(90)

In Wolfram Alpha, try Plot 90~Log~(1 + 89 y) from 0 to 1. Multiply by 1023 if you like, or multiply by 955 and add 64, to get HD-SDI code. In a future class, I’ll say more about quasilog.

Peter: When I capture in log with a 10bit codec – will it really be a problem that can be noticed? How far can one go in grading or ist there still so much information that it will never be a problem in the real world?

It all depends … but, generally, a well-exposed scene captured by a 12- or 14-bit ADC coding with a reasonable quasilog (like SI log90, or Slog) into 10-bit space will be fine. If in 10-bit HD-SDI code you take the range between codes 400 and 420, and stretch that into the full black-to-white range, well no, that won’t work. Noise that was previously below visual threshold will now be way in excess of visual threshold. But there is no simple easy answer concerning exactly where visual threshold lies. And even if there was, it couldn’t be exact!

Aiieee. That took an hour! Great comment/question, Peter; again, sorry for the delay – and I hope we don’t have a “share some thoughts” amplification ratio greater than unity!


Free preview of our new Advanced Digital Colour Theory course

This course is one of eleven new courses on offer this term, in addition to over 100 other repeat offerings. Check out the entire first class of DCT303 below — totally free for your eyeballs’ (and brain’s) pleasure. P

To find out more about how fxphd works, check out our tour page.