Meeting Notes
- @matthias.scharfenber started by restating the intention to have a separate immutable ACES version of the compression transform as well as a parameterized version which would be discussed later.
- @nick: Perhaps only the ACES version should be on the AMPAS GitHub. We could put a parameterized version on Nukepedia and online Matchbox shader libraries, not badged as ACES, but with a note that it is compatible if particular parameters are used. Or the software vendors could implement it themselves.
- @jeroen.schulte: It has broader use than just the static version. It has become our go-to gamut mapping operator, and we adjust it to the requirements of each particular source.
- @matthias.scharfenber: We have discussed OCIO being a good first implementation for discussion. Particularly as Doug is here today.
- @doug_walker: The “blue light fix” is implemented in OCIO as a look (LMT) and we could do the same with the gamut compression operator.
- @jzp: LMTs are strictly AP0 in and out, but in reality they are often applied in ACEScct. Might this cause range issues? Also LMTs are perceived as something that goes after the grading stack. Perhaps we need a new concept of an “input LMT”.
- @matthias.scharfenber: It’s important it is put in the correct place in the pipeline, otherwise negatives could be altered or clipped by operations in the node tree.
- @Alexander_Forsythe: The spec doesn’t actually define that LMTs have to go after grading operations.
- @doug_walker: At the low level in OCIO it would be implemented as a Fixed Function, added to the list we already have. Then a Built-in Transform would be used to expose that to config authors. The working space would be defined in the config. The fixed function probably shouldn’t include the transforms to and from AP0 which are in the CTL, as that would mean the optimizer couldn’t cancel them out if they were redundant.
- @nick: Would the fixed function take parameters, and the constants for the ACES immutable version be applied by the built-in transform?
- @doug_walker: If so the fixed function would have to have a different name, and it would only be called “ACES” at the built-in transform level. It’s analogous to the spline curve fixed functions, which are generic but used by the ACES built-in transforms.
- @matthias.scharfenber: How do people see it being exposed in a grading system? Daniele suggested last week it should be an operator in the stack. Or it could be a switch in the input settings. Perhaps a “smart” check-box which applied it or not depending on whether metadata either from AMF or in the EXR header defined it as already being applied.
- @jzp: EXR metadata often gets stripped by pre-processing.
- @jeroen.schulte: We have used it on a show as an input “sweetener” applied using DCTL after the IDT, customised to the particular camera.
- @Alexander_Forsythe: I would vote for the check-box. If it’s present in the stack, people will move it to different positions because they can.
- @Thomas_Mansencal: For many people doing simple fast turnaround jobs, the fixed version they just turn on will be enough. They don’t need to think about it.
- @jzp: There should be clear guidance that it is not to be applied to VFX pulls if we agree that’s the recommendation. But it’s still a tracking issue, as the originals will not have it baked in, but when shots come back from VFX they will have.
- @joseph: We need to make sure dailies are included in the discussions, and use every channel available to us to get the message out – Patrick Renner’s newsletter, and DIT FaceBook groups and mailing lists.
- @jzp: It’s critical we define a standard way to indicate in an ALE whether the operator has been applied or not. Defining standard ALE fields for CDL was the best thing we ever did!