Recap:
- 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.