How to mix camera brands in one vision software stack

You run cameras from two makers on one line, and each maker's software lists only its own cameras. That wall is built into the viewers, not into the cameras: behind it sits a standards layer — GigE Vision, USB3 Vision and GenICam — designed precisely so one program can drive cameras of any brand. Here is why brand tools behave this way, how a GenTL-based acquisition stack enumerates a mixed line, the bandwidth arithmetic that decides the cabling, and the checks to run before the next camera order. It is written for integrators maintaining multi-brand inspection lines — X-ray, electronics assembly, packaging — where moving every camera to a single maker is not an option.

The decision: one standards layer under one application

Stop trying to make one maker's viewer list another maker's cameras. No preference, flag or license opens a brand viewer to third-party devices, because discovery in that viewer is bound to the transport layer shipped with it. Replace the viewer with a standards-based layer and let it enumerate everything:

1. Every camera sits on a standard link — GigE Vision, USB3 Vision, 10GigE or CoaXPress. Reserve Camera Link for cameras a grabber explicitly supports.
2. One acquisition stack — a GenICam GenTL-capable SDK, a vision package that loads transport producers, or a multi-brand frame grabber SDK — enumerates and controls all cameras through one API.
3. The makers' own viewers stay on the engineering PC as maintenance tools; they never appear in the production path.

Choosing that layer is the same decision as choosing data acquisition software for a mixed-instrument test cell: one API above hardware from several makers — selecting data acquisition system software for a test cell sets out the criteria to weigh.

At order time the test is short: the data sheet names the standard and its version, the maker ships a transport-layer producer with its SDK, and the feature list covers everything your code touches. Filter the area scan cameras catalog by interface first; that single filter removes most of the mixing risk before it exists. A mixed line can look like this — a 6 MP GigE mono camera from one maker beside a 12 MP USB3 camera from another, both in one device list:

Why a brand viewer only lists its own cameras

A vision program never talks to a sensor directly; it asks a transport layer to find devices, open them and stream pixels. The transport layer sends the discovery queries and decides which answering devices to report. A brand viewer ships with exactly one transport layer — its maker's — and that layer reports only the devices it recognizes as its own, often filtered by the maker's device ID. Both cameras can be fully standard-compliant and still invisible to each other's tools; the tool simply never asks.

The reason is commercial, not technical. Makers test their software against their own cameras, and a discovery list is a support promise, so they keep the list to what they test. The standard obliges the camera to answer standard queries; it does not oblige a maker's viewer to ask about anyone else's camera. The same mechanism explains why one utility works and another fails on the same PC — frame grabber SDK support: why one viewer works and another fails traces that failure from the SDK side.

One rule of the road follows: a camera is held by one application at a time. Your stack takes exclusive control of every camera it opens, so close the brand viewers before the production application starts — the failure mode is exactly GigE camera open fails in a second tool: exclusive control.

How one stack controls every brand

Three standards carry a mixed line:

• GigE Vision defines device discovery on the network, a control protocol and a streaming protocol. Any compliant camera answers any compliant stack.
• USB3 Vision applies the same pattern over USB: standard enumeration, standard control, standard streaming.
• GenICam defines how a camera describes itself. Each camera carries its feature dictionary — an XML file the host reads at enumeration — with names from the Standard Features Naming Convention: ExposureTime, Gain, PixelFormat, Width, Height, TriggerSource, AcquisitionStart.

Because the camera describes itself, your code never carries a per-brand register map. You set ExposureTime in microseconds on camera A and camera B through the same call; access GigE camera registers at runtime from your control code shows what that looks like in practice. Read camera compatibility with vision software: what GigE Vision guarantees before you commit the application — it separates the guarantees from the habits.

GenTL is the piece that mixes brands. It splits the world into producers — transport-specific libraries from each camera or grabber maker — and consumers: your SDK or vision software, which loads any producer. Install each maker's producer once, point the consumer at all of them, and one device list appears with every camera in it. Open-source libraries ride the same rails, with the tradeoffs laid out in open source machine vision software: integration tradeoffs.

Camera Link and CoaXPress: the two exceptions

Camera Link defines the cable, the signals and the pixel format — not discovery, not a register map. A Camera Link camera cannot describe itself to software, so the frame grabber maker supplies per-camera support files. Confirm the exact camera model is on the grabber's support list before ordering: Camera Link camera and frame grabber compatibility: what must match lists what has to line up, and will your camera work with a frame grabber? compatibility checks covers the wider chain. Without a support file you are into the grabber's generic camera dialog and the camera's serial interface, configured by hand — fine for one camera, miserable for ten.

CoaXPress is the opposite case: standard discovery, a control channel from the GenICam family, and data, triggering and available power on one coax run. A CXP grabber enumerates any compliant camera on its links. For electrically noisy X-ray bays and long fiber runs, an XoF frame grabber with 4 ports, an SFP+ slot and 40G total bandwidth supported keeps the data path away from the generator:

On the copper side, an octo CXP-6 frame grabber enumerates every compliant camera on its links:

Acquisition through both grabber families is laid out in frame grabber image acquisition for Camera Link and CoaXPress.

Bandwidth arithmetic decides the layout

Mixing brands changes discovery, not physics. Each camera still streams at its own link rate, and that rate decides the interface each camera needs:

Typical usable payload for planning, with the on-paper figure beside it:

Worked example, a two-brand cell. Camera A, brand one: GigE Vision, 4,000 × 3,000 pixels, mono 8-bit, target 25 fps. Camera B, brand two: USB3 Vision, 3,000 × 2,000 pixels, mono 8-bit, target 40 fps.

• Camera A: 4,000 × 3,000 × 1 B = 12 MB per frame. 12 MB × 25 fps = 300 MB/s, or 2.4 Gb/s. A 1 Gb/s link tops out near 115 MB/s, so 25 fps does not fit. Decision: order camera A as a 10GigE model — 300 MB/s is about 27% of a 1,100 MB/s link — or stay on GigE Vision and accept 9 fps (12 MB × 9 = 108 MB/s, 94% of the ceiling, tight). Cropping to 4,000 × 900 pixels at 25 fps needs 90 MB/s and also fits, if the algorithm tolerates the smaller frame.
• Camera B: 3,000 × 2,000 × 1 B = 6 MB per frame. 6 MB × 40 fps = 240 MB/s, or 1.92 Gb/s. That uses 60-69% of the USB 3.0 ceiling, inside the 25% margin rule, so camera B stays on USB3 Vision with its own port — no hubs on a production line.
• Host side: 300 MB/s + 240 MB/s = 540 MB/s, or 4.32 Gb/s, across two cards — any modern PCIe x4 slot carries that.

If camera A later moves to 12-bit packed pixels (1.5 B per pixel), a frame grows to 18 MB and 25 fps needs 450 MB/s — still comfortable on 10GigE, unreachable on 1 Gb/s.

Distance and cable choice follow from the same numbers, and 5GBASE-T sits between the two Ethernet rates: 5GBASE-T camera interface: bandwidth, cables and distance. For the layout rules — one camera per port, the IP plan, trigger distribution — read multi camera system design for reliable image capture.

The same host carries all three transports: a 4-port GigE frame grabber for the slow cameras, a quad-port copper 10GbE NIC for the fast one, a quad USB3.0 adaptor for the USB3 Vision cameras:

Each GigE camera gets a 3 m high-flex drag-chain cable with screw locks, so vibration never loosens a connector:

Longer runs and other connector styles are in cables; the host cards are in frame grabbers.

Checks before the next camera order

Run these on one demo unit, inside your stack, before the purchase order goes out:

1. The data sheet names the standard and its version — 'GigE Vision compliant' with a version number — not just 'GigE interface'.
2. The maker ships a transport-layer producer with the SDK, and the camera enumerates in a third-party GenTL consumer, not only in the maker's own viewer.
3. Every feature your code touches exists under its standard name: walk ExposureTime, Gain, PixelFormat, TriggerSource and AcquisitionStart end to end and read the values back.
4. The camera accepts packets near 9,000 bytes if a 1 Gb/s link will run near its ceiling.
5. Firmware updates run through the standard interface or a supported tool from the maker — no bench-only procedures on a production line.

When the standards path is the wrong path

• A camera that ships only a closed SDK never appears in a GenTL device list. Some X-ray flat-panel detectors and specialized linescan heads are built this way. Keep it on its own SDK and bridge the frames into your application, or buy a standard-link camera when a replacement comes due.
• Vendor-proprietary features — on-camera defect correction, calibration uploads, exotic trigger modes — sit outside the standard feature names. If the algorithm depends on one, that camera is single-brand whatever the data sheet says.
• UVC and MIPI cameras are not GenICam devices; they capture through the operating system or board-specific drivers, and the mismatch surfaces as UVC camera not detected by software: choose the right capture path. Keep them out of the stack.
• A line that will stay single-brand does not need any of this. The standards layer earns its cost the day the second brand arrives or the first one is discontinued.

Pre-order checklist

• Standard and version named on the camera data sheet.
• Transport producer installs, and the camera enumerates in a third-party consumer.
• Needed standard features present and settable from your code.
• Payload per camera computed with the formula above, at least 25% of each link left free.
• Jumbo packets supported where a 1 Gb/s link runs near its ceiling.
• Camera Link only with a grabber support entry for the exact camera model.
• Brand viewers kept off the production PC image, or set not to auto-start.

Once the layout is settled, the camera finder narrows by interface and shutter, and the accessories finder covers grabbers and cables. The system configurator walks camera, lens, light and controller in one pass; if a camera needs a non-standard SDK, raise it with us through the contact page before it joins the line.