Using Calibration Test Patterns in Premiere Pro

CalMan Part 10: Using Calibration Test Patterns In Your NLE

February 22, 2018

If you want to calibrate your reference display through your main non-linear editing software then you want to use calibration test patterns playing through a timeline. Learn how to be sure you don't have Data- and Video- level mismatches.


Series

Plus, Identifying Data – Video Level Mismatches

In my previous Insight in this series, I promised we’d look at these ‘pre-calibration test images’ inside Premiere Pro. And that’s precisely what we’re doing now; using the images from the Light Illusion website (get the free download from this page). Specifically, you’re learning how to use these images while reading the waveform displays to definitively help you asses if you have a Data Level vs. Video Level mismatch in your calibration images. Once you’ve determined that your software-external monitoring pipeline is accurate then you can continue the calibration.

But I’ve slipped an additional lesson into this Insight.

You also learn how to use DaVinci Resolve to solve Data – Video Level Mismatches in your renders

These types of workflow issues can be a big problem if you either:

  • A) Regularly override the ‘Auto’ settings in DaVinci Resolve (without knowing precisely why you’re doing so)
  • B) Render to high-quality 444 codecs that are RGB (which leads to lots of Video Level – Data Level mismatches between software packages). Some examples of these confusing codecs include ProRes444 and DNxHR.

In either case, you’re eventually going to get a mismatch between your renders and software that plays back those renders. This Insight will give you some ideas on how to generate a suite of test renders to help you identify the precise mismatch – and conclusively identify which is the right setting for you particular workflow; video levels or data / full range / rgb levels.

Please use the comments to continue the discussion or get your questions answered.

Very shortly now I’ll be recording the Q&A Insight for this series. I being by reading through all the comments in this series and formulating answers to any outstanding questions… before moving on to a few more advanced topics in CalMAN. So get those questions in!

Enjoy!

-pi


Comments

9 thoughts on “CalMan Part 10: Using Calibration Test Patterns In Your NLE”

    1. With RGB codecs, it’s usually not a bug. Often the RGB codec supports both Video and Full Range levels… end-user choice. The problem comes when two software apps make different choices about what they assume as the default behavior. In Premiere, I’ve never found a way to alter the interpretation, so if there’s a mismatch and PrPro is interpreting incorrectly, the only remedy is to rerender to how PrPro ‘wants’ the bit value set for black and white.

      In the specific case of what I show in this Insight: Resolve is assuming we’re following a Broadcast workflow and chooses Video Levels by default. Premiere Pro see it’s an RGB codec and assumes a computer graphics render and expects Data / Full Range – but PrPro also assumes you’re editing in a Broadcast workflow, so it correctly remaps the image – yet the default assumption about the image is incorrect.

      Both Resolve and PrPro are correct. They’re just making different choices – and we have to pick up the pieces 🙂

      Make sense?

  1. Great timing, Patrick. I’ve just been through a couple good lengthy exchanges with Lars Borg, color head for PrPro. Yea, he confirmed what thee, me, everyone else has figured out through testing: PrPro is straight sRGB, Rec709, and “data levels” full range by expectation. And further, you’re correct … there’s not any way for the user to make any other choice. You did a great job here also showing how PrPro “reads” codecs … actually correctly, as far as data vs video levels, even if it doesn’t give the user the chance to pick the settings. So any mismatch from what PrPro expects … like someone sending a DNxH* in a modified range, there’s a train wreck gonna happen in PrPro and squat all the editor can really do about it.

    But great material here confirming how to setup in Resolve correctly, and how to test it back in PrPro.

    1. The truth is, most NLEs have this problem so I wouldn’t lay it squarely at the feet of PrPro. But it is time for NLE software developers to give their users control over how to decode codecs. With all the high-quality codecs that allow both Legal and RGB range encoding, end users need a bit more granular control for smoother workflows. It was easier when your only choice was Uncompressed Rec. 601.

      1. Oh so true. And with all the changes happening now, not just what’s coming … users need more space/profile controls in PrPro now. PrPro “properly” working with a video levels encoded codec but always itself working in data levels results in surprises galore. You can get one input coming in, and depending on what you export in, a different one on export … without explanation. Oh … the base expectation of *this* flavor of X codec is video, of *that* flavor of it is data … didn’t you store all that in your head?

        Um … no, not really … sigh.

  2. To all those reading the great info provided by MixingLight on using the Light Illusion CalImages, do also have a play with the free LightSpace DPS version of LightSpace, as it will help a lot with understanding colour workflows, levels, and that like.

    It is very simple to use, and has a dedicated User guide.

    https://www.lightillusion.com/manual_calibration_idiots_guide.html

    There is also a page dedicated to the issues of TV Legal vs. Data levels.

    https://www.lightillusion.com/data_tv_levels.html

    Also remember that we are available for any questions and answers, especially via the forum on our website.

    https://www.lightillusion.com/forums/

    Steve

  3. Hi Patrick, thanks for the insight on a subject that has been a dilemma in our community for awhile. It’s interesting that the 95% of the chances we have to obtain proper result from Davinci Resolve depends on setting Resolve to Auto. In the current version of DR I’m running here, (14.2.1.007) this option is gone, unless I’m missing something. So, it seems to be that now our only chance to delivery the codec with the right data or video level depends in being precise about the final delivery codec or format.

    Correction: Although the Auto option is not in Preferences, it’s still an option in the Delivery page.

    1. In Resolve there are two places to set Data / Video levels. 1) In Project Settings under ‘Video Monitoring’. That setting deals specifically with feeding the external display and has nothing to do with your final renders. 2) On the Deliver Page where there’s an Auto / Data / Video. That’s the one I’m talking about when I say, “Set it to Auto”; Resolve will choose based on the codec.

Leave a Reply

Hundreds of Free Tutorials

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


Start Your Free Trial
Loading...