Run vision Python onboard the camera or on the host

Where does the vision code actually run? On a camera with no user-programmable processor, your Python runs on the host, and every pixel has to cross the cable to get there. That one fact sets the camera choice, the cable, the host sizing and, for robot guidance, the latency budget. This guide sorts the hardware into three classes — sensor-only camera modules, smart cameras and vision controllers. It gives the bandwidth arithmetic that decides between them, and ends with the decision for each common set-up.

The decision in one line

Run your Python onboard only when the device carries a processor that accepts deployed code: a smart camera or a vision controller. A sensor-only camera module — a board camera, or a camera connected by flat-flex ribbon — has no user CPU at all. Its 'Python' is a host-side script that pulls raw frames over USB3 or GigE and processes them on your PC.

One case needs naming. Modules built around an embedded vision SoC do run work onboard: a host-side Python API builds a pipeline graph of image stages and neural models, and the SoC executes that graph frame after frame. Your script still lives on the host, though — the module runs the graph, not an interpreter. You cannot open a shell on it.

So the rule: go onboard when the raw stream exceeds the link, or when the inspection must run standalone. Go host when you want the full library ecosystem and fast iteration on one machine that also holds your data.

What each hardware class can run

Sensor-only board cameras and ribbon modules

A board-level camera is a sensor, its timing logic and a connector, nothing more. The MV-CB016-10GM-M-W is a 1.6 MP mono GigE board camera with an M12 mount and a global shutter: it streams raw frames to any host with a network port and does no processing of its own. The MV-CB060-10UM-B ships as a 6 MP USB3 bare board with no lens mount, made to be built into your own optics.

Flat-flex modules split the same way. A pure sensor board crosses every pixel over the ribbon to the host processor. An SoC module runs its vendor-defined pipeline onboard and ships processed outputs across the ribbon instead — still no Python on the module. In both cases your code runs on the host; the difference is how many pixels the cable carries. The ribbon itself reaches only centimeters, so the host sits beside the sensor.

Smart cameras and vision sensors

A smart camera carries the processor, the development stack and usually the lens and light in one housing: the inspection runs on the device and only results cross the network. The shop's smart-camera category says it directly — inspection on the device, no PC. You build or configure the program in a host tool, deploy it once, and the camera runs unattended. Matching the SDK to the camera's firmware before you deploy is its own step, covered in Deploy custom code to a smart camera: match SDK and firmware versions.

Two examples from the ends of the range. The LS-SMC-0063 is a 1.6 MP smart camera rated 60 fps with a fitted 16 mm lens and integrated white light — the fixed-lens, run-it-out-of-the-box kind. The MV-SC5060XM-08M-WBN is a 6 MP mono smart camera of the SC5000X series with an M12 mount and a GigE interface — the programmable kind that takes deployed inspection code, including custom detection models: see Running custom object detection models on embedded smart cameras. For how SoC camera boards and smart cameras trade off on detection work, see Edge object detection: SoC camera boards vs smart cameras.

Vision controllers

A vision controller is a fanless industrial computer built around cameras: several dedicated LAN ports, PoE options and built-in light-controller channels. Your Python runs there with a full operating system — OpenCV, deep-learning runtimes, anything you install — and the cameras hang off its ports. The MV-VC5525-256G70-NN pairs a 12th-generation Intel Core i5 with 32 GB of memory, PoE camera ports and 8 built-in light channels. Sizing the CPU side of such a loop is its own exercise in Object detection on an industrial controller: sizing a CPU vision loop.

The bandwidth math that forces the choice

When the host does the processing, the link carries every pixel, and the link is a hard ceiling:

Two ceilings matter. A USB 3.0 port signals at 5 Gbit/s, which is 500 MB/s after 8b/10b encoding; host controllers and protocol overhead bring the sustained bulk rate to roughly 350-400 MB/s. A GigE port signals at 1 Gbit/s — 125 MB/s at line rate — and typical GigE Vision stacks sustain about 110-115 MB/s.

Worked example: a 4K module streaming into a host over USB3.

• 4K at 30 fps, 8-bit color: 3840 × 2160 × 3 B = 24,883,200 B ≈ 24.9 MB per frame, and 24.9 MB × 30 = 746 MB/s.
• Against USB3's best practical 400 MB/s: 746 ÷ 400 ≈ 1.9× over. The link cannot carry this stream uncompressed at any host speed.
• Same sensor, 8-bit mono: 3840 × 2160 × 1 B ≈ 8.3 MB per frame, 249 MB/s at 30 fps — fits USB3, still 249 ÷ 115 ≈ 2.2× over GigE.
• Down to 1080p mono: 1920 × 1080 × 1 B ≈ 2.1 MB per frame, 62 MB/s at 30 fps — 54% of a GigE link.

The escape ladder, cheapest first: mono instead of color (÷3), fewer frames per second, a smaller ROI or binning, hardware compression — MJPEG or H.264 typically buys 10-20× at some quality cost — and finally processing onboard, so only results cross the wire. The per-camera arithmetic behind the middle steps is in Reduce USB3 camera bandwidth: the per-camera budget math and USB3 bandwidth for a multi-stream pipeline: size each stream.

Latency: the second forcing function

Bandwidth kills streams; latency kills control loops. The transfer formula above sets the floor for host-side processing: a 24.9 MB 4K color frame moved at 350 MB/s takes 24.9 ÷ 350 ≈ 71 ms on the wire, and a 2.1 MB 1080p mono frame at 115 MB/s takes ≈ 18 ms. That is before exposure, host processing and the robot's own motion are added.

Onboard processing deletes that transfer: a smart camera or SoC module sends a few bytes of coordinates, which cross a 115 MB/s link in well under a millisecond. For guidance loops the commit is simple — keep raw frames at or below 1080p mono on GigE, or process onboard. The full exposure-to-motion budget is laid out in Image based control latency: budget the full feedback loop.

How to tell which class you are holding

Classify the device from its data sheet before writing any code:

1. It names a processor, an operating system or an SDK that deploys programs — smart camera; the inspection runs onboard.
2. It lists only sensor, shutter, interface and lens mount — sensor-only; Python on the host, and budget the link.
3. It connects by flat-flex ribbon — look for a vendor pipeline API. With one, the SoC runs the graph onboard while your Python stays host-side; without one, the ribbon brings you nothing but pixels.
4. It is a box with several camera LAN ports and light-control channels — vision controller; run full Python there and hang the cameras off it.

Sensor-to-host compatibility is its own pre-purchase check — Board level camera sensor compatibility: match the host before you buy — and Board camera evaluation checklist for inspection systems turns the rest into a list you can score.

The decision for each case

For the single-inspection case, the practical choice is between two smart-camera formats: a fixed-lens device with the light built in, or a programmable camera with an interchangeable lens. The LS-SMC-0063 is the first — 1.6 MP at 60 fps with a fitted 16 mm lens and integrated white light. The MV-SC5060XM-08M-WBN is the second — 6 MP mono over GigE with an M12 mount:

Values as printed in each product's data sheet; open a part for its drawing and full specifications.

When the usual answer is wrong

Host-side processing is the default, and three cases break it. First, a single-camera station that must run with no PC on the line: a smart camera with the inspection deployed is less hardware, not more. Second, a stream that looks impossible — 4K color — often fits once mono, a reduced ROI or the camera's hardware encoder are applied; recompute before adding a computer. Third, a ribbon SoC module tempts you to 'put Python on the camera': the onboard part is the pipeline graph. Keep the orchestration small on the host and budget its CPU for what the nodes do not cover.

Before you order

• Sum the streams: per-camera MB/s from the formula, added up, against the controller's port count and switch capacity; a multi-camera rig on one processor is worked through in Design a multi-camera board-level rig on one processor.
• Confirm the deployment path: the SDK you build with must match the firmware on the camera, and the algorithm you need must exist in the camera's library if you will not write your own.
• Plan the optics for bare boards: M12 or CS mount, back-focus distance, and strain relief on the connector.
• Count the light channels if you strobe: a controller integrates them — 8 on the MV-VC5525-256G70-NN — and a smart camera with a built-in light covers the single-camera case.

Where to go next

Size the stream with the formula, pick the class, then pick the part. Browse smart cameras and board-level cameras in the camera finder, or start a controller build from vision controllers with the system configurator. More set-up-level reading sits on the machine vision systems topic page. If you want a second opinion on where the code should run, send us the layout through the contact page.