Frequently Asked Questions (FAQ)

Why the recognizer application is slow?

The application isn’t slow. We have added multiple comments in the source and in the documentation to explain why the duration reported by the recognizer is high but we keep getting the same question. So, let’s explain several points here:

Danger

  • The first time you call the process function it will take several seconds because we’ll load the deep learning models and perform some initializations. This is why the recognizer reports high duration for the first call.

  • The init function will take several minutes if you’re using NVIDIA Jetson and binaries under jetson_tftrt. The models are built at runtime. More info here#1.

Note

  • Don’t use Python if you care about speed. Python language is very slow and memory hungry compared to C++. There are many limitations when it comes to multithreading. Please note that parallel processing isn’t supported with Python.

  • Use the benchmark application if you want to know the average frame rate you can expect. If you want to write your own benchmark app, do something like this:

    init();
    warmup(); // or call process() using image with plate to force loading OCR models
    
    start = now();
    for (i = 0; i < 100; ++i)
       process();
    end = now();
    
    duration = (end - start);
    
  • Call the init function once at started.

  • Use C++ for maximum performance.

  • Enable parallel processing. Only C++, Java and C# support this feature. On some ARM platforms the code will be up to 5 times faster. More info here#2.

  • On NVIDIA Jetson, put the device on maximum performance mode: sudo nvpmodel -m 0 && sudo jetson_clocks

Why the benchmark application is faster than VideoParallel?

The VideoParallel application has many background threads to: read from the camera, draw the preview, draw the recognitions, render the UI elements… The CPU is a shared resource and all these background threads are fighting against each other for their share of the resource.

Why the image is 90% rotated?

When the device is on portrait the image from the camera is rotated 90% to match the screen size. I swear it’s not our fault :). We could rotate the image back -90% to have the image on the right orientation but this would increase the processing time and we prefer to let the end user decide what to do. Anyways, put the device on landscape and the image will have the right orientation.

Rotating an image by 90% is very easy, f: (x,y) -> (y, x)

Why does the detector fail to accurately detect far away or very small plates?

As explained in the documentation, the input layer will resize any image to a fixed 300x300x3 resolution and small or far away plates may become undetectable after such process.

You can enable pyramidal search feature (will add some delay to the detection pipeline) to fix such issue.

Could you explain what each field in the JSON result mean?
The fields in the JSON result are self explanatory except for warpedBox and confidences
  • warpedBox: represents a quadrilateral, the angles are not always square which means we cannot represent it using 2 points.
    Format: [LeftTop.x, LeftTop.y, RightTop.x, RightTop.y, RightBottom.x, RightBottom.y, LeftBottom.x, LeftBottom.y].

  • confidences: a 2+N float array. The first 2 entries are the confidence for the OCR result then the confidence for the plate detection. The next N entries represent the scores for each character in the OCR result.
    Format: [Plate text OCR score, Plate detection score, Char 0...N scores].