Paul Bodell works in the megapixel surveillance camera industry with IQinVision.
Image 1: In this theoretical example, it would take 35 cameras at 640 x 480 resolution (4 CIF) to cover the parking lot at a forensic level. If we attribute 50kB of bandwidth to each of the 35 cameras, the total bandwidth need would be 1.75MB.
Image 2: In the same theoretical parking lot, four megapixel surveillance cameras operating at 2048 x 1536 (3 Mpix) can give the same level of detail that 35 4CIF cameras would provide, but less bandwidth would be used. Four cameras at 225kB each would eq
Image 3: "Choke points", or areas of special interest, are often defined by security system designers. It's these areas which often call for forensic surveillance where a great deal of detail must be captured.
Image 4: Our first option for obtaining forensic video surveillance detail in this choke point is to use 6 cameras operating at 640 x 480 resolution (4 CIF). The result would be a bandwidth need of roughly 300kB.
Image 5: The second option for fully covering the choke point is to use a single high-resolution camera at 2048 x 1536 (3 Mpix). The bandwidth in this design would be 225kB.
[Editor's Note: This is the second in a series of three articles addressing the growing technology of megapixel video surveillance cameras. Upcoming installments (to be published on SecurityInfoWatch.com during March 2007) will cover topics of the relationship between megapixel cameras and storage/bandwidth needs and digital zoom versus mechanical pan/tilt/zoom.]
In Part 1 of this series, we said we would discuss compression, so let's start there. While there are many different types of compression-some of the more familiar being H.264, MPEG4 and MJPEG-there are basically two types: frame-by-frame and Temporal.
A Short Note on Compression
MJPEG is the most popular frame-by-frame compression technique, compressing each image in its entirety. It is widely deployed and easy to integrate with. The advantage of this technique is that it enables you to recreate images accurately and bandwidth use is predictable. The drawback is that by handling each image in its entirety, it is not very efficient in terms of bandwidth when there is little motion or activity.
Temporal is represented by popular compression methodologies like H.263, H.264 and MPEG4. These techniques are widely deployed in applications where the available network bandwidth is limited and low quality images will suffice. Temporal takes an image, called a "key frame," compresses it in its entirety, then for the next few images, only compresses and transmits things that change in the image. Every few images, it takes another key frame and repeats the process. The advantage of this technique is that by sending only changes to the key frame, you can save a lot of bandwidth and storage when there is very little motion or activity. One drawback of this technique is that only the key frame is a true "legal" picture. Another drawback is that motion results in a significant increase in bandwidth consumption, thereby reducing the bandwidth advantage over frame-by-frame compression.
To Megapixel or Not to Megapixel
But in reality, compression isn't significant for our following analysis, because the examples below will hold true as long as you aren't mixing apples and oranges. This article is about comparing Megapixel cameras with low-resolution cameras to see if and when deploying Megapixel makes sense. In that sense, we are simply comparing different size apples. So, for our analysis we will assume the customer wants the highest quality images available and will, therefore, use a frame-by-frame compression like MJPEG.
When does megapixel make sense? In Part 1, we talked about pixels-per-foot, which helps make the megapixel decision fairly straightforward. Let's use the same example, but we'll now add depth of coverage as well: we want to cover a parking lot with forensic detail (40 pixels/foot - see part 1 for an explanation of the different video quality levels, but this is the resolution at which you can recognize faces and license plates) and the lot is 100 feet wide, but now let's add that we need to cover multiple rows of cars at a depth of 60 feet. To do the math, we multiply the 100 foot width by the 40 pixels/foot to come up with 4,000 pixels. Then we multiply the 60 foot depth of field by 40 pixels/foot to come up with 2,400 pixels. We then multiply those two values (2,400 and 4,000) to produce the total number of pixels needed. In this case, that number is 9.6 million pixels, or 9.6 megapixels.
Megapixel Coverage vs. Conventional
We know from our previous discussion that there are a number of camera options to achieve forensic detail on this scene as shown in the examples at right. Let's now determine the bandwidth required for each option.
Determining bandwidth is accomplished by simply calculating the size of each image and keeping the compression for all cameras the same. Once you have the image size, you multiply that by the images per second to get your bandwidth requirements. To be fair, let's use the compression guidelines given by a popular NVR supplier, Milestone. They publish compression guidelines on their website at www.milestonesys.com/?cid=419. Milestone's specs indicates that a 640 x 480 image with medium-low compression has a file size of approximately 50kB. For higher resolution images we can use IQinVision's comparison matrix for megapixel cameras (in PDF format), which shows a typical 3.1 Mpix image will have a 225kB file size.
The following examples show what it would take to cover the parking lot with the desired resolution. Option #1 (show in photo column above as Image 1) would require 35 cameras operating 640 x 480 resolution (a.k.a. 4 CIF). If each of those 35 cameras was using 50kB of bandwidth, the total bandwidth needed for this option would be 1.75MB.
The second option is to pursue a megapixel application (Image 2 in the photo column). Four cameras operating at 2048 x 1536 (3 Mpix) would cover the scene. If each of those cameras is using 225kB of bandwidth, the total is 900kB.
So, an apples-to-apples comparison reveals that megapixel cameras can deliver the same image quality for about half the bandwidth. But let's face it; most people won't employ cameras to cover the entire area. To save money, they are more likely to only use cameras at critical "choke points," so the 35-camera-to-4- camera comparison isn't really practical. Let's take a quick look at a choke point example and see how Megapixel cameras stack up. First, let's define the choke point area; this is the area in which something you want to record is likely to happen (see Image 3).
Then, we run the numbers again. Option #1 (Image 4) is to use six cameras running 640 x 480 resolutin (4 CIF). At 50kB each, the bandwidth requirement would total to 300kB. The second option (Image 5) is to use a single megapixel camera at 2048 x 1536 (3 Mpix). The bandwidth requirement in that design would be 225kB.
This example demonstrates that covering our choke point with a megapixel camera would use 33 percent less bandwidth than using 4CIF, 640 x 480 cameras.
As a side note, some of today's megapixel cameras incorporate smart features such as digital image cropping that allow the user to optimize a camera for a given application. Essentially they can crop out areas of the image that are not needed and save the corresponding bandwidth. In the above example, the choke point is 1920 x 960, so a 3.1 Mpix camera with digital image cropping could be cropped to 1920 x 960 and still cover the area. This should yield a file size 135kB, which would be about 56 percent less bandwidth than what what would be used if we were to cover the same area using 640 x 480 cameras.
In the final installment of this series on the realities of megapixel surveillance, we turn to a comparison of digital pan, tilt and zoom versus mechanical pan/tilt/zoom cameras. Look for that update on March 20th, on SecurityInfoWatch.com.
About the author: Paul Bodell is vice president of sales and marketing at IQinVision, a U.S.-based vendor of high resolution/megapixel surveillance cameras. Bodell has been with the company since 2002, and has worked in the electronic security industry since 1994.