Display multiple cameras on one screen without a splitter

A sorting loop, an assembly cell or a test bench runs two to sixteen cameras, and the operator wants every picture on one display. The old recipe — an analogue matrix switcher feeding a quad or 16-way splitter — still gets specified out of habit. A modern machine-vision workstation needs none of it: each GigE or USB 3 camera delivers full-resolution frames as its own stream, and one application window composites those streams into panes. This guide shows how the compositing works, the bandwidth arithmetic that decides how many cameras one PC can carry, and the layout and buffer settings that keep every pane live.

What the matrix-and-splitter chain actually did

Analogue composite video carried one picture per cable, on a 480 to 576-line standard. A matrix switcher routed any camera to any monitor; a quad or 16-way splitter merged four or sixteen inputs into one video output, so a single monitor showed every station. The lines divided across the panes: a 16-way wall left roughly 120 to 144 lines per pane, enough to see that a station is running and nothing more.

Digital machine-vision interfaces removed the bottleneck. Each area scan camera puts its full frame on its own stream, and the merge moved into software on the PC. The splitter survives in two places: a legacy analogue wall, and a monitor that must run with no PC at the line. If the actual need is a second operator display, live camera display on a second monitor without a frame grabber covers that case on its own.

How a workstation composites the streams

A multi-camera window has five working parts, each with a known failure mode:

1. Discovery and open. Open the cameras one after another, not all at once. Simultaneous discovery broadcasts collide at startup, which reads as cameras missing from the list — see camera discovery startup contention.
2. One acquisition object per camera. Even inside one process, each camera keeps its own acquisition object and handles; multiple GenTL cameras in one process shows what breaks when two cameras share one.
3. A frame queue per camera. Each acquisition fills its own small queue, so one slow consumer cannot stall the others.
4. A draw loop. A UI timer takes the latest frame from each queue and paints its pane; displaying OpenCV video in a Tkinter window without flicker is a good reference for the paint side.
5. Processing threads that never touch the screen. Inspection runs on untouched full frames; multi-camera acquisition session architecture is the working design.

The window is a viewer, not the acquisition path. That separation lets a four-camera wall run beside a demanding inspection without either starving the other.

The bandwidth math that decides the capture chain

Bandwidth, not screen space, decides how many cameras one PC carries. Two multiplications size it:

Bytes per pixel: Mono8 is 1, RGB8 is 3, unpacked 10- or 12-bit is 2. A GigE port moves 1 Gb/s — 125 MB/s of line rate, roughly 110-120 MB/s of usable payload after protocol overhead. Size every port at 90 MB/s or less so retransmissions have room.

Typical continuous streams work out like this:

Multiply by three for RGB8: a 5 MP color stream at 15 fps is 225.6 MB/s and moves to 10GigE. Two cameras may share one GigE port when their combined rate stays under 90 MB/s; above that, each camera gets its own port. USB 3.0 and 10GigE carry the heavy rows, and 5GBASE-T camera interfaces: bandwidth, cables and distance covers the intermediate option. The cards that provide the ports live in the frame grabbers category and its accessories finder.

Worked example: four 5 MP GigE cameras on one 1080p screen

The inputs

Four cameras, each 2448 × 2048 Mono8 — the pixel count of a typical 5 MP machine-vision sensor, standing in for your camera list. Each runs 15 fps, a realistic continuous GigE rate at this resolution. The monitor is 1920 × 1080. The hardware being sized is a quad-port GigE NIC.

The rule and the arithmetic

Per camera:

• Frame size: 2448 × 2048 = 5,013,504 B ≈ 5.0 MB.
• Rate: 5,013,504 B × 15 fps = 75,202,560 B/s ≈ 75.2 MB/s.

All four cameras: 75.2 × 4 = 300.8 MB/s, about 2.41 Gb/s. One GigE port cannot carry that — 300.8 MB/s is close to triple the ~115 MB/s a port delivers. One camera per port loads each port to 75.2 ÷ 115 = 65%, under the 90 MB/s plan value. Two cameras per port would need 150.4 MB/s and would drop frames within seconds.

The decisions

• Capture: a quad-port GigE NIC, one camera per port, each camera on its own subnet. The MV-GE1104 quad-port GigE frame grabber is this layout: four ports, one camera each.

• Monitor: a 2 × 2 grid gives each pane 960 × 540 pixels. The vertical display scale is 540 ÷ 2048 = 26%, so a feature spanning 40 sensor pixels shows as about 11 screen pixels — judgeable. Defects below about 30 sensor pixels fall under 8 screen pixels; the operator flags the part and the inspection thread measures it on the full frame.
• Processing: each inspection thread reads full 2448 × 2048 frames from its camera's queue. The panes never carry measurement pixels.

If the same enclosure must also drive lighting and line logic, one controller covers the whole chain. The MV-VC3301H-128G66 pairs an Intel Core i3 with 8 GB of memory, 5+ LAN ports and 4 built-in light channels, and includes a vision software license.

Pane layout: the monitor's pixel budget

Divide the monitor by the grid and check what survives. On 1920 × 1080:

• 2 × 2 grid → 960 × 540 per pane
• 3 × 3 grid → 640 × 360 per pane
• 4 × 4 grid → 480 × 270 per pane

Pane scale is pane height ÷ sensor height. A feature F sensor pixels tall shows as F × scale screen pixels, so keep anything an operator must judge at 8 screen pixels or more. Below that, add a click-to-enlarge pane or a dedicated ROI view: splitting one camera image into multiple ROIs and displaying each is the ROI route, and controlling vision display window size and screen position handles the geometry.

Mind the aspect ratio too. A 2448 × 2048 sensor is roughly 6:5, so a 16:9 pane crops or letterboxes it, and the scale follows whichever axis binds first. The wall is for humans; the measurement stays on full frames in the processing thread.

Buffering and refresh: keep the panes live

Set each camera's stream buffer to newest-only so a pane always paints the current scene; stream buffer handling mode, set newest only names the exact transport-layer setting. With default queuing, a slow draw loop backs up frames and every pane drifts seconds behind the line.

Keep acquisition callbacks lean and let a UI timer pace the painting. When drawing happens inside acquisition callbacks, queues overflow and the window stalls — the callbacks and buffer queues failure is the classic multi-camera freeze. A pane that paints torn or shifted is display timing, not camera timing: diagnosing machine vision screen tearing separates the two. A persistently black pane is usually configuration: the blank image window checklist works through it.

Free-running cameras refresh their panes independently. When two panes must show the same instant — a part crossing two stations — trigger them from one pulse source; a square-wave trigger for five cameras is a bench-proof way to test the wiring before committing.

Matching capture hardware to camera count

Count cameras, add their MB/s, then pick the card shape:

• Two GigE cameras: a dual-port PoE NIC gives each camera its own port and powers it over the same cable.
• Four GigE cameras at moderate rates: the quad-port GigE layout from the worked example, one camera per port.
• Four or more 10GigE cameras, or 12 MP streams: a quad-port 10GbE NIC carries four heavy rows of the table at once.
• USB 3 cameras: a quad USB 3.0 adaptor, one camera per controller port group.
• A bank of CoaXPress cameras: an octo CXP-6 frame grabber takes the bank onto one card.

When the cameras, lighting and line logic should live in one fanless box instead of a tower plus cards, start from the vision controllers category — the LAN-port and light-channel filters narrow it fast. The cameras finder narrows the camera side by interface and resolution.

Where the splitter still wins, and where it fails you

A matrix-and-splitter wall still earns its place with legacy analogue composite cameras, and on front-line monitor walls that must work with no PC nearby. It fails everywhere else. It cannot accept a GigE, USB 3 or CoaXPress output without a capture step in front of it. It discards sensor resolution before the picture reaches glass — a 5 MP frame squeezed into a 144-line pane keeps about 7% of the height. And it merges pixels before software ever sees them, so there is nothing per-camera left to measure. If inspection is the job, streams-in-one-window wins; keep the splitter for the analogue wall only.

Checks before you build

• Sum width × height × bytes × fps per port, and keep every GigE port at 90 MB/s or less.
• Prefer one camera per port; share a port only when the combined sum stays below the plan value with margin.
• One acquisition object, one queue, newest-only buffer per camera.
• NIC ports: camera count plus at least one spare for configuration and PLC traffic.
• Color cameras multiply bytes per pixel by three — redo the sum before ordering.
• Pane check: feature pixels × (pane height ÷ sensor height) ≥ 8 screen pixels for anything an operator must judge; otherwise add ROI panes or click-to-zoom.
• Trigger plan if two panes must show the same instant.

The decision for each case

• Two cameras, one window: dual-port PoE NIC, side-by-side panes, newest-only buffers.
• Four 5 MP GigE cameras at 15 fps: quad-port GigE NIC, one camera per port at 65% load, 2 × 2 panes at 960 × 540.
• 12 MP or 4K streams: one 10GigE or USB 3 port per camera — 248.8 to 294.9 MB/s exceeds any shared GigE plan.
• Sixteen stations, overview only: any supported capture chain, 4 × 4 panes at 480 × 270 for status, ROI panes for judgment.
• Cameras plus lighting plus line logic in one box: a vision controller with 5+ LAN ports.
• Legacy analogue wall: matrix switcher and splitter, with inspection happening elsewhere on the full streams.

Size your own camera list with the numbers above, then specify the chain in the configurator or send it through requesting a quote. The systems topic page collects the other display and streaming fixes, and the contact page reaches the applications team when the camera list is unusual. In-stock items ship within one business day.