{"id":1366,"date":"2017-06-08T17:01:21","date_gmt":"2017-06-08T15:01:21","guid":{"rendered":"http:\/\/asuralpr.com\/?p=1366"},"modified":"2017-06-08T17:01:21","modified_gmt":"2017-06-08T15:01:21","slug":"maximizing-processing-speed-lpr-systems","status":"publish","type":"post","link":"https:\/\/asuratechnologies.com\/de\/2017\/06\/08\/maximizing-processing-speed-lpr-systems\/","title":{"rendered":"Maximizing processing speed for LPR systems"},"content":{"rendered":"

It has been a while since my last post. Duty called and as part of the Asura crew I visited<\/i> the 2017 IPI conference<\/i> and had an<\/i> amazing time<\/i> in New Orleans. After the expo, it\u2019s back to business and obviously to writing the blog. Now that <\/i>the issues of <\/i>reaching maximum <\/i>hitrate<\/i> and <\/i>–<\/i>accuracy with LPR systems are out of the way with the previous posts, let\u2019s turn our focus on maximizing processing speed. <\/i><\/p>\n

When talking about maximum processing speed, most people think about decreasing the processing time where it counts the most: the part of the system where processing takes longest, which in our case is the runtime of the LPR engine. With this approach however, you will most likely have to deal with lower accuracy.<\/p>\n

Let me list a few cases, where this tradeoff is acceptable:<\/p>\n

    \n
  1. Process every single image of the cameras with a very fast license plate finder library to determine whether or not there is a license plate in them;<\/li>\n
  2. Preprocess the images with OCR to determine which one(s) of them contain(s) the license plate in the optimal position so they can be processed with the final (high-accuracy) LPR library;<\/li>\n
  3. Process the license plates for statistical purposes only, e.g.: for calculating an expected travel time between certain checkpoints of a city.<\/li>\n<\/ol>\n

    Most of the time such accelerated LPR recognizer methods are used in preprocessor algorithms which provide a more specific input for the final high-accuracy LPR subsystem. On a side-note – we provide a preprocessor to help with systems where no other triggering is possible as part of ARU. Generally speaking though, I would say that these tasks should be considered more matters of triggering than parameters of the LPR library.<\/p>\n

    At this point let\u2019s revisit my earlier post \u201c5 common misconceptions in LPR \u2013 explained<\/a>\u201d where misconceptions 1, 2, 3, and 5 can give you some insight on the workings of LPR systems. I\u2019m sure it will make much more sense now. Also note that the scenario depicted in misconception 5<\/a> is that where the expectation is a combination of high speed with high accuracy, but this time we are talking about the speed of processing set on higher priority, accuracy being less important.<\/p>\n

    In the next post it will be time to wrap up the current series and and continue with something even more exciting\u2026 \u2018Til then!<\/p>\n

    \n

    Don\u2019t forget to sign up for our newsletter!
    \nYou will receive first hand reviews on Asura services and LPR related news and articles!<\/p>\n

    \n \t\n