Resolve 17 Color Management Tips and Pat’s Revised Fixed Node Tree

Thank you for sharing your updated node tree! One note to add about that Canon footage which was clipping at the edge of the gamut — Canon Log from the C100 is always captured in the REC709 gamut (as are MP4/AVCHD Canon Log files from the C200) not the Canon Cinema Gamut. Since Resolve has no preset for that combo it’s necessary to tick the “separate color space and gamma” option to be able to set those attributes of the input color space separately in order to tag log files from the C100 correctly as Canon Log + REC709 gamut.

Thanks James. It didn’t seem quite right when I was doing it – but I haven’t worked with footage from that camera in a few years. Once again, showing how important you understand the footage in front of you when attempting color managed workflows.

Thanks Patrick. Tons of nice tips there, an intriguing update to creative colour choices.

On the subject of getting the right input transform: sometimes I’ve received footage where *no-one* kept a note of the camera colour settings, and the DP doesn’t remember! Profile-bashing doesn’t always give you much certainty, but I’ve had some luck using the command-line tools Exiftool and FFMPEG to sniff around the camera metadata. You’d be surprised what you can find!

Stephen, thanks for that tip. I don’t know why I’ve not used FFMpeg? I’ll look into it.

It’s the most epic Swiss Amy knife for hacking away at video files, things like re-muxing without re-rendering can be helpful in a pinch, and also useful for diagnosing exotic problems. Bit of a learning-curve for sure, but I’ve found it a useful quiver. But for metadata it’s as simple as: terminal > ffmpeg -i [drag in source file from finder] and then having a look through the video channel.

It’s a real challenge with independent documentary projects as quite often it’s difficult (and sometimes impossible) to determine in which OETF and gamut the footage was recorded. Sony and Canon both have created too many different log curves + gamut combos and then buried that metadata in byzantine folder structures that only their proprietary tools can read.

Great insight! I have v17b6 on a MBP to play with I’m starting to re-build my node tree for v17. I’m trying to anticipate workflow. What are your thoughts on using the regular Color Wheels vs. the HDR wheels. I’m mostly asking about a SDR project. Do you think there is merit in using Reg CW first as a “base” then HDR CW after? Or just HDR CW?

Not Pat, but I’ve been playing around with that workflow a bit

I’ll get a rough balance with lift gamma gain wheels then in the following node use the HDR controls to build a bit of a look. Usually mostly just lifting up the specular/highlights or just pulling the shadows down to black. Then when I past the grade onto another shot I can just massage it around with the Lift gamma gain node to get it sitting in the right place underneath that HDR node.

There’s no reason you couldn’t use just the HDR tools though. I think you just need to dive in and try it. See what works for you. Sometimes If I’m stuck I might just blow away what I’ve got and start again with a different method. I think it’s good to get comfortable working in different ways so you have options when you need them.

I just tested FFMPEG with some Sony MXF files and some Canon MXF files and it didn’t read the OETF and gamut metadata from the files. All it reported for those attributes was “stream” ¯_(ツ)_/¯

Yup, YMMV. How did exiftool do?
Admittedly, the ‘prosumer’ cameras tend to write more metadata that these two tools can read. Panasonic GH series writes a ton readable to EXIF, and DJI cameras often do, too.

No luck in exiftool either, even when I requested output for every bit of metadata in the files. I tested files from Canon C300 Mark II, Sony FS7, and also prosumer digital SLR cameras like the A7sII and Canon 1D Mark IV.

Robbie mentioned this metadata-reading tool in our first Mailbag LIVE yesterday: https://mediaarea.net/en/MediaInfo

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

MediaInfo is great for checking out the codec, bit depth, audio tracks, subtitle tracks, etc but unfortunately it doesn’t report the color space or gamut info either beyond telling you that it’s “YUV” and full range. The OETF and color primaries metadata fields read only as “stream”
If Robbie knows how to get MediaInfo to dig out the OETF + color primaries/gamut metadata, it would be super useful info.

I use mediainfo with DJI cameras; useful as I use several different Zenmuse and lenese.
Under the Tree heading I am able to ascertain the codec used, whether it’s MAIN or MAIN 10 @ HIGH 5.1, whether it’s 709 (next line states -limited) or 2020 et.al., but yes I do not recall seeing an EOTF and/or gamma however something like a Mavic 2 pro sensor is using the Hassleblad color science (info on there page) and the Dlog is there own Dlog-M (h.265 10 bit) and luts are provided to rec709 as an input whereupon you can set output to Rec2100 PQ w/ Rec2020 color space or 2084.
The Zenmuse X5 and X5S while different stories (using EI?) Are easily contained / controlled using DR17 RCM where you set the output.
I use the HDR node before the Primaries- correct in Pri, the go back to hdr and setup as usual .
So nodes would look like > NR , HDR, PRI then your usual flow.

The biggest challenge is with Canon and Sony cameras where any combination of 3 different log gammas and multiple gamuts can be set in camera. If producers don’t take notes on the particular settings used, the only way that the information can be confirmed in post is by using Sony and Canon’s own tools. There is no third party app that I’ve ever found which can dig through to determine the OETF + gamut used to record a particular file. The worst is when Atomos recorders are used as they don’t record any metadata at all, so there is no way to confirm what the cameras was set to output.