QuickTime gamma shift [Prevent color shift on export from premiere on MACOS]

[FeedbackCommunityMember]

A common issue I've seen here. When exporting a sequence from premiere the color shifts dramatically in the majority of playback programs. Quicktime, Vimeo, Youtube etc. VLC works fine but not everybody is using VLC. Makes for lots of wasted time on color grades.

Comments from Adobe below

This is an issue we (Adobe) are aware of. The best desciption of this issue is in this article and the related video: 
https://www.todddominey.com/2021/01/24/why-are-videos-washed-out-on-the-mac-exploring-quicktime-gamm...

A feature for handling this issue - adjustable Viewer Gamma - has been added to Premiere Pro v24 and is explained in this documentation: https://community.adobe.com/t5/premiere-pro-ideas/quicktime-gamma-shift-prevent-color-shift-on-expor....

Fergus

[R Neil Haugen]

Yup. It's actually totally because of Apple choosing to be so Apple, and do their own thing different from everyone else.

I don't really care which is used, like most, I just want one SINGLE standard used! 

Ah well ... we aren't getting that anytime soon. A couple noted colorists I've listened to even have "connections" in Cupertino, and mentioned this ... and got total stone-wall. Wow.

So VLC can actually be handy, in a practical sense. Look at something in QuickTime player, and in VLC. When you get to a usable image in both, well, you've probably got something ... well, useful across platforms, eh?

[FSR_Industries]

The ongoing nature of this issue blows my mind. Resolve include the correct tag in the metadata so the exports are viewed correctly on whatever they're viewed on. In a world where some people have Mac, some have PC, some android and others iPhone, simply adding some saturation and contrast or adjusting the viewer gamma for what it'll be viewed on, is completely pointless. You're just panda-ing to one set at the expense of another. Resolve includes the tag that allows whatever the viewer software is, to recognize how it needs to display the content, so it always gets displayed as intended. I'm no coder, but why is one of the "big two" having such a hard time with this? Adding all these half-baked fixes just kicks the can down the road. Maybe Adobe should delay the next release a year or two until they can actually put a fix to this, or at the very least tell us why it's so hard to do. Then we can all get on with the shift to resolve (which I've done for much of my work - though I admit, resolve doesn't offer the most practical solution for fast turn around work in remote places, but that's another discussion). There's no two ways about it, resolve does colour better. Its time we saw ye olde faithful, premiere, offering a professional solution to this issue. I'd argue that nothing else, feature wise, matters to creators more than this right now. Put the AI tools down and fix the foundation before bolting more bells and whistles on. This is genuinely enough. 

[R Neil Haugen]

How I wish your comments were correct and totally accurate. But sadly, they aren't. They are a commonly published misconception, and as often blown out of the water by noted color specialists.

I work for/with/teach pro colorists. Have for years. I've been around hours of discussions on the issue. And have seen several "this is the absolute fix" claims been easily blown out by color calibration professionals.

You're talking about the notion that simply applying "correct" NCLC tags "fixes" the issue. Well, like every other potential fix, it "fixes" on some things on some systems but never all things on all systems.

Part of the problem for an NCLC based "fix" is that they aren't comprehensive ... sadly. So this uses a number technically listed as not-set to anything, that on some hardware and software combinations is read as "X". But on others, ignored, because it technically isn't set to anything.

And for the record, yes, I wish we could control the tags in Pr, I've argued for that for years with their chief color scientist. Not because that is any complete fix, but because it allows some users better chances for their particular needs.

And I was just through another round of a "this will fix things" program for colorists, that yes, included the NCLC tags ... and in the follow-on discussions several colorists were able to show how it still doesn't fix things even across all Macs.

It gets back to a few things ... first, you simply cannot change physics. When Apple went with the camera transform instead of the "by the book" display transform for their internal color management, it caused the whole mess. Using two different display transform processes cannot possibly result in the same viewed image. Period.

Trying to use NCLC tags ... which are themselves 1) incomplete 2) inconsistent) and 3) ignored by too many hardware and software bits in use ... is trying to fix the issue after the cow got out the gate. 

And saying that any software provider has made a total complete in all-cases fix is simple balderdash.

And yes, I work in Resolve Studio daily, have for a decade. I've tried and tested all this stuff myself. I'm working up several tutorials at the moment for a pro colorist's subscription site on working in Resolve ... the people I work for/with/teach, some of whom were the earliest adopters of DolbyVision in "boutique" post houses, and were hired by DolbyLabs to produce Dolby's in-house training video series for DolbyVision.

[R Neil Haugen]

The problems with Apple's color "system" on non-reference mode Macs is apparently two-fold.

First, there's a tonal component. That's the mostly sort of gamma issue, though it's technically a combination of the "power law" function math used, and the short gamma section, that are both incorrect for display transforms in Rec.709.

This is where Apple uses the "gamma 1.96" figure ... and the accompanying math formulation ... rather than the correct, long-established Rec.709 standard for both.

Why? They did publish a comment in a tech paper some years back that this was the 'correct Rec.709 transform' ... because it was original ... but the problem with that is pretty obvious. That was the camera transform so that digitally created images matched decently on the displays of the time.

But the display technology had changed! And that had led to the Bt.1886 addendum to Rec.709, so that on the newer tech displays the old media still worked, and newly created media also worked. It's a double "trick" which in some ways would be nice I suppose if it wasn't there, but 1) it simply works and 2) the whole system breaks with any changes to it.

NOT GOOD.

Second, as one rather amazing bit of sleuthing has shown recently, even if you master the math to match the tonal transforms for the Apple display. that doesn't fix the saturation issue.

Which isn't actually a saturation thing, technically. Saturation is very definable in mathematical terms. It's a chroma issue ... a color issue.

The actual problem is the remapping of hues Apple uses, on non-reference mode Macs, to fit on the screen's P3 'native' color system. It's flawed.

The demonstration of that flaw was fascinating, and has been supported by numerous others testing it that I've seen. To actually, correctly, remap the chroma values between 'standard' Rec.709/sRGB to the math the Mac uses, requires an additional transform process on chroma data only.

So simply changing NCLC tags can't totally fix the "issue" because there are two issues, neither of which NCLC tags works for on all systems.

[madebysixteen]

I made this video on how to correct the problem for make videos for phones, computers, etc (non broadcast). The setting you need to change is in Lumetri Color > Settings > Project > Viewer Gamma > Quicktime. Make that change and your colors in PP and in your h.264 export will be the same. https://youtu.be/QirnkZA0ZUY

[R Neil Haugen]

That is good advice if you work on an Apple computer without reference modes for the monitor ... but it may not give the best image on most other gear.

Sadly.