License Plate Detection Without Machine Learning
sod.pixlab.io
sod.pixlab.io
Spoiler alert: these kinds of image processing Rube Goldberg machines fall apart real quick with real world conditions.
> The intent of this article is to sensibilize the reader that a machine learning approach in not always the best or first solution to solve some object detection problems.
The danger of this article is people end up wasting time & budget with brittle approaches.
(Though to be fair the danger of the deep learning/ML route is people can end up wasting just as much time when they don’t have an adequate amount of training data.)
Robust feature detectors, voting methods, etc. can fill that gap for object detection and pose estimation. Also simpler machine learning models for classification like SVMs.
It increasingly feels like the slice of computer vision techniques I learned in the early 2000s is receding in relevance. But at the same time, there ought to be a more modern grab bag of robust tools to build engineered solutions.
In the end any algorithm is only as good as the dataset it’s developed/validated against. Ad-hoc methods may fail in bright sunshine, but so too would a neural network if that condition never arises in its training set.
After tiring of convoluted web 3.0 frameworks and Babel-esque dependency structures, programmers have finally fashioned a black box they cannot understand which relieves the anxiety of knowing they should.
I'll wait.
Until then, when it comes to the state of the art in things like reading license plates, it's the old algorithmic approaches (like described in the article) that result in convoluted, brittle, easily broken approaches - far closer to the "convoluted web 3.0 frameworks and Babel-esque dependency structures" you seem to despise.
DL may not be fundamentally understandable (yet), but it works a hell of a lot better than stringing together image processing algorithms.
Why would the car be at an angle? These type's of systems are usually directly overhead of a lane of traffic I would imagine; like at a tollbooth.
The rest of that would be the job of the camera itself to best expose the image, no?
Just look at existing ANPR installations. You get tight lanes. Barriers to arrest cars. High and low angle cameras working together. Heavy use of IR illumination (reads through all but the thickest mud IME).
That's not to say some people don't get it wrong. I've worked on systems where they've cheaped-out and put a single camera at bumper-level. It's completely ineffective 2-4pm in winter because of the glare.
But yeah, if you can avoid being a cheap idiot, you can easily take a system to 90+% confidence.
And doesn't it fail just as hard if it encounters a real-World example that it can't fit into its model?
Probably a very naive question but this is entirely outside my domain.
But to do OCR you need ML. Not "100 layer DL CNN using the latest arxiv paper" but a shallow learning technique should be enough.
Those techniques could also be useful for identifying the license plate.
The methods described in the article are dated, and worthless
Disclaimer: I build number plate recognition systems
Edit: They are dated and might have made sense some 8 years ago which is when I heard of them being used
In this task accuracy is much much more important than computational efficiency, and given a forward pass is already quick (less than 2 seconds) why wouldn’t you use the superior method that always works?
Check out some of the hard cases here: https://waysight.com/lpr-technology/#examples
I couldn't use neural networks at the time, because 1) it had to run in a single core 200 MHz ARM at 20 fps, and 2) it took too long to "debug" the NNs (often you want to improve performance and the failure cases seem fine to you)
So the resulting performance of this system was and is state of the art in that in practice it captures everything correctly, so there is no point wasting cycles on an NN solution.
On the other hand, starting from scratch, an NN solution can allow you to advance quickly with little domain knowledge.
I would like to repeat a word of caution other posters mentioned as well - it takes years to collect the training data required for successful commercial LPR, both for NN and non-NN methods (as you need regression tests even if you don't need it for training), to get plates from all seasons and weathers and vehicle conditions.
Interestingly, now almost 10 years later, when I look at more modern deep NNs and analysing their initial stages with modern tools I see a lot of similarity to my original "standard" algorithms. In essence, the code I wrote did the same thing a modern convolutional deep NN would learn to do.
In particular, see this recent analysis of how (some) convnets learn:
https://www.lyrn.ai/2019/02/14/bagnet-imagenet-with-a-simple...
Which, as it turns out, is really similar to how 80's and 90's style classic OCR algorithms work!
While the machines learn, the humans don't.
Are those not an issue or does the tech just fail so hard on those it's not even worth trying?
Every other older vehicle where I live has a front plate that's got a horizontal bend in it from when you park with the front end in a snow bank so while not a majority case it's not exactly an edge case either.
Some bending and distortions are tolerated, so maybe it would work. One of the design goals I had was that if the system fails, it should fail in a way a human would understand (like dirt in the wrong place turns an F into an E, or something like that). And if a human can't immediately see the bent chars (and had to "reason" about them), probably my system would have problems as well.
The plastic bracket doesn't usually support the bottom half and the result is a license plate that's formed to perfectly follow the contour of the bumper (for stuff that still uses a steel bumper) or just bent into the empty space of the lower grill opening (on many cars)[1]. Then there's all the work vans that just have the license plate affixed wherever on the front bumper the owner felt like drilling two holes.
[1]https://upload.wikimedia.org/wikipedia/commons/7/72/2000_Sub...
I would imagine there's probably some mental disconnect about how damaging ice could be because "hey, it's just frozen water, it's not like it's concrete or something"
I suspect this won't be the case for much longer (or perhaps already isn't). It seems successful generalization from simulated environments is within reach.
This is a good lesson to teach people! But I don't think that this page does so successfully. By far and away the biggest issue is that they are only demonstrating on a single image. You can get almost any method to work on a single image, especially when you're interactively designing the method to work on that specific image. If you want a method that works in unforeseen conditions, you need to think carefully about your assumptions...
* Threshold on 0.5–will that work at night? What if you're driving into the sun and the image is overexposed?
* Dilating canny edges and finding connected components–what if the car is white with black trim, and the dilation merges the license plate CC with another one? What if the car is further away, and the dilation factor merges the entire car into one big blob?
* Filtering the blobs by ratio–what if the car is at an angle (turning, or starting up a hill), so the ratio is off? What if they have bumper stickers that are the same shape, and fool the filter?
While you can make a reasonable license plate detector with traditional methods (see, for example, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.455...), the advantage of using ML methods is that, if done correctly, they actually have a chance of working in most the situations you encounter (including the assumption-violating ones above), rather than just the ones you can think of while making the system. That lesson is probably just as important as the "don't jump straight to ML" one.
How do you fix an ML model that fails to cover a weird special case?
Ultimately, you will need to validate the model, whether parametric as the old algorithms, or not, as in ML.
You bring examples of those special cases into the dataset.
People are absolutely desperate to show that ML isn’t the answer to everything, which nobody in ML claims it is. But it is the very clear answer to some things, and problems like license plate detection fall so unambiguously into that category that, quite frankly, if you think otherwise you’ve really disqualified yourself from the set of people who ought to be asked about these things.
In my team, we don’t use deep learning for every problem. We don’t even use machine learning for every problem. I’m a Mathematician, and frankly I’m just not that immature. The fact is, ML is a great solution to a lot of problems, and Deep Learning is a particularly good solution to an ever-increasing category of problems.
If you can’t tell the difference between such cases, then you should probably not conclude that everyone is doing it wrong, and instead conclude that you have more to learn.
This article shows how by following a number of logical steps (and explaining how the algorithms work), you can achieve numberplate recognition.
These techniques have been used for DECADES. They work on machines your ML model likely wont fit on. In some cases they are faster. In some cases they are slower. In some cases they are more accurate, and in some cases they are not.
If you think ML is the magic bullet to any task you've really disqualified yourself from the set of people who ought to be asked about these things.
> We don’t even use machine learning for every problem.
Since your comment is in obvious bad faith, this is the only response you’ll get from me.
You’re free to have this opinion. I don’t see how it could possibly be justified.
> that requires data of still huge amount
This is true for some problem spaces, but not true in general. If your exposure to Deep Learning is relatively casual, then I can see why you would think this. So while it’s not a totally unfair criticism, if you’re in a problem space wth lots of data, and you have a method that performs well under those circumstances, then you’ll have to do more work to convince me it’s a bad idea to use it.
> and still has terrible failure modes. It is not yet ready, not until we can reason about those failure modes better than using highest end statistics.
This just feels like parroting others’ criticisms. Yes, our primary method for understanding failure modes of stochastic function approximators are statistical, the same as they are for stochastic processes. Statistics is precisely what is used to rigorously describe behaviour in the aggregate that cannot be well explained in the particulate.
It also ignores the fact that there is a huge amount of theory that is currently being developed around deep learning. You won’t see it linked on HN, and you likely won’t find many in the typical software engineering crowd who know about it (which is fine! - software engineers are highly skilled specialists, who should not be expected to closely follow the mathematical literature), but it does exist, and several of my friends who remained in acadaemia are building careers on developing it.
As a general aside, I have to say that the glibness of the responses objecting to my comment really does speak volumes.
It is certainly do-able and has already been implemented by banks for image based clearance/processing of cheques[1] and fraud detection. The caveats in this case would include a large set of training data and a supervised model for handwritten examples.
[1]https://www.pyimagesearch.com/2017/07/24/bank-check-ocr-with...
https://github.com/mathDR/reading-text-in-the-wild/blob/mast...
This is almost sounding like ASM vs Python.