We use the same GoToMeeting URL and phone numbers for all VWG meetings.
You may join via computer/smartphone (preferred) which will allow you to see any presentations or documents that are shared, or you can join using a telephone which will be an audio only experience.
Please note that meetings are recorded and transcribed and open to the public. By participating you are agreeing to the ACESCentral Virtual Working Group Participation Guidelines.
Audio + Video
Please join my meeting from your computer, tablet or smartphone.
Audio Only
You can also dial in using your phone.
Dial the closest number to your location and then follow the prompts to enter the access code.
I have pushed a version of my DCTL implementation of @matthias.scharfenber’s ZCAM DRT, based on what I showed in the meeting to my GitHub if anybody wants to have a play. It’s very much work in progress, and the inverse transform is not working properly yet, but I thought I would put it out there.
I should note that I have only tested this under Metal on Mac. OpenCL is always problematic, so I don’t know if I can support that. But I need to test under CUDA, and will probably have to fix some syntax.
UPDATE:
Pushed another commit, which hopefully makes it work under CUDA. OpenCL is still a no go. But is anybody still using that?
Thanks for making DCTL version, Nick!
It works on CUDA, but I get small black squares if pixels have at least one negative value. Or if I touch anything in the node after the DCTL.
And there are a few more artifacts, but I don’t know if they come from DCTL implementation for CUDA or from original ZCAM DRT design. So here they are just in case.
And I’m not sure this is incorrect, but I can’t get the same white point as the input has whatever combination of white point settings I choose.
Here is ACEScct to ZCAM DRT curve:
The DRT expects ACES2065-1 (AP0) as input. I get the same artifacts with the LUT stress test image but if I do AP1 → AP0 transform before the DRT then it looks as expected. It would be nice to add ACEScg and ACEScct as input options too.
Adding ACEScct and ACEScg as input options will be pretty straightforward. I didn’t bother initially, as you need to use it in non ACES mode in Resolve, so it has to be preceded by various colour space conversion nodes anyway.
Thanks! I used AP0 Linear images with ZCAM DRT. And LUT Stress test image intentionally was not converted from AP1 to AP0. I thought, DRT should be able to deal with the whole AP0 gamut, not just AP1, or what’s the point to use AP0 gamut in ACES framework at all? I’m not using this question to say one more time that DRT has to be able to display AP0 gamut somehow, but I would actually like to know if I’m wrong. So please feel free to correct me.
I believe my latest commit should have fixed that. Thanks to @Thomas_Mansencal for the suggestion of using “safe power” operations to make things robust to negative input.
@matthias.scharfenber has pointed out that the ZCAM DRT is actually input gamut agnostic. AP1 is in fact not used at any point. The input to the rendering is actually CIE XYZ. That does not mean that certain input values might not produce negative values at certain points in the processing, and the DCTL version should now handle those more elegantly.
Thanks! Black squares that appeared after any operation after DRT are gone now!
But if I lower the shadows with the offset wheel performed in linear space (ACEScg for example), then I get sharp square black pixels:
