Bayer raw stream from an RGB camera: how to know you have it

You asked the camera for the sensor's own pixels and the software answered with a list of YUYV resolutions. That list is the whole answer, and this page shows you how to read it. It explains where raw Bayer exists inside a color camera, why an integrated depth-plus-RGB module keeps it off the wire, how to enumerate formats at the driver level with one command, and how to budget the bandwidth raw costs. It also tells you what to specify when raw is absent. If you buy cameras or integrate modules, you can settle the raw-Bayer question in five minutes, before a single line of integration code exists.

When does a color sensor's raw Bayer actually leave the camera?

A raw Bayer stream leaves the camera only when the device's own interface descriptors list one. The sensor almost always produces Bayer internally, but whether you can subscribe to it is decided by the firmware, not by the sensor die.

Every color sensor reads out one sample per pixel through its color filter array. That mosaic of red, green and blue samples is raw Bayer, and it exists in every color camera from the moment the analog front end digitizes. What differs is where the pipeline goes next.

A machine-vision area scan camera packs those samples onto the bus as BayerRG8 or BayerRG12, because raw is a primary product there. An integrated depth-plus-RGB module usually consumes the same samples internally, where calibration and depth-to-color registration need them, and offers only the demosaiced, white-balanced result on the interface. The sensor never stops producing raw; the interface decides whether you can subscribe. When the color sensor sits behind no ISP at all, the raw output is the only output — what raw sensor output means on a CSI camera with no ISP covers that case.

Why does the SDK list YUYV and RGB but never Bayer?

Because the SDK can only enumerate what the device itself advertises. On a module whose descriptors offer YUYV and RGB, the SDK's stream list shows exactly those, and a Bayer format that stays inside the module never appears anywhere.

Two lists are in play. The first is the SDK's own vocabulary of formats its code can name. The second is the format list the device advertises — carried in the USB descriptors of a USB video class camera, or in the GenICam feature XML a GigE Vision camera serves on request.

A stream's pixel format is selected against the device list, together with resolution and frame rate. A format the device never advertises cannot be selected, whatever the SDK's enum contains. That is why a module can carry raw-looking names in its code and still have no raw color stream: the vocabulary is bigger than the offer. The same device-side rule explains formats that refuse to change, as why a camera pixel format will not change describes, and options that sit greyed out in your software, as why a YUV 4:4:4 format is greyed out and what to use instead explains.

How do you list the formats the driver really exposes?

On Linux one command answers it. v4l2-ctl --device /dev/video0 --list-formats-ext prints every four-character format code with every resolution and frame interval the device advertises, before any SDK has filtered the list.

Install the v4l-utils package with your distribution's package manager, then run the command once per video node. A module with more than one sensor exposes several nodes, and the color sensor's formats live on their own node, so check each one. Read this output before you trust any SDK's stream list: the SDK sits on top of it and can narrow it, never widen it.

On a machine-vision camera the equivalent check is the PixelFormat enumeration in your GenICam feature browser. It shows the same kind of device-side truth, and it names each Bayer code explicitly.

How do you read the format list you get back?

Read the four-character code, not the marketing name. YUYV is processed 4:2:2 color that has already been demosaiced, white-balanced and subsampled. A code that names a Bayer pattern with a bit depth is the raw sensor sample.

The pattern letters describe the 2 × 2 block at the sensor's top-left corner. RGGB starts red-green over green-blue, and GR, GB and BG rotate the arrangement from there. A format is usable only at the resolution and frame-interval pairs printed beside it, and raw is sometimes offered at reduced rates.

An advertised bit depth can also exceed what the converter actually resolves, which is why a 10-bit sensor can ship 8-bit images, as ADC bit depth versus pixel format explains. And a listed format is an offer the consumer must honor: requesting a Bayer format the device never advertised produces the blank preview described in diagnosing an unsupported Bayer pixel format. If the color node ends at YUYV, RGB and MJPG, raw is not a stream on that device — a decision, not an omission.

How much bandwidth does raw Bayer cost?

Raw Bayer stores one sample per pixel, so it costs the same bytes as an uncompressed mono image of that bit depth: 1 byte per pixel at 8-bit, 1.5 packed or 2 unpacked at 12-bit, against 2 bytes per pixel for YUYV.

Worked example, a 4000 × 3000 color sensor at 30 fps:

• 8-bit raw: 4000 × 3000 × 1 B = 12 MB per frame; 12 × 30 = 360 MB/s.
• 12-bit raw, packed: 4000 × 3000 × 1.5 B = 18 MB per frame; 18 × 30 = 540 MB/s, about 4.3 Gbit/s.
• YUYV processed: 4000 × 3000 × 2 B = 24 MB per frame; 24 × 30 = 720 MB/s.

A GigE link moves about 115 MB/s of usable payload, so 12 MB frames give 115 / 12 ≈ 9 fps and 18 MB frames give 115 / 18 ≈ 6 fps. USB 3.0 moves roughly 400 MB/s usable: the 360 MB/s 8-bit stream fits with margin, the 540 MB/s packed 12-bit stream does not. The format choice keeps costing frame rate after the link too; frame rate limits from pixel format and exposure continues that arithmetic. Packed 12-bit also needs unpacking to a 16-bit container before most processing, which packed 12-bit Bayer conversion to a 16-bit image shows step by step.

What should you demand from a machine-vision camera instead?

Demand a camera that enumerates its own formats. On a GigE Vision or USB3 Vision machine-vision camera the GenICam PixelFormat feature lists every output the firmware supports on the first connect, and if BayerRG12 is in that list you can stream it.

Raw is the primary output on these cameras, not a calibration side door. Names follow one convention: Bayer, then the pattern (RG, GR, GB, BG), then the bit depth — BayerRG8, BayerRG10, BayerRG12 — with processed RGB8 or YUV options listed alongside where a camera offers them. Setting a name outside the enumeration raises the invalid-value error covered in checking GenICam symbolics before you set an enumeration, a guardrail rather than a mystery. To shop by the numbers that drive the link budget, the camera finder filters interface, resolution and shutter, and the camera configurator walks the rest of the stack. Two color GigE options across the resolution range:

The MV-CS200-10GC is the 20 MP color option on a 1" sensor; the MV-CU020-90GC is the 2.5 MP global-shutter color option for fast parts. Compact builds find the same explicit format lists across the board-level cameras range, in M12, CS-mount and bare-board form on USB3 and GigE.

When is a mono camera the better answer?

If your inspection does not need color at all, a mono camera removes the question entirely. The sensor has no color filter array, so its native output is a plain Mono8 or Mono12 stream with no demosaic, no interpolation and no white balance to manage.

Raw Bayer is still a mosaic: each pixel holds one color sample, and the other two are interpolated at your demosaic, which softens fine detail and roughly halves the true luminance resolution. When the defect is a dimension, a presence or a code, color adds nothing and mono delivers the finished image directly, with higher sensitivity because no filter blocks part of the spectrum at each pixel. For embedded builds, the board camera evaluation checklist walks the same decision at module level. Two mono parts in the classes above:

The MV-CS200-10UM is the 20 MP mono counterpart on USB3.0 with a C-mount; the MV-CB060-10UM-B is the 6 MP bare-board module on USB3.

Which checks do you settle before you commit?

Settle the device's own format list before you write integration code. Five minutes with one enumeration command decides the camera choice, and it costs nothing to run.

• Enumerate at the device level first: v4l2-ctl --device /dev/videoN --list-formats-ext per node over UVC, the PixelFormat enumeration over GenICam. The SDK list is a view, not a source.
• Look for a Bayer code at the color sensor's native resolution, with the frame intervals printed beside it.
• Divide the link budget: width × height × bytes per pixel × frame rate against about 115 MB/s usable on GigE or about 400 MB/s on USB 3.0.
• Plan the decode: packed 12-bit arrives at 1.5 bytes per pixel and unpacks to 16-bit; your demosaic runs after that if you need color.
• If the device lists no raw and the task needs it, change the camera — no SDK, driver or setting creates a format the device does not advertise.

One line settles most projects: enumerate, divide, decide. If raw Bayer is in the list, stream it; if it is not, pick a camera that names it, starting from the cameras topic page or the contact page with your resolution, interface and frame-rate numbers.