Colour calculations must be done in a declared colour space

What it is

A warm card with a semi-transparent black veil: the design tool returns a greyish mix, the browser paints something dirtier and greener. Opacity numbers match; the space the mix happens in does not. Gradients, averages, overlays and interpolation are arithmetic on coordinates. Unless that arithmetic names its colour space, the same inputs can lawfully produce several appearances. The claim is that the operation has a name, not that one space is universally “right”.

Why it happens

sRGB values are gamma-encoded. Averaging two encoded channels yields a midpoint that is too dark — the familiar “50% grey is not a perceptual mid-grey”. Physically plausible overlay wants linear-light compositing, then re-encoding. Perceptually even gradients more often interpolate in Lab or OKLab, where a straight line is closer to equal colour difference.

Space also changes the path. Red and green averaged in RGB drift toward dull yellow or brown; in HSV a short-arc lerp may pass through high-chroma yellow, a long arc through magenta. CSS color-mix() asking for in oklab or in srgb is an admission that the trajectory is a choice, not a default. Premultiplied alpha and the compositing space further shift translucent stacks: the same 40% black suppresses lightness differently in gamma and in linear light, which is why a warm base turns grey in one tool and muddy in another.

Studying it

Hold two endpoint colours and an opacity fixed, vary only the working space, measure XYZ of the result and run paired comparisons. Independent variables: space (gamma sRGB, linear sRGB, CIELAB, OKLab, HSV), interpolation path (short arc / long arc), premultiplication. Dependent variables: midpoint lightness, whether the path crosses the achromatic axis, observer labels of “muddy / grey / smooth”.

The typical interface failure is a split toolchain: the design app composites in one space, the runtime in another. Report both engines, not only the hex values.

Where it stops holding

• When endpoints are close, space differences shrink; they show up when the span is large or the path crosses grey.
• Games and 3D pick linear light for energy conservation; flat UI gradients care how the middle stops look. They need not share a working space.
• A later colour-management stage in the OS can rewrite a mix that was “correct” upstream.
• Naming the space does not prevent gamut clipping: clamping after the mix still changes the midpoint.

Applying it

• Name a working space for overlays, gradients and theme interpolation, and put it in the implementation — not a verbal “just mix in RGB”.
• For veils, shadow tints and frosted layers that rewrite large areas of the base, compute in linear light or OKLab, then convert to the output gamut.
• Do not connect complementary hues with an HSV short arc unless the high-chroma middle is intentional.
• How to check: eyedrop the midpoint of the same overlay in the mockup and on device. If the gap is stable, align the mix spaces before touching opacity.

Related

• Same group: F5.01.1 Perceptually uniform colour spaces are better for generating ramps · F5.01.2 Identical numbers look different across gamuts
• Nearby: F5.13 Building and maintaining colour scales · J2.01 Text contrast
• Search terms: working color space · linear-light blending · colour interpolation · color-mix