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

Wayne Steven

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

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Nov 26, 2019 4:59 am

That wasn't the point, HLG can deliver SDR too. With updates, support for this will grow. Thinking about this during the day, maybe it was mapping the lower color gumut to rec2020 made the colour hang better. Can't remember, got too go. Have a great day Marc.
Often people deceive themselves so much they do not understand, even when the truth is explained to them.
Offline
User avatar

Marc Wielage

  • Posts: 6155
  • Joined: Fri Oct 18, 2013 2:46 am
  • Location: Hollywood, USA

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Nov 26, 2019 10:26 am

Hey, this discussion made it to 150 messages! Let's see how long it goes before people read the links and figure out that this problem has been going on for decades.
marc wielage, csi • VP/color & workflow • chroma | hollywood
Offline
User avatar

Dmitry Shijan

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

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Nov 26, 2019 10:51 am

It is great that moderators pin this thread at the top of the page. Looks like we collect some really useful and important info here :idea:

P.S. Even with proper display calibration things will always look different. A lot depends of monitor light source itself. LED vs CCFL backlight lamps vs Plasma vs vs OLED looks different. Even different CCFL backlight lamps may produce different light. I personally use two DELL U2311H monitors (revision.2 made in Czechia and revision.3 made in China). They have different CCFL lamps with different native temperature. Calibration makes them look very close but i can still see some difference because of different backlight.

HDR delivery is currently something very special and very different to normal workflow and delivery. HDR delivery is separate delivery. So let's don't mix this gamma shift related discussion with HDR delivery problems.
All my custom made accessories for BMMCC/BMMSC now available here https://lavky.com/radioproektor/
Offline

Wayne Steven

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

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Nov 26, 2019 12:09 pm

Well, because there was no real solution, I am interested in side stepping using more modern standards, and letting the player remap. It's increasing the players output accuracy I'm interested in

However, I am not interested in the last 1% of accuracy per say, even 10% might be acceptable (sorry Marc) and you can't do anything about a bad display unless you map for it, so that too is moot and not worth for discussing. But just to get the playback to map better. If that means abandoning conventional gamut or SDR, so be it. :)
Often people deceive themselves so much they do not understand, even when the truth is explained to them.
Offline

Andrew Kolakowski

  • Posts: 5911
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Nov 26, 2019 7:31 pm

Going HDR to solve SDR issues- good luck :)

Solution is quite simple- introduce (for h264, h265, MOV etc. headers) standardised signalling for Rec.709 2.2 and 2.4 gamma and 95% of problems will be gone.
Very quick and simple solution for Mac. Change OSX gamma for Rec.709 tag from 1.96 to 2.2. (or 2.4) and all current files will start looking properly.
Offline

Wayne Steven

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

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Nov 27, 2019 12:30 am

Thank you Andrew for your sensible talk.

But what happens if you want to go DCI, rec2020, HDTV content?
Often people deceive themselves so much they do not understand, even when the truth is explained to them.
Offline

Andrew Kolakowski

  • Posts: 5911
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Nov 27, 2019 12:34 am

This already works better than Rec.709 tagging. Just update it if needed together with Rec.709 changes.
Offline

Wayne Steven

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

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Nov 27, 2019 12:46 am

Thanks Andrew. :)
Often people deceive themselves so much they do not understand, even when the truth is explained to them.
Offline
User avatar

Marc Wielage

  • Posts: 6155
  • Joined: Fri Oct 18, 2013 2:46 am
  • Location: Hollywood, USA

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Nov 27, 2019 7:45 am

Wayne Steven wrote:Thank you Andrew for your sensible talk. But what happens if you want to go DCI, rec2020, HDTV content?

Where do you plan to deliver this? No monitor can reproduce all of Rec2020 yet.

I think this is a solution in search of a problem. I would worry only about real standards that exist, like Rec709 and an actual HDR delivery in something like Dolby Vision. That's a real standard that you can see under controlled conditions, and it's actually supported by Amazon, Apple, Disney, and Netflix.

DCI standards are real, but I'd say for best results, you need to watch them on a DCI-calibrated projector. That's only for 2K, not (technically) for HD.
marc wielage, csi • VP/color & workflow • chroma | hollywood
Offline

Wayne Steven

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

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Nov 27, 2019 9:03 am

?? Did I say it had to 100% rec2020 color space or compliant?
Often people deceive themselves so much they do not understand, even when the truth is explained to them.
Offline

Andrew Kolakowski

  • Posts: 5911
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Nov 27, 2019 10:10 am

P3 gamut inside Rec.2020 is answer to your question. If you want to deliver something above Rec.709 with 'standard' gamma then this can be used ( exactly like it's done for HDR). You can grade to P3 with 2.4 gamma and export as Rec.2020. This will work on TVs and Mac. Actually this could work for Rec.709 limited gamut as well. Nothing stops you deliver smaller gamuts inside bigger ones (as long as math behind translation is robust).
Last edited by Andrew Kolakowski on Wed Nov 27, 2019 10:14 am, edited 2 times in total.
Offline

Andrew Kolakowski

  • Posts: 5911
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Nov 27, 2019 10:13 am

Marc Wielage wrote:
Wayne Steven wrote:Thank you Andrew for your sensible talk. But what happens if you want to go DCI, rec2020, HDTV content?

Where do you plan to deliver this? No monitor can reproduce all of Rec2020 yet.

I think this is a solution in search of a problem. I would worry only about real standards that exist, like Rec709 and an actual HDR delivery in something like Dolby Vision. That's a real standard that you can see under controlled conditions, and it's actually supported by Amazon, Apple, Disney, and Netflix.

DCI standards are real, but I'd say for best results, you need to watch them on a DCI-calibrated projector. That's only for 2K, not (technically) for HD.


Resolution has nothing to do with gamut or gamma. You can have SD, HD or UHD file flagged as DCI P3.
DCI standard may not suit for normal displays due to 2.6 gamma.
Offline

Andrew Kolakowski

  • Posts: 5911
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Nov 27, 2019 1:43 pm

Inserting Rec.709 2.4 into standard Rec.2020 signal works like a charm on Mac. You have perfect preview staying with some standard signalling (without additional gamma tag).

Why on earth Resolve has no gamma settings for Rec.2020 standard?

Maybe this is why:
"While the Rec. 2020 transfer function can be used for encoding, it is expected that most productions will use a reference monitor that has an appearance of using Gamma 2.4 transfer function as defined in Rec. ITU-R BT.1886 and that the reference monitor will be evaluated as defined in Rec. ITU-R BT.2035.[1][13][14]"

yet no one ever introduced any singling for such a case. It's all messy.

Youtube was close to passing this Rec.2020 singling, but not fully. It changed transfer function to Rec.709 which of course causes on Mac bad preview. I think both Youtube and Vimeo work on principle to normalise every source into Rec.709, which of course for color managed Mac preview causes problems (due to Rec.709 being treated as 1.96 gamma).

1 interesting fact. Vimeo will show correct preview before you hit play. This is most likely still which has sRGB profile assigned, so OSX color engine processes it properly (Vimeo converts between profiles during processing). Once you hit play flagging changes to Rec.709 (1-1-1) and will of course cause video to show up to bright (due to 1.96 gamma used for conversion).
Offline
User avatar

Jamie LeJeune

  • Posts: 1169
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Nov 28, 2019 6:19 am

Andrew Kolakowski wrote:Why on earth Resolve has no gamma settings for Rec.2020 standard?
Because REC2020 only defines a color space, not a gamma. Thus, there is no such thing as a "REC2020 gamma" setting. The REC2020 color space can be applied to any gamma you choose. In the color space transform OFX and in the Resolve Color Management settings, the color space and gamma are each defined separately.

EDIT: I neglected to add “in practice” — yes the REC2020 documentation is for SDR and includes a defined gamma (essentially BT1886 with added precision) but REC2020 color space is also used for REC2100 which defines an HDR EOTF so REC2020 color space can be paired with various EOTFs in SDR and HDR. So any reference to “REC2020” without specifying an EOTF is ambiguous.
Last edited by Jamie LeJeune on Fri Nov 29, 2019 9:01 am, edited 1 time in total.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

Andrew Kolakowski

  • Posts: 5911
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Nov 28, 2019 9:45 am

Not true. Spec clearly defines tranfer function for Rec.2020. Even 2 options.
It's actually the same transfer function as for Rec.709, but with higher precision. Use of 2.4 gamma ( or more precisely BT.1886) is a recommendation, but of course there is no unique flagging for it. Another messy situation, similar to Rec.709 story.
When TV receives Rec.2020 flagged signal how it's going to know what gamma it's? It's TV manufacture hard coded choice or user setting. For HDR they were able to provide unique flagging for HLG and PQ, but SDR it's again not so obvious.
What do you think OSX color engine expects for Rec.2020 SDR signalling? No, it's not recommended BT.1886 (or pure 2.4 gamma). New standard, old mess from the very beginning. Why on earth h265 did not get flagging for BT.1886/2.4 when all SDR current files should use it?
In Rec.2100 they totally omit SDR and just focused on HDR. What % is HDR currently of all 'video' productions? :D
Hopeless...
Offline

Wayne Steven

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

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Nov 28, 2019 4:49 pm

What happens if you transfer remap into bt2100 HLG HDR, will the important players output it right (forgetting about the accuracy of screens at the moment)?

Seems the standards compliance out there presumes options, and aren't very thorough.
Often people deceive themselves so much they do not understand, even when the truth is explained to them.
Offline

Andrew Kolakowski

  • Posts: 5911
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Nov 28, 2019 4:54 pm

HLG to SDR is no that easy. Apple color engine has no support for it.
Without proper conversion with tone mapping end results are crap.
Offline

Wayne Steven

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

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Nov 29, 2019 3:10 am

HLG has one tone function, and is supposed to be SDR compatable (maps to an SDR signal) so that is surprising that they stuff that up aswell.

Why don't they just over size display resolution a bit, and use the surrounding pictures to emulate a well lit environment of your choice (hmm, then again, most lcd's lack enough contrast black control)? You could do Phillips ambilight or Dolby cinema like hue effects.
Often people deceive themselves so much they do not understand, even when the truth is explained to them.
Offline

Andrew Kolakowski

  • Posts: 5911
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Nov 29, 2019 9:54 am

It's not looking good. Dull and lifeless. Similar to wrong gamma been applied.
Offline
User avatar

amiroxx

  • Posts: 16
  • Joined: Thu Nov 22, 2012 1:54 pm
  • Location: Deutschland
  • Real Name: Michael Radeck

Re: Final Explanation of Gamma and Color Shift Problems

PostSat Dec 07, 2019 11:49 pm

that there are gamma shifts mostly related to mac os x and apples bad color management implementation to Quicktime - no question

but most what is written here is adding more horror nonsense blah blah blah... it is annoying!

what is true:

Apple video gamma correction value was just taken from some random value by a hired coder who doesn't understand the concept of gamma.

In my experience, as a consultant for several manufacturers and developers in the media industrie, I can tell you, that many engineers and coders really misunderstood the SMPTE or DCI specifications. The results are mistakes in the hardware video IOs and mistakes in software and mistakes in whitepapers. I helped out EIZO, SMALL HD, Dolby!!!, AJA, AVID and many more.

One problem with gamma is that the (older) SMPTE specifications are incomplete in terms of display gamma, only with the newest BT1886 there is now a concrete specification for gamma. But nearly all video displays are based on the older power gamma, not on the BT1886... that is also a new problem, cause newer consumer TVs use sometimes and more and more will do BT1886... (near to gamma 2.4 but looking different in the blacks)

filmlights correct implementation of NCLC tags is the only correct way to prevent this problem on mac systems.

Blackmagic should also implement those NCLC tags for Quicktime files...

all other explanations and solutions that here are presented and linked are 99% nonsense like apple's code

think about: only 10% of the whole computer market in the world are Apple computers. So if you want to have a better-controled environment with not so much color or gamma shift problems, do no use apple computer or apple computer monitors especially that are not calibrated by a professional calibrator.
Do not care about proofing any kind of video on to an apple computer connected monitor. Use a controlled video monitor with video IO connection, do not connect to a graphic card... i also do not recommend the upcoming apple monitor even if Apple claims it is calibrated as a reference monitor, if they do not solve the color management errors, it does not make sense.

Especially nearly any explanation and tips here in this thread on how to use gamma settings are wrong.

Cullen Kelly - wrong ... "and one targeting Rec. 709 Gamma 2.2 (for Vimeo)" --- nonsense:
no content distributor has any gamma specification and should not have any, cause no one can assume that those videos are only viewed at bright daylight conditions like in an office

The article "https://blog.frame.io/2019/10/14/grading-mixed-delivery/" does not give any concrete solution it states only typical problems the rest is blah blah blah after reading this you do not know more than before, sure anyone should use controled setups, but how to setup correct no one explains!


FSTOPPERS video about calibration (former wedding videographer - what a qualification) - wrong - "spyder horror": if you want to prevent to even calibrate your colors worse then they would have been from factory, do not use spyder or i1display probes, your chance to get more deviations than the display had when it was delivered are near to 100%, especially with better displays from Eizo, BenQ, NEC, etc. even with the cheap onboard probes from Eizo you will not prevent to stop the drifts that happen, I found only after 1 year a big delta E2000 above 3 even with those onboard probes used on a regular monthly bases. Above 3 means "ok i see colors" but you are far away from being looking at a reference display. Do not buy those crap stuff. Better save your money, it is not worse it at all! Spend this money in a professional calibration or stay with the factory setup. A good display like an EIZO CG has professional settings for rec709, DCI p3, P3, EBU and many more, you can control the gamma directly like 1.8, 2.0, 2.2. 2.4, 2.6.... and more, you can control the whitepoint in a kelvin range rec709 norm is 6500k

In general, gamma is not specified for rec709 deliveries!! Especially gamma should never be targeted in the metadata or encoded differently in files (only apple os needs this, cause it is there implemented by a misconception). Gamma is only related to the monitor/projector and is only depending on the amount of ambient light conditions of the current viewing stuff. The problem is, that nearly all findings here or explanations completely ignore this fact, the result is, that no one really would solve the main reasons behind these problems. In fact, all solutions here make it even worse.
The gamma of a recorded file of a rec709 camera setup is normally at 0.45 (not 2.2 or 2.4 or 2.6) (the human eye has the same and this is (should always) fixed (besides the creative grading!!)
If you do a proper grading under correct viewing conditions and according to the viewing conditions correct setup for the monitor gamma like 2.4 in a dark studio setup, then the same file gamma of 0.45 should be viewed with gamma 2.2 monitor setup on an office environment and the file should look the same in this brighter environment. So the gamma of the file does not need to be changed, the gamma of the monitor setup is the key. That is how gamma has to be used.... so the different gamma setups for Davinci resolve in their color management, do not make any sense, as also the apple color management does not make any sense in terms of gamma handling.
HP Z820 win10pro 64bit v1903 - Quadro RTX4000 GUI, Geforce RTX 2080 - Decklink 4k extreme 12g
Offline
User avatar

Jamie LeJeune

  • Posts: 1169
  • Joined: Tue Feb 26, 2013 4:33 am
  • Location: San Francisco

Re: Final Explanation of Gamma and Color Shift Problems

PostSun Dec 08, 2019 12:52 am

amiroxx wrote:Blackmagic should also implement those NCLC tags for Quicktime files...

Resolve does apply NCLC tags to the exports. That's the whole reason for this thread. It used to be that tags were only correctly set when working in Resolve Color Management mode. Now, from version 16.1 in 'Davinci YRGB' mode, the 'timeline color space' setting can also determine the NCLC tag applied on export.

However, the problem we all run into is that a lot of software ignores the NCLC tags for HD video and assumes 1-1-1 (for example, VLC). Also, many commonly used transcoders also ignore the NCLC tags and apply 1-1-1 to all files by default. For Quicktime files exported with any other tag, there will be a viewing mismatch between applications that read the tags versus those that ignore them and always assume 1-1-1. So, as far as I've seen, the only way around the problem is to render out Quicktime files with a 1-1-1 tag and that look correct with that tag so that regardless of whether the software reads the tags or not, the file will be interpreted the same across all apps.
Last edited by Jamie LeJeune on Sun Dec 08, 2019 10:29 am, edited 2 times in total.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

Wayne Steven

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

Re: Final Explanation of Gamma and Color Shift Problems

PostSun Dec 08, 2019 3:20 am

Thanks Michael. When you ask questions and you hear a lot of wind, you have to wonder how much substance there is. But Jamie is right, it is about maintaining the look over different players and hardware, but there is another issue, interpretation of mapping in HDR, which I understand is a corker. So, I'm realistically not expecting every player to produce the right output, but if players which cover most people can be, that's good enough (all disc, most services, most Linux, most windows, most Apple. The rest of the players can learn to be more respectful of their customers, and implement things better, or suffer the reputation. You can't chase every crazy cat around to get it right.

However, now it appears that the implementations of the modern of HDR are also fairing little better. So, what is the ideal HDR workflow chain and solution? I was interested in the HLG solution as a simple HDR to get consistent mapping between hardware and SDR, that some are trying to expand upon dynamically frame to frame also. But those implementations are stuffed up as well I am told here. I could have targetted doing things in it in BT2100 as a starting point, as except bit depth, it pretty much is a good future proof base starting point. I'm interested in something beyond 709.

I think Resolve should hire a consultant to ensure the stability of workflow outputs.
Often people deceive themselves so much they do not understand, even when the truth is explained to them.
Offline

Wayne Steven

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

Re: Final Explanation of Gamma and Color Shift Problems

PostSun Dec 08, 2019 4:06 am

Anyway Michael, you mention calibration. Is there any good cheap robust calibration out there for SDR and HDR, and which displays?

Another question, why don't the display standards clarify their standards through research and educational documents and tutorial videos, very sitting all the major players (contact and chat over phone and email, and provide links).

I am a bit shocked at some of the names, as I'm used to the computer industry spaghettigying stuff, but I wouldn't expect some of those companies to do that. Things are so stuffed up. Sometimes I want to take up consultancy, just to help rectify at least bsome things out there, but am not well enough long enough. But the story is the same for years, the consultant will recommend, but then they are fortunate if at least something doesn't get thrown into the bin, if not the whole thing. What gets implemented maybe misinterpreted or misinplented, stuffing things up. I pretty much am dubious about community feedback on major infrastructure now. You can give it, but when they come along to implement the suggestions, they may simplement it, stuffing it up in weird ways and costing tens of millions of dollars. It's cheaper for the community and government if I don't suggest anything that will actually benefit them compared to what they do with it instead. They have fundamental issues, like thinking they can do whatever in themselves, and not consulting with the person who actually figured it out. Seen this suggesting to major companies too, like Google android, most of you are carrying around heaps of improvements I suggested, and using a number on the desktop. I would have loved to run a company myself, getting it all accurate so we wouldn't have messes. The system is broken, very broken. By my calculations, the development from no technology to high speed star travel could take less than 500 years (you need people who can actually from hire out these things) but after so many thousands of years of civilisation we don't have any official manned planetary travel past the moon, despite now old valid high speed technology proposals which were not officially developed but canned.

What we need is originators, the ones good at analytically and creatively coming up with and developing how to do ideas=designs, as directors of business and business plans, along side CEO's and Chairman roles. The product/service, is the business, the administration (CEO) and planning (CEO and Chairman) is not but such originators can so be good consultants in that area. Originators may likely not be good at administration or implementing their designs, but good ones can pick the right people to run these jobs. There needs to be a third arm of business after workers and officers, the creative designers with their own hierarchical structure co-working in teams with officers/workers /implementers (which may be in any of these groups, according to their ability). By this, we can greatly accelerate progress. There are some very talented people going to waste under the direction of incompetent administration trying to dictate progress.
Often people deceive themselves so much they do not understand, even when the truth is explained to them.
Offline

Andrew Kolakowski

  • Posts: 5911
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Final Explanation of Gamma and Color Shift Problems

PostSun Dec 08, 2019 10:07 am

amiroxx wrote:
what is true:

Apple video gamma correction value was just taken from some random value by a hired coder who doesn't understand the concept of gamma.

In my experience, as a consultant for several manufacturers and developers in the media industrie, I can tell you, that many engineers and coders really misunderstood the SMPTE or DCI specifications. The results are mistakes in the hardware video IOs and mistakes in software and mistakes in whitepapers. I helped out EIZO, SMALL HD, Dolby!!!, AJA, AVID and many more.

One problem with gamma is that the (older) SMPTE specifications are incomplete in terms of display gamma, only with the newest BT1886 there is now a concrete specification for gamma. But nearly all video displays are based on the older power gamma, not on the BT1886... that is also a new problem, cause newer consumer TVs use sometimes and more and more will do BT1886... (near to gamma 2.4 but looking different in the blacks)

filmlights correct implementation of NCLC tags is the only correct way to prevent this problem on mac systems.

Blackmagic should also implement those NCLC tags for Quicktime files...

As far as I been told Apple QT spec was written by broadcast veterans, not random programmers. It was done long time ago. It's still the most, full and advanced system related to videos (just bit outdated now).
Even if it's 'industry' problem (including crazy slow SMPTE) and taking into fact that it was written so long time ago (with just few later changes) it does work. It's everyone else than Apple who ignores all tagging etc. which is the main reason for all this mess. Another reason are SMPTE and others who omit most important tagging in quite new technologies. I asked so many times- where is tagg for BT.1886 which is current standard for SDR videos?

Filmlight has done nothing more except properly using what is already available.
BlackMagic also does it now, so you are bit outdated (for few good months now).

In general, gamma is not specified for rec709 deliveries!!


And this is the core reason of all these problems…
Well- now it's specified, but even new technologies (h265) simply forgotten about it (yet have all outdated and useless flags).

I've asked BM what is the gamma behind Rec.709 choice in Resolve. Answer was- as per Rec.709 spec. But spec doesn't specific any gamma related to monitoring :lol:

Whole problem is a "industry" problem, not Apple's.
Apple's choice for Rec.709 gamma is not from nowhere. Their 1.96 approximation is based on the Rec.709 spec itself:

"The power function of the majority of the gamma curve is 0.45, but because it is offset by the linear section the resulting equivalent gamma is more approximate to 0.50-0.53 (the inverse of which is approximately gamma 1.9-2.0 to convert back to linear)."

Problmes is that value is useless these days as no one grades to 1.96 gamma.
It's all plain and simple- just in no ones interest to fix it (same as some companies are not interested to provide proper GPU monitoring) as there is no money behind it :lol:

Whole argument that you need and will ever need dedicated card to display video accurately as oppose to just using GPU is one big bullxxx :) All what you need is move forward and use properly current technology, not live by 20 years old one. Todays GPUs are more than enough to handle this task.
Print industry been using GPUs for years and they need to be as accurate as video world.
Last edited by Andrew Kolakowski on Sun Dec 08, 2019 10:48 am, edited 3 times in total.
Offline

Andrew Kolakowski

  • Posts: 5911
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Final Explanation of Gamma and Color Shift Problems

PostSun Dec 08, 2019 10:32 am

amiroxx wrote:The gamma of a recorded file of a rec709 camera setup is normally at 0.45 (not 2.2 or 2.4 or 2.6) (the human eye has the same and this is (should always) fixed (besides the creative grading!!)
If you do a proper grading under correct viewing conditions and according to the viewing conditions correct setup for the monitor gamma like 2.4 in a dark studio setup, then the same file gamma of 0.45 should be viewed with gamma 2.2 monitor setup on an office environment and the file should look the same in this brighter environment. So the gamma of the file does not need to be changed, the gamma of the monitor setup is the key. That is how gamma has to be used.... so the different gamma setups for Davinci resolve in their color management, do not make any sense, as also the apple color management does not make any sense in terms of gamma handling.


How your TV meant to then know if your file is SDR or HDR if you abandon tagging? What if video is HDR, but TV can barely do SDR with small gamut? It was all much easier when there was about one Rec.709 standard (even if not full). We passed this. Now we need a lot more advanced and inteligent players/TVs/playback systems.
There have to be some tagging, but no one is really interested in providing it (again, no real money there- plain simple :D ).
Offline

Andrew Kolakowski

  • Posts: 5911
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Final Explanation of Gamma and Color Shift Problems

PostSun Dec 08, 2019 10:59 am

amiroxx wrote:
filmlights correct implementation of NCLC tags is the only correct way to prevent this problem on mac systems.



It solves nothing for general public. In some cases (like Resolve users found) it creates even bigger mess as "others" are simply not ready for those correct tags.
Previous

Return to DaVinci Resolve

Who is online

Users browsing this forum: DaRookie, detroitechno, LauraE, Leslie Wand and 96 guests