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

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

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.

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.

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. 

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?

Thank you for explaining. I'll have to update my system so I can run Premiere 24 because those changes really sound worth it. I started viewing random video files on my mac and comparing them in Quicktime and VLC to see if theres any difference or if its just videos I've exported from Adobe software. To my surpirse its every single video, totally raw videos that were never imported or exported to Adobe. Every single video I watch has a different gamma in Quicktime vs VLC. So is that just because of Mac's Color Utlity controlling Quicktime? Its just crazy to me that the same file will never look the same between those two programs. 

Some screenshots I took. QT on Left. VLC on Right.

I work for/with/teach pro colorists. So I've been through HOURS of presentations and discussions on this, in person and over zoom/whatever with high-end colorists. And with the people that make the calibration software used by the colorists.

It annoys and pisses them all off, btw ... but at Apple, who created this mess.

And as Fergus and other staffers will point out, Adobe has given you some good new options in 24.x. But before you choose, you need to know what happens depending on your choice. As in ... you get to pick your poison. 

So have you read through the many threads on here alone, discussing the issue? Simply put:

• The broadcast/streaming/professional standards for Rec.709 media include Bt.1886, which suggests using a display gamma of 2.4 for Rec.709 media, 2.2 allowed as a choice, for web-destined media. Premiere has 'natively' followed the professional standard.
• Your Mac is using an Apple utility called Colorsync, that is designed by Apple, and uses a display gamma for Rec.709 video of 1.96.
• You cannot display a video file at two divergent gammas and get the same view.

Even though it's the same file, it will look different if you use two different gammas for viewing it. Well, that's pretty obvious, right?

Which leads to the following:

• If you visually correct the file to look "correct" diplayed at gamma 2.4, it will look too light and a bit desaturated on a sysem using 1.96. (What you've been seeing it seems.)
• If you visually correct the file to look "correct" displayed at gamma 1.96, it will be too dark (crushed blacks instead of shadows) on a system using 2.4. (What I would see on my correct broadcast-type setup for a file set for gamma 1.96)

Neither option is what any of us really wants, sadly.

New for the 24.x Major Version Builds

In Pr 2024, you have a much easier color management setup in Premiere. Go to the Color Workspace, Lumetri panel, the Edit tab. 

All CM options for the program are in the various sub-tabs. Including several new things, so you should look through it in general.

Especially for Macs in 2024 (though of good use for all users)

There's a new option for setting the Premiere display gamma. With three settings available, which will set the Program Monitor of Premiere to the gamma you select.

• Broadcast 2.4 ... this is the general standard for professional Rec.709 deliveries worldwide.
• Web 2.2 ... this is allowed in the standards for use with web-only deliveries.
• QuickTime 1.96 ... this sets your in-Premiere display gamma to match the Mac  Colorsync gamma of 1.96.

And this is the pick your poison choice. Where do you want this to look "correct"?  As you can't have a file that looks good at "proper" gamma 2.4 and at Mac gamma 1.96

Adobe can't "solve" this, though they've given you choices now. BlackMagic can't solve this, they give you similar result choices. No colorist can solve this. Only Apple could 'solve' this for all users across platforms.

Any updates on this? Ive been having this problem for about a year or two now. Happens whether I export from Premiere or After Effects. Exported footage looks totally fine in VLC but totally washed out in Quciktime on my Mac Mini. Then sent it to my Macbook Pro and its the same thing. I even tried viewing it on my iphone and it was washed out there as well. So the only time it looks okay is in VLC or if I bring the footage back into Premiere or After Effects. So essentially nowhere that someone is going to view the video when I send it to them. This is so infuriating. And I see so many solutions that are just adding new LUTS to correct this gamma change (or whatever it is) but if or when this issue is ever fixed, then that footage with the lut is going to look too contrasty. So do we just make 2 separate exports of all our videos now? One how it was originally graded (but will be washed out in Quicktime and all devices but look correct in VLC). And the other one with the corrected edits/lut (will look correct everywhere except VLC and if you drag back into Premiere/AE). I don't understand how I've never run into this issue with 10-15 years of editing/coloring experience, or has it really just flown under my radar?

That would be appreciated, Fergus! And there's a lot of us that will be very interested in what options you may add.

I know quite a few want to be able to easily mod the files to get around the Mac display issue. And well, if someone wants to, and understands the other problems that choice may cause, it's their file. I'd always go for more user options. (No matter how wise they may be at times in certain uses.)

But then there's also issues with cameras that can be set to do full range with YUV files, or people running their monitors in full ... so again, user settings there could be of use to many people.

But anyway, looking forward to seeing some further options.

Neil