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

rrodriguez · April 23, 2021, 11:22pm

ACES Gamut Compression Implementation VWG Meeting #5

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

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.
https://global.gotomeeting.com/join/241798885

First GoToMeeting? Let’s do a quick system check: https://link.gotomeeting.com/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

matthias.scharfenber · April 30, 2021, 8:30pm

Recap

@matthias.scharfenber started by restating the intention to have a separate immutable ACES version of the compression transform as well as a parameterised version which would be discussed later.
@KevinJW noted that application vendors would most likely implement the parameterised version first and posed the question of where in a workflow would one use the fixed vs the parameterised version.
@matthias.scharfenber : The main difference is how the two would exist in an ecosystem (OCIO for example) and the user experience of them. Perhaps a project level setting (which can be overridden per clip) vs an operator in the node tree/stack.
@nick: In Resolve, for example, it might be a check-box in the project settings next to the choice of IDT.
@KevinJW: Usage might vary depending if it was applied by an artist to solve a problem they had, or was simply there as a production requirement.
@matthias.scharfenber : It comes back to the discussion of whether to include it in the AP0 to AP1 transform (but not the AP1 to AP0).
@KevinJW : Asymmetric OCIO conversions are possible, but I wouldn’t advise it. I suggest (if it was defined as a color space) a separate color space with it applied to be used on ingest to ensure it only happens once. But I would prefer something more like a CDL operator.
@michaelmaloney333 : On one project we tried applying it in Resolve at a project level, but it caused issues for VFX, so we changed to selectively applying it per shot.
@daniele : I would keep it as an operator, to give it visibility and give the user control of its position in the stack.
@michaelmaloney333: We’re trying it on a current show by including it in the LMT, with parameters dialled back, so it’s “part of the look”. It’s been used successfully on set. This show is grading in LogC, so ACEScct range issues for LUTs are not a problem, as CDLs were applied in LogC.
@matthias.scharfenber: asked how this pipeline impacted VFX. Mike acknowledged that this was something to be dealt with separately if negatives in comp (before the LMT with gamut compression) caused issues.
@michaelmaloney333 : On this show we did not need to do what we have always done in the past, inverting out the RRT and really working entirely in LogC.
@daniele: We need to make sure we design something that works with a standard ACES pipeline grading in ACEScct.
@matthias.scharfenber: Great to hear of it being used in the real world and working as expected.
@zachlewis s: In OCIO 2.0 the parameterized version could be implemented using the new fixed function operators. But currently there is no Nuke OCIO node to call these.
@matthias.scharfenber: We imagined the ACES static version would be a built in transform so it could be applied using an OCIO Look operator, even without a dedicated built in transform or named transform node.
@nick : The fixed function concept exists in Autodesk CTF now, but not in CLF.
@KevinJW: We need to think about how it will be added to CLF and AMF. I wouldn’t want to add the complexities of fixed functions to CLF. I see it more like a CDL.
@KevinJW : Are there any other situations apart from ACEScct which have limitations which might cause issues?
@matthias.scharfenber: Anything that has to implement it as a 3D LUT (even with a custom shaper) will mean it is not invertible.
@nick : If it’s in the grading stack, people need to be aware that they can’t just bake a LUT of the grade as applied in ACEScct (Resolve LUT export) and expect that LUT to include the gamut compression.
@joseph : Are there any issues if it was implemented in camera, where CDLs can be applied in camera. Currently those are applied in camera native log.
@jzp : On the Marvel show we mentioned earlier, it would be possible to apply it entirely in camera, as the CDLs were applied in LogC, followed on set by a concatenated LUT. There it was “on” for the whole show which removed tracking problems.
@Giardiello : We have implemented it on a couple of shows. On one as part of the on-set IDT and as a pre-group in Resolve. On the other there was no on-set grading, so we just made a concatenated LogC to Rec.709 LUT with it in. It’s still to be decided exactly how it’s applied in VFX, because it’s already part of the look seen in dailies.
@nick : If it’s applied universally mathematically as part of the IDT, how much difference is there between inverting it straight back out again and not applying it in the first place?
@daniele: Relying on inversion is a bad idea. If anything at all happens in between the forward and inverse transform it can have a dramatic effect. Maybe even half-float quantization would be enough to introduce issues.

Recording/Transcript