Camera Link transfer: is the image sent as Bayer or RGB?

A color camera on Camera Link raises a question the cable cannot answer: does the wire carry the raw Bayer mosaic, or finished RGB? Both exist on real cameras, and the choice decides your payload, the frame grabber's video format setting, and where the debayer step runs. If you are matching a Camera Link camera to a frame grabber — on a new build or a late camera swap — here is what you will be able to do: read the camera's tap configuration, compute the payload against the Base, Medium and Full ceilings, and bring the color up proven on the first bench session.

What the link actually carries

Camera Link is a hardware specification, roughly a hundred pages of it: driver and receiver chips, LVDS cable pairs, the frame-valid, line-valid and data-valid timing signals, and the mapping of pixel bits into taps. Its format tables say how bits travel, RGB888 included. They never say how a Bayer mosaic becomes that RGB — color interpolation is deliberately outside the standard, and that omission drives almost every color surprise on this interface.

A link runs at one of three widths, and every decision below hangs on the ceilings that follow. Base carries 24 pixel-data bits, Medium carries 48, Full carries 64, and the maximum pixel clock is 85 MHz:

Camera and grabber must agree on more than the connector. Shutter framing, bit depth and tap behavior all have to line up, which the piece on Camera Link camera and frame grabber compatibility walks through in detail. The buffer and DMA mechanics live in the guide to frame grabber image acquisition for Camera Link and CoaXPress.

Remember what the link is: a bit mover. It never translates formats. That is why an analog camera on a Camera Link frame grabber fails for the same family of reasons.

Raw Bayer crosses the link as monochrome

Most Bayer-filter cameras send the mosaic raw. Each photosite carries one color sample behind the filter array, and the camera streams those values with a plain monochrome mapping, typically 8, 10 or 12 bits per pixel across one or more taps. The payoff is bandwidth: 1 byte per pixel instead of 3, a threefold cut against every ceiling above.

The color comes back downstream. Each 2×2 block holds two green, one red and one blue photosite, and a debayer step interpolates them into three full-resolution planes. The Camera Link specification does not define that step, so the enable path differs per grabber and SDK: some cards debayer in silicon, some expose a library call, and many pipelines decode in host software. Until it runs, the frame looks like a striped grayscale image; the guide on recognizing a Bayer raw stream from an RGB camera shows the pattern.

Depth deserves a deliberate choice here. A 10-bit sensor does not automatically hand you 10 usable bits — the note on ADC bit depth versus pixel format explains why — and the guide to camera bit depth helps you pick 8, 10 or 12 on purpose.

RGB taps: prism cameras and cameras that decode internally

Two camera families put finished color on the wire. Prism, three-sensor designs split the light optically, so RGB is all they can send; the comparison of prism 3-sensor color cameras versus Bayer covers when that optical split earns its cost. Some Bayer cameras also decode internally and output RGB.

The typical RGB output is 24 bits per pixel — three 8-bit planes — in one or two taps, and most grabbers list RGB888 among their standard video formats and handle it in hardware. The trap is the two-tap case. Many 2-tap color cameras split odd and even lines across the taps, and a grabber that interleaves them in the wrong order produces line-pair striping in green and magenta. That is a format-setting fault, not a defective sensor, and it disappears once the tap order matches.

Worked example: a 5 MP color camera at 30 fps on a Base link

The case: a 5 MP color camera replaces a mono line and must deliver full resolution at 30 fps over an existing Base link. The inputs:

• Sensor 2448 × 2048 px, the common 5 MP 2/3-inch format sold across the area scan cameras range — illustrative, and typical of the class.
• Required frame rate: 30 fps.
• Candidate format 1: raw Bayer at 8 bits, 1 byte per pixel.
• Candidate format 2: RGB888, 3 bytes per pixel — the 24-bit RGB output most color cameras offer.
• Link ceilings from the math above: Base 255 MB/s, Medium 510 MB/s.

The rule, in words: payload in megabytes per second equals pixels per frame, times frames per second, times bytes per pixel, divided by a million — and the answer must sit under the link ceiling.

Arithmetic, step by step:

1. Pixels per frame: 2448 × 2048 = 5,013,504 px.
2. Pixel rate: 5,013,504 × 30 = 150,405,120 px/s, about 150 Mpx/s.
3. Raw Bayer, 8-bit: 150,405,120 × 1 B = 150.4 MB/s. Share of Base: 150.4 / 255 = 0.59, so 59% of the ceiling.
4. RGB888: 150.4 × 3 = 451.2 MB/s. Share of Base: 451.2 / 255 = 1.77, a 77% overrun. Share of Medium: 451.2 / 510 = 0.88, so 88% of a Medium link.

Result: raw Bayer 8-bit fits Base with about 105 MB/s to spare, which also lifts the ceiling to 255,000,000 / 5,013,504 = 50.9 fps at this resolution. RGB888 misses Base by 451.2 − 255 = 196 MB/s at 30 fps and consumes 88% of Medium, leaving little room for clock or tap changes.

Decision: configure the camera for raw Bayer 8-bit output and debayer on the host — Base carries the line with 41% of the link idle, and the pipeline survives a frame-rate bump to about 50 fps. If the camera cannot disable its internal decode and only outputs RGB888, the choices are a Medium or Full grabber, a lower resolution, or a different interface. The threshold to keep: once payload passes 255 MB/s, Base leaves the design.

10-bit and packed formats: where the multiplexer bites

Less common, and worth respecting: greater pixel depth, for example 10-bit color values carried inside 32-bit data words. Two things follow. Bandwidth inflates, because RGB888's 3 bytes per pixel become 4, a 33% increase. And the multiplexer that spreads the taps across the byte lanes is implemented per grabber, so two cards can both list a packed color format yet order the lanes differently — the same camera reads correctly on one card and scrambled on the next.

On FPGA-based frame grabbers the taps are merged by logic you write yourself, so a 2-tap color camera needs the odd and even line interleaving implemented explicitly and tested against a ruled target. Camera-side format changes ripple too: the note on changing pixel format halving frame rate and the one on pixel formats that refuse to change both come from the same linked-attribute chains.

Setting up and proving the color

1. Write down the tap configuration from the camera manual: video format name, bits per pixel, tap count, and the split rule between taps.
2. Set the camera output through the link's serial channel — the specification runs it at 9600 to 115200 baud with each manufacturer's CL protocol — to the chosen video format.
3. Match the grabber. In the frame grabber's configuration utility, select the video format that mirrors the camera's bits per pixel and tap order. If the utility stalls before you reach that list, the host side is the usual culprit; the fix for a camera configuration that stops responding starts there.
4. Choose the decode location. On-card debayer frees the host; host decode costs memory bandwidth equal to bytes per pixel times the pixel rate, so budget the decoded stream, not the raw one.
5. Prove the color. Image red, green and blue patches or a color-bar chart: each patch must light its own plane and leave the other two near zero. A red-blue swap or green-magenta striping means channel or tap order, not a failing sensor.

Among the frame grabbers we list, the Camera Link card to configure against is the MV-GC1102IOL.

When the design lets you choose the interface

On a new build, tap arithmetic is optional. CoaXPress negotiates the pixel format across the link instead of publishing a tap map. One CXP-6 connection carries a 6.25 Gbit/s line rate — about 625 MB/s of payload after encoding overhead, more than a full Base link per connection — and the path scales by adding connections. GigE Vision and USB3 Vision cameras negotiate formats over GenICam, so the Bayer-or-RGB question becomes a dropdown in the camera's feature browser rather than a format-table cross-check.

A frame grabber such as the MV-GX1008 takes the CoaXPress side of that equation at CXP-6.

The camera finder filters by interface, resolution and color, so the shortlist exists before any tap math starts.

Checks before you order

• The camera manual's tap configuration — format name, bits per pixel, tap count, split rule — is the source of truth, not a summary.
• Payload at your frame rate, from the formula above, against 255, 510 or 680 MB/s for Base, Medium and Full.
• The grabber's format list contains the camera's exact video format, plus a debayer function if the decode must run on-card.
• Host-decode budget: the decoded RGB stream triples the raw byte count.
• Packed 10-bit color in 32-bit words: lane order proven on the bench before either card is committed.
• Cable length from the specification's table for your configuration — it shrinks as clock and channel count rise.

If the payload math and the format list agree, the interface disappears from the project risk list. The frame grabber finder filters the cards by interface and ports, the configurator builds the acquisition chain around a chosen camera, and the systems topic page collects the neighboring interface fixes. For a camera-plus-grabber pairing you already own, send both manuals through the contact page and ask for the format table to be checked against the tap list.