Record color video when your camera outputs Bayer images

You press record, the clip comes out gray, and the live view may even show color or a faint maze pattern. In nearly every case the cause is the pixel format: the camera is streaming a Bayer format such as BayerRG8 — raw mosaic data with no color decoded yet — and the recorder saved the frames without a debayering step. This page explains what a Bayer stream is, why recording tools trip on it, and the two reliable fixes: switch the camera to RGB8, or record Bayer and convert on the host. Anyone recording from GigE or USB3 machine-vision cameras in an SDK viewer or in their own code can apply both fixes today; the bandwidth arithmetic tells you which one your interface survives, and all you need is your camera's resolution, frame rate and pixel-format list.

Why a Bayer stream has no color yet

A color sensor places a microscopic filter over each pixel in a fixed 2 x 2 pattern — one red, one blue, two green sites (Bayer filter). Each pixel therefore measures a single color component; the two missing components are estimated afterwards by a demosaicing step. Someone must run that step, in the camera or in software. Until it runs, the frame is a gray-looking mosaic that encodes color by pixel position.

Pixel formats name this state directly. BayerRG8 means an 8-bit Bayer mosaic in RGGB order, one byte per pixel. RGB8 means three 8-bit channels per pixel — debayered color. If the camera's PixelFormat feature reads BayerRG8 (or BayerGR8, BayerGB8, BayerBG8, and their 10- and 12-bit variants) while you record, the recorder receives mosaic data, not color frames. Why a 10-bit sensor can still ship 8-bit images is its own topic in ADC bit depth versus pixel format.

What the recording tool does with mosaic frames

Live view and recording are separate paths. Many viewers debayer automatically for display; the record path often writes exactly what the SDK hands it. A Bayer frame pushed into an encoder that expects RGB or YUV produces one of three outcomes: a monochrome-looking file, a rejected format, or a playable clip full of maze texture.

Grab one frame and look at it before changing anything:

• Live view gray as well: the camera or viewer is delivering the wrong stream, which is stream selection rather than a recording bug — the fix is in camera images black and white: select the color stream.
• Live view color, recording gray: the conversion is missing on the record path. Both fixes below work.
• A raw stream has tells even before recording; how to recognize a Bayer raw stream from an RGB camera lists them.

Fix 1: switch the camera to RGB8

Every GigE Vision and USB3 Vision camera exposes the GenICam PixelFormat feature in its feature browser. Setting it to RGB8 moves the debayering into the camera; the recorder receives true color frames and nothing in your recording workflow changes.

The cost is bandwidth: RGB8 triples the bytes per frame, and frame rate follows the link, as the BGR vs Bayer on GigE frame-rate drop case shows. The next section puts numbers on exactly how much you lose.

The arithmetic that decides it

Stream bandwidth is pixels per frame, times bytes per pixel, times frames per second:

Bytes per pixel by format: Mono8 and BayerRG8 are 1, YUV422Packed is 2, RGB8 is 3. The link sets one ceiling and the sensor sets the other; the lower wins. Practical link ceilings: GigE is 1 Gbit/s = 125 MB/s theoretical, about 110 MB/s after protocol overhead; USB 3.0 is 5 Gbit/s = 625 MB/s theoretical, about 400 MB/s in practice. Dividing the link rate by MB per frame gives the fps ceiling:

If the ceiling is still above what you need, RGB8 is the easy answer. A middle ground helps when it exists: YUV422Packed costs a third less than RGB8 and trades some chroma resolution for it; availability varies per camera, and the YUV 4:4:4 packed greyed-out explainer covers the case where your camera does not list it.

Worked example: 12 MP USB3 camera at 30 fps

Inputs, each with its source:

• Resolution and frame rate: 4000 x 3000 px and 30 fps, from the camera data sheet. The LS-CMR-0166 is a concrete example of the class: 12 MP on a 1/1.7-inch sensor, USB3.
• Bytes per pixel: 1 for BayerRG8, 3 for RGB8, from the GenICam format definitions.
• Link budget: about 400 MB/s practical on USB 3.0, from the 5 Gbit/s = 625 MB/s theoretical rate minus protocol overhead.

The rule in words: stream bandwidth equals pixels per frame, times bytes per pixel, times frames per second.

The arithmetic:

• BayerRG8: 4000 x 3000 = 12,000,000 pixels = 12 MB per frame. 12 MB x 30 fps = 360 MB/s.
• RGB8: 12,000,000 x 3 bytes = 36 MB per frame. 36 MB x 30 fps = 1080 MB/s.
• Compare: 1080 MB/s exceeds even the 625 MB/s theoretical USB 3.0 ceiling, so 30 fps in RGB8 cannot fit. The practical ceiling is 400 / 36, about 11 fps; with zero overhead the link would still cap at 625 / 36, about 17 fps.

Result and decision: at this resolution, RGB8 caps the recording near 11 fps — a 63% cut against the sensor's 30 fps. Above roughly 400 MB/s of RGB8 demand, a USB 3.0 link cannot carry full-rate color, so record BayerRG8 at 360 MB/s and debayer on the host, or move the camera to 10GigE, whose practical rate of about 1.1 GB/s carries 1080 MB/s with thin margin. The 360 MB/s raw stream also needs storage that sustains it; the practicalities are in streaming camera images to disk at high frame rate.

Fix 2: record Bayer and debayer on the host

Keep PixelFormat on BayerRG8 and let the sensor run at full speed. Capture each mosaic frame, run it through the SDK's pixel-format conversion to RGB8, and hand the converted frame to the encoder. The recorder sees color; the sensor never slows down.

The conversion is one call in mainstream machine-vision SDKs: an image processor takes the captured Bayer frame plus the target format, RGB8, and returns the debayered image — the save-to-video examples that ship with SDKs show the pattern. Budget CPU for it, because the conversion triples the data rate through memory: give the stream its own core and measure per-frame latency before promising a write rate. A Python walk-through of capture plus encoding is in recording video from a machine vision camera in Python.

Recording raw also buys quality control: you choose the demosaicing algorithm — bilinear for speed, edge-aware for detail — and can re-process archived footage without re-shooting, at a third of the disk use of RGB8. If your camera runs 12-bit packed formats, packed Bayer 12-bit conversion to a 16-bit image covers decoding before display, and the sensor side of color is in the color filter array explainer.

Which fix fits your case

• 2-5 MP camera on USB 3.0, target rates in the tens of fps: set RGB8 and record; the ceilings (about 67 fps at 2 MP, 27 fps at 5 MP) sit above most sensors' own limits, so nothing else changes.
• 2-5 MP camera on GigE: RGB8 works up to the ceiling (about 18 fps at 2 MP, 7 fps at 5 MP); beyond that, record Bayer and convert on the host.
• 12 MP and up on USB 3.0: record BayerRG8 and debayer on the host unless your rates sit at or below about 11 fps.
• High resolution on GigE: the interface is the bottleneck for both formats at full rate, so plan for 10GigE or CoaXPress if you need color video at speed, or accept the reduced rates.

If the camera itself is still an open choice, the split shows up directly in current hardware. The MV-CU020-90GC is a 2.5 MP color GigE camera with a global shutter, at the easy end of the table. The MV-CS200-10GC is a 20 MP color GigE camera on a 1-inch sensor. At that resolution RGB8 is 60 MB per frame, about 2 fps on the link, so record Bayer and convert on the host, or move to a faster interface.

Checks before you hit record

1. Read the PixelFormat feature from the camera itself, not from the software's assumption: any BayerRG8, GR8, GB8 or BG8 value means raw mosaic is arriving.
2. Grab one frame and view it at 1:1: smooth gray means mono output, maze texture means undecoded Bayer, true color means RGB or YUV is flowing.
3. Compute the stream with the formula above and compare it with the practical ceiling for your interface.
4. After any pixel-format change, re-read frame rate and exposure from the camera; if saved stills look brighter than the clip afterward, the exposure path differs, as video exposure and frame rate explains.
5. Check the storage side against the rate you computed: a raw stream of that size wants an NVMe drive or a compressed encoder.
6. Run a 10-second test recording and step through individual frames before the real take.

If you are choosing hardware for the recording task rather than fixing an existing one, the area scan cameras category and the camera finder filter by interface, resolution and shutter, and the camera configurator walks the whole chain from sensor to cable. More acquisition and streaming guides sit on the systems topic page, and contact us when a specific rig needs a second opinion.