Artifacts in ODT shadows mapping

Tags: #<Tag:0x00007f0e3d039308>

I noticed one thing with all ODT (rec709 mainly) in the shadows, that normally can’t be noticed, but in some dark scenes and on OLED displays it is definitely visible. And also if somebody calibrate their low contrast (for example 400:1) IPS display to 1886, this is also noticeable. And I saw LG TV in my local store, that has measured contrast ratio 400:1 and 1886 “gamma” in its color menu, that lifts shadows. So this thing can be visible in real life situations.
Unfortunately I can’t post the problem shots I’m currently working on, but here is the demonstration of an artifact with exactly the same nature.

Colorful objects, if they are dark enough somewhere on its area, have clipping in the lower end of one of the channels. To make it more visible on any display I added simple gamma operation after rec709 ODT. This artifact is also present in default LUTs and Resolve Color Space Transform effect with its mapper, but it is barely visible there and not always easy to reproduce the artifact at all.
I tried various methods to soft clip it before ODT with no luck. I tried to modify new gamut compress DCTL settings (by the way, the only DCTL that works in resolve 17 is that have only one parameter “power” exposed to the user, and those that are in @jedsmith github can’t be open), I tried to soft clip RGB curves in different color spaces and encoding curves, tried to soft clip S channel in HSL and HSV. Nothing helps.

So I have 3 questions.

  1. Could you please advise me what should I do to fix this before ODT? I can clip or soft clip gray scale and not let it touch 0 value, but not the colors. They always clip, because it happens inside ODT. Is there a way to soft clip it without being high skilled programmer?
  2. Is there a chance that in ACES 2.0 ODT will be some mapping not only for out of gamut colors in the upper end, but for the lower end, instead of clipping?
  3. Probably I misunderstand everything about how gamut compression works. And there is no way to avoid it if we want to be able to fill the whole gamut of a target display. If so, could you please tell me it? :slight_smile:

I really love to work in ACES because of its amazing gamut compressor (from camera to AP1). And this is one of the main reasons why I switched to ACES.
But ODT is the thing I always fight for hours. I can make it match k1s1 curve in the highlights. This is not a big deal. But because of the artifact in shadows I have to spend a lot of time for tracking shadows for the artifacts or to use my custom ACEScct-to-ARRIrec709 LUT. It’s ok and smooth, but it’s only for rec709. And for DCP I have to add inverse rec709ODT to DCDM ACES transform.

And thanks a million to @jedsmith @nick and others, who took part in creating the best gamut compressor I’ve ever seen! And to @Paul_Dore for ACES 1.2 OFX with ability to export DCTL, this really helps to work in ACES without resolve native buggy ACES implementation.

If you go back through the Git history, there was a commit which fixed the syntax for Resolve 17 compatibility, and happened prior to the parameters becoming locked.

1 Like

It’s difficult to tell without testing if that is gamut clipping or shadow clipping, or a combination of both.

The ACES SDR Output Transforms clip all input values below 0.02 in scene-linear. When the image is rendered out to an integer data format, the differences won’t be very noticeable, but if you are using the ACES Output Transform in a DCC package and “Gammaing up” to check blacks, the clipping becomes very noticeable obvious and annoying. (I run into this on an almost daily basis in a VFX Compositing context).

If it is shadow clipping issue, your observations here sound like a good argument for mapping 0.0 to 0.0 in the display rendering transform rather than the approach previously taken.

Thanks for the flag on that - looks like a simple fix. I’m gonna go back and change those previous releases as well so they work for people.

1 Like

Thank you! It works!

@jedsmith Thank you for the detailed answer! I tried to do the same with stills from different movies from shotdeck.com. Some of them have the same artifacts, but most - don’t. What I usually see is the compressing of the lower end of one of the channels that falls into the shadows. And I also checked Avengers Endgame, that was graded in ACES (according to imdb). There is also I couldn’t find these artifacts. But probably they used their own custom ODT, I don’t know.

And this appears not because of color correction, but just with .ari (or any other) files directly to ACES pipeline without any color modification. Even with the default RAW settings.
It looks so unfamiliar even on waveform analyzer. I used to see soft clipping whenever I touch the lower end. What could be your recommendation? Should I just ignore it?

Just coming back to say that this particular example is being caused by the cyan on the helicopter being out of the BT.709 gamut.

Using this file from the Arri camera sample footage:
ALEXA 65/ALEXA65_ARRIRAW_OpenGate_6560x3100/A005R51F/ari/A005C031_160120_R51F.0002427.ari

Here’s the a crop of the area in question rendered using the ACES Rec.709 Output Transform:

And here’s the same area rendered using the P3D65 ACES Output Transform (notice that the blue channel is now not 0.0 in the sampled area).

And here’s a chromaticity plot of the above image prior to display rendering:


The triangle pictured is the BT.709 gamut.

1 Like

Thank you!
But seems like even if I soft clip that, ODT introduces it again.

  1. AP1 ACEScct converted to Rec709 primaries and Rec709 OETF. W Point nodes are for converting white point, because Resolve doesn’t do it automatically. And in the end I added gamma operation to make everything brighter. Grayed out darker nodes are bypassed.
    We can see the out-of-gamut clipping. Triangle on the analyzer is for rec709 gamut.

  2. I soft clip out-of-gamut colors back to Rec709 gamut. Artifacts are disappeared.

  3. Rec709 primaries and Rec709 OETF image goes back to AP1 ACEScct. And then to ACES Rec709 ODT. The artifacts are here again.


    (Also you can notice clipped higlights. This is because of how soft clip in Resolve works. So the highlights are clipped at 100 nit in rec709 OETF)

I used CAT02 for white point conversion. Not sure if this is correct. But with Bradford artifacts are also there. So this probably isn’t the reason.