Thursday, April 15, 2021
9:30am - 10:30am Pacific Time (UTC-4:30pm)
Please join us for the next meeting of this virtual working group (VWG). Future meeting dates for this month include:
April 22: 5-6pm PT
April 29: 9:30-10:30am PT
Dropbox Paper link for this group:
We will be using the same GoToMeeting url and phone numbers as in previous groups.
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 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
Results of inverse on renders that did not have the forward transform applied
We established that without parameter modification, the tracking of the algorithm could be done using the current AMF spec (in an LMT slot)
Then the topic of parameterization was discussed:
@hasche and @matthias.scharfenber pointed out that exposing parameters could be useful in comp as well as color grading (green screens might be out of gamut, etc)
Even though the blue > magenta hue shifts are Output Transform related, they can be slightly mitigated through gamut compression and that might be desirable
How to handle the desire to parameterize vs. the need to track?
@KevinJW suggested two options: the official ACES Gamut Compression which would be static and trackable via AMF, and then another separate operator of a different (TBD) name, which could expose parameters in Nuke, Resolve, Baselight
This second option would be treated like any other operation in comp that changes colors (despill, etc) and would not need tracked because you’d never want to go back
@mario suggested separating the thought process as technical vs creative in our documentation
We discussed briefly that negative values still remain in the noise floor post gamut compression, and that this is intended - pointed to earlier versions of the algorithm in @jedsmith’s repo if folks want an idea of how to solve that separately. But it was not included in the final algorithm to maintain exposure invariance for invertibility.
Not sure I’m understanding this correctly. The shadow_rolloff parameter was not intended to “fix” negative values in the noise floor. It was intended to fix very subtle invertibility issues due to the asymptoting compression curve when dealing with large distance values in shadow grain.
I attempted to explain that clearly in this post if it’s helpful to resurrect this thread again
I would even suggest that even though we run the same gamut compression algorithm we clearly separate parameterized creative tool that could find custom and creative use from standardized ACES approved and version locked process. This will prevent huge mess that will result with facilities workflows and people picking up, modifying and applying custom (and sometimes broken) gamut compression to images.
I think names matter and shape how people think about these two use cases. One custom and creative the other standard, tested and ACES approved.
