Help with roundtrip CST

Hello everyone, I’m new here. I also posted this on WeSuckLess, so I’ll just copy-paste the text. Please let me know if doing something like that is frowned upon, but I figured since this is a Resolve/Fusion and ACES issue, why not ask both communities?

I’ve come across an inconsistency in how I would expect the CSTs to work in both Resolve and Fusion but I’m guessing I’m missing some information. My hope is that someone can help me understand what’s going on and if my workaround is somehow affecting quality in some way.

For context: I do independent freelance VFX work for independent productions, so anything close to a color managed pipeline for the whole project is too much to ask for BUT I want to stablish my own roundtrip workflow to be able to deliver back files that’ll cause no issues when color grading etc. I wanna use ACES for this, partly to teach myself and get used to the ecosystem. I want to make my VFX Pushes and Pulls in EXR.

So, here’s the issue: applying a CST inside Resolve from source to ACES (AP1 cct), then ACES to my monitoring display gives me one, correct, reference look. From Resolve I export EXRs on ACES AP0 Linear and bring them into Fusion. If I use a CST node to take them from AP0 Lin to my monitoring display, it looks as if it had a different gamma, HOWEVER if in Fusion I first use a CST node to do AP0 Lin to AP1 cct, and then another from AP1 cct to my display, it looks exactly like the reference. What am I doing wrong to be needing two transforms, or what do I not understand about ACES?

Full procedure:
Inside Resolve I’m in a non-managed timeline, I bring in the camera originals and manually add a first CST node to bring them into ACES AP1 ACEScct, from there I add another CST node, this one to the whole timeline, to go from AP1 cct into Rec.709 Gamma 2.4, because that’s the display I’m monitoring in and what my final output will be. Doing this process gives me what I’ll call “Look1”, which looks correct (in color and gamma) to me and we’ll define as the baseline. My VFX monitoring inside Fusion should match this Look1, because I’m literally using the same computer and displays, and that’s the whole point of ACES.
That was just to have the reference and know the roundtrip worked properlly. To export the EXRs I use a CST node to bring the camera originals from whichever gamut and gamma they are in, into ACES AP0 Linear. No other nodes are applied. On the delivery page I make sure it tags them as AP0 Lin, and export EXR RGB half (piz).

As stated above, inside Fusion using a single CST AP0 Lin to Rec.709 2.4 node would give a different look to the baseline “Look1” I’m seeing in Resolve, so I gotta do a two step CST process: AP0 Lin to AP1 cct, AP1 cct to Rec.709 2.4, and use this node as my viewing node. To roundtrip I then do another two CSTs: 709 2.4 to AP1 cct, AP1 cct to AP0 Lin, and then to a saver node, Open EXR, with output color and gamma set to Keep.

Back in Resolve, doing a CST from AP0 Lin to 709 2.4 gives me the correct “Look1” that’s exactly as the baseline reference stablished earlier. Pixel peeping the waveform and vectorscope shows no changes between the reference and the roundtrip’d, once they’re both in 709 2.4, so I’m assuming it worked, but I’m very curious as to what I might be doing wrong that Fusion needs a two-step CST transform to look exactly like Resolve, when back in Resolve the same AP0 Lin file can look exactly like the reference with a single CST.

I hope I’m being clear, both on my question and my process. Thank you to anyone who might know what’s going on.

Hey @jckobeh welcome!

I think there is one key question that needs to be answered first. By CST are you referring to the actual CST (Color Space Transform) Effect native to Resolve? Resolve users often use the term as a general means of converting data but depending on how it’s used it means different things.

I’m saying this because in an ACES pipeline the correct way to do your conversions and apply the correct view transform would be to use ACES Transform nodes/effects.

If you’re using CSTs it could perhaps explain the issues you’re facing as the way it works isn’t as most users would think/assume.

Would you mind sharing an image that shows the node settings you use throughout the pipeline?

You are correct in that I was using the CST node, not the ACES Transform one, which seems to be working just fine both in Resolve and Fusion Standalone, completing the roundtrip.

How can it be that these nodes are working separately? Isn’t the colour space transformation math always the same matrix (as in, the input and target values of primaries and white point are known CIE XYZ numbers, and gamma is also a known, fixed parameter)?

Why do they behave differently?

Yes they should mostly be the same, but there is difference in the mechanisms around it.

  1. ACES IDTs use specific chromatic adaptation models and to my memory different ones depending on which camera space it is as they are supplied by their vendor. A CST exposes only enabling adaptation but the method used for each space to me is unknown. So regarding the matrix for the primaries there may be slight differences if you’d need to match data that was managed via ACES IDTs before, eg. you’d go to AP0/lin via one method and back to camera log via another method.
  2. A CST node in it’s default settings has Tone Mapping enabled. When going from log to linear, if you do not disable tone mapping, the result is linear-tonemapped, whatever that means. So it’s mapped to 0-1 range rather than a true linear signal.
  3. ACES is a color management framework to manage and convert between color spaces but it also intends to serve as a basis for actual image grading and finishing. Therefore it has built a DRT which you use to convert from scene to display. This transform is ACES’ own design (with ACES 2.0 being the new one recently released) and is not the same appearance as using a CST which by default uses ‘DaVinciDRT’ but has a few other options non ACES related.
  4. The design of DaVinciDRT is made so that the rendering/tone mapping happens in the linearized space it came from afaik, so converting AP0/Linear to Rec.709 would result in a completely different image than converting the exact same image data from SG3c/SLog3 for example.
  5. The CST uses separate checkboxes for applying forward or inverse OOTF. They get enabled by default when converting from scene to display or reverse, but choosing Linear has an odd quirk that this doesn’t happen so going from a Linear space to Rec.709 Gamma 2.4 you need to enable it manually. If you pick Rec.709 as the Gamma as well, this part is built in to the option so the checkbox becomes unticked but the appearance matches… A bit of a mess eh…

I have the feeling either 2 or 5 could be the cause of your discrepancies.

That said, if you want to work in a full ACES pipeline and intend to view the same image as other parties involved using ACES you would need to match the ACES version and use ACES Transforms throughout the project. For sanity sake I’d redo any intermediate exports via the ACES Transforms before continuing work.

The CSTs and Resolves color management as a whole are a bit of a mess imo but have their use for anything non-ACES related.

1 Like

@shebbe inconsistencies arising from user error due to lack of awareness on weird tick boxes sounds exactly like my kind of issues, I’ll test it out, thank you.

These chromatic transformations the IDT does, is there documentation to read on them?

These are the IDTs: GitHub - aces-aswf/aces-input-and-colorspaces: ACES Input and Color Space Conversion Tranforms