From Backbuffer to capture in Davinci/Color Discrepancies

Hey fellow colleagues, I come here in ask for advise within the ACES community wisdom as I am a bit clueless onto where the problem I’m facing might be. Any advise from a Davinci guru would be immensely appreciated.

On our game engine, the game is running with an ACES/OCIO implementation, so that we can just set the viewer display to whatever we need. So far with still images things have been great, the color correction on the engine works as intended, and the color differences between a baked lut and the davinci operators is quite small.
For this the game is set to render onto a 10 bit backbuffer, and if we take a screenshot with RenderDoc to see the final output, we can extract an .exr to inspect the values.
So what we are doing right now for live color grading is:

  • Set the game to render in ACEScc
  • Connect via HDMI 2.1 a capture card to the video card (this way the capture card becomes a new “fake” screen
  • Display the game on this new fake screen which by the Nvidia Control panel is set to YCbCr 422 10 bit (Resolve Live only runs on this mode)
  • Run Davinci Resolve Live with color science set to Aces 1.2/ACEScc, ODT ST2084/1000 nits (for HDR Color grading)
  • Color grade and export LUT

The problem I am facing right now is that if I compare the color of the backbuffer’s final output from a RenderDoc capture and the color that Davinci is capturing, the later looks a bit brighter.
As if Davinci (or Windows) is applying some transformation to whatever the capture card is sending.

So the concrete problem I’m facing is that an image/video when viewed through a capture card using Davinci Resolve Live will result in a slightly brighter color.

EDIT: And seems that the culprit is somewhere between Windows and the Capture Card, because at some point there is a rec709 conversion. The ACEScc source is correct but then gets a contrast reduction at the moment it reaches Resolve.

On the attached images you can see that if I import an EXR in Resolve I can see the correct image, but if I see that same EXR through Resolve Live the color ranges get squeezed a little bit. Any ideas would be greatly appreciated!



*Ignore the curve spike at the beginning, the image is cropped at that part

It could also have been a Full->Video level conversion. For the life of me, I haven’t been able to get Resolve’s previewer to match our game engine nor rendered H.265 encoded mp4 files if I render them with Full data level. If I change the settings in DaVinci Deliver page for mp4 encoding from Full to Video then it will match Resolve’s preview panel. I’m assuming that this is why I can’t get our game engine to match.

1 Like

Hey Jean!

Thanks a lot for the hint, now that you mention and I look at it closely, it makes a lot more sense that the problem lies in a range mismatch.

How did I end up assuming it was a rec709 curve? Well there’s this Media Express app that works as a video capture for whatever the decklink is receiving and it came to my attention that the info will point to a rec709 colorspace video, but then I compared it to Davinci and this two images don’t match.

So now, what I did is added a bit of contrast (1.16) and pivot offseting (.431), just eyeballing it to be honest, in order to expand the squeezed limited range values and the tones came to be extremely close to what the backbuffer is outputting. Did some tests with various exaggerated intensity values and could not see any case where those magic numbers would have a dramatic discrepancy. Of course I’m still gonna try to find what would be the correct science to expand this values back to a full range, but it seems to me that it should be somewhere along those lines.

So for now, our pipeline will rely on baking a LUT with this fix only when using the Resolve Live feature, pinning this doing to a interface problem rather than a color science one. Doing CC with still images works as intended, so I guess we will still need to improve/advance this workflow and setup.

Cheers!

After some further testing here and there, the contrast needed to match the source with the backbuffer is a value of 1.135 (dropping the Pivot offset I was doing before), which stretches just enough the curve to get the colors as needed. Couldn’t really find the formula for what Davinci may be doing in the contrast, since the value I was aiming for was something around 1.16 so it seems that there may be some extra compensation than just a plain multiplication. I’ll move on on this as the difference is visually minimal if any.

DaVinci is using some kind of S-curve for contrast.

1 Like

DaVinci has (or had last time I looked) a preference setting to choose linear or s-curve contrast.

1 Like

There is indeed an option to turn off the S curve!