Nothing up there is white: white balance for night skies on a phone

Two runs on the same constellation, same night, same tripod. The first one comes out with a brown sky, leaning orange. The second one, an hour later, is bluish. Nothing visible changed in between: same field, same streetlights, same settings saved in the app. What changed is the phone’s opinion about what counted as white in that frame. It formed that opinion on its own, and it keeps forming it, frame after frame, while you are busy looking at the sky.

White is a guess

White balance does not measure the light falling on the scene. It guesses at it. The algorithm looks at the image, forms a hypothesis about what kind of source lit the thing in front of the lens, and applies the gains needed to bring a neutral surface back to neutral. Android’s camera documentation is blunt about this when it describes the metering areas reserved for auto white balance: they exist for «illuminant estimation». Estimation being the operative word.

The list of alternatives is the part that concerns us. Switch the automatic routine off and the device offers a menu of assumed illuminants: daylight, cloudy daylight, incandescent, fluorescent, twilight, shade. Six situations, every one of them daytime or domestic. None of them resembles a dark sky at two thousand metres, and none of them resembles the edge of a town with the lights on.

Two reference lamps, and no sky anywhere

The trouble starts further upstream, back at the factory. A sensor’s colour characterisation is anchored to two standard reference illuminants, the points around which the matrices that convert native sensor colour into the output space are computed. Android’s permitted list is straight out of a colorimetry textbook: D50, D55, D65, D75, standard illuminant A, tungsten, the various fluorescents with their temperature bands, flash, shade. Lamps and daylight. Everything else is an interpolation between those two anchors.

A night photograph falls off that map entirely. The light reaching the sensor is a mixture with no equivalent in a living room: the artificial component the atmosphere scatters above towns, nowadays mostly broad-spectrum LED where sodium once put nearly everything into one narrow orange line, the upper atmosphere’s own emission, which works in narrow lines rather than a smooth continuum, and finally the stars, which differ in colour from one another. There is not one neutral surface in the frame to start from. Asking an estimator trained to find grey inside a room to find it out there is a question with no right answer.

What white balance actually does

Under the elegant name sits a multiplication. White balance is applied as a vector of gains on the Bayer channels, followed by a three by three matrix after demosaicing: the documentation calls them «gains applying to Bayer raw color channels for white-balance». Two details on that page are worth the night. First, the range guaranteed not to be clipped runs from 1.0 to 3.0. Second, gains below 1.0, on devices that allow them at all, are «usually not recommended because this can create color artifacts». Apple describes the same geometry in its own words, noting that each channel takes values between 1.0 and the device maximum.

So the correction only ever multiplies upward. Whichever channel you push carries its own noise up with it, and in a sky frame the blue channel is almost always the dirtiest of the three: a gain of 2.4 on blue hands you a neutral-looking sky with twice the grain.

There is a second consequence, quieter and more expensive, and it has to do with the geometry of the fix. Those gains are three numbers applied to the whole frame. A colour cast that changes from one corner to another, which is the normal case when the lit village sits to your left and clean zenith sky sits top right, has no white balance setting capable of curing it. Neutralise the middle and you wreck the edges, or the other way round. That job belongs to gradient subtraction during processing, and confusing the two costs hours.

Three hundred frames, three hundred different whites

The factory default on phones is the worst possible one for our purposes. Apple calls it continuous auto white balance and describes it exactly: a mode that «continuously monitors white balance and adjusts when necessary». For video of a toddler walking from sun into shade that is precisely right. Across three hundred frames of one star field it means the gains drift while the sky rotates, while a veil of cirrus slides through, while a car’s headlights wash the hedge for two seconds.

Then you stack. The average is taken over frames that disagree about colour, and the result is easy to recognise: slow chromatic blotches across the background, washed-out saturation, stars all the same dirty white. Alignment is innocent here, and so is outlier rejection, because no single frame is anomalous. They are all slightly anomalous, each in its own direction.

Locking it properly

Android documents a procedure, and it repays being followed to the letter. Lock the auto white balance routine, wait for the first result that comes back with the lock already applied, copy those values into a request set to manual, and only then start collecting. The wait in the middle has a specific reason, spelled out on the same page: the camera keeps a pipeline of in-flight requests, so the settings that end up locked do «not necessarily correspond» to the ones in the last result you saw. In terms of fingers and cold hands: after locking, throw the first few frames away.

The other platform works the same way. Apple exposes a method that puts the device into a locked state with explicit gains, plus a conversion that turns device-specific gains into «device-independent» temperature and tint values. The practical difference matters: a temperature and tint pair is something you can write down and reuse next week, while raw channel gains are not. On the Android side, API level 36 added a mode that takes kelvin and a tint directly, with out-of-range requests clamped to the interval the device advertises, assuming the device supports it at all.

Which value you pick matters far less than keeping it still. Set it, note it down, leave it alone until the session ends. Shooting raw keeps the decision open in development, as we covered a while back, with one warning attached: if every file arrives carrying a different as-shot white balance and your stacker applies each one in turn, the raw format has saved you from nothing. The lock is still mandatory.

Colour gets judged at the end

You cannot rule on colour while looking at a single frame. The verdict comes after stacking and after the stretch, which amplifies any residual cast along with everything else. At that point the standard move is to bring the sky background to a neutral grey, the three channels sitting at the same level. The background works as the eye’s reference for every other colour in the picture: leave it tinted and it shifts how you read everything above it.

The check comes from the stars, the only honest reference in a night photograph. A wide field holds orange ones and blue-white ones, and the difference is real, tied to the temperature of their surfaces. If yours all come out white after the stretch, you have saturated the cores and what you are looking at is full scale. If they all share one tint, the balance needs redoing.

White, in a photograph of the sky, is a convention, and it is yours to choose. The one serious mistake is letting it get chosen three hundred times in three hours by an algorithm hunting for a white tablecloth among the stars.