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

ACES Gamut Compression Implementation VWG Meeting #6

Thursday, May 6, 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/13/21: 9:30 am PT
  • 5/20/21: 5:00 pm PT
  • 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.

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

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!

Recording and Transcript


Is it ok to write in this thread or it isn’t for discussion but for meeting notes only?
I’m not sure where is the appropriate place for the discussions about meeting notes :slight_smile:

For Resolve, applying gamut compressor in a node goes after resizing from source to timeline resolution. This means that resizing is applied to ACEScct (or even ap0 linear? I hope not) with negative values. So I think, it’s better to apply gamut compressor by the context menu of a clip (I’m not completely sure, but I think resizing goes after that), to avoid artifacts.

Hi! Replying here is great - thanks for the feedback! We will keep this in mind, definitely agree.