How to troubleshoot Resolve Color Management (RCM)

Troubleshooting 101 – Resolve Color Management

February 28, 2019

Troubleshoot an interesting problem for a more in-depth understanding how Resolve Color Management (RCM) works.


Using Resolve’s Bars and Grayscale generators to explore the RCM workflow

Resolve Color Management (RCM) gives you, the colorist, explicit control over how the software interprets footage in your projects. You can precisely tag non-RAW assets with their native specifications. This lets the software calculate how to transform footage into your desired output. The transforms are mathematical and, as a result, non-destructive – unlike LUT workflows. BUT while the RCM workflow benefit is more precise and higher quality color transforms, what is the cost (or trade off)?

RCM requires you know the origin of your footage

Unlike working with RAW recorded footage, which can explicitly define its origin, non-RAW footage rarely carries such metadata with it. That’s why camera reports from the DP, AC, or DIT can be vital. If the settings of the camera are preserved on paper then we can easily implement an RCM workflow. But what if you don’t know the ‘origin’ of your footage? What if there are no camera reports? Is there a way to test your footage to determine the proper Color Management settings to implement a RCM workflow? Possibly, if your camera-person recorded out a known test signal (like color bars). Starting with a known source makes it much easier to determine the proper Input Color Space for an RCM workflow.

Using test signals to discover the Color Space (and Gamma) of Resolve’s internal generators

In this video Insight, we explore a strange behavior when you add Resolve Bars or Grayscale generators to a timeline with Resolve Color Management enabled. You can easily follow along yourself to see this action (in Resolve 15.2, assuming Blackmagic doesn’t fix this in future updates). We learn that the default behavior for those generators result in an image with an improper Gamma adjustment applied. We also learn how to use an OpenFX plugin (Color Space Transform) to identify and un-do the incorrect adjustment. Finally, we learn the difference between Rec.709 (scene) and the other Rec.709 options in DaVinci Resolve.

My hope in this Insight isn’t that you learn only how to fix this particular, quirky problem. My hope is you learn how to troubleshoot RCM workflow problems, generally. My goal is for you to walk away with a better understanding of the Resolve Color Management workflow.

Update: Be sure to check out Ryan’s comments below about the MediaInfo app that uncovers metadata that Resolve (and other post-production) apps aren’t pulling in – including gamma and color space details. Thanks Ryan!

-pi

Member Content

Sorry... the rest of this content is for members only. You'll need to login or sign up to continue (we hope you do!).

Membership options
Member Login

Comments

Homepage Forums Troubleshooting 101 – Resolve Color Management

Viewing 10 reply threads

    • Ryan S
      Guest

      Using the Mediainfo app, I’ve found a surprising amount of color/gamma info embedded as metadata in media files from many common / prosumer cameras. Worth taking a look at!


    • Pat Inhofer
      Guest

      Thanks Ryan! Good to know. I’ll check it out and report back.


    • Ryan S
      Guest

      Yep! I was working on a doc shot on the EVA1 & GH5, and the op switched between Vlog-L and HLG depending on the scene (don’t ask me why…). Mediainfo would show me which clips, for instance, were recorded in BT.2020/HLG etc., which was very helpful for quickly setting up Colorspace Transform nodes properly. Now that I think of it, perhaps it would be nice if Blackmagic were to include the same libraries that Mediainfo is using, potentially as metadata columns in the Media page? Could make our work a bit easier!


    • R Neil Haugen
      Guest

      Interesting. Testing here, as long as the Output is Rec.709(Scene), the color bars and ramp give a proper straight line. I can have the Input & Timeline settings in either Scene or 2.4, doesn’t matter. But if the Output is anything but Rec.709(Scene) … I get that odd bump you’re showing.


    • Pat Inhofer
      Guest

      It may be that the generated Bars are treated like RAW files – in the sense that Resolve will ignore the Input Settings for those elements. It’s an interesting behavior – and useful for showing mismatches and the importance of knowing your footage in a RCM workflow. But there are elements of this Insight that are specifically unique to the Resolve-created generators (until you export them and re-import as genuine clips).


    • Jan K
      Guest

      It has bailed me out as well. On an FS7 with mediainfo you can determine if the footage was shot slog2 vs slog3. I had a project where the client swore it was slog3 but didn’t look right. Metadata confirmed it was slog2. I think the challenge of Resolve (and other apps) using the data is that it’s not clear how often they are actually set correctly vs. left in some library default. In particular the color primaries, transfer characteristics, and matrix always seem to be set to Rec709 even if it’s very different material. In my mind those are good hints for the human eye, but not reliable for automatic processing.


    • Jan K
      Guest

      This also brings up one interesting puzzle. The Resolve generator for SMPTE color bars includes the pluge area, which is actually a great way of testing if your display brightness is correct. However, when you load the SMPTE color bar generator, the pluge area is way to bright, which goes along with a gamma mismatch. You’re not supposed to be able to tell the difference between one of them, and the other should ever so barely be visible. With the color space transform applied, the pluge area works properly.

      Which is why it’s nice to include them along with the two pop at the beginning of every sequence as a quick test.

      Thank you for solving this riddle. We discussed this at length on LGG the last few days.


    • Jose S
      Guest

      hi Patrick, I did a similar test with Arri Log C Footage. As a reference, I’m using the Arri Lut, from Arri’s Lut generator. I got the same results as you did. However I found out that if you set the tone mapping to simple when using rec709 gamma 2.4, that lift in the shadows does not occur, however, setting the tone mapping to Luminance mapping, will enable that lift in the shadows again! I also tried setting the luminance mapping to simple with rec709 (scene) but that lead to clipped highlights.

      For me the biggest take away here, is that Resolve RCM is still very much unusable.

      At least with Arri Log-C Footage (which is 90% of my work), all the highlights are clipped from the get go and you’d have to get all the highlights back. What’s really tricky is that if you set the max timeline luminosity to 10000 so that the highlights aren’t clipped, the controls become unusable because the pivot of the gain control is at 0, gamma behaves like a weird contrast control, and lift’s pivot is at 640?

      In comparison, a CPS node on the end of the grade does not clip the highlights at all.


    • Pat Inhofer
      Guest

      If you’re in a rec709 workflow (end-to-end) there’s no reason to enable tone mapping. It will give you incorrect results, as you’ve seen. Check out page 112 in the August 2018 version of the manual for the explanation. Keep Tone Mapping set to None in pure rec709 workflows and you’ll find more happiness.

      That said, many colorists are doing a form of RCM in YRGB using the OpenFX transforms. It’s not that RCM is buggy. It’s just more confusing.


    • Pat Inhofer
      Guest

      I missed that thread on LGG. It was an interesting problem to diagnose.


    • Jose S
      Guest

      That’s what I often use, a CPS OFX node on the timeline, however I have always selected some sort of tone mapping because otherwise it will simply hard clip the highlights, it works perfectly. But I’m transforming Arri Log-C to 709, not 709 into 709, not enabling tone Mapping will result in heavily clipped highlights.

      But my previous point was that RCM does not behave the same as a CPS OFX node. Since with CPS will not clip the highlights but RCM will (unless I set the max luminance to at least 1000nits, which in turn results in the controlls not reacting correctly, because I’m actually doing SDR)

      See here:
      Arri Lut: https://uploads.disquscdn.com/images/792370397fa20c861fd7f118a0aa7c0d626ebad2a7b567f652ac8bfdafa62ff4.png Max Lum set to 9900: https://uploads.disquscdn.com/images/72d4cd5e1d601fe90151aa48ecbe07f87147a379a4ef17ebe5ea9e55909ccc50.png
      Simple: https://uploads.disquscdn.com/images/326a54ac95d909fd6e9a89a77fa2d5877cb0f499986446f352ea44f6278834c9.png
      CPS Node https://uploads.disquscdn.com/images/5077236bbe9b141db643c77e2fbb764be2c2e57a8cfb33bf7e1bb0b7487f3265.jpg

Viewing 10 reply threads
  • You must be logged in to reply to this topic.

Hundreds of Free Tutorials

Get full access to our entire library of 900+ color tutorials for an entire week!


Start Your Free Trial
Loading...