Copy link to clipboard
NLC tags are rather crucial to working in video post professionally. They can be incredibly confusing. And there is no published information on what PrPro's NLC practices are concerning both reading and publishing tags (to file headers on export).
I know the app is hard-coded to assume Rec.709 b-cast standards for monitors: sRGB primaries, D65 white point, gamma 2.4, and 100 nits monitor brightness in a semi-darkened room. The "display color management" preferences option makes PrPro look at the monitor's ICC profile and attempt to remap the image to show as correct Rec.709 on that monitor's color management system.
I work with some of the top colorists in the world daily. They work out of Resolve, Baselight, and Avid mainly, and have gear including $10,000 spectroradiometers to use for calibrating their spendy monitors. They deal in NLC tags every day. And need to know, professionally, exactly what PrPro does with the NLC tags inbound and outbound.
In some applications/CM, 1-1-1 will show as Rec.709 without a gamma specification. So whatever gamma is applied via monitor/LUT box will be used. So on mine for example, with everything calibrated and profiled for Rec.709/2.4, anything 1-1-1 will show as I expect, gamma 2.4.
On some systems though, 1-1-1 seems to be shown as gamma 2.2.
On most systems that show 1-1-1 as 2.2, the "other" or "2" tag will cause the system to apply gamma 2.4. So for some users, a 1-2-1 NLC tag would simply get the correct view.
And I'm told there's not many systems where the 1-2-1 tag is a problem, fewer than where 1-1-1 is a problem.
But ... it's durn hard to get the hard information. And ... after that deep dive of hours and hours with Francis and Lars Borg a couple years back now on PrPro's internal CM, if I don't know this, ain't hardly nobody out here that does.
On input, does PrPro read and utilize NLC tags, or does it look at the format/codec and assume 'correct' standards?
On export, does PrPro apply NLC tags and if so, what?
Here is a very long and technical answer. Hope you don’t mind.
1-1-1 is standard Rec. 709. Only 1-1-1 is standard 709.
The middle 1 does not specify a display gamma.
AVC and HEVC declares 1 as the transfer function of a fictitious Rec. 709 camera, approx gamma 2. But camera vendors say no camera uses that TF in production. Definitely not for display.
More recent Rec.709 specs say that when viewed on a broadcast monitor (which historically is based on a CRT TV in a dim room), you should use gamma 2.4 (see ITU-R BT.1886:2011).
On the other hand, sRGB (approx. gamma 2.2) was developed in 1996 by Microsoft and HP specifically to make a computer monitor in an average-lit office (500 lux?) match the color appearance of a TV in a dim room, so that no color conversion would be required. Blacks need to appear a bit lighter in the office than in the living room. Thus, 709 video should be viewed on an sRGB display when in the office, for an equivalent appearance.
Then we have the deviant, Apple’s QuickTime Player, which, long before BT.1886, decided to use gamma 2 for color conversions. Apple’s choice seems to be a compromise between the 1987 Apple RGB monitors (gamma 1.8) and 1996 sRGB monitors (gamma 2.2). Earlier, Web designers had made the same gamma compromise between Apple and Windows displays. Or maybe Apple just picked the Rec. 709 camera gamma 2 (going scene-referred). Unfortunately this has been adopted by other video players, giving us the QT gamma bug, where video looks too light compared to an sRGB display.
Premiere uses 1-1-1 for Rec. 709 video (import, timeline and export)
Right now, Premiere defaults viewing to broadcast monitor viewing conditions, gamma 2.4 (but we’re tweaking that).
DCM off would be useful for viewing 709 on an sRGB monitor.
1-2-1 is a hack. And it’s a hack to fix a hack.
AVC and HEVC declares 2 as undefined transfer function.
In many devices (QTP?!) this disables TF color conversions and color management, as there is no defined curve to apply and you get Preserve RGB. OK for 709 to an sRGB display or 709 TV, but not elsewhere where color management is needed.
In other devices, 2 signals a private, non-standard TF, including some HDR TF cases.
Given the inconsistent results, 1-2-1 should not be used generally.
1-2-1 won’t pass broadcast QC as it’s not standards compliant.
Premiere imports 1-2-1 as 709 (1-1-1). This is because Premiere ignores the invalid 1-2-1, and uses the default which is 709. It doesn’t matter anyhow as import to a 709 timeline preserves the 709 media values.
Premiere exports compliant 709 (1-1-1), marked in both NLC and VUI.
There are 3rd-party tools that can change the media’s tag setting from 1-1-1 to 1-2-1 or vice versa.
These tools usually only hack the NLC record, and not the VUI records inside the video frames, so as a result the video file is inconsistent, with different color spaces in different parts of the media file. This can lead to unpredictable results when playing or transcoding depending on which part the app looks at. So the hack to fix a hack would need more hacks.
A trivia question: Why did Apple select gamma 1.8 for Mac displays?
No points given for asking Charles Poynton!
Hi Lars & Neil,
There is a discrepency in your description of the "Transfer function" tag (The middle one) 1-1-1
And the description given by "FilmLight" in this vidéo : https://vimeo.com/349868875
They say that transfer function tag 1, implies a 1.95 gamma.
That would be the source of the gamma shift when a player, that has color managment, converts a "Rec709 2.4" video to the gamma of the display (Let's say 2.2), by compensating from 1.95 to 2.2...and not from 2.4 to 2.2
It seems they are right, because resolve exports 1-2-1 tags when we output a "Rec709 2.4" like filmlight.
The 2 would stand for custom gamma. If I understand correctly, the custom gamma number is carried through from the gamma of the project/source.
If we tackle this, we could get rid of the gamma shift in premiere exports, at least in a color managed (NCLC) pipeline.
Daniel starts by assuming the unique Apple/ColorSync concept of gamma for Rec.709 media ... that it's 1.95 ... is the 'normal' or correct usage. As Steve Shaw of LightIllusions and other color experts have noted (with no link to Adobe, Apple, whomever) ... this is NOT actually correct.
Pro usage of the Rec.709 standard includes use of 2.4 gamma (semi-dark room) or 2.2 (bright room). Period.
And quite a number of the experts have noted they cannot find "sRGB gamma" for any Rec.709 video usage. Which is what Apple says they use.
So yea, it's a morass.
On my system, a normal Rec.709 export from Resolve gets a file tagged 1-1-1. Which has a 2.4 gamma.
The ONLY way I get a 1-2-1 file out of Resolve is to use the "Rec.709-A" option, and as noted, Rec.709-A is for Apple use. I've bee through this with the colorists I work with daily. They're primarily a Mac crowd, and they're ticked off with Apple over this, and besides ... just wish that Apple, Microsoft, and a couple others would simply agree to ONE freaking standard, whatever ... so we could get on without this divide.
There are standards - for broadcast media. (BT.709, BT.1886, sRGB), and such media should be labeled 1-1-1.
If your media is not mastered for broadcast, those standards don't apply. Unfortunately, lacking other options, this media is most often labeled 1-1-1 as well, resulting in loss of creative intent.
Another label is needed. But 1-2-1 is not a suitable label, as 2 means undefined transfer function. OK, undefined does describe the current situation, so right now it is correct in a bad way 🙂
It seems we need a distinct label (and definition) for the non-broadcast media encoding.
ITU defines the labels.
First we need an industry agreement on the non-broadcast media encoding, followed by a standards document. The standard can be done at SMPTE.
Who would be the partners for such an agreement?
I respectfully disagree. 🙂
The ITU BT.709 spec is very clear on this:
Exhibit A: Approximate gamma 1/1.95 is for cameras (in the rare case the camera works in reference conditions).
This is probably from where many got the 1.95 value, but it's for cameras, not for displays.
See ITU BT.709 Table 1, case 1.2:
V = 1.099*L^0.45 – 0.099
Exhibit B: Gamma 2.4 is for reference displays. Footnote under Table 1.
(1) In typical production practice the encoding function of image sources is adjusted so that the final picture has the desired look, as viewed on a reference monitor having the reference decoding function of Recommendation ITU-R BT.1886, in the reference viewing environment defined in Recommendation ITU-R BT.2035.
And BT.1886 uses gamma 2.4: See BT.1886 Annex 1: γ: Exponent of power function, γ = 2.40
BT.1886 also notes: This value has been shown to be a satisfactory match to the legacy CRT display.
This is for broadcast.
The media code here 1-1-1 is always set for the camera encoding, not for the display encoding. You might find that weird, but there's one media and many different display viewing conditions for that media:
To display the broadcast media on a TV in reference viewing conditions, without any color conversions of media or display, a BT.1886 setting (gamma 2.4) is the best match.
To display the broadcast media on a computer display in an office environment, without any color conversions of media or display, an sRGB display (gamma 2.2) is the best match preserving the creative intent.
If your media is not intended for broadcast, the above doesn't apply.
This is an excellent presentation, Lars.
Glad you like it.
Unfortunately knowing the problem here doesn't solve the problem.
It only tells you where the pain is coming from.
It seems there are a few options for a solution:
Options 2 and 3 are similar. The main difference between options 2 and 3 is where the gamma conversion is done. In 2/ it's converted in the player (from 709 gamma to QT gamma). In 3/ it's converted on the server side before AVC/HEVC compression. Option 3/ will require double the amount of server space if you provide both broadcast and QT delivery.
Guess which option I prefer?
One thing is unclear to me: Is this only a 709 problem? Or do we have the same gamma problem for HDR content, such as playing PQ media? Do you know?
* This is not new. Already 60 years ago, analog TVs included circuits to preserve the creative intent (apparent contrast) (crudely) when the room light or the brightness control changed. Color management as we know it now wasn't required.
Your comment up above about the 1.95 being the Rec.709 camera transform/gamma function and not the display transform/function is really the crux of the problem.
With the Apple ColorSync using that for the display transform, and so many Apple devices out there, it's really botched up an already whacked system.
If Apple would properly apply the full "updated" Rec.709, which includes Bt.1886 giving the camera transform/gamma function, then the NLC tag of 1-1-1 would work as expected on the majority of screens of any type out there.
If they don't ... I don't see there is a "fix" anyone else can apply. Which is not the answer anyone wants.
As far as PQ/HLG/DolbyVision, that seems to in general be following the standards. Although some monitors have naturally screwy applications of them as is to be expected. But from the discussions I've seen online, if the grading/editing app gets the proper data in the file, screens tend to use them in displaying the content.
Now, users are screwing up by the numbers in getting the proper export settings it doth seem. Even colorists have lengthy discussions on how to get proper metadata in a file for PQ or HLG from whatever app they're using. And at times, the "proper" setting can even be affected by the format/codec chosen for the deliverable.
So it takes practice and testing to get the proper data into the file. But once the user gets that established, the screens do their thing sorta the way they're supposed to. Which is as its ever been.
DolbyVision ... now that's the beast of the different color. It takes a fully compliant system from the app through the display devices. And the setup for that is very, very complex. Not many of us gonna be working DolbyVision anytime soon methinks. My friends that do, do their work on upwards of $80,00 of highly specialized gear by the time you add in all the monitors, screens, breakout-boxes, computer, Dolby gear (for some things) and calibration equipment.
Or they move into a rented fully compliant Dolby suite for a particular job. As even for a pro colorist, unless you're getting paid well to do routine Dolby deliverables, that extra $40G to $50G in gear is simply not an acceptable business expense.
Now, having seen in person what it's like to work with say a Flanders 310 HDR monitor and full DolbyVision, yea, I want that bad. But ain't no way I can justify the full cost to setup for it.
And well ... yea, I can work in Resolve ok. But I'd prefer PrPro. And it's got some needed changes yet before it seems fully setup for a range of HDR workflows.
Getting some of the pieces ... the Rec.2020 for PQ/HLG timeline settings is good. Getting scopes in the spaces is good. Getting a more solid monitoring setup is coming soon I hope. It sorta seems to work, but ... I'm not so fully confident I can get it accurate. And still working on how one would export properly also.
But partly, that's because of me. If I'm not completely totally absolutely certain and can prove something, I don't fully trust it. So if I'm still figuring out how to prove I've got something correct, I can't be certain, can I?
Copy link to clipboard
Removed this content as it was just quoting Lars, who's now come on here with the exact same content.
For unknown reasons there was a long delay (several days) between me posting and the post showing up. Maybe my answer had to be inspected by a moderator?
Glad you're posting now though!