Yes, the mistake @priikone picked up only affected hellwig_lib_v057.h. The other v57 DCTL files are unchanged.
Thanks for that. I don’t have an OpenCL system here to test. When I had one before I always found it was far more picky about DCTL syntax than the others.
I’ve pushed an update with your suggested fix.
I pushed CAM DRT v058 with some new parameter values to my repo. I’ll create a pull request for Alex later after we’ve discussed some things in the meeting.
One thing we’ve talked privately was P3D65 inverse. Previous versions haven’t inverted P3 as well as Rec.709 and to get it inverse better we’d have to increase cusp smoothing, rather than what I’ve been doing lately, which is to reduce it to reduce clipping. This version should bring P3 inverse to same level as Rec.709, but it does come with a bit more clipping in the forward direction in Rec.709.
Param changes (no code changes):
Just pushed a v58 update to my DCTLs, including versions tagged to be used in the custom ACES Transforms directory.
During last night’s meeting, @jpzambrano9 pointed out that the reach cusp (AP1) table in my DCTL did not quite match the table in the Blink. I realised that my Python which generates the tables was still incorrectly using D65 white for the AP1 reach, despite that being fixed in the Blink a few versions ago.
I have just pushed a commit to fix that in the v58 DCTL.
Hello guys,
I have a quick question.
It is super nice to see this group wrapping up and I was wondering if now would be a good time to discuss the “flare/glare compensation” ?
Are we compensating for the “low contrast” look of the curve by boosting this parameter ?
DRT_CAM_Kernel_daniele_t_1 0.04
Is this intended ? I think it was mentioned also in this thread.
Regards,
Chris
Hello,
I just wanted to share that one of the participants of the Output Transform VWG, @jpzambrano9 , got his picture formation “2499” used on the Cannes short film winner (The man who could not remain silent).
Original post: Jpzambrano: "Kinda funny first post here but I am very proud t…" - Mastodon.ART
I thought that was kinda cool and wanted to share the news.
Regards,
Chris
Hello,
following tonight´s meeting (2024/06/05), I post here the Nuke script and images that I shared during the meeting. If I did not mess my setup, it looks like ACES 2.0 is more contrasted in the low-end than ACES 1.2. I have attached a frame with OpenDRT v0.3.2 just because I know that Jed worked really hard on the tone scale.
sweep_comparison.nk (25.4 KB)
I used the OCIO version 060 (from here) in Nuke 12.2v6. These sweeps use sRGB/BT.709 primaries but it looks like the same contrast can be observed with ACEScg primaries.
Regards,
Chris
What was wrong with the originally proposed flare value?
I cannot remember exactly but maybe the following happened : in order to get a pleasing image out-of-the-box, this parameter was boosted for contrast, instead of relying on a LMT.
But I could be wrong since my memory is fuzzy on that specific point.
Regards,
Chris
A related question, where are the views for sRGB or EOTF 2.2 displays? I thought the ones named re.709 were for those displays.
They are indeed available for selection from the Output Transform presets available in the ACES 2.0 Developer Release (aces-output/srgb at main · ampas/aces-output · GitHub).
The transforms for Rec.709 is labeled Rec.709 and is for Rec. 709 primaries for EOTF according to BT.1886 set with a 2.4 gamma.
The transforms for sRGB are labeled sRGB and represent sRGB primaries for EOTF according to sRGB IEC 61966-2-1:1999.
There is also a transform labeled sRGB Gamma 2.2 which is intended for sRGB primaries according to a pure gamma 2.2.
Which is the “right one” is a religous debate that you can find many digressions about on this forum, but each option is available and you should pick the one that best fits your display characterization.
Sorry for the confusion, I was referring to the ones that were made for OCIO, there are no luts for sRGB there.
Ah, yes, I misunderstood your question. That is correct - we have not been baking LUTs for every possible output during the development phase. However, the full suite of outputs defined in the CTL will be available in OCIO and other products when updated for ACES 2.0.
It is an option to get sRGB (IEC 61966-2-1:1999) from the Blinkscript used in the LUT bake script but the Nuke bake file doesn’t currently have that linked up as one of the presets to output as part of the bake process. The Blink does not currently include the option for a gamma 2.2, but it’d be very easy to add that as an additional option in the Blink if there was a need to do so.
I expect the release version in OCIO will follow the OCIOv2 convention of separating the view transform from the encoding, so the ACES 2.0 SDR view transform can be combined with a BT.1886, sRGB or gamma 2.2 display device.
I’ve pushed a new set of DCTLs with parameters updated to match the release candidate CTL.
Thank you all for the incredible work. I’ve been using the various ACES 2.0 DRT candidates over the past year in Resolve on various shows, including grading a few VR concerts for Meta Quest, and I really like the softer curve. There can still be some breakup in super highly saturated, bright colors, like the LED lights you find at concerts, but I know there isn’t too much that can be done to avoid that. I also like that ACES 2.0 continues to look nice with some PFEs I purchased, namely the Cinegrain Pipeline LUTs.
I was hoping to try the release candidate in Mistika. Is there any chance to get it as a GLSL shader? If I’m not mistaken, that could be interesting also to people using Scratch/Live FX and Flame. If it’s too much extra work, no worries. I can wait for the release.
I’m afraid no glsl version of the release candidate exists. The only glsl implementation I am aware of is this one I wrote for Baselight back at version 31. But things have changed quite a bit since then.
Hello @Thomas_Mansencal , may I ask how to use those cornell box renders ?
More specifically which colorspace are they encoded in ?
If I understand correctly this Alexa variant is basically a virtual reproduction of what would capture a ALEV 3 sensor under specific light sources, that you have then “”“debayered”“” to a specific colorspace ?
Hi Liam,
I was asking once Thomas as well, because I wanted to post the renderings in different encodings (SDR/HDR) on YouTube. The EXR files are ACES 2065-1.
Yes, they should indeed all be encoded using ACES2065-1, the Alexa one used a custom IDT.
