RGB Gamut Errors Part 1: A Broadcast Colorist’s Nemesis

An Annoying Spec that Broadcast Colorists Must Adhere To

Imagine this:

You’ve color graded an hour of programing for a big name network or production company.

You’ve worked your butt off making fabulous grades and of course making sure that the video signal – since this is a broadcast show – was perfectly legal.

As you graded you made sure the signal wasn’t too bright or dark, and that saturation was in check.

Maybe you even used a ‘broadcast safe’ filter or effect somewhere in your pipeline to just catch any stray illegal pixels.

You did fantastic work, and the client is exceedingly happy!

You render the show, ship it off for delivery and go have a pint rewarding yourself for a job well done.

The following week your client calls (you’re thinking victory lap!) and tells you that there have been some things flagged in QC.

Not one to worry, you ask them to send the QC report over as you’re confident most of the issues are probably audio problems or something else that’s not really your concern.

As you scan down the report there they are – they almost jump off the page – RGB GAMUT ERROR (HIGH, RED) 01:13:23:18, there is another one RGB GAMUT ERROR (LOW,BLUE) 01:14:36:18!  Dang!!!

Has this ever happened to you?

We’ve talked quite a bit in MailBag episodes and at conferences Team Mixing Light has spoken at about RGB gamut errors.

These pesky QC flags can be infuriating, and ultimately feared, as they can be hard to clear up if you’re not sure exactly what they are and how to go about fixing them.

The first thing to understand about RGB Gamut Errors?

Every broadcast colorist has been there! You’re not a bad colorist!

Trust me, depending on the network and QC engineer, RGB gamut errors might not even be anything the eye can see – but only an automated alarm on a set of scopes can!

In this Insight, which is Part 1 of a two part series on RGB gamut errors,  I want to take a closer look at what these errors are, how you can monitor for them and some broad strategies on how you can fix them.

Part 1 is an article, but in Part 2 with the background knowledge in place, I’ll show you in a video how to use the techniques I outline below for dealing with pesky RGB gamut errors in your own projects.

Let’s jump in.

So What Is An RGB Gamut Error or Excursion?

I’m sure you understand basic video signal concepts like luma levels and saturation, but what exactly is an RGB gamut error?

First, these errors sometimes go by a different name depending who you are talking to and how geeky they are.

Another phrase you’ll hear all the time is RGB Gamut Excursion – this phrase is referring to essentially the same phenomenon, but some folks prefer it as excursion implies the state of signal as it ‘passes’ legal limits.

Use whichever you prefer – I generally use RGB gamut error.

Now that we’ve got the semantics out of the way, lets get back what an RGB gamut error is.

Many of us grade with formats that use Y’CbCr encoding but ultimately the video monitors and TVs that audiences use display that signal as R’G’B’.

In that conversion from Y’CbCr to R’G’B’ it’s possible to create pixels that are legal in Y’CbCr but illegal within the specified R’G’B’ signal limits of a broadcaster.

In other words, an RGB gamut error (you can also have luma gamut errors) is a math problem in the color space conversions that have to happen from Y’CbCR to R’G’B’ and sometimes back again.

Will an RGB gamut error blow up a transmitter or a viewers TV – ummm, no!

Chances are you can’t tell the difference visually between a shot with a RGB gamut error and one without.

Originally, like many QC tests, the idea was to protect transmission equipment from signal voltage anomalies and signal degradation that could occur.

These days RGB gamut errors are still flagged for a variety or reasons including composite transmission, possible signal degradation and yes because networks like to be hard asses about deliverables!

Networks that measure for RGB Gamut problems will typically specify the signal levels that they’re looking for with 0mV-700mV being the most common specification on an RGB waveform.

They might also specify signal be legal as seen on a dedicated gamut display (more on that in a moment).

Values above 700mV are referred to as high or upper errors and values below 0mV are referred to as under or lower errors.

But there is one more important thing I want to mention.  Gamut errors can be transient or persistent.

Many broadcasters (and QC equipment) don’t care or filter out the transient errors.

It’s the persistent ones that cause the majority of the QC flags you’ll encounter.

Check with the broadcaster you’ll be working with for what constitutes a persistent RGB gamut error.

If you’d like to dive deeper on the definitional side of RGB gamut errors check out these links from Tektronix and EyeHeight (makers of a legalizers):

Color Gamut Monitoring (Tek)

Preventing Illegal Colors (Tek)

What’s A Gamut Warning (EyeHeight)

Now that we have a basic understanding of RGB gamut errors, let’s talk about how to monitor for them and then fix them!