technical
frame grabbers
Jet Mk III supports several families of Frame Grabbers including:
- Most Video For Windows (single input and can be slow)
- CitySync - JG-201 Win XP / 2000 based cards - multi card possible
- CitySync - JG-401 Win XP / 2000 based cards - multi A/D converters for speed
- Common USB Grame Grabbers - low resolution and sometimes slow but useful for laptops
Capture boards vary in terms of number of camera inputs, resolution, frame rate, video switching times and price. The appropriate board is dependent upon budgets, pc platform and the application requirements.
Video for Windows compatible frame grabbers are easliy sourced but only single channel i.e. only useful for 1 lane of traffic per pc.and the capture rate is variable - but up to 25 frames per second depending on the PC and card.
The JG-201 however will grab at 50 fps and switch at approx. 17 fps (50/3) divided by the number of inputs. (See chart below). If also using colour surveillance cameras there is no additional overhead when switching between colour and monochrome. Note that two or more JG-201 cards may be addressed within one pc. This can improve results as switching between two cards is faster than switching between two video inputs on the same card. ... Thus calculating processing speeds on say a 4 lane system using either one or two JG201 cards requires some thought!
The JG-401 has four A/D converters and will grab at 50 fps per channel simultaneously. If also using colour surveillance cameras there is no additional overhead when switching between colour and monochrome. This is often faster than the PC can process - and so the card can be clocked down to 25 fps which is adequate for high speed traffic.
USB grabbers are useful when connecting to laptop computers but give variable fps from 16 to 24 fps at half video size ( 320 x 200). (We normally process images at 768 x 288 ). This can reduce accuracy and mean that a camera has to be zoomed in to the center of a traffic lane. Normally laptops are only used for temporary traffic surveillance and the odd "miss" may not be important. USB II does not help much as tearing of the image often occurs with moving traffic.
Be aware of these shortcomings when selecting an ANPR system.
When using any of these frame grabbers, the PC is used for image compression which adds sub 0.1 sec for every image stored on say a P4 2.8GHz and there is no overhead for colour / mono switching.
Charts are included below to help you - but don't worry, the CitySync technical team will not let you specify the wrong combination!
Question: Why does faster frame grabbing and processing speeds give better ANPR results?
How Jet works….
A car approaches and a plate recognised e.g. T4 TWO .. but with imperfect conditions the O is read as a D.
We would get an incorrect answer.. but Jet will, if it has time, capture the plate again and again as the car gets nearer - re-sampling the plate. Say it gets two T4 TWD readings followed by six T4 TWO readings. Jet considers these results and finally reports T4 TWO as the plate with the highest confidence factor.
In the light of this it becomes apparent that faster grabbing and processing speeds mean more attempts as a car approaches in a set period and therefore a higher accuracy in plate reporting. This can improve results by up to 10%!
Frame Rates, Image Processing Rates - and Bus Speeds
Unfortunately, there are one of two other technical factors consider when designing a complex ANPR system - but the good news is that CitySync will help you - unlike some other unscrupulous ANPR suppliers who choose the cheapest PC, the easiest Frame Grabber to program - and hope for the best! Most of these systems will work - but often not very well - and the odd frame lost means the odd plate mis-read or missed altogether - which could have been the important one.
There are four factors - or bottlenecks in the image capture and processing thread:
- The Image Capture Rate
- The speed of the Computer's Bus - down which the images must travel to be processed
- The amount of data in the image - a colour image has more data than a monochrome one
- The speed of the CPU to process the images - i.e. look for plates
The Image Capture has been mentioned above - and the tables that follow illustrate more complex compinations of monochrome, colour - and overview cameras.
The Bus speed is fairly easy to explain .... a typical PC will have a 32 bit bus - which can route data at a rate of approximately 96Mb per second. The newer 64 bit bus machines can theoretically handle twice this amount - but with all calculations we are assuming that the bus is not busy handling the graphics card (if say a PCI graphics card is used as opposed to an AGP card) - or some other internal shifting of data.
Jet ANPR Images are 768 x 288 = 221,184 pixels and so the amount of data in the image is normally one of three sizes:
- An 8 bit monochrome image = 221 Kbytes
- A 24 bit colour image = 221k x 3 = 663 Kbytes
- A 16 bit YUV colour image = 442 Kbytes
So - at 50 images per second, a monochrome ANPR camera would produce: 221 x 50 = 11050 k = 11MB.
4 cameras would be sending 44Mb down the 96Mb bus - but 4 colour cameras would be attempting to send 132Mb - and so there would be bus contention - which normally manifests itself as video tearing. However - current processors cannot handle 50 x 4 = 200 images per second - see below for estimates. Here we would have to turn "grab-sync" on - i.e. just process the odd - or even fields - therefore reducing the data down the bus to 4 x 25 images per second = 100.
If we are forced to use colour ANPR cameras - say in a town centre - and our PC bus is not coping (image tearing) then we can use a trick here ... the Jet s/w can be set to use YUV (16 bit) images - which are not as larger as 24 bit colour variants (see above). If we use this option then in Jet Live the user sees a monochrome ANPR image - but a 16 bit colour image is written to disk. This can then be viewed in colour later on by JetBase Review.
Image Processing rates are fairly linear - i.e. they are fairly easy to predict / calculate as processor speeds increase. The Jet Engine uses no floating-point arithmetic - and as PCs get faster - so does the JetEngine.
The rates shown are 'raw' processing rates. These are measured whilst monitoring traffic lanes. When a car comes into view and a plate is detected as being present, these raw rates drop by about a third depending on the complexity of the image. Note that these times are estimated and assume no other processor activity.
Processing Times Note: fps - fields per sec
PC (GHz) Typical Processing fps - i.e. recognition
P3 1GHz 70 fps est.
P4 2.8Ghz 100 fps est.
So, on a single camera system using a fast PC we can process faster than we can grab....so no problem.
On say a 4 lane system with mono cameras we can grab faster than we can process ... so we clock down to 25 fps x 4
As processors get faster and using multiple grabbers the bus becomes the bottleneck and so it goes on!
Frame Grab Times
Video for Windows
Inputs |
Images per second |
|---|---|
1 |
8 - but no time for anything else on pc |
Notes: |
Runs under Windows 9x. |
JG-201
Inputs |
Images per second |
|---|---|
1 |
50 |
2 |
17/2 = 8.5 per camera |
3 |
17/3 = 5.7 per camera |
4 |
17/4 = 4.25 per camera |
Notes: |
Runs under Windows XP / 2000
|
JG-401
Inputs |
Images per second |
|---|---|
1 |
50 per camera |
2 |
50 per camera |
3 |
50 per camera |
4 |
50 per camera |
Notes: |
Runs under Windows XP / 2000
|
Traffic Speeds
The limiting factor with modern fast machines is normally the frame grabber as illustrated above.
For fast moving traffic (100mph motorway) a single snapshot will often do - but 3 or more grabs are preferable so a better decision can be made on the plate.
For barrier work a car will be stationary for several seconds and 3 or more grabs are easily possible with a system using several cameras on one input card.
Examples
All assume a P4 - 2.8GHz computer processing say 100 images per sec.
Colour cameras are colour surveillance / overview cameras
1 |
1 x ANPR Camera
|
Grab 50 fps
|
2 |
1 x ANPR Camera
|
Grab 17 fps total (switching) / 2 = 8.5 fps max per camera.
|
3 |
1 x ANPR Camera
|
Grab 50 fps on each card
|
4 |
2 ANPR Cameras
|
Grab 17 fps total (switching) / 2 = 8.5 fps max per camera.
|
Examples continued ...
5 |
2 x ANPR Cameras
|
Grab 50 fps each card.
|
6 |
4 x ANPR Cameras
|
Grab 17 fps total (switching) / 4 = 4.5fps
|
7 |
4 x ANPR Cameras
|
Grab 50 fps each channel
|
8 |
2 x ANPR Cameras
|
Grab 50 fps each channel clocked down to 25fps
|
Now the JG-401 can be connected to up to 3 daughter boards per card. Each board take one of the 4 A/D converter inputs and divides it between up to 4 additional inputs - in effect making it the same as a JG-201 with 4 inputs. The video switch times are the same as for a 201 also.
So in total - with 3 daughter boards - a JG-401 can take up to 16 inputs - but the frame rate would ve 4.25 fps per channel.
Example - a 401 has one daughter board fitted - allowing up to 8 inputs. (3 original inputs at 50fps - and the 4th channel divided into 4 slow-switch inputs at 4.25 fps). But if only 2 cameras were connected to the daughter board, then the frame rate would be 3 x 25 (clocked down) plus 2 x 8.5 which totals 92 fps which the processor can handle.
By clever use of daughter boards - i.e. a/d sharing - this give slower frame rates on certain cameras - which can be used for slow lanes (barriers) - or colour overview cameras where the frame rate is not so critical.
Examples continued ...
9 |
4 ANPR Cameras
|
Grab 100 fps total (switching) per grabber card / 2 = 10fps
|
10 |
4 ANPR Cameras
|
Grab 100 fps total (switching) per grabber card / 2 = 10fps
|
11 |
4 ANPR Cameras
|
Grab 100 fps total (switching) per grabber card / 2 = 10fps
|
