EOS 20D - white balance peculiarity

Let me first mention that the basic information I start with here was kindly brought to my attention by fellow OPFer Colleen Vermillion of Austin, Texas. And Colleen, maybe you have the insight into this curiosity as well!

Background

It appears that the Canon EOS cameras actually execute white balance color correction by multiplying the raw outputs of the three sensor channels (actually four, but the two greens seem to always be treated the same, so I'll only speak of three) by three coefficients. I call this set of three coefficients a "color correction vector". Each is really a "recipe" for shifting the chromaticity implied by the raw data before it is demosaiced ("developed").

In the proprietary portion of the Exif metadata (in both the JPEG and, if present, raw outputs), the camera recites the vectors for all its white balance "presets", with the vectors for the "K" and "CWB" presets reflecting how those are currently particularized, and the value for the AWB mode evidently reflecting the determination made for the current shot.

In addition, the list includes the vector actually used for correcting the current shot's JPEG output (the "as shot" vector).

In almost all cases, the green coefficient(s) in the "repertoire" vectors are "normalized" to the value 1023. This is not a restriction, since basically it is only the ratios among the three coefficients that determine the correction given.

Among other things, this recitation of the camera's repertoire of correction vectors in the Exif metadata allows a program such as PS ACR to give the user the option, if desired, to do white balance color correction during development of the raw data under any of the presets the camera might have used to correct the JPEG output (had the photographer selected that one at the time of the shot) or to do it under the "recipe" the camera actually used to correct the JPEG output.

The curiosity

But curiously, at least in my EOS 20D, the "as shot" vector is never quite the same as the vector listed for the WB preset in use. For example, in a recent test shot taken with the "daylight" WB preset in effect, the daylight vector is listed as (and I'll show both "green" values for consistency with the report):

1919 1023 1023 1494

but the as shot vector is listed as:

1919 1015 1015 1494

In other cases, the discrepancy is much greater.

Not surprisingly, as a consequence, if in ACR we develop the image using the "as shot" selection, we get a different developed image than if we use the "daylight" selection.

In the case above, the difference is subtle. But in other cases, the "discrepancy" is very substantial.

One thought is that the camera actually "scales" the stored standard vector for some reason (perhaps based on the range of sensor levels in the shot or something), but the change above would not result from such a scaling (the ratios between the coefficients being changed - substantially, in other examples).

(In reality the coefficients are no doubt actually scaled, at least so that perhaps "1023" effectively becomes "1.000" before being used for multiplication.)

A second thought was that no doubt the " color shift" setting in the camera "piles on" the standard vector for any preset to influence the vector actually used for correction, and maybe I had a non 0,0 color shift in place.

Well, indeed testing shows that the "color shift" setting does pile on the pertinent preset vector to influence the "as shot" vector, but no, I did not have any color shift in effect.

So, what does all this mean? I'd appreciate any insight.

Thanks.

Doug_Kerr said:

So, what does all this mean? I'd appreciate any insight.

Click to expand...

Hi Doug,

Just a thought (a bit of a long shot), I haven't tested it myself, so FWIW.

Maybe the "Shot as" is always calculated, but not necessarily used for the actual (JPEG) generation. In that case there would need to be yet another flag that indicates the actual vector to use as default for "Shot as" at Raw conversion.

Bart

Hi, Bart,

Bart_van_der_Wolf said:

Hi Doug,

Just a thought (a bit of a long shot), I haven't tested it myself, so FWIW.

Maybe the "Shot as" is always calculated, but not necessarily used for the actual (JPEG) generation. In that case there would need to be yet another flag that indicates the actual vector to use as default for "Shot as" at Raw conversion.

Click to expand...

Certainly possible. I doubt if there is another vector listed for that purpose (but see the following). Canon may not be interested in having "others" be able to do this exactly correct!

Another piece of information I had not yet had a chance to write about. In DPP, assuming no "color shift" is in effect, then balancing a raw file with the "as shot" choice and with the choice for the preset in effect for the shot produces, as near as I can tell, the identical color correction. (I have only checked a couple of cases so far, though).

Presumably DPP, being aware of the actual algorithm used in the camera, can behave consistently in this regard. ACR just takes the "as shot" and "presets" at face value.

I'm have not yet ascertained whether the correction is done with the reported as shot vector or the "should have been" vector for the preset in effect. I may be able to tell by comparing the two different conversions done by SCR with the consistent one ones by DPP (but there still may be differences in the development algorithm between the two programs that muddies this). I'll let you know what I find.

Just now, I have to get ready to go to a picnic (a send-off for the county delegates to the State Democratic Party Convention, of which Carla is one).

Thanks for your thoughts.

DPP and ACR color correction

Earlier, I commented that PS ACR, when developing a Canon raw file, seems to apply a different "color correction vector" when the user selects "as shot" vs. when the preset WB correction that was in effect for the shot is selected. I further noted than when using Canon DPP, this anomaly did not seem to occur.

I took a single test shot to illustrate this situation. One frame was taken, with the camera WB set to the "daylight" preset. The subject was a gray card. (Note that no effort was made to have the gray card corrected to "neutral", as if I had taken a CWB reference frame on the gray card.)

I then took the raw output file, loaded it into DPP, and generated two 16-bit TIF files with the color correction set to "shot settings" and "daylight".

Then I then took the raw output file, loaded it into PS2/ACR, and generated two 16-bit TIFF files with the color correction set to "as shot" and "daylight".

Then I took those four TIF files and the JPG file generated by the camera and read the average recorded chromaticity of a rectangular area in the center of the gray card. For the four TIF files, the coordinates of the gray card sample area was read on a 16-bit RGB basis (to minimize quantization error).

These readings were converted to CIE u'v' coordinates, and plotted on the by-now-familiar du'v' chart. The chromaticity of the sample area in the JPG file was arbitrarily made the origin (and note that this was of course only read on an 8-bit RGB basis), so it is "goosey" by up to about 0.001 u'v' unit). Here is the chart:



Note that the two conversions done by DPP produced almost indistinguishable correction results. The two conversions done by ACR produced significantly-different results, both significantly different from the DPP result.

I assume that this mostly means that DPP is designed based on genuine knowledge of the Canon in-camera color-correction algorithms, while the ACR design presumably had to be based on "reverse engineering" knowledge (with the "as shot" and "preset" correction vectors in the Exif metadata taken at face value.

Best regards,

Doug