Notice of Meeting - Output Transforms Architecture VWG - January 5, 2022

Output Transforms Architecture VWG Meeting

Wednesday, January 5, 2022
1pm Pacific time Add to calendar (.ics)

Dropbox Paper homepage for this group:

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.

** United States: +1 (669) 224-3319 **
** Access Code: 241-798-885 **

More phone numbers:

Australia: +61 2 8355 1038
Austria: +43 7 2081 5337
Belgium: +32 28 93 7002
Canada: +1 (647) 497-9379
Denmark: +45 32 72 03 69
Finland: +358 923 17 0556
France: +33 170 950 590
Germany: +49 692 5736 7300
Ireland: +353 15 360 756
Italy: +39 0 230 57 81 80
Netherlands: +31 207 941 375
New Zealand: +64 9 913 2226
Norway: +47 21 93 37 37
Spain: +34 932 75 1230
Sweden: +46 853 527 818
Switzerland: +41 225 4599 60
United Kingdom: +44 330 221 0097

The recording and notes from meeting #36 are now available.

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.

Pushed another commit, which hopefully makes it work under CUDA. OpenCL is still a no go. But is anybody still using that?

1 Like

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.

Good point. I should have mentioned that.

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.


1 Like

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:

But if I hard clip the image, most (not all) of those black pixels are gone:

I apologize if this is nitpicking and is expected for a not finished prototype.