Troubleshooting 101 – Resolve Color Management

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!

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

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!

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.

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).

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.

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.

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.

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.

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

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/

Max Lum set to 9900: https://uploads.disquscdn.com/images/

Simple: https://uploads.disquscdn.com/images/

CPS Node: https://uploads.disquscdn.com/images/