UVC camera raw sensor data: why the pipeline hides it

A UVC USB camera hands your code a finished image: demosaiced, white-balanced, gamma-corrected and often JPEG-compressed before the first byte crosses the wire. If your application needs the sensor's own RAW10 Bayer output, you are stuck. Custom demosaicing, low-light gain studies, HDR merging and sensor-level defect maps all need those raw values, and no host setting will produce them, because the conversion happens inside the camera. This page explains where the raw data goes. It covers what the camera's format list tells you, the bandwidth arithmetic behind the compression, and what to order when raw Bayer is a hard requirement.

Does a UVC camera send the sensor's raw data to the host?

No. A UVC camera converts the sensor's RAW10 Bayer output into standard video formats such as YUY2, NV12 or MJPEG inside its ISP and bridge chip. Only finished frames ever cross the USB link.

The raw stream exists, but only inside the camera. The sensor drives RAW10 across its output lanes into the bridge, which consumes it there; nothing routes it onward. On the USB side the device presents itself as a USB Video Class device, and the class defines a fixed menu of pixel formats. What your operating system and capture library report is that menu. A menu without a Bayer entry is a menu without raw data.

Why can't the sensor's RAW10 capability help once a USB bridge sits behind it?

Because the raw stream terminates at the bridge chip. The sensor delivers RAW10 to the bridge's input. The ISP demosaices, white-balances and encodes it. The firmware then exposes only the formats its USB descriptors advertise, so a host-side data path for raw does not exist.

Sensor capability and device capability are different things. The sensor can emit RAW10 at its own interface. The device you bought is defined by what its bridge chip routes to USB. That also settles the firmware question. An update can change controls and metadata, but it cannot reroute a pipeline whose silicon consumes raw internally. No shipped update turns this class of module into a raw source. If the maker lists no raw mode for a module, treat that as final for that module. Pick different hardware instead of spending days on control-transfer experiments.

Can a control transfer or vendor extension unit surface RAW10 on a UVC device?

No. Extension units add vendor controls and per-frame metadata, not pixel formats. If no Bayer format descriptor exists, a low-level USB request has nothing valid to select. There is no undocumented switch waiting to be found.

The extension mechanism itself makes the point rather than refuting it. The class's extension mechanisms carry things like timestamps and capture flags beside the frames — metadata travelling with the data, never a new pixel format. A few industrial USB cameras do carry raw modes. Those are built in deliberately, listed in the descriptors like any other format and written up by the maker. Raw modes are read off a format list, not hunted for behind control transfers.

How do you check which pixel formats a UVC camera really offers?

Enumerate the formats the device advertises and read that list as complete and final. A UVC camera that carries raw data lists the raw format exactly like YUY2 or MJPG. A list without a Bayer entry means no software can request it.

Every capture stack reads the same descriptors, so one check is enough. Ask your library what the device supports and what you can set: OpenCV's capture properties, ffmpeg's device listing or the operating system's video API all mirror the descriptor table. Requesting a Bayer FOURCC from a device that never advertised it buys a failed call or a silent fallback to MJPEG. If a stream you already have might be raw, the quick checks in how to know you have a raw Bayer stream settle it in minutes.

How much bandwidth does RAW10 need, and why do bridges compress instead of piping it?

A 4,000 × 3,000 RAW10 frame is 15 MB, which at 30 fps is 450 MB/s or 3.6 Gbit/s — most of a USB3 link. The demosaiced YUY2 version is larger still. That is why bridge chips spend their silicon on compression rather than a raw pipe.

Take a 12 MP sensor read out as 4,000 × 3,000; the same arithmetic applies at any resolution:

The surprising line is the third. The ISP's YUY2 output is bigger than the raw Bayer it replaced, because demosaicing turns 10 bits per pixel into 16. Above roughly 1080p30, no uncompressed format fits inside a 5 Gbit/s USB3 link with realistic efficiency. A UVC bridge therefore offers YUY2 at modest resolutions and switches to MJPEG for everything larger. The 10:1 figure is an example value; the real ratio moves with image content and encoder quality.

Compression is what makes high resolution possible over the link. It is also what makes the raw data unrecoverable: once the bridge has averaged Bayer neighbors into 8-bit color pixels, the per-pixel sensor values are gone. The same arithmetic, applied to a CSI-to-USB path you build yourself, is worked through in sizing the MIPI CSI-2 to USB bridge data path.

What should you order when the application needs raw Bayer?

Order a device whose format list names the raw depth you want. That means either a board-level camera module that exposes the sensor's native MIPI CSI-2 lanes to a host you control, or a machine-vision area scan camera on GigE Vision or USB3 Vision, whose format sets are built around raw Bayer.

GigE Vision and USB3 Vision devices enumerate formats such as BayerRG8, BayerRG10 and BayerRG12 as ordinary operating modes. Demosaicing and white balance move into your pipeline, where you set them. On the board-level side, the sensor's lines reach a carrier board, SBC or FPGA that you configure, and with no ISP in the path, raw sensor output is the default — see what raw sensor output means on a CSI camera with no ISP. Match sensor and host before ordering with the board-level sensor compatibility checklist. Both families live in the board-level cameras and area scan cameras categories, or start from the camera finder.

Two from the board-level range: the MV-CB016-10GM-M-W is a 1.6 MP mono GigE board-level camera with a global shutter and an M12 mount. The LS-BCM-0003 is a 3.1 MP USB3 board camera on a 1/1.8" global-shutter sensor with a C-mount and 120 fps.

On the housed side, the MV-CS200-10UM — 20 MP, mono, USB3.0, C-mount, 1" sensor format — sits at the high-resolution end of that raw-first machine-vision family.

If your host sits on a GigE network instead, the MV-CU020-90GC — 2.5 MP, color, global shutter, 1/1.7", C-mount — fills the same role on a GigE network.

What do you check before ordering a raw-data camera?

Check the format list of the exact model, not the interface name on the box. Raw support is a per-device property, and five minutes with the data sheet prevents the exact dead end described above.

Run down six points:

• Depth and pattern. The list names the Bayer depth and arrangement you need (BayerRG10, BayerGR12 and similar). The pattern must match your demosaic or your library's default.
• Packing. Four 10-bit pixels packed into five bytes, or each pixel padded into a 16-bit container. Padding shifts values into the upper bits, and a 12-bit stream in a 16-bit container tops out near 65,520 — see why 12-bit values top out near 65,520 in a 16-bit V4L2 frame.
• Stride and byte order. Row alignment and endianness decide how your unpacking code indexes memory.
• Frame rate in the raw mode. Check the rate at full resolution in the raw mode specifically, because processed modes sometimes run faster than the raw one.
• Host software. Confirm your capture library decodes the format natively, or plan to unpack the packed data yourself.
• Trigger and control fit. If the inspection is strobed or synchronous, check exposure, gain and trigger controls exist in the raw mode too.

When is "no raw over UVC" the wrong conclusion?

Twice. First, when a module ships a vendor raw mode by design — some industrial USB cameras do. Second, when a stream that should be raw shows clipped or shifted values, which is a packing problem rather than a missing format.

The first case is a purchase decision. Read the maker's format list instead of assuming the whole class forbids raw, because a vendor that built the mode in advertises it like any other format. The second case is a parsing problem. Before concluding that data is missing, confirm how the bits sit in the container. If a raw10/raw12 path is producing 8-bit-looking output, the fix in getting full pixel depth from raw10 and raw12 sensor modes is usually a mode setting rather than new hardware. Which transport carries the raw stream — CSI lanes to your own host, or a vision-standard camera — is its own comparison, set out in MIPI CSI vs USB3 for a raw Bayer camera stream.

Next step: work backwards from the format list. Pick the camera first, then walk the camera configurator to pair it with a lens, light and controller. If you want a second opinion on a format table before ordering, contact us — expert support comes with every order.