Do Not Let White Balance Throw You Off-Balance
End of Fall Sale!
All LibRaw Products and Bundles - 25% off
Our Special Prices are valid until December 03, 2024.
White balance: does it or does it not affect RAW image data at all? Certainly it affects JPEG, but how and why?
We are going to demonstrate that setting the white balance in a camera has no effect on "normal" RAW data. To do so, we took four shots under the same, fairly constant, light, varying only the white balance (WB) settings in the camera (and the number of roasted coffee beans on the skillet handle). The white balance settings used for these four shots on figure 1 are:
- Daylight (no coffee beans) - shot 3300_41, top left,
- Shadow (four coffee beans) - shot 3300_40, top right,
- 10000 K (two coffee beans) - shot 3300_38, bottom left,
- 2500 K (one coffee bean) - shot 3300_37, bottom right
As you can see the "as shot" color differs dramatically between the shots, yet the RAW histograms of these shots are, for all practical purposes, the same.
If we apply the same custom WB (white balance) to all of the RAW shots, they come to look exactly the same, as expected; the RAW histograms also stay as they were, because, obviously, applying white balance does not affect RAW data (figure 2).
As you can see, changing the white balance setting in the camera doesn't affect the underlaying RAW data in any way. The histograms are the same, and adjusting the white balance to the same value on all of the shots results in the same look and color. Thus, white balance is only an instruction for a RAW converter, not an actual modification of RAW data. If, however, the file contains modified RAW data, like with "small RAW" or in multiple exposure mode, white balance may change the RAW data. An example of "small RAW" with white balance applied is Nikon pre-D850 small RAW format.
You can repeat the simple experiment above yourself, and also check that changing the white balance setting does not affect the in-camera exposure metering readings.
Let's take it a little further now.
For a subject to appear neutral gray on the screen, it is commonly expected for it to contain equal values for red, green, and blue. This is typical for idealized working spaces (sRGB, Adobe RGB, ProPhoto RGB, etc), but hardly ever happens for input device (scanner, camera) data. For a neutral subject, camera RAW data has non-equal values for red, green, and blue and we say that camera RAW data is not grey-balanced. There are two reasons for this imbalance: the responsivities of the red, green, and blue channels of a sensor are not equal*, and the light intensities in the red, green, and blue portions of the light spectrum are also different and vary with the "color of the light." Of course, different intensity of light produces different exposure. Thus we arrive at different exposures for different color channels, producing something one might describe as a color cast. In a lot of cases, this cast appears as green. Here we switched the white balance correction off, setting UniWB in the white balance drop-down:
To get rid of the color cast, we need to equalize (balance) the values of red, green, and blue on neutral subjects, that is to apply per-channel response ("exposure") correction to linear RAW data. That is exactly what white balance is.
Since the green channel usually receives the largest exposure (remember that green color cast?), the RAW data in the red and blue channels is multiplied to catch up with the green channel. Out-of-camera JPEGs are in one of those gray-balanced working spaces (usually sRGB or Adobe RGB), and that means that white balance is necessarily applied to out-of-camera JPEGs. What difference does it make? The short answer: because of applying white balance, something that is not clipped in RAW may end up being clipped in JPEG. This means that the JPEG histogram, frustratingly, misinforms you with regards to the true exposure of your shot; this is especially damaging in already-difficult low light conditions, because it tricks you into decreasing already dangerously low and thus "noisy" exposure.
Most cameras record white balance as WB multipliers. You can see the values of these WB multipliers in FastRawViewer. However, FastRawViewer also allows one to see these coefficients using more conventional photographic units, that is stops, or EV.
To switch between different forms of WB display and edit mode in FastRawViewer please use Preferences (FastRawViewer -> Preferences -> Image Display -> White Balance: White balance display mode / White balance edit mode).
Let's look at a shot taken with the white balance set to 10000 K**. We have RAW and the RAW histogram on the left; the corresponding embedded JPEG and its histogram is on the right.
To see what white balance the camera recorded, we opened the White Balance editor. At this high color temperature setting the camera "expects" the light in the scene to be "cool", that is to contain much more blue and much less red than the actual light that hits the scene. So, it sets the WB coefficient for the red channel (in other words, the response ("exposure") correction for the red channel) to a relatively large value (adding 1.48 stops) to compensate for the supposed deficiency in red, and the WB coefficient for the blue channel to a very small one (adding only 0.09 stops). Such over-correction in red not only makes the respective JPEG look very warm, it also clips the red channel, as the red channel histogram climbing the right wall indicates.
For the next shot the white balance was set to 2500 K.
The camera "expects" a large amount of red and a modest amount of blue in the light that hits the scene. So the response ("exposure") correction for the red channel is set to a rather small value (0.13 EV), while response ("exposure") correction for the blue channel is set to a very substantial value (1.6 EV). No wonder that the JPEG of this shot has a very cold, cyanish tint. The JPEG histogram shows clipping in the blue channel.
The last shot was taken while in-camera WB was set to Daylight.
Here you can see yet another reason why the JPEG histogram can't be trusted if one is shooting in RAW. In spite of the fact that the RAW histogram confirms that there is absolutely no overexposure in RAW, and that the chosen white balance is very close to the actual white balance in the scene, we still have a certain amount of overexposed pixels in the JPEG - the JPEG histogram for all the channels is climbing the right wall.
This happens because, while rendering the JPEG, part of the highlight data that is available in the RAW is simply clipped. You can read more about it in the article "The Three Most Obvious Reasons to Look at RAW and Not Cull Based On Previews".
Exposure meter calibration for RAW and for JPEG is quite different. For more details please read:
- "Digital camera light meter calibration"
- "Establishing the in-camera exposure meter calibration point is the way to extract more dynamic range from your camera"
- "How to Use the Full Photographical Dynamic Range of Your Camera"
One might say that inaccurate white balance is no longer a problem since Auto white balance is quite accurate now. However, in RAW data there is no way to differentiate between the colors present in the scene and the color of the light hitting it. Because of that, if an object in the scene has some saturated colour, usually a shade of red or blue, applying white balance may result in a false overexposure warning. Quite often, looking at a JPEG histogram of a shot with a flower or sky you may think that the shot is overexposed and petals are devoid of details, but the RAW truth is quite different: the RAW data is intact and the overexposure indication is trigged by WB application.
As you can see, it is most certainly worth using RAW histogram while selecting shots for further processing. FastRawViewer is the only (as of the time of writing) image culling application with the set of features necessary to evaluate the exposure in RAW. To learn more about the toolbox we offer for this purpose please see RAW histogram and working with exposure in FastRawViewer
* The response in blue is limited by the nature of the interaction between light and silicon; the response in red is somewhat limited artificially, to keep white balance coefficient for the red channel from being significantly less than 1. Contrary to the popular belief, the response in green being the largest has nothing to do with the Bayer pattern containing 2x of "green" pixels.
** You may be curious why the indication of the color temperature is not exactly accurate. The difference (10000 K to 9050 K), however, is only 10 mired, negligibly small for photographic purposes, equivalent to the smallest available color conversion filter. The interesting thing here is that white balance is communicated through white balance coefficients. When we set the in-camera white balance to some color temperature, the camera converts it to white balance coefficients and puts those coefficients into the RAW file, but the conversion tables the camera is using for this are proprietary and unknown. Because of this, one may expect some discrepancy between the color temperature as it is set in the camera and the color temperature reading in a third-party raw converter, which reads the coefficients from the RAW file and converts them to color temperature using a different approximation.
Add new comment