When starting to choose a camera for many visual projects, the one parameter everyone looks at most is frame rate.

The manufacturer’s documentation states 120 fps, and the proposal also estimates the frame rate at 120 fps. However, as soon as the equipment arrived on site and the software was run, the actual frame rate turned out to be only 60 fps—and occasionally even dropped to 40 fps.

At this point, everyone at the scene started looking at each other, wondering: Is the camera spec misleading? Is the software poorly written? Or is the computer just too weak?

But anyone who’s worked on projects knows that,If the frame rate can't reach its target, it's often not a matter of just one single parameter—but rather that the entire acquisition pipeline is bottlenecked somewhere along the way.

Nominal frame rate does not equal the actual frame rate.

The maximum frame rate listed in the camera’s specifications is usually measured under specific conditions.

For example, should the resolution be set to full or to ROI? Should the pixel format be Mono8 or RGB24? What’s the exposure time? At what bandwidth is the interface operating? Is there a trigger involved? Is algorithm processing being performed simultaneously?

As soon as these conditions change, the actual frame rate could be completely different.

Many beginners tend to misunderstand “how many frames the camera supports” as meaning “how many frames my project can run.” That’s the first pitfall.

What the visual scene really wants to ask is not...How fast can the camera go?, but ratherUnder the current conditions regarding exposure, resolution, interface, algorithms, and host system, how fast can the entire system run reliably?.

Exposure time is the hardest-to-notice hard constraint.

If the camera’s frame rate isn’t reaching its target, don’t rush to look at the code—first check the exposure.

For example, if you want to achieve 100 fps, the frame period is only 10 ms. But if you set the exposure time to 15 ms, forget about 100 fps altogether. Before the camera has even finished exposing the current frame, the next frame’s time has already passed.

This isn't a problem that optimization can solve—it's simply a matter of insufficient physical time.

On-site, we often encounter this situation: the light source isn't bright enough, so to achieve a clear image, we have no choice but to extend the exposure time. The image does become brighter, but the frame rate gets locked as well.

So sometimes, when the frame rate can’t go up, it’s not because the camera is slow—it’s simply that the lighting setup can’t handle it.The exposure time has eaten into the beat, and no matter how much you adjust the software later, it’ll be hard to make up for it.

In many performance issues within visual projects, the root cause ultimately turns out to be that “the frontend, in its quest for clarity, forces the backend to run too slowly.”

When the interface bandwidth is maxed out, the frame rate naturally can't go any higher.

Every frame of the camera’s image has to be transmitted to the computer. The larger the image, the higher the bit depth, and the higher the frame rate, the more staggering the amount of data becomes.

A 5-megapixel image, if it’s in 8-bit grayscale, would be roughly 5 MB; if it’s in color format, the file size could easily multiply several times over. If you’re trying to transmit dozens of such images per second, the interface bandwidth will quickly reach its limit.

USB3, GigE, Camera Link, and CoaXPress—all appear to be interfaces, yet the amount of data they can handle behind the scenes is completely different. What’s even more complicated is that on-site performance can also be affected by factors such as cable quality, switches, network cards, drivers, and system load.

Many projects aren't about the camera failing to produce images; rather, it's...The image is stuck in traffic on the transmission route..

This is also why, in industrial vision, you can’t just focus on “camera frame rate”—you also need to consider data throughput. The frame rate is the result; bandwidth, however, is the channel itself.

Whether it's the capture card, the cache, or the host—any one of them that’s slow can hold things back.

Some high-speed cameras require a capture card. If the capture card is chosen improperly, the slot bandwidth is insufficient, or the driver configuration is incorrect, the camera may not perform at its full potential.

There’s also a caching issue.

The camera keeps continuously outputting images, while the software on the back end can’t keep up with the pace of image acquisition, causing the cache to pile up. Once the cache reaches a certain threshold, either frames will be dropped, or the latency will keep increasing. As a result, on-site, the detection appears to be half a beat behind—or even occasionally miss detections altogether.

What industrial sites fear most isn't constant slowness—it's rather...Sometimes it’s normal, sometimes it suddenly lags a bit..

The same goes for host performance. The CPU is running the algorithm, the memory bandwidth is transferring images, the hard drive might still be writing images, and the interface keeps refreshing. If all these tasks are crammed into the same time frame, the capture thread gets bogged down, and the frame rate naturally becomes unstable.

It’s hard to expect the backend algorithm to compensate for the instability of the frontend data collection pipeline in the long term.Once the image source starts to shake, all subsequent detections will suffer as a result.

If the triggering method is incorrect, the frame rate may also appear “below standard.”

There’s also a situation where the camera itself is fine, but the triggering method limits the frame rate.

When capturing images freely, the camera will continuously output frames according to its internal timing. However, when triggered externally, the camera must wait for signals from the sensor, PLC, or encoder. If the trigger signal frequency is insufficient or the signal is unstable, the camera will be unable to run stably at full frame rate.

Be careful even with soft triggers. The computer itself, when issuing trigger commands, is subject to system scheduling and communication delays. While this might not be noticeable in low-speed projects, in high-speed projects, even a small delay can be greatly amplified.

So at the scene, don't just ask, “Can the camera be triggered?”—you also need to ask...Is the trigger rhythm stable? Is the trigger link controllable?.

Some projects appear to be frame-rate issues, but in reality, the root cause is a problem with beat design.

When troubleshooting frame rates as a beginner, don't immediately suspect the camera.

If you encounter a situation where the frame rate can't reach the target, you can trace back along the project pipeline.

First, check whether the exposure time exceeds the target frame period; then, examine the resolution and pixel format.Is there room for optimization in terms of ROI? Then calculate the interface bandwidth to see whether the data volume is already approaching the upper limit.

Next, examine the acquisition card, drivers, caching policies, and host workload. Finally, check the triggering method—whether it’s free acquisition, hard triggering, or soft triggering.

Here’s a very practical guideline:If you disable the algorithm and still can't increase the frame rate, the problem is most likely in the acquisition pipeline. Only when image acquisition runs at full capacity does the frame rate start dropping after the algorithm is enabled—indicating that the issue is more likely on the processing side.

Don't underestimate this move—it can save you a lot of detours on-site.

The camera's frame rate can't reach its full potential—not because of any mystical phenomenon, and it’s not necessarily anyone’s fault.

When actually working on a project, don't just focus on the highest frame rate listed in the spec sheet. Instead, pay attention to whether the exposure is short enough, whether the bandwidth is wide enough, whether the buffer will become congested, whether the host can handle the load, and whether the trigger timing is stable.

At the end of the day, what the visual system is striving for isn't achieving the highest frame rate in a single second, but rather...Running steadily at the pace required by the project for an extended period..