by IQinVision
Can mega-pixel network cameras really save bandwidth and store?
In the first part of this series, we said we would discuss compression, so let's start there. Although there are many different types of compression (some of the best known are H.264, MPEG4 and MJPEG), there are basically two types: frame by frame and time.
A short comment on compression
MJPEG is the most popular frame-by-frame compression technique, as it compresses each image in its entirety; it is widely used and allows for easy integration. The advantage of this technique is that with it you can recreate images accurately and the use of bandwidth is predictable. The problem is that having to handle each image in its entirety, it is not very efficient in terms of bandwidth when there is little movement or activity.
The temporal is represented by popular compression methodologies such as H.263, H.264 and MPEG4. These techniques are widely used in applications where the available network bandwidth is limited and the images are of low quality. The temporal type takes an image, called a "key frame," it compresses it in its entirety, and then, for the following images, it only compresses and transmits things that change in the image. Every few images, it takes another key margo and repeats the process. The advantage of this technique is that by sending only changes to the key frame, a lot of bandwidth and storage can be saved when there is little movement or activity. One of the drawbacks of this technique is that only the key frame is a true "legal" image. Another difficulty is that the movement produces a significant increase in bandwidth consumption, thus reducing the bandwidth advantage over frame-by-frame compression.
Use mega-pixels or not use mega-pixels
But actually, compression is not significant for our next analysis, as the following examples will be valid as long as apples and oranges are not being mixed. This article is about comparing mega-pixel cameras with low-resolution cameras, in order to see if and when, the use of the mega-pixel makes sense. In this sense, we are simply comparing different types of apples. Therefore, for our analysis, we will assume that the client wants the images of the highest quality and therefore, it will use a frame-by-frame compression such as the MJPEG. When does the use of the mega-pixel make sense? In the first part, we talk about pixels per foot, which helps to make the decision whether or not to use the mega-pixel.
Let's use the same example, but now we'll also add depth of coverage: we want to cover a parking lot with forensic detail (40 pixels/foot) and the parking lot is 100 feet wide, but now we'll add the fact that we need to cover multiple rows of carts at a depth of 60 feet. To recognize faces and plates, you would need 40 pixels per foot x 100 feet or 4,000 pixels through by 40 pixels/foot x 60 feet or 2,400 pixels deep. We arrived at a total number of pixels required, multiplying the pixels wide by the pixels deep for 9,600,000 or 9.6 mega-pixels.
Mega-pixel vs. conventional coverage
From our previous discussion, we know that there are a number of camera options to achieve forensic detail in this scene, as shown in the following examples. Let's now determine the bandwidth required for each option. This is achieved by simply calculating the size of each image and keeping the compression the same for all cameras. Once we have the size of the image, it must be multiplied by the images/second to obtain the bandwidth requirements. We will use a compression pattern found on a website of the Milestone provider: http://www.milestonesys.com/?cid=419. According to Milestone, a 640 x 480 image with medium-low compression has a file size of about 50kB. For higher resolution images, we can use IQinVision's comparison matrix for mega-pixel cameras.
(http://www.iqeye.com/iqeye/images/uploads/File/Sales_Datasheets/Product_Specs.pdf ), which shows a typical 3.1 Mpix image that will have a file size of 225kB.
The following examples show what it would take to cover the parking lot with the desired resolution:
Option #1: 35 cameras at 640 x 480 (4 CIF) = 35 x 50kB = 1.75MB
Option #2: 4 cameras at 2048 x 1536 (3 Mpix) = 4 x 225kB = 900kB
So the apple-to-apple comparison reveals that mega-pixel cameras can offer the same image quality for about half the bandwidth. However, let's face it: most people won't use cameras to cover the total area. To save money, they will probably only use cameras at "critical points", so the comparison of 35 cameras and four cameras is really not practical. Let's take a quick look at an example of a critical point and see how mega-pixel cameras are stacked. First, let's define the critical point area; it's the area where something you want to record is likely to happen.
So, let's talk about numbers again.
Option #1: 6 cameras at 640 x 480 (4 CIF) = 6 x 50kB = 300kB
Option #2: One camera at 2048 x 1536 (3 Mpix) = 1 x 225kB = 225kB
This example demonstrates that critical point coverage with a mega-pixel camera would use 33% less bandwidth than when using 4 CIF, 640 x 480 cameras.
And this improves
Finally, some of the most sophisticated mega-pixel cameras incorporate smart features such as digital image collection, which allows the user to optimize a camera for a certain application. Essentially, they can collect image areas that are not needed and save the corresponding bandwidth. In the example above, the critical point is 1920 x 960, so the 3.1 Mpix camera could be collected by 1920 x 960 and would still cover the area. This would produce a file size of 135kB, which is now 42% smaller than it would take to cover the same area with 640 cameras. x 480.
In the first and second parts of this series, we've seen mega-pixel cameras offer irresistible overall value in terms of system cost, cost per pixel, and overall installation costs, when compared to pan/tilt/mechanical zoom cameras. Let's tune in to the third part. which is the final installment in our series of spreading myths around mega-pixel technology.
