A camera module can produce a clear image and still fail in a real-time application. A barcode scanner may react slowly, a robot may detect an object after it has moved, or an industrial inspection system may capture an image that does not match the trigger timing.
These problems are often described as “camera delay.” However, camera module latency is rarely caused by the camera alone. It may come from exposure settings, sensor readout, interface bandwidth, video compression, ISP processing, firmware, system buffers or the host platform.
To reduce latency effectively, the complete imaging pipeline must be evaluated.
Camera module latency is the time between the beginning of image capture and the moment the image becomes available to an application, algorithm or display.
The process may include:
A camera running at 30fps has a theoretical frame interval of approximately 33.3 milliseconds. At 60fps, the interval is approximately 16.7 milliseconds. However, this is not the total system latency. Exposure, processing, transmission and buffering may add one or several additional frames of delay.
This is why latency should be measured across the complete system rather than estimated from frame rate alone.
Different applications have different latency requirements. A moderate delay in a video conference may only make communication feel unnatural. In robotics, industrial inspection or real-time control, the same delay could affect system accuracy.
Latency can influence:
For these applications, a camera module should be evaluated not only by its resolution and image quality but also by its response time and synchronization performance.
Higher resolution means more image data must be captured, processed and transmitted. If the interface, ISP or host processor cannot handle the additional data efficiently, the system may introduce buffering or reduce the actual frame rate.
Higher frame rates shorten the time between frames:
However, a higher frame rate does not automatically guarantee lower end-to-end latency. A 60fps system with several software buffers may respond more slowly than an optimized 30fps system.
The resolution and frame rate should match the target size, movement speed and processing capability of the final device. Using the highest available specification is not always the best solution.
Exposure time is one of the most overlooked causes of camera latency.
In low light, automatic exposure may extend the exposure time to make the image brighter. This can increase both latency and motion blur. Even if the camera is configured for 30fps, a long exposure prevents the sensor from completing image capture quickly.
Possible improvements include:
Brightness, noise, motion clarity and latency usually require a balance. These parameters should be tested inside the final device under actual working conditions.
After exposure, the sensor must read and output the pixel data. Readout time depends on the sensor, resolution and operating mode.
Rolling-shutter sensors expose and read the image row by row. They are widely used because of their image quality and cost advantages, but fast movement may produce distortion.
Global-shutter sensors capture all pixels at the same moment, making them suitable for machine vision, high-speed movement and synchronized inspection.
However, global shutter does not automatically mean lower total latency. The interface, ISP, firmware and system buffers still affect the final result. Shutter type should be selected according to motion and synchronization requirements.
The interface determines how image data moves from the camera module to the host platform.
MIPI CSI-2 is commonly used in embedded devices, robots and smart terminals. It supports high-speed transmission and a relatively direct connection to the main processor. However, integration requires compatibility between the sensor, processor, ISP, driver and operating system.
USB camera modules are easier to integrate. UVC-compatible cameras can work with many Windows, Linux and Android systems without a proprietary camera driver. Their latency may still be affected by USB bandwidth, output format, driver behavior, controller performance and system buffering.
HDMI is useful for direct video output, while interfaces such as GMSL are often used for automotive or long-distance video transmission.
It is inaccurate to assume that USB is always slower than MIPI. A well-optimized USB camera can provide low latency, while a poorly configured MIPI system may still experience significant delay.
The output format affects both bandwidth and processing time.
YUY2 is uncompressed and offers a relatively direct image path, but it requires substantial bandwidth at high resolutions.
MJPEG reduces the amount of transmitted data by compressing each frame independently. This makes high-resolution USB video more practical, although encoding and decoding may add some processing time.
H.264 and H.265 provide higher compression efficiency for storage and network transmission. However, frame prediction and buffering may increase latency if the codec settings are not optimized.
RAW data preserves more sensor information and offers greater ISP tuning flexibility, but it requires more processing from the host platform.
The best format depends on interface bandwidth, host performance, image-quality requirements and the acceptable latency range.
Modern cameras may perform extensive image processing before outputting a frame. Functions that can add processing time include:
These functions should not necessarily be disabled. Many are important for image quality. The goal is to use only the processing required by the application and balance image quality with real-time response.
For example, temporal noise reduction can improve low-light images by comparing multiple frames, but it may also increase latency and cause ghosting around moving objects.
ISP parameters should therefore be tuned for the actual application rather than using the same default settings for every project.
In many projects, the camera module is blamed even when most of the delay occurs after the image leaves the camera.
Drivers and applications use buffers to maintain stable video output. Too many buffers, however, increase the time between capture and display.
Possible sources include:
Firmware also affects exposure control, image output, compression and USB transmission.
In real-time systems, reducing the buffer count or processing only the newest frame can improve response speed. These changes must be tested carefully because excessively small buffers may cause dropped frames or unstable video.
The camera is only one part of the imaging system. CPU, GPU, NPU and memory performance all affect how quickly each frame can be processed.
AI recognition, image enhancement, format conversion or video decoding may overload the host platform and create a growing frame queue. The display can add further delay through a low refresh rate or internal image enhancement.
When diagnosing latency, check:
A camera that performs well on a powerful development computer may behave differently on the final embedded platform.
A practical optimization process should include:
The largest source of delay should be identified first. Changing the sensor will not solve application buffering, while upgrading the interface will not correct an excessively long exposure time.
Camera latency should be tested under controlled and repeatable conditions.
Display a high-precision timer and compare it with the timer shown in the camera preview. The difference provides an approximate end-to-end latency value.
Use a controllable LED and record both the physical LED and the camera output with a high-speed camera. The frame difference can then be used to estimate latency.
For industrial applications, compare the hardware trigger signal with the timestamp of the output frame. This provides more accurate information about exposure, readout and transmission timing.
Testing should use the actual camera module, lens, output format, host processor, driver, firmware, application and display. A result obtained from a bare module on a development computer may not represent performance inside the final product.
Camera module latency is not determined by one specification. It is the combined result of exposure, sensor readout, frame rate, interface bandwidth, video format, ISP processing, firmware, buffering, host performance and display behavior.
For real-time applications, the complete imaging pipeline should be evaluated to balance image quality, bandwidth, processing load and response speed.
If your project requires low-latency video, please provide the application, interface, resolution, frame rate, host platform, output format and acceptable latency range. Krieer can help evaluate the camera module, lens, firmware and imaging pipeline before prototyping, reducing the risk of discovering system-level latency problems later in development.
