OpenEXR way too dark in Davinci

[Dmitry Kitsov]

Check you range. Legal versus full. Van Hurkman goes about it at length in the new manual for resolve.

[Chris Martin]

Wonderring if switching from DaVinci YRGB to ACES color space and using the appropriate ODT would do the trick. It’s about as close to how NUKE runs things through as it gets. I have not worked with exr’s yet myself so would be curious to know what your solution winds up being.

[Felix Gorbach]

Thanks Chris and Dmitry!
I did the rtfm workflow as suggested – but after some try and error settings I couldn´t figure out the exacte correct settings that the OpenEXR looks exactly like the sequences are interpreted in Nuke and AE.
But I could create a far better startingpoint to grade without pushing the values too crazy. So the banding in the skies aren´t that bad now.

Seems like the following settings are working for my project:
In the Master Project Settings the DaVinci Aces Color scinence
In the Look Up Tables Tab the ODT of P3 D60 – and the LUT Cdp.

I know – this is just lucky punch style – maybe somenone has a more robust solution for this issue – as OpenEXR is one of the standard formats for Postproduction and Nuke is build araound this format, I wounder if there is a well documentated workflow with this issue.

Thanks for your tips so far – looking foward to great trainings of the new resolve release, but I could find anything so far that I need:)

[Mike Most]

Open EXR files are in linear light. You need to use a video gamma correction or a liner to video LUT to get a proper interpretation on a video monitor. Try starting with a gamma of about 2.4 and go from there.

[Craig Harris]

What LUTs are the artists using in NUKE for the VIEWER, READ and WRITE nodes?
What is the source footage?

Craig

[David Ngo]

Hi Felix,

I’ve been working on an animation series that had the same problem. After a lot of LUT testing we essentially gave up. Even when we were able to create a LUT workflow that matched the initial frames pretty closely, when we did any grading it simply fell apart – blacks would be grey mush when pushed up and highlights would have casts/banding. We also found that adjusting anything lacked the fine control feel of grading any other type of file in DaVinci.

Failing to find any definitive reason for the problem in the end I assumed the OpenEXR support was a bit premature and we transcoded everything to 16-Bit TIFFs, which worked beautifully.

Cheers,

Dave.

[Craig Harris]

We’ve had no issues with Open EXR’s.
We did our homework to find the right colour pipeline from camera to Nuke to Resolve.

Craig

[Jesse Vrielynck]

Hi Craig,

We’ll having the same issues here on a project with some students.
Are you willing to tip us on the colour pipeline?

We were not aware of the issues involved…

Thanks in advance!

best
jesse

[Felix Gorbach]

I can´t remember what I did, but finally i fixed this issue… but don´t ask me how, so Craig the solution you found would be perfect to know.

Thanks – maybe there is a fix in 9.1.5?

[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