Before a system can read the characters on a plate, it first has to find the plate itself in a full vehicle image, crop it out, and hand a clean rectangle to the OCR step. That cropping step, segmentation, is where most of the accuracy problems in automatic number plate recognition (ANPR) actually originate: a blurry or misangled crop dooms the character recognition that follows, no matter how good the OCR model itself is.
A full ANPR pipeline runs roughly: detect the vehicle, locate the plate region, segment it out, then read the characters. Segmentation is the middle two steps, and it has to handle angle, glare, partial occlusion (a trailer hitch, dirt, another car partially blocking the view), and wildly different plate formats and character sets across countries and regions, none of which the character-recognition step downstream can compensate for once a bad crop has already been handed to it.
The original approach to this problem, and still what a lot of open-source tooling was originally built on, uses classical computer vision: edge detection (Sobel or Canny filters to find sharp intensity changes), followed by contour detection to find rectangular regions matching a plate's expected aspect ratio, sometimes combined with color-based heuristics (many plates have a consistent background color that stands out from a vehicle's body).
This works reasonably well for well-lit, front-facing, close-range plates. It breaks down fast under steep viewing angles (the plate's apparent aspect ratio changes, defeating a fixed-ratio contour filter), motion blur (edges get smeared, weakening the edge-detection signal that the whole approach depends on), and low light (fewer sharp edges to detect at all). These are exactly the conditions a highway toll gantry or a border checkpoint camera deals with constantly, which is why classical-only systems tend to underperform specifically in the deployments where accuracy matters most.
The more recent, and now dominant, approach uses a convolutional neural network trained specifically to detect plate regions, often a YOLO-style object detector adapted from general object detection and fine-tuned on plate-specific training data. Instead of hand-coded rules about edges and aspect ratios, the network learns what a plate looks like directly from labeled examples across a wide range of angles, lighting conditions, and occlusion patterns, which is exactly the variation that broke the classical edge-and-contour approach.
The practical result: CNN-based segmentation handles occlusion and odd angles noticeably better than the older rule-based methods, because the model has actually seen partially occluded and angled examples during training, rather than relying on a geometric assumption (a clean rectangular contour at a roughly known aspect ratio) that simply doesn't hold under those conditions. The trade-off is that a CNN-based detector needs a reasonably large, diverse labeled training set to generalize well, and performance on a plate format or lighting condition genuinely absent from training data can still degrade, just less predictably than the classical failure modes.
| Tool | Model | Best fit | Trade-off |
|---|---|---|---|
| OpenALPR | Self-hosted, open source | Full control, no per-request cost, source available to modify | Real setup and tuning work for a specific camera angle and plate format, not a config flag |
| Plate Recognizer | API-based subscription | Noticeably better accuracy than a stock OpenALPR install on difficult angles | Ongoing subscription cost, dependent on their API uptime and latency |
| Carmen Cloud | API-based, enterprise-scale | High-volume toll and parking deployments rather than a single camera feed | Same network-dependency trade-off as Plate Recognizer, built for scale over a single deployment |
OpenALPR is the default starting point for anyone wanting to self-host: free, and the source is available to modify, but getting it tuned for a specific camera angle and plate format takes real setup work, not a config flag. Plate Recognizer trades that setup effort for a subscription, sending an image over an API and getting a plate string back, with noticeably better accuracy than a stock OpenALPR install on difficult angles, which is really the whole pitch for paying. Carmen Cloud targets the same API-first use case but leans harder into scale, high-volume toll and parking deployments rather than a single camera feed. The trade-off is the same either way with a hosted option: dependency on someone else's uptime and network latency, not just your own infrastructure.
OpenALPR handles well-lit, front-facing plates reasonably well, but accuracy drops fast with steep viewing angles, motion blur, or low light, the exact conditions listed above as classical computer vision's weak spot, because OpenALPR's default pipeline still leans on the classical edge-and-contour approach rather than a fully CNN-based one. That's the gap the paid, cloud-based options are built to close: more training data across angles and lighting conditions than most self-hosted setups can realistically assemble on their own, at the cost of a subscription and a network dependency.
The honest framing: if the deployment is a single, reasonably controlled camera angle (a gated parking lot entrance, for instance), OpenALPR tuned properly for that specific setup can perform close to the paid options at zero per-request cost. If the deployment spans varied conditions, multiple camera angles, outdoor lighting, higher speeds, a hosted CNN-based option's broader training data becomes worth the subscription. Testing against actual footage from the real deployment site, not a vendor's demo images, is the only reliable way to know which side of that line a specific use case falls on.