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: 3362
  • 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.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline
User avatar

Marc Wielage

  • Posts: 10901
  • 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

Dmytro Shijan

  • Posts: 1760
  • 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.
BMMCC/BMMSC Rigs Collection https://bmmccrigs.tumblr.com
My custom made accessories for BMMCC/BMMSC https://lavky.com/radioproektor/
Offline

Wayne Steven

  • Posts: 3362
  • 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. :)
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Andrew Kolakowski

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

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: 3362
  • 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?
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Andrew Kolakowski

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

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: 3362
  • 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. :)
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline
User avatar

Marc Wielage

  • Posts: 10901
  • 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: 3362
  • 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?
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Andrew Kolakowski

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

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: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

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: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

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: 2012
  • 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: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

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: 3362
  • 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.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Andrew Kolakowski

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

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: 3362
  • 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.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Andrew Kolakowski

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

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: 29
  • 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 Z8G4 win11pro 64bit- Quadro RTX A4000 GUI, Geforce RTX 3080 - Decklink 4k extreme 12g
m2max laptop osx 14.1.2
18.6.4
Offline
User avatar

Jamie LeJeune

  • Posts: 2012
  • 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: 3362
  • 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.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Wayne Steven

  • Posts: 3362
  • 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 mis-implement 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 could do it, 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 as well, along side CEO's and Chairman roles. The product/service, is the business, the administration (CEO) and planning (CEO and Chairman) are not, but such originators can also 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 (who 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. We have gone through the ages of dominance by authoritarianism, administrators, science, implementers (engineering and tech companies), and also workers, personality even (celebrity), and nerdism, now it is time for the practically creative.
Last edited by Wayne Steven on Wed Dec 11, 2019 2:32 am, edited 1 time in total.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Andrew Kolakowski

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

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: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

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: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

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

Wayne Steven

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

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Dec 11, 2019 2:35 am

amiroxx wrote: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.


What, no answers to subsequent questions, most strange?
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline
User avatar

d.dragun

  • Posts: 18
  • Joined: Sat Sep 29, 2018 9:52 pm
  • Location: Russia, Moscow
  • Real Name: Dima Dragun

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Dec 18, 2019 6:11 pm

Thank you for your post! Read it several times.

I have question about tags in macOS Get Info. For example I export from DVR with sRGB timeline. In macOS Get Info it's 1-13-1 color profile (it's correct, 13 is iec61966-2-1 trc).
But when I look at this file in mediainfo (or another info utilities), it's appear as bt709 trc (what should be 1-1-1), but macOS Get Info show me number 13.

So how macOS get this info about color profiles?
Are you sure that macOS get info 1-1-1 (x-y-z) is:
x: Color primaries
y: Transfer characteristics
z: Matrix coefficients
?

I couldn't find any information about macOS Get Info color profile.
Attachments
sRGB.mp4.zip
mp4 export from DVR 16.1.2 with sRGB timeline
(447.05 KiB) Downloaded 498 times
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Dec 18, 2019 11:16 pm

You have 2 places with headers- container and codec private headers (stream).
In this file sRGB headers are set on container level (but it's MP4 and most tools don't understand them- OSX does). Actual h264 data has headers set to 1-1-1 as it's shown but mediainfo and also Resolve itself (when you import file back to Resolve).

If you set mediainfo to detailed/complete view then it tells where it takes info from:

colour_description_present : Yes
colour_description_present_Source : Stream
Color range : Limited
colour_range_Source : Stream
Color primaries : BT.709
colour_primaries_Source : Stream
Transfer characteristics : BT.709
transfer_characteristics_Source : Stream
Matrix coefficients : BT.709

It's basically an example of badly flagged file where private and container headers are not aligned.
Export this as MOV and then mediainfo will show this misalignment in nicer way (it will show you both sets as it can read MOV headers).
Last edited by Andrew Kolakowski on Wed Dec 18, 2019 11:50 pm, edited 1 time in total.
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Dec 18, 2019 11:26 pm

Encoded to MOV:

colour_description_present : Yes
colour_description_present_Source : Container / Stream
Color range : Limited
colour_range_Source : Stream
Color primaries : BT.709
colour_primaries_Source : Container / Stream
Transfer characteristics : sRGB/sYCC
transfer_characteristics_Source : Container

transfer_characteristics_Original : BT.709
transfer_characteristics_Original_Source : Stream

Matrix coefficients : BT.709
matrix_coefficients_Source : Container / Stream

in most tools container flagging is more important. As you can see this can be very messy :D
In this case it's Resolve fault as it doesn't pass info properly to GPU h264 encoder, so it doesn't set h264 headers properly.
If you export eg. ProRes (which also has private headers) then everything is aligned and fine.
Offline
User avatar

d.dragun

  • Posts: 18
  • Joined: Sat Sep 29, 2018 9:52 pm
  • Location: Russia, Moscow
  • Real Name: Dima Dragun

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 19, 2019 12:09 am

Andrew Kolakowski wrote:Encoded to MOV:

colour_description_present : Yes
colour_description_present_Source : Container / Stream
Color range : Limited
colour_range_Source : Stream
Color primaries : BT.709
colour_primaries_Source : Container / Stream
Transfer characteristics : sRGB/sYCC
transfer_characteristics_Source : Container

transfer_characteristics_Original : BT.709
transfer_characteristics_Original_Source : Stream

Matrix coefficients : BT.709
matrix_coefficients_Source : Container / Stream

in most tools container flagging is more important. As you can see this can be very messy :D
In this case it's Resolve fault as it doesn't pass info properly to GPU h264 encoder, so it doesn't set h264 headers properly.
If you export eg. ProRes (which also has private headers) then everything is aligned and fine.


Thank you for good explain!

So macOS Get Info take flags from container, not from stream.
Very strange that "mediainfo -F" show only stream flags in my file, but macOS show container flags.

Flagging arrange is very awful :oops:
Offline

Wayne Steven

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

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 19, 2019 2:24 am

So, how are the values compensated for increased field of view, or even closeness to light source?

500 nits on a movie theatre filling up half your view is a lot more intense then a little 500 nit screen (55 inch) 12 feet away. Are there formulas for this over FOV, to target different delivery types? Distance decreases or increases brightness too, so the reaction of the visual system is different to the same graded content.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline
User avatar

waltervolpatto

  • Posts: 10502
  • 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

PostThu Dec 19, 2019 7:28 am

Wayne Steven wrote:So, how are the values compensated for increased field of view, or even closeness to light source?

500 nits on a movie theatre filling up half your view is a lot more intense then a little 500 nit screen (55 inch) 12 feet away. Are there formulas for this over FOV, to target different delivery types? Distance decreases or increases brightness too, so the reaction of the visual system is different to the same graded content.


Distance from a lambertian surface from the observer does not change the perceived (or measured) brightness: you measure or view an angle, therefore a surface. When you go further from the screen, the surface that the instrument measure get bigger and collect more light.

Empirically, put white on the screen of a theater, go at 1 meter and look at it. Then go back at 16 meters and look at it: if the light decrease with a square law, everything else being equals, you will have a screen so dim that nothing is visible anymore.

Instead, in a normal theater, the absolute luminance does not charge much between 1 meter and 20 meters.
W10-19043.1645- Supermicro MB C9X299-PGF - RAM 128GB CPU i9-10980XE 16c 4.3GHz (Oc) Water cooled
Decklink Studio 4K (12.3)
Resolve 18.5.1 / fusion studio 18
GPU 3090ti drivers 512.59 studio
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 19, 2019 9:45 am

So macOS Get Info take flags from container, not from stream.
Very strange that "mediainfo -F" show only stream flags in my file, but macOS show container flags.


If container flagging is missing then it will use stream one if present.
Mediainfo does not support reading flagging in MP4, otherwise it shows whatever it can find.
Offline
User avatar

Dmytro Shijan

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

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 19, 2019 11:29 am

Separate tags for container and for codec. Great, just great. Another problem that should never be exist. I just wonder why it all developed in so complicated way? Who controls this? Who responds for this? How this mess became industry approved standards? Even simple thing like aspect ratio have variations and mismatches that may produce endless problems viewtopic.php?f=21&t=104371&p=578183

By the way, it seems Finder Info window don't show those 1-1-1 or similar info tags if Spotlight is turned off system wide.
BMMCC/BMMSC Rigs Collection https://bmmccrigs.tumblr.com
My custom made accessories for BMMCC/BMMSC https://lavky.com/radioproektor/
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 19, 2019 1:58 pm

Bit messy and outdated, but key problem is that almost no one respects and applies those specs.

Maybe Spolight is responsible for reading them.
If no tag is found OSX color engine assumes some old schema- something like Rec.601, so this is not any good either.
Offline

Wayne Steven

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

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 19, 2019 5:11 pm

waltervolpatto wrote:
Wayne Steven wrote:So, how are the values compensated for increased field of view, or even closeness to light source?

500 nits on a movie theatre filling up half your view is a lot more intense then a little 500 nit screen (55 inch) 12 feet away. Are there formulas for this over FOV, to target different delivery types? Distance decreases or increases brightness too, so the reaction of the visual system is different to the same graded content.


Distance from a lambertian surface from the observer does not change the perceived (or measured) brightness: you measure or view an angle, therefore a surface. When you go further from the screen, the surface that the instrument measure get bigger and collect more light.

Empirically, put white on the screen of a theater, go at 1 meter and look at it. Then go back at 16 meters and look at it: if the light decrease with a square law, everything else being equals, you will have a screen so dim that nothing is visible anymore.

Instead, in a normal theater, the absolute luminance does not charge much between 1 meter and 20 meters.


Actually that is exactly what happens. They use this to give depth perception in pseudo 3D. At 2 metre the brightness decreases at the same rate as 4 meters then 8 meters then 16 meters, so the real drop is not that much compared to the adaption of human vision to adjust it to try to compensate to an individuals level. But, the adaption itself can change the perception and shift colors. As your square gets smaller as you move back, it also occupies less of your physical vision process, I think this might effect adaption, as you physically are stimulating less area of adaption mechanism. Now, as you move back, the field of view the screen occupies changes, this changes the organisational perception of what's on the screen, their relationships to one another, and the perceptual magnitude of sizes. This is why certain sizes and distances are used, and why the minimum close view screen should be at least 4 inches, and preferably 6 inches as size requires. If you can stick this closer to your eye without straining, affecting your perception, then it can be smaller. Smaller sizes, are not so good perceptually and tracking things. But then again, a young person could probably do with less, but you sell and set standards for wider markets. No, 4 inches is probably not going be the best for grading, it's going be more difficult to easily at rest deal with spatial perception, levels, colours and details. My personal taste is at least 30 inches+
closer, too go into the inner peripheral vision, to about 120 inches at several feet. The strain on eye, and viewing, effects feeling of perception.

So, we have situations where different content going to screens of different sizes, brightness, distances in differently lit environments. So, one is delivered to phone, another to tablet, another to TV, another to theatre. While the user can control their gamma on their TV, I don't think their are many phones that can do that with. You can basically adjust levels, rather reframe.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline
User avatar

Robin Erard

  • Posts: 138
  • Joined: Fri Mar 07, 2014 12:21 pm
  • Location: Switzerland

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 19, 2019 8:58 pm

Hello,

I played with those metadatas. You can find images here : https://we.tl/t-C7s0lIswwj

I edited metadatas with Atom Inspector and changed the nclc/nlcx tag and in both version 1-1-1 and 1-2-1

- VLC never changed
- QTX is clearly different than VLC.
- QTX 1-1-1 = QTX 1-2-1 (so the tag doesn't change anything). I'm on OSX 10.13.5.
- Changing nclc to nclx only affect QTX, VLC doesn't read this tag.
- None of this exports look exactly as my projector. VLC is closer I think.

Anyway, my only reference is my calibrated projector, connected to a Blackmagic card. For DCP it's not a problem because DCI rules are very precise. Of course, the best thing would be to be able to export Prores and to be sure it will be well displayed. Personally, when I deliver Prores or MXF to the Swiss television, I always indicate the correct gamma and colorspace into the name of the file... and I cross my fingers and hope the technician interprets my export correctly before to broadcast it.

Best

Robin
Robin Erard
www.rougegorge-postproduction.ch
http://www.imdb.com/name/nm2831668/
Colorist, director, editor
Nord 13, 2300 La Chaux-de-Fonds
Switzerland
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 19, 2019 11:53 pm

1-2-1 by itself does nothing.
You need to add for such tagging gamma value to whatever you used for grading, eg. 2.2 or 2.4. This will give you fully correct tag and QTX preview (matching Resolve GUI).

You need to achieve this:

Image
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Dec 19, 2019 11:57 pm

Robin Erard wrote:...Personally, when I deliver Prores or MXF to the Swiss television, I always indicate the correct gamma and colorspace into the name of the file... and I cross my fingers and hope the technician interprets my export correctly before to broadcast it.
Best
Robin


This should be enough in case of TV.
Offline
User avatar

Robin Erard

  • Posts: 138
  • Joined: Fri Mar 07, 2014 12:21 pm
  • Location: Switzerland

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Dec 20, 2019 6:10 am

Hello thank’s,

Where could I change this metadata? I mean, in Atom Inspector.

Best

Robin
Robin Erard
www.rougegorge-postproduction.ch
http://www.imdb.com/name/nm2831668/
Colorist, director, editor
Nord 13, 2300 La Chaux-de-Fonds
Switzerland
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Dec 20, 2019 9:55 am

Don't know. It's gamma tag.
It's probably not in the file and needs to be added. Not sure if Atom Inspector can do it.
Offline
User avatar

Robin Erard

  • Posts: 138
  • Joined: Fri Mar 07, 2014 12:21 pm
  • Location: Switzerland

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Dec 20, 2019 2:09 pm

Hello,

I found the place where gamma indication is. But it appears only if the Quicktime file is modified with Jes Extensifier.

Atom et Jes.png
Atom et Jes.png (509.7 KiB) Viewed 28493 times


I don't know if there is an other way to integrate this specific metadata.

Best
Robin
Robin Erard
www.rougegorge-postproduction.ch
http://www.imdb.com/name/nm2831668/
Colorist, director, editor
Nord 13, 2300 La Chaux-de-Fonds
Switzerland
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Dec 20, 2019 7:41 pm

Not sure which other tool can add gamma tag, maybe Pro Media Tools.
Offline

Cosmin Hodiș-Mîndraș

  • Posts: 62
  • Joined: Wed Mar 13, 2013 9:00 pm
  • Location: Cluj-Napoca, Romania

Re: Final Explanation of Gamma and Color Shift Problems

PostSat Dec 21, 2019 4:58 pm

Unfortunately the author of JES Extensifier - Jan E. Schotsman - has passed away, and his website is no longer on-line. The forum is still available (http://jes.weiss.no) but no working links are provided.

Do anyone has the v3 (64-bit)? I have searched for it, but to no avail...
iMac 27-inch Retina 2017 (4.2 GHz i7, Radeon Pro 580 8GB, 32GB RAM, 2TB SSD) | DaVinci Resolve Studio 18 Public Beta 2 | UltraStudio 4K Extreme 3 | Resolve Micro Panel | Desktop Video 12.2.3 | Ursa Mini Pro 4.6K
Offline
User avatar

Dmytro Shijan

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

Re: Final Explanation of Gamma and Color Shift Problems

PostSat Dec 21, 2019 5:19 pm

Cosmin Hodiș-Mîndraș wrote:Unfortunately the author of JES Extensifier - Jan E. Schotsman - has passed away, and his website is no longer on-line. The forum is still available (http://jes.weiss.no) but no working links are provided.

Do anyone has the v3 (64-bit)? I have searched for it, but to no avail...


:arrow: Here is my backup of JES Tools for everyone: https://www.dropbox.com/sh/x8o2q07zyb6g ... Ome8a?dl=0
BMMCC/BMMSC Rigs Collection https://bmmccrigs.tumblr.com
My custom made accessories for BMMCC/BMMSC https://lavky.com/radioproektor/
Offline

Cosmin Hodiș-Mîndraș

  • Posts: 62
  • Joined: Wed Mar 13, 2013 9:00 pm
  • Location: Cluj-Napoca, Romania

Re: Final Explanation of Gamma and Color Shift Problems

PostSat Dec 21, 2019 6:21 pm

Thank you a lot, Dmitry! JES Extensifier still works on macOS Catalina, being 64-bit, unfortunately the other tools do not.
iMac 27-inch Retina 2017 (4.2 GHz i7, Radeon Pro 580 8GB, 32GB RAM, 2TB SSD) | DaVinci Resolve Studio 18 Public Beta 2 | UltraStudio 4K Extreme 3 | Resolve Micro Panel | Desktop Video 12.2.3 | Ursa Mini Pro 4.6K
Offline
User avatar

Dmytro Shijan

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

Re: Final Explanation of Gamma and Color Shift Problems

PostSat Dec 21, 2019 7:08 pm

Cosmin Hodiș-Mîndraș wrote:JES Extensifier still works on macOS Catalina, being 64-bit, unfortunately the other tools do not.

Just don't use macOS Catalina. There are still endless amount of apps, plug-ins and hardware drivers that still exist only in 32 bit. I can change system icons back to normal human friendly "10.5 look" on Mojave, but 32 bit apps disaster with Catalina + more and more totalitarian Apple control for everything on your computer with each MacOS update makes future very uncertain for me.
BMMCC/BMMSC Rigs Collection https://bmmccrigs.tumblr.com
My custom made accessories for BMMCC/BMMSC https://lavky.com/radioproektor/
Offline
User avatar

d.dragun

  • Posts: 18
  • Joined: Sat Sep 29, 2018 9:52 pm
  • Location: Russia, Moscow
  • Real Name: Dima Dragun

Re: Final Explanation of Gamma and Color Shift Problems

PostSun Dec 22, 2019 10:21 pm

One more drop of water in the oil.
Project in DVR with sRGB timeline export in h264.
But first time in MPEG-4 (.mp4) container and second in QuickTime (.mov) container.

"mediainfo -F input"

mov:
Code: Select all
colour_description_present               : Yes
colour_description_present_Source        : Container / Stream
Color range                              : Limited
colour_range_Source                      : Stream
Color primaries                          : BT.709
colour_primaries_Source                  : Container / Stream
Transfer characteristics                 : sRGB/sYCC
transfer_characteristics_Source          : Container
transfer_characteristics_Original        : BT.709
transfer_characteristics_Original_Source : Stream
Matrix coefficients                      : BT.709
matrix_coefficients_Source               : Container / Stream


mp4:
Code: Select all
colour_description_present               : Yes
colour_description_present_Source        : Stream
Color range                              : Limited
colour_range_Source                      : Stream
Color primaries                          : BT.709
colour_primaries_Source                  : Stream
Transfer characteristics                 : BT.709
transfer_characteristics_Source          : Stream
Matrix coefficients                      : BT.709
matrix_coefficients_Source               : Stream


So as I discover previously, macOS Get Info take info about 1-13-1 in mp4 file from container, not from stream.
And mediainfo in mp4 show info about stream only. In mov file mediainfo can show container and stream info about tags.
(macOS show 1-13-1 in both file)
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostSun Dec 22, 2019 10:27 pm

Already explained- mediainfo has no support for MP4 headers.
PreviousNext

Return to DaVinci Resolve

Who is online

Users browsing this forum: Jim Simon, panos_mts and 166 guests