The BT.1886 EOTF doesn't specify any particular "signal". As I understand it, video input level is something basic and fundamental to a display. I think it makes sense to think of things like luma and chroma channels as operating on a different "layer".

Poynton, from "Digital Video and HDTV Algorithms and Interfaces":

"Now that I have explained the overall signal flow of video, and introduced my notation for the basic components, I will detail the encoding of luma and color difference signals [...]".

These signals can be sent to a display where they will necessarily be input signals. Moreover, they will have levels. So those levels will be input signal levels.

Now it may be that the BT.1886 document is using these words in a different way. I would say it is really important in a document like this to precisely define the terms used to avoid ambiguity and misinterpretation.

I am going to assume, in the absence of any contradicting information, that BT.1886 can safely be applied to R', G' and B' individually to linearize those encoded values.

Hopefully someone else can help you out here, but perhaps going back to the definition of an EOTF might help (the E, referring to the electrical domain, is what is proportional to V)*. Also see chapter 27 of Poynton, where EOTFs are discussed. I suppose you can consider video input level the same as R'G'B', but that's really only the case when an appropriate EOTF is in place. If a linear EOTF were in place, I don't think it would make sense to equate video input level with R'G'B'. With a CRT, the video input level (i.e. voltage driving the cathode) was naturally R'G'B', but this was incidental. In the context of more modern displays, which have various natural EOTFs, and with software LUTs, I don't think it makes sense to do the same.

*Because LUTs can change the relationship between input level and voltage, it might make sense to conceive of V as simply a normalized vector (values ranging from 0 to 1) that has 2^bitdepth elements. A LUT will then transform this vector into a set of voltages, and the display will transform these voltages into a set of luminances (L). The EOTF of the system is the relationship between V and L.

"With the introduction of new display technologies which have entirely different characteristics to the CRT displays, it is necessary to define the EOTF of new devices that emulate that of the CRT displays. "

Rec. 709 is from a time when CRT displays were still widely used and decoding by CRT at the other end was more or less assumed. You need to regard the BT.1886 and Rec. 709 recommendations as being complementary. The BT.1886 function is not a kind of universal EOTF. In fact, if you look at the BT.1886 document, you will find part of the Rec. 709 document in it.

"With the introduction of new display technologies which have entirely different characteristics to the CRT displays, it is necessary to define the EOTF of new devices that emulate that of the CRT displays. "

Rec. 709 is from a time when CRT displays were still widely used and decoding by CRT at the other end was more or less assumed. You need to regard BT.1886 as being complementary to that legacy standard (and others similar to it) and not as a kind of universal EOTF. In fact, if you look at the BT.1886 document, you will find part of the Rec. 709 document in it.

I don't see how anything I've written contradicts this. I never claimed BT.1886 to be a universal EOTF (I'm not even sure what a "universal EOTF" would even mean).

I sense that "we" may be over thinking the situation here. In digital REC709/601 luma and chroma are expressed in Y,Cr,Cb domain. In this case, bt1886 "V" is simply R709/601 (normalized) "Y." As spacediver stated, the de-matrixing to RGB domain is a different "layer."

Conversely, in sRBG, "gamma" is technically applied to each of the R, B, G channels separately, however, through the power of "math" this is also moot point for Y,Cr,Cb encoded "video" material. Muddy enough? (48)

Order of operations to convert YCbCr is inverse color difference matrix and offset for "legal" to "full" range to R'G'B' followed by EOTF to linear RGB. This is the non-constant luminance encoding that is used with 709.

BT.2020 has an option for constant luminance encoding, where the order of operations is altered so that the color difference calculation is done in the linear domain, but manufacturers are too cheap to actually implement it because it requires a few additional steps and higher precision in their video chips.

interesting, it seems I've had a reversed understanding of what R'G'B' actually entails.

The primes are used to denote a nonlinear encoding. Similarly, X'Y'Z' is a 2.6 gamma encoding of linear CIE XYZ values. YCbCr is written without primes in the BT.709 document, but with BT.2020 was changed to the more explicit form Y'C'bC'r with primes. It is unfortunate that old standards can't be edited because it leads to confusion when you see BT.709 use one form:

Quote:

Coded signal R, G, B, or Y, CB, CR

And then BT.2020 uses the other form:

Quote:

Coded signal R', G', B' or Y', C'B, C'R or Y'C, C'BC, C'RC

In any case, the standard practice now is to use primes to denote that the encoding is nonlinear. Color differencing has always been performed on the nonlinear encoded signals, which is why "luma" has the non-constant luminance problem.

It is worth noting that in the 709 document there is a line that partly clarifies/partly muddies the issue:

Quote:

The terms R, G, B, Y, CB, CR, are often used and are generally understood to refer to the signals E'R, E'G, E'B, E'Y, E'CB, E'CR respectively (i.e. they correspond to gamma pre-corrected signals).

the part that confuses me is that linearity can be defined with respect to luminance, or with respect to some other quantity. If an EOTF creates a perceptually uniform relationship between adjacent levels of luminance, then one could say that the relationship between adjacent input levels is non linear with respect to luminance, but linear with respect to "lightness". So if an EOTF results in RGB that is linear, I'm assuming that the term "linear" here is with respect to lightness, rather than luminance. Am I on the right track?

Yes, you have to define what it is linear relative to. Linear with respect to luminance is pretty straightforward. To make something perceptually uniform generally introduces a high degree of non-linearity, and there are always compromises in which aspect of perception is being optimized for. I.e. CIELAB even though it has the goal of being perceptually uniform is known to be highly nonlinear in hue (especially for blue). So it is common to hear something described as perceptually uniform, but perceptually linear is not usually used. In the 2084 definition for EOTF, they completely did away with primes and just define L as linear color value and N as nonlinear color value, with the goal being that N is well aligned with human visual contrast sensitivities.

Order of operations to convert YCbCr is inverse color difference matrix and offset for "legal" to "full" range to R'G'B' followed by EOTF to linear RGB. This is the non-constant luminance encoding that is used with 709.

Thank you, EvLee. That is what I had originally assumed, but I wanted to be sure because there is a history in video of sometimes doing things in a somewhat unexpected or even odd way. In addition, the BT.1886 document isn't very clear in this respect. Again, I will quote the relevant part of BT.1886:

What is not stated there is that is that there is more than one video signal and those individual video signals do not range from black to white. E.g., if and when V is R', then after normalization it represents black at V=0 and luminous red at V=1. In the Rec. 709 situation, and assuming the correct order of operations, there isn't a single V value that represents a range from black to white as described in BT.1886. One could think of a virtual V that represents one of the greyscale levels R'G'B' = {16,16,16}, {17,17,17} ... {235,235,235}. In that case, because R' = G' = B', this is one dimensional and a single V will suffice. But that V input video signal level is an imaginary notion - there is no suitable candidate for it in Rec. 709.

As per Lindbloom, it seems that V properly interpreted in the Rec. 709 context can be understood to be member of the set {R',G',B'}. Now, R', G' and B' do each happen to be 1 at white, when normalized appropriately. So that is not inconsistent with the quoted statement from BT.1886. But the recommendation could be much clearer than it is because the most natural, but wrong, interpretation is that the function is applied to a signal that itself represents a range from black to white. And once one starts thinking about it like that, then the next error might be to think of Y' as something that represents a range from black to white and then wrongly apply the function to Y'.

If BT.1886 is intended, in part, to be formalize a decoding component for Rec. 709, then the ITU need to be much more explicit about how the two standards fit together. By way of analogy, if you describe an encoding/decoding device pair, you may also need to describe where any wires between them go. Otherwise, a wire from the encoder may be plugged into the wrong socket of the decoder.

A little comment about the phrase "for content mastered per Recommendation ITU-R BT.709". That would seem to imply that BT.1886 is also suitable for content mastered in other ways and it might well be. But the recommendation appears to be largely tilted toward that standard, even if it is applicable elsewhere. I think the ITU need to be really careful about embedding hidden dependencies in their recommendations.

Quote:

Originally Posted by EvLee

The primes are used to denote a nonlinear encoding. Similarly, X'Y'Z' is a 2.6 gamma encoding of linear CIE XYZ values. YCbCr is written without primes in the BT.709 document, but with BT.2020 was changed to the more explicit form Y'C'bC'r with primes. It is unfortunate that old standards can't be edited because it leads to confusion when you see BT.709 use one form

Yes, that is unfortunate. For the analogue signals the prime is used, but it is omitted elsewhere, which is not a very consistent approach. Looking again at that statement from Rec. 709 page 3:

"The terms R, G, B, Y, C_B, C_R , are often used and are generally understood to refer to the signals E′_R, E'_G, [...] respectively (i.e. they correspond to gamma pre-corrected signals)."

That is not very helpful, because "generally" can mean "sometimes but not always". It is also not clear whether they are referring to how the symbols are used in that particular document alone (I assume they are) or elsewhere as well. They could have written that the symbols are often used elsewhere in that way, but they are going to be more precise than that and always use the prime symbol.

709 is an old standard. I think they are much more careful about wording in the new standards when it comes to distinguishing which statements are normative and which are simply informative. However, it is quite difficult to get the wording just right when drafting a document that needs to bridge old conventions and new, or standards from different organizations (ITU and SMPTE), not to mention balancing the interests of all parties involved in the standards work. In some cases clarification can be found in the SMPTE RP (recommended practices) documents.

I've been looking at these gamma functions a little bit more closely. One thing that strikes me as rather odd is the use of the max function in the BT.1886 definition:

The use of max only makes sense if (V + b) is ever negative. If not, then the max function acts just like the identity function and returns (V + b). Now V cannot ever be negative because it takes values from the closed real interval [0,1]. Therefore (V + b) can only be negative if b is negative. Could b ever be negative? At a glance it looks as though b can only be negative if Lw < Lb. In other words, the use of max only makes sense for those occasions when a white screen is darker than a black screen

Taking a little detour to look at the BT. Rec 709 pre-correction function first, as BT.1886 will generally be used to partially (and inexactly) invert that (and, yes, I know it's not meant to be the exact inverse), here is its point gamma plot:

The limit at the low end (L = 0) is 1 and it approaches 0.49455 as L->1. It is undefined for L=1 itself and the mean point gamma value is 0.512992 (= 1/1.94935).

The plot of the encoding gamma reciprocal:

And here is the usual sort of plot of BT.1886 pt gamma for various Lb (MLL) values ranging from 0 to 0.01 cd/m^2:

The uppermost curves are for lower Lb values, with the straight line gamma = 2.4 curve for when Lb=0 cd/m^2. I guess one could ask what the average gamma is for each level of Lb. Well here is another graph that illustrates that relationship:

So the mean gamma of BT.1886 falls as Lb rises, which I am sure is not news. But anyway, I thought you might like to see my graph, which may well be very much like other graphs posted before.

Now the gamma exponent of BT.1886 is 2.4, but we could ask what it would have to be, for a given Lb (MLL) value, to yield a mean point gamma of 2.4. If, for example, Lb is 0.01 cd/m^2, then the mean point gamma is 2.29963. If a higher gamma exponent had been used, then the mean point gamma would have been higher. A mean point gamma of 2.4 occurs for Lb = 0.01 when the gamma exponent, g, is 2.52572. A plot of the relationship between g and Lb if one wants to achieve a mean pt gamma of 2.4:

I've just thrown this together super quick, so it would not surprise me if there were mistakes above. Corrections, as always, welcome.

yes, the max function basically says to evaluate the V+b part of the function, compare it to 0, and choose the larger value. Then proceed with the rest of the function. It's there presumably to prevent negative luminance targets that may arise with a negative inputted black level. I suppose this might arise in an automated process where an instrument reads a very dark display and instrument noise results in a negative reading for the black level.

The use of max only makes sense if (V + b) is ever negative. If not, then the max function acts just like the identity function and returns (V + b). Now V cannot ever be negative because it takes values from the closed real interval [0,1]. Therefore (V + b) can only be negative if b is negative.

But, BT1886 is now making an some inroad into grading facilities - so some newer films may indeed have been graded BT1886 now.

However, even that will be shorted lived as SMPTE2804 (and variations on it) becomes the standard for HDR displays, which most higher-end post-facilities will be adopting.

What all this means is it is still a crap-shoot as to what gamma was used for any given film grade!

Personally, I dislike the way BT1886 washes-out shadows, especially on material graded 2.2 power, so I stick to a power 2.2 for my personal TVs. It works the best for everything in my personal view.

When we (the Light Illusion team) perform calibrations for facilities we give them the choice as to their preference.
We still have 85% selecting to go 2.2 for Rec709 workflows, with the remainder split 2.35, or BT1886.

I think there's a bit of a misconception about the idea that the gamma of a CRT is "native". Yes, the gamma (essentially the transfer function of the triode) is influenced by the structure of the triode (in particular, the spacing between the grid elements), but it's also heavily modulated by the G2 voltage, and this is psychophysically calibrated - typically a pattern of 16 bars ranging from min to max luminance is used, and the idea is to adjust the G2 voltage until the second bar is barely distinguishable against the first (pedestal) bar. Because this is a psychophysical procedure, different service technicians (perhaps working under different lighting conditions) may produce different gammas. I know of at least one studio (which used FW900s) that requested the technicians to turn the G2 way down so that the blacks were even deeper (they then used a LUT to finely tune their desired gamma). When I calibrate my CRTs I like setting the blacks very deep, and when I do so, the native gamma is around 2.8 or higher (I then correct with a LUT, allowing me a custom gamma while retaining those gorgeous inky blacks).

At least this is what I think was going on - I have experience with the GDM line of Sony CRTs, in particular the FW900, but I imagine the BVM calibration procedures were similar.