Automatic License Plate Recognition (ALPR) is one of the applications of OCR. When it comes to commercialization, ALPR cannot be sold as a sole capability but is one among many features of the entire solution. Common features of such solutions are:
Depending on the application ( smart city, highway surveillance, cop car, access control, service centers, retail outlet, or commercial parking ) one may use the subset of listed features or can add more. This is the reason why almost the same solution goes by many names like "Automatic Number Plate Recognition", "Automatic License Plate Recognition", "Vehicle Detection System", "Vehicle Monitoring System", "Traffic Control System", "Traffic Monitoring System" etc.
One thing we can clearly state is that implementing ALPR on out-of-the-box Raspberry PI Does not mean anything. To make a commercial offering one should think in following dimensions:
Let's consider a common application of Vehicle Monitoring System on the highway to understand features, hardware components, software capabilities, and performance demanded from such systems:
Basic Hardware Components:
Now, this seems like a lot of work and very well it is. Once developed, such solutions open up many possibilities of automation, surveillance capability, and even research. But you must be wondering that if there is so much to offer then why such solutions are categorized as ALPR. That's because these solutions started with vehicle number identification and ALPR is still the centerpiece of any such offering.
All data points gathered about the vehicle need to be associated with a vehicle number. If vehicle number identification is incorrect then none of this makes sense. Thus algorithmic strength becomes the most important development criteria. What do I mean by this?
Consider our application of highway surveillance. In the scenario of foggy weather, night, multiple vehicles traveling at a speed of 120 Km/Hour (average). How well does your algorithm perform? Because this is an edge compute solution either you compress your model and make it suitable for low power devices (let go of some of the accuracies in favor of resource constraints in computation) or deploy compute-intensive hardware (this will increase the edge device cost).
We can deep dive further into the choice of algorithm and development technology to use but I leave it up to the reader to research such solutions further (depending on the interest). I only hope to convey that AI algorithm development is just a starting point while AI products or solutions development is a far greater path to cover.