Gamma & BT.1886 explained. Lightspace users check in here - need your help! - Page 8 - AVS Forum | Home Theater Discussions And Reviews
Baselworld is only a few weeks away. Getting the latest news is easy, Click Here for info on how to join the Watchuseek.com newsletter list. Follow our team for updates featuring event coverage, new product unveilings, watch industry news & more!


Forum Jump: 
 9Likes
Reply
 
Thread Tools
post #211 of 232 Old 05-07-2015, 01:09 AM
Senior Member
 
fluxo's Avatar
 
Join Date: Oct 2012
Posts: 461
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 211 Post(s)
Liked: 133
Quote:
Originally Posted by spacediver View Post
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.

Last edited by fluxo; 05-07-2015 at 01:14 AM.
fluxo is online now  
Sponsored Links
Advertisement
 
post #212 of 232 Old 05-07-2015, 01:38 AM - Thread Starter
AVS Special Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 1,005
Mentioned: 4 Post(s)
Tagged: 0 Thread(s)
Quoted: 150 Post(s)
Liked: 81
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.

Last edited by spacediver; 05-07-2015 at 02:06 AM.
spacediver is offline  
post #213 of 232 Old 05-07-2015, 04:59 AM
Senior Member
 
fluxo's Avatar
 
Join Date: Oct 2012
Posts: 461
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 211 Post(s)
Liked: 133
BT.1886 is supposed to mimic the characteristics of CRT displays:

"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.

Last edited by fluxo; 05-08-2015 at 01:01 AM.
fluxo is online now  
post #214 of 232 Old 05-07-2015, 09:23 AM - Thread Starter
AVS Special Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 1,005
Mentioned: 4 Post(s)
Tagged: 0 Thread(s)
Quoted: 150 Post(s)
Liked: 81
Quote:
Originally Posted by fluxo View Post
BT.1886 is supposed to mimic the characteristics of CRT displays:

"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).
spacediver is offline  
post #215 of 232 Old 05-07-2015, 11:08 AM
AVS Special Member
 
HDTVChallenged's Avatar
 
Join Date: Jan 2002
Posts: 8,879
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 187
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)
HDTVChallenged is offline  
post #216 of 232 Old 05-07-2015, 07:07 PM
Member
 
EvLee's Avatar
 
Join Date: Dec 2009
Posts: 171
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 88 Post(s)
Liked: 98
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.

Last edited by EvLee; 05-07-2015 at 07:11 PM.
EvLee is offline  
post #217 of 232 Old 05-07-2015, 08:56 PM - Thread Starter
AVS Special Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 1,005
Mentioned: 4 Post(s)
Tagged: 0 Thread(s)
Quoted: 150 Post(s)
Liked: 81
interesting, it seems I've had a reversed understanding of what R'G'B' actually entails.
spacediver is offline  
post #218 of 232 Old 05-07-2015, 09:28 PM
Member
 
EvLee's Avatar
 
Join Date: Dec 2009
Posts: 171
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 88 Post(s)
Liked: 98
Quote:
Originally Posted by spacediver View Post
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).

Last edited by EvLee; 05-07-2015 at 09:37 PM.
EvLee is offline  
post #219 of 232 Old 05-07-2015, 09:34 PM - Thread Starter
AVS Special Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 1,005
Mentioned: 4 Post(s)
Tagged: 0 Thread(s)
Quoted: 150 Post(s)
Liked: 81
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?
spacediver is offline  
post #220 of 232 Old 05-07-2015, 09:52 PM
Member
 
EvLee's Avatar
 
Join Date: Dec 2009
Posts: 171
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 88 Post(s)
Liked: 98
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.

Last edited by EvLee; 05-07-2015 at 09:58 PM.
EvLee is offline  
post #221 of 232 Old 05-08-2015, 12:34 AM
Senior Member
 
fluxo's Avatar
 
Join Date: Oct 2012
Posts: 461
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 211 Post(s)
Liked: 133
Quote:
Originally Posted by EvLee View Post
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:

"V: Input video signal level (normalized, black at V = 0, to white at V = 1. For content mastered per Recommendation ITU-R BT.709, 10-bit digital code values “D” map into values of V per the following equation: V = (D–64)/876"

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 View Post
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.

Last edited by fluxo; 05-08-2015 at 01:14 AM.
fluxo is online now  
post #222 of 232 Old 05-08-2015, 08:22 AM - Thread Starter
AVS Special Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 1,005
Mentioned: 4 Post(s)
Tagged: 0 Thread(s)
Quoted: 150 Post(s)
Liked: 81
my apologies fluxo, seems that I may have been the one making a thinking error here
spacediver is offline  
post #223 of 232 Old 05-08-2015, 08:52 AM
Member
 
EvLee's Avatar
 
Join Date: Dec 2009
Posts: 171
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 88 Post(s)
Liked: 98
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.
fluxo likes this.

Last edited by EvLee; 05-08-2015 at 08:57 AM.
EvLee is offline  
post #224 of 232 Old 05-08-2015, 10:20 AM
Senior Member
 
fluxo's Avatar
 
Join Date: Oct 2012
Posts: 461
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 211 Post(s)
Liked: 133
Quote:
Originally Posted by spacediver View Post
my apologies fluxo, seems that I may have been the one making a thinking error here

It will be my turn next time. If there's one area of expertise where I'm infallible, it is the art of making mistakes
fluxo is online now  
post #225 of 232 Old 05-09-2015, 09:24 AM
AVS Special Member
 
HDTVChallenged's Avatar
 
Join Date: Jan 2002
Posts: 8,879
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 187
Quote:
Originally Posted by fluxo View Post
It will be my turn next time. If there's one area of expertise where I'm infallible, it is the art of making mistakes
LOL ... Nice. I too believe made an error wrt the significance of the order of operations. I was visualizing the "EOTF" only in terms of greyscale. (50)
HDTVChallenged is offline  
post #226 of 232 Old 05-12-2015, 02:22 AM
Senior Member
 
fluxo's Avatar
 
Join Date: Oct 2012
Posts: 461
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 211 Post(s)
Liked: 133
Gamma & BT.1886 explained. Lightspace users check in here - need your help!

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.

Cheers!

Last edited by fluxo; 05-12-2015 at 02:52 AM.
fluxo is online now  
post #227 of 232 Old 05-12-2015, 05:48 AM
Senior Member
 
fluxo's Avatar
 
Join Date: Oct 2012
Posts: 461
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 211 Post(s)
Liked: 133
May I ask, is anyone using the alternative formulation in BT.1886?
fluxo is online now  
post #228 of 232 Old 05-12-2015, 07:51 AM - Thread Starter
AVS Special Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 1,005
Mentioned: 4 Post(s)
Tagged: 0 Thread(s)
Quoted: 150 Post(s)
Liked: 81
From another thread

Quote:
Originally Posted by spacediver View Post
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.
fluxo likes this.
spacediver is offline  
post #229 of 232 Old 05-12-2015, 08:48 AM
zel
Member
 
zel's Avatar
 
Join Date: Mar 2004
Location: California
Posts: 88
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 28 Post(s)
Liked: 19
Quote:
Originally Posted by fluxo View Post


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.
V = (D-64)/876, so blacker than black is negative V.
zel is offline  
post #230 of 232 Old 05-12-2015, 09:24 AM
AVS Special Member
 
sotti's Avatar
 
Join Date: Aug 2004
Location: Seattle, WA
Posts: 6,758
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 123 Post(s)
Liked: 214
Quote:
Originally Posted by zel View Post
V = (D-64)/876, so blacker than black is negative V.
Correct. That's why it gets clipped and doesn't show up on a display. That's also the purpose of the max[V+b,0] function.

Joel Barsotti
SpectraCal
CalMAN Lead Developer
sotti is online now  
post #231 of 232 Old 05-29-2015, 04:42 AM
Advanced Member
 
Light Illusion's Avatar
 
Join Date: Aug 2010
Posts: 618
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 52 Post(s)
Liked: 278
For older films and programs that is factually correct.

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.

Steve
anta1974 and bonafied like this.

Steve Shaw
LIGHT ILLUSION

Light Illusion is offline  
post #232 of 232 Old 06-07-2015, 07:56 PM - Thread Starter
AVS Special Member
 
spacediver's Avatar
 
Join Date: May 2013
Location: Toronto
Posts: 1,005
Mentioned: 4 Post(s)
Tagged: 0 Thread(s)
Quoted: 150 Post(s)
Liked: 81
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.

Last edited by spacediver; 06-07-2015 at 08:22 PM.
spacediver is offline  
Sponsored Links
Advertisement
 
Reply Display Calibration

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off