At A Complete Loss Getting Vimeo and Color Grade To Match

I will throw my hands up in the air and admit that I am no computer wiz. I am a photographer and cinematographer. I've shifted away from Premiere to do my color timing in Resolve because of all the control it gives you in the grade. But, for the life of me, I can't seem to get the colors I see in Resolve to stay that way once they are uploaded to Vimeo or viewed across platforms.

Here's the background on what I'm currently doing and what I've tried so far over the course of the last four months of thinking I found the answer only to be proven wrong.

Footage shot originally with the Canon C200 in Canon Raw Lite (in most cases). Canon Cinema Gamut. C-Log which in the C200 is C-Log 2 if I'm not mistaken.

I bring it into Resolve and use DaVinci YRGB Color Managed, DaVinci Wide Gamut, and leave the default Output Color Space as Rec 709 Gamma 2.4.

I have read several articles about color spaces/gamma, and as far as I understand 2.6 is for movie theatre, 2.4 is more for TV, and 2.2 is more for office computers and brighter viewing environments. So, at least as far as I understand it so far, those different levels have certain different brightness level standards they aim for. While everything will end up online at some point, my work could end up a lot of places from TV to Movie screens, to something else I'm not even aware of yet. So, my goal is to establish a workflow that covers multiple potential outlets with a consistent image across platforms.

I understand that the colors on the iMac 27 inch I am working with are not always correct. So, on previous suggestions, I went out and spent a lot of money (for me) on an external monitor, an Eizo CG279X. I did the calibration setup for that and it is set to calibrate itself every week. I currently have it set to Rec 709 Gamma 2.4 to match the settings in Resolve.

I then use DaVinci to color grade my footage and get it just right. I usually spit out at least two versions. One version is ProRes 422 using Same As Project for my color tag and gamma tag.

Having found Dan's excellent infographic from The Post Process, I then export a second version in H264 where I specify Color Space Tag as Rec 709 and Gamma Tag at Rec 709-A. If I understand correctly, 709-A is supposed to keep things consistent online (I probably have that wrong). Everything else is left the same.

If I export those two, the ProRes 422 using Same As Project will playback in QuickTime exactly how I saw it on my monitor during editing. But the second file with the Rec 709-A tag will play back significantly brighter as if I had shot the whole things one or two stops over what I did. The black levels are up and overall contrast feels less. (I've attached two photos for reference. The darker one is correct). If I try exporting H264 using Same As Project for Gamma and Color Space (instead of changing to 709-A), the QuickTime version looks good of my computer, but will then have the same brightness and contrast shift when uploaded to Vimeo/YouTube.

If I try to post either the lighter or the darker version to Vimeo, the video plays back through Vimeo as the bright low contrast version and it's driving me crazy.

I spent about an hour on the phone with DaVinci trying to get help without luck. At this point, I'm at a loss, because I've been reading the various posts suggested online for a while and can't seem to get a consistent workflow where what I see in Resolve (on the external calibrated monitor) is what I will get if posting Vimeo, sending a file directly to someone to playback in Quicktime, or anywhere else. Since purchasing the calibrated monitor, the colors do seem more accurate. But this exposure boost & lower contrast that seems to happen whenever I take it out of Resolve and put it online is my current Mount Everest.

I realize I'm not the first person to ask a similar question on here. Believe me, I've read all the previous threads just to try and get this far. But, I keep trying to find a simple set of steps to make sure everything matches across platforms and I'm coming up short, leading me to think that somewhere I must be setting something wrong, but I just can't tell you what it is.

Any help at all would be greatly appreciated.

[Peter Chamberlain]

Moved to Resolve forum

I would try setting tags to 709/2.4, and then 709/2.2, and even 709/709

Have honestly never uploaded anything to Vimeo but I have struggle solved others

I can't seem to get the colors I see in Resolve to stay that way once they are uploaded to Vimeo or viewed across platforms.

Trying to QC the image coming from Vimeo is...problematic. You're going to encounter, and may not be able to overcome, variables in the signal path.

Is Vimeo re-encoding the video?
What is the browser doing to to it?
What is the GPU doing to the image on your monitor?
What is the OS doing to the image on your monitor?
Is your monitor properly calibrated?
Can your monitor be properly calibrated?

I think what you're experiencing is the transition from 'legal' levels (16-235 8 bit/64-940 10 bit) to 'rgb or full' levels and I think Vimeo maps legal to full. So what you want to do normally is export and maintain at legal levels, aka 'same as source'. You can test this by using a SMPTE test chart and following the process through, including upload to Vimeo. In any case I have always done this with Vimeo and have not noticed any adverse shifts.

I believe you may be encountering a known issue - google "quicktime gamma shift." Most browsers running on a Mac rely on Quicktime to display video, and Quicktime imposes a weird gamma that causes video graded at gamma 2.2 or 2.4 to look washed out. I've read the claims online that setting color space and gamma to "rec.709" or "rec.709-a" (rather than "same as project") on the render setting window of the delivery tab will force Quicktime to adhere to gamma 2.4, but in my testing this has had no effect.

In my experience, the same washed out effect that you describe and illustrate in your screen grabs is also visible when I view the exported video file directly in Quicktime. What surprises me is that you say when you export a file with gamma and color space set to "same as project" and then open the exported file in quicktime, it matches what you saw when you graded the material in Resolve. Again, this is not what I have experienced. Are you sure that your are opening the exported files in Quicktime and not VLC? VLC WILL play back the files properly, with the gamma approximately matching what you graded to.

None of which gets you closer to solving the problem. One can't simply do a higher-contrast grade for Vimeo displayed on a Mac, because then the file will appear too contrasty when Vimeo is displayed on a Windows machine. The best advice I have been able to find online is to split the difference, and grade the file so that it appears somewhat low-contrast on a Mac and somewhat high-contrast on a PC.

Needless to say, this is hugely frustrating. I hope there is someone out there more knowledgeable than myself who can suggest a better solution!

Read these:

"Grading for Mixed Delivery: Cinema, Home, and Every Screen in Between" by Cullen Kelly
https://blog.frame.io/2019/10/14/gradin ... -delivery/

"How to Deal with Levels: Full vs. Video" by Dan Swierenga
https://www.thepostprocess.com/2019/09/ ... l-vs-video

and
"A Deeper Look at Consistent Color with QuickTime Tags From Resolve To YouTube & Vimeo on Wide Gamut Apple Monitors" by Dan Swierenga
https://www.thepostprocess.com/2020/07/ ... ktime-tags

and I think they cover the issues and the solutions very well. Understanding color management is also helpful:

"Color Management for Video Editors"
https://jonnyelwyn.co.uk/film-and-video ... o-editors/

My simple method: always export a second or two of SMPTE color bars at the very head of the project, and then check them on scopes in whatever player you're using to see how it looks. If there's a shift (video level or hue or chroma), you'll see it very quickly in bars.

Note that the same image will look different on different browsers, different operating systems, different laptops, and different desktop displays. Even worse when they're not calibrated. Sound has similar issues.

Thank you all so much. I've been digging through every link posted here so far, and I have made a bit of progress. Little by little. So far, the changes I've made seem to be helping....

I created color bars and exported a couple versions with the bars attached. I then reimported the export into Resolve and looked at the scopes while toggling between Data Level Scopes and Video Level Scopes on the waveform to make sure I was viewing things correctly.

I also checked to make sure I wasn't using any illegal levels letting anything dip too low or too high.

I turned off Use Mac Display Color Profiles for Viewers and turned on Use 10-bit precision in viewers if available. This shifted my calibrated external monitor away from what was showing in the DaVinci interface (on my iMac screen). But it was much much closer to what ultimately was showing in Vimeo. So I think that setting had been adding a bit of color to my external monitor that wasn't really there in the file.

As for the Vimeo export, I edited my timeline using Rec709 2.4 as the output setting. My monitor allows me to toggle between previewing 2.4, 2.2, and 2.6 so I could easily preview the difference converting on export would make. Predictably 2.2 made things lighter and 2.6 made things darker. Then, instead of exporting as either Rec 709-A or Rec 709 2.2, I instead exported a sRGB Gamma 2.2 version. This was much much closer to the Rec 709 2.4 I had been seeing on my monitor and in the export where I left the gamma and color space as Same as Project. And it was pretty much spot on if I used my monitor to preview the 2.2 version before exporting. So going from editing in 2.4 to exporting in 2.2 is still brightening things, but not to a criminal degree. I still want to figure out how to get it to not brighten things, but one step at a time.

I'm sure there are some surprises still to come. I'm exhausted after all that reading and need to shut it down for the night. Lol. But so far, this workflow seems to give me a more consistent result. Or at least a predictable one which would allow me to make multiple exports based on the eventual destination which would somewhat match. I don't know if it's possible to get an exact match between the 2.4 and the 2.2 in terms of luminance without going in and pre-darkening the video prior to export so that the lift that occurs when converting to 2.2 would only bring it back to "normal." I'd prefer not to do this as it will never be exact and that will drive me crazy. But hopefully I can continue to get it closer and closer to the same general range as to be less noticeable.

Thank you for you help!

Marc's links are spot on and as I said earlier, I too use SMPTE bars and a vectorscope to check things, it's an instant method. These gamma settings, 2.4, 2.2, 2.6 or whatever are totally misleading - they are for output devices - e.g. cinema screens, TVs and computer screens, in much the same way as we used to print different gammas for film depending on whether the print went to the cinema or ended up on telly. For video upload we should stick to the old standard rec. 709 2.4. It's legal vs full levels that are being overlooked. If you export a file at full levels, i.e. 0-255, then Vimeo will map that to 16-235, hence the huge shift, I think You Tube does the same. It's the platform transcoding that is the problem - the Quicktime player thing is something else. It doesn't matter what problems your local player has, except that ideally it too should be set up to playback true levels that you have set. SMPTE colour bars/vectorscope will show these anomalies, as I say instantly.

Note that the same image will look different on different browsers, different operating systems, different laptops, and different desktop displays. Even worse when they're not calibrated. Sound has similar issues.

never were truer words written. in my limited experience, if it looks right on my calibrated monitor, then that's what i put out.

I often see data/video levels being discussed but rarely the fact that browser operate in sRGB and most webplayers don't convert rec.709 to sRGB gamma.

First: double check if it looks more washed out when you switch your EIZO to sRGB.
If it still looks brighter convert rec.709 to sRGB gamma on top of the entire grade and export with normal rec.709 settings. This way you 'pre-fix' the fact that the webplayers don't do this.
It should now likely look the same as inside Resolve without the conversion.

You wouldn't do this for broadcast however. Only for web.

We do the exact inverse of this idea in Premiere Pro. We grade unmanaged for web (seeing rec.709 through sRGB without conversion) so viewer == webbrowser. And then for broadcast we preconvert to compensate. (Our monitors are sRGB calibrated)

Hope it makes sense and helps.

sRGB and rec. 709 are almost identical, close enough infact that there is never any need to convert, in any case I've always just used rec. 709 legal without issue. In this case it's really about what Vimeo et al are doing with your video when you upload it. In the case of Vimeo because it was designed for filmmakers they have built the platform to accept rec. 709 more often than not.

sRGB and rec. 709 are almost identical, close enough infact that there is never any need to convert

The colorspace is identical but the gamma is very different and very visible if you view one as source through a monitor that is the other without conversion.

If you think there's no need to convert that's a personal opinion/choice to not care and not a solution.

In the case of Vimeo because it was designed for filmmakers they have built the platform to accept rec. 709 more often than not.

That's an assumption based on what? Expecting Vimeo is "designed for filmmakers" thus it ought to be perfect is a bad way of thinking.

This is what I see in a rec.709 timeline in Premiere.

1.jpg (126.27 KiB) Viewed 3451 times

This is what I see on Vimeo. Exactly the same. (aside from compression removing detail/grain)

3.jpg (59.32 KiB) Viewed 3451 times

This is what it actually looks like if rec.709 would be converted to sRGB or would be viewed on a rec.709 monitor.

2.jpg (130.93 KiB) Viewed 3451 times

Pretty different right? I think the OP is in the same situation as I described.

Yes that's what I said the colourspace is identical. The levels are what I referred to earlier i.e 16-235 8 bit legal or RGB/full 0-255, so of course there is a difference, you demonstrate. I was taking exception to the use of sRGB as a colourspace for video, which is a print/Photoshop thing, we don't ever refer to that as a delivery spec in the video world. Gamma is misleading here because they are two different things - gamma is about the viewing conditions and levels are about the gammut:

https://mixinglight.com/color-grading-t ... i-resolve/

https://www.thepostprocess.com/2019/09/ ... -vs-video/

This is how it looked on my EIZO monitor set to Rec 709 Gamma 2.2

4 DaVinci Preview On EIZO.png (701.01 KiB) Viewed 3420 times

Arrgh. Thought I had it, but just tried again, regrading from scratch for practice, using the new method and still got the brightness bump. Darnit. Just when I thought I had it figured out.

This time, trying to establish a routine....

I brought in the footage.

Set the project to DaVinci Color Management, DaVinci Wide Gamut. Gamma 2.4 default.

I set my monitor to 2.2 so that I would get what I thought would be a real view of what the 2.2 output would look like if exported at 2.2 for Vimeo.

Then graded using the external monitor again to get the desired look on the external monitor set to 2.2.

Then I went back to Resolve and outputted in both ProRes 422 2.4 and H264 sRGB Gamma 2.2.

I tried setting the levels to Video to try and take into account the higher base value in case Vimeo was automatically raising levels as mentioned in an earlier response (I also exported using auto and it didn't seem to make a difference within Quicktime).

I was expecting the 2.2 export to look the same as the color grade on the external monitor which had been done with the sRGB 2.2 preview setting on the EIZO. And I expected the 2.4 export to be a bit darker than the monitor since I was grading to a 2.2 monitor this time.

But instead, the 2.4 export which I expected to be too dark (since I graded to the 2.2) was actually just right. And the 2.2 export which I expected to be right, was bumped up brighter again on export. It didn't get brighter once on Vimeo. So that's good. But it was already bumped brighter when exporting which I hadn't expected.

My goal this time was to try and focus on the Vimeo version. So I tried, unsuccessfully apparently, to color grade to my "final" deliverable. Which, as I understand it, would be a sRGB Gamma 2.2 file since the internet is partial to sRGB and Vimeo understands 2.2. At least I think that is correct. But the video still got brighter on export, it seems. Wheras the 2.4 export that I expected to be too dark, ended up matching exactly what I graded on my monitor (with it set to 2.2).

I am Jack's boiling rage.

Lol (but crying on the inside)

Arrgh. Thought I had it, but just tried again, regrading from scratch for practice, using the new method and still got the brightness bump. Darnit. Just when I thought I had it figured out.

Christopher, please look at the article I linked to above, noting particularly this line: "The delivery destination makes no difference when I’m color correcting! I set my gamma appropriate to my viewing conditions, not my delivery specification."

Gamma settings are meant to be used during colour correction for your viewing environment, not as an export format. Your problem with Vimeo is what I said before, you are exporting 0-255 8bit RGB full levels and Vimeo is mapping to 16-235 legal levels. It will make no difference what gamma lut you apply, to that shift.

Yes that's what I said the colourspace is identical. The levels are what I referred to earlier i.e 16-235 8 bit legal or RGB/full 0-255, so of course there is a difference, you demonstrate. I was taking exception to the use of sRGB as a colourspace for video, which is a print/Photoshop thing, we don't ever refer to that as a delivery spec in the video world. Gamma is misleading here because they are two different things - gamma is about the viewing conditions and levels are about the gammut:

https://mixinglight.com/color-grading-t ... i-resolve/

https://www.thepostprocess.com/2019/09/ ... -vs-video/

Colorspace is a compound of gamut and gamma, there is no colorspace outside gamma. So rec709 and sRGB colorspaces are not identical, their gamuts are. Gamma is about value range encoding, which for some colorspaces also serves the purpose of producing appropriate end to end gamma for viewing environment when fed to properly calibrated display (rec709 > bt1886 for example). Levels have nothing to do with gamut, they are a property of value encoding in luma-chroma color model (although sometimes also used for rgb data) for specific video signal. You can exceed gamut with futzing illegal and invalid values in luma-chroma though, because those values can produce negative rgb values if not clipped. Only way to exceed gamut is to go negative, dynamic range has zero effect on gamut.

Colorspace is a compound of gamut and gamma, there is no colorspace outside gamma

Of course, in a viewing context. It is essential that your grading environment has the correct calibration and gamma. It has no bearing upon delivery since that, in this instance is just applying a 3D lut in an arbitrary manner. Whatever, the shift Christopher is experiencing with Vimeo is about gammut levels. And for all practical purpose sRGB is more or less identical to rec. 709 at least in the colourspace it can cover. Christopher has a background in photography and so I can see why he's using it but we use rec. 709 and there should be no issue with exporting videos and playing them on pc or uploading them, if we do.

In any context, this is what colorspace means as a term. What Christopher is experiencing could be from levels issue, could be gamma issue. But there is no such thing as gamut levels, its just levels. It is very simple to differentiate between levels and gamma issues: if it clips something it is levels issue (full interpreted as video), if it doesn’t but lifts pure black it is levels too (video interpreted as full), if it doesn’t clip or lift blacks it is gamma issue. Could be both combined but easier to sort levels first, then gamma. Easiest to test levels issues is with an smpte chart. I disagree about sRGB and rec709 being near identical, difference in gamma is very visible and offending enough when comparing side by side, on same monitor. What the gamut coverage is is irrelevant in this case, they have the exact same gamut anyway. If sRGB data is encoded as video, it gets the levels conversion applied exactly the same way as rec709, and if data values were identical, you can’t differentiate between them. Where things can go sideways is when player or video streaming service interprets the metadata tags as ”aha it is sRGB, we need to do a conversion” which produces misalignment when intent was to keep it as-is.

But there is no such thing as gamut levels, its just levels.

RGB gamut levels are specified in every delivery spec document I have to use, if they are wrong then that would include the EBU and all major UK channels I know of. Here for instance is the DPP section:

1.2.1. Video Level Tolerance
In practice, it is difficult to avoid generating signals slightly out of range, and it is considered reasonable to allow a small tolerance:
 the RGB components and the corresponding Luminance (Y) signal, should not normally exceed the “Preferred Minimum/Maximum” range of digital sample levels in the table below,
 measuring equipment should indicate an “Out-of-Gamut” occurrence only after the error exceeds 1% of an integrated area of the active image.
For further details see the EBU Recommendation, EBU R103.
Any signals outside the “Preferred Minimum/Maximum” range are described as having a gamut error (or as being out of gamut). Signals cannot exceed the “Total Video Signal Range” and will therefore be clipped.

Being out of gamut is a result of exceeding reference excursions. Just as going negative with rgb values goes out of gamut. Levels are still just levels, not gamut levels. Bringing gamut into it and using gamut and colorspace interchangeably as if they were the same thing is confusing terminology because they aren’t.

OK Hendrik, have it your way, maybe my semantics are not in accordance with yours, I'll warrant and will accept as long as I don't fail QC. Nonetheless Christopher is experiencing a shift, from and to Vimeo no matter which standard he exports to and I'm pretty convinced that is to do with full to legal mapping, because it's happened to me, which can be tested simply by using the aforementioned SMPTE colour bars.

All good, it just makes imho problems easier to undertand and reason over if terminology is aligned I might slip myself too, happy to correct if it happens.

Yep, I think best is to run smpte bars through first to see if it is levels issue, sort that first and then deal with gamma issues if difference persists. For gamma, there are basically two different approaches, modify metadata to force no conversion or modify data itself to correct for conversion with its inverse.

Ha ha, I didn't say you corrected me - we refer to them as rgb gamut levels, perhaps incorrectly according to you but yes all good

maybe it will stick to you unconciously

No doubt now - I'll be terrified to use the wrong term Hendrik

Thanks again for everyone's help.

So, if I am understanding correctly, it seems like the next thing for me to check is to make sure that the levels I am grading at match the levels I am exporting at match the level that Vimeo is reading. As Steve mentioned I may be exporting 0-255 8bit RGB full levels and Vimeo is mapping to 16-235 legal levels. Or some other combination.

So here's what I've done. I checked to make sure that my levels were the same across the board. So, in my project settings, I switched it from video/auto to full. Then I went to my waveform and changed that to show full. When it was set to video, it was showing the SMPTE color bars not touching top and bottom, which, if I read it correctly in one of the link articles, means that I was mismatching levels. So, this morning, I tried setting both the projects setting as well as the waveform settings to full. My EIZO monitor was also set to full.

I then exported twice. Once with a 2.2 gamma and once with a 2.4 gamma just for purposes of comparison. I understand that 2.2 and 2.4 refer to viewing environments. The 2.2 predictably brightened up the image from what I originally saw on the monitor. The 2.4 did not.

I then tried uploading the sRGB Gamma 2.4 tagged file to Vimeo to see if the platform would interpret correctly or if it would bump the levels up versus what was on the monitor. It seemed to do a better job this time making the two very very close.

Christopher, you see that setting 'Data levels' in the Advanced section on your export page? Set it to 'Video' not 'Full' and try an export/upload to Vimeo again. Try rec. 709 and 2.4 for the colorspace and gamma tags as well, just for a test and let's see what you get.

Sorry for the delay. Steve, here is what happened when I exported with advanced settings to Rec 709 2.4 at video levels then uploaded to Vimeo. The QuickTime file was correct to the Resolve viewer. The Vimeo file, once on Vimeo was a wee bit brighter. Close. But brighter by a little bit.

I understand this isn't really helpful but have you tried grading, exporting, and uploading on a PC?

I HATE to even mention that but a couple years ago I tore my hair out trying to get my uploads to look accurate to my grading monitor on the iMac Pro at work and uploading at my home PC was my answer.

My contrast levels were consistent and every project since then looks good on my phone, on my macbook, and streamed on my TV. Whereas, anything before then I can immediately tell there are color shifts that weren't intentional.

There are loads of people who seem to have figured out grading with Macs but particularly with Adobe Premiere I just couldn't despite spending weeks on the issue. Resolve was significantly better but I was still having similar problems as you.

Christopher, Did you ever sort this out? I have been working on this for weeks and following almost the same path as you. What was your conclusion?