******* ***** *********** (***) *** ************ been **** *********, ********* *********** ******** and ********.
********** *** ********************** ** ****** ****, ******* ********** **** ******* **** ***-**-*** LPR *******, *** **** *********** *******.
LPR ** ***
**** ******* *** *** ***.
******* ***** ******* (***) ** *** ability *** * ********'*******' * ***** ***** ** * license ***** **** * ***** ***** can ****. *** **********, *** ******* ***** ******* ******** ****.
******* ***** *********** (***) ** *** ability *** * ******** ** ************* recognize *** ******* *** ******** ********** of *** ******* ***** ** ****, without *** ***** ************. ** ******** LPC *** ** *** **** *********.
LPR ****
** *** *** ************** *** ********* ** **** ***** ************, we ****** ** **** ** **** Q1604 ** **** **** ******, ***** 5 ***, *** **** ******, **+ MPH, **** *****:
**** *** *** *** ******** **** this ****:
*******
*** ******** *** *** *** ** MSRP ** $*** ***. ******** **** a***** *******, ***** ****** ****, ********* ** add-on ***********, ** ** *** ***** of $*,***-*,***. **** ** *** ******** to **** ***** *** ******, *** example:
***************
******* ** *** **** ******** ** low ****** *** *** **** ******** to **** *** *******,***********'******** ** **** ****** ** ************ such **:
** ***** ************, ******** ****** ** strong ** ***********'* ********** *** *************, ***** ** view, *** ************ *** ********.
*** ****** ****** ***** **-** ***, its **** ** ******** ***** *** likelihood ** ****** ******** *** ******* characters **** ***********. ***** ******* *** recognition ** ***** ****** ***** ****** be ****** ****** ** ****** *** dedicated *** *******. ******* **** ** these **** ********* ** *** ****** from ****** **** ** ******** *****, reading ******* ******* ** *******, ***.
App ***********
******* ** *********** **** *** **** ***'* ARTPEC-4 ********* ** ********** ****, ***** are *** *** *********** ** *** performance:
Narrow Field ** ****
********************* ******** ** ***** *** ****** per **** **** ***** *** **** Q1604, ********* ** **** * *'*" horizontal ***** ** ****, *** ***** a *' ******** ***** ** ****. Because ** ****, **** ********' ****** were ******* *** **** *** *** FOV.
************, ******* ** **** ***** ***** of ****, * **** ******** ** the *** ** *** ********, ********* another ****** ** **** ** *******. Make *** ***** **** ********* ******* on *** **** ** *** *******, as **** ** ***** ** *** daytime. At *****, *** ** *** */***** shutter and ** ************ ********, ***** *********** ** completely ***********.
App/Camera *************
********** ******** ** ** **** *********** on *** ***** *** *****.
*** ********* ***** ******* *****************'* ******** *** *********** ******* ** camera ********.***********'* ********** ***** * ***** ******* ***** at */*****, *** **** ******* ** 24db ***.
App **** *********
*** **** ********* ** *** *** displays *****, **** ****** *** ******* (highlighted ** ***), *** ****** ***** to ****** *** *** ****** *****. This ***** ******* *** ****** ** use:
Read ******
***** **** * *** ****** ****** which ******** ** ******** *** *********** degradation:
******** *****
* ******** ***** ***** ***** ************** *** *********** *** ******** ***** *** the **** *******. **** ********* *** image ********** *****, ******* ***********, *** adds *********** *****. ***** ****** ***** captures **** **** ******* ** ****, inaccurate ****** *** ***** (** ****) reads ** * ***** ********* ******** read ***** **** ******.
******* ***-***** ****
*** *** ********** **** ***-***** **** such ** *** ********* ** **** bumper ********, **** ** **** ***** vehicle. ***** ***** ****** ******** ** missed ********, ** *** ***** *** also ****, *** ******* ***** ** the ********* ** *** *****.
******* ***** *****
******* ****** *** ******* ******* ***** negatives ************ ***, ** **** *** issue ** ***-***** ****, ***** *** several ******** ** ***-******** ********.
********** ******* *** ******* ** *** scene ***** ************ ****** * ***** **** as **** *****.
High ***** *****
***** ** ****** *** ****** ** a ******** ****, **** ******* ****** about ** ***.
*******
****** *** ***, ******* *** ******. Of ******** ****, ***** **-**% ** plates ********** **** *******. **** ********, bad ***** **** *** ** ** mistaken *** ** ** ** ******** for **.
*********
** *** ** ** *** **** scene ** ***** ***** * **** powered ******** ** ***********, ********** *******. **** ****** ******* ****** *** *** were ******* ** *****, **** ********* misreads, *** ******* ******** ******** ***** the ****.
Low ***** *****
** *** ****** *****, ** ****** vehicles ** *** *****, ******* ** a ********** ******* *********/*****. ** ***** speeds, ******** ***** ** *** ****** were ********. *******, ******** ***** **** still ********.
** ***** ** **** *****, ***** the ** *********** *** ******* ****** to *** *******, *********** ***** *** to ** ********* ******** ** ******* enough ******** ** ********** *** *****, but *** ********** **, ******* *** characters.
ExacqVision *********** & ****** *** ** ****
********** **** *****, ********** ***** ****** *** **** ** only ***** ** * *********, ***** are ********* ** ** ******* ** the ******'* ***** ****, *** *** be ******** ** **** ** ******* events. **** ***** ***** *** ************* of **** ***********, * ******* ****, and ****** ******:
*******, *** ** **********, ***** *** be * ***** ******* *** ******* passing ******* *** *** *** *** read ******* ***** **** ** *****. This ******* ** ****** ****** ***** linked ** ********* *****, **** ** this *******:
**** *** **** ****** ** **** speed *****, ***** *** ********** ***** quickly ******. ****** ** ** **** as ** ******* **** ******** ** this ********. ** ****** ******, ****** data *** **** **** *******, **** little ** ** *****.
***********
*** *******, ** **** *** **** Q1604 **** ******** ******* *.**.*. *** external ** *********** **** *** * NuOptic VIS1040-S850.
*********** ******* *.*.***** *** ****.
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, IP Fixed Box Cameras | Basler
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:
Everything You Wanted To Know About Rolling Shutter - DIY Photography
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.
If some one would like to test our software - which does not have these mentioned problems and price is 10 times lower, please contact!
#1, that is an impressive first comment. You picked a 4+ year old article, posted undisclosed and asked people to contact you.
Who are you? What is your product? How does it integrate with Axis / ACAP?
Hi, Our software works with any IP camera via RTSP. Actually we have implemented ANPR with Axis on the latest our site. System is connected with SMS billing system. How it looks you can see in picture.
That's fine. Is your company in our Directory of 50+ LPR / ANPR Providers? If not, email sean@ipvm.com and he will add you in.
That said, as for the topic of this article, you should not be recommending it here unless your software can run inside Axis cameras. Evidently, you cannot, yes?
