Raw10 and raw12 sensor modes: get full pixel depth instead of raw8

You order a 10- or 12-bit sensor, wire it up, and the stream arrives as raw8: 256 gray levels, a histogram that stops well short of full scale, and detail you paid for is gone. The same failure hits area scan cameras in GenICam tools and board-level cameras under V4L2, and it almost never means the sensor lost its depth.

This guide shows you how to list the pixel formats the driver really enumerates, force the 10- or 12-bit mode before the stream starts, size buffers and links for the extra bytes, and choose between packed and unpacked formats. The numbers are concrete throughout: a 12 MP frame costs 12 MB in raw8, 15 MB in packed raw10 and 18 MB in packed raw12. At the end you can prove on one captured frame whether the full pixel depth is flowing.

Why does a raw10 or raw12 sensor stream raw8?

In almost every case the sensor still delivers its 10 or 12 bits, and something between the driver and your code threw the depth away: the host accepted an 8-bit pixel format during negotiation, and every frame was scaled to 256 levels before you saw it.

Negotiation runs once, when the stream opens: host and device publish the formats they accept, a common one is chosen, and an 8-bit code is often first in line because it minimizes bandwidth. The depth can drop at three points. The sensor mode itself may be 8-bit only — some high-rate readouts are. The transport negotiation may settle on raw8. The decode layer after capture may convert anyway. If your frames arrive grayscale instead of Bayer, the decode layer did it — camera image encoding falls back to Mono8: request Bayer instead. If re-requesting a deeper format changes nothing, you are fighting fixed enumeration rules; camera pixel format not changing: why formats are fixed and how to set it walks through that case.

How do you list the pixel formats the driver actually offers?

Ask the driver, not the data sheet: on V4L2, v4l2-ctl --list-formats-ext prints every format code it supports with the frame sizes each carries, and on a GenICam stack the PixelFormat node's enumeration is the authoritative list of depths the camera firmware exposes.

Every line in that output is a complete sensor mode: one frame size, one depth, one maximum rate. Treat the list as the contract. A 10- or 12-bit code beside your resolution means the depth is available; no such code beside it means this driver build does not expose it, and no host-side setting creates it later.

On V4L2 the list also shows whether packed and unpacked variants exist as separate codes. On GenICam, open the feature tree and read the PixelFormat node's allowed values directly — browse and set any GenICam feature with a generic feature tree shows how. For raw Bayer capture across several V4L2 cameras, capture raw Bayer RG10 frames from six V4L2 cameras with v4l2-ctl is the practical walkthrough. A board camera on an embedded carrier follows the identical procedure; the hardware side is covered in board level camera selection for embedded vision machines.

How do you force raw10 or raw12 before streaming?

Set the depth on both sides of the link before acquisition starts: pick the exact enumerated mode, apply it to the camera or V4L2 device, request the matching format in your decoder, and only then start the stream.

1. List and choose. From v4l2-ctl --list-formats-ext or the PixelFormat enumeration, note the exact code or value that pairs your resolution with 10- or 12-bit depth. If none exists, stop here: the driver does not expose that depth (see the register-map section below).
2. Set it before stream-on. On V4L2 the setter takes the fields your list printed — v4l2-ctl --set-fmt-video=width=640,height=480,pixelformat=YUYV is the shape; substitute your Bayer code and frame size. On GenICam, write the PixelFormat feature to the enumerated 10- or 12-bit value before you start acquisition.
3. Match the decoder. Tell your conversion step the input depth. A converter that assumes 8 bits reads packed samples at the wrong offsets, and the image tears with rows displaced — that symptom means format mismatch, not a broken sensor.
4. Prove it with one frame. Capture a single frame and count its bytes against width × height × bytes per pixel. 4000 × 3000 at packed raw10 is 15,000,000 bytes; if you count 12,000,000, negotiation fell back to raw8.

How much larger are 10- and 12-bit frames?

Budget 1 byte per pixel for raw8, 1.25 for packed 10-bit, 1.5 for packed 12-bit and 2 for either depth in a 16-bit container, and the same bytes-per-pixel figure multiplies straight into your bandwidth budget.

Worked example, 4000 × 3000, decimal MB (10^6 bytes):

• raw8: 12,000,000 × 1 B = 12 MB per frame
• packed raw10 (four pixels in five bytes): 12,000,000 × 1.25 B = 15 MB
• packed raw12 (two pixels in three bytes): 12,000,000 × 1.5 B = 18 MB
• either depth in a 16-bit container: 12,000,000 × 2 B = 24 MB

The LS-CMR-0166 pairs a 12 MP IMX226 sensor with USB3 and lists 30 fps at its full 4000 × 3000 resolution. At packed raw12 the host side must also move 18 MB × 30 = 540 MB/s through conversion and storage, so budget the processing path, not just the wire.

Size the queue for the deepest mode you keep: four buffers at 24 MB hold 96 MB per camera before your own code runs. Full resolution image capture is slow or stalls: size the data first covers the downstream arithmetic.

Can USB3 or GigE carry 12-bit frames at full speed?

A 1 GigE link sustains roughly 105-118 MB/s and a USB3 link roughly 350-400 MB/s, so an 18 MB packed-raw12 frame tops out near 6 fps on GigE and near 21 fps on USB3; 30 fps at that depth needs 540 MB/s, which means 10GigE or CoaXPress.

Those figures are practical sustained payload, not wire rate. A 1 GigE link is 125 MB/s nominal and delivers 105-118 MB/s after protocol overhead; USB3 leaves roughly 350-400 MB/s of its 5 Gbps; 10GigE lands near 1,000 MB/s; one CoaXPress CXP-12 lane sustains about 1,200 MB/s. Link and sensor readout ceilings both apply, and the slower one sets the frame rate.

The catalog runs on this arithmetic. The LS-CMR-0053 runs a 12 MP sensor over GigE at 9 fps: a 12 MB raw8 frame at 9 fps is 108 MB/s, right at the GigE ceiling. The same pixels at packed raw10 would need 15 MB × 9 = 135 MB/s, which the link cannot carry, so the practical rate falls to about 7 fps (110 ÷ 15).

The LS-BCM-0020 pairs a 6.3 MP IMX178 sensor with GigE and lists an 18 fps mode. A 6.3 MB raw8 frame at 18 fps is 113 MB/s — it just fits. Switch that readout to packed raw10 and the frame grows to 7.9 MB (6,300,000 × 1.25 = 7,875,000 B), so the same link delivers about 14 fps (110 ÷ 7.9). On GigE, a 10-bit readout costs you roughly a fifth of your frame rate at this resolution.

Two cameras on one USB3 controller share that 350-400 MB/s budget; two USB3 cameras at full resolution stream: raise the host USB buffer covers the host-side queue.

Ceilings for a 12 MP sensor; the sensor readout can cap below them.

Packed or unpacked: which depth format should you pick?

Pick packed, at 1.25 or 1.5 bytes per pixel, when the link or the recorder is the bottleneck and your software can unpack; pick the 16-bit container, at 2 bytes per pixel, when you want the simplest memory layout and can afford the double bandwidth.

Packing exists because the wire, not the sensor, is usually the constraint. Unpacking costs a shift and mask per pixel, or a 1,024- or 4,096-entry lookup table: a small load on a CPU and native on GPU pipelines. Storage is where unpacked formats bite. A 12 MP stream at 30 fps writes 24 MB × 30 = 720 MB/s, past a SATA SSD's ~550 MB/s limit; packed raw10 cuts the write rate to 450 MB/s and packed raw12 to 540 MB/s.

The decision: over GigE, or when recording long runs, go packed and unpack in the processing step. With a fast link and heavy 16-bit per-pixel work, go unpacked for the simpler addressing. Either way, read the container carefully — 12-bit data in a 16-bit V4L2 frame: why values top out near 65520 shows what left-justified values look like after capture.

Does a crop or binning mode change your bit depth?

No: cropping and binning are separate sensor readout modes, and each one carries whatever depth it was designed with — if the mode list shows only a raw8 variant of your size, no host setting turns it into raw12.

A sensor mode is a bundle: one size, one depth, one rate. Binned and cropped readouts are separate bundles with their own numbers. Binning trades resolution for signal and frame rate — 4x4 binning vs 2x2: sensor readout decides your frame rate — while an ROI cuts bytes in proportion to area — camera ROI cropping at the source: reduce bandwidth before the host.

An ROI at half the width and half the height carries a quarter of the bytes: 15 MB becomes 3.75 MB and the GigE fps ceiling roughly quadruples. A crop applied after capture does none of this; the sensor still reads full frame and the link still carries it. Choose the enumerated mode that already pairs your depth with your size, because attributes cannot be combined across modes.

When do you need the sensor register map?

You need it only when the driver enumerates no 10- or 12-bit mode at all: the documented source is then the sensor maker's register documentation, released under NDA through their support channels or a commercial engagement, not trial-and-error I2C writes.

If a raw10 or raw12 mode is enumerated, the driver owns the registers and you never write them; even unavoidable sensor-register access should stay within documented registers — set exposure via sensor registers when the SDK has no API shows that case. A full register map matters only when you write a driver yourself. Undocumented I2C writes to chase a mode can break sensor timing permanently. The fastest route is simpler: pick hardware whose standard driver already enumerates the depth you need.

What should you check before ordering for 12-bit work?

Ask for the enumerated mode table for your exact camera model and interface, not just the sensor part number: a sensor with native 12-bit readout is useless to you if the driver ships raw8-only modes for your resolution.

• The mode table for your exact model and interface — sensor capability is not driver capability.
• Your link budget: frame bytes × fps against the practical rates in the table above.
• Ring buffer memory at the deepest mode, multiplied by queue depth.
• Recorder write rate, if frames stream to disk.
• Your converter's supported inputs: packed and unpacked 10- and 12-bit Bayer are different formats and both must appear in your pipeline.

Let the budget pick the interface. 12 MP at 30 fps in packed raw12 needs 540 MB/s, which puts you on 10GigE or CoaXPress; start at the camera finder or the camera configurator. When resolution is the point rather than depth, the MV-CS200-10UM carries a 20 MP IMX183 mono sensor on USB3.0 with a C-mount.

If a mode table looks wrong, or you want a second pair of eyes on the bandwidth math, send us the sensor, resolution and target frame rate through the contact page — the arithmetic takes minutes. Related bring-up guides sit on the cameras topic page.