Inverse DRT issues

[antonmeleshkevich]

Hi! I get this when I try to inverse HDR DRTs. Looks like it turns high saturated colors into 0 in linear gamma.

And here is another thing, I've already asked about. But I'm not sure I understood your answer right. Is this expected and correct behavior? It is Inverse 1886 and then back to 1886. All the colors look different, even those that are low saturated.

P.S. I've added OpenDRT into built-in Resolve ACES :) They've made it possible now to add custom IDT and ODT based on DCTL.

[jedypod]

Thanks for the testing! First a disclaimer. I think I've probably mentioned it before, but the OpenDRT design is not a good one if an accurate inverse transform is important for your workflows. If you need a perfect inverse, a per-channel display transform will give you a much better result.

Second:

Looks like it turns high saturated colors into 0 in linear gamma.

I am not able to reproduce this. Is your input linear encoding or ACEScct encoding like you have set in the input curve?

Inverse 1886 and then back to 1886.

Yeah that looks about right. The forward transform will not inverse exactly for the following reasons:

1. All input chromaticities within an ACEScg gamut volume will not be mapped into the Rec.709 output display gamut volume. That is, some values will clip.
2. The weighted vector norm does not have an analytical inverse (or at least not one that I have been able to find yet). This results in the chroma compression not being inverted 100% correctly. The higher the chroma value the less accurately it inverses, especially around blues and yellows.
3. It's worth noting that a nice looking image rendering and a perfect inverse are goals which are at odds with each other and must be compromised.

Here is what I'm seeing with the latest release:

I've added OpenDRT into built-in Resolve ACES :)

Hey that's cool! :D

[antonmeleshkevich]

If you need a perfect inverse, a per-channel display transform will give you a much better result.

Thanks!

I am not able to reproduce this. Is your input linear encoding or ACEScct encoding like you have set in the input curve?

Input is just the image itself with no transforms. I'm still getting the same artifacts for unknown reason. Looks like there is something else applied in your screenshots. Maybe this is where the difference comes from?

The first two screenshots are inverse, when it is in the first node and when it is in the last (second) node.

And this is HDR preset to ACEScct with the latest OpenDRT (and its library file) version.

By the way, isn't it a good idea to rename ACEScg primaries to AP1 in the list? And probably ACES to AP0? I'm administrating a Russian colorists community in Telegram with about 738 members in it's chat and with ~1300 subscribers in our public group. And I often post something about OpenDRT and its Look tools to the chat. And there are people who use OpenDRT. So wouldn't it be more clear for not developers and testers, but also the artists and colorists to choose from a bit more standardized names for the primaries?