Should Premiere Tag Exports as NCLC 1-13-1 when using Gamma 2.2?

[jefftypebeat]

I'm very happy that premiere is overhauling color managment. I work on macos primarily for videos for the web. I set my projects to 2.2 as this is known to be a good compromise for most devices (it will look accurate for sRGB displays and only have a small 1.96 to 2.2 difference for most macos users). 

But exports still are tagged as NCLC 1-1-1 when i'm working in gamma 2.2. Shouldn't they be tagged as 1-13-1 or 1-4-1 (1-13-1 for sRGB seems more supported than 1-4-1 gamma 2.2). I've seen some suggest that YouTube has started supporting those two tags.

When re-tagged as 1-13-1 exports would match premiere's GUI program in quicktime. Ideally frame.io's web app could also be updated to support these tags on macos.

Right now, is the only way to get client's to consistenly approve color to set Premiere to 1.9 Quicktime gamma, upload to frame.io (file has 1-1-1 tag and that's what frame shows), and live with the export being a little crunchy on sRGB displays?

cc: @Alexis Van Hurkman for your wisdom! (thank you so much for all your work!!)

[Alexis Van Hurkman]

Since Premiere Pro doesn't have a setting for outputting sRGB, I assume you're setting the Viewer Gamma to 2.2. Keep in mind that, in the context of grading and delivering Rec.709 content, the Viewer Gamma setting is for choosing the appropriate gamma for your viewing environment, while the exported output remains Rec 709 (which assumes a signal being played on a display using the BT.1886 EOTF). So, the tagging applied to the exported output and the Viewer Gamma setting are not linked, and the Rec 709 tag that's currently being output is intentional.

This is the intended workflow, as the viewer gamma setting is about making sure you're looking at the image in a way that accounts for the viewing conditions — 2.2 is for a display in a brightly lit environment, while 2.4 is for a display in a dimly lit living room environment. But the same Rec.709-encoded signal is shown in either case. This is how these gamma standards are intended to be used, the idea being that perceptually an image displayed with gamma 2.2 in a brighter ("office") environment will look the same as the same image with gamma 2.4 in a darker ("living room") environment. And in all cases, a Rec.709 signal output via Transmit to a calibrated external display in a reference viewing environment should look identical (assuming the displays are set up identically).

Secondarily, the Viewer Gamma setting helps make sure that the Premiere Pro viewer matches the viewers of other applications (that make different, non-adjustable gamma assumptions) on the same machine, so you can verify client feedback based on what you know they'll be looking at on their computer's display (such as QuickTime).

We're working to make the monitors in Premiere Pro function more as external monitors would, with the different adjustable settings one would expect to make sure you're seeing what you need to be seeing given any one of a host of workflows. Some are automatable (viewing format) while some are not (viewer gamma) as we don't know your environment.

Hope this helps!

[jefftypebeat]

Thanks for the reply Alexis!

Your explaination makes sense and I totally missed that nuance of the viewer gamma not being linked to the outputted file. I've seen a lot of people suggest exporting as Rec. 709 Gamma 2.2 (or ~sRGB) to be a better way to deliver project intended for web delivery. That's what this (infamous) video recommends: https://www.youtube.com/watch?v=1QlnhlO6Gu8 -- My understanding is that 2.2 is a good compromise between the (potentially, maybe contraversially) over-estimated surround compensation of colorsync on macos and iOS (gamma 1.98) and the lack of color management on many Windows machines.

[There's also the argument that 1-1-1 is the incorrect NCLC to use for Rec.709 Gamma 2.4 content and 1-2-1 with the gamma custom tag should be used like how Resolve tags files. But I guess the reasonsing isn't important] 

But I really don't want to act like I know my way fully around this technical hurdle. I guess the next question would be if there might be a way to add a Gamma 2.2 Rec709 output option. Potentially tagged as 1-4-1 or 1-13-1. 

[Alexis Van Hurkman]

We're exploring other options we can offer to cater to other workflows, and it's good to see what you're referencing. This is a complicated subject with many, many (too many perhaps) opinions, and we're treading carefully and trying to adhere to standards-driven approaches.

[jefftypebeat]

Thanks Alexis.

Thank you for walking through this. I know you've probably explained all this a million times.

An additional question: What does enabling "Display Color Management" do on macOS? And how does that relate to how I set the viewer gamma?

Premiere does seem to be color-managed through colorsync when "Display Color Management" is enabled, which does make sense. Does that mean it's telling colorsync what color space and gamma it's operating in? Does it always basically tell colorsync that it's operating in rec709/bt1886 and the viewer gamma is more like an offset? 

I understand that my viewer gamma should relate to my display enviroment. That if I'm editing in an office-like enviroment, setting my display to 2.2 gamma is ideal versus a dark enviroment for 2.4. But it's confusing to me to have both colorsync and the viewer gamma selection trying to compensate. In a weird way shouldn't it always look the same if premiere tells colorsync which gamma the viewer is set for and coloysync transforms whatever premiere is set to to the display (like p3/2.2)?

Let me know if I'm asking all the wrong questions.