• site home
  • blog home
  • galleries
  • contact
  • underwater
  • the bleeding edge

the last word

Photography meets digital computer technology. Photography wins -- most of the time.

You are here: Home / The Last Word / Macbeth white point adjustment errors

Macbeth white point adjustment errors

January 10, 2016 JimK 2 Comments

This is the sixteenth in a series of posts on color reproduction. The series starts here.

I’ve spent the last few days coding up a storm so that I can automate the color error calculations involved in analyzing Macbeth color checker charts converted by various cameras, raw developers, and camera profiles.

I needed to test my code, so I came up with a way to simulate a perfect camera, and run the files from that camera through my analysis code. Since the method that I’m using counts on the raw developer’s conversion of the white point of whatever image its presented to the white point of the output RGB file, I needed to perform that white point transformation as well. There are many ways to do this, and two popular algorithms are the old, reliable von Kries method, or the newer Bradford one. Not knowing what method any given raw developer uses, I used both.

I started out with the spectral reflectances of each of the Macbeth patches, and illuminated them with several standard illuminants, D65, D50, E, A, and C. The CIE has tables with the spectral values of these illuminants. I chose Adobe RGB as the output color space. Since the white point of Adobe RGB is D65, the errors with that illuminant should be very low.

Here are the aggregate measures for von Kries WB adjustment that my simulation spit out.

von kries errors

And here are the errors using Bradford conversion:

bradford errors

The illuminants are across the top, and the aggregate measures run from top to bottom.

Mean Delta E is the average CIELab delta E. It is very low for the two D65 columns, meaning that my code is probably doing its job well. Judged by Lab Delta E, Bradford appears to do a better job of WB correction than the old standard method. Since Delta E can never be negative, errors in one direction don’t cancel out errors in another.

Mean Delta L is the average difference in the CIELab and CIELuv vertical (luminance) channel. Positive Delta L means that the output is brighter than it should be. Negative Delta L means that the output is darker than it should be. Thus Delta L is good for detecting systematic luminance bias.

Mean Gray Delta L is the average difference in the CIELab and CIELuv vertical (luminance) channel for the 6 gray patches. Positive Gray Delta L means that the output is brighter than it should be. Negative Gray Delta L means that the output is darker than it should be. Thus Gray Delta L is good for detecting systematic luminance bias in the gray axis. I will be adding software to correct for exposure variations. Driving the Mean Gray Delta L towards zero will be the job of that code.

Mean Delta A and B are the average differences in the CIELab and CIELuv a and b channels. Positive Delta A or B means that the output is redder or yellower than it should be. Negative Delta A or B means that the output is bluer or more cyan than it should be. These measures are good for detecting systematic color balance bias.

Mean Delta Cab is the average chroma error measured in Lab. A positive number means that the output colors are more saturated than they should be. A negative number means that the output colors are less saturated than they should be.

Mean Non-Gray Delta Cab is the average chroma error measured in Lab for the 18 chromatic patches. Mean Non-Gray Delta Cuv is the average chroma error measured in VIELuv for the 18 chromatic patches. A positive number means that the output colors are more saturated than they should be. A negative number means that the output colors are less saturated than they should be. The sigma metrics track the standard deviation of the 18 samples.

Mean Delta Hab is the average hue angle error measured in Lab, expressed in degrees. The gray patches are excluded from this measure, since their target hue angle is undefined. A positive number means that the output colors have a hue angle higher than they should have. A negative number means that the output colors have a hue angle lower than they should have. Mean Delta Huv is the same measure in CIELuv.  The sigma metrics track the standard deviation of the 18 samples.

In case you want to see how these errors appear plotted in CIELab, here’s a look at the Bradford algorithm with Illuminant A.

Bradford ab graph Ill A

What’s the dark gray rectangle? Beats me. Some kind of Matlab weirdness, I guess.

When you see the errors from actual raw converters, it will be well to remember that white balance conversion can be a significant source of errors, although in general smaller than those due to the camera, the profile, and the raw developer.

 

The Last Word

← Presenting capture accuracy results: aggregate chroma Macbeth whitepoint adjustment errors — more illuminants →

Comments

  1. Jean Pierre says

    January 10, 2016 at 10:41 pm

    Hi Jim,
    Oh, many thanks for that! Wow, You give me an answer of all my try to understandt, why the raw-Converter-software works different, with the same raw-file! When I open a raw-file with Capture One Pro, Lightroom/ACR, DXO, RawTherapee or darktable software (default), you will have a different starting point in color. Because all these software use an other converting algorithm for the whitebalance.
    That is annoying and do not help for colorcorrection, even with MacBeth or X-Rite color card!
    Maybe you have pointed out the point.

    Reply

Trackbacks

  1. Macbeth CC, Illuminants, & output color spaces | The Last Word says:
    January 11, 2016 at 3:20 pm

    […] we’ve seen in the two previous posts (here and here), standard white point converters are error-prone, even with a (simulated) perfect […]

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

May 2025
S M T W T F S
 123
45678910
11121314151617
18192021222324
25262728293031
« Apr    

Articles

  • About
    • Patents and papers about color
    • Who am I?
  • How to…
    • Backing up photographic images
    • How to change email providers
    • How to shoot slanted edge images for me
  • Lens screening testing
    • Equipment and Software
    • Examples
      • Bad and OK 200-600 at 600
      • Excellent 180-400 zoom
      • Fair 14-30mm zoom
      • Good 100-200 mm MF zoom
      • Good 100-400 zoom
      • Good 100mm lens on P1 P45+
      • Good 120mm MF lens
      • Good 18mm FF lens
      • Good 24-105 mm FF lens
      • Good 24-70 FF zoom
      • Good 35 mm FF lens
      • Good 35-70 MF lens
      • Good 60 mm lens on IQ3-100
      • Good 63 mm MF lens
      • Good 65 mm FF lens
      • Good 85 mm FF lens
      • Good and bad 25mm FF lenses
      • Good zoom at 24 mm
      • Marginal 18mm lens
      • Marginal 35mm FF lens
      • Mildly problematic 55 mm FF lens
      • OK 16-35mm zoom
      • OK 60mm lens on P1 P45+
      • OK Sony 600mm f/4
      • Pretty good 16-35 FF zoom
      • Pretty good 90mm FF lens
      • Problematic 400 mm FF lens
      • Tilted 20 mm f/1.8 FF lens
      • Tilted 30 mm MF lens
      • Tilted 50 mm FF lens
      • Two 15mm FF lenses
    • Found a problem – now what?
    • Goals for this test
    • Minimum target distances
      • MFT
      • APS-C
      • Full frame
      • Small medium format
    • Printable Siemens Star targets
    • Target size on sensor
      • MFT
      • APS-C
      • Full frame
      • Small medium format
    • Test instructions — postproduction
    • Test instructions — reading the images
    • Test instructions – capture
    • Theory of the test
    • What’s wrong with conventional lens screening?
  • Previsualization heresy
  • Privacy Policy
  • Recommended photographic web sites
  • Using in-camera histograms for ETTR
    • Acknowledgments
    • Why ETTR?
    • Normal in-camera histograms
    • Image processing for in-camera histograms
    • Making the in-camera histogram closely represent the raw histogram
    • Shortcuts to UniWB
    • Preparing for monitor-based UniWB
    • A one-step UniWB procedure
    • The math behind the one-step method
    • Iteration using Newton’s Method

Category List

Recent Comments

  • JimK on Goldilocks and the three flashes
  • DC Wedding Photographer on Goldilocks and the three flashes
  • Wedding Photographer in DC on The 16-Bit Fallacy: Why More Isn’t Always Better in Medium Format Cameras
  • JimK on Fujifilm GFX 100S II precision
  • Renjie Zhu on Fujifilm GFX 100S II precision
  • JimK on Fuji 20-35/4 landscape field curvature at 23mm vs 23/4 GF
  • Ivo de Man on Fuji 20-35/4 landscape field curvature at 23mm vs 23/4 GF
  • JimK on Fuji 20-35/4 landscape field curvature at 23mm vs 23/4 GF
  • JimK on Fuji 20-35/4 landscape field curvature at 23mm vs 23/4 GF
  • Ivo de Man on Fuji 20-35/4 landscape field curvature at 23mm vs 23/4 GF

Archives

Copyright © 2025 · Daily Dish Pro On Genesis Framework · WordPress · Log in

Unless otherwise noted, all images copyright Jim Kasson.