I’m trying to use the new ACES2 IDT/ODTs “ACES2 candidate CAMDRT rev060” from github. And it works very well if I only use the rec709 ODT from for example LogC footage. But if I want to grade rec709 video and use the inverse rec709 for IDT and then the rec709 ODT, it doesn’t work. If I only use the IDT/ODT, the output should look the same, right? At least that is the case when I use the ACES1 IDT/ODT.
I use DaVinci Resolve Studio 19.1.1 on a MacStudio.
thank you very much for your replay! So I don’t know there was a “pure DCTL” with auf a LUT in the DCTL, very nice!
So I try it like you with the ACES Transform, that works. But If I try it with ACES Color Management, then it doesn’t work on my side. I looks like the IDT don’t do anything, only the ODT. Any Ideas?
Because I am very interested: What ist the CAMDRT dctl for? and what is the difference to the pure DCTL?
I adjust the CAMDRT v60 rec709 on my side, because I need a 1.96 Gamma and sRGB ODT too, I only combine a v60 rec709 ACES Transform and a Gamma24 to Rec.709-A and sRGB CST and export the LUT and copy the LUT data in a new v60 rec709 (LUT)DCTL. I know not the clean way, but i don’t have any chance to output Gamma 1.96 and sRGB in ACES. So ist there also a similar way with the pure DCTL?
Thank you for your thoughts in this topic!
Best
Rafael
But then it also works for me with the CAMDRTv60. What platform and Resolve version are you on? I am using Resolve 19.1 on an M1 Mac Studio.
The LUT based CAMDRTv60, hosted on the AMPAS repo, is the official candidate, baked by @alexfry from the Nuke BlinkScript implementation used for development. The pure DCTL version was written by me for testing, and because it does not use a 3D LUT, it should be closer to the “ground truth” of the CTL reference.
Making a copy of the pure DCTL version and changing it to use a different EOTF would be very simple. This line applies the BT.1886 2.4 gamma, so you would just need to change it to something else.
You should also change Rec709_100nits_dim in line 2 to sRGB_100nits_dim.
For the Rec.709 OETF (~1.96 gamma) the form would be the same, just with different constants as seen here. Although I have to question why you would want to use that one, since no display uses that curve as an EOTF.
thank you for your answer, that is very strange. I’m also on a M1 Ultra Mac Studio, with DVR 19.1.1 yesterday I updated to 19.1.2 still the same problem. The strange thing is, when I change to the build in ACES1 IDT Rec709 then it works. And also the inverse ACES2 CAMDRT rev028 and CAMDRT rev035 what I installed last year, work. But not rev060 and your rc1. Any ideas about that?
And thank you for the sRGB example code, I will try it as soon as I have solved the first problem
I found something out, but I don’t understand the background. I compare the code of the rev035 to the rev060 file and so that in the “float3 transform part” there is something different. There is the variable p_R, p_G and p_B I don’t know if its right but i change this variable to the variables of the rev035 r_lin … and now it looks like it works. I don’t know if its right, but now it looks like a rec709 rendering in davinci.
Good catch! That’s an error made in the most recent change to the LUT based transforms. I’ll report it to @alexfry so he can push a fix. I must still have an older version, which is why it worked.
Doesn’t explain why my rc1 DCTL does not work for you. The version I am using is the same one that is in my repo. I’ll let you know if I find anything out.
Just checking. You have copied the entire folders for my rc1 DCTLs, haven’t you? Particularly the hellwig_lib_rc1.h file, which the other DCTLs all use.
Nick that’s so helpful, thank you very much, I forgot the hellwig_lib_rc1.h File, now everything works perfect! I also adjust your PURE DCTL and now I have a Gamma 1.96 and sRGB ODT!
And I also manage the inverse so the IDT. I found the place to replace the IN Gamma from 2.4 to 1.96 and recode the math for the sRGB to linear part what you wrote above.
Thank you Nick for all that, it was really fun, I’m happy now that everything works!
Hi Nick,
I still owe an answer, I overlooked the question:
So my grading pipline looks like this (I don’t know if it’s the right one.): My working monitors are calibrated to BT.1886 with gamma 2.4. A lot of work I do, is for online. And a long time i had issues with the gammashift on mac. Also my export don’t look like on my monitor. Then I found out, that QuickTIme or what Mac interpret as Rec.709, is a gamma 1.96 in the video file. In DaVinci they called it “Rec.709-A” a for “Apple” maybe? If I do that, and open the video in QuickTime, then the video looks 99 % same to DaVinci. (The Gamma-Tag need to be also “Rec.709-A” is 1-1-1)
The same effect I have, when i want export stills from DaVinci, I need change the ODT to sRGB then make a still and export it to jpg. Because I found out, that the jpgs are tagged as “sRGB” but not converted automaticly to sRGB.
With this pipline a have a perfect match between a exported still, the exported video and DaVinci Viewer and monitoring. Perfect match in the Apple World. On Windows, the Video looks too dark, because the convert to gamma 1.96, but this is a different story.
There have been so many countless articles written about this over the years.
QuickTime, AVFoundation, Safari etc. on macOS are, for the purposes of this conversation… wrong. They decode “BT.709” tagged content as ~1.961, which is essentially the inverse of the (largely legacy) reference television OETF, with no forward surround compensation (OOTF) that is expected with a modern display referred BT.1886 pipeline.
I understand it seems crazy and unfortunate that macOS of all platforms would have this issue. Especially considering iOS doesn’t have this issue (iOS is mostly 2.2, but auto-brightness mode will skew it around as needed).
By using “Rec. 709-A”, you are asking Resolve (via ColorSync) to mimic QuickTime’s behavior in the UI player (~1.961 decoding) thus it will match. But this also means you are effectively baking a fix for this problem into your footage forever. I think most folks on this forum would agree that’s generally not a great idea, unless you’re specifically trying to make a client that’s using a MacBook happy, or just post things quickly to social media that don’t need to be evergreen for very long.
It’s also ideal to use an external SDI monitor (through Decklink, Ultrastudio, etc.) when possible, but I understand that isn’t practical for everyone especially for web focused work.
Unfortunately you just have to accept that your content will get decoded anywhere from 2.4 (hopefully by a TV in a dark room) all the way to 1.961 (hopefully in a very bright environment). This is why many folks suggest mastering content intended for web with a 2.2 power OETF/EOTF. You can do this either while sitting in a well lit room, or by converting your dim room 2.4 master to 2.2 at the end. This puts you in a good middle ground, as discussed in FilmLight’s fantastic “sRGB… We Need To Talk” video. It also means your still frame exports would match, or be very close to matching. (macOS uses the piecewise sRGB function to decode still images, regardless of your display, as you’ve discovered already).
Gamma shift operations to RGB data can create undesirable perceptible hue shifts, which is why it’s best that your modern sophisticated image formation chain handles such gamma encoding and viewing environment compensation for you at the rendering stage. It’s best to not rely on things further down the line to do those conversions. So mastering to 2.2 puts you roughly in the middle such that there will be a minimal amount of differences from your master on any given platform. Again I say this for web focused content. Anything cinema or theater focused should follow those delivery specs.
thank you very much for your thoughts! In any case, I had no intention of opening this topic here. I know that it’s a kind of ‘never-ending story’.
I completely agree with you on all points. I also do colour grading on BT.1886 calibrated monitors. I also only do this workflow, exporting with gamma ~1.961, in certain cases when I know the client is sitting in front of a Mac watching the videos in QuickTime. I also only perform this export specifically if it is intended for social media content or if I know which display the customer is looking at. I have also often exported to Gamma 2.2, exactly as you described. I also know the video by Daniele Siragusano very well.
Unfortunately, the whole situation is a tragedy, because it’s also very tedious and time-consuming to explain to every customer why the video looks brighter than the stills he received. In the end, he wants to see exactly what he saw in my suite, and I try to achieve that with a wide variety of gamma exports.
For TV or cinema, of course, I only export in gamma 2.4 or whatever is required for the format.
Let’s hope that Apple changes a few parameters in the AV Foundation in the future.
