Color shift in export

.../...
We used Photoshop. At the time I left we stopped outputting proofs and had been on a completely digital pipeline for a few years. A properly calibrated monitor looked the same in photoshop as it did on the proofs as it did on the press.
.../...

Hi,
Good to know :
Blackmagic provides with its cards/software plugins for Photoshop X32 and X64. It allows to export to the same control screen (calibrated) used by Davinci Resolve. If we have a difference with the result once using Davinci Resolve: check the Photoshop settings.
A+

I'm happy to share another solution to this problem. Besides switching your monitor profile to sRGB and regrading your whole project from scratch, you can also follow these easy steps, and keep all that glamorous complementary colour you've worked so painstakingly long and hard to achieve.

1. Deliver your shots as Tiff sequences. See which settings work best for you, I picked 8bit Tiff and got great results.

2. Open your Tiff sequence in Quicktime Player 7 by clicking "Open Image Sequence".

3. Export the sequence as a Quicktime movie to ProRes 422(HQ), but before you do, turn off Gamma Correction in the settings dialogue.

And that's it, you now have a ProRes version of your Delivered shot that looks identical to the GUI preview in Davinci Resolve on your computer monitor.

I have also fooled around with different settings and did an export to H.264 at 25000 kbps (Super HD), which gives me a slightly brighter video when viewed in Quicktime and VLC, but I got very low quality compression that made the fog in my shot look like a topographical map.

1. Deliver your shots as Tiff sequences. See which settings work best for you, I picked 8bit Tiff and got great results.

2. Open your Tiff sequence in Quicktime Player 7 by clicking "Open Image Sequence".

3. Export the sequence as a Quicktime movie to ProRes 422(HQ), but before you do, turn off Gamma Correction in the settings dialogue.

+1.

I always find that "Data" mode gives more accurate result. Prores 4444 output in data mode is almost identical to what I see in Resolve. Hence for QT needs I always output in Prores 4444 from Resolve (in "data" mode) and then go for other Prores conversions through Compressor 4.0. Gives me better

I use the same workflow for web delivery with upstanding results.

Page 690 should not only be placed earlier, but in fact, the words "Davinci Resolve is not compatible with computer displays, please disregard our advertising that shows our software on a household iMac!" should be written in bold letters as soon as you open http://www.blackmagicdesign.com. ...

Well, you can do HD pretty well on the latest iMacs, assuming fast drives. And you might be able to use 4K files somewhat, monitored at 1/4-res good. Maybe that's what they're using in the ad photos.

Yes, you can.
We have iMacs with 4 GB VRAM in our labs and students are using them for RED footage, even in half-res. But only professional formats: as we already expected, H.264 in 4K doesn't work.

I have encountered a similar issue and not having found this thread first, I created a new one here: viewtopic.php?f=23&t=47828

My bottom line is that Quicktime seems to be the problem. If I render to AVI 10Bit uncompressed YUV, the render matches exactly what I see in the GUI viewer. Even if I render to the same 10 Bit uncompressed YUV with Quicktime, the result doesn't match. Here's an overview of my test results so far:

Quicktime DNxHD: Bad
Quicktime h.264: Bad
Quicktime Uncompressed YUV 10 Bit: Bad

AVI Uncompressed YUV 10 Bit: Good
AVI Uncompressed YUV 10 Bit converted to h.264 4:2:0 with libx264: Good

It is notable that there is no visual difference in the contrast and colors between the Quicktime renders.

I'll do some more experimenting when I have time but for the moment, I have adapted my workflow so that I render everything first to AVI 10 Bit uncompressed YUV and then use ffmpeg to convert it to the final deliverable. That costs a bit more time and CPU hours but the results come out perfect.

Any news as of late?

Top right is FCPX and the exported file below it. No color difference.

Top left is Resolve 12.5.b3 with it's export below it. Big gamma difference.

Driving me nuts. Tried 709/709 2.2/709 2.4. No dice. Tried 'Mac Display Colors' No dice.
I know the proper setup is to have a separate monitor connected through a Blackmagic monitoring card but come on... If iMovie/FCPX/Premiere can all export a file that looks identical to the one you're grading there's a way.

Blackmagic is marketing a $1000 dollar camera and free editing software so there's no reason to pretend that we all have CG318-4K Eizo's attached to UltraStudio Extreme 's


iMac 5K P3

If iMovie/FCPX/Premiere can all export a file that looks identical to the one you're grading there's a way.

your automatically implying that the operator is doing nothing wrong and the error must be in resolve...

The color shift has been jumping from NLEs to color grading applications for a long time, and it's a QuickTime issue. It seems to be that some applications have found a workaround others haven't. I first encountered the issue back in 2011 using , if I well remember, FCP6 or 7 FCP. The only solution I found at that time was to create a custom setting in Apple Compressor, changing the Color Correct Midtones: Red, Green and Blue by 3.0 points and Gamma Correction by 1.05. I made a droplet in Compressor to avoid opening this application every time I need to export a project for the web. The issue and the solution were well documented around 2011 by Larry Jordan in his blog. I'm still using the setting today after exporting projects from Davinci Resolve. It still working.

The key (which I think I said a year or so ago in this thread) is to always export a few frames of color bars and other test signals, and check the render on a scope. If the other application is suddenly using Data levels when it should be Video levels (or vice-versa), or if something is changing drastically in the render, then you'll see it on the scopes.

The key (which I think I said a year or so ago in this thread) is to always export a few frames of color bars and other test signals, and check the render on a scope. If the other application is suddenly using Data levels when it should be Video levels (or vice-versa), or if something is changing drastically in the render, then you'll see it on the scopes.

+1, critical to establishing any workflow for any program, from open sourced to thousands of dollars, imho.

Thanks to everyone who clarified the problem with Data Levels vs Video Levels. I agree that when dealing with YCbCr, by definition, that is Video, and the luma channel, Y, maps to [64-940] and the chroma channels, Cr and Cb, both map to [64-960]. These values are the 10-bit equivalents of the more traditional 8-bit values that leave headroom and footroom. YCbCr outside these ranges have traditionally been referred to as superwhites and superblacks, and superwhites, in particular, are often encountered in consumer camcorder footage. But I digress.

Here is my question that may or may not be related to the problems others are experiencing. When I:

1. Import my SMPTE color bars that are 8-bit YCbCr 4:2:2 (UYVY)
2. Export the color bars (no effects) as either 8-bit or 10-bit Uncompressed YUV 422
3. Import the exported bars
4. Scope them up along with the original import

there is a slight shift in the scopes. It is probably not very obvious from the attached images. It is much easier to see when clicking between the clips within Resolve and studying the borders between the bars.

It appears that Resolve is resampling the chroma channels upon export because the edges of the bars are blurred in the export. My original bars have clean edges (if anyone is interested in how I generate them, I will be happy to share). The slight noise present on the scope of the original bars is undoubtedly the result of Resolve's resampling to RGB 444 for display on my computer monitor. Now, ordinarily I could live with this. However, what concerns me is that the exports appear to go through this YCbCr 422 -> RGB 444 -> YCbCr 422 pathway as well.

I am using the lite version, so there is no YUV444 option available. I am just spit balling here, but my guess is the only way to bypass the chroma resampling when exporting requires the use of YUV444. Lite users are out of luck. Can anyone please confirm my suspicion?

Thanks everyone.

My post above got quarantined by the mods for more than 48 hours. Anyhow, I received the following suggestion from Peter Chamberlain in PM:

you should try the same test with internal color bars and dpx renders to compare. Then your 8-bit YCbCr bars and dpx.

However, internal color bars won't help me. I am trying to find a lossless pathway through Resolve for imported content, unless Peter is saying that dpx is only lossless export format. In which case, every other format will incur some color shift on export, no matter how slight?

Any thoughts?

[Peter Chamberlain]

All internal processing in DaVinci Resolve is 32bit floating point RGB. So all input sources, video or data, in float or integer, are transformed to 32bit float. The reverse happens at the end. 10 and 12bit integer video is now considered the norm and 16bit half float interchange is becoming popular in high end productions.

There are numerous file formats that can hold 10/12 bit video and a few 16bit half float. I think a good starting point with your example files would be to see where the discrepancy starts and that may be at ingest/transform of the 8bit bars or render.

All internal processing in DaVinci Resolve is 32bit floating point RGB. So all input sources, video or data, in float or integer, are transformed to 32bit float. The reverse happens at the end. 10 and 12bit integer video is now considered the norm and 16bit half float interchange is becoming popular in high end productions.

There are numerous file formats that can hold 10/12 bit video and a few 16bit half float. I think a good starting point with your example files would be to see where the discrepancy starts and that may be at ingest/transform of the 8bit bars or render.

Thank you, Peter.

If I understand correctly, since DR does not operate in a Y'CbCr colorspace, all such sources will be transformed to the RGB 32-bit floating point colorspace for internal processing even if the export codec is YUV? IOW, there is no way to bypass the Y'CbCr -> RGB -> Y'CbCr pathway? This is a little surprising, and I think the reasons will be evident below.

First, a Y'CbCr source doesn't transform to RGB nicely even in a floating point space. How does DR handle out-of-gamut values like superwhites? Does it clip the values? Is a soft knee applied? This would be a potential problem no matter if the Y'CbCr source is 8-, 10-, or 12-bit. Are there any settings available to the user to tell DR how to perform this transform? Or should users as a rule transcode their footage prior to import to minimize the transformations DR will perform?

Second, RGB by definition is full chroma, or 4:4:4. Therefore, what happens when a 10- or 12-bit Y'CbCr source is 4:2:2 like ProRes? How does DR upscale the chroma channnels? Cubic? Bicubic? Lanczos? Unless DR uses something like nearest neighbor upscaling, then there is no way this can be lossless, and there will be artifacts. And similarly, how does DR subsample the chroma channels when one chooses a 4:2:2 export format?

I know my colorbars dont have any out-of-gamut values. So the first issue doesn't affect me in this particular scenario. However, I think I now understand why I see generational losses in my color bars. The upsampling from 4:2:2 to 4:4:4 is introducing artifacts into my footage. Therefore, I am hoping that there is something in the settings that gives me finer control over how DR performs this upscaling.

I really hope my questions make sense. For me, these are all crucial questions to understanding how Resolve handles my footage. Thank you for taking the time to answer them.

Resolve doesn't do anything to superwhites. They go over the scopes but the user can bring them down as needed.

Thank you. I am not sure I understand completely, but no matter. I haven't tested yet how Resolve handles out-of-gamut values in imported footage. But I assume there are some persnickety settings that one needs to be aware of so that superwhites don't get clipped, etc. That is next on my list.

Any ideas on how Resolve handles chroma upsampling/downsampling? It looks/sounds like there is no way to avoid it. Thus if you import anything other than 444 footage, you will be introducing artifacts into your footage.

Oh boy, yet another tidbit of info that adds to my confusion.

Turns out the gamma of the P3 iMac 5K is 2.2 in the Apple 'Display P3' color profile instead of the standard 2.6 gamma that DCI P3 has. This made me think of another reason why my output files are different than how they look when be edited is because Quicktime X and iOS assume 2.2 gamma while the output gamma of Resolve is 2.4.

Changing the output gamma is only possible with Resolve Studio correct? That's why the option is greyed out?

The key (which I think I said a year or so ago in this thread) is to always export a few frames of color bars and other test signals, and check the render on a scope. If the other application is suddenly using Data levels when it should be Video levels (or vice-versa), or if something is changing drastically in the render, then you'll see it on the scopes.

+1, critical to establishing any workflow for any program, from open sourced to thousands of dollars, imho.

Thanks to everyone who clarified the problem with Data Levels vs Video Levels. I agree that when dealing with YCbCr, by definition, that is Video, and the luma channel, Y, maps to [64-940] and the chroma channels, Cr and Cb, both map to [64-960]. These values are the 10-bit equivalents of the more traditional 8-bit values that leave headroom and footroom. YCbCr outside these ranges have traditionally been referred to as superwhites and superblacks, and superwhites, in particular, are often encountered in consumer camcorder footage. But I digress.

Here is my question that may or may not be related to the problems others are experiencing. When I:

1. Import my SMPTE color bars that are 8-bit YCbCr 4:2:2 (UYVY)
2. Export the color bars (no effects) as either 8-bit or 10-bit Uncompressed YUV 422
3. Import the exported bars
4. Scope them up along with the original import

What sort of error are you seeing? Check RGB values on original and transcoded. If it's below +-4 (for 10bit) than the is expected. You should not be able to see any difference by naked eye. Scope will move slightly. Resolve works in RGB, so any YUV format will be converted to RGB and even with 32bit float pipe this will show small differences in the scopes. You would have to stay in YUV to be "more precise", but this is not an option for Resolve, which uses GPU heavily (at least by my understanding). Keep in mind- Resolve comes from high-end world were people work mainly with "perfect" RAW originated sources- DPX, TIFF etc.
I've done similar test with DPX to 10bit YUV and results from different apps are very similar and always have small (with RGB picker) errors. I don't think this should worry you. If you do see difference by an eye than this is not good. Other than that: RGB<->YUV conversion is never lossless, even with 32bit float math, but this shouldn't worry you as long as it's performed accurately.

If iMovie/FCPX/Premiere can all export a file that looks identical to the one you're grading there's a way.

your automatically implying that the operator is doing nothing wrong and the error must be in resolve...

Lo and behold after updating to the final release 12.5, an imported untouched file now looks exactly the same when exported.

Still on the search to try to make the edit/color window look the same as the output file.

What sort of error are you seeing? Check RGB values on original and transcoded. If it's below +-4 (for 10bit) than the is expected. You should not be able to see any difference by naked eye. Scope will move slightly. Resolve works in RGB, so any YUV format will be converted to RGB and even with 32bit float pipe this will show small differences in the scopes. You would have to stay in YUV to be "more precise", but this is not an option for Resolve, which uses GPU heavily (at least by my understanding). Keep in mind- Resolve comes from high-end world were people work mainly with "perfect" RAW originated sources- DPX, TIFF etc.
I've done similar test with DPX to 10bit YUV and results from different apps are very similar and always have small (with RGB picker) errors. I don't think this should worry you. If you do see difference by an eye than this is not good. Other than that: RGB<->YUV conversion is never lossless, even with 32bit float math, but this shouldn't worry you as long as it's performed accurately.

Thank you Andrew for your help. The problem I am seeing is generational losses when I import, for example, a Y'CbCr 4:2:2 test signal and export it as Y'CbCr 4:2:2 without having applied any effects. As you have noted, Resolve works in 32-bit floating RGB. As long as one is operating in a 10-bit Y'CbCr 4:4:4 space, then the YUV<->RGB conversion is technically losseless. However, since my test footage is 4:2:2, Resolve must upscale the chroma channels from 4:2:2 to 4:4:4 which I presume is the source of the generational losses which is separate from the YUV<->RGB conversion. I apologize if I sound like I am being pedantic, but my question is two-fold:

1. What algorithm does Resolve use to upscale 4:2:2 footage to 4:4:4 for RGB space? Bilinear? Bicubic? Lanzcos? This is a common reason for seeing artifacts when displaying 4:2:2 or 4:2:0 content on computer displays which also operate in RGB. I am just trying to wrap my head around what Resolve is doing since it does not operate in YUV like a typical NLE. And I have yet to get a straight answer on this.

2. Is there a way to bypass (a nearest neighbor approach) or specify the chroma channel upscaling?

Your comment about DPX and TIFF formats being the typical sources is surprising because I would have thought ProRes HQ or DNxHD/HR content were perfectly suited as well. But if I take your comments to their logical conclusion, it would seem if one is starting with 4:2:2 content, then the recommended workflow would be to transcode it to 4:4:4 content prior to import into Resolve? At least, if one wants full control over the upscaling technique that Resolve will inflict on one's footage?

Can't emphasise enough that everyone needs to ditch Quicktime, it simply gets it wrong. Most noticeable with gamma, and of course that in turn affects perceived contrast and saturation. Just please use VLC...

...Just always turn off 'use mac display profile for viewers' forever...

Paul, thank you! This solved the issue for me, finally my exported file is IDENTICAL to what I'm looking at in Resolve (when viewed in VLC). Even the H.264 Vimeo preset in Resolve matches up now (when set to 'Video' levels). For anyone interested I am using a single display setup (27" iMac late 2013).

The only issue now is that when I upload to Vimeo the slight shift still occurs, and the result looks more like what I'm seeing in Quicktime 10.4. How do you avoid this Paul and get this to match up with what you're seeing in Resolve and VLC?

Thanks again!

Any YUV<->RGB conversion is lossy (at least this is what I have been told by people who design complex filters). In real image difference should be tiny.

Try exporting this:

http://madshi.net/madVR/ChromaRes.png

into 444 and 422 format in AE (e.g. DPX and YUV 10bit uncompressed)

Take it to Resolve and export back as YUV 10bit and compare to the source.

You may find that Resolve is not really good choice for direct conversion of 422/420 sources back to YUV format. You need something which stays in YUV world for this.

Can't emphasise enough that everyone needs to ditch Quicktime, it simply gets it wrong. Most noticeable with gamma, and of course that in turn affects perceived contrast and saturation. Just please use VLC...

...Just always turn off 'use mac display profile for viewers' forever...

Paul, thank you! This solved the issue for me, finally my exported file is IDENTICAL to what I'm looking at in Resolve (when viewed in VLC). Even the H.264 Vimeo preset in Resolve matches up now (when set to 'Video' levels). For anyone interested I am using a single display setup (27" iMac late 2013).

The only issue now is that when I upload to Vimeo the slight shift still occurs, and the result looks more like what I'm seeing in Quicktime 10.4. How do you avoid this Paul and get this to match up with what you're seeing in Resolve and VLC?

Thanks again!

This will be related to Viemo preview which can be slightly different in each browser.
Real test is to download Vimeo version and compare it to the source in the same software, e.g. Resolve in the same timeline. Vimeo should not shift anything (you may just see smoothness due to compression).

This will be related to Viemo preview in browser which can behave differently in each browser.
Real test is to download Vimeo version and compare it to the source in the same software, e.g. Resolve the same timeline. Vimeo should not shift anything (you may just see smoothness due to compression).

Hi Andrew,

The preview/initial load image looks identical to video playback when using Safari (Vimeo) and I do not see a shift between the load and playback at all.

Chrome and Firefox however do have a hue shift when I hit play. Their previews both match Resolve and VLC but playback doesn't match anything.. other than each other.

What a minefield. I can't seem to get any video playback in any browser to match up with what I'm seeing in Resolve and VLC.

Mac is terrible for this. On PC it's easier to have some constant results.
I don't trust VLC on Mac. Your exported e.g. ProRes on Mac needs to have color info in MOV headers (latest Resolve update adds it- should be there from day 1). Then another thing is your display profile setup in the Mac settings. If your profile is set to Rec.709 and headers in MOV also says Rec.709 than QT X should not touch your video and this should match Resolve preview. If your profile says sRGB than OSX will do conversion to "correct" mismatch between MOV headers and OSX settings. If MOV has no headers info then things complicate even more.
In case of VLC whole color management is not respected (which is maybe helpful), so that's why you see same result as with Resolve (with color profile turned off).
When it comes to browsers same story applies- different browsers will respect or not whole OS X color engine, so things may look very different for each browser It's a bit of a nightmare. Add to this fact that all Mac screens crush black details (compared to external monitors) and you have real roller coster, specially if you use reference SDI monitor.

Mac is terrible for this. On PC it's easier to have some constant results...

Oh dear. Well unfortunately I am stuck with a Mac for now, and the majority of my clients view this content on Vimeo, via Safari ..on a Mac.

So.. I guess my question at this stage is: Is it even possible to get what I'm seeing in Resolve to look anything like what I eventually see in Safari? Am I going to have to adopt some sort of +Contrast adjustment prior to export?

What if you set color profile in the display setting to Rec.709 (Rec. ITU-R BT.709-5) and watch HD version on Vimeo?

What if you set color profile in the display setting to Rec.709 (Rec. ITU-R BT.709-5) and watch HD version on Vimeo?

Within my system pref colour settings or within Resolve itself?

In Mac settings.

In Mac settings.

My only concern with shifting system colour is that most clients will view my content on Vimeo in Safari with 'out of the box settings' Mac's. So what I currently see in Safari is at least somewhere in the ballpark of what they are seeing.

In Mac settings.

My only concern with shifting system colour is that most clients will view my content on Vimeo in Safari with 'out of the box settings' Mac's. So what I currently see in Safari is at least somewhere in the ballpark of what they are seeing.

That is a common issue: if i do something in HD, any TV out there (out of the box) will look different. It is advisable (and recommended) to set the monitor to the standard (or closer to) and let the variation be in the field.

If you don't do that, your error can accumulate and generate very unpredictable results.

That is a common issue: if i do something in HD, any TV out there (out of the box) will look different. It is advisable (and recommended) to set the monitor to the standard (or closer to) and let the variation be in the field.

If you don't do that, your error can accumulate and generate very unpredictable results.

Hi Walter,

I completely appreciate that once it's out in the wild you really have no control but my issue here is that there is a mismatch on the same display between Resolve and Safari/Vimeo. Correct me if I'm wrong but even if I change my system colour settings this mismatch will still exist as they will both just shift accordingly. If it's wrong in Safari on my calibrated display to start with then what hope do I have of it looking correct on anything else?

If it's wrong in Safari on my calibrated display to start with then what hope do I have of it looking correct on anything else?

There is no hope of anything looking 100% right once out in the wild. All you can do is work to standards on calibrated displays. This minimises the variations, you are diverging from a centre point of accuracy. If you start making adjustments for a particular specific delivery combination you are making an assumption that a shift you are seeing is universal (it probably isn't, it could be down to OS, safari version, your monitor, ColorSync settings, graphics card drivers), and that combination makes up the majority of your audience (it probably doesn't). In making adjustments to target a specific delivery medium you inevitably make all the other delivery combinations less accurate (ie Vimeo in other browsers, on windows, through an appletv,).

I always think about it like this: something mastered to calibrated standards, if played on a screen that is a bit blue, will look a bit blue, on a tv that is a bit warm, will look a bit warm. If you target the screen that is a bit blue, and warm up your grade to compensate, it will look better on that one cooler display. But it will look extremely warm on the warmer display, and in addition will look wrong on accurate displays. Targeting one medium always makes things less accurate overall.

I think a big part of all of this is perceptual — you have a much stronger sense of right and wrong on a piece you have graded yourself, so you can see all the variation easily, and it's troubling. Watch someone else's project, and it just looks great - you have no mental standard to compare it to - you don't see the lifted gamma, the blue shift, the extra contrast that is affecting everything you look at on your laptop. This contributes greatly to the feeling that something has gone dramatically wrong with your project alone, that you need to fix.

I had a moment of clarity a while back, in a queue at the cinema. There were a bank of 10 screens playing trailers. Wildly different calibrations. The image was all over the place. But they still looked like high end, well graded, Hollywood films. Good grading is very durable, it will survive a lot more variation in presentation than you think.


Sent from my iPhone using Tapatalk

If it's wrong in Safari on my calibrated display to start with then what hope do I have of it looking correct on anything else?

There is no hope of anything looking 100% right once out in the wild.

Thanks for the input Daniel, some great points there.

Just for the sake of argument let's say you are grading in Resolve, you are on a Mac, you export and upload to Vimeo. You compare Safari to your Resolve timeline (on the same device) you notice Safari/Vimeo looks flat and less saturated. Now let's say you compare this same upload with a MacBook Pro, an iPad and a couple of iPhones, and while there is indeed variation they all share the flat/desaturated look of Safari/Vimeo, none of them are similar to what you see in Resolve.
Now let's say that you know your client will be viewing this content in Safari, on apple devices. At this point would you not then dial in some form of compensating correction so you know they will see something that is at least close to the original or do you still accept that your Resolve grade is correct and nothing else is going to match it?

It is very frustrating that FCPX Timeline, QuickTime Player and Vimeo/Safari all match up.

Hi there. i don't read the thread yet, but last week i find some interesting things about color shifts in OSX.
First of all It highly depends of custom monitor ICC profile type and the monitor calibration app.
Seems some apps when monitor brightness is too high generate a profile with additional correction of tone curve in dark area and in OSX there is no common method to read this curve. Some apps (VLC, Firefox) use it for correction of deep darks as expected, but native OSX color managed apps (QuickTime, Safari) read this curve in very strange way and looks like they try to fix it to straight line and this all cause shifted ugly darks. Adobe apps with Adobe CMM seems ignore this gap at all. Same mess happens with custom gamma setting in icc profile - some apps can implement gamma 2.4 as darker value but some may do the opposite. LUT profiles are even more unpredictable.

Its a shame that for so many decades Apple still can't standardize color management in various apps and systemwide.
So today unfortunately for better compatibility it is better use a simple matrix profile with gamma 2.2 without any tweaks, or use Windows where is cmm not so advanced but surprisingly way more standardized than in OSX.

Screen-Shot-2016-10-12-at-3.53.26-AM.jpg (118.86 KiB) Viewed 21655 times

In OSX Sierra things may be better https://developer.apple.com/videos/play/wwdc2016/712/
There is also tons of buzz about same problem
http://lagemaat.blogspot.com/2014/09/co ... en-in.html
https://discussions.apple.com/message/29674571#29674571
https://github.com/mpv-player/mpv/issues/534
https://github.com/mpv-player/mpv/issues/2815
https://vitrolite.wordpress.com/2010/12 ... gamma_bug/

With Vimeo and Safari I think the danger is not having a a large enough sample size, accurate measurement, or enough control of all the other variables ( What brightness level are the iPhone and iPad set at? How do you isolate the shift you are trying to observe in the footage from the inherent differences in the displays?). It's very easy to assume a couple of iPhones, your computer, and your iPad are representative. But the main problem is: If you are in a situation where you want to see a consistent elevation across all three (because you want this to be a solvable problem, rather than just an unavoidable inconsistent issue that affects all colour grading), you will persuade yourself you see it, and see it consistently. There are a lot of assumptions involved in deciding a shift is universal, worth compensating for, and making that compensation. It feels like you are solving a problem, based on solid evidence. Really you are just making an arbitrary choice based on limited information.

The only time I'd feel comfortable targeting a specific viewing environment / system would be in a gallery / site specific installation type situation - how can we get this file, played through this particular device, through this projector, in this environment looking as good as possible. Also, I know many people do a gamma conversion from 2.4 to 2.2 for web based deliverables - I'm comfortable with this as it's a choice between whether some of your audience sees a project with elevated midtones vs lowered midtones - with a youtube video I am confident a gamma 2.2 viewing environment outnumbers one at 2.4.

Embrace the inconsistency of viewing environments. It is out of your control, and it effects everyones work the same way. Focus on your own working environment and making that as consistent and calibrated as you can, because that is something you can control. And the more precise your work is, the better chance it has out in the world; not of being completely accurate, but of being as close to accurate as is possible, in as many different situations as possible.

Embrace the inconsistency of viewing environments. It is out of your control, and it effects everyones work the same way. Focus on your own working environment and making that as consistent and calibrated as you can, because that is something you can control. And the more precise your work is, the better chance it has out in the world; not of being completely accurate, but of being as close to accurate as is possible, in as many different situations as possible.

Daniel is very wise, and I think he puts the idea across very well.

I would also observe that not only are Mac and Windows different, but you'll also see slight differences in Safari vs. Firefox vs. Chrome. On the other hand, the differences between a new laptop vs. an old laptop vs. a Dell monitor vs. an Apple monitor vs. an iPad vs. a Microsoft Tablet will be even bigger. The hope is that the final image will translate well across multiple platforms. When there's a change (in color temperature, in brightness, in contrast, whatever), one hopes it'll be consistent and something the viewer can mentally adjust for.

If it makes you feel any better, sound changes even worse than picture.

I spent about a year (at one of the biggest VFX houses) fighting with this problem. There is no real solution for it. If you for example use grading monitor and want client to see "the same results" at home you can ask to use iPad for previewing. Based on test done by A company consistency between iPad screens is quite good, so when you compensate for it then at least you know that it will look close to reference regarding iPad unit (assuming same model).
Same story 1000 time. One thing which you can make sure is that neither your export, nor youtube upload etc shifts colors during conversion and this is key point here. When client complains you download youtube clip, put it on timeline next to your master and show that they are the same in terms of colors (client is very surprised and even so will still say: but...). Any differences are due to screens settings/imperfection and there is NOTHING what you can do about it.
Most common case for me was- to dark on Mac screens. This is something you can compensate for during grading, but it's about pointless because enough to have external screen connected to Apple machine and it will look to bright in shadows Good thing is that on PC side with decent screen things look much closer. You can't win with it, work to a standards on calibrated screens. If client wants something to look good on Mac screen makes sure he is aware of all consequences which come with grading to a specific screen not a standard and calibrated screen.
You can try to solve it for yourself using different browser etc, but as someone said- client uses A browser and he doesn't care/want to hear about doing something different. You need to work per client and per case, don't try to find overall solution as it doesn't exist.

So am I now correct in thinking that it is impossible for Safari/Vimeo to accurately display what I am seeing in Resolve? Even on the same device under the same viewing conditions?

If they don't look the same not much what you can do about it as you have not much of a control over it.

With Vimeo and Safari I think the danger is not having a a large enough sample size, accurate measurement, or enough control of all the other variables ( What brightness level are the iPhone and iPad set at? How do you isolate the shift you are trying to observe in the footage from the inherent differences in the displays?)

Thanks Daniel, that all makes perfect sense, and I appreciate the input here. But lets just remove all other variables for the moment and just discuss the shift that occurs on the same device/monitor/environment as this is where my current frustration lies. For example, does your 'Colour Grading Reel 2015' (which is most excellent by the way!) look the same to you as it does in Resolve when played back in Safari via Vimeo?

Also, I know many people do a gamma conversion from 2.4 to 2.2 for web based deliverables - I'm comfortable with this as it's a choice between whether some of your audience sees a project with elevated midtones vs lowered midtones - with a youtube video I am confident a gamma 2.2 viewing environment outnumbers one at 2.4.

How would you go about this? Is it something I can control during the Resolve export process or does it have to be converted at a later stage?

For anyone interested, I have compared the same file on the same display in all browsers, media players and NLE's available to me on the same device. I repeated this within both Yosemite and El Capitan and this yielded the same results.

Here are my findings:
https://dl.dropboxusercontent.com/u/526 ... iation.jpg

As you can see, everything Quicktime is identical.

I look forward to hearing what you guys make of this, do you have similar results?
Do we just have to accept that this is how it is and the only seemingly consistent workflow really is Quicktime/FCPX/Safari.. albeit constantly wrong?

Can of worms released.

For anyone interested, I have compared the same file on the same display in all browsers, media players and NLE's available to me on the same device. I repeated this within both Yosemite and El Capitan and this yielded the same results.

Here are my findings:
https://dl.dropboxusercontent.com/u/526 ... iation.jpg

As you can see, everything Quicktime is identical.

I look forward to hearing what you guys make of this, do you have similar results?
Do we just have to accept that this is how it is and the only seemingly consistent workflow really is Quicktime/FCPX/Safari.. albeit constantly wrong?

Can of worms released.

the contrast look like a full range to video range issue.

the contrast look like a full range to video range issue.

I don't know about the 5D mk III but there were some legal/data issues with the 5D mk II. The level metadata wasn't flagged and programs would interpret the levels wrong.

QT X preview is changing with monitor color profile on Mac.
I managed to get exactly the same ProRes look in VLC and QT X, by using Rec.709 profile saved from my Sony Tv. This is based on 1.961 gamma. This gives exactly the same look between QTX and VLC. ITU Rec.709-5 profile (based on hybrid 2.22 gamma) also gives the same colors, but gamma is different. Similar effect is with sRGB profile. This is why so many people are seeing contrast changes- this is OSX correcting gamma difference between file headers and screen profile.
This also suggest that VLC on Mac uses 1.961 gamma.
Screen profile setting (+fact if application is separated from OSX color engine or not) will be key point for all the different looks.
This whole color engine meant to be good thing, but in reality it causes more problems than good things.

For anyone interested, I have compared the same file on the same display in all browsers, media players and NLE's available to me on the same device. I repeated this within both Yosemite and El Capitan and this yielded the same results.

Here are my findings:
https://dl.dropboxusercontent.com/u/526 ... iation.jpg

As you can see, everything Quicktime is identical.

I look forward to hearing what you guys make of this, do you have similar results?
Do we just have to accept that this is how it is and the only seemingly consistent workflow really is Quicktime/FCPX/Safari.. albeit constantly wrong?

Can of worms released.

the contrast look like a full range to video range issue.

It's gamma difference related, not range.

the clipping in highlights/lowlights suggest otherwise

Edit: I'm looking at the lower left image...

the clipping in highlights/lowlights suggest otherwise

In which examples are you referring to Walter? The difference between the Quicktime examples and Premiere/Resolve or the more extreme shifts of VLC and Chrome?