The Color Mangled Workflow – Modifying Look-Up Tables For Better Results

If I find myself in such a situation I usually try to reshape the curve before the transform, that way it’s reshaping the actual footage and not messing with a technically correct transform. That is particularly useful in ACES. If a “technically correct” transform isn’t needed then I’d do the gamma transform manually with a custom curve and leaving the CST gamma as is, that way you are not restricted to the cineon curve.

Either way, I usually drop a greyscale, put a CST node to transform it to the footage’s camera log and then apply the custom shaped transform to see of it’s a clean straight line with nice rolloff in the highlights and shadows or if I’m breaking the footage. Same thing with color gradients when developing looks but that is out of subject.

I also do my transforms at the very end of my chain so that everything else remains scene or camera referred.

Interesting. Thanks for the ideas.

Great tutorial, Patrick. Thanks

I’m the “anti-LUT” guy (unless a client points a gun at my head), but CST’s are very interesting and I have used them on occasion. But god help you if it’s 8-bit material.

I LOVE this idea and see no issue with it, especially when working with on documentary a “DSLR mirrorless “mystery” camera” scenario that you presented in your insight.

I’m confused why this wouldn’t work with HDR, as you’re simply telling Resolve that the input is cineon, NOT converting to cineon via the output curve option (which would break HDR). Essentially, applying a softer gamma curve (when compared to d-log) while still providing the appropriate chroma transform, correct? Seems like a great way to get a better starting point when the manufacturers provided transform isn’t looking good.

This is a topic that has long interested me. Where do I begin?

I cut my teeth relying on the SLog3/SGamut3.cine to 709 LUT from Sony, which they called “LC” for low contrast. They left it “low contrast” so as to be conservative and not clip out data. I would typically increase the contrast a bit in a node after that LUT, to taste. Those results were OK.

When this new CST tool was introduced, it took me a little while to get used to it.

I think the CST ResolveFX is great, and far superior to just using a manufacturer LUT, because it’s an implementation of the specification: it’s same math of the intended transforms, but not constrained by the resolution of the LUT, e.g. 33x33x33, etc. So you can take advantage of the documented technical transform, straight from the manufacturer, while still using Resolve’s 32-bit floating point image processing pipeline. In some circumstances, that will mean fewer artefacts and noise, etc., than if you had used the equivalent LUT.

There’s some weirdness with the CST, though.

At least for SLog3/SGamut3.cine footage, I’ve noticed that for the CST to be a useful tool, the tone mapping must be set to “simple,” at least if your output is in the SDR ballpark, like 2.4/Rec. 709 or 2.6/DCI P3.

If you take a greyscale ramp generator [inside a compound clip so that you can see it in the Color page] in a regular 2.4 / Rec. 709 timeline, throw the CST on with SLog3 back to 2.4, you’ll see that having the tone mapping set to “none” or “luminance mapping” produces utterly nonsensical results. Only “simple” gives you that perfect S-curve transfomation that you’d expect from SLog3 back to 2.4.

I assume that the CST was a kind of custom tool that was made bespoke for some high-end customers doing HDR grading early on, because for the longest time the explanation of the tone mapping for the gamma curves wasn’t documented. I just checked the 16.1.2 manual from December 2019, and was pleased to finally see the explanation on p. 2713 that “luminance mapping” is really only for tweaking HDR EOTFs. Without that knowledge, it was just a mysterious nonsensical option.

I won’t say who specifically, but I have seen an OFX developer trash the CST ResolveFX because they didn’t seem to understand how to use it, which, to be fair, was understandable since the documentation didn’t really exist there for a while. In a side-by-side demo with their OFX tool for gamma and gamut transforms, they showed the CST ResolveFX and literally left the tone mapping to “none,” apparently “proving” that the ResolveFX still just wasn’t good.

I think the CST ResolveFX is a really, really great tool, and is my current go-to method to get started with technical transforms. You can even have lots of fun bringing different log gammas from totally different brands of cameras into one single log curve so that you can apply similar workflows across those clips.

I’d love to see more on this topic. There’s a lot here.

Wouldn’t you want to be using two CST nodes for that workflow? One to move the DJI gamma to Cineon gamma, and then a second CST to go from the Cineon gamma to the display output space, in this case REC709 2.4 gamma.

Hi Patrick.
I love your curiosity on this, but I think you’re not doing what you think you’re doing. Happy to explain and discuss if you want to DM me.
Chris

I know – I am a little late to the party here.
Was wondering if D-log is based on Cineon that you are actually just using a similar gamma curve by using Cineon? I know that Arri Log-C works fine in Cineon and I have used it with V-log and even occasionally with s-log3. So to take this experiment further you could also use one of those choices in the CST as well. I guess creatively we work with hard fast rules and then break them and whatever looks and feels right is right.

That’s the spirit of this Insight. It’s about breaking the rules – but doing so with intent and only if it gets you someplace you want to go 😛

Chris – I missed your response from earlier this year. As I say in this Insight, it’s shared in the spirit of an ‘open beta’. Feel free to share your thoughts on this here in the comments. It’s a ‘safe space’ and will help everyone learn – and 18 months after publishing this I’m sure everyone’s thoughts on this workflow have evolved.