
Updated on 23.05.2020
DaVinci Resolve 16.2.2 now provide special Rec.709-A gamma for macOS. More info here viewtopic.php?f=21&t=114047
Rec.709-A is only for monitoring in combination with enabled "Use Mac display Colour profiles for viewers"
If you don't use "Use Mac display Colour profiles for viewers" option - just keep use Rec.709 (Scene)
Rec.709-A reads Rec709 gamma in Apple way
Rec.709 (Scene) reads Rec709 gamma in normal way
Use Rec.709-A only as "Input" of "Timeline" gamma. I guess you should not render to Rec.709-A and never use Rec.709-A as output gamma in CST node as output, because it is out of any common video specification.
DaVinci Resolve 16.2 now support for overriding the color space and gamma tags in render settings. In most cases in YRGB project when your output CST node set to Rec709 with gamma 2.4 or Rec709, you also need to set both Color Space and Gamma Tags in render settings to Rec709. This allow to avoid Gamma and Color Shift Problems described below.
Also now you can use any Timeline Color Space and Gamma in YRGB project. Timeline Color Space and Gamma in project settings don't affects anymore tags in rendered video file.

Additional explanation by Andrew Kolakowski about how Resolve 16.2 works now:
Summary:
You can set YRGB project timeline to Rec709 (Scene) and choose "Same as project" render tags. This will not produce gamma shift. (This emulates how Resolve 16.1 worked)
Or you set YRGB project timeline to gamma 2.4 (or any other you like) and choose Rec709 render tags. This will not produce gamma shift. (This emulates how Resolve 16 and earlier worked)
Some legacy but still useful content to read and learn:
This is my attempt to understand and explain gamma/brightness and color shifts problems between different video formats and players. This problem is rather complicated and consists of multiple factors.
(This investigation is NOT related to legacy outdated Mac OSX versions gamma 1.8 vs Windows gamma 2.2 shift problems in quicktime .mov files. It is NOT related to incorrect setup of Full/Video levels in Project/Render settings which may produce darker/lighter image. It is also NOT related to various types of HDR metadata tags.)
For those who not sure how to setup things i created example project archive that may help better understand workflow details described earlier in this post viewtopic.php?f=21&t=65149#p537852
You can download project archive here: https://www.dropbox.com/s/kwcgdada65lub ... e.zip?dl=0
Part 1. Video file metadata tags:
There are 3 main metadata tags located inside video file:
- Color primaries
- Matrix coefficients
- Transfer characteristics

These metadata tags describes color space and gamma for apps that support color managed video output. "Color primaries" and "Matrix coefficients" describes color space settings. "Transfer characteristics" describes gamma setting.
You can find full list of supported tags here https://x265.readthedocs.io/en/default/ ... -colorprim
To see those metadata tags you need some media file inspector app (Invisor, VideoSpec, VideoScan, MediaInfo)
Modern color management for video is not standardized enough between different apps and operating systems. Some apps can read all those tags, some can read some of those tags, and some apps just ignore all those tags.
Part 2. Few basic things to understand:
- DaVinci Resolve Color Space Transform Node or LUT attached to clip or to timeline does not add or affect metadata tags.
- If you use DaVinci Resolve 16.1 and set project to YRGB (non color managed) workflow, it adds metadata tags to rendered video file according to timeline settings (Rec709, Rec2020, PCI-P3, Linear, g2.2, g2.4, g2.6 and so on...). Things may be different in older versions of DaVinci Resolve.
- The amount of supported metadata tags in video files is limited to few common color spaces and gammas, so if you set Timeline to some camera specific Log gamma and wide gamut Color Space, DaVinci Resolve will not add any metadata tags to rendered video file.
- If you use YRGB Color Managed workflow, DaVinci Resolve adds metadata tags according to selected Output Color Space in project settings.
- All macOS system apps (QuicktimeX player, Preview, QuickLook, Safari browser) always read "Color primaries", "Matrix coefficients" and "Transfer characteristics" tags from video file and transforms color space and gamma described in video metadata tags to monitor profile. This gamma color management method is rather exotic and unusual among other apps and video players, so as a result video output on mac always have that slightly brighter gamma look.
- When you check “Use Mac Display Color Profiles for Viewers” in DaVinci Resolve Preferences->System->General, it attempts emulate that specific macOS color management. It reads Timeline ColorSpace and Gamma settings (or "Output Color Space" project settings if you use YRGB Color Managed workflow) and transforms them to monitor profile.
- VLC Player v3 use it's own internal color management processing. It reads only "Color primaries" and "Matrix coefficients" metadata tags. It only transforms color space described in video metadata tags to monitor profile. VLC don't read Rec.709 gamma metadata from video file and don't transforms it in any way.
VLC output is usually 100% match to DaVinci Resolve viewer output if “Use Mac Display Color Profiles for Viewers” turned OFF.
- Older versions of VLC and most other video players, as well as Firefox browser can't read any of video metadata tags and so always output video "as is" without any additional color or gamma transforms.
- As i remember, Windows OS is not system wide color managed for video, so it always relies to video players and apps own internal color management. (Please correct me if i'm wrong)
Part 3. Different types of Monitor ICC profiles:
Monitor ICC profiles may have a lot of different types (XYZ LUT based, LAB based, Curve+Matrix based, Gamma+Matrix based). Different ICC profile types provides different calibration complexity and accuracy, but same time may cause compatibility problems in some apps when it comes to color space and gamma transform from video source to monitor profile.
Original bundled Monitor ICC profiles usually always designed within safe guidelines (Gamma 2.2 or sometimes sRGB and single curve+matrix profile type), so usually they don't cause any problems.
If you decide to calibrate your monitor manually and choose unusual profile type or some custom gamma curve, or use too complicated XYZ LUT based ICC profile type, you may expect problems with strange gamma shifts between different apps. Some monitor calibration software even warns you about possible compatibility problems and suggests to choose simpler but more compatible profile type.

Part 4. Missed metadata tags inside video files:
Now we can move to final comparative tests and investigations to understand the core of the gamma/brightness shifts problem.
Software used:
- DaVinci Resolve 16.1
- VLC player 3.0.8
- macOS 10.14.6 (Mojave) QuicktimeX Player
- HandBrake video transcoder 1.2.2
Test setup:
- DaVinci Resolve project settings set to YRGB (non color managed).
- As a source i used DNG RAW footage captured with BMMCC camera.
- I created various combinations of project Timeline gamma settings and CST Node output settings and render each example to ProRes422.
- Next i convert all those files to .mp4 h264 with HandBrake video transcoder to see the difference in metadata tags between ProRes source and .mp4 delivery.
- Next i open all those video files with Invisor media file inspector and made comparative screenshots of metadata tags.
- And finally i open each of those video files in VLC and QuicktimeX players and made comparative screenshots.
- In addition i made few reference screenshots of DaVinci Resolve viewer.

Tags added to ProRes .mov file rendered by DaVinci Resolve 16.1, if Timeline set to Rec.709:
- Color primaries: BT.709
- Matrix coefficients: BT.709
- Transfer characteristics: BT.709
Tags added to ProRes .mov file rendered by DaVinci Resolve 16.1, if Timeline set to gamma 2.4:
- Color primaries: BT.709
- Matrix coefficients: BT.709
Tags added to ProRes .mov file rendered by DaVinci Resolve 16.1, if Timeline set to some unusual camera specific wide gamut color space and Log gamma:
- matrix_coefficients_Original: BT.709
Tags added to h264 .mp4 file rendered by DaVinci Resolve 16.1, if Timeline set to Rec.709:
- Color primaries: BT.709
- Matrix coefficients: BT.709
- Color range: Limited
- Transfer characteristics: BT.709
Tags added to h264 .mp4 file rendered by DaVinci Resolve 16.1, if Timeline set to gamma 2.4:
- Color primaries: BT.709
- Color range: Limited
- Matrix coefficients: BT.709
Tags added to h264 .mp4 file transcoded by Handbrake, YouTube, Vimeo or any other similar app:
- Color primaries: BT.709
- Matrix coefficients: BT.709
- Color range: Limited
- Transfer characteristics: BT.709
And some Rec.2020 tests:
Tags added to ProRes .mov file rendered by DaVinci Resolve 16.1, if Timeline set to Rec.2020:
- Color primaries: BT.2020
- Matrix coefficients: BT.2020 non-constant
- Transfer characteristics: BT.709
Tags added by Handbrake during transcoding Rec.2020 ProRes .mov file to h264 .mp4 file (Handbrake can read metadata tags from source file and preserve them in transcoded .mp4 file):
- Color primaries: BT.2020
- Color range: Limited
- Matrix coefficients: BT.2020 non-constant
- Transfer characteristics: BT.709
Tags added to h264 .mp4 file rendered by DaVinci Resolve 16.1, if Timeline set to Rec.2020 (Wrong Color primaries metadata. Seems software bug found here):
- Color primaries: BT.709
- Matrix coefficients: BT.709
- Color range: Limited
- Transfer characteristics: BT.709
Here are some animated examples. VLC colors looks exact same between all tests and match to DaVinci Resolve 16.1 viewer.
Archive with original images here: https://www.dropbox.com/s/zmmi3xwgwl96k ... s.zip?dl=0
DaVinci Resolve 16.1 viewer:

Timeline set to Rec.709 (VLC looks the same all the time, QuickTime X player looks the same):

Timeline set to gamma 2.4 (VLC looks the same all the time, QuickTime X player produce shifts in gamma):

Timeline set to BMDfilm (VLC looks the same all the time, QuickTime X player produce shifts in color and gamma):

Part 5. Different look in different versions of DaVinci Resolve:
Metadata tags in DaVinci Resolve are added automatically based on selected Timeline settings. DaVinci Resolve 16 and 16.1 adds tags metadata in different way.
Tags added to ProRes .mov file rendered by DaVinci Resolve 16, if Timeline set to gamma 2.4:
- Color primaries: BT.709
- Matrix coefficients: BT.709
- Transfer characteristics: BT.709
Tags added to ProRes .mov file rendered by DaVinci Resolve 16.1, if Timeline set to gamma 2.4:
- Color primaries: BT.709
- Matrix coefficients: BT.709
So before DaVinci Resolve 16.1 both Rec709(Scene) and gamma 2.4 project settings where tagged exact the same: BT.709-BT.709-BT.709. Technically it may looks like mistake to tag g2.4 project with Rec709 metadata, but in real life it allow to avoid problems with gamma shifts between QuickTime player ProRes and mp4 YouTube transcodings and preserve "What You See is What You Get" concept.
But as we already know, color managed QuickTime player on macOS can read gamma tag, and by QuickTime specification decide that empty gamma tag means something like Gamma 2.4. As a result output video in QuickTime now looks darker, but all rest apps in the world just fill that empty gamma tag with BT.709 and so produce gamma shift during transcoding or during preview.
Currently only macOS QuickTime player can read all customized metadata tags in video files. Most other software and hardware video players on planet will ignore any custom metadata tags and will use BT.709-BT.709-BT.709 to playback HD video. I guess that Apple designed those tags long time ago as a part of QuickTime player, and later those tags where partially adopted to mp4 h264/h265 specification to communicate with video players for 4K Rec2020 HDR delivery.
Part 6. The solution:
If looking ahead, the quick solution for this problem - do NOT use gamma 2.4 in DaVinci Resolve Timeline project settings. If you work in YRGB project, always set Timeline gamma to Rec.709 (Rec.709 (Scene)) and adjust final desired gamma look with CST Node or manually with gamma slider wheel whatever you like. This will help to avoid hidden gamma shifts and metadata tags mismatches between editing or transcoding, and will provide cleanest "What You See is What You Get" workflow. HandBrake, Youtube, Vimeo or any other current video transcoder by default expects Rec.709 gamma curve in video file and during transcoding always automatically adds BT.709 Color primaries, Matrix coefficients and Transfer characteristics to converted video file.
Part 7. YRGB vs YRGB Color Managed project settings in DaVinci Resolve
I done a little test and noticed gamma shift in DaVinci Resolve viewer between same project settings:
YRGB (non color managed) project:
- Timeline set to Rec.709 (Scene)
- CST nodes set to: input Rec.709, Output Rec.709
YRGB Color Managed project:
- Input Rec709
- Timeline Rec709
- Output gamma Rec709
After some research it appears that in YRGB Color Managed project Resolve automatically assigns gamma 2.4 input to any ProRes file on timeline. This overridden project input color settings and produced gamma shift in my test.
So if you use simple Rec.709 source file, don't forget to right click on clip and select input Rec.709 (Scene).
If you use Log source from camera, select input according to your Log camera format.
If you use RAW source from camera, select input bypass.
With proper input color space and gamma image preview will look the same between both YRGB and YRGB Color Managed project settings.

Part 8. Gamma shift between macOS QuickTime player and other apps:
Even with proper tagged Rec.709 source you still may see slight gamma shift between macOS and VLC. Color management logic just very different between those apps and there is nothing we can do with it except to adjust gamma during grading to provide the gamma look somewhere in between.
If you want to (almost) match QuickTime player "look" in DaVinci Resolve viewer, Set YRGB (non color managed) Timeline to Rec709(Scene) as described earlier and check “Use Mac Display Color Profiles for Viewers” in DaVinci Resolve Preferences->System->General
If you want to match VLC player "look" in DaVinci Resolve viewer, Set YRGB (non color managed) Timeline to Rec709(Scene) as described earlier and uncheck “Use Mac Display Color Profiles for Viewers” in DaVinci Resolve Preferences->System->General
I think that main troublemakers here are Wide gamut Apple P3 monitors and color managed macOS QuickTime player. Corporations always force people to spend money for something new and partially useless, so step by step hardware moved to wide gamut/HDR displays. But same time video color management is not widely established and not standardized yet. It may take another 10 years until Windows will add system wide color management for video, and until Apple realize that it probably reads and transforms video gamma in wrong way and will fix it. This problem was well explained in details by fumoboy007 in this thread https://github.com/mpv-player/mpv/issues/4248 In short: Apple reads simplified 1.961 gamma instead of precise ITU-R 709 transfer function which is produce system wide gamma shift between color managed QuickTome player and other non color managed video players and apps.
As a quick fix for P3 displays you can use monitoring correction LUTs made by Cosmin Hodiș-Mîndraș. More details in this post viewtopic.php?f=21&t=101253&start=50#p564992
Download LUTs here https://www.dropbox.com/s/0sux7nydfyk72 ... c.zip?dl=0
My personal opinion is that in current real life situation for video monitoring you better get modern monitor with real 100% sRGB coverage. I will produce the most accurate result for video without any additional color management shifts.
P.S. When you test something and for some reason you switch between display ICC profiles in macOS System Preferences, don't forget to restart DaVinci Resolve to see correct result. Other apps with own internal color management like Photoshop, VLC, Firefox also needs to be restarted to output correct result.
As a bonus here is FilmLight QuickTime Colour Management tutorial with some similar things explained:
And also few helpful articles suggested by Marc Wielage:
Grading for Mixed Delivery: Cinema, Home, and Every Screen in Between
https://blog.frame.io/2019/10/14/gradin ... -delivery/
Color Management for Video Editors
https://jonnyelwyn.co.uk/film-and-video ... o-editors/

Rec.709-A is only for monitoring in combination with enabled "Use Mac display Colour profiles for viewers"
If you don't use "Use Mac display Colour profiles for viewers" option - just keep use Rec.709 (Scene)
Rec.709-A reads Rec709 gamma in Apple way
Rec.709 (Scene) reads Rec709 gamma in normal way
Use Rec.709-A only as "Input" of "Timeline" gamma. I guess you should not render to Rec.709-A and never use Rec.709-A as output gamma in CST node as output, because it is out of any common video specification.

Also now you can use any Timeline Color Space and Gamma in YRGB project. Timeline Color Space and Gamma in project settings don't affects anymore tags in rendered video file.

Additional explanation by Andrew Kolakowski about how Resolve 16.2 works now:
You can grade to any gamma you wish, yet tag to totally different. Your real nature of the file will be as you want (not some Rec.709 Scene crap), but tag will say something else, which in your case is most likely Rec.709 (1-1-1).
16.2 allows to achieve everything what older version did+ even more as working parameters are separated from export tags.
Resolve does now everything as it should be done- it doesn't do anything to please QT preview etc. It does things as per existing specs and also lets you to do it in "old (wrong)" way if you have such a need.
Tagging 2.4 gamma graded files as Rec.709 Scene was always wrong (and is still wrong) as Rec.709 Scene gamma is no near 2.4, but more like 1.96 and should be never used on the display side.
Setup "normal" 2.4 gamma based project and during export set tags to Rec.709 Scene (in Advanced settings). You will get proper 2.4 gamma graded file with "old" 1-1-1 Rec.709 tagging.
Summary:
You can set YRGB project timeline to Rec709 (Scene) and choose "Same as project" render tags. This will not produce gamma shift. (This emulates how Resolve 16.1 worked)
Or you set YRGB project timeline to gamma 2.4 (or any other you like) and choose Rec709 render tags. This will not produce gamma shift. (This emulates how Resolve 16 and earlier worked)
Some legacy but still useful content to read and learn:
This is my attempt to understand and explain gamma/brightness and color shifts problems between different video formats and players. This problem is rather complicated and consists of multiple factors.
(This investigation is NOT related to legacy outdated Mac OSX versions gamma 1.8 vs Windows gamma 2.2 shift problems in quicktime .mov files. It is NOT related to incorrect setup of Full/Video levels in Project/Render settings which may produce darker/lighter image. It is also NOT related to various types of HDR metadata tags.)
For those who not sure how to setup things i created example project archive that may help better understand workflow details described earlier in this post viewtopic.php?f=21&t=65149#p537852

Part 1. Video file metadata tags:
There are 3 main metadata tags located inside video file:
- Color primaries
- Matrix coefficients
- Transfer characteristics

These metadata tags describes color space and gamma for apps that support color managed video output. "Color primaries" and "Matrix coefficients" describes color space settings. "Transfer characteristics" describes gamma setting.
You can find full list of supported tags here https://x265.readthedocs.io/en/default/ ... -colorprim
To see those metadata tags you need some media file inspector app (Invisor, VideoSpec, VideoScan, MediaInfo)
Modern color management for video is not standardized enough between different apps and operating systems. Some apps can read all those tags, some can read some of those tags, and some apps just ignore all those tags.
Part 2. Few basic things to understand:
- DaVinci Resolve Color Space Transform Node or LUT attached to clip or to timeline does not add or affect metadata tags.
- If you use DaVinci Resolve 16.1 and set project to YRGB (non color managed) workflow, it adds metadata tags to rendered video file according to timeline settings (Rec709, Rec2020, PCI-P3, Linear, g2.2, g2.4, g2.6 and so on...). Things may be different in older versions of DaVinci Resolve.
- The amount of supported metadata tags in video files is limited to few common color spaces and gammas, so if you set Timeline to some camera specific Log gamma and wide gamut Color Space, DaVinci Resolve will not add any metadata tags to rendered video file.
- If you use YRGB Color Managed workflow, DaVinci Resolve adds metadata tags according to selected Output Color Space in project settings.
- All macOS system apps (QuicktimeX player, Preview, QuickLook, Safari browser) always read "Color primaries", "Matrix coefficients" and "Transfer characteristics" tags from video file and transforms color space and gamma described in video metadata tags to monitor profile. This gamma color management method is rather exotic and unusual among other apps and video players, so as a result video output on mac always have that slightly brighter gamma look.
- When you check “Use Mac Display Color Profiles for Viewers” in DaVinci Resolve Preferences->System->General, it attempts emulate that specific macOS color management. It reads Timeline ColorSpace and Gamma settings (or "Output Color Space" project settings if you use YRGB Color Managed workflow) and transforms them to monitor profile.
- VLC Player v3 use it's own internal color management processing. It reads only "Color primaries" and "Matrix coefficients" metadata tags. It only transforms color space described in video metadata tags to monitor profile. VLC don't read Rec.709 gamma metadata from video file and don't transforms it in any way.
VLC output is usually 100% match to DaVinci Resolve viewer output if “Use Mac Display Color Profiles for Viewers” turned OFF.
- Older versions of VLC and most other video players, as well as Firefox browser can't read any of video metadata tags and so always output video "as is" without any additional color or gamma transforms.
- As i remember, Windows OS is not system wide color managed for video, so it always relies to video players and apps own internal color management. (Please correct me if i'm wrong)
Part 3. Different types of Monitor ICC profiles:
Monitor ICC profiles may have a lot of different types (XYZ LUT based, LAB based, Curve+Matrix based, Gamma+Matrix based). Different ICC profile types provides different calibration complexity and accuracy, but same time may cause compatibility problems in some apps when it comes to color space and gamma transform from video source to monitor profile.
Original bundled Monitor ICC profiles usually always designed within safe guidelines (Gamma 2.2 or sometimes sRGB and single curve+matrix profile type), so usually they don't cause any problems.
If you decide to calibrate your monitor manually and choose unusual profile type or some custom gamma curve, or use too complicated XYZ LUT based ICC profile type, you may expect problems with strange gamma shifts between different apps. Some monitor calibration software even warns you about possible compatibility problems and suggests to choose simpler but more compatible profile type.


Part 4. Missed metadata tags inside video files:
Now we can move to final comparative tests and investigations to understand the core of the gamma/brightness shifts problem.
Software used:
- DaVinci Resolve 16.1
- VLC player 3.0.8
- macOS 10.14.6 (Mojave) QuicktimeX Player
- HandBrake video transcoder 1.2.2
Test setup:
- DaVinci Resolve project settings set to YRGB (non color managed).
- As a source i used DNG RAW footage captured with BMMCC camera.
- I created various combinations of project Timeline gamma settings and CST Node output settings and render each example to ProRes422.
- Next i convert all those files to .mp4 h264 with HandBrake video transcoder to see the difference in metadata tags between ProRes source and .mp4 delivery.
- Next i open all those video files with Invisor media file inspector and made comparative screenshots of metadata tags.
- And finally i open each of those video files in VLC and QuicktimeX players and made comparative screenshots.
- In addition i made few reference screenshots of DaVinci Resolve viewer.

Tags added to ProRes .mov file rendered by DaVinci Resolve 16.1, if Timeline set to Rec.709:
- Color primaries: BT.709
- Matrix coefficients: BT.709
- Transfer characteristics: BT.709
Tags added to ProRes .mov file rendered by DaVinci Resolve 16.1, if Timeline set to gamma 2.4:
- Color primaries: BT.709
- Matrix coefficients: BT.709
Tags added to ProRes .mov file rendered by DaVinci Resolve 16.1, if Timeline set to some unusual camera specific wide gamut color space and Log gamma:
- matrix_coefficients_Original: BT.709
Tags added to h264 .mp4 file rendered by DaVinci Resolve 16.1, if Timeline set to Rec.709:
- Color primaries: BT.709
- Matrix coefficients: BT.709
- Color range: Limited
- Transfer characteristics: BT.709
Tags added to h264 .mp4 file rendered by DaVinci Resolve 16.1, if Timeline set to gamma 2.4:
- Color primaries: BT.709
- Color range: Limited
- Matrix coefficients: BT.709
Tags added to h264 .mp4 file transcoded by Handbrake, YouTube, Vimeo or any other similar app:
- Color primaries: BT.709
- Matrix coefficients: BT.709
- Color range: Limited
- Transfer characteristics: BT.709
And some Rec.2020 tests:
Tags added to ProRes .mov file rendered by DaVinci Resolve 16.1, if Timeline set to Rec.2020:
- Color primaries: BT.2020
- Matrix coefficients: BT.2020 non-constant
- Transfer characteristics: BT.709
Tags added by Handbrake during transcoding Rec.2020 ProRes .mov file to h264 .mp4 file (Handbrake can read metadata tags from source file and preserve them in transcoded .mp4 file):
- Color primaries: BT.2020
- Color range: Limited
- Matrix coefficients: BT.2020 non-constant
- Transfer characteristics: BT.709
Tags added to h264 .mp4 file rendered by DaVinci Resolve 16.1, if Timeline set to Rec.2020 (Wrong Color primaries metadata. Seems software bug found here):
- Color primaries: BT.709
- Matrix coefficients: BT.709
- Color range: Limited
- Transfer characteristics: BT.709
Here are some animated examples. VLC colors looks exact same between all tests and match to DaVinci Resolve 16.1 viewer.
Archive with original images here: https://www.dropbox.com/s/zmmi3xwgwl96k ... s.zip?dl=0
DaVinci Resolve 16.1 viewer:

Timeline set to Rec.709 (VLC looks the same all the time, QuickTime X player looks the same):

Timeline set to gamma 2.4 (VLC looks the same all the time, QuickTime X player produce shifts in gamma):

Timeline set to BMDfilm (VLC looks the same all the time, QuickTime X player produce shifts in color and gamma):

Part 5. Different look in different versions of DaVinci Resolve:
Metadata tags in DaVinci Resolve are added automatically based on selected Timeline settings. DaVinci Resolve 16 and 16.1 adds tags metadata in different way.
Tags added to ProRes .mov file rendered by DaVinci Resolve 16, if Timeline set to gamma 2.4:
- Color primaries: BT.709
- Matrix coefficients: BT.709
- Transfer characteristics: BT.709
Tags added to ProRes .mov file rendered by DaVinci Resolve 16.1, if Timeline set to gamma 2.4:
- Color primaries: BT.709
- Matrix coefficients: BT.709
So before DaVinci Resolve 16.1 both Rec709(Scene) and gamma 2.4 project settings where tagged exact the same: BT.709-BT.709-BT.709. Technically it may looks like mistake to tag g2.4 project with Rec709 metadata, but in real life it allow to avoid problems with gamma shifts between QuickTime player ProRes and mp4 YouTube transcodings and preserve "What You See is What You Get" concept.
But as we already know, color managed QuickTime player on macOS can read gamma tag, and by QuickTime specification decide that empty gamma tag means something like Gamma 2.4. As a result output video in QuickTime now looks darker, but all rest apps in the world just fill that empty gamma tag with BT.709 and so produce gamma shift during transcoding or during preview.
Currently only macOS QuickTime player can read all customized metadata tags in video files. Most other software and hardware video players on planet will ignore any custom metadata tags and will use BT.709-BT.709-BT.709 to playback HD video. I guess that Apple designed those tags long time ago as a part of QuickTime player, and later those tags where partially adopted to mp4 h264/h265 specification to communicate with video players for 4K Rec2020 HDR delivery.
Part 6. The solution:
If looking ahead, the quick solution for this problem - do NOT use gamma 2.4 in DaVinci Resolve Timeline project settings. If you work in YRGB project, always set Timeline gamma to Rec.709 (Rec.709 (Scene)) and adjust final desired gamma look with CST Node or manually with gamma slider wheel whatever you like. This will help to avoid hidden gamma shifts and metadata tags mismatches between editing or transcoding, and will provide cleanest "What You See is What You Get" workflow. HandBrake, Youtube, Vimeo or any other current video transcoder by default expects Rec.709 gamma curve in video file and during transcoding always automatically adds BT.709 Color primaries, Matrix coefficients and Transfer characteristics to converted video file.
Part 7. YRGB vs YRGB Color Managed project settings in DaVinci Resolve
I done a little test and noticed gamma shift in DaVinci Resolve viewer between same project settings:
YRGB (non color managed) project:
- Timeline set to Rec.709 (Scene)
- CST nodes set to: input Rec.709, Output Rec.709
YRGB Color Managed project:
- Input Rec709
- Timeline Rec709
- Output gamma Rec709
After some research it appears that in YRGB Color Managed project Resolve automatically assigns gamma 2.4 input to any ProRes file on timeline. This overridden project input color settings and produced gamma shift in my test.
So if you use simple Rec.709 source file, don't forget to right click on clip and select input Rec.709 (Scene).
If you use Log source from camera, select input according to your Log camera format.
If you use RAW source from camera, select input bypass.
With proper input color space and gamma image preview will look the same between both YRGB and YRGB Color Managed project settings.

Part 8. Gamma shift between macOS QuickTime player and other apps:
Even with proper tagged Rec.709 source you still may see slight gamma shift between macOS and VLC. Color management logic just very different between those apps and there is nothing we can do with it except to adjust gamma during grading to provide the gamma look somewhere in between.
If you want to (almost) match QuickTime player "look" in DaVinci Resolve viewer, Set YRGB (non color managed) Timeline to Rec709(Scene) as described earlier and check “Use Mac Display Color Profiles for Viewers” in DaVinci Resolve Preferences->System->General
If you want to match VLC player "look" in DaVinci Resolve viewer, Set YRGB (non color managed) Timeline to Rec709(Scene) as described earlier and uncheck “Use Mac Display Color Profiles for Viewers” in DaVinci Resolve Preferences->System->General
I think that main troublemakers here are Wide gamut Apple P3 monitors and color managed macOS QuickTime player. Corporations always force people to spend money for something new and partially useless, so step by step hardware moved to wide gamut/HDR displays. But same time video color management is not widely established and not standardized yet. It may take another 10 years until Windows will add system wide color management for video, and until Apple realize that it probably reads and transforms video gamma in wrong way and will fix it. This problem was well explained in details by fumoboy007 in this thread https://github.com/mpv-player/mpv/issues/4248 In short: Apple reads simplified 1.961 gamma instead of precise ITU-R 709 transfer function which is produce system wide gamma shift between color managed QuickTome player and other non color managed video players and apps.
As a quick fix for P3 displays you can use monitoring correction LUTs made by Cosmin Hodiș-Mîndraș. More details in this post viewtopic.php?f=21&t=101253&start=50#p564992
Download LUTs here https://www.dropbox.com/s/0sux7nydfyk72 ... c.zip?dl=0
My personal opinion is that in current real life situation for video monitoring you better get modern monitor with real 100% sRGB coverage. I will produce the most accurate result for video without any additional color management shifts.
P.S. When you test something and for some reason you switch between display ICC profiles in macOS System Preferences, don't forget to restart DaVinci Resolve to see correct result. Other apps with own internal color management like Photoshop, VLC, Firefox also needs to be restarted to output correct result.
As a bonus here is FilmLight QuickTime Colour Management tutorial with some similar things explained:
And also few helpful articles suggested by Marc Wielage:
Grading for Mixed Delivery: Cinema, Home, and Every Screen in Between
https://blog.frame.io/2019/10/14/gradin ... -delivery/
Color Management for Video Editors
https://jonnyelwyn.co.uk/film-and-video ... o-editors/
Last edited by Dmytro Shijan on Sat May 23, 2020 6:24 am, edited 41 times in total.
BMMCC/BMMSC Rigs Collection https://bmmccrigs.tumblr.com
My custom made accessories for BMMCC/BMMSC https://lavky.com/radioproektor/
My custom made accessories for BMMCC/BMMSC https://lavky.com/radioproektor/