Color Management Still Not 100% Accurate on Wide Gamut Monitor

Report · Oct 16, 2018

Hi All,

I was very excited to hear about Color Management being added to Adobe Premiere Pro CC 2019. I can confirm that color and/or gamma shifts are improved when "Enable Display Color Management" is checked under Premiere Pro CC > Preferences > General. There is still, however, a slight variation between what is seen in the Premiere Pro Program Monitor and what is exported by Adobe Premiere Pro CC 2019 or Adobe Media Encoder CC 2019. To the naked eye, the exports from Premiere Pro and Media Encoder seem slightly washed out when played back on Quicktime, YouTube on the Safari Web browser, or on the YouTube app on the iPhone XS Max. VLC Media Player over-saturates and shifts the colors even more. I am running the latest version of Premiere Pro Version 13.0 (Build 225) on a 27-inch Late 2015 iMac with a 5K Retina display. My processor is a 4GHz Intel Core i7, my Memory is 24GB DDR3, and my Graphics Card is an AMD Radeon R9 M395X. Does anybody have any insight into what could be causing these color/gamma shifts, despite the new Color Management feature in Adobe Premiere Pro CC 2019 now supposed to make what we see in the Premiere Pro Program Monitor 100% accurate to what will be exported? I have included the variances below (please look closely) on a Premiere Pro-generated Bars and Tone graphic for reference. Thank you in advance for your help!

A Screenshot of the Program Monitor within Premiere Pro CC 2019:

An Exported Frame from the Premiere Pro CC 2019 Project:

Please notice:

1) The slight hue difference in the bottom left cyan color.

2) The slight hue difference in the bottom middle purple color.

3) The lighter shade of black in the bottom right.

A Screenshot of the Exported Clip, Playing Back in Quicktime:

Please notice:

1) The slight hue difference in the bottom left cyan color.

2) The slight hue difference in the bottom middle purple color.

3) The lighter shade of black in the bottom right.

A Screenshot of the Exported Clip, Uploaded to YouTube, Playing Back on the Safari Web Browser:

Please notice:

1) The slight hue difference in the bottom left cyan color.

2) The slight hue difference in the bottom middle purple color.

3) The lighter shade of black in the bottom right.

I understand the the differences here are very subtle and are rather hard to see in a Bars & Tone graphic on this website. These differences become much more noticeable with one's specific footage, however, and bringing these above graphics into Photoshop with the blending set to "Difference" shows the definite variance I speak of.

Thank you in advance for your time and assistance as we try to make Color Management seamless within Adobe Premiere Pro CC 2019.

Report · Oct 25, 2018

first thing I did, after realizing the panel was a fine instrument ( tight manufacturing tolerances for controls etc.), is put a kitchen towel over it when it's not in use. Keep dust out of track balls, etc.

Report · Oct 25, 2018

But doesn't even work anything in editing in Resolve? Huh. I've seen it demo'd for color in Resolve, it's pretty nice there.

Neil

Report · Oct 25, 2018

yeah, it's super nice there (in color). Very fine stuff. I only tested basics and doubt this panel will work anywhere else. I'm faster with keyboard and mouse anyway, for typical editing timeline stuff, so although I of course looked into it, it's only color and I can put it out of the way until I get there ( just have keyboard and mouse until then).

seems to work so far.

got off subject a bit.. sorry.

Report · Oct 26, 2018

Hi all,

Just a few updates for those of you who were closely monitoring this thread hoping for answers:

With the very generous help of Vlad and Francisco, we have determined the following to be true:

1) Color Management is consistent in Adobe Premiere Pro CC 2019 and After Effects CC 2019. This means that what we see in Premiere Pro's Program Monitor is exactly what we see in After Effects. Color management is consistent across apps.

2) Exports from Premiere Pro, Adobe After Effects and Media Encoder are not changed. Re-importing test exports into Premiere Pro and After Effects shows there is no difference in RGB values. This means that the actual export process is not causing any issues.

3) Exports uploaded to YouTube and then re-downloaded after YouTube processes the video file also showed no difference in RGB values once that YouTube file was re-imported into Premiere Pro and After Effects. This means that YouTube itself isn't incorrectly changing the video file at all. (YouTube is my primary end location for all of my videos.)

4) Color RGB values in an After Effects-generated Bars and Tone graphic appeared the same in QuickTime, Sarai and "QuickLook." Greyscale values do not. This is what is causing the visible "contrast" difference in the exported file from what I see within Premiere Pro/After Effects. This is the issue we are still trying to work out. This means that the colors we see within the Program Monitor of Premiere Pro and After Effects are what we will likely see across web browsers/video players. Greyscale values, not so much. I am yet to find a web browser or video player, that is displaying the same greyscale RGB values as what I see in Premiere Pro. This is what is so confusing to me.

5) Final Cut Pro (yes, I know we're comparing one video editor to another here, but this is a good example of the issue at hand) shows the exact same color RGB values AND greyscale RGB values as the Premiere Pro exports when importing the Premiere Pro-exported footage into Final Cut Pro. This means what you see within Final Cut Pro will be exactly what you see in color-managed web browsers and video players. We already know that Final Cut Pro is also color managed and that Rec.709 can be selected as a Color Space for a project file.

And so: Why can't Premiere Pro display these same color and greyscale RGB values? I am not so quick to accept the notion that Final Cut Pro is "wrong" and that Premiere Pro is "right" when displaying greyscale RGB values. Being able to explicitly select "Rec.709" as the Color Space within Premiere Pro and the lack of the option to do so within Premiere Pro (not pointing fingers here, just pointing this out), suggests to me that perhaps there is still something going awry with the way Premiere Pro is utilizing color management. Perhaps someone has an explanation for how Final Cut Pro is able to show the same color and greyscale RGB values as exports, but Premiere Pro is not? And how Premiere Pro video exports have the same RGB values when viewed in a color-managed apps and Final Cut Pro, but not when re-imported into Premiere? Thus far, Premiere Pro is the ONLY app that has has shown the greyscale RGB values that it has. No other app does. That's what I really need to figure out here.

Essentially, we just need to get the greyscale RGB values within Premiere Pro and After Effects to match what we see in other third party color-managed apps. The colors appear identical with nearly identical RGB values, but greyscale values still do not and, as mentioned above, Final Cut Pro shows the same color and grescyale RGB values as Premiere Pro exports without a problem. I hope I don't sound crass in saying "if Final Cut Pro can do it, so should Premiere Pro and After Effects."

As always, not playing the blame game here. Just laying out what I've discovered and pondering what could be causing what I'm experiencing. Thanks to all for your input and assistance!

Report · Oct 26, 2018

By noting that the difference is in grey-scale values, what I'm thinking is there is something that isn't read properly in the data range file header. The old style standard of tape days was 26-235, but currently many devices record 0-255 ... and some is 16-255.

Most colorists working b-cast still setup Resolve to work in 16-235. However, I've seen a colorist presentation saying to leave Resolve in the file-reading options to 'auto-read dynamic range' setting rather than 'apply 16-235'. Some codecs from PrPro come in correctly (some of the upper-depth ProRes) if you've set that to apply 16-235, but some don't.

I don't know why that is ... but I'm wondering if that is the issue here. Something that isn't being set or read properly for dynamic range would affect the grey-scale figures without necessarily affecting color.

Neil

Report · Oct 26, 2018

Hi, Neil.

Thanks for bringing this up. I'll admit that much of this is probably "way over my head," and I'm not sure if this even makes sense, but Digital Color Meter does show the blackest black value of the Bars and Tone graphic as R=0 G=0 B=0, and the whitest white value of the Bars and tone Graphic as R=255 G=255 B=255. (Please excuse any wrong terminology there.) This is true for both exports and the Program Monitor within Premiere Pro. Where values start to differ, however, are in the various greyscale values in-between. This is what is leading to a visible difference in perceived "contrast" between the Premiere Pro Program Monitor and the exports. Final Cut Pro X does not have this issue. RGB values are consistent within what is seen and measured within the app and with what is exported (and viewed on nearly all of my web browsers and video players). Not sure if this helps at all, but just thought I'd pass it along.

Report · Oct 28, 2018

What you see in Premiere Pro is not wrong–it's Rec.709.

So you will only see correct colors when your monitor is Rec.709. Most monitors are not.

The new Display Color Management feature in Premiere attempts to show you a better (not perfect, because it's not possible) representation of how the video will look on a Rec.709 monitor when you're using a monitor that is not Rec.709. It's a feature for the pros that deliver their videos to Broadcasters.

I've tried to explain what the Display Color Management in Premier Pro does here: How Display Color Management in Premiere Pro works - PremierePro.net

When you're sending your Rec.709 videos to the great Interweb (or to QT Player and other color-ignorant players) to be watched on an sRGB monitor, you're letting go of all control. The player decides how to display it. Using the sRGB gamma (and maybe even 16-235 levels) for video that is shot, edited and exported in Rec.709 will make it look washed out.

That is what you're seeing in most players and on most websites, and it's been like this forever. And it's got nothing to do with the new Display Color Management feature.

Here's an interesting test you can do:

Import your test footage into FCPX.
Export an h.264 file.
Import that file into Premiere Pro.
What colors and levels do you see?

Report · Oct 28, 2018

if it really is that simple, then perhaps this might work. a simple rec. 709 2.2 to 2.4 and 2.4 to 2.2 lut that you export out from media encoder to match browsers. only firefox will truly match as chrome has a white point issue you have to edit its config file for.

one lut will darken the image, the other, will lighten. both are done with a pure gamma conversion.

CreativeCOW

Report · Oct 28, 2018

Thanks for the LUTs link, Chris, but neither of these LUTs seem to help match the export greyscale RGB values to the Premiere Pro Program Monitor greyscale RGB values. The issue still persists.

Report · Oct 29, 2018

there's so many scene referred and display referred issues going on, the only way you'll be able to figure it out is using after effects or photoshop to match fcpx then burning that color profile into a HALD image. it may be a p3 2.2 to rec 709 2.4 as imacs use a proprietary version of P3. on top of that, FCPX may even be using the old 2.2 gamma for rec. 709. as 2.4 is a fall back position from BT1886 for poor quality lcd screens.

Report · Oct 29, 2018

That greyscale thing goes back, it would seem, to the Apple stuff not using the display transforms (Bt1886) but only the original camera transforms. PrPro apparently applies both the original camera transforms of the original Rec709 video-tape specs and the later addition of a display transform from the Bt1886 specs that were an addition to Rec709.

Ergo, final gamma is slightly displaced due to the presence of the Bt1886 display correction applied within PrPro.

And of course, if technically PrPro is "more correct" ain't of interest if the difference causes such a problem in working.

A ... toggle, switch ... ? ... to turn on/off the Bt1886 transform might be a useful "fix" here.

Neil

Report · Oct 29, 2018

since rec. 709 gamma 2.4 and BT1886 use a different shadow curve, here is test #2

This will convert between bt1886(a theory that premiere uses this over rec709 2.4) and sRGB 2.2/rec 709 2.2

I added both. one to darken and one to lighten.

srgb to bt1886 and bt1886 to srgb 64 iradas cube - Creative COW

CreativeCOW

if this fails, one can only assume that its color management passthough of the OS's color profile is not accurate; as true color profile support should, in effect, negate having to worry about what ICC you are currently calibrated at and then you just only have to worry about the difference between premiere's and FCPX's display reference.

Report · Oct 29, 2018

Neil - Very interesting thinking. This would make complete sense if this is, indeed, what's going on. Perhaps my results on Chris' LUT (below) will provide you with more information.

Chris - Thank you so much for taking the time to generate these LUTs and provide them for testing. My results are as follows: I exported my test Bars and Tone graphic from Premiere Pro with each of the LUTs applied (separate exports) and then compared those exports to the Premiere Pro Program Monitor without any LUTs applied on my timeline. Unfortunately, there is still a greyscale mismatch. I also tried exporting my Bars and Tone graphic as-is without any LUTs applied, and then compared my Premiere Pro Program Monitor with each LUT applied to the timeline (again, each separately). Unfortunately, there was once again a greyscale mismatch.

Here's where it gets interesting: Exporting a .PNG frame (which, if I remember correctly from Vlad and Francisco's help earlier in this thread is an "untagged" .PNG file) and then comparing that exported .PNG file to my Program Monitor with the "sRGB to BT1886" LUT applied to my timeline results in an EXACT match between all colors and greyscale RGB values. I have no idea what this means, I just know that it must mean something (or it's just a crazy coincidence, which I don't want to believe).

I'll try to do some more testing later tonight. In the mean time, perhaps the above results can be of use to someone else contemplating this issue.

Thanks again to everyone for offering assistnace and help on this issue!

Report · Oct 29, 2018

As explained by the engineers, the Rec709 initial standard was only a camera-reference standard. Bt 1886, added later, was designed to take the camera-referenced Rec709 and apply a display-referenced out-coding (?) to the file ... so it's part and parcel of normal 'modern' Rec709 work.

If, as Lars Borg says, Apple has chosen not to apply the other half of the typical Rec709 reference values, that would result in the grey-scale issues. And it would seem what is necessary is a way to reverse-engineer Bt 1886 display-reference values out.

Which on one hand, I understand one might find that usable. But ... on two levels, I do find this a problematic thing to do. First, what, 10% of computers out there are Apple rigs, so ... you're assuming you don't have many PC viewers ... or don't care what they see.

Second ... this means that your material will not (even on Apple rigs) look like b-cast material that is produced to full modern Rec709, using both the camera-referenced and display-referenced values.

I agree with giving the choice to the user to do so. I wouldn't ever take that choice myself.

Neil

Report · Oct 29, 2018

since all three srgb, rec709 and bt1886 don't change black or white point, just custom gamma curve, i see two ways you can grade

1. you can use a reverse lut while you're grading and essentially grade 'wrong' so that when you export for web, it looks correct.

2. grade correctly, and trust that a AME export lut will do the conversion correctly. you won't know it works until you actually load your browser.

both ways suck and all the software manufacturers of the world need to address this. i remember when Charles Poynton told all the tech groups, screw that! we're getting rid of non-square pixels. he changed EVERYTHING so now HDTV is square pixels. no more crazy PAR. That's what we need now. Where are you Charles?

Report · Oct 29, 2018

Oh, so agreed!

Although, using the reverse lut to un-display-transform for web publication will work for some machines/apps and work against you on others. Totally a screwed-up system.

Pick-your-poison.

Neil

Report · Oct 28, 2018

Hi Jarle,

Thank you so much for this very helpful post. What you say makes complete sense for my MacBook Pro, but not much sense for my iMac. The reason being, my MacBook Pro is sRGB but my iMac is P3. Prior to the Adobe Premiere Pro CC 2019 update, I completely understood that lack of color management within Premiere Pro was causing inaccurate colors to be shown in the Program Monitor on my P3 iMac. Now, with color management enabled, do I not cover the Rec.709 color space on my iMac with a P3 color space? Taking that a step further, shouldn't I have no problems editing and accurately seeing Rec.709 footage within my Program Monitor on an iMac with a P3 monitor, correct? Shouldn't my exports perfectly match my Premiere Pro Program Monitor, so long as I am viewing the PPro export file on a monitor that covers Rec.709 and in a color managed app? Your post suggests otherwise, but I think that's because you were assuming I was on an sRGB monitor.

I'd also like to once again clarify that this is not just an issue of playing back my exported video on one end source in particular (YouTube on Safari, QuickTime, etc.). I know that once my video is out in the "wild" that I have no control over how it is seen. What doesn't make sense is how I haven't been able to see the same Premiere Pro export greyscale RGB values in any other color managed web browser/video player as I see in the Premiere Pro Program Monitor and how Final Cut Pro X is 100% accurate in terms of color AND greyscale RGB values. This is the part of this issue that is still unresolved/unexplained. Thanks for linking to that article - I actually read that article in the midst of trying to determine a solution to this problem. Your article suggests that this problem should not be occurring on a P3 monitor, but unfortunately, greyscale values still do not match for me (like they do in Final Cut Pro X).

I also just finished the test you suggested that I do. To confirm:

1) I imported test footage into FCPX.

2) I exported that test footage from FCPX as an .H264 file.

3) I opened that FCPX-exported file into Premiere Pro.

Conclusion:

Once again, comparing the FCPX export to what the export looks like within Premiere Pro and FCPX:

1) In Premiere Pro, the color values match perfectly, but greyscale values still do not.

2) In Final Cut Pro X, the color values match perfectly and so do the greyscale values. The export is identical to the FCPX Program Monitor.

Any additional insight would be greatly appreciated and thanks for your time to respond to this thread!

Report · Oct 29, 2018

Would love to swap to Final cut right now just for this accurate colour, the dynamic link is a saviour right now but it's getting harder to justify using this at work

Report · Oct 26, 2018

if your source and stuff is sRGB into YUV y,cb,cr, and going out as that, shouldn't you be at 16-235 or something around that ?

I'm just as clueless as the next person, and don't work as a pro colorist or color scientist, or nothin.

It's a fascinating subject for me, cause I am partially color blind.

Report · Oct 28, 2018

jarle, Thank you for responding and being concise etc. You wording is perfect in describing your observations and experience.

The trick is to get the icc profiles from monitors to be standardized maybe ?

And, get the video card manufacturers in the same boat re: what can and cannot be utilized via GPU to be stable and reliable.

Adobe Community

Color Management Still Not 100% Accurate on Wide Gamut Monitor