Notice of Meeting - ACES Gamut Compression Implementation VWG - Meeting #8 - 5/20/2021

Discussions - ACESNext VWG – Gamut Compression/Mapping
1

ACES Gamut Compression Implementation VWG Meeting #8

Thursday, May 20, 2021
5:00pm - 6:00pm Pacific Time (UTC-12:00am Friday)

Please join us for the next meeting of this virtual working group (VWG). Future meeting dates for this month include:

  • 5/27/21: 9:30 am 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 + Video
Please join my meeting from your computer, tablet or smartphone.
https://global.gotomeeting.com/join/241798885

First GoToMeeting? Let’s do a quick system check: https://link.gotomeeting.com/system-check

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

2

Recap:

  • We gave an update to the implementation TAC today, all went well. The only actionable request was for visual documentation, before/afters, etc, showing that where you apply the compression matters.
  • @jzp : the point about how all of this fits together brought up by @CClark was a good one - the working groups do need to talk to each other and make sure interop can be successful.
  • OCIO 2.1 Implementation:
    • @doug_walker : I thought at first that only the hard coded parameter version should have the ACES name on it, but now I’m wondering if that is realistic - people are going to use both.
    • @matthias.scharfenber - if they’re both ACES, people might use them interchangeably and cause confusion. If it has ACES in the name, there should be no doubt of what it is.
    • @LarsB : Agree. We need to be clear on what is ACES and what is not.
    • @Alexander_Forsythe : Parameterized version feels like a power user tool. Fixed version is to avoid confusion, provide a vetted set of defaults.
    • @doug_walker : but the reality is that there’s already the Nuke, DCTL, etc implementations - these things need a name. If we don’t name it, folks will call it ACES anyway.
    • @sdyer - this convention happens with the SSTS. It’s an algorithm with a default set of parameters. If someone modifies it, it’s still ACES.
    • @michaelch : it’s very important that we keep this split. For example, we exposed the parameter for the mid-grey in the ODT, and to be honest that’s not tracked very well. We need to be very clear.
    • @matthias.scharfenber : yes, that’s exactly what what we’re thinking. Once you start tweaking things, it’s not a reference transform anymore, it’s a creative grading operation.
    • @nick : And the transform ID tracks a fixed version via the AMF - how would you indicate a custom transform in an AMF?
    • @Alexander_Forsythe : You can reference a transform ID, in your own namespace, not publicly available, but the production can use it. You can also use a file path reference to a custom CLF or something too.
    • @sdyer : Also, our current transform ID naming convention doesn’t cover all parameters, only some - would need updating.
    • @doug_walker : Should there be three names? ACES Reference, version where you’ve just changed the power curve parameter, and a version where you change whatever you want.
    • @carolalynn : To summarize: seems like we agree that the Reference will have a specific, consistent name. We also agree that this parameterized version needs a name. We don’t agree on whether the parameterized version should have ACES in its name.
    • @matthias.scharfenber suggested something to start from, though all agree it’s too long and not marketable: Immutable Version: ACES RGCT (Reference Gamut Compression Transform) , Creative Version with Parameters: AMPAS VTGCT (Variable Threshold Gamut Compression Transform)
    • @doug_walker : Should get input from the community, without the OCIO PR in the picture, and then make a decision for all implementations.

Recording and Transcript