Notice of Meeting - ACES Gamut Mapping VWG - Meeting #8 - 4/2/2020

Discussions - ACESNext VWG – Gamut Compression/Mapping
1

ACES Gamut Mapping VWG Meeting #8

Thursday, April 2, 2020
9:30am - 10:30am PT (Los Angeles time / UTC-4:30pm)

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

  • 4/9/20 5pm
  • 4/16/20 9:30am
  • 4/23/20 5pm
  • 4/30/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.
[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

1 Like
3

Is there a recording of meeting #7 available? It is not listed in the Past Meetings section of the DropBox Paper page. It would be good to be able to listen to that before today’s meeting.

1 Like
4

I think not, I was looking for It also but didn’t find it.

5

It has now been added

2 Likes
6

Recap:

  • Some more updates from @matthias.scharfenber about the example Nuke script that was posted on ACES Central
  • Carol will debayer/convert all images currently on the dropbox repo to AP0 and re-upload for ease of use/consistency in dataset
  • @SeanCooper talked through his ‘Sketches of Hue’ post - thoughts around hue-based extrapolation of lines out to the spectral boundaries at the point they diverge. How to find that point in a predictable way?
  • @LarsB and others mentioned the benefit of limiting the scope to one area/point in the processing pipeline - i.e. AP0 to AP1. This will become a future agenda item to examine if a consensus can be reached on how to limit the scope to something achievable, now that we’ve seen some preliminary examples, to help the group move forward.
  • @daniele demoed the gamut compression operation in Baselight - parameterized control for colorists to bring colors back into gamut from any number of reasons. It is gamut agnostic and exposure invariant, and used on a case-by-case basis by the colorist as part of the grading/finishing process. Daniele noted that their algorithms stay within the RGB world - not using any perceptual spaces.
1 Like
7

Copy-pasting almost verbatim stuff talked on Slack after the meeting:

thomas 9:28

Following-up @Daniele Siragusano demo of Baselight, I find that there is something enticing about having an operator that we could tune on a per-case basis

It could be used pre-tuned post-idts and we could find the best parameterisation via optimisation/minimisation AND it could be used manually after as required

When you think about it, there is a ton of stuff in ACES that is pre-tuned, especially in the RRT and ODT portions of the pipeline

Carol Payne 9:53 AM

Yeah, I think there’s value in sort of the ‘super user’ parameters, we sort of talked about that a bit last thursday

kinda like the extra arri debayer options etc

nick_shaw 10:26 AM

ACES philosophy has up to now always been “select from preset options”, e.g. Output Transform, which are parameterised, but only presets are exposed to end users.
I am all in favor of exposing options for advanced users, as long as mechanisms are in place to track those settings in e.g. AMF.

We need to be sure we don’t break the “works the same everywhere, known quantity” advantage of ACES.

thomas 11:46

@nick_shaw : Yup agreed! i was thinking along the lines of choosing a particular IDT would use the dedicated gamut mapping operator parameterisation, nothing exposed to users in that sense

However the operator would be exposed as a tool if they need it for some other stuff

nick_shaw 11:47 AM

Makes sense

thomas 11:49 AM

It is pretty much what is happening when you pick an ODT/OutputTransform, the splines are adjusted to the particular display device

Makes the work comparable too

8

As one of the interested lurkers following the conversation: just curious if meeting #8 was recorded and will be put up on the dropbox papers site?

Thanks! :slight_smile:

9

Hi Jed,

The meeting recording should be up on the Dropbox site now.

10

The submitted test images that were converted to AP0 EXRs can now be found on Dropbox as mentioned this this post:

1 Like
11

If parameterized and user-tunable, you’re enabling color grading in the IDT.
Do we really want that?

If parameterized (but not user-tunable) this could result in an IDT explosion. For example vendor-provided IDTs optimizing for every color temperature x every exposure index. (Not sure what they’d optimize for, but you get the idea)
Do we really want that?

1 Like
12

Daniele’s great demo reminded me of some previous work.

Existing products for mapping HDR/WCG to SDR/NCG have issues that may be relevant here.

HDR to SDR compression based on luminance doesn’t work well. Superbright blues and yellows get compressed to about the same luminance level, which leaves the blue colors way outside the device gamut, so not done yet. Recall that in video max blue (0,0,1) has maybe 7% luminance of max yellow (1,1,0).
Seems better to compress based on RGB values, or maybe simulated spectral data (==WCG primaries).

Color orderings should be preserved. If an original blue is brighter than original yellow, then maintain that order. An old ACES test image included a gray parking lot with yellow stripes. After RRT+ODT to 709 the yellows appeared very bright compared to the gray. Seemed wrong to me.

Neon-lights! Almost every picture of neon-lights show a bright pale center color on a highly saturated background. This color reordering (caused by gamut clipping) looks so unreal. But how to fix it?

The commonly used Reinhart operator does a nice job of compressing overbrights, gradually reducing contrast with stimulus strength. But it affects all colors, also those in the center of the color gamut. Would be desirable to leave most of the gamut unchanged. Could be done as a mod to the operator. Some HDR to SDR conversions use a linear core + log top curve.

Several of the implementations I looked at simply clipped oversaturated colors! Really! It should be easy to compress into the outer 20 % of the gamut.

1 Like
13

Hi @LarsB ,

To a degree anyone can change the numbers in the existing IDTs, I’m not suggesting to provide UI controls to change the parameters we would come with.

If the model is exposure invariant (which it should be) we are left with dealing with colour temperature which reduces substantially the required sets of parameters. Would be certainly worth testing to see how many are actually required.

Cheers,

Thomas

1 Like