Thursday, December 18, 2008

City center monitoring - Runnymede

This brief article about city center monitoring interests me because it is a 'simple' yet pragmatic setup. Both IP cameras and analog cameras (going into VIP X1600 multi-channel encoders), recording Direct-to-iSCSI managed by the Bosch Video Recording Manager.

And as Chris Lazzari rightly points out, "...enables [Runnymede Borough Council] to expand their network and storage requirements easily". That last point is particularly important to me. Estimating how much storage you're going to need is as much a guessing game as predicting how many miles till your tank is empty. It is very nice to have an easy way to transparently add storage, or add cameras, or improve recording quality, certainly without stopping, resizing/reformatting stuff.

Click here for the original article.

Tuesday, December 16, 2008

Bunny tale - BVIP allegory

I had so much fun writing this. If you ever wanted someone to explain the whole of Bosch Video over IP to you just as though you're a 7 year-old being read to at bed-time, then please feel free to check it out. Funnily enough it covers just about everything, but without the usual dryness of coventional formal corporate literature. If it's not too late to have a little laugh while learning, hope you enjoy it as much as I did, and leave me a comment if it made you smile.
A Story.

Monday, December 15, 2008

DCRI - surveillance levels

In his work for the US Army Night Vision lab, John Johnson developed a standard which, when you look at it, seems so downright obvious it's amazing it took someone this long to come up with it, as is the case with many great but simple concepts.

John Johnson realized that this simple comment 'We want a video surveillance system so we can see what's going on' is as loaded as it gets. The problem lies in 'what you want to see' and 'what you want to take away from it'.

He broke down 'seeing' into 4 steps, abbreviated to DCRI. D for detection, C for classification, R for recognition and I for identification. Let's take a deeper look at those.

I have a nice thermal camera (yes, I saved up for it) pointing at a distant treeline. I see a glowing blob moving through the trees. After watching it for a second or two I convince myself I have DETECTED something moving. Don't know what yet.

The guards are alerted.

It moves closer and appears a little bigger. I can see it is walking upright - it is certainly taller than it is wide. I convince myself it is human. I CLASSIFY it as a human. Good or bad, man or woman, I have no clue. but a person it is.

The guards are dispatched, along with some big slobbering doggies.

As it comes closer, and I now switch from my thermal camera to something that can reveal finer detail, I realize it is not moving at a steady walking pace - instead it is making erratic moves, almost trying to avoid detection and occasionally crouching. With IR illumination, and especially if it is in the spectrum where there is no visible light whatsoever so the person does not know he is under surveillance, I catch a glimpse of the clothing. The clothes, rifle and overall demeanor are a total give away. I know it's not a good person. I RECOGNIZE it as an intruder.

The guards proceed to engage.

As I zoom in I catch the face and other tell-tale marks of who it is. I have IDENTIFIED it not only as a man, but if I can't put a name to him yet, with the printed image from my video management system, I soon will.

How does Bosch take this principle into our development of products? Unlike many active IR and thermal solutions out there that claim only distance when it comes to their night vision products, Bosch infrared imagers provide performance parameters based on the DCRI principles…so what? It means you can effectively specify cameras based on what YOU are trying to achieve. Hopefully this posting will help you think about what the system really needs to do, which should in turn drive the right selection of parts.

DCRI - equally valid during the day or night. Simple, but effective. Wish I'd thought of it.

Friday, December 12, 2008

In the dark

In the dark, a couple of wierd things happen besides not being able to see very much.

With conventional analog video or digital/IP video, the image certainly looks worse as contrast fades and AGC (Automatic Gain Control) kicks in, amplifying the weak signal but simultaneously, the noise and hurting the signal to noise ratio. I refer to this ants crawling all over the screen, but please stop me if I get too technical. Snow storms, or as one colleague puts it, the equivalent of the 'shhhhhh' sound in the audio world. The other thing is the shutter speed slows to let in more light, which naturally leads to blurring (especially noticeable with Megapixel cameras, but by no means exclusive to them). This is not noticeable in a static picture, but when you most need it, when a person or car goes by, you have to ask yourself was it a bird, a plane or some other extra-terrestrial object? The point is that for security and surveillance video it might still be 'good enough'. You might say 'I can see what I need to see', and quite rightly, no-one should argue as long as you're happy.

But a second thing happens in the IP video world, the noise in the image makes the compression engine go wild, because (i) it thinks almost the entire image is moving (like a PTZ) and (ii) there is no stable part of the image which it can simplify through redundancy (like a person walking down a corridor). This makes the compression engine beg for more bandwidth in order to adequately represent the image and this puts a strain on the network and consumes more disk space (which is often half the cost of a CCTV system). If you do not feed the engine's appetite with more bandwidth, it will do the only thing it is allowed to do - oversimplify the video, either by making it horribly blocky or just unashamedly drop frames leading to jerky video. This is particularly evident in WANs and wireless networks, but I've even seen it on a LAN with one switch.

The third impact of low light is that machine vision, that gave us modern day video analytics, simply collapses in a blubbering heap. Near-zero contrast and noisy motion all over the image overload the analytics so that it can neither detect key objects nor track them. Video analytics just doesn't work in the dark.

In our experiments with active IR illumination, the improvement in the quality of the image is jaw-dropping. You have to see it to believe it. PowerPoints, video clips and brochures just don't cut it. It's like looking at a monochrome image in broad daylight, because, well, that's basically what the illuminator is giving you. We've watched bitrates slashed by 30-80% down from their peak values in the dark, just because the video is clean. Finally, and I don't quite know how to quantify this better, video analytics doesn't work in the dark, but it does in the light.

Of course you don't have to use active IR illuminators, you can use white light, which also acts as a deterrent. However IR consumes very little power and generates little to no pollution. Another option is thermal imaging, or passive IR. This comes at a very different price point but is excellent for long-range detection that 'something is out there'. You don't know what yet, but it warns you to take a closer look, possibly with a camera and lighting that reveals more detail.

So lights aren't just for better video, although that's a good enough reason when you do a side by side comparison. It affects network bandwidth, disk space consumption and whether or not your analytics dollars are going to deliver on their promise or find nothing, or maybe worse, swamp you in thousands of false alarms. Nasty, nasty ants.

Click here for a video clip

Sunday, December 7, 2008

Many Little Places...Far, far Away

Sometimes we all get a bit over-excited about our full-blown, nuclear-powered IP video solutions - the power, flexibility and sheer potential of this sledge-hammer. It is easy to overlook some ridiculously trivial ways to solve certain problems. For this reason, I wrote this little document that describes a few ways of solving the serious challenge of monitoring a large number of remote locations.

The scenario pulls together a number of classic challenges, not all of which will apply in every case, but some might. The locations might be far apart, possibly linked by a low bandwidth WAN. For economy or practicality of installation, the WAN might be wireless (RF, laser, microwave etc.), with intermittent up-time. The place might be in the middle of no-where, and might rely on solar power with somewhat fluctuating power. The environment maybe a little uncomfortable - not exactly your average IT rack where you otherwise may have installed a PC. It may be cold, dusty, even quite dirty. Humid or shaky. There my be limited space for equipment. There may be pressure to reduce the amount of light pollution in the area.

Out of 365 days you may only want see one of the cameras once to verify an alarm, otherwise you really don't care as long as it's reliably recorded, and you can export the video for use as evidence, obviously without having to physically go there. You may only need 1 to a small handful of cameras. Traveling to these sites might be a very expensive exercise, and so once installed you really never want to go there again. You may have a small fence with traditional intrusion detection, linked to a central monitoring station. You may be considering using video analytics to add an extra layer of detection, since you already have the cameras installed, and you figure they may as well serve a dual purpose so you get your money's worth.

Click here for Many Little Places...Far, Far Away. Enjoy.