Color Grading on Mac

I have a video that looks just like I want in the viewer on my iMac, but when I go to output it is less saturated or vibrant. I am assuming there is a difference in the color profile of Danvic vs Quicktime player. I cannot see where you set the color profiles.

In the project settings under color management you can set the timeline and output color space. On my iMac Pro I set them to Gamma 2.2 instead of the default 2.4 to solve this. Even so, the same clip looks different if I use QT player or VLC.

Do a search for Broadcast Monitor and you will find approximately 1 billion related posts.

You can't depend on an iMac display...or a quick time display.

From the question I assumed the videos were only going to be shown on a computer/tablet/whatever, not for broadcast.

From the question I assumed the videos were only going to be shown on a computer/tablet/whatever, not for broadcast.

You are correct. I know that there is a difference between my iMac and broadcasting. For that matter, there is a difference from monitor to monitor. I just want to get the same color when editing in DR and viewing in QT. Since it is the same monitor I thought that is a real possibility.

Assuming you're not talking about QT 7 anymore, you can try going to Pref Sys > Monitor of OSX and choose rvb in the preference; then do the same in color science of Resolve for TL and output.
Let's say you're increasing chances to see the same in the Resolve viewer and in QT X after export...

Use color managed viewers in Resolve to get it closer (specially on P3 screens).
QT X wil show you rendered files differently because it's relying on Rec.709 flagging to convert video to screen profile. This is fixed math based on 1.96 gamma, so your 2.2 or 2.4 based master will never match Resolve preview. In this case it's not necessarily Resolve which is showing wrong preview, but QT X. Problem here is related to fact that OSX and its video/color management engine is limited.

Do you mean the “Use Mac Display Color Profile for Viewers“ option? So assuming the timeline, viewer, and output are set to rec 709 and gamma 2.2, when Quicktime X plays the clip on a screen calibrated (in my case with an x-rite) at gamma of 2.2, Quicktime will still be assuming that 1.96 and still make changes?

The more I read about the subject of video profiles, the more I consider sticking to still photography.

Erich

Yes, it's this setting.
Problem is that Resolve viewer will be color managed and what you see will be converted from project settings (eg. Rec.709 2.4 gamma) to display profile by OSX color engine.
Then QT X preview will be also color managed, but Rec.709 MOV flagging will be converted to display profile using 1.96 gamma (not 2.2 or 2.4 as used in Resolve). It's due to limited possibilities of color tagging in MOV.
If you use eg. mpv player (where you can set custom gamma for color management) then it will match Resolve preview. There is a way to force QT X to use other gamma (eg 2.2 will work), but it requires knowledge and 3rd party tools for editing MOV headers.

There is a way to force QT X to use other gamma (eg 2.2 will work), but it requires knowledge and 3rd party tools for editing MOV headers.

I think Resolve should really start handling that itself, if BMD wants Resolve to become a one stop shop, rather than having to go to outside tools for export to the real-world consumer.

Despite their name, Blackmagic needs some form business model to keep going (if they are not supported by forces more evil than capitalism).
If they can't sell electronic I/O devices too, you would need to pay quite a bit more for the software.

There is a way to force QT X to use other gamma (eg 2.2 will work), but it requires knowledge and 3rd party tools for editing MOV headers.

I think Resolve should really start handling that itself, if BMD wants Resolve to become a one stop shop, rather than having to go to outside tools for export to the real-world consumer.

Read pp. 667-668 of the Resolve 14.3 manual: "Limitations When Grading With the Viewer on a Computer Display." This goes into some detail why you cannot accurately monitor directly from the computer and operating system. You have to have a color-managed output, like one from a Blackmagic display card, preferably on a calibrated Rec709 display.

That section just leads to more confusion for me, probably given my lack of practical experience in this area. The big disclaimer in the manual there "NOTE: custom calibrated .icc profiles are not supported at this time." seems like a huge oversight.
What's the difference if I'm using my iMacPro calibrated with an X-Rite iDisplay Pro using the BT.709 workflow to create an icc profile and applying that in Resolve to the viewers vs an external calibrated monitor. They're both being calibrated to the same spec, so why not be able to set everything in Resolve so that it is as closely as possible a "what you see is what you get" in the color page viewers? Using an external display was obviously a necessity in the past, but with so much content being developed that will never be viewed on a standard TV or in films, it seems that kind of workflow should be possible.

There is a way to force QT X to use other gamma (eg 2.2 will work), but it requires knowledge and 3rd party tools for editing MOV headers.

I think Resolve should really start handling that itself, if BMD wants Resolve to become a one stop shop, rather than having to go to outside tools for export to the real-world consumer.

Read pp. 667-668 of the Resolve 14.3 manual: "Limitations When Grading With the Viewer on a Computer Display." This goes into some detail why you cannot accurately monitor directly from the computer and operating system. You have to have a color-managed output, like one from a Blackmagic display card, preferably on a calibrated Rec709 display.

All of this is irrelevant to the actual problem of preview difference between Resolve viewer and QT X ( they should match).
Fact that both may be inaccurate is yet another story, but we don't care about it here as all what is needed is same preview between QT X and Resolve (when I grade my holiday videos I watch them only on my Mac screen so I don't care about reference preview). This is not really Resolve issue though.

There is a way to force QT X to use other gamma (eg 2.2 will work), but it requires knowledge and 3rd party tools for editing MOV headers.

I think Resolve should really start handling that itself, if BMD wants Resolve to become a one stop shop, rather than having to go to outside tools for export to the real-world consumer.

It's much bigger problem. It's lack of reliable technology on OSX or WIN to display videos taking into account their different color spaces (+headers flagging!) and also display settings/possibilities.
Another issue is the we use Rec.709 with 2.4 gamma which is actually something "made up".

When it comes to MOV videos OSX color engine does understand few flagging combinations (some combinations from this tables: https://github.com/bbc/qtff-parameter-editor), but not exactly the ones which are commonly used, so this the problem. You can't reliably flag file as Rec.709 with 2.4 gamma. OSX engine doesn't process this properly, which is exactly why Resolve preview is different than QT X. Your option is to use different than QT X player (which you don't want as it's default player) which can be forced to use same "math" as Resolve does in its viewers. mpv allows for this as it does use OXS color engine and also allows to overwrite file flagging and force it to use eg. pure 2.4 based gamma curve.

"PRO" solutions are not any better- they all rely on manual user setting. When pro colorists grade they have settings in grading tool set manually. They also manually set monitor to correct preset- Rec.709 2.4 gamma, P3 D65 etc. It's not like in pro world it all works well automatically. Not only it doesn't work automatically it's also even further limited with only few choices (sometimes you even have the set eg 4:2:2 sampling on both sides). You can't expect this from home users, but unfortunately up to today neither OSX nor WIN provide reliable enough technology which could guarantee accurate (at least to the flagging) playback.

Recent introduction of HDR with PQ and HLG options is a very good example. Flagging was added to HDMI spec so TVs can switch accordingly, but many solutions are not ready, so this information is not passed to the actual TV. Resolve does it, but eg Premiere/Edius+BM card don't, so it all falls apart again and people can't use them to monitor HDR (add funny fact that most TVs can't be even switched manually to HDR mode).

@OP, This is exactly the problem I've been having. I love the image inside Resolve and spent a considerable amount of time "perfecting" the image I want, but the output video is horrendously mis-colored. NOT WHAT I SAW IN RESOLVE WINDOW.

I don't have this issue with Premiere, but Premiere... is no Resolve, so, is there a solution?

What are some setups you guys are using to get the results you want from Resolve? (i.e. external monitors, sys prefs, LUTs, etc)

If you make videos for client then you need to use calibrated external display with BM card. At least then it's done to some standard/properly monitored, so any difference will be due to different monitor/viewing.

If you doing it for yourself and want your video look "nice" on your Mac screen (played with QT X) then this is bit tricky. You either create custom viewer LUT which will let you see in Resolve same as later with QT X or you can use Rec.709 with 2.2 gamma and after ProRes export re-flag your file to correct settings (which is easy once you have tools and knowledge). This will then give you QT X identical look like in Resolve viewers.

I've just checked latest Resolve and it actually now tries to add custom gamma headers instead of always using Rec.709 (1-1-1) flagging. Looks like BM did read my old post

Problem is that Rec.709 with 2.2 gamma is flagged 1-4-1 which is:
Rec.709-Gamma 2.2 curve-Rec.709
As far as this may look correct QT X and OSX color engine doesn't like it.
It needs to be flagged as 1-2-1 (Rec.709+unspecified transfer function, which is 2)+ additional old gamma tag should be set to 2.2. This is then treated as Rec.709 with 2.2 gamma and 100% matches Resolve preview. Same flagging for 2.4 gamma is still not 100%- very end is darker in Resolve preview. Maybe it has something to do with BT.1886.

update: I re-checked it and 2.4 gamma also gives 100% same preview in Resolve 15 (and OSX 10.13.4), so it's good news.

OSX Color Engine understands those values in MOV header:

Video Characteristics: 1,5,6,9,11,12
Transfer Function: 1, 2- so this is either Rec.709 or unspecified (nothing more is properly processed). When value 2 is used then MOV needs gamma header to be present and set to some value, eg. 2.2
Colour Matrix: 1, 6,7,9,17

Sometimes if value is unsupported it shows it as 2 in File Info.
Here is what these values actually represent:
https://github.com/bbc/qtff-parameter-editor

Looks like BM did read my old post

I guess it is a bit complicated but it looks like BMD really are listening and I'm hopeful that the Delivery page will improve further. You're investigations have made this Topic worth a bookmark for later reference, thanks.

What's the difference if I'm using my iMacPro calibrated with an X-Rite iDisplay Pro using the BT.709 workflow to create an icc profile and applying that in Resolve to the viewers vs an external calibrated monitor.

Number one, the monitor is crappy. Number two, if somebody goes in and changes the brightness of the display in the control panel, you won't get an accurate picture. Number three, the uniformity of the display is going to be suspect. Number four, I'd like to know your calibration procedure, because this is fraught with problems. Calibrating a computer display is tough even with great software and a great probe. I had a display calibrated a couple of weeks ago and I believe the engineer used somewhere north of 2000 calibration points and it took more than 24 hours to do. This is not for the faint-of-heart.

@OP, This is exactly the problem I've been having. I love the image inside Resolve and spent a considerable amount of time "perfecting" the image I want, but the output video is horrendously mis-colored. NOT WHAT I SAW IN RESOLVE WINDOW.

Bring the rendered video into Resolve and A/B it with the original file using the scopes. If the image does not change, then there is no change. One huge problem is the player itself (plus the operating system) will affect the image under many conditions. Unless you know what the player is doing and how the signal is affected before it reaches the monitor, you're completely flying blind. Disregard my advice at your own peril.

Again, all this is standard Color 101 stuff, very basic, very much a beginner's thing that's been covered here for years and years. And it's covered in the manual, as mentioned before. We've been there/done that so many times, it's almost uncountable (though you can try if you use the search function within the forum). If you want a longer, more in-depth discussion of why and how playback color works inside a computer system, and why an external monitor makes more sense, read Alexis Van Hurkman's excellent book Color Correction Handbook. (Know in advance that Alexis also wrote most of the Resolve manual, so the advice will be similar.)

If you don't believe in all of this, just try playing the same footage im QT Player and in VLC. See?

@OP, This is exactly the problem I've been having. I love the image inside Resolve and spent a considerable amount of time "perfecting" the image I want, but the output video is horrendously mis-colored. NOT WHAT I SAW IN RESOLVE WINDOW.

Bring the rendered video into Resolve and A/B it with the original file using the scopes. If the image does not change, then there is no change. One huge problem is the player itself (plus the operating system) will affect the image under many conditions. Unless you know what the player is doing and how the signal is affected before it reaches the monitor, you're completely flying blind. Disregard my advice at your own peril.

And this is exactly what the problem is, but it's not impossible to sort out (impossible mission is to have same look on all consumer monitors). BM+Apple can solve it if there is enough willingness.
Apple needs to add more "supported" flagging options and BM have to correctly set them during export. Problem solved- Resolve viewer will match QT X preview (do they match reference preview or not is a different story).

Well. my work-around flow

edit in Premiere
grade in Resolve,
screen capture the graded image (from Resolve)
use color match in premiere.



I'll let you know if this works.

read Alexis Van Hurkman's excellent book Color Correction Handbook. (Know in advance that Alexis also wrote most of the Resolve manual, so the advice will be similar.)

Thanks, I will. I'm working my way thru the manual and the "Definitive Guide to resolve 14" and that will be next on the reading list.

You can read it as it's most likely full of good knowledge, but it won't sort out this problem.
If you understand it then it's enough. Color science or grading techniques etc. won't bring anything new to this.

Well. my work-around flow

edit in Premiere
grade in Resolve,
screen capture the graded image (from Resolve)
use color match in premiere.



I'll let you know if this works.

Premiere preview is not color managed, so it's also different than QT X preview. On P3 screen difference is like day and night. Premiere is about useless for correction on P3 based Macs (without external monitoring). Adobe promised to solve it, but I did not check latest version.

update: very latest Premiere (12.1.1) preview is still color unmanaged.

OK, I had no idea the current iMac displays were so bad with the Apple-Display P3 specs, but then I guess it depends on what you're comparing it to. I fully acknowledge a pro reference monitor painstakingly calibrated by a pro using expensive equipment will shine, but at the moment we're talking about getting as close as we can as consistently as we can using the gear we already have to eliminate the variables we can control.

VLC seems to be closer than QT to the Resolve viewers although still not exact, so I'm assuming it more properly reads the flags similarly to the MPV player already mentioned and unlike QuickTime X. I have also gotten QT much closer by calibrating my iMac screen with the X-rite i1Display Pro using the rec.BT709 gamma 2.2 calibration workflow and setting the Resolve timeline and output color to rec709 gamma 2.2.

The question becomes, would using something like DisplayCAL to calibrate the screen and create a corresponding Resolve viewer LUT using the iDisplay hardware get us any closer to solving the problem of the Original Poster (and me) of getting the viewers to more closely match the output when displayed on the same computer? Would this basically be the same as having Resolve use the calibrated custom display icc (which Resolve currently does not support), and eliminate the variable of QT possibly not reading the flags correctly without having to manually re-flag the output files as already mentioned?

Mac screen are very good as consumer grade. They just lack the hardware calibration and other features supported by eg. Eizo, NEC etc. (good uniformity, many refresh rates etc.).
As I said- it all depends what you do. If you want to make your holiday videos look nice on your Mac screen then they are very good (I really like look of my work Macbook Pro with P3 screen). They are not crazy far from reference screens, but for pro work you definitely want something what can be calibrated and is more broadcast orientated (or decent TV).

You should separate need for accurate preview on reference screen from the problem with Resolve preview vs. QT X.
If you just want to get best of your Mac's P3 screen and match Resolve preview with later QT X (which you use for watching your videos) then use P3 D65 with 2.2 gamma Resolve setting (so you make use of Mac's P3 gamut) and later re-flag your exported MOV (PM me to find how to do it). Of course at this point you have something quite custom and it will work well only on your P3 screen.
If you do work for clients then get BM card and calibrated TV/monitor and work to Rec.709 2.4 gamma.

VLC uses unmanaged preview which on non-P3 screens will be close to Rec.709 2.2 gamma. On P3 screens its preview will be crazy oversaturated and unusable. Those P3 screens do need managed preview due to having wide gamut. They are definitely nice, but in the same time cause issue due to mentioned OSX limitations.

The question becomes, would using something like DisplayCAL to calibrate the screen and create a corresponding Resolve viewer LUT using the iDisplay hardware get us any closer to solving the problem of the Original Poster (and me) of getting the viewers to more closely match the output when displayed on the same computer? Would this basically be the same as having Resolve use the calibrated custom display icc (which Resolve currently does not support), and eliminate the variable of QT possibly not reading the flags correctly without having to manually re-flag the output files as already mentioned?

Proper solution is to "force" QT X to use same math to go from video to screen as Resolve uses.
All what you need in this case is small re-flag on exported Resolve ProRes file.
I've re-checked it and 2.4 gamma also gives 100% same preview, which is great news.
Now we just need BM to do one more evaluation and correct flagging again.
It needs eg. 1-2-1 (Rec.709-unspecified transfer-Rec.709) + old gamma tag set to what is in the project, so 2.2 or 2.4.



Custom gamma tags (2.2, 2.4 and 2.6) work fine with Rec.709 as well as with P3 D65 color space.
In case of 2.6 gamma there is no need to do re-flagging as default Resolve exported one (eg. 1-17-1 for Rec.709) is properly recognised by OSX color engine. If you do re-flag it to 1-2-1 plus 2.6 for gamma then preview is identical.

In response to the OP, and without currently having the time to properly read all the many responses, I've found that in order to get QTX to match the Resolve viewer, you should have the timeline colour space set to the colour space of your monitor (P3 D65 for your iMac?) and the output colour space should be set to Rec709 Gamma 2.4 (obviously this is just for when it comes to the export; also note that your footage would have to have the same input colour space (or bypass) as the timeline for this to work as expected). Or alternatively have this as a temporary timeline grade and then you don't need to worry about input colour space settings.

Now I don't know if this is something that is strictly correct, I just know that it's a pretty decent (though not 100%) match, which for the purposes of the OP should be good enough. The fact it isn't identical may be to do with gamut mapping, I found a highly saturated original image to be too saturated in the shadows for my conversion, but I exported it in Resolve 12.5 and not 14/15 so I couldn't tell for certain since 12.5 doesn't have gamut mapping as an option. Or it may be to do with another matter that someone else has already mentioned.

On another note, I've found that despite not being 'correct', QTX shows images that are identical to what you see on YouTube, allowing for minor differences resulting from compression. So it's certainly worth taking into account as a viewing platform.

This will only let you avoid over saturation on Rec.709 screens/TVs for files graded in Resolve GUI with P3 screens. It's far from perfect solution.

In response to the OP, and without currently having the time to properly read all the many responses, I've found that in order to get QTX to match the Resolve viewer, you should have the timeline colour space set to the colour space of your monitor (P3 D65 for your iMac?) and the output colour space should be set to Rec709 Gamma 2.4 (obviously this is just for when it comes to the export).

no -- i don't think, it would be a wise idea, to modify the timeline colorspace just to satisfy your GPU screens requirements. IMHO the timeline colorspace should be correspond to the final deliveries or an intermediate representation (like ACES lin/log) which may provide some benefits regarding the actual image processing capabilities.

the translation between this internal image colorspace resp. video data representation and the output on your GUI display is one of the task, a video processing application simply has to provide in some satisfaying manner. and in case of resolve this will be done by some operating system specific color management services resp. transformation information provided by the operating system on mac os in a much more satisfaying manner than on the other two platforms. sure, as andrew already mentioned, it still may not be seen as the perfect solution even on this OS, but it's at least a much more satisfaying compromise, than do not have any kind of useful color management capabilities resp. accurate color rendition on the GUI screen at all.

In latest OSX and after custom flagging we have now working management- at least for Rec.709/P3/Rec.2020 and standard gammas.

Hi Andrew, maybe I missed something in this thread, but how do you custom flag?

You need a tool for MOV headers adjustments (eg. https://www.digitalrebellion.com/promedia/) or mediainfo+hex editor

Thanks!

Not sure if https://www.digitalrebellion.com/promedia/ allows for custom flagging.
You also have this:

https://github.com/bbc/qtff-parameter-editor

Perfect, thanks again!

VLC seems to be closer than QT to the Resolve viewers although still not exact, so I'm assuming it more properly reads the flags similarly to the MPV player already mentioned and unlike QuickTime X. I have also gotten QT much closer by calibrating my iMac screen with the X-rite i1Display Pro using the rec.BT709 gamma 2.2 calibration workflow and setting the Resolve timeline and output color to rec709 gamma 2.2.

What software are you using for calibration?

The simplest advice is to just ignore QuickTime player and believe what VLC is showing you. If VLC and Resolve match each other, then Apple QT is the odd man out here.

One huge problem with color-correction in general is essentially, "which standard do you believe?" followed closely by "which monitor do you believe?" If you don't have a handle on answers to both of these questions, you can endlessly search for a solution that's never really going to happen. And again: Watch Resolve on 5 different displays out of the box and tell me how different it is. It's the Wild West out there. Sound mixers have a similar problem in that a million-dollar surround mix can sound one way on a laptop, another way on TV, another way in the theater, and another way on earbuds. Which is telling the truth? What if they're all wrong in different ways? Picture monitors and color management present the same problem, and people have been struggling with this for many decades.

And many sound people have a cheap Ghettoblaster sitting next to their expensive speaker system just because of that…

The simplest advice is to just ignore QuickTime player and believe what VLC is showing you. If VLC and Resolve match each other, then Apple QT is the odd man out here.

If anything, VLC is wrong here.

There is actually no issue in latest OSX and QT X as long as file is properly flagged, which is key part here. This makes perfect sense- you can't have files with 5 different actual content types (Rec.709 2.4, Rec.709 2.2, etc) use same flagging. It's obvious only 1 or none (if flagging is not matching what Resolve project was set to) will ever match.
Again- this still doesn't guarantee accuracy against reference monitor. For this you need calibrated display first and then worry if preview is correct or not.

Here are two (the same) files, but 1 is Resolve default flagging and 2nd is re-flagged to Rec.709 2.4 gamma, which is what was used in Resolve project setting.

If you setup Resolve color managed project with Rec.709 2.4 gamma, load footage and set input color space to "Project (Rec.709 2.4 gamma)" or "Bypass" then you should see that for re-flagged one QT X preview will 100% match Resolve preview, where default in QT X will look nothing like in Resolve (of course in Resolve both look the same). Resolve has to be set to: "Use Mac Display Colour Profiles For Viewers".

https://drive.google.com/open?id=1edy4T ... Qyl-Yz6pYM

Watch Resolve on 5 different displays out of the box and tell me how different it is. It's the Wild West out there. Sound mixers have a similar problem in that a million-dollar surround mix can sound one way on a laptop, another way on TV, another way in the theater, and another way on earbuds. Which is telling the truth? What if they're all wrong in different ways?

This is one of the conundrums in using reference monitors for material that is destined only to be viewed online. A reference monitor is the one piece of equipment that your target audience is almost guaranteed not to own, so from that perspective it would seem slightly insane to use a reference monitor for color grading if your entire audience will be viewing on web browsers and phones. But because consumer monitors (including phones) vary so widely and there's nothing that could be considered "representative," picking any one consumer monitor makes little sense either because only the portion of your audience who uses that particular monitor will see your intended results. If you use a 5K iMac as your "reference monitor," only people who use a 5K iMac will see your product as you intended it to look (and even then there will be variations across monitors).

It's a no-win situation, but I still think the usual arguments for using a reference monitor still hold true even if you are ouputting only for the web and are a one-person shop doing editing, sound, and color.

Web designers have long wrestled with this kind of problem on a smaller scale: web browsers are more standards-compliant than they used to be, but you still have to serve up different style sheets for different browsers, especially Internet Explorer, which never did a good job of following standards. Web pages have "sniffers" in their code that detect what browser you're using and give you the appropriate style sheet or insert hacks to make the page display as intended. Could the same kind of thing be done for video, I wonder? The web page or app detects what monitor you're using and uses that information to provide the originally intended colors. Probably impossible given the huge range of monitors out there.

Well this is exactly the problem- do you follow reference look or some "other" one. I also think it's always good so see footage on reference monitor and then make decision to adjust it for "other" look or not. I don't think there is an easy answer for this.

With last years Mac's screens it's not that bad at all as they do match quite well not only between units but also different models. I have early 2015 13inch one and 2016 P3 screen 15inch and they do match quite well. Well enough for home users for sure, which is good.
Unfortunately most other laptops/monitors are real mess and far from any standard.

Web designers have long wrestled with this kind of problem on a smaller scale: web browsers are more standards-compliant than they used to be, but you still have to serve up different style sheets for different browsers, especially Internet Explorer, which never did a good job of following standards. Web pages have "sniffers" in their code that detect what browser you're using and give you the appropriate style sheet or insert hacks to make the page display as intended. Could the same kind of thing be done for video, I wonder? The web page or app detects what monitor you're using and uses that information to provide the originally intended colors. Probably impossible given the huge range of monitors out there.

There is already technology for this (at least on Mac)- it's just bit not robust enough and not updated on time.
This is what "colr" atom is for in MOV container. Idea is simple. Each video file should be flagged accordingly to its actual video content, so Rec.709 2.4 gamma, P3 D65 etc. Then you have OSX color engine which based on this info converts preview into display profile. This is good enough to avoid situations when Rec.709 graded video is displayed on P3 screen "as is", which of course looks very wrong. It all sounds fairly easy, but fact that for so many years most apps still can't flag video files accurately (or not all or totally wrong) shows where we are in this matter

it's a little bit complicated to explain, how this apple quicktime container (.mov-files) issues affect color rendition over the network.

.mov is usually not used in nowadays video transport over the internet. this is nearly exclusively handled by MPEG transport streams or fragmented MPEG-4 files -- even by apple. sure, there are also horrible and inexcusable bugs related to correct color translation in actual webbrowsers in this case. well known long term issues, like utilizing a wrong rec.601 color translation for h.264 content and a correct rec.709 translation in case of vp9 content within the same browser and the same transport framework... but that's all irrelevant to the actual topic of this thread.

the .mov 'colr'-atom issues and apple software specific peculiarities usually only affect those people, which share .mov files in a more traditional way, and try to play them on their local machine. BUT there is one important exception to this general rule: if you upload a .mov-file to any internet video service provider, it also has to be interpreted on his machine for the final reencoding into more network suitable formats like on a physical screen. and that's usually not done by apple software, but by ffmpeg derivatives resp. typical unix server software. and as apples spends much more efforts on making their products and internal standards inaccessible to any other software, instead of establishing useful standards for the whole industries, we are always facing an annoying gap between the [always changing] behavior in their proprietary tools and in all the other widely used free implementations, which are build more or less on insight gathered by reverse engineering.

i personally share marcs advice in this case. it's indeed the most promising strategy of control, to utilize mpv or vlc, if you want archive correct reencoding of your files by one of the internet video service providers. both tools simply use the same libraries resp. color interpretation than those mechanisms utilized by youtube, vimeo etc. during their refinement for the network delivery. it simply doesn't matter if apples software and their publicly unavailable standards classify the data as incorrect and prefer a different color rendition. that's only relevant, if you have to share your footage with other people working straight from your files on apple software, but for delivery over the network and use in most non-apple software it simply doesn't matter. but it's also highly recommendable, to utilize more open specified file formats for exchange, to prevent this kind of annoying troubles as consequent as possible.

This is one of the conundrums in using reference monitors for material that is destined only to be viewed online. A reference monitor is the one piece of equipment that your target audience is almost guaranteed not to own, so from that perspective it would seem slightly insane to use a reference monitor for color grading if your entire audience will be viewing on web browsers and phones.

the weak link in this thought is... most everyone else who is delivering content for web is gradeing on a callibrated screen,

so imagine we have a cleint who cares deeply about the color of their logo.... Marc in LA grades a client's logo to match a specfic shade, denisty and saturation of orange, in Vancouver i grade another clip from the same client and logo to the same specfic shade, denisty and saturation of orange, on external scopes and callibrated monitor's the logo's are identical

someone else grades a third clip and grades the same client's logo to match visualy on their iMac screen

all three clips go to the same web service, and in the work the Marc and i did display as identical logo's, the third clip could be anything, anything but accurate that is....

no matter how crappy the screen used to display, the client's logo's will match if graded on callibated screens, the uncallibrated screen leaves the colorist no leg to stand on if the resuat looks like crap somewhere / anywhere else other than their iMac screen and the client is not happy

you are insane not to use a callibrated ref mon, if for no other reason that to know what you are shipping is valid

one more thought, when YouTube has skin in the game, like millions of their own cash in a YouTube RED exclusive feature film, the deliverables spec's are pretty tight!

someone else grades a third clip and grades the same client's logo to match visualy on their iMac screen

Completely bogus argument. In the absence of any colour management, the logo will look identical as a png/bmp/tiff file on disk to whatever you're "grading" it to, as long as both are viewed on the same monitor, no matter how bad said monitor is. If it matches there, it will still match on a reference monitor.

Only thing you can argue is that subtle shades/hues will be harder to discern on a "bad" monitor vs a reference monitor, but it won't magically make two files with the same RGB values get rendered any different (you need colour management, and, more specifically, QuickTime X for that).

it's a little bit complicated to explain, how this apple quicktime container (.mov-files) issues affect color rendition over the network.

.mov is usually not used in nowadays video transport over the internet. this is nearly exclusively handled by MPEG transport streams or fragmented MPEG-4 files -- even by apple. sure, there are also horrible and inexcusable bugs related to correct color translation in actual webbrowsers in this case. well known long term issues, like utilizing a wrong rec.601 color translation for h.264 content and a correct rec.709 translation in case of vp9 content within the same browser and the same transport framework... but that's all irrelevant to the actual topic of this thread.

MOV or other container should be really irrelevant as the same color metadata should be in actual codec (VP9/h264/h265/ProRes etc.) headers and through the browser's video engine passed to OS color management. It's all doable, but not in anyones interest as it won't really generate any "profits". Whole metadata is very poorly handled now and I don't see it changing. Problem will only grow with even more standards like Rec.2020 and all HDR variations. It's almost a joke how poorly OS developers+GPU manufactures+post industry is handling it. For many years there were only 2 main options 601 vs 709 and even just with those 2 many apps still can't handle it properly. Simply a joke.

.... that's only relevant, if you have to share your footage with other people working straight from your files on apple software, but for delivery over the network and use in most non-apple software it simply doesn't matter. .

And this is what I'm talking about. I want same QT X and Resolve preview on the same screen. This is just for start. How this look will "go" further is another problem.

Of course youtube will screw it up and final look will be as Resolve default export seen in QT X (in both Chrome and Safari).
Whole 2.4 gamma flagging is lost. This just shows how crappy youtube and whole chain is. Video was made as Rec.709 2.4 gamma, but end display is done most likely with 1.96 gamma due to Rec.709 default flagging.
it's not Resolve or QT X which is wrong here, but youtube and its default Rec.709 flagging.
How can youtube flag every SDR video always as Rec.709 if they could be done as 2.2, 2,4 gamma etc. and more interestingly it will be displayed on Mac using 1.96 gamma?

Does anyone know how to make 1.96 gamma based project in Resolve?
Why does Apple use in its color processing 1.96 gamma for Rec.709 tagged files? (maybe because this is correct inverse gamma as per https://books.google.co.uk/books?id=nQs ... ma&f=false). Is no one aware of it? Everyone uses 2.4 gamma yet there is no standard way of marking such a file. Mess.

Of course Vimeo also doesn't care about my flagging- for them everything HD SDR is also Rec.709.