Notice of Meeting - ACES Output Transforms Architecture VWG - Meeting #22 - 07/07/2021

ACES Output Transforms VWG Meeting #22

Wednesday, July 7, 2021
1:00pm - 2:00pm Pacific Time

Dropbox Paper link for this group:

Output Transforms Virtual Working Group

We use the same GoToMeeting URL and phone number for all virtual working group meetings.
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

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

The recording and notes from this meeting are now available.

1 Like

Thanks Nick for the notes. It is always very helpful to go back to the notes and check exactly what has been discussed.

One thing caught my attention during last meeting (at 17:00) :

Also the mid-slope, this has been a constant thing that the ACES RRT is too contrasty by default. Obviously that’s an aesthetic preference. Some people love the contrastiness of the RRT. But we know that it can be much more forgiving if you take just the edge of that off a little bit, and especially for people who are used to looking at other renderings that tend to have a little bit less contrast by default. […] I’m thinking that will probably a value is somewhere between where we currently are, and if we over plotted, some other favorable renderings that people tend to like (like K1S1).

What about doing something similar than the filmic blender which comes with different looks for contrast ?

  • Very High Contrast
  • High Contrast
  • Medium High Contrast
  • Very Low Contrast
  • Medium Low Contrast
  • Low Contrast
  • Base Contrast

Since contrast is an aesthetic preference, would that make sense ? I already asked the question here and I think this is part of what Jed’s hinting at with this thread as well. I guess it will be pretty much impossible to have everyone agree on contrast so having several looks could give us more options.

Chris

@ChrisBrejon certainly a reasonable questions to ask.

However, in my opinion, too many options is a bad idea. We already have enough to contend with by trying to accommodate different rendering intents.

RED IPP2 also provides 4 contrast options and 4 R options - but I rarely hear anybody say “I used IPP2 with low contrast and R4 Very Soft”. Instead, they just say “it’s IPP2”. So if anyone is using anything other than the default, this can cause problems.

Also, we’re not prohibiting people from adjusting contrast, just not doing it with the reference rendering. Anyone can, and always has been able to, establish an “always on” LMT that boosts or lowers contrast of the default rendering to their liking.

There have certainly been requests that whatever becomes ACES 2.0 we ship a library of “look” LUTs via LMT akin to RED’s Creative LUT Kit, ARRI’s Look Library APP, or Sony’s Cine LUTs. Doing so would service people who just want presets and also demonstrate that the base rendering does not restrict from changing the look creatively.

Back to tone scale design: We don’t want things to go unrendered, but I do believe that taking just a bit off our current tone scale midslope and highlight rolloff might help us with reducing the obviousness of some of the objectionable skews or artifacts that are accentuated through the current structure.

I think the key idea is, that we need to identify the behavior we expect from the tone mapper across different displays and use cases, and make sure that whatever model we choose meets those needs. It is easier to discuss this in a B&W context and leave color out of it for the time being. I’m working on talking more on this in a separate post…

Isn’t this impossible operating in the stimulus domain?

The stimulus will yield irregular notions of brightness (luminance and / or more refined models), hence instantly voided in terms of meaningfulness because the result is nonuniform with respect to the perceptual sensation?

EG: Red skewing to yellow, or magenta, will gravely shift the resulting brightness in a completely non-uniform manner when compared to the identical curve applied to blues, which would skew in a completely different manner and derive completely different brightness / luminance. Even with respect to near identical light mixtures, the skews will cleave toward rather different notions of brightness / luminance.

Thanks for your answer. That’s much appreciated. Yes, I am pretty fond of this idea. I’m quite sure our studio (and others) would love to have a look library to dig from.

If I’m being honest, I’m struggling a bit to grasp the scope of the VWG. I have always thought (since it was a major version update) that “every option was on the table” (as it has been said a couple of times). Or is it more like fixes and updates of the current system ?

Chris

I think it’s true that the group can consider every option on the table, but that the final delivery shouldn’t be every option on the table. We need to deliver the simplest system that fixes the issues and meets the requirements.

1 Like

The benefit of a DRT that is not too aggressive is that it is easier to work under, and tweak the look with LMTs. Also, by providing many rendering options we are also showing that as a group, we are unable to decide what we think is the best which is not necessarily a great signal. It also increases management complexity.

Thanks guys, that’s really appreciated.

One rendering solution, not “too aggressive”, with maybe a couple of LMTs could be a nice “demo” of the system’s possibilities. As you already know, our studio is quite fond of very saturated images, which might not be suitable for other projects (hence the proposal for different looks available, including one by default).

There is a video about RenderMan 24 and I was really pleased to see to see the following “Look” feature implemented :

Chris

I’d be happy to upload all my CG examples with a B&W version. Is there a “proper” way to desaturate an image ? Is it just saturation at 0 in Nuke ? I kinda remember there was a bit of debate when we did this sequence on Happy Feet 2 :

So I prefer to ask before converting all my examples. Thanks !

You would ideally use the weights of your working space, e.g. ACEScg, instead of the default BT.709 of Nuke desaturation node.

Thanks Thomas. I have done a quick test to compare Rec.709 weights compared to ACEScg weights to check the differences.

With the ‘Saturation’ node in Nuke :

With Jed’s Saturation node :

However, there is something that would be worth clarifying is possible.

In Natron Documentation, the ACEScg weights are listed as :

ACES AP1 (acesap1): Use ACES AP1 (0.2722287168r + 0.6740817658g + 0.0536895174b).

And @jedsmith saturation node is using :

ACES AP1 (acesap1): Use ACES AP1 (0.26806405r + 0.67246455g + 0.05947147b).

I’d be interested to know which ones are correct before converting my frames.

Many thanks,
Chris

1 Like

import colour

print(colour. RGB_luminance_equation(colour.RGB_COLOURSPACES[‘ACEScg’].primaries, colour.RGB_COLOURSPACES[‘ACEScg’].whitepoint))

Y = 0.2722287167809146(R) + 0.674081765
8111483(G) + 0.05368951740793704(B)

After some discussion, I believe the luminance weights for ACEScg in Natron are correct.

For posterity:
To calculate luminance weights for some RGB colorspace, one would calculate an RGB to XYZ matrix using XYZ Scaling as the chromatic adaptation method, and then take the middle row of that conversion matrix.

For example for converting ACEScg to XYZ E w/ XYZ Scaling CAT, the matrix would be

0.695383 0.140665 0.163951 
0.272229 0.674082 0.0536895 
-0.00552588 0.00402521 1.0015

(calculated using my GamutConvert tool)

This yields a luminance weighting of 0.272229 0.674082 0.0536895 (rounded to 6 digits of precision).

I’ve pushed a fix to my Saturation tool to reflect this.

As I was typing, Thomas has confirmed my hypothesis. Further trust this is the right answer!

1 Like

Hello again,

I have uploaded twenty exr files in B&W using the latest version of the saturation node from Jed with the following options :

image

The exr files have the following characteristics :

  • Encoded as ACES - ACES2065-1 with proper metadata (ACES compliant EXR).
  • Full HD (1920*1080) with correct metadata (dataWindow and displayWindow being the same : 0,0,1919,1079 to avoid any CTL crash).
  • To avoid any ambiguity, there are two suffixes (‘lin_ap0’ for the colourspace and ‘BW’ for the version).

Some of these exr are more interested than others. But I thought it would be better to convert/upload all of them to be safe. It has been a very interesting “exercise”. A couple of examples jumped out to me immediately.

The loss of tonality using ACEScg primaries on the spheres is quite interesting :

I was pretty much pleased by the shaping here :

Same thing with my light sabers using ACEScg primaries :

This reminds me of the exposure sweeps I did back in February :

Same thing here :

It is just amazing how colour affects our visual perception :

And our little stick boy using ACEScg primaries :

With a nice shaping/tonality in its B&W version :

I used Jed’s Output Transform Nuke implementation. It is a perfect match to the CTL code and it is easier for me to generate frames. I hope that’s okay. I am wondering if we could use these “luminance” tests as a ground truth for tonality when we’ll switch back to their colour versions.

Hope it helps a bit,
Chris