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

ACES Gamut Compression Implementation VWG Meeting #10

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

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

  • TBD

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

Here’s the recap, sorry for the delay:

  • @carolalynn brought up the naming ACES central post, farming for dissent. Folks seem to favor Parametric over Variable.
  • Talked about the Resolve implementation status:
    • @michaelch: We are working to get an implementation out in a future point release. More of the concern is AMF, and being able to track it, that isn’t as far along but moving forward.
    • @carolalynn : The group would be interested to see how it works in the UI - settings, etc
    • @michaelch : We might be able to get a demo build out soon for testing.
    • @carolalynn - for both the reference and the variable/parameterized? There’s a lot more to decide for the latter - what do we call the sliders? We know what distance limits are but users likely won’t - also, what are the defaults? Do we start from nothing or from the reference?
    • @jzp : also things like valid ranges and perceptual differences in different slider values
    • Likely better to start with the Reference implementation, and address the needs around the other later.
  • Talked a bit about how to combine efforts with AMF to push both implementations forward - looking to make use cases for both as a workflow. Will work with the AMF implementation group to align.
  • Lastly, we brought up Gary Demos’ feedback on the released CTL:
    • @nick : Gary flagged our use of max(RGB) and its potential to introduce noise to other channels. We don’t feel it’s generally an issue due to the fact that we’re generally operating on bright pixels with not a ton of noise, but this is a general assumption and not proven.
    • @matthias.scharfenber : we also talked about possible “lift” to the noise floor slightly. The architecture group felt that this was a worthy tradeoff to make to fix the out of gamut values.
    • @matthias.scharfenber : the other piece of feedback was around numerical compression near 0. If the achromatic value is really small, you end up dividing by a really small number. If it’s large enough, you may theoretically exceed the limits of the data type. As the process space for this algorithm is 32bit float, we think this outcome is highly unlikely. Pretty academic issue, especially as the real way it might show up is the inverse, but that is not the intended workflow anyway.
    • @joseph : I wrote a bunch of code to categorize numbers around these areas - 2 negative, all negative, etc. Happy to share it.
    • Proposal would be to use a small epsilon in replace of if ach == 0, but not until the next release of ACES, as it’s not critical.

Recording / Transcript