ACES 2.0 grading colorful lights

[shebbe (Shebanjah Klaasen)]

I’m almost afraid to bring this up again.. but now that Resolve 20 beta has been released with it’s implementation of ACES 2.0 I was playing around with it.

Especially since they’ve made a very nice ‘totally original’ tool for manipulating color that actually works quite nice and is color space aware.

I’m struggling to get a smooth colorful representation of blue light in the scene when working on the OT VWG frame 0075. When I compare my efforts against ACES 1.3 or other DRTs it’s a big difference.

The problem I have with ACES 2.0 is that to my eyes it’s built in gamut compression or some other mechanic always leaves a hard transition somewhere in the blue region that is seemingly impossible to bypass. The only solution is to grade it so that the entire area is the same range as the portion from before where the issue starts. Or move the entire area of colors away from the problematic region, like making it cyan. Adding a secondary ACES RGC in the mix only desaturates the region but the sub-optimal gradation can still be observed.

This issue is not present in ACES 1.3 (makes sense) or any of the other DRTs I tested of which some have compression built in and others don’t.

I had similar struggles with red lights, with ACES2.0 it would look too pinkish or orange couldn’t find a sweet spot. Green not tested.

It feels like the built in compressor is somehow not smooth enough, making it harder rather than easier for colorists to deal with images similar to the above, especially if the intent is to make colors ‘pop’. And given it’s always on at the final stage, could an LMT even solve this?

I recall one of the big goals of ACES has always been being able to reach the corners. Was this solely for the context of inverses, or also for grading? For the latter, it looks like you can but not something you may want.

I should note that my findings above are based on Rec.709 output only. I also compared 2.0 vs 1.3 in HDR P3 D65 1000nits and there the issue is almost non-existent. The brightest spot on the ceiling still felt slightly desaturated but I would see that as better matching SDR/HDR. The transition itself was smooth. Haven’t tested P3 SDR.

Happy to be proven wrong.

For anyone that wants to mimic my setup, I used manual management with timeline set to ACES (AP0/Lin) and output space Rec.709. The ChromaWarp node was used directly on the ACES linear input followed by the DRT setup in the next node(s).

[chuckyboilo (Charles Boileau)]

Thanks for the post. We are just about to start using ACES v2 at our facility and this obviously could be of some concern.

Curious to see what people @nick or @alexfry might have some insight on this. These images were obviously used for the WG.

Thanks for the post!

[shebbe (Shebanjah Klaasen)]

An anecdote to this:
I’m working on a project where they shot a scene with some colored tube lights in the background. We went from imo acceptable and aesthetic appearance and a nice look to the overall image, all the way back to “the LUT we saw on set” + contrast and saturation post LUT(DRT) .

I’m starting to wonder why I’m challenging myself and others at this point. Looks like I don’t even need ACES2.0 .

Gotta keep the client happy in the end!

[versalstudios]

I blame the YouTube generation

Btw are you talking technical or aesthetical issues in your first post? Imo ACES 2.0 renders the most aesthetic image in your comparison, with less plasticky saturation in the wrong spots. But this is of course just personal taste.

[chuckyboilo (Charles Boileau)]

So wait… In this example ACES 2.0 is the left side example?

[ChrisBrejon (Christophe Brejon)]

Hey Shebbe,

thanks for sharing those examples.

Have you by any chance tried to grade under openDRT 1.0.0 ? I would be curious to hear some feedback from you.

Your examples remind me of two examples shared in this forum (here and here). I think in both cases the suggested solution was a LMT.

@shebbe

I recall one of the big goals of ACES has always been being able to reach the corners. Was this solely for the context of inverses, or also for grading?

If memory serves, I think it was about logos (such as a red superhero one) and their invertibility.

Because of strong requirements such as hitting the display´s corners and invertibility, some compromises had to be made for the "rendering " of ACES 2.0. Also I don´t think I ever read smoothness in its design requirements (not in the dropbox at least).

Regards,
Chris

[shebbe (Shebanjah Klaasen)]

@versalstudios

Btw are you talking technical or aesthetical issues in your first post? Imo ACES 2.0 renders the most aesthetic image in your comparison, with less plasticky saturation in the wrong spots. But this is of course just personal taste.

I should have clarified more. I wasn’t trying to grade the whole shot to a finished look.
What I challenged myself with was solely: “How blue can I make the blue lights appear in SDR?”

I guess in a sense partially technical and partially aesthetical. I wanted it to still look smooth and somewhat similar to how it I experienced the intensity when viewing it in HDR. The issue I’m running into with ACES2.0 is that the gradation on the wooden ceiling from light source to it’s outer reach poses problems when pushed far towards Rec.709 blue. Once you’re in that area, sudden jumps in color occur by presumably the compression algorithm/threshold but I’m not sure. This problem is not observed with any of my other tests with various other DRTs including ACES1.0.

Example ACES2.0 no RGC with pushing blue

Yes you can mitigate this by compressing more but I feel you can only smoothen it out to the point where the problematic area is least saturated. In turn my efforts looked something like this.

Example ACES2.0 with RGC and more conservative blue placement.

@Christophe mentions the same issue I think in the examples linked in the above post.

I did another test by cheating a bit.

Example ACES2.0 RGC + smoothen Blue → convert to 709 → add blue sat.

That was more or less the amount of saturation I was trying to get out of it which was a lot easier with the other DRTs I tested.

I’m not sure if it’s the tools I’m using/how I’m using them or my own grading experience. Maybe it is possible to push it more under ACES2.0 with the right treatment. But if that’s the case I definitely feel that it takes much more effort compared to some other DRTs out there, ACES1.0 inclusive.

@chuckyboilo

So wait… In this example ACES 2.0 is the left side example?

No, the anecdote example were all graded shots from initial look to approved look, unrelated to ACES2.0. It was only to show how funny it was that the client was preferring the clipped and skewed look ‘from set’ because that’s what they saw and got attached to when someone made a quick framegrab to do a mockup with graphics on top.

@ChrisBrejon

Have you by any chance tried to grade under openDRT 1.0.0 ? I would be curious to hear some feedback from you.

That’s really cool, I didn’t know a new version was released. I just had a quick look and I think it’s very interesting in terms of options you have. Will definitely explore more for real grading projects.

In my very quick test on just the discussed image, it seems that the DRT has quite some bias to cyan for bright blue light, I had to reduce the exposure of that light quite a bit to be able to land it more in ‘blue blue’, but it looks nice and smooth.

[ChrisBrejon (Christophe Brejon)]

One thing that I have learned with the VWG is that it is impossible to please everybody with one single solution.

Several modules were exposed in openDRT 1.0.0 so users can design their own image formation.

For example, blue bar can be “tweaked” quite differently based on your needs and also you may notice that it is quite interesting to have these options available in the “DRT” itself rather than a “scene” grade.

Attached are a few examples playing with the module “hue shift” for the B channel.

I find the modularity of it quite interesting. Thanks !

[shebbe (Shebanjah Klaasen)]

@ChrisBrejon

One thing that I have learned with the VWG is that it is impossible to please everybody with one single solution.

I know the design and it’s imposed restrictions by various requirements have been really challenging. But it still strikes me as odd that in it’s current form it poses such an issue while a perhaps more simple DRT like DaVinci which does have inverses does not have these issues and neither does ACES 1.0. I just wonder if as a result the overall rendering difference between 1.0 and 2.0 is really a win in that regard.

But I haven’t given up yet. I did another attempt this time in combination with Jed’s ZoneGrade DCTL to lower “Exposure - H” to bring down the ‘hotspot’ to match the not so hot spot further out from the light source to remove the sudden jump. This helped tremendously but the downside is that the whole scene’s brightness is reduced including the interior lamps. I could mitigate this by masking only the blue hue and luma ranges but I feel that’s too specific already. I don’t think I have other cleaner tools that could do the job but I can see that what I wanted to achieve is possible.

@ChrisBrejon

Several modules were exposed in openDRT 1.0.0 so users can design their own image formation.

For example, blue bar can be “tweaked” quite differently based on your needs and also you may notice that it is quite interesting to have these options available in the “DRT” itself rather than a “scene” grade.

That’s what I liked about JP2944 and AgX as well. Having such control is really welcome if you’re not bound to an ACES workflow. It could be quite cool if a similar functioning tool is developed by the ACES team itself tuned to the ACES2.0 rendering that can be used as LMT rather than a perhaps few separate ones that only tackle a specific look or issue.

I must have missed something, where can these modules be found? I only downloaded the DRT itself but there are no such controls on the main DCTL?

[jedsmith]

@shebbe

where can these modules be found?

If you want access to all the controls you will need to use OpenDRT_v1.0.0_StickShift.dctl from the OpenDRT v1.0.0 Release. This gives you all the parameters and no presets. The DCTL user interface leaves a lot to be desired. It is not very suited to this level of control so I made the choice to expose only the presets by default so as not to overwhelm and confuse users. If you want to do full on look development I would probably recommend to use the Nuke node and then add a preset to the DCTL with what you come up with.