Final Explanation of Gamma and Color Shift Problems

Get answers to your questions about color grading, editing and finishing with DaVinci Resolve.
  • Author
  • Message
Offline

franciscovaldez

  • Posts: 147
  • Joined: Wed Aug 22, 2012 4:52 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 6:50 pm

Dmitry Shijan wrote:Monitor calibration is just a monitor calibration. Monitor calibration should match your monitor but you never need to adjust rendered video to your monitor calibration.
If my monitor calibrated to sRGB gamma (because i feel that current versions of mac OS color management works better with sRGB monitor gamma), it doesn't means that i need to render video with sRGB gamma and put some crazy custom sRGB tags inside that video.


That's exactly what I'm trying to achieve. I'm grading on a 2.4 environment but I don't want resolve tagging that info to my QuickTime files.

I want no tags. Like so:

"New in 16.2

• Support for overriding the color space and gamma tags in render settings.
Dwaine Maggart
Blackmagic Design DaVinci Support"
Online
User avatar

Dmitry Shijan

  • Posts: 1144
  • Joined: Wed Sep 17, 2014 7:15 pm
  • Location: UA

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 7:21 pm

"No tags" by mov/h264 specification means Quicktome X player and Safari will read video as gamma 2.4. Same time all other non color managed apps like VLC/Handbrake/Windows/Youtube/Vimeo/Firefox will read it as Rec709 (1-1-1) because they just ignore any tags and read any video as Rec709 (1-1-1). As a result this will produce huge gamma shift between these two groups (see example in first post).
Best thing you can do today is to manually adjust gamma of your grade somewhere in between: Not too bright for Mac specific 1.96 gamma and not too dark for all other non color managed apps. And tag it as Rec709 (1-1-1).
All my custom made accessories for BMMCC/BMMSC now available here https://lavky.com/radioproektor/
Offline

Vit Reiter

  • Posts: 505
  • Joined: Mon Sep 04, 2017 5:36 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 8:11 pm

Andrew Kolakowski wrote:Baselight, JesExtensifier, whole OSX color engine.
It's because most companies didn't/don't care about those headers and even if they do they don't implement it according to full spec, but just small portion of it.
Depending on applications which you list, you can see that the exported video from DaVinci cannot be simply used as a master for further processing for a professional world - broadcast, DCI or for VOD platforms delivering.
Perhaps the video makers who place videos on YouTube are now happy to see the same picture in Quick Time player as in the viewer in DaVinci. Congratulations Blackmagic!

It is very sad that exports worked well before two versions back.

One question for BM team: When will Rec.709 Gamma 2.2 exported video be identified in the transform characteristics as Rec.709 and not BT.470 System M?
DaVinci Resolve 16.2 Studio
Mac Pro 2013, AMD FirePro D700, 64GB RAM, macOS Mojave 10.14.6
iMac 2017, Radeon Pro 575, 24GB RAM, macOS High Sierra 10.13.6

Film Editor, Colorist, DIT, Encoding technician
linkedin.com/in/vít-reiter-film-editor
Offline

Vit Reiter

  • Posts: 505
  • Joined: Mon Sep 04, 2017 5:36 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 8:17 pm

franciscovaldez wrote:I'm grading on a 2.4 environment but I don't want resolve tagging that info to my QuickTime files.
Don't you think it's right to have exactly the parameters you set for exported video?
DaVinci Resolve 16.2 Studio
Mac Pro 2013, AMD FirePro D700, 64GB RAM, macOS Mojave 10.14.6
iMac 2017, Radeon Pro 575, 24GB RAM, macOS High Sierra 10.13.6

Film Editor, Colorist, DIT, Encoding technician
linkedin.com/in/vít-reiter-film-editor
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 8:50 pm

Vit Reiter wrote:Depending on applications which you list, you can see that the exported video from DaVinci cannot be simply used as a master for further processing for a professional world - broadcast, DCI or for VOD platforms delivering.
Perhaps the video makers who place videos on YouTube are now happy to see the same picture in Quick Time player as in the viewer in DaVinci. Congratulations Blackmagic!

It is very sad that exports worked well before two versions back.


No- this is rather incorrect. This tag affects mainly preview. It has not much to do with further processing in real world (at least in 95%+ cases). Almost not a single transcoding tool etc. uses headers. When precise info about source is required in most cases you tell app what it's. Most tools recognise just HD vs. SD or SDR vs. HDR. Quite often SD vs. HD is done based on resolution, not by reading headers.

New exports will work as well as old ones. Also, with new 16.2 you can export them with "old" Rec.709 tagging (1-1-1) regardless of your project settings. It's not bad change, but good one, specially now with 16.2 version.
Offline

Vit Reiter

  • Posts: 505
  • Joined: Mon Sep 04, 2017 5:36 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 8:56 pm

Dmitry Shijan wrote:During all this discussion i still can't understand what is the practical point of gamma 2.4 for delivery and why some of you so want to use that custom gamma 2.4 tags into your workflow?
Do you really know why? You need to export a video master from NLE for further processing with the correct parameters - gamut, gamma and transmission characteristics, and all must be listed. Television companies, encoding houses and others have it in the technical specifications because their systems require it and cannot do the manufacturing process without them. These parameters ensure proper processing, after which the video must look the same as the master.
DaVinci Resolve 16.2 Studio
Mac Pro 2013, AMD FirePro D700, 64GB RAM, macOS Mojave 10.14.6
iMac 2017, Radeon Pro 575, 24GB RAM, macOS High Sierra 10.13.6

Film Editor, Colorist, DIT, Encoding technician
linkedin.com/in/vít-reiter-film-editor
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 8:57 pm

Vit Reiter wrote:
Andrew Kolakowski wrote:Baselight, JesExtensifier, whole OSX color engine.
It's because most companies didn't/don't care about those headers and even if they do they don't implement it according to full spec, but just small portion of it.
Depending on applications which you list, you can see that the exported video from DaVinci cannot be simply used as a master for further processing for a professional world - broadcast, DCI or for VOD platforms delivering.
Perhaps the video makers who place videos on YouTube are now happy to see the same picture in Quick Time player as in the viewer in DaVinci. Congratulations Blackmagic!

It is very sad that exports worked well before two versions back.

One question for BM team: When will Rec.709 Gamma 2.2 exported video be identified in the transform characteristics as Rec.709 and not BT.470 System M?


And why would you flag 2.2 gamma based video with Rec.709 tag which is totally incorrect and represents around 1.96 gamma? (regardless if there is a bug in Resolve).
Last time I checked such an exports where tagged properly with 1-4-1, which precisely describes Rec.709 with 2.2 gamma.
Last edited by Andrew Kolakowski on Mon Mar 09, 2020 9:03 pm, edited 1 time in total.
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 9:03 pm

Dmitry Shijan wrote:"No tags" by mov/h264 specification means Quicktome X player and Safari will read video as gamma 2.4. Same time all other non color managed apps like VLC/Handbrake/Windows/Youtube/Vimeo/Firefox will read it as Rec709 (1-1-1) because they just ignore any tags and read any video as Rec709 (1-1-1). As a result this will produce huge gamma shift between these two groups (see example in first post).
Best thing you can do today is to manually adjust gamma of your grade somewhere in between: Not too bright for Mac specific 1.96 gamma and not too dark for all other non color managed apps. And tag it as Rec709 (1-1-1).


It won't use 2.4 at all (unless it changed in latest OSX). No tag means using some old analog tag as reference, something like SMPTE 170M-1994. It's specified in QT spec.

Most PC apps don't read QT tags at all- they just uses hard coded values of sRGB or 2.2, 2.4 etc. gamma.
mpv player for example will use BT.1886 for 1-1-1 tagging. TVs will also most likely uses hard coded values of 2.2, 2.4 or BT.1886 (or let you set it in settings).
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 9:20 pm

Dmitry Shijan wrote:Best thing you can do today is to manually adjust gamma of your grade somewhere in between: Not too bright for Mac specific 1.96 gamma and not too dark for all other non color managed apps. And tag it as Rec709 (1-1-1).


Well- this is home method :D (but there is really not much more you can do).
Offline

Vit Reiter

  • Posts: 505
  • Joined: Mon Sep 04, 2017 5:36 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 9:26 pm

Andrew Kolakowski wrote:
Vit Reiter wrote:Depending on applications which you list, you can see that the exported video from DaVinci cannot be simply used as a master for further processing for a professional world - broadcast, DCI or for VOD platforms delivering.
Perhaps the video makers who place videos on YouTube are now happy to see the same picture in Quick Time player as in the viewer in DaVinci. Congratulations Blackmagic!

It is very sad that exports worked well before two versions back.


No- this is rather incorrect. This tag affects mainly preview. It has not much to do with further processing in real world (at least in 95%+ cases). Almost not a single transcoding tool etc. uses headers. When precise info about source is required in most cases you tell app what it's. Most tools recognise just HD vs. SD or SDR vs. HDR. Quite often SD vs. HD is done based on resolution, not by reading headers.

New exports will work as well as old ones. Also, with new 16.2 you can export them with "old" Rec.709 tagging (1-1-1) regardless of your project settings. It's not bad change, but good one, specially now with 16.2 version.
In real world application for iTunes packaging alerts me that transfer characteristic is missing and ends process.

New exports will not work as well as old ones. How can you tell it? Transfer characteristic is missing now for Rec.709 Gamma 2.4.
DaVinci Resolve 16.2 Studio
Mac Pro 2013, AMD FirePro D700, 64GB RAM, macOS Mojave 10.14.6
iMac 2017, Radeon Pro 575, 24GB RAM, macOS High Sierra 10.13.6

Film Editor, Colorist, DIT, Encoding technician
linkedin.com/in/vít-reiter-film-editor
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 9:26 pm

Vit Reiter wrote:
Dmitry Shijan wrote:During all this discussion i still can't understand what is the practical point of gamma 2.4 for delivery and why some of you so want to use that custom gamma 2.4 tags into your workflow?
Do you really know why? You need to export a video master from NLE for further processing with the correct parameters - gamut, gamma and transmission characteristics, and all must be listed. Television companies, encoding houses and others have it in the technical specifications because their systems require it and cannot do the manufacturing process without them. These parameters ensure proper processing, after which the video must look the same as the master.


Not true at all. All mentioned assume some values and in most cases and don't read those tags at all. Premiere assumes 2.2 if I'm correct, broadcast assumes 2.4.
Any YUV based transcoding (which is huge majority) doesn't touch gamma at all. Your source "look" in such a cases is simply passed as is- all what you get is compression on top of it. IF you app goes to RGB and back to YUV then tag is important, but then in most cases it's assumed/set rather then read from tags.
It's slightly better for HDR masters. In more cases tags are actually read, but in this case at least we have more current spec and more apps which can properly work with tags (still quite often this is manually overwritten anyway).
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 9:31 pm

Vit Reiter wrote:
Andrew Kolakowski wrote:
Vit Reiter wrote:Depending on applications which you list, you can see that the exported video from DaVinci cannot be simply used as a master for further processing for a professional world - broadcast, DCI or for VOD platforms delivering.
Perhaps the video makers who place videos on YouTube are now happy to see the same picture in Quick Time player as in the viewer in DaVinci. Congratulations Blackmagic!

It is very sad that exports worked well before two versions back.


No- this is rather incorrect. This tag affects mainly preview. It has not much to do with further processing in real world (at least in 95%+ cases). Almost not a single transcoding tool etc. uses headers. When precise info about source is required in most cases you tell app what it's. Most tools recognise just HD vs. SD or SDR vs. HDR. Quite often SD vs. HD is done based on resolution, not by reading headers.

New exports will work as well as old ones. Also, with new 16.2 you can export them with "old" Rec.709 tagging (1-1-1) regardless of your project settings. It's not bad change, but good one, specially now with 16.2 version.
In real world application for iTunes packaging alerts me that transfer characteristic is missing and ends process.

New exports will not work as well as old ones. How can you tell it? Transfer characteristic is missing now for Rec.709 Gamma 2.4.


If iTunes requires 1-1-1 then set it during export using 16.2 new feature, but this just shows how crap whole system is. You produce 2.4 gamma based file ( I assume you follow current specs), yet tag it as something totally different just to please some outdated delivery system. All full of crap.
16.2 allows you to tag your file as you want regardless of your project settings, so in your case there is no problem compared to older Resolve. Just set color and gamma tag in Advanced setting in export panel to Rec.709 and you will have your file tagged as Rec.709 (1-1-1), so iTune won't complain. It's exactly same end result as in "old" Resolve.

You can also have even more tagging freedom with apps like JesExtensifier or DigitalRebelion (or simple hex editor) tools which allow you to re-tag files within seconds. If you deliver to iTunes you should learn about it as it can be very useful for you. Same applies to audio tracks types or language tags etc.
Last edited by Andrew Kolakowski on Mon Mar 09, 2020 9:45 pm, edited 1 time in total.
Offline

Vit Reiter

  • Posts: 505
  • Joined: Mon Sep 04, 2017 5:36 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 9:35 pm

Andrew Kolakowski wrote:
Vit Reiter wrote:
Andrew Kolakowski wrote:Baselight, JesExtensifier, whole OSX color engine.
It's because most companies didn't/don't care about those headers and even if they do they don't implement it according to full spec, but just small portion of it.
Depending on applications which you list, you can see that the exported video from DaVinci cannot be simply used as a master for further processing for a professional world - broadcast, DCI or for VOD platforms delivering.
Perhaps the video makers who place videos on YouTube are now happy to see the same picture in Quick Time player as in the viewer in DaVinci. Congratulations Blackmagic!

It is very sad that exports worked well before two versions back.

One question for BM team: When will Rec.709 Gamma 2.2 exported video be identified in the transform characteristics as Rec.709 and not BT.470 System M?


And why would you flag 2.2 gamma based video with Rec.709 tag which is totally incorrect and represents around 1.96 gamma? (regardless if there is a bug in Resolve).
Last time I checked such an exports where tagged properly with 1-4-1, which precisely describes Rec.709 with 2.2 gamma.
2.2 gamma is 2.2 gamma and not 1.96. Gamma 2.2 is ideal for video watching on PC monitor in office or home. Or not?
DaVinci Resolve 16.2 Studio
Mac Pro 2013, AMD FirePro D700, 64GB RAM, macOS Mojave 10.14.6
iMac 2017, Radeon Pro 575, 24GB RAM, macOS High Sierra 10.13.6

Film Editor, Colorist, DIT, Encoding technician
linkedin.com/in/vít-reiter-film-editor
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 9:38 pm

I thought you want it to set/recognise as Rec.709 tag (1-1-1), which on OSX is processed as 1.96 gamma.
Resolve sets headers for Rec.709 2.2 exports correctly: 1-4-1, where 4 means 2.2 gamma (but OSX color engine is not coded to recognise this set of parameters). When you load this file back to Resolve it will also read it as 1-4-1 and uses 2.2 gamma for processing.
You can check here what those values mean:
https://github.com/bbc/qtff-parameter-editor
Offline

Vit Reiter

  • Posts: 505
  • Joined: Mon Sep 04, 2017 5:36 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 10:29 pm

Andrew Kolakowski wrote:I thought you want it to set/recognise as Rec.709 tag (1-1-1), which on OSX is processed as 1.96 gamma.
Resolve sets headers for Rec.709 2.2 exports correctly: 1-4-1, where 4 means 2.2 gamma (but OSX color engine is not coded to recognise this set of parameters). When you load this file back to Resolve it will also read it as 1-4-1 and uses 2.2 gamma for processing.
You can check here what those values mean:
https://github.com/bbc/qtff-parameter-editor
Andrew, but Baton or Media Info read BT.470 System M. Apple Compressor reads 1-2-1, Finder 1-4-1. After Automator action to 1-1-1 Media Info reads still BT.407 System M., DaVinci Rec.709 (Scene), Baton I don't know now. You are great expert but we need less theory and more user-friendly application from DaVinci. (theory is important, of course) My idea is, if I set export to Rec.709 Gamma 2.4 or 2.2 then exported video will be so and it is irrelevant how it looks inside Quick Time player which works inside P3 color space in macOS. It is a jungle but DaVinci can not fixed that. DaVinci has to export what user set and don't tell me that it doing.
DaVinci Resolve 16.2 Studio
Mac Pro 2013, AMD FirePro D700, 64GB RAM, macOS Mojave 10.14.6
iMac 2017, Radeon Pro 575, 24GB RAM, macOS High Sierra 10.13.6

Film Editor, Colorist, DIT, Encoding technician
linkedin.com/in/vít-reiter-film-editor
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 11:33 pm

You have 2 sets of headers- MOV headers and ProRes private frame headers.
When you export files they both should (and in most cases are) be set to the same values.
Then when you patch file with automator, JesExtensifier etc. you only change MOV headers.
Different apps read headers from different place, so you either see new values or still old if app takes them from ProRes private header (which you never changed). Mediainfo shows them from both places (in complex view) and you can easily see if they are different. Values like BT.470 System M may show up as transfer is set to value 2 which is unspecified and depending on the app it may show something default/wrong (it's basically not handling such a tagging properly).

Don't understand what you are trying to achieve. Resolve tags files properly for 2.4 and 2.2 gamma (as per Apple QT spec). It's all other tools which don't read it properly.
2.4 tagging is bit special case (as there is no 2.4 gamma transfer tag in Apple spec). In order to have such a tag you have 1-2-1, where 2 means unspecified transfer. On top of this you get gamma tag set to 2.4 and this is where your gamma is specified. Unfortunately atm. there are only Resolve, Baselight and Apple color engine which can read such a tag properly (about nothing reads gamma values- including mediainfo).
For 2.2 gamma there is a transfer tag and it's value 4. Resolve, Baselight will read it, but not Apple color engine (they simply never coded it). Apple only supports few sets of headers, which is bit limited. In order to have it read properly by Apple color engine you follow same rules as for 2.4, so 1-2-1 with gamma tag as 2.2. Then it will be read fine in OSX. BM doesn't do it this way as they set existing preset for 2.2 gamma which is value 4, so we have bit of problem here.

As you can see for 2.2 gamma, both places are set by Resolve properly:
MOV tag:
22C656E Color parameter type: nclc
22C6572 Primaries index: 1 (0x0001) - BT.709
22C6574 Transfer function index: 4 (0x0004) - BT.470 System M
22C6576 Matrix index: 1 (0x0001) - BT.709

ProRes frame tag:
0009CA0 primaries: 1 (0x01) - BT.709
0009CA1 transf_func: 4 (0x04) - BT.470 System M
0009CA2 colorMatrix: 1 (0x01) - BT.709

mediainfo is correct as value 4 means 2.2 gamma, which is also used in BT.470 System M.
Last edited by Andrew Kolakowski on Tue Mar 10, 2020 10:07 am, edited 7 times in total.
Offline
User avatar

waltervolpatto

  • Posts: 7548
  • Joined: Thu Feb 07, 2013 5:07 pm
  • Location: 1146 North Las Palmas Ave. Hollywood, California 90038 USA

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 11:34 pm

Dmitry Shijan wrote:Any ideas how video color management works on Android?


Android look like poop.. because is not apple.

Just kidding, I have no idea....
SuperServer 5039AD-I
C9X299-PGF - DDR4-2400 16x4 GB
i9-7920xCPU 12c 2.90GHz Water cooled
2x 1080ti DeckLink Studio 4K (11.4)
W10-1903 - BMR St. 16.2.055
nvidia: 441.66 studio
Offline
User avatar

waltervolpatto

  • Posts: 7548
  • Joined: Thu Feb 07, 2013 5:07 pm
  • Location: 1146 North Las Palmas Ave. Hollywood, California 90038 USA

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Mar 09, 2020 11:34 pm

There is a 3rd way to trick all apps, but this stays as my secret method :)


teaser.........
SuperServer 5039AD-I
C9X299-PGF - DDR4-2400 16x4 GB
i9-7920xCPU 12c 2.90GHz Water cooled
2x 1080ti DeckLink Studio 4K (11.4)
W10-1903 - BMR St. 16.2.055
nvidia: 441.66 studio
Online
User avatar

Dmitry Shijan

  • Posts: 1144
  • Joined: Wed Sep 17, 2014 7:15 pm
  • Location: UA

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Mar 10, 2020 1:01 am

Andrew Kolakowski wrote:Resolve tags files properly for 2.4 and 2.2 gamma (as per Apple QT spec). It's all other tools which don't read it properly.

Based on your info i done few more tests with videos captured from DV tapes and upscaled to HD and seems gamma 2.4 tag on final render is closest possible option to match look between VLC (non color managed) and Mac QuicktimeX color management (my monitor calibrated to sRGB gamma)

So yes, the problem formally comes from other apps as well as from Apple itself.

Resolve 16.2 exports MP4 h264 as well as mov files with proper tags. No any problem here.

If i use Hangbrake or any other local app to convert video to h264, it ignore 2.4 tag and change it with BT.709 tag, but i can change tag back to gamma 2.4 (1-2-1) with JESExtensifier (seems it don't works mp4 container).

If i upload to youtube/vimeo it will be auto converted to BT.709 and i can't change tags anymore, and so video will look with too shifted gamma on web.

So formally gamma 2.4 tag could be sort of cross platform compromise to unify look between legacy non color managed players and modern apple color managed players. But at least youtube/vimeo should start to read and support color management tags.

Or Apple should somehow redesign it's color management and change that stupid 1.96 gamma reading for videos with gamma 2.4 to match gamma appearance of legacy non color managed apps.
All my custom made accessories for BMMCC/BMMSC now available here https://lavky.com/radioproektor/
Offline

Wayne Steven

  • Posts: 2612
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Mar 10, 2020 4:48 pm

Is there a list of all tools and hardware that are implemented correct in respect of this?
If you are not truthfully progressive, maybe you shouldn't say anything. Side topics in-line with, or related to, the discussion accepted.

Often people deceive themselves so much they do not understand, even when the truth is explained to them.
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Mar 10, 2020 4:55 pm

Nope. Who would create it ?
Offline

Vit Reiter

  • Posts: 505
  • Joined: Mon Sep 04, 2017 5:36 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 7:49 am

Andrew Kolakowski wrote:Don't understand what you are trying to achieve...
How can I achieve this:

- source video is ProRes 422 HQ Rec.709 Gamma 2.4
- DaVinci sees ProRes 422 HQ Rec.709 Gamma 2.4 after import
- after editing I need to export video to ProRes 422 HQ Rec.709 Gamma 2.4 with visible transform characteristics in Baton, Switch and Media Info
DaVinci Resolve 16.2 Studio
Mac Pro 2013, AMD FirePro D700, 64GB RAM, macOS Mojave 10.14.6
iMac 2017, Radeon Pro 575, 24GB RAM, macOS High Sierra 10.13.6

Film Editor, Colorist, DIT, Encoding technician
linkedin.com/in/vít-reiter-film-editor
Offline

Wayne Steven

  • Posts: 2612
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 1:14 pm

Andrew Kolakowski wrote:Nope. Who would create it ?


Anybody really serious about the work.
If you are not truthfully progressive, maybe you shouldn't say anything. Side topics in-line with, or related to, the discussion accepted.

Often people deceive themselves so much they do not understand, even when the truth is explained to them.
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 2:18 pm

Vit Reiter wrote:
Andrew Kolakowski wrote:Don't understand what you are trying to achieve...
How can I achieve this:
...
- after editing I need to export video to ProRes 422 HQ Rec.709 Gamma 2.4 with visible transform characteristics in Baton, Switch and Media Info


You won't as those tools are unable to detect flagging for 2.4 gamma. It has nothing to do with Resolve, but with those tools. For production there is really no special need for it. If you want to pass grading standard info then you can do it in MOV headers as eg. comment metadata or simply in the file name or on the slate (this is how it's mainly done for now).
Offline

Vit Reiter

  • Posts: 505
  • Joined: Mon Sep 04, 2017 5:36 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 4:04 pm

Andrew Kolakowski wrote:
Vit Reiter wrote:
Andrew Kolakowski wrote:Don't understand what you are trying to achieve...
How can I achieve this:
...
- after editing I need to export video to ProRes 422 HQ Rec.709 Gamma 2.4 with visible transform characteristics in Baton, Switch and Media Info


You won't as those tools are unable to detect flagging for 2.4 gamma. It has nothing to do with Resolve, but with those tools. For production there is really no special need for it. If you want to pass grading standard info then you can do it in MOV headers as eg. comment metadata or simply in the file name or on the slate (this is how it's mainly done for now).
DaVinci 16.1.2 and 16.2 cannot. 16.1 can do it and I had no problems with it.

It does not matter if these tools can read the gamma value, they see the missing transfer characteristics as unusable video. I could export the video from DaVinci to Rec.709 Scene, I know, but I don't want to archive the material with shifted gamma and it's not just about archiving. Other people are working with this video and I don't know when shifted gamma can cause trouble.

Is it so hard to make DaVinci export correctly according to the user settings as it was in DVR 16.1 and not invent foolishness that the user did not set? What is the benefit of not registering transfer characteristics? QT Player or YouTube with proper picture? This is not a good idea for professional software.
DaVinci Resolve 16.2 Studio
Mac Pro 2013, AMD FirePro D700, 64GB RAM, macOS Mojave 10.14.6
iMac 2017, Radeon Pro 575, 24GB RAM, macOS High Sierra 10.13.6

Film Editor, Colorist, DIT, Encoding technician
linkedin.com/in/vít-reiter-film-editor
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 4:12 pm

You seems to not understand how new 16.2 works.
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. Not sure what is so hard to understand here?
Have you actually tried this?
Offline

franciscovaldez

  • Posts: 147
  • Joined: Wed Aug 22, 2012 4:52 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 5:13 pm

[quote="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. Not sure what is so hard to understand here?
Have you actually tried this?[/quote]

It's hard to understand because it's a workaround and in my point of view, not an obvious solution.

Your explanation is very straightforward and is the first time I've seen these steps explained in a way I can grasp the concept.

I will give this a try.
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 5:28 pm

Andrew Kolakowski wrote:...
16.2 allows you to tag your file as you want regardless of your project settings, so in your case there is no problem compared to older Resolve. Just set color and gamma tag in Advanced setting in export panel to Rec.709 and you will have your file tagged as Rec.709 (1-1-1), so iTune won't complain. It's exactly same end result as in "old" Resolve.

You can also have even more tagging freedom with apps like JesExtensifier or DigitalRebelion (or simple hex editor) tools which allow you to re-tag files within seconds. If you deliver to iTunes you should learn about it as it can be very useful for you. Same applies to audio tracks types or language tags etc.


I already mentioned how to do it.

You may call it work around.
I would call it: "using new Resolve feature to flag files in wrong way, which is still required by other apps".
It's others who need to change, not Resolve. This is proper way going forward. Baselight already does it, so let's hope it will spread.
Last edited by Andrew Kolakowski on Wed Mar 11, 2020 7:51 pm, edited 1 time in total.
Offline

franciscovaldez

  • Posts: 147
  • Joined: Wed Aug 22, 2012 4:52 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 7:40 pm

Andrew Kolakowski wrote:
Andrew Kolakowski wrote:...
16.2 allows you to tag your file as you want regardless of your project settings, so in your case there is no problem compared to older Resolve. Just set color and gamma tag in Advanced setting in export panel to Rec.709 and you will have your file tagged as Rec.709 (1-1-1), so iTune won't complain. It's exactly same end result as in "old" Resolve.

You can also have even more tagging freedom with apps like JesExtensifier or DigitalRebelion (or simple hex editor) tools which allow you to re-tag files within seconds. If you deliver to iTunes you should learn about it as it can be very useful for you. Same applies to audio tracks types or language tags etc.


I already mentioned how to do it.

You may be called work around.
I would call it: "using new Resolve feature to flag files in wrong way, which is still required by other apps".
It's others who need to change, not Resolve. This is proper way going forward. Baselight already does it, so let's hope it will spread.


Yes. I'm sorry I didn't catch it before. It's difficult to weed out the useful information on such a long thread, while at the same time, trying to understand the issue as well.

I erroneously called it a workaround because it wasn't a clear choice for me. I was looking for a "no tag" option, which from what I've been reading here, would also give me the wrong gamma.
Online
User avatar

Dmitry Shijan

  • Posts: 1144
  • Joined: Wed Sep 17, 2014 7:15 pm
  • Location: UA

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 8:09 pm

We live in Wrong Gamma reality and there is nothing we can do with it. Most problems are due Interconnection between legacy and new technologies. Billions of video content already where encoded with 1-1-1 and no one will change things only because Apple introduce new "correct" way to do color management for video where 1-1-1 produce too bright gamma look. Apple just should do an exception and change it's color management logic for video from "mathematically correct gamma representation" to "legacy compatibility gamma look representation" Things are moving very slow so don't expect something will change globally in nearest 10-20 years.

P.S. Andrew Kolakowski's additional explanation about Resolve 16.2 added to first post.
All my custom made accessories for BMMCC/BMMSC now available here https://lavky.com/radioproektor/
Offline

franciscovaldez

  • Posts: 147
  • Joined: Wed Aug 22, 2012 4:52 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 8:12 pm

From what I can tell on my end, the result from exporting this way, with the "wrong tag", to trick other players, delivers the same result as to what I was doing before, which was to remove the tag externally with another app. But no I can avoid that extra step that a lot of time I forgot to do.

So I ask again, would it practical to have a "no tag" option on the deliver page? Or would that give a whole different wrong result.

The reason I insist in asking, is because for me that would be the obvious choice, if I didn't already know the other ways to achieve it. And was what I understood was going to be there, when the announcement that now it was possible to remove tags. And not that I would have to go check with which all the wrong tags it would look ok in other players...

I get it, it works and now I know how it's done and will do it that way. I also get it, that it's not Resolve's fault that other apps are reading it wrong, but since they went to the trouble of giving us the tool to address this issue. Couldn't they make it a bit more obvious with a "no tag" option?
Online
User avatar

Dmitry Shijan

  • Posts: 1144
  • Joined: Wed Sep 17, 2014 7:15 pm
  • Location: UA

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 8:17 pm

Dmitry Shijan wrote:We live in Wrong Gamma reality and there is nothing we can do with it. Most problems are due Interconnection between legacy and new technologies. Billions of video content already where encoded with 1-1-1 and no one will change things only because Apple introduce new "correct" way to do color management for video where 1-1-1 produce too bright gamma look. Apple just should do an exception and change it's color management logic for video from "mathematically correct gamma representation" to "legacy compatibility gamma look representation"


I hope after all these huge debates someone from Blackmagic tech team could explain this problem directly to Apple tech team.
All my custom made accessories for BMMCC/BMMSC now available here https://lavky.com/radioproektor/
Online
User avatar

Dmitry Shijan

  • Posts: 1144
  • Joined: Wed Sep 17, 2014 7:15 pm
  • Location: UA

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 8:23 pm

franciscovaldez wrote:From what I can tell on my end, the result from exporting this way, with the "wrong tag", to trick other players, delivers the same result as to what I was doing before, which was to remove the tag externally with another app. But no I can avoid that extra step that a lot of time I forgot to do.

So I ask again, would it practical to have a "no tag" option on the deliver page? Or would that give a whole different wrong result.

The reason I insist in asking, is because for me that would be the obvious choice, if I didn't already know the other ways to achieve it. And was what I understood was going to be there, when the announcement that now it was possible to remove tags. And not that I would have to go check with which all the wrong tags it would look ok in other players...

I get it, it works and now I know how it's done and will do it that way. I also get it, that it's not Resolve's fault that other apps are reading it wrong, but since they went to the trouble of giving us the tool to address this issue. Couldn't they make it a bit more obvious with a "no tag" option?


Resolve 16.2 provided all required options. It is up to users to learn how to use it. Your imaginary "no tag" option is BT.709 BT.709 BT.709 (or 1-1-1). Most editing apps never provide you any custom tag options at all and just always use 1-1-1 for any HD video source import and export.
All my custom made accessories for BMMCC/BMMSC now available here https://lavky.com/radioproektor/
Offline

franciscovaldez

  • Posts: 147
  • Joined: Wed Aug 22, 2012 4:52 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 8:52 pm

Dmitry Shijan wrote:
franciscovaldez wrote:From what I can tell on my end, the result from exporting this way, with the "wrong tag", to trick other players, delivers the same result as to what I was doing before, which was to remove the tag externally with another app. But no I can avoid that extra step that a lot of time I forgot to do.

So I ask again, would it practical to have a "no tag" option on the deliver page? Or would that give a whole different wrong result.

The reason I insist in asking, is because for me that would be the obvious choice, if I didn't already know the other ways to achieve it. And was what I understood was going to be there, when the announcement that now it was possible to remove tags. And not that I would have to go check with which all the wrong tags it would look ok in other players...

I get it, it works and now I know how it's done and will do it that way. I also get it, that it's not Resolve's fault that other apps are reading it wrong, but since they went to the trouble of giving us the tool to address this issue. Couldn't they make it a bit more obvious with a "no tag" option?


Resolve 16.2 provided all required options. It is up to users to learn how to use it. Your imaginary "no tag" option is BT.709 BT.709 BT.709 (or 1-1-1). Most editing apps never provide you any custom tag options at all and just always use 1-1-1 for any HD video source import and export.


When I read in the announcement "override tags" I translated in my mind as "no tag". I understand your point and now know how to do it within Resolve.

But I didn't imagine the "override tag" statement. The point I'm trying to make is: is it too much to ask to have an option that's called "override tag" (which I wrongly called before "remove tag")?

Or would doing this introduce new issues or misinterpretations?
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 9:51 pm

Default setting clearly says "As Project". With other options you can set what you want. It's self explanatory (at least for me).
It could have different wording, but I don't see current way been any confusing etc. (specially when manual will say what it does).
Offline

franciscovaldez

  • Posts: 147
  • Joined: Wed Aug 22, 2012 4:52 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 10:00 pm

Andrew Kolakowski wrote:Default setting clearly says "As Project". With other options you can set what you want. It's self explanatory (at least for me).
It could have different wording, but I don't see current way been any confusing etc. (specially when manual will say what it does).


Same as project is introducing a gamma shift for me.

Choosing plain Rec709, as per your recommendation, seems to do the trick.
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 10:12 pm

Same as project is not introducing any gamma shift if player behaves correctly as per MOV spec (eg. QT X).
Why do you assume that previewing based on Rec.709 tag is correct? It's far from being correct.
If you need color accurate preview then you need BM monitoring to some external monitor (ideally calibrated). Anything else is hardly ever going to show you really correct preview. Rest (all the tagging options etc.) at this time is pure random mess and basically useless for judging correct look. Avoid it.

You rely and put way too much importance to this tagging. It may matter more for home and prosumer users (for project which go to youtube etc.), but for broadcast and places with color accurate monitoring it's about meaningless and you should never use Rec.709 Scene based projects (which you seems to understand).
Last edited by Andrew Kolakowski on Wed Mar 11, 2020 10:36 pm, edited 6 times in total.
Online
User avatar

Dmitry Shijan

  • Posts: 1144
  • Joined: Wed Sep 17, 2014 7:15 pm
  • Location: UA

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 10:13 pm

franciscovaldez wrote:
Andrew Kolakowski wrote:Default setting clearly says "As Project". With other options you can set what you want. It's self explanatory (at least for me).
It could have different wording, but I don't see current way been any confusing etc. (specially when manual will say what it does).


Same as project is introducing a gamma shift for me.

Choosing plain Rec709, as per your recommendation, seems to do the trick.


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)
All my custom made accessories for BMMCC/BMMSC now available here https://lavky.com/radioproektor/
Offline

franciscovaldez

  • Posts: 147
  • Joined: Wed Aug 22, 2012 4:52 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 11, 2020 10:46 pm

Andrew, you are right. I'm assuming it is correct when I export with Rec709 tag, just because to my eye, it looks closer in contrast to what I'm getting on my calibrated monitor... Close, is good enough for me, since this doesn't affect my final deliveries just the movies or clips I'm sharing with my producers while in progress.

Dimitry, in my case I can't switch timeline to Rec709 (scene), without ruining my grades.

Your second suggestion does work, and is the one I'll be implementing.

Thank you both for your input.
Offline

jan_berlin

  • Posts: 17
  • Joined: Mon May 06, 2019 2:24 pm
  • Real Name: Jan Wiechmann

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Mar 13, 2020 8:38 am

Hey Folks.

Thanks for your explanations. Graet topic at all. But I have another question regarding the color space settings and the "Bypass re-encode when possible" feature.
If you want to insert/repair shots within your final export (reimport your previous export > edit > export again), does the bypass feature work for you, if you select any other color space (color management disabled) then Rec709 Gamma 2.4? No matter which color space/eotf your reimported file is tagged, export without transcoding works only in Rec709.
This behaviour has been reported since Resolve 15 (I think), when the bypass button was introduced. I there any explaination?
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Mar 13, 2020 12:30 pm

With bypass re-encode you get copy of your existing data + re-encode for all changed parts. Re-encode will be done according to your current project settings.
When it comes to headers then it can get bit messy (for codecs which have private headers). Resolve will write global eg. MOV header as per your current project settings, but private headers will remain as in original file (as Resolve simply copies this data to new file). Inserted bits will have new private values. It's not end of the world as in most cases private headers are ignored and this won't casques any issue.
Offline

jan_berlin

  • Posts: 17
  • Joined: Mon May 06, 2019 2:24 pm
  • Real Name: Jan Wiechmann

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Mar 13, 2020 1:02 pm

Nevertheless it only works with Rec709 :lol:
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Mar 13, 2020 1:25 pm

You mean in other cases it tries to re-encode anyway?

Maybe it will only bypass files if project matches exactly file headers? What if you overwrite them at clip level?
Offline

jan_berlin

  • Posts: 17
  • Joined: Mon May 06, 2019 2:24 pm
  • Real Name: Jan Wiechmann

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Mar 13, 2020 2:15 pm

Yes. No matter which metadata your clip has, project gave to be set up as Rec709g24 to make it work.
What if you overwrite them at clip level?

Dunno how :?
Offline

Vit Reiter

  • Posts: 505
  • Joined: Mon Sep 04, 2017 5:36 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Mar 13, 2020 4:55 pm

Andrew Kolakowski wrote:You seems to not understand how new 16.2 works.

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. Not sure what is so hard to understand here?
Have you actually tried this?
Yes, I have. Immediately with 16.2.

I see the export set tags in Advanced settings bring the same result like Output Color Space of Managed Color Space. If I import exported video to DaVinci again, Imput Color Space of video is Rec.709 (Scene) and has shift gamma opposite original video. So the way "... during export set tags to Rec.709 Scene (in Advanced settings)" is not good way - picture after export is different than original.
DaVinci Resolve 16.2 Studio
Mac Pro 2013, AMD FirePro D700, 64GB RAM, macOS Mojave 10.14.6
iMac 2017, Radeon Pro 575, 24GB RAM, macOS High Sierra 10.13.6

Film Editor, Colorist, DIT, Encoding technician
linkedin.com/in/vít-reiter-film-editor
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Mar 13, 2020 10:05 pm

Well- it's not to nice to lie about real nature of your video :D

All features are for users, but they have to understand how to use it.
I can just advice that you should never let Resolve auto detect your source files. You should always manually set real nature of the file (or otherwise if desired). Headers at this time are no near reliable enough to let any app rely on them. This is rather bad practice.

Just manually overwrite your falsely tagged file and all will be fine.
Offline

Vit Reiter

  • Posts: 505
  • Joined: Mon Sep 04, 2017 5:36 pm

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Mar 13, 2020 10:57 pm

Andrew Kolakowski wrote:Well- it's not to nice to lie about real nature of your video :D

All features are for users, but they have to understand how to use it.
I can just advice that you should never let Resolve auto detect your source files. You should always manually set real nature of the file (or otherwise if desired). Headers at this time are no near reliable enough to let any app rely on them. This is rather bad practice.

Just manually overwrite your falsely tagged file and all will be fine.
Andrew is a master in misting how to use DaVinci. The fact is that DaVinci from version 16.1.2 is not currently able to reliably export video with the appropriate metadata needed to process the exported master in other tools. :|
DaVinci Resolve 16.2 Studio
Mac Pro 2013, AMD FirePro D700, 64GB RAM, macOS Mojave 10.14.6
iMac 2017, Radeon Pro 575, 24GB RAM, macOS High Sierra 10.13.6

Film Editor, Colorist, DIT, Encoding technician
linkedin.com/in/vít-reiter-film-editor
Offline

Andrew Kolakowski

  • Posts: 6283
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Mar 13, 2020 11:06 pm

Lost my interest in discussion with you.
Offline

Peter Cave

  • Posts: 1854
  • Joined: Thu Aug 23, 2012 6:45 am
  • Location: Melbourne, Australia

Re: Final Explanation of Gamma and Color Shift Problems

PostSat Mar 14, 2020 7:00 am

[/quote]Andrew is a master in misting how to use DaVinci. The fact is that DaVinci from version 16.1.2 is not currently able to reliably export video with the appropriate metadata needed to process the exported master in other tools. :|[/quote]

Resolve 16.2 works great for me with Input formats auto detected correctly, processing on a rec709 gamma 2.4 timeline and output with ColorSpace & Gamma tags set to Same as timeline.
Previews match in all desktop players (except deprecated QT7 player) and also match original sources when re-imported into Resolve, Premiere or FCPX.
Resolve 16.2
Mac OSX 10.14.6, Hackintosh i7 8700 32GB RAM, Radeon RX 580 8GB
FSI LM1770 Calibrated Monitor, MIDIGrade 2.0, Zoom R16 Audio Interface.
Avid, FCPX, Premiere.
Online
User avatar

Dmitry Shijan

  • Posts: 1144
  • Joined: Wed Sep 17, 2014 7:15 pm
  • Location: UA

Re: Final Explanation of Gamma and Color Shift Problems

PostSat Mar 14, 2020 2:16 pm

In YRGB Color managed project i suggest you don't rely on auto detection and always manually set correct input color space for each file.
In YRGB project you can do it with input CST node.

See explanation in first post:
Part 7. YRGB vs YRGB Color Managed project settings in DaVinci Resolve
All my custom made accessories for BMMCC/BMMSC now available here https://lavky.com/radioproektor/
PreviousNext

Return to DaVinci Resolve

Who is online

Users browsing this forum: adaskruk, Hermès, mikea72580, Nigel Scott, Steven Reid, TonyGamble, Uli Plank and 75 guests