Mid-grey is not half the light

The number 128 is a lie you need

Take a pixel at RGB 255 and a pixel at RGB 128. The second one looks roughly half as bright. It is emitting about 22 per cent of the light of the first.

This is not an error. Image files are stored with a transfer function applied: in sRGB, close to raising the value to the power 2.2 on the way to the display and the inverse on the way in. The reason is efficiency. Human vision is roughly logarithmic: you can tell 1 unit of light from 2 units easily, and 100 from 101 not at all. If 8-bit files stored light proportionally, almost all 256 codes would be spent on bright tones nobody can distinguish, and the shadows (where the eye is most sensitive to steps) would band horribly. Encoding perceptually spends the codes where your eye can use them.

So the numbers in an ordinary image file are perceptually spaced, not physically proportional. That single fact explains a family of bugs that otherwise look like software defects.

Where it goes visibly wrong

Resizing. Take a fine checkerboard of pure white (255) and pure black (0) and scale it down until each new pixel covers one white and one black square. Physically, half the light is gone, so the correct answer is about 187 in sRGB. Software that averages the stored numbers gives you 128. The shrunken checkerboard comes out noticeably darker than the original, and a photograph of a distant railing or a striped shirt darkens the same way.

Blur and glow. Blurring a bright highlight across a dark background in gamma space produces a dim, grey smear rather than a spreading glow. Compositing a bright light source over a night scene is the case where this is impossible to ignore.

Alpha blending and semi-transparent edges. A 50 per cent opaque white over black should read as 187, not 128. Anti-aliased white text over a dark background, blended in gamma space, looks thinner and weaker than it should. This is the mechanism behind text that looks fine as black-on-white and spindly as white-on-black.

Saturated colour fringes. Scaling down a red-and-green pattern in gamma space can produce a dark muddy band along the boundary rather than a clean yellow-ish mix.

Doing it correctly

The fix is to convert to linear light, do the arithmetic, convert back. Most tools can:

• Photoshop: Edit > Colour Settings > More Options has Blend RGB Colours Using Gamma 1.00. It is off by default for a good reason: see the limit below.
• GIMP 2.10 and later works internally in 32-bit linear light for many operations and lets you choose per-operation in several dialogues. This is one of the genuine technical advantages of the free tool.
• Krita can set a document to 32-bit float linear, which is the standard for anyone compositing with rendered 3D.
• ImageMagick on the command line: magick in.png -colorspace RGB -resize 25% -colorspace sRGB out.png. Here RGB means linear and sRGB means encoded, which is confusing and correct.
• Raw developers (darktable, RawTherapee) work in linear scene data for the early part of the pipeline by design, which is one of the reasons starting from raw gives cleaner results.

When to care, and when not to

For an ordinary photograph of an ordinary scene, gamma-space resizing is usually fine. Real photographs are full of mid-tones with soft transitions, and the error is small enough to be invisible. This is why the industry got away with it for twenty years.

Care when you have extreme brightness ranges next to each other: a lamp at night, a window in a dark room, stars, specular highlights on chrome. Care with graphics: logos, flat saturated colours, thin lines, text, anything with a hard black-white boundary being scaled. Care when compositing semi-transparent elements, smoke, glass or rendered output. Care with HDR and exposure blending, where you are literally adding light values together.

The honest cost of switching it on

Turning on linear blending in Photoshop changes the result of every blend mode and every partially transparent layer in every file you open, including files a colleague made with it off. A document that looked right yesterday will look different today, and a layered file exchanged between two people with different settings will not match. That is why Adobe left it off: correctness was traded for compatibility with a decade of existing documents, deliberately.

So the sensible practice is not to flip a global switch. It is to know which operations are sensitive, handle those explicitly (a linear-light resize in ImageMagick, a 32-bit float document for a composite with real light in it) and leave the rest alone.

One genuine unresolved corner: not every operation has an obviously “correct” space. Sharpening in linear light exaggerates highlights unpleasantly, and most photographers prefer it done on encoded values even though the arithmetic is arguably wrong. “Physically correct” and “looks right” are not always the same target, and where they differ, photography has generally chosen the second.