Smart camera image processing time: what is fast enough

Your smart camera finishes the inspection, but the log shows about 50 ms between image and verdict, and all the program did was threshold the frame and run a particle count. Is the camera slow, or is that normal? This guide gives you the numbers behind that question: what a frame costs to move across each interface, what a threshold-plus-blob chain costs in memory traffic, and which levers shrink each block. Split your cycle into exposure, transfer, processing and output, put a millisecond value on every block, and decide whether to tune the camera or move the work to a vision controller.

The short answer: 50 ms is normal, and the arithmetic says why

Yes. A full-frame binarization plus particle analysis takes tens of milliseconds on a smart camera's embedded processor, and a reading near 50 ms at 5-6 MP sits inside the normal band. Nothing is broken. The cost is not the threshold operation itself: it is moving every pixel through memory one or more times, and, whenever the image leaves the camera, moving it across the network too.

Every cycle splits into four blocks:

A well-lit station exposes in 0.1-10 ms. Transfer scales with frame size and interface, processing with pixel count and the number of passes, and output stays under 1 ms when a verdict of a few bytes leaves the camera. Stream or save the image too and output grows by tens of milliseconds.

Decisions up front:

• Inspection on an ROI, or at 2 MP full frame and below, with a verdict out: stay on the smart camera and expect single-digit processing after tuning.
• 5-6 MP full frame that must land under 10 ms: enable hardware binarization and binning, or move the chain to a controller.
• More than one camera, AI models or 3D: a vision controller with desktop-class cores and memory.

Transfer: what a frame costs on the wire

An 8-bit mono image is 1 byte per pixel, so megapixels convert to megabytes one to one. Practical payload after protocol overhead: GigE delivers about 118 MB/s, Fast Ethernet about 12 MB/s, USB 3 around 350-400 MB/s. Divide frame size by payload rate: 6 MB ÷ 118 MB/s ≈ 51 ms on GigE, and 6 MB ÷ 12 MB/s = 500 ms on Fast Ethernet.

Two conclusions fall straight out of the table. A Fast Ethernet vision sensor cannot ship full 5 MP frames at a production rate — 417 ms each — which is exactly why vision sensors process on the device and return results instead. And a 60 fps rating only holds when the frame fits the wire: 1.6 MB per frame at 60 fps is 96 MB/s of traffic, inside GigE's payload with margin, impossible on Fast Ethernet.

That is the case for on-device inspection, and these cameras are built for it:

The MV-SC3050XC-16M-ATN-H pairs a 5 MP color global-shutter sensor with Fast Ethernet and decides on the device. The MV-SC5060XM-08M-WBN captures 6 MP mono over GigE with an 8 mm M12-mount lens — the frame size the worked example below uses. The LS-SMC-0063 inspects a 1.6 MP image at 60 fps over GigE through its built-in 16 mm lens.

Processing: count memory traffic, not operations

Thresholding and blob analysis are memory-bound: the processor reads every pixel, writes a result, and often reads that result again. What matters is megabytes moved, not instruction count. Count on about 1 GB/s of effective read-plus-write bandwidth for one embedded core, and several GB/s per core in a desktop-class controller.

Worked example: a 6 MP mono frame, one embedded core at 1 GB/s:

31.5 MB ÷ 1 GB/s ≈ 32 ms. Add the per-particle feature pass, which grows with blob count, plus scheduler overhead, and the chain lands at 35-50 ms — exactly where a measured 50 ms reading sits. The model is linear in pixels: the same chain costs about 8 ms at 1.6 MP (31.5 × 1.6/6) and about 2 ms at 0.3 MP.

So if the log shows 50 ms for this job at full frame, the arithmetic agrees with the measurement and the camera is not misbehaving. If it shows 50 ms on a small ROI, skip ahead to what else can eat the time.

Four levers, in the order to pull them

Transfer and processing both scale with pixel count, so each lever works on both at once — the same scaling covered in how processing time scales with image size.

1. Shrink the ROI. A 640 × 480 window holds 307,200 pixels, 5.1% of a 6 MP frame. Processing drops from 32 ms to 1.6 ms, transfer from 51 ms to 2.6 ms, and a full verdict cycle lands around 6-8 ms including exposure and output. Size the window as the part plus its positioning tolerance and a margin of a few pixels.
2. Bin pixels. 2×2 binning quarters the pixel count before the frame reaches memory: the 32 ms chain becomes about 8 ms, and mono sensors gain signal-to-noise at the same time.
3. Let hardware threshold. Most smart camera firmware offers a hardware threshold or LUT stage in the image path. Enable it and your software starts from a 1-bit image: the threshold pass falls about eightfold, from 6.75 MB to roughly 0.85 MB of traffic, and if the binary mask crosses the network instead of the grayscale frame, transfer falls by the same factor.
4. Return results, not frames. A verdict, coordinates and counters are bytes; a 6 MB frame is not. Stream images for set-up only, and rate-limit archive writes: an SD-class write of a 6 MB frame takes tens to hundreds of milliseconds and competes with the processor for the same memory.

Benchmark the camera in 15 minutes

Estimates say where the time should go; a benchmark says where it went.

1. Trigger the camera from hardware so exposure start is a known instant, and check the per-camera trigger settings first — the free-run default hides the handshake, as covered in hardware trigger configuration per camera.
2. Latch the camera's exposure-end timestamp; chunk data carries camera time at exposure end, and chunk data timestamp shows how to latch it.
3. Put a timer around each stage: image ready, threshold done, blobs done, verdict sent.
4. Run at least 100 frames and judge by the median and the worst case, never the fastest frame.
5. Turn the live preview and HMI streaming off for the benchmark, then on again to see their share — smart camera image in a PLC HMI covers what actually displays live.
6. Reuse image buffers across frames; allocation inside the loop adds variable milliseconds, as reuse image buffers instead of per-frame allocation explains.
7. Compare processing time against the acquisition period; when acquisition outruns processing, frames queue or drop, which acquisition faster than processing diagnoses.

Stay on the camera or move to a controller

Stay on a smart camera when one camera decides on an ROI or a small frame, the output is a verdict plus coordinates, and the cycle has 10 ms or more to spend. One device to mount, power and configure, with the inspection running next to the sensor.

Move to a vision controller when the chain needs several cameras at once, a 5-6 MP full-frame result under 10 ms, AI inference or 3D, or when lights and I/O belong to the same brain. The cameras then just capture, and the controller's cores, memory and built-in light channels do the rest. Sort out what runs on the camera itself before you offload — on-camera image processing — and see the same budgeting method worked on a small part in measuring points on a 5 mm part in under one second.

Two controllers cover the usual ends of that range:

The MV-VC3301H-128G66 runs the chain on an Intel Core i3 with 8 GB of memory, drives lights from 4 built-in channels and includes the vision runtime license — enough for one or two GigE cameras and a threshold-plus-blob load with headroom.

The MV-VC5525-256G70-NN steps up to an Intel Core i5 with 32 GB of memory, PoE camera ports and 8 built-in light channels, for multi-camera cells, larger frames and AI models.

When 50 ms means something else

• Encoded input. If the program receives JPEG or another encoded stream, a decode pass runs before your threshold and charges a full extra read-plus-write of the decoded image; work on RAW or mono 8-bit data, as image bytes vs pixel data explains.
• Allocation in the loop. A fresh buffer per frame turns a steady 32 ms into a jittery 40-60 ms; reuse buffers as in the benchmark steps above.
• Availability, not speed. If processing is fast but the cycle still misses its rate, the part may not be where the trigger expects it; conveyor target availability breaks that loss down.
• No GPU to rescue you. A smart camera carries no discrete GPU, so "add a GPU" is a controller conversation, and slow GPU image processing shows what that path really delivers.

Checklist before you commit a cycle number

• Frame size written down: pixels × bytes per pixel, mono 8-bit = 1 byte.
• Transfer time: frame MB ÷ 118 MB/s on GigE, ÷ 12 MB/s on Fast Ethernet.
• Processing time: MB moved per pass ÷ bandwidth (≈1 GB/s embedded), summed over passes.
• ROI grown by the part's positioning tolerance plus a margin of a few pixels.
• A 100-frame benchmark with preview off, median and worst case recorded.
• Output carries results, not frames; archive images rate-limited to exceptions.
• Acquisition period longer than processing time, or the queue explained.

When the numbers hold, pick the hardware with the camera finder, which filters smart cameras and sensors by interface and resolution. Send your cycle budget through the contact page and we will check the arithmetic with you. More on timing and pipelines sits under the systems topic and the code-reading topic.