ADC bit depth vs pixel format: why 10-bit sensors ship 8-bit images

Every camera data sheet lists two numbers that look interchangeable: the ADC bit depth and the pixel format. They are not. The ADC bit depth says how many bits of real signal the sensor's digitizer resolves; the pixel format is only the size of the container the camera hands your software. That gap explains why a 10-bit camera can deliver 8-bit images, why 16-bit files from a 10-bit sensor are mostly padding, and why the same scene looks identical in both until you start measuring faint contrast. This page separates the two numbers, works one pixel value through both containers, and ends with the decision rule for choosing a format per inspection job.

The two numbers on the data sheet

The ADC bit depth is hardware: how many bits the sensor's on-chip analog-to-digital converter resolves for every pixel it reads out. The pixel format is a setting: how many bytes the camera writes per pixel in the image it streams to you. The first is fixed when the sensor is designed; the second you set in the camera's pixel-format feature, in your acquisition software or GenICam feature list, before or during streaming.

Both are counted in bits, so they read like the same specification. They are not. A 10-bit ADC with an 8-bit pixel format digitizes 1,024 grey levels and delivers 256 of them. The same camera with a 16-bit pixel format delivers all 1,024 levels, each stored in a 16-bit word with six zero padding bits. Same sensor, two different images: the format decides which bits survive the trip out of the camera.

If you are choosing hardware rather than settings, start with the area scan cameras; the rest of this page tells you which format to run once the camera is on the bench.

How many grey levels each number buys

The count is a power of two: N bits resolve 2^N distinct levels, numbered 0 to 2^N - 1 in DN (the digital number a pixel carries). What each depth buys in contrast terms:

The dB column is 20 × log10 of the level count, so each extra bit adds 6.02 dB of indexable range.

This is why sensor designers skip 8-bit digitizers. Machine-vision sensors commonly specify 60 dB or more of linear dynamic range, which 8 bits cannot index, and the camera does its digital gain, offset and color arithmetic at full ADC depth before any format is applied. Truncating at the converter would bake the loss into every later step. For the camera-level choice between sensors that digitize at 8, 10 or 12 bits, see machine vision camera bit depth: choosing 8, 10 or 12 bits.

The pixel format is the container, not the resolution

An 8-bit pixel format keeps the eight highest bits and discards the rest: a 10-bit ADC loses its two lowest bits, a 12-bit ADC loses four. A 16-bit pixel format adds nothing - it left-aligns the valid bits and pads the low end with zeros, so a 10-bit value arrives intact inside a 16-bit word, followed by six bits of nothing. Some cameras also offer a packed 10-bit format that spends exactly ten bits per pixel and wastes none.

The padding exists so the stream stays aligned to the 16-bit words that image libraries, file writers and displays expect. It carries no information, and it changes what your arithmetic reads - see the warning below. Pixel formats themselves are fixed definitions, not tunables; when a format refuses to change, that is by design: why camera pixel formats are fixed and how to set them.

One pixel through both containers: 831 DN from a 10-bit ADC

Inputs. ADC bit depth: 10 bits, the digitizer depth fixed in the sensor - the case this page works through, and a common depth on current machine-vision CMOS sensors. Pixel value: 831 DN, an illustrative reading at 81% of full scale (831 / 1,023 = 0.81). Containers: the 8-bit format holds 0-255; the 16-bit format holds 0-65,535.

Arithmetic:

• 2^10 = 1,024 levels, so DN runs 0-1,023.
• 8-bit container: 831 / 2^2 = 831 / 4 = 207.75, floored to 207. Full-scale check: 1,023 / 4 = 255.75, which floors to 255 and fills the container exactly.
• 16-bit container: 831 × 2^6 = 831 × 64 = 53,184. Full-scale check: 1,023 × 64 = 65,472 ≤ 65,535 - it fits, with six padding zeros per pixel.
• What is lost: in 8 bits every value from 828 to 831 DN collapses to 207, so one container step spans 4 DN. The 16-bit container keeps all 1,024 levels. Scale both to 8 bits for display - take the top byte of 53,184 and you get the same 207 - and the pictures look identical; the missing information sits in the low bits the display drops.

Decision. One 8-bit step equals 4 of 1,023 DN, 0.39% of full scale. Contrast you must measure below about 0.4% of full scale cannot survive the 8-bit container - run the 16-bit format. Contrast above that - presence checks, code reading, robot guidance - is served by 8 bits at half the bytes.

What the container costs in bytes and bandwidth

Bytes per pixel is the container's price tag, and the bill scales with resolution and frame rate:

4000 × 3000 = 12,000,000 pixels, so the frame sizes follow straight from the bytes-per-pixel column (MB here means millions of bytes), and the stream rate is frame size × 30.

Set that against the links. A 1 GbE (GigE Vision) link carries roughly 118 MB/s of usable image payload - 125 MB/s line rate minus protocol overhead - so the 12 MB frame tops out near 10 fps in the 8-bit format and about 5 fps in the 16-bit one. USB3 carries about 400 MB/s usable in practice: 30 fps in 8 bits fits at 360 MB/s, the packed 10-bit stream misses it at 450 MB/s, and the 16-bit stream at 720 MB/s needs the frame rate cut to about 16 fps or a smaller ROI.

The LS-CMR-0166 ships 4000 × 3000 frames at 30 fps over USB3 - the row in the table above.

On GigE the budget bites earlier, and sensor resolution is the lever that keeps both formats affordable. A 2.5 MP frame is 2.5 MB in 8 bits and 5.0 MB in 16 bits, so the same GigE link runs about 47 fps or about 24 fps. The MV-CU020-90GC is a 2.5 MP GigE camera with a global shutter, sized for exactly this kind of link budget.

Choosing the format per job

Decide from the smallest contrast your inspection must separate, then check the bandwidth bill:

• Presence checks, code reading, robot guidance: the 8-bit format. Tools rescale internally, and you halve bandwidth, file size and copy time.
• Faint-defect contrast, surface grading, print inspection: the 16-bit format, so all 1,024 (or 4,096) levels arrive. In 8 bits the surviving step is always 1/255 ≈ 0.39% of full scale - 4 DN of 1,023 from a 10-bit ADC, 16 DN of 4,095 from a 12-bit one.
• Histogram-based exposure control, radiometric work, lux estimation: full depth end to end, because those algorithms consume absolute values; see can you convert pixel values to lux with a camera.
• Archiving and training data: the 16-bit format. The padding zeros compress away in lossless formats; the storage side is covered in how to save 16-bit grayscale camera images reliably and, for 12-bit sensors, saving 12-bit camera images without losing intensity data.
• Display-only previews: 8 bits, and expect the rendering quirks covered in why 12-bit camera images look black in a 16-bit preview and why 10-bit PNG images look black in image viewers.

For the faint-contrast jobs, resolution headroom helps you see small features at all. The MV-CS200-10UM pairs a 20 MP mono sensor with USB3.

Checks before you configure

1. Read the ceiling. Saturate the sensor on a white target and read the histogram: a wall at 1,023 DN points to a 10-bit converter, 4,095 to a 12-bit one, 255 to an 8-bit converter or an 8-bit format.
2. Find the padding. In a 16-bit stream, values stepping in 64s mean 10 valid bits left-aligned; stepping in 16s means 12 valid bits. Values spanning the full 0-65,535 range mean the camera right-aligns or spreads - scale by the converter's own maximum before comparing runs.
3. Bill the bandwidth. Compute width × height × bytes per pixel × fps for your real ROI and frame rate, then hold it against your link's usable rate: about 118 MB/s on GigE, about 400 MB/s on USB3.
4. Log what arrives. Print the pixel format your frames actually carry, not the one you requested; the classic mismatch is covered in converted image object pixel format: verify before processing.
5. Choose by contrast, not by size. The 0.39% rule decides the format; the bandwidth table decides whether your link and frame rate survive it.

When the obvious answer is wrong

• A 16-bit image does not mean 16 bits of information. The ADC depth caps the levels; from a 10-bit converter the container just appends six zeros, and no setting recovers levels the converter never resolved.
• More bits do not clean up noise. When temporal noise spans a few DN, the lowest bits ride on noise; averaging frames recovers precision, truncating to 8 bits does not add it back.
• A better preview is not a reason. On an 8-bit display both formats render the same 256 shades; the extra bits pay only when software measures with them.

If you are sizing hardware now, take your resolution, frame rate and link type to the camera finder or straight into the build-a-system configurator. The two rules on this page decide the rest: 0.39% of full scale per 8-bit step, and bytes per pixel × frame rate against your link's usable rate. More camera-side reading sits in the cameras topic guides, and if you want a second pair of eyes on a histogram or a link budget, reach us through the contact page.