The importance of the right white balance

I talked about images from this place before. This is from a little stream in Zion National Park. It is an extreme example of how important it is to know the right white balance. Below I show a single shot from this place using the as-shot white balance, auto Lightroom white balance, daylight, cloudy and shade, and lastly the white balance taken from the neutral patch on a x-rite colorchecker passport. These images, apart from the camera landscape profile are using completely default processing values.



I made this hextich using the print panel in Lightroom and added the text in Photoshop. Click for bigger. As you can see, both the camera and the auto white balance get this completely wrong. The as-shot and auto are far from reality. The rocks on the top left should be orange as they are standard Zion sandstone. The water should not be Cobalt blue. I should also point out here that this image was made at the bottom of a steep canyon where one cayon wall was lit by the sun, causing a very strong glow light in the area where we were. The water is reflecting the light from this canyonwall. Assuming different white balances gets very different results. You can see the results from assuming daylight to shade. Each is giving very different, but much more pleasant results than "as shot" or "auto". The last panel shows what happens when using the neutral patch on my white balance card on the x-rite passport. It is even warmer than "shade"! Of these, I think I prefer shade as the colors are more interesting. One example in which using a white balance card actually is not that helpful. I came accross many more situations like this in the Narrows and other places where the light was just very strange and where my eyes were not seeing what the white balance standard thinks I should be seeing.

EDIT: I posted another illustrative example in a recent blog post.

See more images from Zion in the link.

A word of caution on using custom camera profiles

If you own a colorchecker, you can use DNG profile editor, or X-rite's passport Lightroom plugin to create a custom camera profile for your camera. This works really well. I should however caution you about an issue I discovered with this. One of the problems is that neutrals are not kept neutral when you change to a different camera profile in Lightroom or ACR. An illustration is given below.



On the left is the result of first assigning my self-calibrated profile generated using the passport plugin (this is also true for other profiles) and then using the white balance dropper on the neutral patch on the card and on the right is the result of first setting the white balance and then assigning the exact same profile. As you can see on the right, my very neutral grey backdrop turns green and the girl's skin is rendered a little too yellow. The skin tone might not be too bad but the green backdrop is very distracting I think. On the left, the color is just fine, no tint to the backdrop and good skin tone. The difference is simply in the white balance chosen by the white balance dropper. The image on the right, Lightroom chose 5700K and -3 tint, while on the left, it chose 5450K and +12. Quite a difference for white balancing on the same patch! I tested with all the other camera profiles and they all show this problem that there is a shift in the color temperature taken from the neutral patches.

P.S. if you prefer slightly more warm skintones than the very neutral rendering you get when using the neutral patch, the passport has a set of warming patches in the top row. You can simply select patches more to the right of the standard patch to warm up skintones. This results in the backdrop staying far more neutral but just the skintones warming up. A far more pleasant effect. See below for the result of choosing the patch two spots to the right of the neutral patch (the middle one in the top row of neutral patches. The second row of neutral patches also allows you to go to cooler colors and is more useful for landscape photography.



This made Lightroom choose 6000K and +27 tint. The skintone that resulted is very nice I think.

Conclusion: do your custom white balance after assigning the profile you want to use.

EDIT: It appears that this is mostly a problem with self-created dual illuminant profiles. I create these by shooting one image under tungsten light and another in sunlight as I don't own a calibrated D65 reference. Whether I create the profile in X-rite's passport program or DNG PE, they show the issue of neutrals not staying neutral. The Adobe-supplied camera-matching profiles also have the problem, but it is too minor to worry about. The differences in grey-card set white balance are on the order of 100K which you won't really notice.

Colorchecker passport minireview

I got myself one of the new colorchecker passports. This product has three different targets in a little make-up mirror format. There is a classic colorchecker that we all now and love, a large white balance target and a "creative enhancement target". The package also comes with a CD with software that allows you to create calibrated dng profiles for use in Lightroom and ACR. There is even a plugin that works straight from Lightroom that is very handy.


Figure: The colorchecker and the creative target in direct sunlight. I white balanced this image from the neutral patch on the creative target and created a DNG profile that is used to correct the image. The image looks almost identical to the real life colorchecker. On mouse over you will see the rendering using the Adobe Standard profile for this camera (A Nikon D300).

Above, by mousing over the image, one can see the results from me calibrating my main camera. There are clear differences in the rendering of a few of the patches and the overall image appears warmer in the calibrated image than in the standard profile version even though both raw renderings were white balanced on the same patch. This might have to do with the very harsh sunlight at the altitudes here. I get far better skin tone rendering using these new profiles generated from the colorchecker. You could do this before (and I have done it) using a standard colorchecker and DNG profile editor. Strangely enough there are small differences between the profiles generated by the two different methods. Something to check out. What's most important of a card like this is to be able to get an accurate white balance. An example is below. This is a shot in my son's room with light from several compact fluorescent bulbs. The walls are painted lightly blue and my camera just has an extremely hard time measuring white balance correctly. The below shows the shot with default settings in camera and in Lightroom and the mouseover shows the result of balancing using the grey card and using a calibrated profile (less important here).


Figure: my son using automatic white balance and grey card white balance (mouseover). Mouseover this link to see the same but with the Adobe standard profile.

His pajamas of course are deep blue, not muddy cyan. Needless to say that the image that used a greycard for white balance is far better. There is not that much difference between the standard profile and the calibrated profile and there it comes down to taste.

The creative target that is provided (see the right part of the top image) is very handy as it changes both temperature and tint instead of just temperature. I measured the white balance change and in the top row (little portrait icons) of white balance patches, each successive patch shifts the assumed white balance up by about 250K, while the tint shifts by approximately 6. In the landscape row, each successive patch shifts by about 300K, while the tint shifts by about 7.5. You can do the same thing with the white balance quick adjust in Lightroom, but that shifts with larger steps and does not bring the tint along. The creative target on the passport is clearly well thought out in my opinion.

In conclusion, it is clear that using a correct color balance is very important especially in difficult light. You can use the colorchecker to very easily generate calibrated profiles for your camera which can significantly alter your image's appearance in limited circumstances.

sRGB tone curve and the Lightroom color space

I got to thinking about the display of color values and the histogram in Lightroom. Lightroom internally uses a working space with prophotoRGB primaries but with linear gamma. Using linear gamma avoids all kinds of possible artefacts and is a good choice if you have the bitprecision. On the display of RGB values in percentages and the histogram, to avoid all values to be in the 0-1% range, Lightroom modifies the values with a sRGB tone curve. I was curious to see what this really means. In this original proposal by the group from HP and Microsoft that originally designed sRGB this is explained more or less. sRGB does not have a simple 2.2 gamma that you can use but a complex curve that has a knee in the shadows. The equations are as follows:

If you have a linear R,G, or B value in sRGB primaries, the equation to find the value in nonlinear sRGB space are:

if R ≤ 0.00304,
R_nl = 12.92* R

if R>0.00304,
R_nl = 1.055* R^1/2.4-0.055

repeated for Green and Blue of course.
So, save for the multiplication with 100 to get percentages, Lightroom uses this exact math to calculate the percentage values in linear prophotoRGB to the sRGB tonecurve modified prophotoRGB value display space (I'll call that the Lightroom Value Space or LVS). This tonecurve looks like the following on a double-log plot.



In Red the sRGB tonecurve and in Blue the curve for a simple 2.2 gamma. You can see that for values below 0.05 in the linear space, the deviation from a 2.2 gamma is larger than 5%. Conversely, in the non-linear LVS space, values below 10% are significantly different from when you would assume a 2.2 gamma. This means that the values I published before for the values for the MacBeth colorchecker color patches in the LVS system are all wrong. Here are the correct values:



Sorry for the graphic, I still haven't figured out how to make tables appear correctly in blogger. You can clearly see that the values are significantly different. Hope this is useful for somebody!

More precise values

I found a much more precise table of values on this site. I used the Babel 2005 16-bit average values in ppRGB space and transformed the numbers into Lightroom percentages taking into account the 2.2 gamma of lightroom. The table below has the actual values. Again, I had to make it into a graphic because of blogger's braindead handling of inline tables. You can see that there are small differences in most places, but one patch is quite different. Funny enough (because it is the color people complain about in ACR/LR), it is the orange patch that was 2 percent off in the blue channel. Use these values if you're using a colorchecker inside lightroom.

Lightroom values for the colorchecker chart

Since Lightroom's colorspace is based on prophotoRGB but has a different gamma, you cannot use any of the published values for the color patches in one of the Gretag MacBeth colorcheckers that many people use to check the color rendition of their toolchain and that you can use to calibrate the color rendering of ACR for your specific camera. Usually you would do this in ACR/PS, but if you only have LR, what do you do? Well you can use the below values in Lightroom and do it manually by going back and forth between patches and changing the hue and saturation in the camera calibration part of the develop module (after white balancing on the second grey patch!). These values are based of the values in this excellent page, so there will be a small error in there of about 1%. I simply did the appropriate transform to gamma 2.2 for the values in the ppRGB column. The values are in percent of the channel in R,G,B laid out just like the colorchecker chart.



Honestly, I have no idea why not all the grey patches are neutral, but this should help those manually calibrating in Lightroom.

EDIT: No idea why, but blogger messes up my HTML table, so it is now just a picture of a table. Hope this still works.

UPDATE 9/19/07: I uploaded a table with more precise values from 16-bit values of the colorchecker reference in the next post.