I created a simple utility today to assist in evaluating the alignment and environment factors of an LPR camera installation, based on metadata produced by an LPR engine.
LPR is almost an art – having a great quality image, a well-tuned engine, and ideal ambient conditions are not enough to ensure best performance. Quite often, the engineering aspects of an installation far outweigh any ability to improve accuracy in software. Consequently, domain knowledge and experience is imperative to ensure that an LPR installation performs to the best of its capability.
By analysing the positions of a set of number plates in a camera’s field of view (FOV) with respect to confidence, correctness, and status; a lot of information regarding the camera can be deduced which in turn helps improve system performance.
Manual sampling can go a long way with the right knowledge. From the image above, it is easy to see that alignment could likely be changed in such a way that the region in which number plates present themselves is more central to the camera. This of course would help improve capture rate – one of the standard benchmark vectors of an LPR system. Doing so would likely just introduce reads prematurely, and adversely impact performance. This would then require the engine to be retuned; but the nature of how to do so can be difficult to deduce. Hence analysis can be quite complex, and problems can quickly compound and become overwhelming.
When viewed on a heat map, this requirement for alignment becomes immediately obvious. It is no longer necessary to be consciously aware of what’s going on during an accuracy audit – the necessary actions can be deduced entirely from the data in this image and the statistics that accompany it.
Different scenarios present different problems of course – like in this image it can be observed that the system read accuracy is quite good, as implied by lots of green. However, the congregation of these reads could be centralised in the FOV, permitting plates which might be uncaptured presently to be captured as they pass through a currently excluded region.
False positives can impact different systems in different ways. In some systems that rely on inferred transactions, they can cause havoc; creating invalid transactions which may have devastating roll-on effects. In other systems, they might go completely unnoticed. Regardless, as with any real-time transactional system that deals with images, space is a premium, and wasting it on useless data is an expensive penalty. A ‘next-step’ from considering a map with similar formations to this could be to filter reads that fall in the yellow regions (false positives), and possibly realign the device to re-centralise the hot spot. It may even justify considering a read-confidence filter to stop them existing in the first place.
An even distribution of misreads might indicate that the engine is not tuned or simply not capable enough to read the plate formats being presented. That is not the case in this scenario however, as the congregation of red regions central to the image, of a small size, tells us that the plate is too small to optimally read, and that a size filter will likely improve the system’s performance dramatically. Furthermore, a region filter could be applied to eliminate almost all the false positives with confidence, and minimal side effects.
Overall, I am really happy with how this process makes it easier to form educated decisions, with lowered risk. I will likely develop this tool further, to interface with more systems and engines to make it easier to quickly assess the quality of an installation with respect to the engineering decisions made, and of course, rectify any issues that may be present.