License Plate Recognition (LPR) Axis App Tested

Author: Ethan Ace, Published on Sep 08, 2014

License plate recognition (LPR) has historically been very expensive, requiring specialized hardware and software.

An embedded LPR app from ipConfigure aims to change that, turning compatible Axis cameras into all-in-one LPR systems, now with integration to Exacq.

LPR vs LPC

Many confuse LPR and LPC.

License plate capture (LPC) is the ability for a camera to 'capture' a clear image of a license plate that a human being can read. For background, see License Plate Capture Shootout 2014.

License plate recognition (LPR) is the ability for a computer to automatically recognize and display the specific characters of the license plate as text, without any human intervention. It requires LPC but is far more demanding.

LPR Test

To see how the ipConfigure app performed in real world applications, we tested it with an Axis Q1604 at both slow speeds, below 5 MPH, and high speeds, 30+ MPH, seen below:

In this report, we detail its performance in these scenes, potential issues in your application, key recommendations, and more.

******* ***** *********** (***) *** ************ **** **** *********, ********* specialized ******** *** ********.

********** *** ********************** ** ****** ****, ******* ********** **** ******* **** ***-**-*** *** *******, *** **** integration *******.

LPR ** ***

**** ******* *** *** ***.

******* ***** ******* (***) ** *** ******* *** * ********'*******' * ***** ***** ** * ******* ***** **** * human ***** *** ****. *** **********, *** ******* ***** ******* ******** ****.

******* ***** *********** (***) ** *** ******* *** * ******** to ************* ********* *** ******* *** ******** ********** ** *** license ***** ** ****, ******* *** ***** ************. ** ******** LPC *** ** *** **** *********.

LPR ****

** *** *** ************** *** ********* ** **** ***** ************, ** ****** ** **** an **** ***** ** **** **** ******, ***** * ***, and **** ******, **+ ***, **** *****:

** **** ******, ** ****** *** *********** ** ***** ******, potential ****** ** **** ***********, *** ***************, *** ****.

[***************]

Key ********

**** *** *** *** ******** **** **** ****:

  • *** ******: ** * *** *** *****, ********** *** *** **** ** ******* ****** ****** *** *** *** at *****, **** ** ****** ***** (**/**), ****** ******** ***** ** the **** ***** **** ********. 
  • **** *****: ** **-** *** ***** * ***** ****, ******** ******* to ***** **-**% **** *** *** ***** (**/** ** * half **** ******), **** *** **** ******** ***** ***** ******** of similar ********** **** ******, **** ** */* *** */*.
  • ********** ***** ** ***** ***** **** ******* ******, **** ** background *******, ******* *******, ** ********** ******* ********* (* *********** in ** ******* *** ~*** ****).
  • ****** ** ********** ******** ** ****** ***** *** ** **** with***** **** ********** *********.
  • ***** ****: ****** ** ************ ** ******** *** ********* ***********, *** **** be ********* *** ** ** *** ** ** *** ****, not ********* ****** ********, *** *** ******, ******* *** *** plate.
  • ***********: *** **** *** **** ******** *** ** *** ***.* ****, *** ****** *** *************** **** ***** *** *****, ********* ** * ****** (~*'*") *** short *** ***** *** **** **** ****** ** *** ********* set, such ** ***** ******* ****** **** ****** ** ****** *** ****.
  • ******* *********: ******* ** ****** ** ********** **** ******-* ******* ****. *** Q1602 *** ******************* *************. ***** ***** * ****** ******* **** *** *****-** (******-* with *****-** **) *** *** ***** *** ******* *** ********************.
  • ***** *********: *********** ********** ********** **** *****. ***** ***** ***** ****** ****** ******* over *** *** ** *********, *** **** *** ****** *************.******************* ***** ************ ***.

*******

*** ******** *** *** *** ** **** ** $*** ***. Combined **** ****** *******, ***** ****** ****, ********* ** ***-** ***********, ** ** the ***** ** $*,***-*,***. **** ** *** ******** ** **** other *** ******, *** *******:

  • ******** ***:********'* *** ***-** ******** * *********** ******, ******** *******, *** server ******** *******, ********* ***** ~$*,*** *** ****.
  • ******* ******:*** **** *********'* ************ **** ********** **** ****** ~$*,***, **** ******* ~$*,*** ** licensing ***** *** ****** ******, ******** $*,*** *** * ****** camera ******.
  • ********************: *********'* ******** *** ** *** ** *** ****** **** *********** *******, **** ** initial ******* **** ** ~$*,***, **** $*,*** *** **** ********** camera. **** **** *** ******* ******** **** ********* (********* ** higher), ********* ******* ** ************.

***************

******* ** *** **** ******** ** *** ****** *** *** cost ******** ** **** *** *******,***********'******** ** **** ****** ** ************ **** **:

  • *** ***** ******* ******* ******* *****, **** ** * ********* campus ** ****** *********.
  • ****** ******* ****** *******, ***** ****** ** **** ***** *********, etc.

** ***** ************, ******** ****** ** ****** ** ***********'* ********** *** *************, ***** ** ****, *** ************ *** followed.

*** ****** ****** ***** **-** ***, *** **** ** ******** makes *** ********** ** ****** ******** *** ******* ********** **** problematic. ***** ******* *** *********** ** ***** ****** ***** ****** be ****** ****** ** ****** *** ********* *** *******. ******* such ** ***** **** ********* ** *** ****** **** ****** such ** ******** *****, ******* ******* ******* ** *******, ***. 

App ***********

******* ** *********** **** *** **** ***'* ******-* ********* ** ********** slow, ***** *** *** *** *********** ** *** ***********:

  • *** ***** ****:********** ** **** ******* ** ********** ** ** ** ***, and **** ** *** ******* ******. ****** ******* ** ***** speeds ******* ** *** ********** ***** ******* ** *******, ******* the **** **** ***** ******* ** ***** **** ***** *********.
  • *** **********:**** **** **** ** *** *.*** *****, *** *** ********* images **** ** *** *** * *** **********. ******* ** this, ****** ** **** *** *****, ******** ****** ******** *****.

Narrow Field ** ****

********************* ******** ** ***** *** ****** *** **** **** ***** the **** *****, ********* ** **** * *'*" ********** ***** of ****, *** ***** * *' ******** ***** ** ****. Because ** ****, **** ********' ****** **** ******* *** **** for *** ***.

************, ******* ** **** ***** ***** ** ****, * **** overview ** *** *** ** *** ********, ********* ******* ****** if **** ** *******. **** *** ***** **** ********* ******* on *** **** ** *** *******, ** **** ** ***** in *** *******. ** *****, *** ** *** */***** ******* *** ** illumination ********, ***** *********** ** ********** ***********.

App/Camera *************

********** ******** ** ** **** *********** ** *** ***** *** Q1604.

*** ********* ***** ******* *****************'* ******** *** *********** ******* ** ****** ********.***********'* ********** ***** * ***** ******* ***** ** */*****, *** **** lowered ** **** ***. 

App **** *********

*** **** ********* ** *** *** ******** *****, **** ****** and ******* (*********** ** ***), *** ****** ***** ** ****** for *** ****** *****. **** ***** ******* *** ****** ** use:

Read ******

***** **** * *** ****** ****** ***** ******** ** ******** and *********** ***********:

******** *****

* ******** ***** ***** ***** ************** *** *********** *** ******** ***** *** *** **** *******. **** increases *** ***** ********** *****, ******* ***********, *** **** *********** reads. ***** ****** ***** ******** **** **** ******* ** ****, inaccurate ****** *** ***** (** ****) ***** ** * ***** otherwise ******** **** ***** **** ******.

******* ***-***** ****

*** *** ********** **** ***-***** **** **** ** *** ********* or **** ****** ********, **** ** **** ***** *******. ***** reads ****** ******** ** ****** ********, ** *** ***** *** also ****, *** ******* ***** ** *** ********* ** *** reads.

******* ***** *****

******* ****** *** ******* ******* ***** ********* ************ ***, ** with *** ***** ** ***-***** ****, ***** *** ******* ******** of ***-******** ********.

********** ******* *** ******* ** *** ***** ***** ************ ****** * false **** ** **** *****.

High ***** *****

***** ** ****** *** ****** ** * ******** ****, **** traffic ****** ***** ** ***.

*******

****** *** ***, ******* *** ******. ** ******** ****, ***** 80-85% ** ****** ********** **** *******. **** ********, *** ***** were *** ** ** ******** *** ** ** ** ******** for **.

*********

** *** ** ** *** **** ***** ** ***** ***** a **** ******* ******** ** ***********, ********** *******. **** ****** ******* ****** *** *** **** ******* ** *****, with ********* ********, *** ******* ******** ******** ***** *** ****.

Low ***** *****

** *** ****** *****, ** ****** ******** ** *** *****, typical ** * ********** ******* *********/*****. ** ***** ******, ******** reads ** *** ****** **** ********. *******, ******** ***** **** still ********.

** ***** ** **** *****, ***** *** ** *********** *** located ****** ** *** *******, *********** ***** *** ** ** carefully ******** ** ******* ****** ******** ** ********** *** *****, but *** ********** **, ******* *** **********.

ExacqVision *********** & ****** *** ** ****

********** **** *****, ********** ***** ****** *** **** ** **** ***** ** * watchlist, ***** *** ********* ** ** ******* ** *** ******'* video ****, *** *** ** ******** ** **** ** ******* events. **** ***** ***** *** ************* ** **** ***********, * typical ****, *** ****** ******:

*******, *** ** **********, ***** *** ** * ***** ******* the ******* ******* ******* *** *** *** *** **** ******* being **** ** *****. **** ******* ** ****** ****** ***** linked ** ********* *****, **** ** **** *******:

**** *** **** ****** ** **** ***** *****, ***** *** processing ***** ******* ******. ****** ** ** **** ** ** seconds **** ******** ** **** ********. ** ****** ******, ****** data *** **** **** *******, **** ****** ** ** *****.

***********

*** *******, ** **** *** **** ***** **** ******** ******* 5.50.3. *** ******** ** *********** **** *** * ******* *******-****.

*********** ******* *.*.***** *** ****.

Comments (27)

Want us to test other LPR software? I am sure many of you do.

We started with this one because its low cost and compatibility with a major camera manufacturer makes it feasible for a broad portion of the market.

There has been good interest in license plate testing, so we are definitely open to testing more LPR.

The accuracy numbers ... whatever were observed change from location to location, country to country, state to state and other conditions like time of day and illumination, speed, view angles, FoV etc (things already identified in this test). One of the challenges is to deliver consistency across all the above variables. Not sure how you would be able to test across all such variations to give sufficient insights to people who would like to choose among different offerings.

I'd be interested in seeing you review Platesmart and Image Sensing systems: Both who integrate with ExacqVision.

I tested out that integration, even getting the recommended lens with an Axis Q1604 and I have to say I was very unimpressed. I'll give you it is "low cost" compared to other systems, but it was still prohibitively expensive for its accuracy rate...

#SpoiledByAutoVu

(I am VP Engineering for IPConfigure)

Sean,

I am not aware of the specifics of your experience, but in general we have found that poor recognition accuracy is often due to an incorrect physical installation. Because Embedded LPR uses a surveillance-grade camera and runs on a device with limited computing resources, installation details such as pixels-per-foot, angles between camera and license plate, and vehicle approach paths need to be exactly right. Systems like AutoVu, with very expensive LPR-specific CCD cameras, tend to be more forgiving in this respect.

Best,

Cort Tompkins

I want to mention that almost all modern IP-cameras use CMOS sensor that affects recognition quality alot in case of fast moving cars. Most of them are with rolling shutter and it's effect may be seen even in 30 mp/h (just take a look at last picture in the article). Taking this into account I believe that results for fast cars may be better in case of strictly frontal camera view. Unfortunately rolling shutter will affects all recognition systems, both embedded and server-based. My opinion that to recognize fast moving license plates one need to use a camera with global shutter sensor.

Hi Igor, you have raised a very good point. Do you know of any surveillance cameras that use a global shutter? I wonder if dedicated LPC or LPR cameras use a global shutter?

Hi Luke, I am not sure that it'll be correct to mention here exact brands. John, please clarify this point.

Hi Igor, I believe it would be both correct and important to mention examples of IP surveillance cameras with global shutter if they exist. I'm not sure why you might be worried as to whether that would be a correct thing to do. If you have an affiliation with one of the brands, then just mention that in your next post and it should be fine.

I'd be surprised if any brand used global shutters in its entire line of surveillance cameras. My guess is that only select models would have that feature and it would be very helpful to find out the make and models of any that you know. In retrospect, I'm surprised the topic of global shutter does not seem to have been raised in the past, especially for traffic at high speed. I wonder why not?

Here is an example from the above test of a 'regular' rolling shutter IP camera at 30mph (with a 1/2000s shutter):

And here is the last picture in the article, as cited as being a problem:

The numbers on both images are quite clear. I don't see the issue.

Thanks very much John. It's great that rolling shutter is a non-issue in the examples you have provided.

I'm left wondering why it isn't an issue? I know that panning (non surveillance) cameras can lead to rolling shutter problems, and fast movement can show up rolling shutter problems even when not panning. Maybe the movement just has to be much faster than regular traffic for it to be an issue for surveillance cameras?

Even with a rolling shutter, the shutter is moving very quickly and the license plate is a relatively short area, meaning that the whole of it gets scanned rather quickly.

With a 1/2000s shutter, the whole frame is captured in .5ms, the area where the license plate is a fraction of even that. How much is the plate moving in a fraction of a ms?

As the vehicle moves faster, the more an impact this will have but as, our shots from 30mph show, it's not a practical problem there. Maybe the issue gets significant at 90mph, but how many people are doing LPR at such speeds. And at those speeds, there are lots of other issues, including having a high enough frame rate to even get a shot of the plate.

Thank you John, that's very helpful. I guess that as one usually tries to capture licence plates as close to straight-on as possible, this also accidentally helps to negate the rolling shutter effect.

With a 1/2000s shutter, the whole frame is captured in .5ms.

John, with all due respect, I don't think that is how rolling shutter actually works. Rather, the whole frame is NOT captured in .5ms, not in the SAME .5ms anyway. With a CCD or global shutter what you say is true, but with CMOS it not possible because those sensors (usually) do not have a capacitor to store charge on each pixel.

Rows of pixels must be read sequentially, each row read takes a finite time.

The shutter speed only insures that the total amount of time any row of pixels is exposed is exactly .5ms, but not that it is the same .5ms. This time-shifting of reads is the very cause of rolling shutter artifacts.

However, the typical examples that I've seen of rolling shutter involve high speed motion with respect to the sensor, e.g. fan blades spinning, extremely quick panning. But the effect is not so pronounced in LPR because the relative speed is far slower. If you were to try to capture a number painted on a cars side door at close range then it would be more apparent.

"The shutter speed only insures that the total amount of time any row of pixels is exposed is exactly .5ms"

Is it the row or the frame?

If the shutter speed is 1/2000s, that means the entire frame is captured in that 1/2000s, aka 0.5ms. If there are, for example, 1080 rows, that means each row is captured in 0.5ms / 1080. yes/no?

If the shutter speed is 1/2000s, that means the entire frame is captured in that 1/2000s, aka 0.5ms.

For rolling shutter this is absolutely not true. If it were true there would be no artifact.

A ROLLING SHUTTER is very different. The rolling shutter actually exposes different portions of the frame at different points in time, “rolling” through the frame. ... the sensor is telling different portions to become light-sensitive at different moments in time, and as this process proceeds down the course of the full frame, until the entire frame is exposed. dvxuser.com

One type of artifact occurs when a fast moving object object is read by the top row of the sensor, and if the object is moving downward fast enough that it gets recorded by the bottom row of the sensor, then the object will appear twice in distinct locations, in the same frame! Note this is not blur since the object shows up twice (or more) as discrete objects, like so: (rolling left, global right).

Rukmini,

I am saying it rolls across the entire period of 0.5ms for a single frame at 1/2000s shutter.

Let's say the frame has 1000 rows (to keep math simple). Then each row would be covered in 500ns if the shutter speed was 1/2000s (i.e., 5ms / 1000 = 500ns). Yes/no?

I am saying it rolls across the entire period of 0.5ms for a single frame at 1/2000s shutter.

Disagree. I know what you are saying, it's logical and intuitive but it's just not true.

Here is a simple proof that the absolute time span of a rolling shutter frame must ALWAYS be longer than that of the interval of the shutter speed.

A rolling shutter turns on (exposes) rows of pixels sequentially, starting at the top, one row at a time, and very quickly*. It does this all the way to the bottom row.

The bottom row therefore is turned on last, after the delay of turning on all the other rows.

All rows must be allowed the full exposure time before being turned off (read), so the time that the last row is turned off is some time (1-10 milliseconds?*) after the turning on of the first. Therefore the difference between the first one turning on and the last one turning off is at least the length of shutter speed, plus the initial delay. So the frame must span events greater than the ss interval alone. Agree?

If not, I'm not sure what I could state clearer, maybe you have a supporting reference I can read so I can understand what you mean.

*It depends on the sensor but I have seen estimates from 1 to 10 microseconds per row so 1-10 milliseconds per 1000 line frame seems reasonable. But no matter what it takes some measurable time to turn on each row.

Dear John,

Both images are quite clear, but characters slope depends on vehicle speed. To neutralize this effect possible value of slope must be taken into account in mathematical model of characters images. AFAIK from my experience most of developers don't do this.

IPConfigure's Embedded LPR features a skew correction processing step that attempts to rectify detected license plate characters before recognizing them as text. This is why the segmented black and white image in John's 30 mph image appears upright even though the text on the original image is obviously slanted.

A global shutter is preferred for most machine vision applications, but in the case of LPR a rolling shutter is not disadvantageous if the recognition algorithm includes a skew correction method, as discussed.

Hi Luke, I know that Basler produces IP-cameras with global shutter sensor. For example, http://www.baslerweb.com/products/Fixed-Box.html?model=181&language=ru&language=en

Hi Igor, thank you for the link. I read their paper on rolling shutter vs global shutter for video surveillance. I got the impression that the global shutter might be useful in situations with poor illumination (of licence plates) and fast movement. However as all of the tests in this article were either in clear daylight or with IR illuminators at night, it would not appear that global shutters would be of much benefit.

You are absolutely right. For slow cars it does not matter what kind of shutter you are using. "Remedy" for poor illumination is good sensor sensitivity (regardless of shutter type).

We've corrected a mistake in the pricing section above. The $15,000 MSRP cited for Genetec reflected a two-camera mobile system. The price for a single fixed camera is about $7,000 in camera and processing unit hardware plus about $2,000 in licenses for AutoVu server and channel licenses.

Hi all

As this is a very interesting subject i.e. capturing fast moving images, and the shutter issue seems to be a core influencer, I want to share with you a link I found to a photography site that will surely provide lots of insight and answers. Take the time to watch the videos.

Hope you all enjoy it:

http://www.diyphotography.net/everything-you-wanted-to-know-about-rolling-shutter/

Here's a good explanatory video from that page:

Again, the main practical issue is that the example are objects moving incredibly fast - likely the equivalent of thousands of miles an hour. As such, it's not applicable to even 'fast' moving cars.

We've been installing ANPR for over 8 years in the UAE and found the highest accuracy/capture rates come from a system previously known as Appiantech and later bought out by US based NDI. They have the highest number of context checkers for the region and perform well at high speeds up to 260KPH. Challenges still exist on the color recognition side, and changes in plates over the years. The system needs to be continously updated to recognize the new plates. The cameras outperform anything we have seen to date, combining overview, ANPR and a pulsed IR unit all in one casing. Downside, the solution doesn't come cheap at all but does the job well.

Login to read this IPVM report.
Why do I need to log in?
IPVM conducts unique testing and research funded by member's payments enabling us to offer the most independent, accurate and in-depth information.

Related Reports

Hikvision ColorVu Integrated Visible Light Cameras Examined on Jun 22, 2018
When it comes to low light, infrared light has become the defacto standard in surveillance. But IR is limited to monochrome images, making colors...
IFSEC 2018 Final Show Report on Jun 20, 2018
IPVM attended the IFSEC show for the first time this year. The Chinese have taken over the UK, centered on Hikvision, flanked by Dahua, Huawei and...
Mobotix Releases 'Move' Into 21st Century on Jun 20, 2018
For years, Mobotix stood resolutely against, well, every other manufacturer, selling it as a virtue: MOBOTIX equipment is designed with no...
Hikvision 12MP Fisheye Camera Tested (DS-2CD63C2F-IV) on Jun 14, 2018
Hikvision's DS-2CD63C2F-IV is their flagship panoramic camera, with a 12MP imager, 15m integrated IR, smart codec, and more. We tested the 63C2 in...
China Public Video Surveillance Guide: From Skynet to Sharp Eyes on Jun 14, 2018
China is expanding its video surveillance network to achieve “100%” nationwide coverage by 2020, including facial recognition capabilities and a...
Avigilon H4 Multi-Sensor Adds 32MP, H.265, Analytics on Jun 13, 2018
Avigilon has announced the H4 Multisensor, the successor to their repositionable multi imager line, adding features like H.265, integrated IR,...
Introducing Effective PPF (ePPF) - Improving Video Surveillance Designs on Jun 11, 2018
Pixel density (PPF / PPM) is the best metric the industry has to define and project video quality. It allows simple communication of estimated...
Hanwha Low-Cost 4MP Camera Tested (QNV-7010R) on Jun 11, 2018
4MP usage is increasing noticeably, as IPVM 2018 resolution statistics show. And low-cost, fixed focal cameras, are popular for budget...
Hikvision PanoVu 20MP Flexible Camera Tested on Jun 01, 2018
Hikvision has released their first repositionable multi imager cameras with integrated IR included, atypical in competitors. We bought and tested...
IP License Plates on Jun 01, 2018
IP cameras, IP speakers, IP toasters... IP license plates? The next generation of license plates is making mainstream news, being called...

Most Recent Industry Reports

July 2018 IP Networking Course on Jun 22, 2018
  This is the only networking course designed specifically for video surveillance professionals. Register now. Lots of network training exists...
Installation Hardware for Video Surveillance - Indoor Fasteners on Jun 22, 2018
As part of our Installation for Video Surveillance series, in this note, we cover drywall anchors. A key part of installing security hardware is...
Hikvision ColorVu Integrated Visible Light Cameras Examined on Jun 22, 2018
When it comes to low light, infrared light has become the defacto standard in surveillance. But IR is limited to monochrome images, making colors...
'Secure Channel' OSDP Access Control Examined on Jun 21, 2018
Despite claiming to be better than Wiegand, OSDP's initial releases did not address the lack of encryption between reader and controller, leaving...
Most Wanted Improvements In Manufacturer Technical Support (Statistics) on Jun 21, 2018
5 key areas of improvement and 1 clear wanted support feature were voiced by 140+ integrator responses to: What improvement in manufacturer...
GDPR / ICO Complaint Filed Against IFSEC Show Facial Recognition on Jun 20, 2018
IPVM has filed a complaint against IFSEC’s parent company UBM based on our concern that the conference violates core GDPR principles on...
IFSEC 2018 Final Show Report on Jun 20, 2018
IPVM attended the IFSEC show for the first time this year. The Chinese took over the show, centered on Hikvision, flanked by Dahua, Huawei and a...
Mobotix Releases 'Move' Into 21st Century on Jun 20, 2018
For years, Mobotix stood resolutely against, well, every other manufacturer, selling it as a virtue: MOBOTIX equipment is designed with no...
Cybersecurity Startup VDOO Disclosing 10 Manufacturer Vulnerabilities Starting With Axis And Foscam on Jun 20, 2018
Cybersecurity startup VDOO has uncovered significant vulnerabilities in Axis cameras along with many others not yet disclosed. In this report, we...
Axis Guardian - Cloud VMS And Alarm Monitoring - Released on Jun 19, 2018
Axis has struggled to deliver a cloud-based managed service video platform. Video service providers have utilized AVHS for over a decade, and have...

The world's leading video surveillance information source, IPVM provides the best reporting, testing and training for 10,000+ members globally. Dedicated to independent and objective information, we uniquely refuse any and all advertisements, sponsorship and consulting from manufacturers.

About | FAQ | Contact