I would not recommend rendering ACEScct to EXRs. Not only is it non-standard (which doesn’t have to be a problem, as long as everybody involved knows you are using a non-standard approach) but it is very inefficient use of the EXR code-space. ACEScct will produce values constrained to the 0-1 range (actually for camera imagery it won’t get anywhere near 1.0) but less than a quarter of the available EXR code values represent the 0-1 range, with the rest used for negatives and >1. EXR is designed to hold linear data. ACES2065-1 (linear AP0) is the ACES standard, although some people do use ACEScg (linear AP1) for internal interchange.
Regarding the choice of linear AP0 or ACEScc(t) for LUTs in Resolve, as long as the LUT you use is built for the correct space, the choice is up to you. Bear in mind that LUTs for linear data need a shaper, as a simple cube does not have the required precision.
I’ve read the new guides. Unfortunately they lack working examples. BTW ACES2065-4? is there a mixup between SMPTE ST2065-4 and ACES2065-1?
The reason I picked ACEScct was that I’m coming from a 32-bit space going into a 16-bit half-float and I wanted to keep as much information as possible without losing much shadow and highlight data. There’s a lot of bling and some shadow action going on that I want to massage some more in Resolve.
As for the guides, I got the most use out of the chart. That workflow creates some confusion though. Writing the EXRs in ACES2065-1 means you can’t pick the space in Resolve. Resolve only offers 'ACEScg,ACESccandACEScct. That's it. MyACES2065-1sequences all are just a bit too bright when I set it to _'No Transform'_. I'm assuming setting Resolve toACESmode means everything that's not specified with a transform is presumedACES2065-1`.
Now setting it to:
Resolve SpaceACEScc/t(not sure which yet, I’ll try both, see what feels best to me)
LUTsAP0 Linear(Thanks for the pointer about shapers, another reason to pick AP0 now, to learn)
EDIT:I just rendered again and now the ACES2065-1 EXR from Nuke looks identical to the No Transform in Resolve.
In Resolve when you select “ACEScc” or “ACEScct” in the Color Science dropdown in Color Management settings, you are designating the “working space”, i.e. the color space in which the color correction operations’ maths are performed. Resolve does a conversion from whatever you specify as the “input space” to this working space.
Therefore, if you have ACES2065-1 data (in a 2065-4 container) then you would pick “No Input Device Transform”.
If your data is already ACEScc/t, then pick the appropriate option as your Input Device Transform. (However, I agree with @nick that writing ACEScc/t data into an OpenEXR is very inefficient use of the EXR code values)
Also note that if you have a mixture of formats, you can set the Input Device Transform for each clip individually using the contextual menu on a clip in the Media Pool. If the majority of your clips are one thing, set that in the master settings and just override the outlier clips individually.
Bear in mind that many LUT generating tools (including Resolve’s LUT export) do not create shapers. If you have a way to create suitable LUTs that’s fine, but otherwise you might consider sticking to ACEScc/ACEScct, where the ACEScc(t) curve effectively is the shaper.
Thanks again for the pointers. Was a bit tight on time (had to re-render stuff) but now got the workflow sorted. The difference of writing to ACEScct from Nuke vs to ACES2065-1wasn’t so subtle in terms how it behaved in the grade. This feels much nicer now.
The LUT shapers are for later, don’t need them for this one. I just put the LUT I had made previously on a separate node and dialled in a curve from a pre-pended node till it looked right. Shaper creation is up next on my ACES bucket list.