Color Balancing

General Notes

Typically, when processing color imagery, there is a required adjustment to the "raw" colors of an image to produce more aesthetically pleasing imagery. Most detectors used in color imaging don't have the same sensitivity to primary colors that the human eye; worse, sometimes decoding techniques for various detectors can add a bias to the colors. Depending on the accuracy of the analysis, tables can be generated for a whole series of detectors, or a very precise table may be created for a specific instance of detector. In these situations, a manufacturer or hardware provider will supply a "color balancing" table. Alternatively, this table can be generated yourself through ColorCalibration^?.

In visible color imagery, these tables are generally represented as a 3x3 matrix of reals. For the remainder of this topic, we will assume common three color visible imagery; commonly referred to as RGB (red green blue). The same techniques apply in other multispectral contexts, but are usually applied with different goals and for different effects. Just a heads up.

These tables represent weightings of the existing red, green, and blue pixel values for new red, green, and blue pixels. If each original pixel is considered as a simple tuple of three values [r,g,b] and the resulting (balanced, or corrected) pixels having the same form [R,G,B], it's a simple matrix multiplication.

In fact, most implementations don't even pay attention to the matrix aspect of these adjustments. They simply unroll the loops and calculate the new pixel values inline (as the new values are not dependent on each other, this can often be implemented with some kind of register-parallel instruction set). For example, the Terrapix camera currently used in WASP has a color correction table generated specifically for that particular detector (tied to a serial number) by GSI.

newred = 0.90843134red + 0.34143497grn + -0.52247801blu
newgrn = -0.42400533red + 1.60575446grn + -0.18705347blu
newblu = -0.50791597red + -0.71435708grn + 3.23840753blu

Caveats and other common "oops":

• Note that even though these are tables of "weights", the values are not bounded in [0,1]. Notice that the Terrapix, for example, is not nearly as sensitive in blue as it is red.
• Pixels are often 8 or 16 bit values, and it is easy to overflow when applying color balance tables. In those circumstances, it is expected that the algorithm will "clamp" the pixel values to the bounds of valid pixel values. For example, a negative result would be clamped to 0; overflow will usually be clamped to some "maxint" value.
• In the case of Bayer encoded CCD devices, the color calibration is dependent on the technique used to decode the image. Thus, different BayerTechniques will require different color calibrations.

Notes for IBM

We will first develop color balancing for the aforementioned Terrapix camera; see WaspTerrapix for details. Implementation of the color balancing algorithm is independent of the Bayer decoding technique; all that changes is the actual 3x3 table we supply.