[Travis Button]

Thanks Marc. If you could relay that message to the self-proclaimed ‘experts’ over at Company 3 we’d all be good to go.

[Travis Button]

Hey all. I know this is an old thread but I figured I’d chime in since nobody actually ever provided a concise solution for this problem that still exists in Resolve 15.

I’ll preface this with some of my findings as I dove into the problem. It appears that Resolve (contrary to almost all other apps including AE) completely ignores any EXR metadata and just interprets the colorspace as “auto/default”, whatever that means. It’s a shame that Resolve doesn’t allow you to manually identify which colorspace interpretation to use, like Nuke does for example.

To get to the bottom of this issue and see where the problem actually was, I rendered multiple metadata based colorspace outputs from Nuke (changing the dropdown in the write node) and none of them effected the way Resolve read the image or how it looked (all resulted in a crunched, overly contrasted image) which is how I determined it ignores the colorspace metadata.

The solution is to do a baked/hard ‘Linear–>sRGB’ colorspace conversion before your write node to make sure it’s importing into Resolve as expected which is very simple and here is the code for that you can copy/paste directly at the end of your node tree before your write node. Hope this helps anyone else running into this problem.

set cut_paste_input [stack 0]
version 10.0 v5
push $cut_paste_input
Colorspace {
colorspace_out sRGB
name Colorspace1
selected true
xpos 266
ypos 1685
}

Cheers,
Travis