Bit Depth

A standard display renders 256 levels per channel. A 16-bit camera image contains 65,536. The arithmetic is unkind: whatever is on screen, more than 99% of the levels in the file are not being shown, and no display setting changes that. What actually happens when a 16-bit image opens is that software picks a window -- a low value that will be drawn as black, a high value that will be drawn as white -- and maps everything between them onto the 256 shades available. Everything outside the window is flattened to one end or the other. Move the window and different structure appears, not because the data changed but because you pointed the 256 shades somewhere else. This is why a 14-bit and a 16-bit acquisition of the same field can look identical on screen while being measurably different files.

The opposite failure is visible, and has a name. Acquire with too few levels and quantization becomes apparent as posterization: smooth gradients break into flat bands with hard edges between them, because there is no value available to represent what belongs in between. Posterization in an acquired image is unrecoverable, the steps having been taken before the file was written. Posterization from a display window is not, and the two look identical on screen -- which is why it is worth knowing which one you are looking at before concluding the acquisition was wrong.

They are for measuring, not for looking. Three things depend on them. Headroom: a bright structure that would clip at 8 bits still has room above it, so its intensity remains a number rather than a ceiling. Precision in arithmetic: ratios, background subtraction and unmixing all propagate the coarseness of their inputs, and a value known to one part in 256 cannot yield a ratio known any better. And deferral: because the display window is chosen after acquisition, keeping the full range means the decision about what to show is reversible, while acquiring at 8 bits makes it permanent at the moment of capture.

The relation has a closed form: an ideal N-bit converter tops out at SNR = 6.02N + 1.76 dB, which is why each added bit is worth about 6 dB and why the returns are steady rather than dramatic. There is a ceiling on the useful side too. The effective number of bits is set by the sensor, not the converter: once one digitization step is smaller than the read noise, further bits describe noise with great precision. Matching the converter to the sensor's real dynamic range -- full well divided by read noise -- is the whole of the sizing question.

Downstream, coarseness is what decides whether two populations can be separated at all. Thresholding and segmentation work by finding a value that divides one population from another, and if two populations sit three levels apart there is no threshold that cleanly separates them -- not because the algorithm is poor but because the distinction was discarded at digitization. This is the practical reason quantitative tissue work asks for 12 bits or more, and it is a decision that cannot be revisited afterwards.

Grayscale offers the eye one dimension to judge: lightness. That is the bottleneck, more than the 256 levels are -- shown a smooth gray ramp, most people resolve a few dozen distinct steps, not hundreds. A color lookup table changes the question by mapping intensity along a path that varies lightness and hue and saturation together, recruiting discrimination the gray ramp never used. Structure separated by a few hundred counts in a 16-bit file, invisible as two nearly identical grays, becomes plainly two different colors.

The caveat is real and worth stating at the control: this only holds for a perceptually uniform map, where equal steps in value look like equal steps to the eye. Older rainbow maps are not uniform. They compress some ranges into a band of near-identical color and stretch others across a vivid transition, so they hide real differences in one place and invent a sharp boundary in another. A color map is a measurement instrument pointed at your eye, and a badly built one reports things that are not in the data.

A histogram alone says how many pixels hold each value. It cannot say what any of those values will look like, because that depends on a mapping the histogram does not draw. Put a color ribbon directly beneath it, on the same axis, and the two together answer the question that matters: where the data actually sits, and where the display is currently spending its ability to distinguish.

Read it as a pair. A tall peak sitting over a stretch of ribbon that barely changes color is the signature of a problem -- most of your pixels are in a range the display is rendering as one shade, and any structure among them is present in the file and absent from the screen. Wide bands of vivid ribbon over an empty stretch of histogram are the same waste in the other direction: discrimination spent where there is nothing to discriminate. Adjusting the window until the ribbon's color changes fastest where the histogram is tallest is not a cosmetic act. It is pointing a limited resource at the part of the range that has something in it.