Premiere Pro still not color matching After Effects (using EXR files)

[MikeCurtis_1138]

The Problem:

EXR file sequences still aren't matching when using Lumetri Scopes in After Effects (v16.0.0) as compared to Premiere Pro (v13.0)

Proof:

I built a ramp of squares (W/R/G/B) using solids in After Effects from black to super white. It looks like this:

It shows in the Lumetri scopes like so:

I'm leaving the pop-up open to show I'm using Rec2020.

If I export that composition as a single EXR frame and re-import it (after setting the Interpret Footage color management to match the working color space of Rec 2020 Gamma 2.4), it is a very close match:

There are slight illinearities - if you want to see the differences better, here's an animated GIF:

Animated GIF - Find & Share on GIPHY

So I know my setup can "eat its own dog food" and still match....pretty much.

Now I pull that same exported image into Premiere, fire up Lumetri Scopes, and I get this:

OK, very very different result. Note that the AE scopes show straight lines through the R, G, & B targets, whereas Premiere rotates red and blue counterclockwise on the color wheel, but green further clockwise. I'm guessing this is a color space assignment issue, but I don't know. What I do know is that it doesn't match between the two programs, and this is a problem as I'm doing color work in AE.

For kicks, I pulled the frame into the latest Resolve (15.1.1.005), and it agrees more with After Effects:

It is hard to see here, but in the lower left vector scope, the lines go through the RGB targets (was set up for Linear color input, Rec 2100 ST2084 output)

Continuing to scratch my head, I exported the image from Premiere back to another EXR file, brought it into AE, re-assigned the Rec2020 gamma 2.4 color profile instead of the default sRGB, and the scopes are identical to the AE original comp.

Just for kicks, I exported from Premiere, re-imported into AE, assigned the proper working color space via Interpret Footage, and it is a dead-on match for the exported from AE version.

In case anyone is wondering, here's the AE settings:

...and yes, I tried the new Enable Display Color Management option in Premiere's preferences, it changes how the image looks on screen but doesn't make the Lumetri Scopes twitch in the least - it only affects on screen display, not how scopes interpret the values.

What I glean from this is that the color values aren't changing as they are interpreted and then re-exported through Premiere, they are just being understood by Premiere as something different.

I'm using EXR files because I'm doing HDR work and it is my best lossless path. If there is something that matches better and is still high quality and HDR, I'd love to know about it.

Thanks for any input or guidance,

Mike Curtis

(who had similar issues with the last set of releases)

[R Neil Haugen]

I think this needs Wes Howell or another color staffer.

Neil

[chrisw44157881]

one staffer said premiere dumb interprets anything in premiere to rec 709 gamma 2.4,

the monitor mangement is only a semi-converted passthrough if your monitor isn't rec. 709. it's supposed to match your monitor profile but not exported media. Ae doesn't burn out color management too unless you use effect color profile converter.

let's say your monitor is rec.709, then theoretically, the color management button clicked on and off shouldn't change anything(if your monitor isn't a specially calibrated rec 709)

My tests seems to support premiere is rec 709 gamma 2.2 but adobe staffers are adamant its 2.4. So, watcha gonna do? Trust something that doesn't work or work around it to match stuff correctly yourself. I prefer 100% matching stuff myself.

and for the record, i've been complaining about the lack of congruity of rec 2020 scopes with a rec 709 color engine for a long time. it's kinda a silly implementation and actually a bit embarrassing trying to hock in a fraction of technology so you're 'hdr' ready.

[R Neil Haugen]

Here's an explanation of the new enable display color management option and what goeth on under the hood.

Neil

.............

From Lars Borg, chief color engineer, Adobe PrPro

["CM" refers to the new Color Management option in the Edit/Preferences dialog.]

- CM off is great if your screen matches the media on the timeline. Works well for Rec. 709 and sRGB and YouTube delivery.

- CM on is useful when that's not the case, and you want your display to reproduce the color appearance of the timeline on a reference monitor.

As always, this assumes your display is reasonably calibrated or characterized.

Examples:

1. Timeline is 709, display is P3. Without CM, the display appearance would be too saturated and would not match your export.

2. Timeline is 2020, display is not 2020. Without CM, the display (709, sRGB, or P3) would look washed out and would not match your export.

3. Timeline is 709, display is sRGB. With CM off, the display will match what a YouTube viewer will see on her sRGB display, which will be slightly washed out (gamma ~0.9) compared to a 709 reference monitor. With CM on, the mid-tones on the sRGB display should match a 709 reference monitor, but some shadow details are lost, as 8bit sRGB encoding in the shadows don't have the fine granularity of the 8-bit 709 shadows; the 20 lowest 709 codes are crunched into the 7 lowest sRGB codes.

4. Timeline and display are both 709. No need for CM, it should make no difference, turn it off.

On loss of values [point 3 above]:

The 78 lowest 10-bit 709 code values are crushed into the 28 lowest 10-bit sRGB values

10-bit 709 codes 0 to 14 are mapped mathematically to 10bit sRGB code 0 (if rounded to nearest).

But most sRGB displays are only 8 bit, so:

The 19 lowest 8bit 709 code values are crushed into the 7 lowest 8bit sRGB values

8bit 709 codes 0 to 6 are mapped to 8bit sRGB 0 (if rounded to nearest).

Some video cards might use floor instead of round:

8bit 709 codes 0 to 8 are mapped to 8bit sRGB 0 (if floor is applied instead of round)

The 78 lowest 10-bit 709 code values are crushed into the 8 lowest 8bit sRGB values

10-bit 709 codes 0 to 26 are mapped to 8bit sRGB 0 (if rounded to nearest)

10-bit 709 codes 0 to 35 are mapped to 8bit sRGB 0 (if floor is applied instead of round)

Many displays are "sRGB-in-name-only", SINO. Even when calibrated to sRGB, a SINO display can be off target, as most calibration tools take very few samples. So a SINO display might show less details than what's represented in an sRGB encoding. (Remember 6-bit displays?) However, the detail loss would be there regardless of CM on or off.

Just for comparison:

When exporting 8-bit full range RGB to 8-bit narrow range YCC, around 83% (5/6) of the original code values are lost (even before chroma subsampling). The result is similar to losing the last bit in 8bit RGB. The losses are spread out evenly over the entire color volume, each mapped to nearest neighbor, so it's it's hard to notice in most cases. It can show up as banding, especially in dark gray skies.

[chrisw44157881]

*after reading a few times as he goes full blown engineer, it seems I was right all along, even the shadow noise dynamic range issue. teehee.

another thing I forgot to mention,(which is a biggie for EXR) you're ok as long as you don't use lumetri luts if you want to keep rec. 2020 color. lumetri luts(hdr checkbox off) will clip your color gamut down to rec. 709 permanently upon import. something to be aware off.

this color management feature is actually going to confuse even more people because they will think it will smart-gamma know about web delivery gamma specs. Now, every single ICC that isn't 2.4 is going to be wrong for web and there will be many threads about this. Why couldn't adobe simply make a web gamma-checkbox, how hard is that!

-addendum

how does this affect Mercury transport and Dynamic link ? same way?

[MikeCurtis_1138]

chrisw- you wrote:

"one staffer said premiere dumb interprets anything in premiere to rec 709 gamma 2.4"

...which MIGHT account for the color shift - since the Rec2020 primaries are more intense and in different places:

Looking more closely at the above image - blue is nearly the same direction in 2020 as 709, red is a bit off, green is way off - this correlates to what I'm seeing on the scopes. Huh. If that is the case, this seems like a full stop and give up on trying to get colors to match between AE & Premiere.

Neil - thank you for your time and effort on this. The new CM option seems to be purely for how to display an image, not how it shows up on the scopes - enabling and disabling (even after a relaunch of the app) makes no changes to how the image shows up on scopes, even though it changes its appearance on screen. So I don't think that is a useful area of exploration for this problem (although it is relevant to the whole color correction issue in terms of WYSIWYG).

So, Wes Howell - you out there?

-mike

[Wes Howell]

Hi Mike,

Rec2020 EXR files are not currently supported as part of a Rec2020 workflow in Premiere Pro. 

An AE workflow is currently recommended for this scenario.

We are looking forward to continuing and expanding our support for various formats and related workflows.

Wes Howell

Premiere Pro Quality Engineer

[MikeCurtis_1138 · Accepted solution]

OK - so it appears that there is a Rec 2020/709 discrepancy going on here, at least for EXRs. While there may be other formats that work as desired, EXR, with this version of Premiere, isn't doing what I'd want it to do.