Notice of Meeting - ACES Gamut Compression Implementation VWG - Meeting #11 - 6/10/2021

ACES Gamut Compression Implementation VWG Meeting #11

Thursday, June 10, 2021
9:30am - 10:30am Pacific Time (4:30pm UTC)

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

  • 6/17/21: 5:00pm PT
  • 6/24/21: 9: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 + Video
Please join my meeting from your computer, tablet or smartphone.

First GoToMeeting? Let’s do a quick 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


  • Naming decided:
    • ACES Reference Gamut Compression (RGC)
    • ACES Parametric Gamut Compression (PGC)
  • Baselight update from @daniele: we have strict release schedules and can’t put new tools in a point release. But we have some options (such as a Matchbox shader) to maybe get the Reference fixed transform in earlier. Parametric may be more complicated.
  • @carolalynn : parametric is much less of a concern, we’d prefer to do it down the road.
  • @jzp : This algorithm is applied in acescg, how will different applications handle that?
  • @matthias.scharfenber - the CTL is published as an aces look, ap0 in and out, and individual implementations will need to decide how to handle the colorspace awareness for application.
  • @nick : this is a reason to have the algorithm applied as a project setting as opposed to a node in the stack.
  • Group agreed that clear documentation on intended usage and requirements will be essential - on for viewing, off for VFX pulls etc.
  • @daniele : are we planning to ship the inverse with the Reference transform? How would that look?
  • @jzp : we’d need it for forensics but that’s about it
  • @KevinJW : it’s going to be per project - a lot of VFX supes will want to invert
  • @daniele - we need documentation around why not to inverse.
  • @carolalynn : It all comes back to documentation - we need to write an implementation guide and also a “user guide” - then maybe applications could point to that in their help. We have to solve for the 80% aces use case, describe the general workflow, and accept that deviations are inevitable.
  • @KevinJW : without AMF, we have big time tracking issues
  • We should talk about the workflow and use case without AMF, as it’s going to be awhile until AMF is widely available / adopted.
  • Should that be in naming conventions? EXR metadata? Both? Something for this group to talk through in more detail for the implementation/user guides.

Recording / Transcript