Site icon ProVideo Coalition

What You Need to Know about Green, Blue and RED

crosstalk476.jpg

What You Need to Know about Green, Blue and RED 1

In a recent article I surmised that RED was mixing green into the blue channel to eliminate blue noise under tungsten light. I had a theory but no proof of what was going on. Now I have proof.

My tests showed that RED saw blue-tinged greens under tungsten light and not under daylight, and by artificially mixing channels in Final Cut Pro I was able to reproduce that effect, matching a daylight-lit test chart to a tungsten-lit test chart by mixing the green and blue channels. (Channel mixing is a known technique for eliminating channel noise, where information from a well-exposed color channel is mixed into a noisy color channel to boost exposure.) Build 20 saw the blue channel’s noise disappear, and RED claimed not to be using traditional noise-reducing algorithms, so it seemed natural to assume that this might be what RED was doing.

As my tests showed that my hypothesis was possible but not guaranteed, I decided to try another test and force the issue. As far as I know, the only way RED could be aware of the overall color of light in a scene is by examining white balance meta data. I decided to shoot footage where the white balance and the color of light completely mismatched. For example, if the RED was channel mixing under tungsten light, then setting the white balance to 3200k but shooting under 5600k light should show the RED trying to eliminate blue noise under daylight, where there is no blue noise. It would be trying to clean up something that wasn’t there.

My plan was to discover whether RED was doing some in-camera channel mixing and image baking, making the term “raw data” meaningless. Read on to see what I discovered…


Here’s a still frame from a RED running Build 20. It’s set to Rec 709, and the image was white balanced in RedAlert. It was shot under tungsten light with an 80A filter, which converts tungsten to daylight. The camera was white balanced for 5600k daylight, and was seeing a chart lit by 5600k light:

Here’s the same chart shot under 3200k light, without the 80A filter and using the “tungsten” preset:

Under tungsten light (bottom chart) the greens and yellows appear muted and dull compared to daylight (top chart). The cause for this is easy to see in the following two waveforms.

First, the RED under daylight:

The circled area shows the left column of chips ranging from green to yellow. Yellow is a combination of equal amounts of green and red, so what we see in that left column is a set of colors in which the green value is the same all the way through: the amount of green in the bottom green chip is the same in every other chip up through yellow, just with varying amounts of red added.

The dip in the circled area shows what we’d expect from the blue channel in a part of the chart where there is no blue: it dips, because there’s nothing for it to do. Notice that on the green and red channels that part of the waveform spikes, showing that those channels see their respective colors in that part of the chart.

Now look at the RED under tungsten light:

The circled area is flat compared to the daylight waveform, which indicates that the blue channel sees some blue in that part of the chart under tungsten light. If you scroll up and look again at the chart images you’ll see that the green and yellow column of the tungsten chart has a blue cast to it when compared to the daylight chart.

The trick is to figure out whether this is intentional or not. If the white balance setting is the only way the camera knows what overall color the light is, then I should be able to incorrectly white balance the camera and force it to mix green into blue when it doesn’t need to.

So I shot a chart with the RED white balanced for daylight, but lit with tungsten light:


Then I shot another chart, lit with tungsten light and with the RED white balanced for tungsten, but with an 80A filter to convert the tungsten light to a daylight white balance:


I then took these images into RedAlert and white balanced them back to normal. In both cases I had to increase the effective ASA to 640 in order to boost the least exposed channel high enough to match the best exposed channel.

If the RED was intentionally mixing color channels to eliminate blue noise under tungsten light, then I should be able to white balance the RED for tungsten light, shoot the wrong color of light (daylight), and see the RED mix green into the blue channel to eliminate the blue noise that it thinks is present because the camera is set for a tungsten white balance. Here’s what happened:

If RED was intentionally mixing color channels based on the white balance setting then each set of waveforms should match, because the white balance settings were the same even though I shot under two completely different kinds of light. The waveforms don’t match, which tells me that the channel mixing isn’t intentional at all, but is instead a flaw in the sensor’s color filters. The camera is simply reacting to the light that’s in front of it, regardless of how the white balance is set.

Turn the page to see my explanation of what I think is going on…


Silicon sensors can’t, at the moment, detect the color of light. They can only detect when light is present. That’s why sensors use colored filters: when the camera detects light at a photosite, it checks its memory to see what kind of filter covers that photosite and then logs the light as belonging to that color. If light strikes a photosite and the sensor knows that photosite has a blue filter over it, it logs the color of the light as blue.

But sometimes the red, blue and green filters aren’t perfect and they pass more than one color. That’s what I believe is happening in this case: the blue filter lets mostly blue light pass to the photosite, but it also lets a little bit of green through as well. Under daylight, which has a lot of blue in it, the green is easily overwhelmed by blue light and has no effect; but under tungsten light there’s not enough blue to overwhelm the green, so the small amount of green light adds to the photosite’s exposure. That means the RED sees a little blue in everything that contains green.

This has broad implications for the colorimetry of the RED under tungsten light. You can see how many colors are affected in the drawing below:

As any color that contains green is affected, almost two third’s of the RED’s color response under tungsten light is distorted by this phenomenon. As most of us learned in film school, the best way to make bright colors look desaturated is to add some blue–and that certainly appears to be the case here. This is a strong argument to use daylight sources or blue filtration when shooting with the RED ONE.

The good news is that RED’s white balance really is meta data. Nothing is “baked in” to the look, and that’s the RED’s greatest strength.

How RED is eliminating blue noise in Build 20 is still a mystery. They claim they aren’t using traditional noise reduction algorithms, so the only means left that I’m aware of is to desaturate the blue channel at the level where blue noise occurs. Under Build 20 the RED is still noisy, but the noise isn’t speckled with blue anymore. It’s more subtle, and in a way more pleasing.

The RED ONE is not the greatest camera ever made, not by a long shot; but it is by far the best $17,500 camera in existence, and you certainly get a lot of value for your money. Just be aware that it’s not currently possible to make a 4k single-sensor camera for that price without taking a few shortcuts. By understanding a camera’s flaws (and every camera has flaws) we can learn how to take advantage of their strengths and make them look their best–which makes us look good as well.

Art Adams is a DP who hates feeling blue. His website is at www.artadams.net.

P.S. At Adam Wilt’s request, below is the waveform for a Sony EX3 shooting the same chart under tungsten light:

Exit mobile version