Now that we have taken the six crucial test images to determine the color-balancing characteristics of the D-220L, we need to gather color data from those images as efficiently as possible. To that end, I developed gatherAllData.m, which basically calls correctGamma.m on each image before running them through processLabData.m, which samples each RGB image for useful information. As mentioned previously in the Methods section of this report, we consider only the central 4x6 color squares of each image. processLabData.m goes into the middle of each square and grabs a region of pixels. It averages all the information in that window to derive a triplet of RGB values representative of that colored square. The white patches in the screenshot below indicate the regions from which we averaged over.
Figure 1: Sampled regions of an image
Because we position the test image in the same position each time, the sample regions stay fixed for all six images. This data, along with macbethXYZ_filters.mat and olympusColors.mat assembled by Li-Yi, a fellow team member, forms the basis of my analysis.
Although it is fairly obvious from our test images that the camera is adjusting the color components of its images to compensate for lighting differences, I want to present that data in a quantitative format that would make this relationship clearer. On a chromaticity diagram, I plot the x,y values of Macbeth color checker white patch under various illumination conditions, the x,y values of the same patch as it appears on the display, the gamut of the display, and the display's white point. To simulate different lighting conditions, we placed blue, amber, green and magenta filters in front of a halogen light source. This explains the cross-like distribution of the white patches' x,y values. For the details of this experiment, please refer to my fellow group members' report.
Figure 2: Chromaticity diagram demonstrating the effects of color-balancing
The chromaticity plot above indicates unmistakably that the D-220L's color-balancing algorithm does an excellent job of clustering white points obtained under dramatically different conditions, and pushing them towards the white point of the display.
Examining the red and green scale factors while holding blue component equal separately on the light and dark control patches yields the following results:
Red scale factor Green scale factor Geometric mean Reciprocal of mean Light Gray Patch 0.7321 0.8400 0.7842 1.2751 Dark Gray Patch 0.7289 0.8335 0.7794 1.2830 The scale factors are consistent for both patches, indicating that the amount of color-balancing applied is independent of the brightness of the pixel. The reciprocals of the red and green factors are very close to 1.3, which strongly suggests a gray world assumption-based color-balancing algorithm.
In the original test pattern, as you may recall from the Methods section, we scaled the red and green components of the colored squares surrounding the gray control patches by a factor of 1.3. The camera evaluates an average for the entire image, which will have both its red and green component greater than its blue by that same factor, and proceeds to scale each red and green value by 1/1.3 relative to the blue value to force the gray world assumption to hold. Since the gray control patches are color neutral, we would expect their blue values to decrease by 1/1.3 = 0.78, which is indeed the case here.
Overall, the camera's color-balancing works very well for this image. If we examine the plot of the red and green scale factors for the 20 'yellowed' squares in the image, we see that they are significantly below the 1.3 level to which they were originally raised.
Figure 3: Red and green (indicated by their respective colors) scale factors
This case is slightly trickier because we need to somehow equalize both the red and green scale factors so that we can isolate the changes in the blue scale factor. My approach is to hold one channel constant at time to get two blue scale factors which we can then compare against each other.
Blue scale factor
(red constant)Reciprocal
(red constant)Blue scale factor
(green constant)Reciprocal
(green constant)Light Gray Patch 0.9026 1.1079 0.8872 1.1271 Dark Gray Patch 0.8986 1.1128 0.8872 1.1225 Unlike the previous case, the camera does not suppress the amount of blue in the control patches as much as the what the gray world assumption would predict. The scaling factor I measured is about 0.9 for both cases, instead of the 0.78 necessary to maintain an overall gray average. If we look at the relative blue scale factors of the other twenty patches, we that the camera color-balances only partially. Although the reproduced blue scale factors are lower than the original scale factor of 1.3, they are still significantly higher than 1.0. A bluish cast is the still present in the processed images.
Figure 4: Blue scale factors, holding red and green constant respectively
It is reasonable to argue that this behavior is in fact desirable. Unlike yellow, blue is an unnatural illuminant color. More often than not, when a bluish tint is present in an image, it is most probably the result of a lighting effect that the photographer was trying to capture. A digital camera that indiscrimately corrects the appearance of every non-white illuminant severely limits its creative possibilities.
The results from this set of experiments are far less interesting. Plotting the exposure-corrected red, green and blue scale factors of each of the twenty color patches surrounding the four middle control patches, we see that the scale factors do not vary much away from 1. In fact, the scale factors for the pattern with the yellow specular patches closely match those of the pattern with the blue specular patches, indicating that the camera is rendering those twenty squares in the same way under two different perfect reflector conditions! This leads me to conclude that the D-220L does not rely on specular information to perform color-balancing.
Figure 5: RGB scale factors under two specular conditions
