Possible Bug encoding video from ProRes 422 and "lower" in Premiere Pro 13.1 on Windows PC

If you're transcoding, either the DNxHD format perhaps with HQ codec, the Cineform, or ProRes 422 or better would work fine.

I'm not sure of the reason you hate proxies, so would be interested to hear of ge trouble you see with that process.

Neil

Interesting watching this, and as expected ... it's from a Mac, almost guaranteed to be using a Retina monitor, which is Apple's interesting, pretty, and completely off-the-wall color space. Remember that Premiere is designed to be used with a Rec709 broadcast standard viewing situation for accuracy. Standard pro broadcast, pretty much world-wide, is video sRGB/Rec.709/gamma-2.4/brightness-100nits.

So ... yea, you get differences because you are not working with the same color space & profiles to begin with as the program is built around. Plus there's been an apparent issue with one or two of the ProRes export codecs being off just a bit (mostly in PC's though, I think), which could be feeding into this.

Let's look at the Apple P3 Display color space.

It's kind of cool actually and the monitors are sure pretty. It's how they do the color math that causes issues.

The P3 color space is nifty, about 20-25% bigger than video sRGB, and more colors are more better, right? The handiest thing about the P3 space compared to say A-RGB is that it isn't mostly increasing color off to one or two sides, but pretty much around the wheel. It's really a more natural fit to move into for wider color gamut spaces.

They kept the D65 white-point of Rec.709, rather than the D60 white point of both other current P3 spaces, Theater and Cinema. So ... that's the same, easy to match.

There is no brightness stat though ... so ... however the monitor is set for brightness, well, you don't have a number to calibrate TO that I can find. HDR doesn't have a regular brightness but is set in the file header for each exported file. So there's a probability for variations between "right" on this or that P3 monitor depending on how the brightness is set. A change from say 100 nits to 200 nits creates a massive tonal shift, and as you shift Luma values, you shift perceived Chroma values also, especially perceived saturation.

That's one issue, and not an easy one to plan around, sadly.

The other is worse ... the gamma. The specs say 'sRGB' and  when you go look that up, it's actually a complex transformation curve applied to smooth the shape between the three separate gamma formulations that are used in different parts of the curve, roughly similar to but not actually like gamma 2.2.

But from extensive testing, Apple isn't actually applying the expected 2.2-ish-sort-of gamma within their systems, and I'll quote Lars Borg, chief color scientist for the Adobe video apps ... apparently Apple only applies half the gamma-equation expected from other systems:

“AFAIK, Apple uses the inverse 709 camera transfer function,

approximately gamma 1.96, so the video is displayed as captured

by the camera, without the TV system gamma being applied.

This decoding is apparent in Apple's ICC profile HD 709-A.icc.

We see a lack of contrast when

compared to the same video shown on your TV.”

So, when Apple says " gamma sRGB", they don't mean what all other systems expect them to mean, but something very, very different.

As color engineer Francis Crossman put it in a post on this forum, their testing of the method needed to get a proper image (measured data levels) out to achieve a "perceptual match" on an Apple P3 screen, with an inverse LUT to re-create the proper Rec.709 levels back within Premiere, required the use of the 1.96 gamma conversion LUT as noted from Lars' earlier comments on color handling within the Mac OS. Francis posted links to those two LUTs in his post on that matter with Carolyn Sears that appeared on this forum a couple months back.

That 1.96 "scene-referred" gamma lifts the shadows dramatically from the 2.4 that Premiere is designed around. And also means the saturation is oft perceived as lessened. But wait ... it's compounded. Using Premiere on a P3-Display monitor, without corrections, means that the values for color are quite a bit farther "out' than they would be on a Rec.709 monitor. So naturally, one pulls saturation "in" to where it looks correct. But it's not. You've excessively desaturated the image to make it look good on an incorrect monitor setup.

Now ... export that file, and display it on the P3-Display screen. You've got lifted shadows and gee, that saturation is low. Even though the P3 screen is trying to map things farther out than the Rec.709 image started out as being, because you set saturation too low in order to "look" correct, all due to the app/monitor color space mis-match.

The use of AfterEffects here is purely to get around a monitor color space mismatch.

So the problem that you and virtually all of us face is a rather difficult one. The "standard" for all broadcast around the world for quite some time has been video sRGB/Rec.709/gamma-2.4/brightness-100nits. The vast majority of screens are still Rec.709 for both TV's and computers. Premiere is built around working within that ecosystem. Use Premiere with a monitor properly calibrated with puck/software ... and then profiled to check the accuracy of the calibration, and Premiere will give precise and accurate tonal and color work. You can export to work in Resolve or Avid and it's perfect.

We now have HDR coming in, and that throws ANOTHER color space and brightness range in. Yea, it ain't getting simpler.

But the Macs don't have a built-in process to 'tag' and properly display Rec.709 media within that wider, and often brighter, color space and profile they use. And producing media with Premiere on a standard Mac P3-Display space monitor requires the use of the Edit/Prefernces/General option "Enable Display Color Management" ... which attempts to modify the internal monitors of Premiere to display a correct Rec.709 image in a monitor that is NOT in Rec.709 setup. It ... sometimes ... works.

But not for what so many users think. This option means you have a better chance of getting a proper Rec.709 image to view when played on other broadcast systems. Not to export and view in say QuickTime Player in the P3 Display space. It won't be the same at all.

Next, there's another issue here, and one that most Mac users seem to think ain't a problem. That is ... something that looks "perfect" on your P3 monitor in its native P3-Display color space will not look the same, nor particularly good, on screens not in the P3 Display space. "But everyone who views my stuff will be on Macs also ... "

Think of Mac market share. In the US, Mac use is up to almost 13% of computers/devices. Worldwide, it's only around 7%.

Understand, the vast majority of potential viewers do not have a P3-Display screen. So they will not see your material anywhere near the same as you do. And with QuickTime player not even available on the vast majority of screens out there, QuickTime will not be the main player used, either.

I heard a colorist at NAB talk of a major mess his shop had been dragging through. Large corporate client/project, involving both broadcast commercials and web distribution of media. And the 'big boss' who had final say was far too important to waste time attending the grading sessions.

He of course had a hot new Mac with that pretty Retina screen, and when he saw it, insisted on changes so it would look "hot" on his screen. Was not interested in any stupid explanations.

So ... first re-grade of entire project. A couple more weeks, high-priced employees hanging around the grading suite.

Approved by Big Boss, sent out to broadcast ... and rejected everywhere. Big Boss upset. Then many web users were complaining of bad view of project. Boss very upset. Finally listened to explanations, and ... they went back to the original grade, sent off to broadcast again.

Accepted ... naturally.

For web use, they set the new grade a bit more 'intense' for color and brightness than for broadcast, and ... it was ok on Macs, not too bad on everything else. Not perfect anywhere mind you except by accident, but ... that's Life.

Sadly, there isn't any real "standard" that every media will just work on any more. Your P3 display is a beaut, really. But what looks good on that won't look nearly as good on my broadcast-standard setup. Nor most PC's and phones.

But then, nothing any colorist ever puts out ever looks the same on anybody else's system. It's just Life.

So what do we do? Yea, good question. I'm not one that thinks planning on delivering for the smallest market is the best option, but hey ... we're all different.

Neil

For comparison reasons, in Premiere Pro on a timeline, switching between the layers. So same player, same Display, same sequence.

If I take a video, which is half a black screen and half a white screen, black becomes dark gray through exporting from ProRes 422 and lower to another format, white becomes light grey. And it is cumulative. If I encoded the video from ProRes 422 HQ, to 422 to LT to Proxy, these 4 steps would make the black really a lot lighter and the white a lot darker.

It is not the "actual color representation", the problem is the degredation through encoding, and only from ProRes 422 HQ and below.

I could encode 10 steps in DNxHD or H264 and black would stay black, white would stay white.

Not so with ProRes on Windows, and ONLY in PP 13.1. In 13.0 everything is fine.

I suggest ONLY using max bit depth if you have no GPU, as if you do, it's already computing in max bit depth ... and can occasionally cause wonkiness like this. Just leave it off.

Max Render Q is also something that can help if you're doing major resizing within the sequence. If not ... leave off.

Neil