ACES Gamut Mapping VWG Meeting #11
Thursday, May 7, 2020
5:00pm - 6:00pm PT (Los Angeles time / UTC-12:00am)
Please join us for the next meeting of this virtual working group (VWG). Future meeting dates for this month include:
- 5/14/20 9:30am
- 5/21/20 5pm
- 5/28/20 9:30am
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: [https://link.gotomeeting.com/system-check]
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
Recap of discussion:
Note - there was a lot of all over the place discussion this meeting, if you want the real context, it would be a good one to listen to the recording.
@LarsB - exposure invariance only possible without limiting input/output - we need to make make clear we are talking about scene-referred in the Progress Report so display limits are not relevant
- List things that are out of scope in Progress Report
- Is exposure invariance truly necessary? Lars points out luminance might change - but for scene-referred, luminance can be negative and therefore not useful.
@joachim.zell brought up chromatic aberration - nice to have reference images here, but not really an issue for a gamut mapping algorithm
- How do we deal with way out of gamut red but in gamut green? This is actually the most common problem. @carolalynn : this is where the safety gamut comes into play
- How do we identify what is ‘right’ or ‘good’? Discussion around camera manufacturers color pipeline vs aces for visual reference
- Lars - working on a 2020 to r709 mapping, cyan is the hardest. What are the hardest colors in ACES to map? Group responded with blues for sure.
@Troy_James_Sobotka proposed that a macbeth chart would be a good place to start for colors we care about? At least as a ground truth - macbeth colors should not ever be affected by our algorithm as a base level of acceptability. 190 or 24 chart?
- What do we do with values outside of AP0? Do we clamp? Treat them as valid?
- Lars referenced the Reinhart tonemapping equation. Applied to luminance only. Thomas and Troy noted that it causes hue distortion. https://www.desmos.com/calculator/udgcerxlsb
- JZ - do we need a golden eye group? Present mapped images and see what people think - maybe eventually, after our own group has done visual/measurable testing
@Thomas_Mansencal raised a grading operator downstream of gamut mapping to ‘steer’ hues back on track. Matthias’ Nuke script has this option, but it’s global – introduces new artefacts when qualified. This is problematic for the zone of trust.
- We need to remember that there will normally be grading as well. So if our gamut mapper ‘heals’ the image so it is easier for the colorist to get to where they want, that’s a big improvement on the current situation.
@carolalynn: That would be the link with the Pseudo Reinhart / Simple Tonemapping operator: https://www.desmos.com/calculator/udgcerxlsb, the other one does not have it and was just the two functions we used so far.
Desmos annoyingly update the url each time you save…
Guh thanks Thomas, I’ve updated the post.
Damn! We cross-updated, I re-saved it to have different colours for all the functions, sorry!
I would suggest that it needs to go a bit further here. The output image by default should not suffer from any gamut mapping issues. The creative default should avoid known first tier breakage.
At its core, the ACES RRT, is part of a gamut map. The transfer function that takes a wide range of scene dynamic range to display is there as a gamut map of source volume to destination. It is missing the other 60+% of the effort.
It would seem reasonable that the goal of the VWG should be to at least to assert that glaring gamut mapping issues are put to bed, at least in terms of primary tier problems being “intensity” and “chrominance”.
In terms of tiers, the following suggestion risks grotesquely oversimplifying “colour” into two impossibly intertwined axes that cover what could be “Primary Tier” gamut breakage. That is, is it reasonable to suggest that the target seek to:
- Repair “intensity” based clipping of gamut volume issues. IE: Drifting of primary ratios toward the Notorious Six of Cyan, Magenta, Yellow, Red, Green, and Blue. The latter three being induced through synthetic rendering, the former three being extremely common in skies, blue neons, trees, human skin, woods, etc.
- Repair “chrominance” based clipping of gamut area. The “slam to hull edge” problem, resulting in posterization along saturation intents.
Secondary tiers may be something valuable, such as Abney, BB, etc. Secondary because they tend to be more abstract psychophysical responses.
JzAzBz uses the Reinhart tonemapping equation:
Jz = ((1 + d) Iz)/(1 + d Iz) - d0
It can be applied to other single-channel remapping such as saturation.
It can be extended with a linear section at the bottom, for the “safe zone”
It can be set to map one range to another range.
It is trivially invertible.