Resolve node tree based aces workflow

Hi all.
I’m sure this has been already discussed before but I can’t find it on the forum. Sorry if it’s a repetition.

I have a big job coming up and I’m planning the workflow I will commit to.

I usually work in resolve with a classic color managed aces workflow, so fully set up in the project settings.

I’m thinking about using a node based approach on this one here, so leaving the project unmanaged and getting in and out aces at node level.
I can see some real benefits on this but before commit to it I wanted to check with all of you the pros and cons of it. We’ll, mostly the cons.
Is there anything that can bite back on the long term?


Hi Orash,

please have a look at the answer from @nick in this thread: Going from ACES to original Blackmagic RAW Debayer?

It sounds to me that it is not the best idea to build your own pipeline inside Resolve.



Thanks Daniel!
Reading @steve reply seems the issue is in the bm camera transform.
Let’s say I have red or arri for the sake of argument, in that case node or project management is it the same?
I will add that I am thinking about hdr as well.

The job I have to do it will be an hdr10 show and one of the benefit I see the most is that I can create and manage an hdr and an sdr timelines in the same project and export all the deliverables requested switching the odt at timeline level.
To do multiple exports its a huge time saver.

Another thing, but I might be wrong, is that I can transform dlog footage (just an example here) to something else that has an actual idt on node 1 and then pipe into the aces node tree.

My comment there was not that the Blackmagic Film transforms are different from IDTs, it was that a Resolve OFX Color Space Transform to ACES is not the same as an IDT, as it does not include a chromatic adaptation. This would be the case for any camera. The OFX ACES Transform does apply a chromatic adaptation, when applying IDTs.

Where two colour spaces have the same white point (most camera encodings use D65) transforming between them does not need chromatic adaptation, so using the OFX Color Space Transform to do this as part of a manually built ACES pipeline is fine. For example you can use a Color Space Transform to go from a camera encoding not included in the ACES Transform to one which is, followed by an ACES transform to apply that encoding’s IDT. I think that is what you were suggesting, @Orash_Rahnema.


I just wanted to follow up on this for anyone else that might had my seme question
I have done few tests, maybe not extensive enough but that made me confident to bring this workflow into production and I must say that so far using ACES Ofx as IDT and as RRT/ODT worked just as expected and feel solid
Plus having access to camera source prior IDT gave me the chance to transform camera shot in 2.2 gamma curve to work much better in hdr.
Same camera in a conventional project based aces pipeline gave me some nasty highlights and saturation in hdr.

@nick sorry for getting that wrong, as I pointed to your answer in another thread.