Gamut Compression - Checking In!

  1. Should VFX Pulls have the gamut compression baked in?

I don’t think so, not by convention. Agreed that not baking in the gamut compression by default would increase complexity for VFX and finishing, but… life is complex.

Baking in the reference gamut compression would also necessitate immediately inverting the compression if one wanted to use the parametric form instead (or not use compression at all, obviously). If the reference compression were baked into the view transform stack, it could be losslessly bypassed with systems like OCIO, where prepending an inverse reference gamut compression transform just prior to an “always on” forward reference gamut compression transform would optimize out to a no-op; whereas baking the reference gamut compression into a plate would “break concatenation”, so to speak.

  1. Should EXRs or other scene-referred media with the gamut compression “baked in” be called something other than AP0?

I think so. I was thinking AP0’ (“Aye-pee-oh prime”), maybe? (To me, AP2 implies an alternate set of primaries.)

I don’t really agree that having a canonical name for the gamut-compressed AP0 image state would increase conceptual complexity any more than potentially having both AP0 and gamut-compressed AP0 plates on a show. In fact, I feel not having a canonical, universally agreed-upon name to differentiate the image states would drastically increase complexity + confusion. Whether or not the name is used in practice is one thing, but I think it would be a mistake not to define shorthand that can be used verbally and visually in diagrams.

Also – and correct me if I’m wrong – I don’t think AMF has a means to indicate whether the gamut compression is baked into a plate, or if it’s part of the viewing transform stack. I could see studios using EXR metadata (internally) to indicate whether compression has been baked in to a plate, regardless of whether or not such metadata is allowed for ACES2065-1 deliverables.

  1. Is the default of “always on” in the viewing pipeline too heavy handed?

I think it depends on who’s doing the viewing, and when. “Always on” might be more appropriate for DITs and dailies grades, but I can imagine Finishing might feel differently.

AMF has an applied flag, so once AMF is universally adopted it will be possible to indicate whether the Reference Gamut Compression needs to be applied or is already baked in.

2 Likes

It does :slight_smile: there is an “applied” flag in the tag that is designed for this purpose.

1 Like

The operator does not change the image state though, the image stays in the scene-referred state. Unless we want to define a state for every single LMT out there, I don’t think it is feasible nor practical. To push the reasoning, a LMT that changes saturation does some form of gamut mapping or gamut conversion, in that case, we would not really define a new name for that “state” and the infinity of “states” that can exist along the saturation path.

1 Like

Damn good point. Hmm. Alright, you’ve won me over.

I feel better about not having a name for “gamut-compressed AP0”, now that I realize AMF is, in fact, fully capable of describing both what’s already been applied to the plate, as well as the rest of the transforms in the viewing stack. Of course it does. That’s an aspect of AMF I had failed to appreciate, and I’m now thinking a bit differently about all this. Should’ve done my homework.

AMF is totally sufficient for communicating what needs communicating – naming the “states” between LMTs is redundant at best, and really only provides room for error.

I’ve seen the light. I’m a changed man. Carry on :slight_smile:

1 Like

Ahahaha! Thank you for the questions and opinions, this is why we made this post - to check in! Appreciate you, @zachlewis!

1 Like

I’ve read about AMF here on ACES Central, but I work in ACES as a colorist, and I’ve never ever faced it in my work. And I’ve never seen anything related in Resolve. Could you please tell a bit about how it is implemented from a user point of view?
I’ve never ever heard anything about AMF from any colorist I know. And of course there is nothing about it in Resolve manual.
Or it’s just not supported in Resolve?

AMF is not currently supported in Resolve. It is not yet supported in many places, but the major software developers are all working on it, so hopefully it will come soon.

We won’t see its full value until it is available in every ACES supporting application.

1 Like

I found RGC in Resolve 17.4 clips values below 0. Is this made on purpose or this is just a one more thing that is broken in Resolve?

Jed, Nick and Paul Dore versions all preserve negative values.

I believe Resolve clamps negative values on input although I have no proof of this. IMO, Resolve is good at what it does but there is still definitely a lot of room for improvement. Is there anybody on this forum who has some pull at BlackMagic to get the most annoying things fixed?

I’ve posted this bug in the thread I created on their forum, where I decided to post all the color management and color tools bugs I know. Not all at once of course, because that would took a day or two.

1 Like

They didn’t fix this with the latest update, but they’ve finally fixed another bug with Canon Cinema Gamut wrong white point I’ve reported in the same thread right in the next message. So they definitely have seen the previous message showing the bug with RGC.

I have verified that this still occurs in 17.4.1. I will check 17.4.2 as soon as I get a chance, and follow up with the Resolve team.

1 Like

Hi all,

We have been working on updates to the User Guide over the last few weeks. We’d be grateful if the group could take a look and comment / provide feedback here.

3 Likes

It’s still there in 17.4.2 build 9 unfortunately.

As well as applying calibration LUT before ODT (to AP0 Linear) during playback and turned on “Hide UI overlays” option which removes latency from Decklink card. This bug is there I guess since ACES was added into Resolve.

This has been fixed and the fix will appear in the next release of Resolve. Either 17.4.3 or 17.5 which ever comes first. Thanks Anton for pointing this out.

5 Likes

Hi @michaelch , super good news. While you’re here, can you tell us whether the Windows version of Resolve will ever support HDR previewer same as the Mac version? Right now, I have to tell people that they have to place hacked system DLLs in Resolve folder to force the creation of a PQ swapchain whenever they want to preview PQ content in Resolve. Of course, this breaks non-PQ workflows but it’s the best I got.

To all, sorry for hijacking the thread.

Is there a chance to see ACEScg in “color science” setting?
And if it will be added some day, then the current bug with wrong OOTF in HDR palette could probably get higher priority for fixing? For now seems like there is hidden unnecessary OOTF is applied in HDR palette when timeline color space is set to Linear. So conversion from Linear to Linear that is used in Global wheel is incorrect now.

I found another bug in Resolve RGC implementation. It doesn’t work when custom DCTL IDT is used. I tried it with custom Alexa AWG Linear IDT and those high dynamic range carousel images, that are in AWG Linear, and turning on RGC has no effect on the image.

This bug is fixed now (v17.4.3). Thanks!

Hope this one will be fixed soon as well.