[Colin Ruggiero]

Hey Sean,
No it’s not specific to Mac. Any wide gamut monitor with Premiere Pro will pose similar issues. You need one of the monitoring solutions I listed above or to export your project and color correct in a properly color managed program.

[Colin Ruggiero]

Yeah, hard to believe – but true.

If you’re working in Premiere, your options for seeing some sort of remotely accurate reference for your image are basically the following:

1. work on a display that is hardware calibrated to rec.709, or output the image, via Mercury Transmit, to a display that is hardware calibrated to rec.709. Mercury Transmit is not supposed to be color managed but I’ve noticed that it does indeed respond to OS level ICC profiles so a software calibrated display may work when using Mercury Transmit also.

2. Use a hardware i/o device to get the signal to a broadcast monitor. A computer monitor won’t work well because the i/o device will bypass your OS level ICC profiles so there isn’t a good way to calibrate the external monitor unless you can load ICC profiles directly into the display’s hardware. If you’re using Resolve you can also calibrate using a messy but serviceable system of exporting patches to use for calibration.

3. You can try to create LUTs using various services that you would then apply to your sequences in Premiere to try to match Premiere’s default display to Premiere’s exports when viewed in color managed software.

4. And… that’s it. Somebody jump in if I’m missing another way.

[Colin Ruggiero]

Hi Alex,

No, so far, I’ve left it where I described in my last post. It’s not just iMac Pros however, it’s any wide gamut monitor. And no, there’s no way to see accurate color inside of Premiere on a wide gamut monitor without using a third party i/o device to a broadcast monitor or at least a calibrated computer. The only other potential fix is to create a LUT as per Chris’s suggestion and apply it to your entire timeline.
Ridiculous, I know. Good luck!

[Colin Ruggiero]

Your working space doesn’t need to match your monitor for color management to work. That’s the whole point of color management. As long as your monitor is calibrated and your footage is tagged properly and the working space is set, you will get an accurate image even with “simulate display” off. Of course you can’t be working in a space that is bigger than your monitor is able to display but that’s a separate issue. And there is no need in most general image editing for your workspace to match your monitor profile. It’s perfectly normal, even optimal, to have a wide gamut display as long as it’s calibrated and you’re working in a color managed environment. It would be silly for me to convert all of the raw images I use for timelapses to Rec.709 jpegs or something to match my intentionally limited monitor space. Better to keep as much information as possible in your images for as long as possible through the workflow. I edit my Raw images in ProPhoto RGB on a wide gamut monitor so that I can see as much of the info as possible. If my workflow is color managed it’s not a problem to then export as Rec.709 for use in my video timeline. In my color-managed Camera Raw and Lightroom and After Effects I can easily “proof” them in Rec. 709 and fix any color clipping that may occur during that conversion. But by working in ProPhoto directly with the raw files, I can easily go back and make changes to exposure and all sort of other things utilizing all the original information that is there. And it makes it easy to use those same timelapses or image sequences (I process my raw drone shots the same way) in Rec.2020 as that becomes more standard. It would be really inefficient to calibrate my monitors to Rec. 709 and convert everything to that space prematurely or to be constantly switching my monitor calibration depending on what sort of footage I’m working with.

As far as Mercury Transmit, yes, it’s forced to rec. 709 but as far as I can tell that just means that it’s expecting Rec.709, just like Premiere. It still lacks any sort of color-management, just like Premiere, and therefor is not a reliable way to monitor, even on a Rec. 709 calibrated display. Unless you’re going through a pro i/o device of course.

Thanks for the info about making a custom LUT and using it as an adjustment layer inside Premiere with the proper blend mode. I’ll try that and see if I can find a reasonable way to compensate for Youtube’s and/or Chrome’s weirdness. Still seems like a ridiculous workaround to have to use to get reasonable color online, especially when I know plenty of people get good color without doing it, but I’m at a little bit of a loss right now for other options. Cheers!

[Colin Ruggiero]

Thanks for your feedback, Greg. Much appreciated.

[Colin Ruggiero]

Thanks once again for your reponses, Chris.

I know that you’re right about the inaccurate display I will see in PP when working on a wide gamut monitor. But your suggestion to calibrate my monitor to rec.709 so that PP acts as a “pass-through” doesn’t make any sense since PP ignores any monitor calibration. I think you mentioned earlier in this thread that a solution to this is to add your monitor calibration LUT to footage in your timeline in PP. That doesn’t seem like it would yield any sort of correct color to me either but I assume that you’re right and I will try this out.

In response to the issues that you think I’m experiencing:
“You are grading with a wide gamut monitor, but premiere ignores it.
AE with -> simulate display turned off(even with color management on) is acting as a ‘passthrough’ for your monitor, once again in dumb mode like premiere. that is problem#1”
I don’t think you’re correct about how color management works in AE. “Simulate display” is for testing display on un-managed devices and other scenarios and is not necessary in order for AE to provide an accurate and color-managed display. I have verified, both through Adobe’s support and through personal trials, that AE provides a fully color-managed display to your computer monitor with “simulate display” disabled.

#2 is that youtube doesn’t do adobe rgb/p3. it does rec.709 or srgb gamma 2.2. its hdr can do rec.2020, but that’s different.
I’m aware of this. My footage is all rec.709 and I’m only interested in it displaying accurately as such on the web. In AE and other color-managed programs I can monitor my video accurately enough for web display, even on my wide gamut monitor, by simply making sure that my computer display is accurately calibrated. Obviously inside of PP is a different story. I’ll try your LUT suggestion. I thought that I could get a fairly decent image to monitor (for web use only) by just using Mercury Transmit to a second computer monitor calibrated to Rec.709. But I don’t think that’s the case – the Mercury Transmit feed out of PP must not be color-managed at all and seems to be subject to the same “dumbness” as the GUI in PP unless you’re using a third party i.o device.

#3 vimeo is rec. 709 2.2 16-235 using broadcast pixel encoding. (don’t ask me why, its on their recommended encode page)
Yeah, I’ve seen that. So stupid. But I’ve never liked Vimeo and don’t use it anyway.

To reiterate my primary issue: Using color-managed Adobe apps and a calibrated monitor, I can edit timelapse images in Adobe Camera Raw. When imported into AE, those images match what I saw in ACR. I can further edit and compile that timelapse and export it in Rec. 709. That exported file looks like what I saw in AE when I open it in VLC. If I then reimport that timelapse back into After Effects, all of the colors still match and everything looks correct. If I then upload that same file (ProRes 422, Rec.709) to Youtube, it looks washed out. “Retouching” the video in Youtube does not force it to re-encode to VP9 and display correctly. Nothing I’ve tried can make that video look remotely correct on Youtube with the exception of exporting it with your fixmyyoutube LUT. This makes the saturation pretty much correct but ends up crushing the blacks too much.

Thanks again for your thoughts.

[Colin Ruggiero]

Hey Chris,

I’m going a little nuts with this stuff and trying to keep track of all of the variables. I really appreciate your help and I sense that you have more technical savvy than I do – so please don’t read any disrespect into this – I just want to figure this out. And I can’t believe that what you’re saying is the answer. I’ve been making videos professionally for almost 15 years, including for broadcast, and neither I nor any other professional I know has ever used a transform LUT to reinterpret everything on their monitors. There has to be an effective way to work with wide gamut monitors without jumping through hoops to turn them into standard gamut monitors. I recognize that PP isn’t color managed and that what I see inside Premiere on my wide gamut monitor isn’t going to be accurate. But After Effects is color managed and can account for my wide gamut monitor in a properly color-managed pipeline and what I see in AE matches what I see in PP close enough. And that matches what I see in video players besides QT. And who cares about QT anyway. And some modern browsers do understand properly tagged Adobe RGB/P3 content. The reason that properly color-managed videos in After Effects look drastically different on Youtube in certain browsers than they do everywhere else is not because I’m not using a transform LUT on my whole system. And before anybody jumps in and says their bit about a properly calibrated broadcast monitor through a profession i/o device – that’s not it either. I’ve worked with professional i/o and broadcast monitors for a long time. I don’t currently use one for a variety of reasons but that whole line of reasoning is irrelevant here. Without a broadcast monitor I may not be seeing the ultimate truth of my video’s color – but whatever color bias is there should be the same in color-managed AE on any given monitor as it is in Youtube on that same monitor unless Youtube or the browser is changing something about the way that video is displayed. Does that make sense? Do you think my analysis is flawed here? I work with ProPhoto RGB photos constantly. My calibrated monitor and color-managed software allows me to accurately translate and proof their colors in sRGB and, once they are uploaded online, they match those proofs exactly. After Effects should and does work the same way when I edit and monitor in a calibrated Rec.709 workspace. Something is happening in Youtube and Vimeo or some combination of Youtube/Vimeo/various browsers/etc. that is causing the videos to be incorrectly interpreted.

[Colin Ruggiero]

Thanks for doing that, Greg. I calibrate my monitors the same way and have pretty much the same experience – washed out in Chrome but matching in Firefox. Also matching on local video players except QT. This seems weird as Chrome is supposed to have more robust color management than Firefox. I’m curious what your computer monitors you’re using. Interestingly, Youtube in Chrome on my Macbook Pro match what I see in Premiere. But, like I said, Youtube in Chrome on my iMac Pro are washed out and Youtube in Chrome on both an older iMac and an older Mac Pro are also washed out. At this point, I might just call this the margin of error that you can’t overcome and let it be.

[Colin Ruggiero]

I already responded to your previous post but this is a follow-up. This is looking more and more like a browser issue at this point. I swear I controlled for this earlier but now looking at my test videos in other browsers I’m seeing strange differences. When I watch on Youtube in Firefox I see “proper” colors that match what I see both in Premiere and in After Effects perfectly. I looked into color issues with Chrome and found a whole bunch of info on washed-out colors in chrome after version 6,1 due to some color profile matching feature. Thought maybe my whole current issue boiled down to that. But then colors in Safari match what I see in Chrome. So my questions at this point is it it’s possible this is a wide gamut display issue and that everything I’m seeing in After Effects, Premiere, VLC, etc. is over saturated and Chrome and Safari are actually closer to the correct values? I don’t see how that could be the case since my computer display is accurately calibrated, After Effects is color-managed, and in Firefox the uploaded video colors match perfectly. But I also don’t understand how the image I’m seeing in After-Effects, which is color-managed, is the same as the image I’m seeing in Premiere, which is not. Seems like the only way this could be the case is if my monitor were calibrated to the same Rec.709 color profile that PP and AE expect by default and the colors were just “passing through.” But my display is not set to a rec.709 profile.

I’m aware of the futility of trying to make everything match and that’s not what this is about. I’m completely accepting of the fact that there will be differences in every viewers configuration and that my videos will look different in each of those. I just want to make sure that the washed out colors I’m seeing on Youtube in Chrome and Safari are not a result of something in my control.

[Colin Ruggiero]

Thanks Chris,

I can’t find any way to override gamma settings on my graphics card. It’s a Radeon Pro Vega 64 card and there don’t seem to be drivers available for Mac as they’re built into the OS. I can change system wide gamma in the calibration panel or Display settings in System Prefs but that seems to be it. Gamma is set at 2.2

Black levels are at 0 on Premiere’s scopes.

I haven’t tried AE’s color profile converter. I want to be working in the full 0-255 range and should be able to maintain those levels throughout the pipeline without problem.

Everything matches and looks correct except for Youtube and Quicktime. Starting to think that QT is just QT and is always messed up and the issue might actually be some sort of video playback and/or web browser gamma discrepancy with my graphics card but I can’t think of anything I can do about that. You know, since I spent a fortune on an iMac “Pro” that is not really pro and doesn’t allow me any access to graphics card settings. The video looks fine in non-QT video players though so that makes it seem like it’s likely some sort of browser issue. I’ve tested on both Chrome and Firefox and had the same issue.