Wrapping up the Architecture VWG

Discussions - ACESNext VWG – Gamut Compression/Mapping
1

Hi all!

Well, the time has come… we are pretty much finished with the architecture deliverable for the gamut mapping group! A few things to wrap up:

  • If you haven’t had a chance, please take a look at the CTL deliverable. It’s been through several rounds of feedback now, but more is always welcome.
  • The Technical Documentation deliverable is still WIP - we’d very much appreciate any contributions, comments, etc. We are aiming for a mid-January delivery to the Academy, so if you need something to do over the holidays… :wink:

As always, @matthias.scharfenber, @nick and I are available for any questions or comments. It’s been a real pleasure to work with all the amazing minds that contributed to this group, there are too many of you to name, but you know who you are.

If all of this ending makes you super sad - have no fear! We’ll be ramping up the implementation working group in early 2021 - so keep an eye out :wink:

Safe and happy holidays!

8 Likes
2

Congratulations, guys – it’s been really interesting watching this come together, and I think you’ve arrived at a really elegant, user-friendly, seemingly magical fix for some serious ACES-1.x issues. The constellation of tools, ideas, notebooks, transcripts, and other ephemera are the icing on the cake.

Also, great job collecting representative samples of trouble images.

Did anyone ever figure out what’s going on with those pool ball shadows in that one image?

3

Hey guys,

congratulations for wrapping this up ! Tremendous effort.

@zachlewis Is this one of the latest mentions of the pool ball shadows, right ? I don’t recall this issue being solved, aside of it being a weird optical illusion…

Also, I think it is a very good call to call the CTL code “Gamut Compress”. I think it is more explicit and less misleading that the term “Gamut Mapping”.

I am currently reading the documentation and listening to the last meeting. I think you can add videos/animated gifs in a pdf using Adobe InDesign. I have never done it myself but I have been told that it was possible.

For me, I would love to see this gif in the documentation. I think it was very explicit to show what the Gamut Compress does. At least a similar gif without the Jed modified version (originally uploaded by @nick ).

alt_mapping
alt_mapping1440×1080 580 KB

And another image that was very helpful was the one from @matthias.scharfenber :
gamut_mapper

I’ll keep reading through documentation to see if any more ideas come up. I’m really looking forward to the implementation group. I think our studio would probably use a future ACES 1.3 OCIO Config with Gamut Compress activated all the time (please don’t quote me on that).

Anyway, a BIG thank you. I have learned a lot through this group !

Chris

1 Like
4

I will certainly look into it again, but my memory from last time I researched was that although it may be possible, the result is not universally compatible.

One of my tasks for today is to look at a non-animated version of that diagram.

Agreed on the polar diagram. Again if it is possible to create an animated version that would be ideal, but otherwise a before/after plot should make the point.

5

Definitely, thanks @nick ! A last minute thought just occurred to me.

Have we ever seen the algorithm’s effect in a 3d space ? Since gamuts are basically volumes, I wonder how a “gamut cartesian scale” would apply here ? Does it scale the volume homothetically (is that even a word) ?

Thanks,
Chris

6

Hey all,

happy new year and best wishes for 2021 !

I have a few questions regarding the Gamut Compress algorithm if you don’t mind. I’m not sure if I’m too late, too early or off-topic to be honest… :wink:

I have a done a series of tests on full CG animated footage to test the algorithm. Here is the test :

Here are some screenshots (in case of the video not working) :

test_gamut_compress_red
test_gamut_compress_red1915×1078 335 KB

test_gamut_compress_blue
test_gamut_compress_blue1918×1077 347 KB

I am using the side effect of the compress algorithm to display some very saturated values, acescg primaries in this case. I am overall satisfied with the result but I have a few questions specific to full CG footage. In the documentation, it is written about the distance limit :

The limit of distance from the achromatic axis that values will be compressed to the gamut boundary. The limit values have been chosen so that the encoding gamuts of all digital cinema cameras with official ACES IDTs(ARRI, RED, Canon, Sony, Panasonic) will compress to within AP1.

Would it be worth trying for full CG footage a different distance limit ? Since we don’t deal with cameras ? I’m just curious if I could set here AP1 limit distance.

Then about the compression limit, it is written that :

Percentage of the core gamut to protect. Derived from the boundary of the ColorChecker Classic 24 (as specified in ISO 17321-1) values in ACEScg.

In my test, would it be worth trying to derive from the boundary of the P3 gamut ?

I have no idea of what I’m writing makes sense or if it would be worth a shot but I’m curious to run this test if anyone could point at me in the right direction… I am anticipating some very saturated sequences with saturated neon lights at night and just want to be sure I have a solution when this happens.

Another thing I have noticed is the general increase of noise on CG footage after the use of the algorithm. I think it makes sense in a way : anti-aliasing is based on the ODT (with the posterized red) and since the algorithm “reveals” some data that was not perceptible before, it is not properly sampled.

I guess I’m just curious how will the algorithm will be implemented in the OCIO config ? An optional LMT ? And if we will be able to render/sample taking in account the GM effect. Maybe I’m just hacking too much the algorithm since it is not supposed to work this way… But I wanted to ask…

Update : found an old version of the algorithm with the possibility to calculate the distance limit based on different gamuts. That’s properly amazing ! Thanks guys !

test_gamut_compress_node

Hope some of this makes sense,
Chris

1 Like
7

You could find that a different limit would suit your purposes better, but it would not be the distance of the AP1 boundary. That would be a distance of 0, since the distance setting is “how far outside the AP1 boundary should I compress to the AP1 boundary”. That would therefore do nothing.

Again, you wouldn’t want to set it to protect thew whole of P3. You are wanting to compress values which are outside P3 to within it. Protecting P3 means “leave everything within P3 exactly where it is” and if you do that you are not making any space to squeeze the out of gamut values into.

8

Thank you ! That makes sense. If I do a small summary,

ACES gamut compress :
Values outside of AP1 (camera vendors) are compressed to AP1 while keeping a safe zone (CC24).

I did try to go from acescg to p3d65 with your blink script and the results are quite interesting to be honest. I’ll investigate some more !

Regards,
Chris