Improving the speed¶

This section explains how to improve the speed (frame rate).

OpenVINO¶

OpenVINO is always faster than Tensorflow on Intel products (CPU, GPU, VPU, FPGA). We recommend enabling OpenVINO if not already done. Check the console logs to make sure OpenVINO plugin is loaded and used.

For now (version 3.0), OpenVINO is only supported on Linux and Windows x86-64.

GPGPU acceleration¶

Desktops¶

On desktops (x86-64) we support GPGPU acceleration via TensorRT (NVIDIA CUDA) and OpenVINO.

For NVIDIA GPUs: https://github.com/DoubangoTelecom/ultimateALPR-SDK/tree/master/samples/c%2B%2B#gpu-acceleration

For Intel GPUs, VPUs, FPGAs: Enable OpenVINO and set the device type using JSON config entry openvino_device as explained in the configuration section.

Mobiles¶

On mobile devices (ARM) we support GPGPU acceleration via TensorflowLite backends (OpenGL shaders, Metal and NNAPI) . For now we prefer using I8 quantized models instead of F32/F16 GPGPU accelerated models. Quantized models work in highly predictable ways on any ARM CPU while GPGPU accelerated models via TensorflowLite (OpenGL or NNAPI) tend to be fast on some devices and horribly slow on others.

Parallel mode¶

Activate the parallel mode as explained in the previous sections. Please note that this won’t change the accuracy while your application will run up to #2 times faster than the sequential mode.

Memory alignment¶

Make sure to provide memory aligned data to the SDK. On ARM the preferred alignment is 16-bytes while on x86 it’s 32-bytes. If the input data is an image and the width isn’t aligned to the preferred alignment size, then it should be strided.

Please check the memory management section for more information.

Landscape mode¶

When the device is on portrait mode, then the image is rotated 90 or 270 degree (or any modulo 90 degree). On landscape mode it’s rotated 0 or 180 degree (or any modulo 180 degree). On some devices the image could also be horizontally/vertically mirrored in addition to being rotated. Our deep leaning model can natively handle rotations up to 45 degree but not 90, 180 or 270. There is a pre-processing operation to rotate the image back to 0 degree and remove the mirroring effect but such operation is time consuming on mobile devices. We recommend using the device on landscape mode to avoid the pre-processing operation.

Removing rectification layer¶

On ARM devices you should not add the rectification layer which introduces important delay to the inference pipeline. The current code can already handle moderately distorted license plates. If your images are highly distorted and require the rectification layer, then we recommend changing the camera position or using multiple cameras if possible. On x86, there is no issue on adding the rectification layer.

Please check the configuration section on how to add/remove the rectification layer.

Disabling pyramidal search¶

Pyramidal search function is used to detect very small and far away plates. The refiner (explained here) is smart enough to not build additional pyramidal levels when there is no small or far away plate on the image. But, its smartness have bounds: additional levels are built when the image is too complex (many edges). More levels means higher CPU usage and inference time.

Disable this feature if the license plates on the video stream are close and large enough. Unless you’re filming a highway using a long-range camera you don’t need this feature.

Please check the configuration section on how to enable/disable the pyramidal search.

Disabling License Plate Country Identification (LPCI)¶

Only enable this feature if you need it.

It’s useless to enable this function if you’re expecting the plates to be from a single country. This feature is useful in European Union (multiple countries), USA (multiple states), Canada (multiple provinces), UAE (multiple emirates)… but not in Russia, Korea, Tunisia or Mauritania.

Please check the configuration section on how to enable/disable LPCI.

Disabling Vehicle Color Recognition (VCR)¶

Only enable this feature if you need it.

Off course it doesn’t make sense to enable this feature if your camera is returning grayscale (8-bit) images. The result would be unpredictable even if you’re just trying to classify the colors as being black or white.

Please check the configuration section on how to enable/disable VCR.

Disabling Vehicle Make Model Recognition (VMMR)¶

Only enable this feature if you need it.

Vehicle Make Model Recognition (VMMR) feature adds latency to the pipeline. Make sure you really need it before enabling it.

Please check the configuration section on how to enable/disable VMMR.

Disabling Vehicle Body Style Recognition (VBSR)¶

Only enable this feature if you need it.

Vehicle Body Style Recognition (VBSR) feature adds latency to the pipeline. Make sure you really need it before enabling it.

Please check the configuration section on how to enable/disable VBSR.

Planar formats¶

Both the detector and recognizer expect a RGB_888 image as input but most likely your camera doesn’t support such format. Your camera will probably output YUV frames. If you can choose, then prefer the planar formats (e.g YUV420P) instead of the semi-planar ones (e.g. YUV420SP a.k.a NV21 or NV12). The issue with semi-planar formats is that we’ve to deinterleave the UV plane which takes some extra time.

Reducing camera frame rate and resolution¶

The CPU is a shared resource and all background tasks are fighting each other for their share of the resources. Requesting the camera to provide high resolution images at high frame rate means it’ll take a big share. It’s useless to have any frame rate above 25fps or any resolution above 720p (1280x720) unless you’re monitoring a very large zone and in such case we recommend using multiple cameras.