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

awppollock

  • Posts: 70
  • Joined: Mon Jul 20, 2020 6:43 pm
  • Real Name: Alex Pollock

Re: Final Explanation of Gamma and Color Shift Problems

PostFri Dec 18, 2020 4:52 am

Andrew Kolakowski wrote:Not sure why.
Just try setting project itself this way.



When I try this I get craaaaazy extreme colors happening to my image. I am so discouraged by this. My images seem to be coming out darker than the viewer and even when the Quicktime image closely resembles the Resolve viewer, the same image on my phone looks completely different. Has anyone put together a SUCCINCT solution to these issues? There’s so many pages of nuanced tech talk here I could really use someone’s help understanding how to improve or accept what must be accepted. I just don’t know up from down at this point. I’m working on a 2019 Macbook Pro maxed out. Posts with screenshots on my page. Thanks.
Offline
User avatar

dariusii

  • Posts: 228
  • Joined: Tue May 15, 2018 1:38 pm
  • Location: Odintsovo
  • Real Name: Dmitry Nesterov

Re: Final Explanation of Gamma and Color Shift Problems

PostSun Feb 21, 2021 7:29 pm

>Rec.709-A reads Rec709 gamma in Apple way

There's a one interesting moment.
If I will be use rec.709-A, so I'll be watch my created movie in qtime well. But - if I'll watch that movie under iOS (iphone/ipad), or under tv (rec.709/2.2), that move will watched more dark. more contrast.

If I'll be use rec.709/2.2 in resolve (proj settings), so all're ok.

I'd calibrate my monitor with rec.709 2.2 settings (i1disp pro with i1profiler).
The file, that was created from resolve is prores 422 and converted as with ffmpeg (libx264), so and with apple compressor. two variants. I believe, that apple compressor can view gamma tags of movie. any result is showing a more contrastly image under ios/tv. There is normal one only under computers (qtime).
But strange to say, many people like to watch video and under ios/tv.
The losers built Noah's ark. The professionals built the Titanic
Offline
User avatar

Uli Plank

  • Posts: 21279
  • Joined: Fri Feb 08, 2013 2:48 am
  • Location: Germany and Indonesia

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Feb 22, 2021 1:07 am

Since you can't avoid it, try to find out what is the preferred device of your audience and target that.
No, an iGPU is not enough, and you can't use HEVC 10 bit 4:2:2 in the free version.

Studio 18.6.5, MacOS 13.6.5
MacBook M1 Pro, 16 GPU cores, 32 GB RAM and iPhone 15 Pro
Speed Editor, UltraStudio Monitor 3G, iMac 2017, eGPU
Offline
User avatar

dariusii

  • Posts: 228
  • Joined: Tue May 15, 2018 1:38 pm
  • Location: Odintsovo
  • Real Name: Dmitry Nesterov

Re: Final Explanation of Gamma and Color Shift Problems

PostSat Aug 14, 2021 7:58 am

A little offtopic.
Does somebody know, purely on the occasion of life's quest) - can vlc support 3dlut tables for playing?
For example :) I want to play video as in Davinci Resolve, where I use 3dlut for video monitoring ( https://hub.displaycal.net/wiki/3d-lut- ... r-resolve/ )
Or (maybe) that moment other player can use.
The losers built Noah's ark. The professionals built the Titanic
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

PostSat Aug 14, 2021 9:12 am

AFAIK VLC does not support LUTs. The video playback app Screen, designed specifically for filmmakers does: https://videovillage.co/screen/
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
Offline

Wouter Bouwens

  • Posts: 244
  • Joined: Sun Dec 03, 2017 7:53 pm
  • Location: Alkmaar, Netherlands

Re: Final Explanation of Gamma and Color Shift Problems

PostSat Aug 14, 2021 2:49 pm

Jamie LeJeune wrote:AFAIK VLC does not support LUTs. The video playback app Screen, designed specifically for filmmakers does: https://videovillage.co/screen/


Is there a similar app for windows?
CPU: Intel Core I9 10850K
GPU: MSI Suprim X Geforce 3080
Motherboard: MSI Z590-A Pro
RAM: 32 GB Gskil Ripjaws 3600
SSD: Samsung EVO 970 M.2 NVME 1TB
OS: Windows 10 Home
Offline
User avatar

dariusii

  • Posts: 228
  • Joined: Tue May 15, 2018 1:38 pm
  • Location: Odintsovo
  • Real Name: Dmitry Nesterov

Re: Final Explanation of Gamma and Color Shift Problems

PostSun Aug 15, 2021 8:20 am

Wouter Bouwens wrote:
Is there a similar app for windows?


mpc + madvr. perhaps.
The losers built Noah's ark. The professionals built the Titanic
Offline

Hendrik Proosa

  • Posts: 3015
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Final Explanation of Gamma and Color Shift Problems

PostSun Aug 15, 2021 8:37 am

Scratch Pay Pro supports luts and cdl-s. RV player also afaik.
I do stuff.
Offline
User avatar

dariusii

  • Posts: 228
  • Joined: Tue May 15, 2018 1:38 pm
  • Location: Odintsovo
  • Real Name: Dmitry Nesterov

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Aug 19, 2021 6:23 am

Answer to myself. About video player + 3dlut.
IINA without icc functions. https://github.com/iina/iina
Be take VideoView.swift in iina build project and delete container of "setICCProfile(_ displayId: UInt32)" function.
Rebuild project.
So we have cleaned player with 3dlut table incapsulation support.
You don't have to pay anything.
The losers built Noah's ark. The professionals built the Titanic
Offline

Sunlit777

  • Posts: 25
  • Joined: Mon Aug 01, 2022 12:00 pm
  • Real Name: Shura Serov

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Dec 27, 2022 7:41 am

Dmytro Shijan wrote:VLC on macOS is not color managed.

It seems they fixed it somewhere in 2020 - as of now end 2022 when I change display profile in Mac OS VLC reacts and video color changes. I have not seen any settings for color management added inside the app itself
Offline
User avatar

Mark Foster

  • Posts: 2089
  • Joined: Tue Oct 27, 2015 10:59 am
  • Location: austria - no kangaroos +g*

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Dec 27, 2022 9:12 am

Sunlit777 wrote:
Dmytro Shijan wrote:VLC on macOS is not color managed.

It seems they fixed it somewhere in 2020 - as of now end 2022 when I change display profile in Mac OS VLC reacts and video color changes. I have not seen any settings for color management added inside the app itself


VLC version 3.0.18 on a mac:

Screenshot 2022-12-27 at 10.09.09.jpg
Screenshot 2022-12-27 at 10.09.09.jpg (91.49 KiB) Viewed 10044 times


Screenshot 2022-12-27 at 10.08.27.jpg
Screenshot 2022-12-27 at 10.08.27.jpg (94.93 KiB) Viewed 10044 times
cMP 5.1 2x3,46/96GB/2x2TB SSD/4x4TB/7101A 4x2TB 970evo+/HP1344/BMD4k/RadeonVII
macOS 12.6.3
BMPCC 6k pro (7.9.1)
meike s35 cine 25mm, 35mm, 50mm, 75mm
resolve studio 18.1.4
mini panel
speed editor
desktop video 12.1
intensity pro 4k
atem extreme (8.6.1)
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

PostTue Dec 27, 2022 5:23 pm

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

lucaimmesi

  • Posts: 37
  • Joined: Thu Jul 11, 2013 1:49 pm
  • Location: Rome

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Mar 15, 2023 2:08 pm

Hello, the only way I've found to match Quicktime with Vlc is to set the timeline to rec 709 gamma 2.4 and in the deliver tab to set color space tag to rec 709 and gamma tag to sRGB. Vlc, as usual, ignores the tag and reads the file correctly but quicktime for some reason interprets the gamma correctly at 2.4 (that doesn't happen if you set the gamma tag to 2.4 or rec709 or rec 709A).
The file from quicktime and vlc almost match, quicktime is just slightly less saturated but the gamma seems correct.
Director - filmmaker - Davinci Resolve 18 Certified Trainer
Offline

harrysundown

  • Posts: 3
  • Joined: Sat Nov 12, 2022 6:16 pm
  • Real Name: Brendan M Fay

Re: Final Explanation of Gamma and Color Shift Problems

PostSat May 20, 2023 6:20 pm

Thanks to everyone who contributed to this 563-post thread. It seems clear there is not a perfect solution, but there are at least settings that can allow you to get the Resolve preview and rendered file in Quicktime on Mac to match (even if it may look different on Windows). That's good enough for me for current needs.

But my question is what should you do if you have a feature-length movie that is already graded under Resolve default settings (Rec 709 Gamma 2.4, with "Mac display color profile" un-checked)? If I follow any of the suggested approaches here it would require re-grading 1000 shots to get back to the look I had. In the end, I applied a suggestion I found elsewhere:

Select P3-DCI color space tag and Rec 709 gamma tag in render settings. As I understand it, this is basically compensating for the fact that I did the grading on a P3 display on Mac without "Mac display color profile" checked. The results are pretty darn good compared to other things I've tried, but not perfect. It's a little brighter, less rich. Any suggestions are much appreciated it!
Offline

swordinhand

  • Posts: 44
  • Joined: Tue Nov 26, 2013 2:07 am
  • Real Name: Luke Sommer

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Oct 30, 2023 5:06 am

What I want to know is the end goal of the tags.

Before I get to the questions, let's set the baseline...

1. Footage is rec709 or converted / graded to rec709, via CST, LUTS, don't really care how you got there, etc.
2. The footage is being viewed on a calibrated to spec Rec.709 2.4 monitor, coming from a Decklink or similar output device (ie bypassing any Mac / Windows color management).
3. Grading room is setup in proper ITU 2035 dim surround environment.

So all of the above is to say, the footage looks absolutely the way you intend, on an absolutely accurate reference display and environment. Everybody in the room is seeing this image and deeming it correct. This is the absolute of this image. Let's call this the "REFERENCE" environment.

The file then gets rendered and output with tags. This is where the mess starts to occur. Which tags are correct, etc.

Let's keep this somewhat simplified and assume that the only destination (outside of the room described above) is an average bright living room in the day time. The computer is a MacBook Pro (because those are common enough) set to the standard Mac display color profile (display P3) with brightness set to a comfortable level and the rendered video is being viewed in Quicktime. Let's call this the "USER" Environment.

Now for my questions:

A. Is the goal of the NCLC tags to have the USER see an exact match to the REFERENCE?
OR
B. is the goal of the NCLC tags to have the USER see an exact match to the REFERENCE, but only if the USER recalibrates their monitor to rec709 2.4 standard?

AND

A. Is one of the above answers supposed to perceptually match in the USER environment to the REFERENCE?
OR
B. Is it an absolute match in the USER environment to the REFERENCE?
Offline
User avatar

Uli Plank

  • Posts: 21279
  • Joined: Fri Feb 08, 2013 2:48 am
  • Location: Germany and Indonesia

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Oct 30, 2023 5:12 am

As long as the tags are not respected by all the software out there, the settings recommended in the video are suggested to get the image as close as possible to what you see in the grading room.
They'll never match perfectly in that jungle out there.
No, an iGPU is not enough, and you can't use HEVC 10 bit 4:2:2 in the free version.

Studio 18.6.5, MacOS 13.6.5
MacBook M1 Pro, 16 GPU cores, 32 GB RAM and iPhone 15 Pro
Speed Editor, UltraStudio Monitor 3G, iMac 2017, eGPU
Offline

Hendrik Proosa

  • Posts: 3015
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Oct 30, 2023 9:09 am

A and A.

Mac colormanage what lands on screen so tags are needed to do the conversion from source to actual display.

Desired match in different environment is always perceptual, absolute match does not match visually so is useless for viewers.

Exact in both cases is a pretty loose word, there is nothing exact in any of this. Dim surround vs bright surround can not be matched exactly, only as close as possible.
I do stuff.
Offline

swordinhand

  • Posts: 44
  • Joined: Tue Nov 26, 2013 2:07 am
  • Real Name: Luke Sommer

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Oct 30, 2023 1:25 pm

Thank you both for your answers.

Another question: doesn't a file mastered for Rec709 standard, always contain a Rec709 transfer function? In other words, the Rec709 standard assumes a Rec709 transfer function, to be viewed through a monitor with a 2.4 gamma. Meaning the monitor will apply another EOTF to the input OETF, resulting in the final image? If the above is true, the confusion must lie in the incorrect idea of the "Output Colorspace". Resolve's (18.6.2) own color managed workflow for SDR, spits out Rec709(scene) files, tagged as 1-1-1. Yet, we keep being told that Rec709 should be using a Rec709 2.4 gamma output colorspace. This seems to be where the confusion lies. The output colorspace is not the display (I'm strictly talking about Rec709, not HDR, P3, etc.) colorspace, but the file's output colorspace. Which then in turn would get viewed on a rec709 2.4 gamma display. It's a two part system. I also see that my files when tagged in 1-1-1 match exactly in QuickTime on a 2.4 calibrated monitor, the same file viewed in DR through Decklink on the same monitor. Meaning QuickTime is correctly applying rec709 tags to be viewed on rec709 2.4 monitor. 1-2-1 tags with 2.4 gamma NEVER look correct in QuickTime, in ANY icc color managed scenario to my reference.

I also get the idea that the tagging naming convention could be leading to some confusion, when you think that "output colorspace" (strictly referring to transfer function tags) should be the same in the tags. But actually it makes total sense, when you realize that a rec709 mastered file is always a rec709 transfer function and is never a 2.4 transfer function. That never was how rec709 was intended. It also is just common sense that the very first tag 1-1-1 is the most common standard we have right now. And to make it even clearer, the "2" tag is literally "Undefined", which just makes things even more confusing. So just using common sense tells us 1-1-1 is also correct for rec709 mastered footage.

Would love for someone to show me, in the real world, where tagging 1-2-1 actually looks like what I'm seeing on my calibrated 2.4 monitor, cause I've NEVER seen it.
Offline

Hendrik Proosa

  • Posts: 3015
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Oct 30, 2023 3:07 pm

swordinhand wrote:Another question: doesn't a file mastered for Rec709 standard, always contain a Rec709 transfer function? In other words, the Rec709 standard assumes a Rec709 transfer function, to be viewed through a monitor with a 2.4 gamma. Meaning the monitor will apply another EOTF to the input OETF, resulting in the final image? If the above is true, the confusion must lie in the incorrect idea of the "Output Colorspace". Resolve's (18.6.2) own color managed workflow for SDR, spits out Rec709(scene) files, tagged as 1-1-1. Yet, we keep being told that Rec709 should be using a Rec709 2.4 gamma output colorspace. This seems to be where the confusion lies. The output colorspace is not the display (I'm strictly talking about Rec709, not HDR, P3, etc.) colorspace, but the file's output colorspace. Which then in turn would get viewed on a rec709 2.4 gamma display.

Exactly. Data in a file mastered on rec709 reference display is not encoded WITH gamma 2.4, nor gamma 1/2.4, whatever the tags say. They are implicitly aquiring rec709 encoding function (OETF with linear toe and gamma of 0.45), either by color management system, or user itself (through the mechanism of "it looks right") and thus they are encoded FOR gamma 2.4 calibrated display.
I do stuff.
Offline

swordinhand

  • Posts: 44
  • Joined: Tue Nov 26, 2013 2:07 am
  • Real Name: Luke Sommer

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Oct 30, 2023 5:29 pm

Hendrik Proosa wrote:Exactly. Data in a file mastered on rec709 reference display is not encoded WITH gamma 2.4, nor gamma 1/2.4, whatever the tags say. They are implicitly aquiring rec709 encoding function (OETF with linear toe and gamma of 0.45), either by color management system, or user itself (through the mechanism of "it looks right") and thus they are encoded FOR gamma 2.4 calibrated display.


So that would be why a rec709 mastered and tagged 1-1-1 file viewed in a different way (ie apple display p3 or sRGB space) we are seeing color and gamma mismatches in Quicktime. If the user would simply calibrate their monitor to Rec709 2.4 the "problem" would be solved. Essentially there is no problem, it's really just user error in failing to understand how Rec709 and Rec1886 work as a system and what the tags mean. And also not understanding ICC for that matter, either. Because ICC works in a similar way with input ICC (source file) and display ICC (ie monitor). But it seems that people think that the source file ICC should spit out the correction for the monitor ICC. But the problem with this is, we have to be mastering for a known user and the reality is no two users will be in the same setting or screen etc. and you wouldn't actually have a correct rec709 file. So users who actually had their monitor calibrated correctly would be seeing it wrong. Which defeats the whole purpose of a standard. Rec709 is the known user, so you have to master for that. If you want to make a special file for someone you knew would only be viewing in a known space, you could do a CST for that space. But otherwise, tell people to calibrate their screens. The rest are just gonna see what they're going to see.

However, I think there is one solution that ICC color managed apps could implement. If a file was tagged 1-1-1 and you had a display calibrated to a known space. Then Apple could have the color managed app, recalibrate to rec709 2.4 and, in theory it would look the same, within the app, to a rec709 2.4 calibrated monitor. That way the monitor is always "Calibrated". But it would require the monitor to be calibrated to some known space that the app would intelligently change to the correct space upon reading the tags. But that still doesn't mean the 1-1-1 tagging is incorrect. Of course, once the monitor fell out of spec (ie user doesn't recalibrate), this wouldn't work anymore, because it would cause all the other calibrations to fall out of spec. The reality is the user has to be in charge of the display ICC or Calibration LUT etc. or they can't rely on some automated system. Maybe in some future perfect world, the screen could auto calibrate (I guess my Flanders has sort of a feature like that), and that might allow all of this to be automated and completely transparent to the user.

Thanks again for your help
Offline

Hendrik Proosa

  • Posts: 3015
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Oct 30, 2023 7:07 pm

swordinhand wrote:So that would be why a rec709 mastered and tagged 1-1-1 file viewed in a different way (ie apple display p3 or sRGB space) we are seeing color and gamma mismatches in Quicktime. If the user would simply calibrate their monitor to Rec709 2.4 the "problem" would be solved.

It’s not that simple as gamma shifts manifest themselves on the same display too, between lets say Resolve and some player X. Problem is in the interpretation of metadata in different softwares and what exactly they do with that interpretation.
I do stuff.
Offline

swordinhand

  • Posts: 44
  • Joined: Tue Nov 26, 2013 2:07 am
  • Real Name: Luke Sommer

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Oct 30, 2023 7:39 pm

I could see how certain tags are incorrectly interpreted. But I'm not seeing it with Quicktime on my setup.

For instance, if I view footage in Resolve through Ultrastudio 4k into LG C9 TV calibrated to Rec709 2.4 it looks identical to footage output to QuickTime with 1-1-1 tags viewed through Mac Studio's HDMI output (using "LG TV" color profile) into the same LG C9 calibrated to Rec709 2.4.

Also, the viewer window in Resolve (with "use Mac Display Color Profiles for Viewers" turned off), looks identical to the file viewed in Quicktime with 1-1-1 tags. This means the file is not changing on output and then when viewed in correct Rec709 2.4 environment looks the same as reference. How does this not prove my point?

Obviously, if someone is experience shifts, either something is not set up right or the software is written incorrectly. But I believe that I'm using the system correctly.
Offline

mpetech

  • Posts: 728
  • Joined: Wed Sep 04, 2013 9:52 pm
  • Real Name: Dom Silverio

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Oct 30, 2023 7:52 pm

swordinhand wrote:I could see how certain tags are incorrectly interpreted. But I'm not seeing it with Quicktime on my setup.

For instance, if I view footage in Resolve through Ultrastudio 4k into LG C9 TV calibrated to Rec709 2.4 it looks identical to footage output to QuickTime with 1-1-1 tags viewed through Mac Studio's HDMI output (using "LG TV" color profile) into the same LG C9 calibrated to Rec709 2.4.

Also, the viewer window in Resolve (with "use Mac Display Color Profiles for Viewers" turned off), looks identical to the file viewed in Quicktime with 1-1-1 tags. This means the file is not changing on output and then when viewed in correct Rec709 2.4 environment looks the same as reference. How does this not prove my point?

Obviously, if someone is experience shifts, either something is not set up right or the software is written incorrectly. But I believe that I'm using the system correctly.



So you are saying that all software behaves the same as QT and Resolve for all the possible metadata?
Offline

swordinhand

  • Posts: 44
  • Joined: Tue Nov 26, 2013 2:07 am
  • Real Name: Luke Sommer

Re: Final Explanation of Gamma and Color Shift Problems

PostMon Oct 30, 2023 8:30 pm

No, I stated that if "software is written incorrectly" it could cause a problem. But Quicktime Version 10.5 (1126.4.1) on Mac OS 12.6.1 (21G217) and Davinci Resolve 18.6.2 are reading 1-1-1 tags correctly. Certainly, YMMV with software that goes rogue. Also, I'm only talking about Rec709, not P3 or Rec2020, etc. But most of the issues seem to be user error and not fully understanding what Rec709 is and isn't. Also what tags are and aren't. You have to get out of the thinking that the "Output color space" in Resolve is defining the viewing EOTF / monitor gamma. It's not. The output color space is defining the source file output color space (which is Rec709 [Scene]), which has a different transfer function than the monitor.

Read these documents over and over until they really sink in, it certainly took me a while:

Rec709
https://www.itu.int/dms_pubrec/itu-r/re ... !PDF-E.pdf
Rec 1886
https://www.itu.int/dms_pubrec/itu-r/re ... !PDF-E.pdf
Rec 2035
https://www.itu.int/dms_pubrec/itu-r/re ... !PDF-E.pdf
Also the wiki for Rec709 is a good overview
https://en.wikipedia.org/wiki/Rec._709

For reference my system is:

Mac Studio (2022)
M1 Ultra
64GB

BMD Ultrastudio 4k Mini
Ultra-studio SDI output to -> Flanders Scientific DM240 in Rec709 2.4 gamma, 6500K, 100 Nits, SDI Black Level Video
Ultrastudio HDMI output to -> LG C9 calibrated to Rec709 2.4 gamma, 6500K, 100 nits, Video level, with MediaLight MK2 bias light at
10 lux. Walls are neutral gray. C9 and Flanders are within 2035 distance spec as well. I've also gone to another professional DI and they were using Sony Trimaster OLED and LG OLED (both professionally calibrated with CR-100 and CR-250) and my footage looked the same on their setup. I'm confident that my room is setup correctly for Rec709 spec.

Hope this helps.
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Oct 31, 2023 9:30 pm

swordinhand wrote:
However, I think there is one solution that ICC color managed apps could implement. If a file was tagged 1-1-1 and you had a display calibrated to a known space. Then Apple could have the color managed app, recalibrate to rec709 2.4 and, in theory it would look the same, within the app, to a rec709 2.4 calibrated monitor. That way the monitor is always "Calibrated". But it would require the monitor to be calibrated to some known space that the app would intelligently change to the correct space upon reading the tags...


This is exactly what reference mode does on iPad Pro.
Which is also what colourist does manually switching its reference monitor to one of the calibrated presets :)
Offline

swordinhand

  • Posts: 44
  • Joined: Tue Nov 26, 2013 2:07 am
  • Real Name: Luke Sommer

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Oct 31, 2023 10:19 pm

It makes sense, except the iPad can’t be recalibrated or can it? Because I would think it wouldn’t work then. The Flanders has AutoCal which recalibrates all known spaces and gammas. But yes, you do have to manually change it.

The real solution is one standard for display. But that’s never gonna happen. I did notice reading up on all the NCLC tags, that many of them are antiquated or obscure. It seems rec709, p3 (dci and d65) and rec2020 with PQ and HLG are the three main standards. Apple’s own Finder even describes these spaces next to the tags.

After further testing, with my above method and tagging 1-1-1, viewed through a calibrated rec709 2.4 monitor, I’m seeing identical images in Resolve Viewer (mac color profile turned off in Resolve preferences), QuickTime, Safari (Vimeo), Firefox (Vimeo), VLC. These aren’t “close” matches, they are identical. Not sure why everyone is saying to tag 1-2-1, when that method never looks right for me in icc color managed apps.
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Oct 31, 2023 10:30 pm

Why it would not work then ?
You have a calibrated preset which monitor switches to it when seeing correct tag.

1 thing is to have proper identification of the video (tag) and then 2nd to have calibrated preset for it. Manual or auto switch is just mechanics. If you have both elements then all will work fine.
You can add 3rd scenario that when you have custom source then you convert it to native monitor gamut or to the widest known standard supported by your monitor.
Offline

swordinhand

  • Posts: 44
  • Joined: Tue Nov 26, 2013 2:07 am
  • Real Name: Luke Sommer

Re: Final Explanation of Gamma and Color Shift Problems

PostTue Oct 31, 2023 11:53 pm

If calibration is off or drifts from factory calibration on iPad then all presets would be off. That’s what I mean. Of course, you can switch between them, but they would all be off. But if you can recalibrate iPad they would all be correct again. Just not sure if you can recalibrate the iPad?

In my testing, correct tag is 1-1-1, when I’m using rec709 2.4 calibrated monitor. 1-2-1 tag applies a 2.4 gamma to footage that really wants to see a rec709 transfer function. The transfer function tagging defines the input OETF, not the output EOTF.

According to this document describing the Apple ProRes Bitstream Syntax and Decoding Process:
https://ieeexplore.ieee.org/stamp/stamp ... er=7438722

It describes the implementation of the different NCLC tags and specifies that the transfer function tag is "A code indicating the opto-electronic transfer characteristic of the source video data."

This would specify the rec709 OETF would it not? Not 1886 / 2.4 gamma EOTF. In the real world, when I'm using 1-1-1 tagging, it supports this idea as well, because the images appear identical on all software named in previous post and they all look identical on reference rec709 2.4 monitor. The reason 1-2-1 tags might keep being perpetuated is the idea the EOTF is being associated with the rec709 input OETF. The EOTF would be applied by selecting a rec709 2.4 display ICC (automatically as in the iPad switching mechanism) or by manually calibrating to rec709 2.4. This allows the rec709 file to be correctly interpreted. But if the monitor is calibrated to say Display P3 (which is a wider gamut and an sRGB transfer function), of course, the image is going to look washed out (gamma shift of around .2 and wider color space).

It's my understanding that a color managed app like Quicktime is identifying the NCLC tags and applying the correct input (ie rec709). It's not then converting the display to the correct output (ie rec709 2.4 [1886]). That would be up to the user or some special method like the iPad autoswitch feature you mentioned. ICCs work on input and output. If not, you would need some absolute display standard, which is not possible in the real world. The user has to determine the display calibration. But what people keep wanting, I think, is the 1-2-1 tag to give them a perceptual match, on a Display P3 monitor to the Rec709 2.4 gamma reference monitor. If that's the case, then I guess you can sort of chimp it with the 1-2-1 tag, but even then it's not really correct (and will require some CST conversion before output), but it also only assumes one type of end viewer (Display P3). What if the viewer is watching on something else like gamma 1.8 or sRGB? You're going to have problems again. Worse, if someone was actually watching on a rec709 2.4 monitor, say an LG OLED (which are fairly common), it's going to look wrong again. The real solution is for there to be a unified display standard. Then none of this would happen.

Also, doesn't anybody think that places like Vimeo and YouTube are retagging 1-2-1 files to 1-1-1 because it might be a feature, not an error? Because they want it to display correctly for people watching on rec709 2.4 monitors? Also the 1-1-1 tag (which is identified in Finder as "HD" next to the tag) is literally the first in the list, this makes sense, given the ubiquity of Rec709 as a format and standard. Why would tag "2" labeled "Unspecified" be correct? It just lacks all common sense.

I know there are wildly differing opinions on this topic, but I still have yet to see in real world where the 1-2-1 tagging looks identical to the reference in a color managed app (ie QuickTime) viewed on a monitor calibrated to Rec709 2.4. It always looks way too dark.
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

PostWed Nov 01, 2023 8:19 am

Grading on BT.1886 calibrated display and applying 1-1-1 tags to the output does not result in a matching result in QuickTime Player.
www.cinedocs.com
http://www.imdb.com/name/nm4601572/
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 01, 2023 9:05 am

Isn't it interesting that after 4 years and 579 messages, there still isn't a solution to this complex problem?
marc wielage, csi • VP/color & workflow • chroma | hollywood
Offline

Hendrik Proosa

  • Posts: 3015
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Nov 01, 2023 10:28 am

Marc Wielage wrote:Isn't it interesting that after 4 years and 579 messages, there still isn't a solution to this complex problem?

It's because users can't change software behavior, however many posts they generate. At best users can make workarounds around workarounds that casually break every sunday morning. In the end the software vendors have to agree on something and make the changes.
I do stuff.
Offline
User avatar

Olivier MATHIEU

  • Posts: 865
  • Joined: Thu Aug 04, 2016 1:55 pm
  • Location: Paris/Grenoble, FRANCE

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Nov 01, 2023 10:51 am

Mark Foster wrote:VLC version 3.0.18 on a mac:

Screenshot 2022-12-27 at 10.09.09.jpg


Screenshot 2022-12-27 at 10.08.27.jpg



I gave a Try : 2 files identical except the NCLC Tags

With VLC 3.0.18
Without the new settings ➧ 2 files are identical in the VLC viewer
With the new settings ➧ 2 files are identical in the VLC viewer.
None the less the new settings have an impact on the chromaticy and gamma

So
NCLC are still ignored by VLC
The new settings do a colorspace conversion but from what colorSpace ??
Any idea ?
Thanks
Resolve Studio 18.6.x & Fusion Studio 18.6.x | MacOS 13.6.x | GUI : 3840 x 2160 | Ntw : 10Gb/s
MacbookPro M2 Max
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Nov 01, 2023 5:51 pm

swordinhand wrote:In my testing, correct tag is 1-1-1, when I’m using rec709 2.4 calibrated monitor. 1-2-1 tag applies a 2.4 gamma to footage that really wants to see a rec709 transfer function. The transfer function tagging defines the input OETF, not the output EOTF.


1-1-1 tagged file for Apple color system is a file with gamma of about 1.96. This is derived from an original Rec.709 spec. At the time when it was defined it was correct (well it's still correct, but no one grades to 1.96 gamma). So what you do is typically create 2.4 gamma based file which you tag (1-1-1) as 1.96 and by doing so you create mismatch between actual nature of the content and its tag. If later software treats 1-1-1 as about 1.96 gamma (like Apple color sync) then you have a problem (hence 1-2-1 tag which allows you to specify 2.4 (or other) pure curve gamma, but this is QuickTime only tag, so not good). All what is needed is widely recognised BT.1886 tag, which was never introduced by industry (while it should together with BT.1886 spec publication).
If you look at HDR then it's all fine as correct tag been standardised and at least we can flag if file is HLG, PQ etc. Before wa start talking about accuracy and calibrated monitors we need a mechanism to properly describe (at least most common) standards in files.

What could work is sRGB grade and tag (once you agree it's fine to grade to sRGB) as this is a standard tag widely recognised, but YT, Vimeo etc. blindly re-tag every transcoded file (they don't do any conversion, just re-tag) as 1-1-1 so things fall apart again. I spoken with Vimeo about bypassing sRGB graded files as is, but after 3 months it went nowhere.

Current standard tags are as fallow:
https://github.com/bbc/qtff-parameter-editor

Atm. it's all mess and I see not much hope for a change as it's nothing which can bring money, so no one is interested :)
You can always set VLC etc. to apply hard rule that any (eg. non HDR file) should be treated as BT.1886 (or something else), but this is also not a universal/proper way.
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Nov 01, 2023 6:02 pm

Marc Wielage wrote:Isn't it interesting that after 4 years and 579 messages, there still isn't a solution to this complex problem?


Solution is very simple just those who could fix it are not interested as there is no money in it.
Offline

Hendrik Proosa

  • Posts: 3015
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Nov 01, 2023 7:03 pm

Andrew Kolakowski wrote:1-1-1 tagged file for Apple color system is a file with gamma of about 1.96. This is derived from an original Rec.709 spec. At the time when it was defined it was correct (well it's still correct, but no one grades to 1.96 gamma). So what you do is typically create 2.4 gamma based file...

What exactly is a gamma 2.4 based file?
I do stuff.
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Nov 01, 2023 8:37 pm

95% today's SDR grades are 2.4 (exponent of the power function) based and not a single one is 1.96 based as it's not today's grading standard.
Offline

mpetech

  • Posts: 728
  • Joined: Wed Sep 04, 2013 9:52 pm
  • Real Name: Dom Silverio

Re: Final Explanation of Gamma and Color Shift Problems

PostWed Nov 01, 2023 10:43 pm

Andrew Kolakowski wrote:95% today's SDR grades are 2.4 (exponent of the power function) based and not a single one is 1.96 based as it's not today's grading standard.


You will be amazed how many are done in 2.2.
Offline

swordinhand

  • Posts: 44
  • Joined: Tue Nov 26, 2013 2:07 am
  • Real Name: Luke Sommer

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Nov 02, 2023 12:04 am

Andrew Kolakowski wrote:Atm. it's all mess and I see not much hope for a change as it's nothing which can bring money, so no one is interested :)


I agree with you, it is definitely a mess. The main thing I realize is for broadcast work or streaming delivery, the tags don't matter (no streamer asks for any specific NCLC tags in specs, for instance). Just grade through Ultrastudio into 3D LUT based rec709 2.4 gamma monitor (like my Flanders DM240) and that's it!

But with ICC / ColorSync systems like NCLC tags and color managed apps like Quicktime, there seem to be some really odd behaviors. Firstly, my understanding of the system, which I tested with multiple tags, using matching RCM workflow, is that the end result shows the same (except for any out of gamut color or out of luminance values, in the case of HDR ) in the color managed app. So, for example, if I use RCM and select rec 709 2.4 and render, it will look the same as a file set to rec2020 2.4, in Quicktime (except any out of gamut colors, which will be dealt with according to how you have Resolve set up). But the understanding I have, is that Quicktime sees the tag and changes the viewing conditions to match. If you output from a RCM workflow, it will look identical (again except for out of gamut / out of luminance in HDR). This behavior seems great, as it smartly transforms your monitor for you. Where as, if I bring the same files into Resolve and turn off color management, the rec709 one will look different than the rec2020, which is the true nature of the file, and would require manually calibrating the monitor to each standard.

However, with this ICC / colorsync based system, there doesn't seem to be a known monitor space / gamma, starting point / monitor profile? So you have no way of knowing if the final image is absolutely accurate, to a known calibrated source. See the problem with this? So when I tag my image with rec709 2.4 (1-2-1) it may have the "correct" tag, but the resulting image looks relatively dark compared to my Ultrastudio output into my 3D LUT calibrated Flanders DM240 set to Rec709 2.4. So this can't be the correct viewing environment. (Let's also set aside the concept that the NCLC is defining the EOTF and not the OETF, which doesn't seem to be the case, at least for rec709, according to the ProRes document I linked in a previous post).

For example, I ran the HDMI output of my Mac Studio into the DVI input of my recently 3D LUT calibrated DM240 (set to Rec709 2.4, D65, 100 Nits, Video level throughout system). The Mac Studio is set to DM240 color profile in System Preferences. I also ran the SDI output of my Ultrastudio Mini 4k into the SDI input of the same DM240. I turned off "Use Mac display color profiles..." in DR Preferences. I used the split screen function on the monitor to display both inputs simultaneously. Aside from a very minor Hue offset (with the DVI input), which I easily corrected on the monitor, the images looked IDENTICAL. If this same clip is then rendered out to QuickTime with 1-1-1 tags, the images looked IDENTICAL to the SDI source and the DVI viewer source in DR. This means that all color management seems to be negated and you're left with the same signal that is being fed out of the Ultrastudio (which is not affected by apple color management).

If I turn on "Use Mac display color profiles..." in DR Preferences and set output color space to Rec709 [Scene] or Rec709 2.4 gamma, the image exhibits a darkening effect in the Viewer window. The SDI input and DVI input do not match now. Again the DVI input being darker. However, when rendering out the image, which applies 1-1-1 tags with Rec709 [Scene], the image matches SDI in Quicktime through DVI. But when rendering out Rec709 2.4 gamma which sets 1-2-1 tags, the image matches the Viewer window, but is darker than the SDI input. So, yes, the "Use Mac display color profiles..." definitely will match (actually the near blacks are very very slightly lifted in QuickTime, so not sure what that is), when viewing the same rendered file in Quicktime. But in relation to a known standard, I'm not sure what the monitor should be calibrated to, to exhibit a match with the known reference. Just doing some non scientific chimping, It appears that around 2.0 gamma gives it a similar appearance. But the colors still look a bit off.

To me, this NCLC stuff is overly complicated and not accurate at all. Maybe it's accurate to itself, but that doesn't matter in the real world and will have massive user error / failure, which is what we keep seeing over and over, in these forums. So that's why I tag with 1-1-1 and then let the user set up their system to reflect the known input. This allows people with correct calibration to see the correct image. I don't want people to be dealing with this automated and absurd color management system, that I've never seen work correctly, in the real world. But it, unfortunately, is the way it is.

The solution would be to have every monitor be calibrated with a 3D LUT based system. The tags would then simply be read by the software to say this file is to be viewed on a "Rec709 2.4 spec monitor" or a "DCI-P3 2.6 spec monitor". The software would then merely switch the monitor LUT automatically to the correct setting and voila the user would see exactly what the mastering house / DI saw. This would be absolutely amazing. The user would just need to recalibrate the system every so often and it would stay in spec. Sadly, it's what we hope the ColorSync system is doing, but it's really poorly implemented and not clearly defined. I've been researching this for weeks now, am technically savvy, I do this for a living professionally and I still am having trouble wrapping my mind around the concepts and why things aren't working. ICC basically sucks and was never designed for broadcast / video standards, but print. Even the white point is based around D50 and needs to be changed for video based profiles. So, again I agree with you, this is a mess. But thankfully, the broadcast system setup is the solution for now and it does work.

Also, does anyone actually know what "NCLC" stands for? I can't find it anywhere online.
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

PostThu Nov 02, 2023 1:09 am

Andrew Kolakowski wrote:Solution is very simple just those who could fix it are not interested as there is no money in it.

No, it's more complicated than that. It would require:

1) all consumer TV set and computer display manufacturers to agree on a method of calibration before the units leave the factory

2) and all the companies making operating systems would have to submit to playing back video under known standards.

That's not simple. I agree it could cost a lot of money.

Andrew Kolakowski wrote:95% today's SDR grades are 2.4 (exponent of the power function) based and not a single one is 1.96 based as it's not today's grading standard.

Yeah, we actually add color space info and gamma space info in the file name, and we also slate the deliverable files (when possible) so the slate actually says "Rec709/Gamma 2.4/SDR." I guess with HDR we'd have to add "P3-D65/ST2084/1000 nits/HDR" on the slate and/or in the filename.
marc wielage, csi • VP/color & workflow • chroma | hollywood
Offline

madchiller

  • Posts: 47
  • Joined: Fri Jul 01, 2022 10:58 pm
  • Real Name: CHAD E MILLER

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Nov 02, 2023 2:56 am

swordinhand wrote:
Andrew Kolakowski wrote:Atm. it's all mess and I see not much hope for a change as it's nothing which can bring money, so no one is interested :)


Also, does anyone actually know what "NCLC" stands for? I can't find it anywhere online.


NCLC stands for Non-Consistent Luminance Coding.

The only fix is for Apple to fix it. Either by adhering to a proper standard or adding a Gamma 2.4 tag...
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Nov 02, 2023 7:20 am

Apple itself can’t fix it properly. They could hack it partially for OSX but that’s not a proper solution.
There is no direct/money gain in all of this so no one cares.
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Nov 02, 2023 7:32 am

swordinhand wrote:…But in relation to a known standard, I'm not sure what the monitor should be calibrated to, to exhibit a match with the known reference. Just doing some non scientific chimping, It appears that around 2.0 gamma gives it a similar appearance. But the colors still look a bit off.


The solution would be to have every monitor be calibrated with a 3D LUT based system. The tags would then simply be read by the software to say this file is to be viewed on a "Rec709 2.4 spec monitor" or a "DCI-P3 2.6 spec monitor". The software would then merely switch the monitor LUT automatically to the correct setting and voila the user would see exactly what the mastering house / DI saw. This would be absolutely amazing. The user would just need to recalibrate the system every so often and it would stay in and it does work.


It’s 1.96 on OSX. This is approximately an inverse value of an original Rec.709 gamma for recording devices. You can find explanation on wiki.
Take any tagged 1-1-1 file, create a copy of it and with Mogurenko tool re-tag to 1-2-1 plus 1.96 gamma. Both files will perfectly match on color managed OSX preview (eg. QTX).

Such a system is there in form of reference modes on new Macs, but you can’t fully calibrate screen, just adjust white point. For home users this should be good enough. This allows monitor with P3 gamut to cover all needs up to P3 gamut, by limiting it like reference monitors do.
For pro world you want full calibration.
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Nov 02, 2023 7:40 am

Marc Wielage wrote:
Andrew Kolakowski wrote:Solution is very simple just those who could fix it are not interested as there is no money in it.

No, it's more complicated than that. It would require:

1) all consumer TV set and computer display manufacturers to agree on a method of calibration before the units leave the factory

2) and all the companies making operating systems would have to submit to playing back video under known standards.

That's not simple. I agree it could cost a lot of money.



This is rather next step to make monitors/TVs better. This is up to manufacturers, but thankfully there are now units which are close to standards (+ have calibration abilities). For masses decent factory calibration is about best you can do.
Offline

Hendrik Proosa

  • Posts: 3015
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Nov 02, 2023 8:53 am

Andrew Kolakowski wrote:95% today's SDR grades are 2.4 (exponent of the power function) based and not a single one is 1.96 based as it's not today's grading standard.

What does ”based” mean here? That data is encoded using power function of gamma 2.4? out = pow(in, 2.4) or out = pow(in, 1/2.4)? Or something else? This is important as big part of the mess is based on this. NCLC tags are meant to state the encoding function of the data, at least this was the original intent. This in turn means that display is irrelevant, as display does not directly relate to the encoding function of the data in a file. There are multiple NCLC transfer function tags that don’t have companying display EOTF at all (linear, log).

My two cents on how to get the mess straightened. Move back to acknowledging that NCLC tags are meant for tagging the content of the file itself, not some intended view environment and display the file was supposedly generated for. Let system and/or player software handle the conversion for actual view environment, which is UNKNOWN at the time of file encoding anyway (assumption =/= knowledge). Whether someones display is actually calibrated to stated standard is irrelevant here, as this can't be known or queried implicitly by the system anyway, it needs explicit probing with external device.
I do stuff.
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Nov 02, 2023 10:30 am

Yes and this seems to what Apple system is trying to do, but 1-1-1 tag lies in current shape about real nature of the file, so any preview generated using it will be simply wrong regardless of the intended display (and display's accuracy to a given standard). No?

Whole idea is plain simple- you tag file with its real encoding and based on that you generate preview adhering to given display capabilities. Without this starting/key information whole thing falls apart at the very start and can be fixed only when you can manually overwrite/correct tag (which is eg. not the case when using file over YT, Vimeo etc. and using browser to see it). Simple fact that there are many files tagged 1-1-1, but they have very different real encoding curve used when producing them, shows how messy it currently is.
Last edited by Andrew Kolakowski on Thu Nov 02, 2023 10:42 am, edited 2 times in total.
Offline
User avatar

Bastien

  • Posts: 91
  • Joined: Sat Apr 14, 2018 10:28 am
  • Location: France
  • Real Name: Bastien CHILLOUX

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Nov 02, 2023 10:37 am

But Gamma 2.4 doesn’t have a proper tag so it’s impossible at the current time, right?
Blackmagic URSA Mini Pro 4.6K G2 • DZOFilm Pictor Zooms • Easyrig Vario 5 Stabil G2
Website : https://bastienchilloux.com
Instagram : https://www.instagram.com/bastienchill.dp/
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Nov 02, 2023 10:39 am

Exactly- whole problem is that simple :)
We don't have such an issue with newly created HDR standard as proper tags were introduced together with a standard.
BT.1886 is bit hidden standard which still confuses many as it wasn't properly introduced, explained and "promoted" at its introduction, yet it's widely used.
Last edited by Andrew Kolakowski on Thu Nov 02, 2023 10:48 am, edited 1 time in total.
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Nov 02, 2023 10:46 am

Hendrik Proosa wrote: Let system and/or player software handle the conversion for actual view environment, which is UNKNOWN at the time of file encoding anyway (assumption =/= knowledge). Whether someones display is actually calibrated to stated standard is irrelevant here, as this can't be known or queried implicitly by the system anyway, it needs explicit probing with external device.


I would not say it's totally unknown. There are standards which narrow/define how content should be produced and watched (this is somehow linked with each other to make it more of a closed system), so it may not be precisely known, but it's predictable to some degree. This is why all studios grade just few possible variations, otherwise not only display side would be 'wild', but also creation side.

Ask Marc if they ever graded file to standard A, but put into file description as it's standard B :D
Why would you ever do it for headers then?
Offline

swordinhand

  • Posts: 44
  • Joined: Tue Nov 26, 2013 2:07 am
  • Real Name: Luke Sommer

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Nov 02, 2023 11:37 am

Andrew Kolakowski wrote:Yes and this seems to what Apple system is trying to do, but 1-1-1 tag lies in current shape about real nature of the file, so any preview generated using it will be simply wrong regardless of the intended display (and display's accuracy to a given standard). No?


No. The real nature of the file is Rec709 (1.96), because NCLC is describing the input OETF, not the output EOTF. The preview is completely accurate, when viewed on a correctly calibrated rec709 monitor, using QuickTime, Safari, VLC, Vimeo, etc. I’ve stated that over and over in previous posts.

The tagging system of the future should describe how or what the file is to be viewed through, not what it is. That tag would tell the monitor, this rec709 mastered file, should be “viewed through” a rec 709 2.4 gamma monitor. Then the monitor would switch to a 3D LUT calibration for rec709 2.4 gamma. This would fix a lot of problems and mismatches. But if you want the best experience, calibrate your monitor and watch Netflix or a blu-ray.
Offline

Andrew Kolakowski

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

Re: Final Explanation of Gamma and Color Shift Problems

PostThu Nov 02, 2023 12:11 pm

How can real nature be 1.96 if you graded file to 2.4 and just tagged 1-1-1? Real nature is based on Resolve setting, not what export tags says as you can make it say anything :)

External display is another story, not sure how color sync works then. It may be just passing data as is, so if your monitor is set to correct gamma you get correct preview (like it happens with reference screens).
PreviousNext

Return to DaVinci Resolve

Who is online

Users browsing this forum: Baidu [Spider], FranzDev78, panos_mts, RCModelReviews and 235 guests