What on earth is White Balance?

My camera (a Fuji X-T2) has a nifty white balance bias feature. I use this frequently to nudge the colors in the viewfinder towards the real colors in front of me. White balance bias is adjusted in a grid on two axis, one green-red, and one blue-yellow.

I wanted to see whether this white balance bias is taken into account in Darktable (and raw developers in general), so I took three pictures, one with no bias, one four points towards green/yellow, and one four points in the opposite direction towards red/blue.

(I place these images into the public domain.)

Looking at the resulting images in several raw developers, it seems that the majority of them are not aware of the white balance bias:


(That’s from left to right: OOC, Affinity Photo, Capture One, Darktable, Lightroom, Luminar, ON1, Silkypix, RawTherapee. More or less default settings.)

From these images, it seems that only Capture One is actually reading the white balance bias. Next, I will probably write a Lua script to retrofit it into Darktable via exiftool.

What truly puzzled me, however, are the numeric values of color temperature and tint that these raw developers showed in their UI:

| App | R+0/B+0     | R-4/B-4     | R+4/B+4     |
|-----+-------------+-------------+-------------|
| ON1 | 4610/2      | 4586/3      | 4547/2      |
| LR  | 4650/20     | 4600/21     | 4600/20     |
| C1  | 4647/5.8    | 4550/-6.5   | 4733/18.3   |
| SP  | 4347/-1     | 4323/0      | 4281/-1     |
| LU  | 4580/13     | 4617/14     | 4642/13     |
| DT  | 4689/1.016  | 4659/1.013  | 4641/1.017  |
| AP  | 4601/1%     | 4578/2%     | 4540/1%     |
| RT  | 4676/1.043  | 4643/1.035  | 4618/1.046  |

Each cell contains values as temperature/tint.

Why are these different? What is up with the tint values? I guess I don’t understand white balance after all…

1 Like

White balance is not about temperature/tint, it’s a set of three multipliers for R, G and B channel. It is needed because of the RGB filters on the sensor. When you take a photo of a neutral (grey) area, the red, green and blue pixels have a different brightness. This has to be corrected, which is the white balance (see images 5 and 6 in the link below).

Background is described here:

1 Like

The description above is for cameras with a bayer-matrix; Fuji uses a different one.

You can read out white balance parameters from your RAW files with dcraw:
dcraw -i -v _DSF9673.RAF

Filename: _DSF9673.RAF
Timestamp: Fri Nov 27 09:03:03 2020
Camera: Fujifilm X-T2
Owner:
ISO speed: 1250
Shutter: 1/8.0 sec
Aperture: f/5.3
Focal length: 74.4 mm
Embedded ICC profile: no
Number of raw images: 1
Thumb size: 1920 x 1280
Full size: 6048 x 4038
Image size: 6032 x 4032
Output size: 4032 x 6032
Raw colors: 3
Filter pattern: BRGRBG/GGBGGR/GGRGGB/RBGBRG/GGRGGB/GGBGGR
Daylight multipliers: 1.000000 1.000000 1.000000
Camera multipliers: 550.000000 302.000000 608.000000 0.000000

‘Filter pattern’ describes the filter matrix on your sensor, ‘Camera multipliers’ are the white balance parameters.

When you open a RAW file in a RAW developer, these tools demosaic the RAW file to calculate the colors and apply some corrections to it. There is no ‘standard’ for these procedures. This is the reason why RAW files look different in different RAW developers when you first open them. Since you edit many parameters and add many more by yourself the first look of a RAW file is not important.

@bastibe Without really giving an answer to your question, this may enlighten you: Introducing color calibration module (formerly known as channel mixer rgb) In particular the remark “The tint is a big fat lie that every software tells you.” - Aurelien

As @pphoto says, the actual important thing is not the value in the GUI, but the absolute RGB mix values.

@bastibe The key is to find ways to interpret and emulate the camera’s white balance bias in your app of choice. Better yet, make sure you expose and frame your image well, so you have maximum headroom to edit to taste and ignore in-camera balance and enhancement controls. In fact, turning them off or setting them to neutral may be ideal.

The trouble with your table is that each app has a different concept of colour temp and tint. Even if you set the same WB values, the colours would not match! A better way to compare would be PSNR or colour difference DE.

What on earth is White Balance?

I’m a simplistic sort, and what I’ve found about white balance is, making something in the image that’s supposed to be white, white. That is, R=G=B. Simple as that.

You really don’t know what white should be unless there’s a white thing in the scene, or at least a neutral gray thing. Then, the white balance is the set of multipliers applied to each of the three channels to make that thing R=G=B. Not a temperature/tint; those are UI things that eventually get translated in to the R, G, and B multipliers to actually be applied to the image data. Temperature as a measurement meant something at the time of capture, regarding the light; after that, it’s the multipliers.

So, your camera measures the light, and it also make some assertion about the multipliers and puts that in the metadata for your raw processing software to use later. And, the camera uses them to make the SOOC JPEG. That assertion could be simply based on what setting you set for whitebalance: daylight, shadow, etc., or the camera could actually be computing numbers based on some unknowable algorithm (auto).

The beauty of shooting raw with regard to white balance is that some notion of white balance isn’t inflicted upon the image; it is expected that the software will later do that to make whatever rendition of the image. Most software will apply the metadata multipliers (“as-shot”, as it’s sometimes known) as a starting point, and what you later do is an adjustment to that original application.

A lot of software gives you temp/tint sliders; me, I prefer to deal directly with the multipliers. If you have a three-channel histogram, you can often see the off-white color cast as an offset of the topology of the three channels in the high end; with that, you can simply scooch the multipliers around to make the histogram channels line up and you get a nice white balance.

FWIW.

6 Likes

Thank you for your answers!

To me, the technical concept of the three multipliers that make neutral colors neutral makes a lot of sense, as e.g. @ggbutcher explained so well. Perhaps it is indeed helpful to think about white balance more in terms of these multipliers than in “temperature” and “tint”.

Evidently, all raw developers understand the three multipliers as well, as all of them agree in their rendering of the white space shuttle.

What is still surprising to me is that these same multipliers are represented as very different temperatures and tints, and that there is so little consensus about the meaning of these terns.

The background of “temperature” and “tint” was discussed in Aurelien’s recent thread on the new color calibration module. Thanks to that, I at least understand where these terms cone from. Still, what a strange thing it is that such a fundamental concept in raw processing is standing on such a flimsy foundation.

1 Like

There ideally would be an absolute notion of temperature; what the temperature of the closest matching blackbody spectrum.

However, without double-checking each and every camera’s response to various color temperatures, we can only guess at it.

Filmulator uses whatever LibRaw says is “daylight white balance”, but it’s not necessarily what the camera thinks is daylight white balance. I normalized the numbers so that the daylight WB preset on my 60D turned out at 5200K and 1 tint. It’s pretty arbitrary, though. Other cameras’ daylight white balance presets don’t end up as 5200/1.

Okay, I’ll now go out on a bit of a limb here attempting to describe things with which I’m only superficially familiar, and in the process I invite others who can “speak snake” about Planck, black-body and all that to straighten me out…

“Temp/tint” in raw processing is an attempt to tie the energy aspect of light to something that can be manipulated in post. While the RGB multipliers are the direct manipulation of the RGB=encoded values of a digital image, they can still be tied to the particular temperature of the captured light. The intuitive notions of “warmer” and “colder” with respect to the “color” of light is very mappable to a single slider and correspondingly to the effect upon the image. If you regard a chromaticity diagram with the white temperatures plotted, you’ll see an arc that can be somewhat readily translated into temp2whitbalance() and whitebalance2temp() functions.

“Tint”, if my understanding holds, is a manifestation of the rather obtuse characteristics of non-uniform light such as fluorescents. Their white is more a product of tricking the eye-brain with some combination of wavelengths rather than a continuous coverage of the spectrum like tungsten produces, and the white they produce doesn’t always fall on the temperature arc. I think of tint as a departure from the temp arc to accommodate such weird light… :laughing:

Definitely “for what it’s worth”, probably not much…

1 Like

Out of curiosity I ran above dcraw command.
I noticed that R6 CR3 doesn’t have Camera multipliers
What does it mean ?

Canon R6

Camera: Canon EOS R6
ISO speed: 500
Shutter: 1/83.0 sec
Aperture: f/6.4
Focal length: 60.0 mm
Embedded ICC profile: no
Number of raw images: 1
Thumb size:  5472 x 3648
Full size:   5472 x 3648
Image size:  5472 x 3648
Output size: 5472 x 3648
Raw colors: 3
Filter pattern: RG/GB
Daylight multipliers: 1.000000 1.000000 1.000000

Canon 7D

Camera: Canon EOS 7D
ISO speed: 6400
Shutter: 1/24.7 sec
Aperture: f/4.0
Focal length: 26.0 mm
Embedded ICC profile: no
Number of raw images: 1
Thumb size:  5184 x 3456
Full size:   5360 x 3516
Image size:  5202 x 3465
Output size: 5202 x 3465
Raw colors: 3
Filter pattern: RG/GB
Daylight multipliers: 2.184862 0.935831 1.256838
Camera multipliers: 1913.000000 1024.000000 2194.000000 1024.000000

It means it cannot read the file properly. dcraw doesn’t work with CR3.

1 Like

Whitebalance annoys me to no end. Generally speaking I want the colours to look like what my brain saw. Proper white balance eliminates the colour of the light that was crucial at the time of capture. Because of the way your brain adapts setting the colour becomes a moving target.

The problem of course is that reproducing what your brain saw is kind of impossible and dependent on a lot of factors.

3 Likes

Like so many things in photography, the white balance setting to make white look white is the “technically correct”, basic setting. After that, nothing obliges you to stay there. In fact, it’s not at all unusual to e.g. push the white balance towards warmer colours for portraits. Perhaps to get a better starting point to getting what your brain saw, would be taking two shots: one at automatic WB and one at “daylight” balance. That should at least give you a hint of which direction to go in.

As for the technical aspects: setting the whitebalance requires a red/green and a blue/green ratio to be adjusted (or red/blue and green/blue, but as the bayer matrix has twice as many green sites…), so only two multipliers need to vary. that’s why we only have two variables to adjust…

@ggbutcher While the modern light sources are “famous” for their weird tints, the “tint” is also quite useful in some outdoor situations, e.g. under trees or on a lawn to get rid of a green cast (not niwe on skin). Basically, you need two variables to adjust white balance (as you can keep the green mulitplier fixed at 1.000), and (in my experience) colour temperature covers most of the needs for outdoor photography, tint is sometimes needed in specific situations.

3 Likes

Back in the old days, we illuminated with the sun and incandescent lighting, which are both black bodies, more or less. So Correlated Colour Temperature was a useful concept, and we knew which gel to put in front of lamps to balance indoor artificial with outside daylight, or which filter in front of the lens would record artificial light on daylight film, and we knew what mireds were.

For still digital photography, colour temperature is a good thing to know about, but isn’t a critical control. Yes, we can control with CT plus “tint” or whatever the other dimension is called, if we want. But personally, I prefer to multiply RGB channels.

We only need to tweak 2 of the 3 channels, but we may want to avoid clipping, so that involves a little juggling with the numbers.

2 Likes

That is a remarkable piece of insight! I had never thought about this, but it makes a lot of sense. In a world of mostly-incandescent light sources, the concept of a “color temperature” would be all you need to correct naturally-occurring color casts.

“Tint” is then a digital graft on existing analog techniques, and should probably be interpreted as “whatever color cast that is not temperature”, more than a sensible measure in its own right.

(The third axis of the tristimulus invariably being “lightness”, and being kept constant for color corrections.)

Which begs the question what other useful color axes there could be besides temperature/tint, and whether they might be useful for correcting color casts.

@johnny-bit collected WB tint data for several cameras earlier this year. See this thread: Call for white balance finetuning samples
I don’t know if that will be included in the next release

Those aren’t Tinted :wink: I requested non-tinted, but finetuned samples. Finetune meaning usually that the requested temp for temperature preset (eg sunny, cloudy, shade etc) moves along planckian locus in smaller increments than between each preset.

And yes, those WILL be in next release : darktable/wb_presets.c at master · darktable-org/darktable · GitHub :slight_smile:

Or the current case in some RAW software - there’s support for reading image data (thanks to libraw), but not metadata (needed for the multipliers) due to the exiv2 team worrying about patents.

I was under the impression that dcraw itself hadn’t been updated for years…

That too, RT uses a heavily modified derivative and I assumed you were talking about that. I missed that he outright ran dcraw, I’m kind of surprised he got that much information out of it. I would have expected it to completely choke on ISOBMFF-based CR3 and not display any of the information he found…

I’m wondering if some distro is installing a symlink from libraw’s dcraw-emu to dcraw…