Revisiting RCM, ACES & CST Workflow

Great stuff guys. I’ve been using color-managed workflows for a couple years now (mostly ACES, some more custom). I’ve really enjoyed the consistency it’s brought to my work, but there are definitely situations where I want to get in and make adjustments either before or after the input and output transforms.

In order to gain that flexibility, I’ve started using a CST based node setup instead of RCM or project-wide ACES. The issue there, as Robbie mentioned, is having to change input and output transforms at the individual clip or group level. That’s a lot of work…

Well, as it turns out, that’s the perfect use for Shared Nodes. In an ACES workflow, I’ll have a shared CST node for each type of camera in the project, applying the appropriate ACES IDT transform to ACEScct. Then, I’ll have ONE shared CST node applying the ACES OT at the timeline level. Changes to any of these shared nodes ripple instantly across the project, including just disabling or enabling them. This setup gives me the flexibility to do pre- and post-transform trims if I need them (as Patrick was talking about), with only a handful of shared CST nodes to manage if I need to change anything in the pipeline.

now that is an excellent tip! Man I wish I had thought of that! 🙂 Thanks Peder!

Great dialogue, guys. Thanx! You answered my fundamental question….why even use a CST in a color managed workflow? I get that, now. A lot of my conundrum, perhaps, was centered around trying to understand the use of a timeline color space; and, why would a timeline colorspace differ from an output color space? I tend to work like Dan does, building my own managed colorspace. Dan’s latest video about rolling his own ACES was very informative. Patrick is on to my original dilemma…how to correct a poorly exposed original image before it hits the timeline colorspace. When a CST transform isn’t available, I have to use a LUT, but, the LUT clips the hi-lights. The issue is that it really isn’t a good idea to use a CST inside of a color managed workflow. The other issue is in learning to work in HDR with YRGB defaulting to REC709. But, that ‘s a separate issue. Patrick, in answering my original question, was too polite to say, “WHY are you using a CST in RCM?” I’ll admit to getting a little lost in the technology, good point. Your discussion confirms where my rather circuitous and convoluted thinking finally led to. It would be great if Resolve had the ability to map what is being set up… to confirm/validate data streams/workflows, yeah a warning message that says I just did something stupid…haha. So, thanx for following up with this discussion.

Thanks guys! Patrick can you explain how you use Filmconvert in the example you mentioned (to convert to cineon)? Cheer!

It was FilmConvert that gave me the idea of Cineon, since it tags Cineon-based camera profiles directly in the ‘Film Settings’ section (see the image I’ve grabbed).

https://uploads.disquscdn.com/ Now, FilmConvert then wants to move the image from the Cineon space into the selected film stock profile. If you instead use CST, you can use the manufacturer’s color space profile to map into your output color space and use the generic Cineon Input Gamma setting to map to your Output Gamma.

This allows you to keep your color profile of the camera without constantly fighting the heavy brightness transforms of those camera manufacturer LUTs. Plus, if the camera has 11+ stops of dynamic range, you can use Tone Mapping to help retain highlights without having to completely rebuild the image from scratch on each shot. In documentary workflows I’m finding this to be extremely efficient while also looking good.

Charles! We’re glad this helped you. Yeah, when I first read your question I did do a little head-shaking 🙂 But I also understand the problem in learning to tame these color-managed workflows – so I will never fault you for asking this question!