Color camera memory bandwidth on an embedded vision controller

The camera connects, the preview shows a clean image, exposure settings change without complaint — and the moment the inspection runs on the controller, acquisition faults or dies a few seconds in, and nothing recovers until a reboot. When the mono version of the same setup runs happily, suspect one thing first: the memory budget was sized for mono, and a color camera tripled it. This page gives you the arithmetic that confirms it in five minutes, the causes ranked by how often they are guilty, the fixes in order of effort, and the RAM decision for the next controller. The whole method is one line: bytes per pixel × pixels × frames in flight.

The symptom: connected and previewing, dead at inspection start

Getting the camera talking is the easy half; the connection procedure for a GenICam camera on an industrial controller covers it. The failure this page is about happens later, in two shapes.

In the first shape, the inspection fails the moment it initializes acquisition on the target. The buffer pool it asks for — queue depth × bytes per frame, plus decode buffers — exceeds what the operating system leaves free. Nothing has flowed yet; the allocation itself is refused.

In the second shape, the inspection runs for a few seconds, then faults and locks acquisition until a reboot. That is a queue growing without limit while processing loses the race to the camera. Both shapes come from the same place: 3 bytes per pixel where the budget assumed 1.

Why a color camera triples the memory bill

An 8-bit mono frame is 1 byte per pixel, end to end. An 8-bit Bayer frame from a color sensor is also 1 byte per pixel, because the Bayer pattern stores one color sample per pixel — the raw frame is the same size as mono. The triple cost appears at the decode: demosaicing turns every pixel into red, green and blue values, and an RGB888 buffer stores 3 bytes per pixel. If the camera debayers on board and ships RGB888 over the link, the wire carries the triple as well as the RAM.

The other place the bill stacks is copies. An SDK that hands your code decoded RGB while the raw frame is still held keeps 4 bytes per pixel in memory where 1 would do. Decoding once, at the point of processing, keeps a single copy — see image bytes vs pixel data: decode before processing.

Bytes per frame by pixel format

Compute every camera at the format your SDK actually delivers, not at the sensor's name:

The right-hand column is the one that hurts. A 20 MP stream decoded to RGB888 moves 60 MB per frame; at 30 frames per second that is 1.8 GB per second of memory traffic before your algorithm touches a pixel. MB here means a million bytes.

The same bill lands on the wire for cameras that debayer on board. An IEEE 1394 bus reserves isochronous bandwidth per camera, so an RGB stream consumes the reservation three times faster than mono, and when the bus cannot allocate it the remedy is a lower frame rate or a smaller bit depth.

Worked example: 20 MP color on a controller with 8 GB

The MV-CS200-10GC is a 20 MP color camera on GigE.

Set the scene. The camera delivers RGB888 at 30 frames per second; the inspection keeps an acquisition queue of 10 frames plus 5 decoded frames in the processing pipeline; assume the OS and runtime leave 2.5 GB free, and measure that once on your own unit.

• One frame: 20,000,000 px × 3 B = 60 MB.
• Buffer pool: 15 frames × 60 MB = 900 MB, about a third of free RAM, so initialization passes.
• Incoming traffic: 30 frames/s × 60 MB = 1.8 GB per second the machine must move, convert and copy.
• If processing sustains only 20 frames/s, an unbounded queue gains 10 frames/s × 60 MB = 600 MB per second. Free RAM beyond the pool is 2,500 − 900 = 1,600 MB, so the controller is out of memory in 1,600 ÷ 600 ≈ 2.7 seconds. That is the fault that appears seconds after pressing start.

The mono side needs no new scene: 20 MB per frame, 600 MB per second of traffic instead of 1.8 GB, and the decode step disappears entirely because there is nothing to debayer. The algorithm that lost the race at 60 MB per frame sustains 30 frames/s at 20 MB per frame, the queue never grows, and the pool settles at 15 × 20 = 300 MB.

All 2 share: Sensor type CMOS, rolling shutter; Sensor model Sony® IMX183; Pixel size 2.4 μm × 2.4 μm; Sensor size 1"; Resolution 5472 × 3648; SNR 41.5 dB; Gain 0 dB to 24 dB; Binning Supports 1 × 1, 2 × 2, 4 × 4. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

Both come from the standard area scan cameras lines: one sensor, two delivered formats. The entire difference in behavior is the pixel format and the threefold memory bill that follows it.

Likely causes and the test for each

Rank by how often each turns out to be guilty, and test in this order:

1. RGB888 delivered where 8-bit Bayer would do. Read the pixel format your SDK receives, not the sensor name. RGB where the algorithm needs only intensity is the 3×.
2. An unbounded receive queue. Processing 20 frames/s against a 30 frames/s camera backlogs 10 frames per second forever. Log free RAM once per second during a run: a straight climb at exactly deficit × bytes per frame is this cause.
3. Duplicate copies. Raw frame kept, decoded frame kept, plus a 32-bit conversion of the decoded frame, is 1 + 3 + 4 = 8 bytes per pixel held. Free each copy the moment its replacement exists.
4. Buffers never returned. A frame that leaves the queue without its buffer being reused climbs even when the camera stops. The buffer-ownership discipline for camera memory in C# is the fix.
5. A crowded host. An HMI, verbose logging or a leftover process can halve the free RAM you sized against. Check free RAM before the camera is opened.

Fixes, smallest change first

1. Deliver 8-bit Bayer, decode at the point of processing. Acquisition buffers drop from 60 MB to 20 MB per frame, and only the frames you inspect pay the 3-byte price. If the defect lives in gray levels, decode to a single channel and never build RGB at all.
2. Bound the queue. A queue of 5 frames plus 2 decode buffers holds 7 × 60 MB = 420 MB worst case, forever. For queue mechanics and reuse patterns see bounding the frame queue and reusing buffers; when the deficit is structural, the fixes for processing slower than acquisition apply.

3. Shrink the ROI to the defect. A 1280 × 960 window is 1,228,800 px; in RGB888 that is 3.7 MB per frame instead of 60 MB — a 16-fold cut for the price of one setting.
4. Go mono when color decides nothing. The MV-CS200-10UM is the worked example's sensor without the color filter array. Mono cuts each frame to a third of the bytes and a third of the host traffic, and the missing filters leave more light on every pixel.
5. Buy the RAM the math demands. If the inspection genuinely needs full-frame RGB from several cameras, no setting rescues an undersized controller. The next section sizes the replacement.

Each fix is provable in minutes with the free-RAM log from the cause list.

Sizing the next controller

Carry one rule out of the worked example: keep the buffer pool at or under half of measured free RAM. The other half absorbs OS spikes, decode bursts and fragmentation, and that margin is what keeps a three-hour shift from becoming a three-second fault. For two cameras sharing one machine the same multiplication runs per camera; the sizing walkthrough for a two-camera embedded vision system shows the pattern.

A single 20 MP color camera with a bounded queue and 8-bit Bayer delivery is the easy case. The MV-VC3301H-128G66 handles it with room to spare: an Intel Core i3, 8 GB of RAM, a 128 GB SSD and 4 built-in light channels.

Two to four color cameras sharing one controller need the next step up. The MV-VC5525-256G70-NN provides it with 32 GB of RAM, PoE camera ports and 8 built-in light channels.

Once the RAM math is on paper, browse the full range of vision controllers and filter by RAM, LAN ports and PoE camera ports to the shortlist.

When the memory answer is wrong

Mono delivered, ROI shrunk, queue bounded — and the inspection still faults at initialization. Then memory was never the culprit, and the suspects change:

• The camera claimed twice. Two driver stacks binding one camera leave the resource locked, and acquisition fails however much RAM is free. One driver wins; remove the other.
• Another acquisition source stalling the pipeline. Multi-camera setups fail in ways that look like single-camera faults; the diagnosis for acquisition stalls from multiple sources separates them.
• The link, not the RAM. Two USB3 cameras at full resolution can exhaust the host controller before RAM is in question; the host USB buffer fix treats that case, but only after the frame math above has ruled memory out.
• A permission refusal at the SDK layer, which mimics an acquisition fault exactly. It fails identically on mono and color, which is the tell.

One run of the free-RAM log separates all four: memory problems either refuse to allocate or climb; everything else fails flat.

Checks before you order

Run the list with numbers, not hope:

• Compute bytes per frame for every camera at the format the SDK will actually deliver.
• Multiply by queue depth plus pipeline frames; the pool must fit at or under half of measured free RAM.
• Confirm the decode location: camera-side RGB888 triples the link as well as the RAM; host-side 8-bit Bayer keeps the wire at 1 byte per pixel.
• Count cameras against LAN ports, and check for PoE camera ports before splitter hardware enters the plan.
• Size against free RAM you measured on the running system, not the RAM total on the spec line.
• Keep one log line printing free RAM per second in production, not just during commissioning.

Ten minutes with a spreadsheet settles all six.

The decision, case by case

• Color carries the defect — seal hue, wire insulation, stains, mix-ups between similar-colored parts. Keep color: deliver 8-bit Bayer, bound the queue to 5–10 frames, decode only the region you inspect. A single 20 MP stream then runs in any controller with at least 2.5 GB of free RAM.
• Gray levels carry the defect. Go mono: a third of the bytes, a third of the host traffic, more light per pixel, same lens and working distance.
• Several 20 MP color cameras on one box. 16 GB of RAM is the floor, 32 GB is comfortable; the sizing section names the two controllers that land on either side.
• An older controller with 2 GB free or less. Shrink ROI and bound the queue today, deliver mono if the inspection allows it, and re-spec the box with the arithmetic above before full-frame color returns to the plan.

Size it once, log it forever: keep the pool under half of measured free RAM and this fault stays gone. More acquisition-side limits are collected on the systems topic page. If you want the arithmetic checked against a specific camera and controller pair before you order, send the frame rates and pixel formats through the quote form or the contact page, and the team will run the numbers with you.