Announcement

Collapse
No announcement yet.

Final Explanation of Gamma and Color Shift Problems

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Final Explanation of Gamma and Color Shift Problems

    Updated on 30.10.2019

    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.)


    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/defau...tion-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/zmmi3xwgwl...tests.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. 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 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.
    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:

    https://vimeo.com/349868875
    Last edited by shijan; 10-30-2019, 05:05 AM.
    All my custom made accessories for BMMCC/BMMSC now available here https://lavky.com/radioproektor/

  • #2
    Thanks for doing this.
    Pretty much matches my findings - and yeah - it's a mess.
    Can't believe that this is even an issue in 2019, but it still is.

    When I output anything with .mov (on a win machine) no mater if DNX or H264, I always do a general gamma adjustment over the whole timeline.
    If I use any other container, that adjustment is not needed. At least when we are talking YT.

    Still wrapping my head around some of those oddities.
    Blog: http://frankglencairn.wordpress.com/

    Comment

    Working...
    X