On more time- it's not really Resolve issue, but also QT X (and more precisely outdated flagging system used by Apple).
It's all explained here:
viewtopic.php?f=21&t=95658&p=530897&hilit=baselight#p530897When you use sRGB then Resolve preview will look 100% the same as QT X (both apps will use same math for managing preview). Issue is with Rec.709 and 2.4 or 2.2 gamma as there are no real standards for it (specially in Apple color manage engine).
Fix needs to come from Apple- they need to include proper tagging (rec.709 with 2.4 and 2.2 gamma) into their color engine and then all will be good (if all app manufactures will also properly read and write tagging).
Interestingly latest Resolve 16.1 beta does set all headers correctly now for 2.4 gamma based projects. It follows Baselight and uses custom flagging with gamma tag. Preview matches QT X (there is some difference which is hard to explain as it use to match 100% and sRGB matches 100%). Shame Resolve doesn't keep proper flagging for 2.2 based gamma
Problem is that such a tagging is properly handled just by few apps out there and it will be lost when files are put through transcoding chains. We need new standardised flagging for 2.4 based gamma. Also-fact that you will have calibrated preview to 30K monitor will solve nothing in regards to later playback in QT X etc. (well- it does guarantee you that video is correct when correctly previewed).
Big studios have exactly same problem. So often client complains that video looks bad watched on Vimeo on his Mac. It ends up taking client and showing him same video on Dolby monitor, but then he says- I don't care. There were even cases when videos were re-graded and we talking about big budget projects (not holiday videos). We know theory, but what looks correct in theory is not always what client wants. You are not alone- it's bigger problem and fact that Apple and others (this includes BM etc.) cannot for 10 years sort out few headers in rendered video doesn't really help. Is it really that difficult to agree on new flag for Rec.709 2.4 gamma, which at least all decent apps will read/set/process properly? It took Baselight people few years to actually figure out that whole Rec.709 tagging is wrong? BM seems to be even not aware of it. Industry really needs to be more "active" and don't count just on SMPTE which doesn't really fit well into current reality. Shame these big companies don't
really talk to each other as whole problem could be sorted within a month (same was with Nvidia which needed years to be able to handle Rec.709 vs. Rec.601 properly- bit of a joke to be honest).
It's plain simple- file needs to be tagged with format which it was graded to: Rec.709 2.4, Rec.709 2.2, Rec.2020 2.4, REc.2020 PQ etc. If later there is a color management engine it has to have correct values to be based on, as otherwise you get mess as we have now. Files graded with different parameters, yet all flagged in one way Rec.709 (1-1-1). Add fact that Apple color engine assumes Rec.709 files was graded with 1.96 gamma, where no one grades to this value ever (due to famous fact of non-existing for many years standard for HD monitoring)! We still have mess in new formats as well- some predefined values exist, but somehow they don't really apply to reality. People grade to something which can't be properly described using standardised headers. It's like we had standards done on Mars by aliens, but grading on Earth
BM please fix flagging for 2.2 gamma. From current 1-4-1 +2.2 gamma tag it needs to change to 1-2-1 +2.2 gamma tag. Apple's color engine doesn't understand 1-4-1. In order for 2.2 info to be taken into account flagging needs to be set to 1-2-1.