Notice of Meeting - ACES Gamut Mapping VWG - Meeting #30 - 9/24/2020

rrodriguez · September 18, 2020, 5:07pm

ACES Gamut Mapping VWG Meeting #30

Thursday, September 24, 2020
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

Thomas_Mansencal · September 23, 2020, 10:24am

Something to discuss about for the next meeting @matthias.scharfenber, @carolalynn and @nick:

So here what you see is 36*5 swatches of Filmlight E Gamut converted to ACEScg and gamut mapped through our operator at default values, and stacked against them the same swatches but with the exponent varying between 1 and 2 for each row. The whole image goes through the sRGB ODT.

The takeaway is that there are only minor practical differences between the output which leads me to the following point: If we are happy about the threshold and the limits, what will we be asking the users to test?

It would be worth looking at the image on a WGC display.

Colab Notebook here: https://colab.research.google.com/drive/1Lm5WpwHKNsxbNIkRyYZ_FbeyuQWqIU-j?usp=sharing

Nuke script to compare the images:

set cut_paste_input [stack 0]
version 12.1 v1
Read {
 inputs 0
 file_type exr
 file /Users/kelsolaar/Downloads/swatches_test_ACEScg.exr
 format "36 5 0 0 36 5 1 "
 origset true
 version 5
 name Read1
 selected true
 xpos -286
 ypos -38
}
clone node1518cdc00|Reformat|52308 Reformat {
 type "to box"
 box_width 1024
 filter Impulse
 name Reformat
 selected true
 xpos -286
 ypos 43
}
set C518cdc00 [stack 0]
set N518cdc00 [stack 0]
Grade {
 white 0
 white_clamp true
 name Grade
 selected true
 xpos -457
 ypos 43
}
Grid {
 number {36 5}
 size {8 8}
 name Grid
 selected true
 xpos -457
 ypos 67
}
Invert {
 name Invert
 selected true
 xpos -457
 ypos 87
}
Transform {
 scale 1.0075
 center {512 71}
 filter Impulse
 name Transform1
 selected true
 xpos -457
 ypos 119
}
push $N518cdc00
Shuffle2 {
 inputs 2
 fromInput1 {{0} B A}
 fromInput2 {{1} B A}
 in2 rgba
 mappings "4 rgba.red 0 0 rgba.red 0 0 rgba.green 0 1 rgba.green 0 1 rgba.blue 0 2 rgba.blue 0 2 rgba.red 1 0 rgba.alpha 0 3"
 name Shuffle
 selected true
 xpos -286
 ypos 119
}
Premult {
 name Premult
 selected true
 xpos -286
 ypos 143
}
Read {
 inputs 0
 file_type exr
 file /Users/kelsolaar/Downloads/swatches_reference_ACEScg.exr
 format "36 5 0 0 36 5 1 "
 origset true
 version 3
 name Read2
 selected true
 xpos -176
 ypos -38
}
clone $C518cdc00 {
 xpos -176
 ypos 43
 selected true
}
Merge2 {
 inputs 2
 name Merge
 selected true
 xpos -176
 ypos 143
}
set N518a5400 [stack 0]
Write {
 file /Users/kelsolaar/Downloads/swatches_ACEScg_Rec2020_ST2084_4000.png
 colorspace "Output - Rec.2020 ST2084 (4000 nits)"
 file_type png
 checkHashOnRead false
 version 6
 name Write2
 selected true
 xpos -78
 ypos 186
}
push $N518a5400
Viewer {
 frame_range 1-100
 viewerProcess "Rec.2020 ST2084 4000 nits (ACES)"
 name Viewer1
 selected true
 xpos -176
 ypos 233
}
push $N518a5400
Write {
 file /Users/kelsolaar/Downloads/swatches_ACEScg_sRGB.png
 colorspace "Output - sRGB"
 file_type png
 checkHashOnRead false
 version 6
 name Write1
 selected true
 xpos -176
 ypos 182
}
push $N518a5400
Write {
 file /Users/kelsolaar/Downloads/swatches_ACEScg_P3_ST2084_108.png
 colorspace "Output - P3D65 ST2084 (108 nits)"
 file_type png
 checkHashOnRead false
 version 6
 name Write3
 selected true
 xpos 12
 ypos 187
}

Cheers,

Thomas

nick · September 23, 2020, 11:49am

Thanks @Thomas_Mansencal. Very useful research, as ever.

However, I’m not sure that stripe is sufficiently sensitively picking up the effect of the gamut compressor. Toggling the gamut compressor on and off in Nuke on the ACEScg (from E-Gamut) strip has no perceptible effect on anything but the three most saturated blue bands, when using the Rec.709 ODT.

If you switch to the ST.2084 1000 nit ODT (I’m only viewing on an SDR display though) the effect of the gamut mapper is much more noticeable, as is the effect of changing the power between 1 and 2.

When looking at our sample images (I’ve tried Fabian’s nightclub scene, Carol’s still life and “Red Christmas”) varying the power between 1 and 2 has a very noticeable effect on all the images.

TooDee · September 23, 2020, 4:10pm

Hi,

some weeks back I listened to two meetings and contacted also Carol.
I got finally some time to play around with the GamutCompress.gizmo that I downloaded from the link in the dropbox paper after the meeting #28. I know I jump ahead because I read that the testing period didn’t even start yet.

But anyway I wanted to share my first test results together with some questions.

I have a Alexa-Mini camera clip with a car headlight. I can’t share the whole image but the important part I can. We are often running into problems in car head- and tail-lights, because of the high and often clipped values in camera.

Here are seven copped and scaled up images of the same headlight.
I read the ProRes4444 .mov directly in Nuke 12.2v2. (ACES 1.1)

My first question is:
I am asking myself, what should the gamut compress node achieve?
Get rid of ugly artifacts only or make the image already prettier?
For me I would say make the image overall better.

As we often compare Resolve standard vs. ACES in grading at the beginning of a project, so the main comparison that I would make is 01:ACES/Rec.709 vs. 07:Alexa LogC2Rec709, This is anyway most likely what I would have seen on set.

So the comparison that I did, is to test, how close can image 01 come to image 07 or can the result get even better?

Here are my results, followed by a little text what I did and which images I compared and why. I hope this is understandable for you to read.

01:
Nuke ACES Alexa IDT —> Rec.709
- which shows ugly magenta pixels and a very hard edge (which is seen here even stronger by the upscaling “impulse” of the image and have the minus green values).

07:
Nuke Default 3D-Lut LogC2Rec709
- softer, but is this actually looking already good enough?

05:
Nuke ACES Alexa IDT
Gamut Compress with the default values
—> Rec.709
- similar to 07, but stronger because of the different tone-mapping of the RRT I guess?

06:
Nuke ACES Alexa IDT
Gamut Compress with the custom values
threshold: 0.601333 0.521333 0.851333
power: 1.0
cyan: 0.55
magenta: 1.0
yellow: 0.312
—> Rec.709
- a result that I like a lot, because it gets me the closest to and an even a better result than 03!

03:
Nuke ACES Alexa IDT
LMT - Academy Highlight Fix (applied as a simple ColorMatrix node in AP1)
—> Rec.709
-Up to now or go-to fix, but it often alters too many other colors too, workaround is to mask the areas only instead of applying it to the whole image

04:
Nuke ACES Alexa IDT
ACEScg-ACES
LMT - Academy Highlight Fix (applied as a simple ColorMatrix node in AP0)
ACES-ACEScg
—> Rec.709
- Question: should a LMT not always be applied in AP0? How is Resolve doing this internally? working space ACEScct–ACES—LMT-Fix–ACES—ACEScct—grading?

02:
Nuke ACES Alexa IDT
ACEScg–ACES (just for the nuke-curve tool to check)
—> Rec.709
- I wanted to see if this changes the number results a lot or not and it doesn’t

Here is also a PDF with the images:
08_01-07_Headlamp_crop_scaled_NK12_2v2.pdf (3.6 MB)

I hope this test is useful and hopefully not really a gamut problem in the first place and only a problem of high scene linear values.

Best regards

Daniel

Thomas_Mansencal · September 23, 2020, 7:32pm

Yes, which raises the point of how we want people to test the operator if the effect is not really noticeable on standard monitors, it will reduce our panel size dramatically because I don’t know if a lot of people are equipped with HDR displays.

For completion:

P3 ST2084 108Nits

BT2020 ST2084 4000Nits

Cheers,

Thomas

sdyer · September 23, 2020, 7:44pm

@TooDee, thanks for doing some testing…

In theory, yes. But the conversion to-from ACES2065-1 can be enclosed in the LMT for convenenience or compatibility in a particular workflow. The important thing is that the same chain of operations are followed.

Just a note about the LMT-Highlight-Fix matrix: that was designed to be applied to AP0 directly. That being said, if someone likes it applied in AP1, I suppose that’s fine, as long as it’s clear that that’s where it’s applied.

I believe that’s the idea, yes. However, if you apply the LMT to a clip via the contextual menu in the bin or gallery page, then it applies it after the IDT but before any other conversions (i.e. on ACES2065-1 as intended). If you apply in the node graph, it is important to make sure you prepend and append appropriate color transforms from the working space to ACES2065-1 and back.

nick · September 23, 2020, 8:48pm

That’s only with the strip you need to switch to ST.2084 to see the effect. With the images a change of exponent is immediately obvious with an SDR ODT.

Thomas_Mansencal · September 23, 2020, 9:05pm

Right, I thought your last paragraph was alluding to the HDR ODTs when you mentioned the test images. I won’t have time to do it but it would be interesting to prepare some contact sheets.

Thomas_Mansencal · September 24, 2020, 8:40am

It is indeed more visible on images where there is much more variety in term of hue and chroma compared to the stripes:

This really becomes subjective though!

TooDee · September 26, 2020, 9:53am

Hi Nick,

I haven’t tired the gamut compressor in Resolve yet, only in Nuke, but I will soon.
But with a MBP 2018 and newer and the iMac Pro/iMac2020 you can see at least a “bit” of HDR directly in Resolve on the UI-display when you are running OS Catalina if you don’t have a real HDR screen at hand.

I found this out by accident earlier this year when I started to learn about HDR. Sadly Nuke is not supported yet as it seems.

Best regards,

Daniel

TooDee · September 26, 2020, 10:50am

Thanks Scott for the explanations. These were very helpful to me.

I was listening again to the last meeting.

I am very happy to hear that it is time to push out the gamut compressor to a bigger audience soon.
I am a “part” of that audience who use ACES only a part of a software like in Resolve/Flame/Nuke. Only in Nuke I can choose between ACES and another OCIO config. But for “me” as a user this is basically the same, because from a user perspective it does the same.

At least for me I needed to test the gamut compressor first on footage that I had trouble with in the past. That’s why I did this weeks test on the Alexa camera clip that I posted. And there I also tired to write down what kind of questions might come up when other people are asked to test the gamut compressor.

After some days of thinking here are some points to the meeting that I did not vocalize on the spot:

Please don’t hand out a baked out 3D-LUT, because it will be used in the same way as the inverse ODT in too many cases where it shouldn’t be used.
Anyway I guess the biggest audience that tries out ACES as a new workflow will be on Resolve and they are forced into Blackmagic’s implementation with the working space ACEScct unless they build their own color management and in either case they don’t need a 3D-LUT.
Without altering any numbers in the gamut compressor that I found in my example is that I am coming close to the Alexa 3D-LUT, so this should be the minimum that it has to achieve. In an ACES pipeline I should never see any kind of real breakups. So in the area of IDTs or converting from AP0 to AP1 the gamut compressor is “only” a bug fix for me. In Resolve the gamut compressor should be applied at the moment only in the bin and there you don’t have access to alter any values.
I needed to dial on nearly all knobs to get a more pleasant result, so a gamut compressor as a “tool” needs as many knobs as necessary to get there. In a case where this would alter other unwanted parts of the image as well I would simply mask them. In Resolve I would apply this “tool” in the node graph and there I have access to change the default values.

I am looking forward to check out the gamut compressor on more occasions soon. I did not really try it in Resolve for myself yet and I am looking forward to see what happens when I change the ODT in Resolve from Rec.709/sRGB to ST-2084 (1.000 Nits P3D65 lim.) on my MBP screen that can show me at least something around 500 Nits.

Best regards

Daniel

carolalynn · September 28, 2020, 7:32pm

Meetin Recap:

Two groups for testing: @joseph suggests reaching out to high-end industry Color Scientists etc. to make sure they are aware of our progress
Second group: hand picked colorists/compositors given resolve/nuke/baselight setups
Tests will need to be explicit to address concerns about whether operations work as expected instead of subjective feelings about how it “looks”
We should hide all values other than the power compression in order to reduce variables in testing
@carolalynn and @Pablo_Garcia will review @Thomas_Mansencal’s test ramps on HDR monitors
Possibility of taking a break in weekly meetings was brought up - outcome TBD - stay tuned for updates!

Recording / Transcript

Pablo_Garcia · September 30, 2020, 4:31pm

Hi All. I’ve uploaded in the Dropbox folder my reports of the test files (ramps and others) using the power value of 1 and 2 as suggested by @nick. As reported by Nick and @Thomas_Mansencal in SDR is barely noticeable but in HDR it is quite noticeable in WFM and visually (HDR reference monitor). I’ve used PQ 1000nit 2020 as OT (ACES 1.1). You’ll find screengrabs from Tektronix WFM with screengrab of the DCTL settings (all default, only changing the power between values 1 and 2).