Disqus - Latest Comments for sggoodri

Re: New Product: OCULUS Surveillance Robot

sggoodri — Wed, 25 Apr 2012 15:11:05 -0000

This type of robot is most useful for investigating an area for anomalies such as water leaks, signs of a break-in, facilities left in proper order, etc. and not as a deterrent. Security robots have been around for a long time; the addition of heat, smoke, CO and other chemical sensors makes them even more useful.

Re: FBI CCTV Best Practices

sggoodri — Mon, 26 Mar 2012 17:50:58 -0000

The vast majority of security video evidence that the FBI (as well as state/local LE) receives is from analog DVRs, due to the installed base in small businesses like convenience stores and banks, so it's not surprising that this 2010 video is light on discussion of megapixel. It's a game changer but law enforcement just isn't seeing it in cases yet.

I think the best way to address the low light and limited depth of field problems is for installers to make optical adjustments at night in addition to daytime. At night the aperture widens and reduces depth of field, which can cause subjects at an important distance to go out of focus if the focus isn't adjusted optimally. My company assisted LE in processing video from a murder investgation where the getaway car was badly out of focus in low light and unidentifiable. As the sun set, the iris opened up and introduced the blur. We went to the scene and collected video from the camera feed of a tiny point light source placed at the car location as the sun set, then used this video to create a mathematical model of the blur point spread function and performed a pseudoinverse to deblur the car. We were very lucky that it worked and we could ID the car, but I would be much happier if we were solving technology-limited problems rather than installation problems.

Re: H.264 Codec Shootout

sggoodri — Fri, 02 Mar 2012 16:32:22 -0000

The details of encoder implementation among cameras and chipsets will vary more in terms of their impact on video quality/bitrate than just the differences between profiles. For example, how good is the motion estimation? How far does it search spatially/temporally for the best match? What are the buffering parameters? As for video hiccups, that's an implementation error. At worst, a video should appear coarse/blocky when unexpected or unusual complexity occurs and exceeds the available bandwidth or buffering budget.

Re: Sharing Surveillance Video with the Police

sggoodri — Fri, 02 Mar 2012 15:44:06 -0000

Police will usually be happy to obtain assistance with retrieval of evidence from security video systems, but they may insist on being present when the video is exported, so that they can preserve chain of custody of the evidence. An exported .AVI is too easy to alter. Also, best practices in forensic video collection recommend that they always collect the native video format as well as the portable format if the system offers both. Self-executing players and propietary containers with proprietary players preserve metadata, full megapixel image resolution, and multi-camera synchronization that is often lost with export to portable standard file formats. The nice thing about IP video, compared to DVRs, in the higher likelihood of standard codecs, and thus the ability to export to standard file containers without introducing recompression artifacts - if the right export container is available for the native codec.

The "Best Practices for the Retrieval of Video Evidence from Digital CCTV Systems" handbook focuses on DVRs and is a bit dated, but I believe it still reflects the current preferred practice by forensic video investigators in law enforcement:
http://www.tswg.gov/subgrou...

-Steve G

Re: Testing: Gain / AGC Impact on Surveillance Video

sggoodri — Wed, 13 Jul 2011 16:23:57 -0000

Although gain amplifies noise, it also amplifies scene details that can be crucial in an investigation. It's often possible to recover useful information from noisy digital surveillance video using forensic video processing methods such as frame averaging, but if the details coming off the imager are too dark due to inadequate gain, the digitizing and compression steps can obliterate them completely.

Noise is hard to compress because it (1) looks to the compression algorithm like lots of image detail, and (2) changes randomly from frame to frame, defeating predictive encoding. The advice to limit the VBR or CBR bitrate is to conserve bandwidth is good; other options for dark nighttime video include reducing the recorded image resolution at night (since the noise obscures the finest details anyway, and antialiased downsampling will reduce noise along with pixel count) or to reduce the frame rate at night, at least when no activity is detected.

Re: Top 10 Surveillance Myths Debunked

sggoodri — Wed, 13 Jul 2011 14:10:26 -0000

Resolution Comparison Diagram: When megapixel resolutions are obtained by making the pixels smaller on a given chip size, each pixel performs worse - it collects less light, has a lower SNR, and the chip may suffer other quality compromises due to the smaller scale of the components. If, on the other hand, megapixel resolution is obtained by increasing the dimensions of the imager while using the same pixel technology, the resolution comparison diagram showing increased field of view at the same angular resolution is realistic - up to the limitations of the lens format.

And yet another reason why megapixel cameras provide underwhelming results compared to mature SD cameras is that the mature SD cameras have been highly optimized in terms of chip design and on-board image processing to create an image that really "pops" with good sharpness and contrast under challenging lighting conditions. I've measured the modulation transfer function of megapixel security cameras and compared them to high-end SD cameras and found that while the megapixel can indeed resolve more line pairs than the SD cameras, the MTF of the megapixel starts declining long before its pixel count limits it, while the SD camera shows a much stronger response right up to the sudden drop due to its limited pixel count. Some even show a spike in the MTF due to the on-board DSP sharpening operations. Such sharpening amplifies noise along with true edge contrast, so it makes for an unfair forensic comparison, but it does make the image look more impressive.

Re: Testing: WDR Comparative

sggoodri — Fri, 08 Jul 2011 16:50:58 -0000

Although this thread is old (I'm just getting to reading it), I thought I'd comment on the appearance of the outdoor background in the hallway images from the Sony. Accurately measuring a wide dynamic range scene without saturating/clipping is only half of the challenge for a WDR camera; the other half is converting that data to an 8-bit per channel, 48dB representation visible on a normal PC monitor. This is done by compressing the dynamic range of the scene. However, from a forensic standpoint we care more about edge details than absolute brightness, so in order to avoid compressing edge contrast, a camera manufacturer may apply a sharpening or local contrast enhancement operation that suppresses the absolute birghtness and highlights brightness transitions.

The Sony image looks very similar to an image processing technique called homomorphic filtering. First, the dynamic range of the image is compressed by computing the natural log of the pixel brightness. Then, a spatial highpass filter operation is applied to preserve edges but attenuate relative "DC" brightness levels. Then the exponential is applied. Note that this operaion separates illumination differences from surface reflectance differences. The reflected light in the measured image is the product of the slowly spatially varying illumination value multiplied by the fast spatially varying surface reflectance. The natural log turns this multiplicative relationship into an additive one, and the highpass boosts the reflectance changes while rejecting the illumination changes. An artifact of this operation is that the edge sharpening makes some things look embossed, and the level shift can make colors look unnatural.

Re: Why Do Republicans Hate Bicycles So Much?

sggoodri — Tue, 30 Mar 2010 13:32:25 -0000

As a cyclist and conservationist, I disagree that Republicans hate bikes.

A good Republican would promote limiting federal transportation spending to facilitation of inter-state travel, and leave intra-state travel to the states and municipalities. Nearly all bicycle transportation is intra-state, so a good Republican would be skeptical of federal pork for bicycle projects. However, since some federal projects have impacts on bicycle and pedestrian travel, some Republicans who are sensitive to cycling would agree that certain federal projects should include features to mitigate those impacts (e.g. a bike/ped bridge over a new interstate freeway in order to preserve local travel.)

When bicycle advocates frame cycling as anti-car, and demand that federal money be shifted away from long distance transportation toward local transportation, plenty of Republicans will cry foul. Plenty of Democrats may be upset as well, but they stay quiet in order to not create problems within their own party.

I see the strongest Republican support for bicycling at the local level. And there are just as many conservatives as liberals among those I know who ride bikes regularly.

Re: Testing Ikena's Video Enhancement Software

sggoodri — Fri, 19 Mar 2010 10:37:10 -0000

Digital surveillance systems pose new challenges for law enforcement when collecting and analyzing evidence. The biggest problem is proprietary video file formats. Most surveillance systems that police collect evidence from today are DVRs. Even if they use standard codecs, most of these systems use proprietary file containers when exporting video at its original quality for archival processes, playable only with the manufacturer's proprietary player. (One motivation for the proprietary container is to store metadata.) Proprietary players often have compatibility issues on different operating systems, and may install codecs or other software on the computer that interfere with other applications and cannot be removed easily. If the DVR provides the option to export to an interoperable file format, it often recompresses the video do a different codec, reducing quality.

The dependency on buggy proprietary players for maximizing image quality forces professional video analysts to set up a dedicated computer or virtual machine just for playing the video evidence and performing a screen recording to uncompressed video for the entire content duration. The video must stay uncompressed for any remaining processing and viewing for fear of degrading its quality and adding new artifacts.

A much better forensics process would be possible if security appliances exported the original quality video streams into standard compliant file containers. IP video cameras and VMS software are much more likely to use standard-compliant codecs than are older DVRs, but often still use proprietary containers. most likely out of convenience to the software developers. There's really no reason not to wrap an MPEG stream in a standard MP4 container; MJPEG will work fine in an .AVI container. This would allow evidence to be digitally signed in its original form as it came off the DVR and imported directly into the forensic video system. This would eliminate the problems with proprietary players and the cumbersome intermediate step of large uncompressed clips, which could also be tampered with more easily without detection if someone was determined to do it.

Re: Testing Ikena's Video Enhancement Software

sggoodri — Thu, 18 Mar 2010 15:13:05 -0000

I work for Signalscape, which manufactures the StarWitness line of video collection and clarification products for law enforcement.

Defense challenges are a key consideration for us when we develop our forensics products. Most of our customers and competitors share this concern. As a result, the forensic video community strives to develop and follow best practices for collection, handling and clarification. This includes making the clarification process unbiased, transparent, and reproducible. One strategy is for the software to maintain an audit trail of everything the examiner does to the video, down to the very last adjustment of brightness and contrast. Automatic digital signing of data before and after approved processing may also be used to deter tampering. The forensic video clarification software may also be deliberately handicapped (compared to other types of video editing packages) insofar that it cannot be used to deliberately change/delete/paste/draw content in the scene. It's also important to be conservative in choice of algorithms. Recursive, "smart" filtering algorithms that adjust the filtering as they interpret the content would be hard to defend in court compared to basics like frame averaging and gain.

Signalscape's StarWitness software combines the above precautions with the ability to automatically reproduce the enhancement process from the original content at will. The enhancement is applied to the original in real-time using parameters that get stored with the case file.

Like any forensics tool, video clarification needs to be used responsibly. Most police will use video to obtain leads that result in more solid evidence for the courtroom. And when suspects who are actually guilty see themselves in collected video evidence, they are much more likely to plea bargain than to challenge the video evidence.+

Re: HDcctv Alliance Competitive Analysis

sggoodri — Mon, 22 Jun 2009 10:00:04 -0000

This may be a naive question, but how often will resolution motivate upgrades of existing CCTV/coax installations?

It seems to me that a competent analog CCTV installer will choose the correct optics and camera placements to obtain adequate detail at important points of interest. If that means installing more SD cameras than would be required with HD, so what? The biggest cost was paid during the orginal installation, with fairly low costs for maintentance, so there isn't much motivation to upgrade. Only for new installations is using HD cameras a big cost saver for getting the same number of pixels on the ground.

I can imagine a migration to HDcctv driven by customer dissatisfaction with their existing analog system, but how widespread is this? Does this happen much after an incident occurs and where video analysis fails to provide adequate identification due to poor video quality?

Personally, I like the idea of HDcctv for static-mount outdoor cameras and other potentially accessible wide-angle viewing locations where IP networks could be vulnerable to exploitation for attack, requiring additional hardware and software to isolate them from the rest of the network.

Re: IPTV vs IP Video Surveillance

sggoodri — Tue, 16 Jun 2009 14:16:24 -0000

Some more differences-

IP Video Surveillance vs IP Video Entertainment:

Low latency for PTZ control versus long acceptable latency

Real-time compression on low-power hardware versus optimized compression performed offline by powerful servers

Willingness to sacrifice frame rate for resolution versus willingness to sacrifice resolution for frame rate

One user viewing multiple concurrent video streams versus viewing one video at a time

Little or no audio versus closely synchronized, multi-channel audio

Rich indexed event metadata versus minimal metadata

Multi-vendor streaming interoperability versus proprietary set-tops and viewers

Authentication and sharing of evidence versus copy prevention and piracy detection

Re: Testing Vivotek IP7161 - 2MP MPEG-4 Camera

sggoodri — Fri, 05 Jun 2009 14:44:27 -0000

The few 1.5 MP cameras that I've used that streamed MPEG-4 Part 2 would only do full resolution over M-JPEG; the MPEG-4 codecs in them were limited to standard definition. Some low-quality megapixel H.264 cameras have similar limitations that are not readily apparent in the spec sheets. I think the reason is mostly that standard definition codec implementations are cheaper while megapixel-capable implementations are newer.

H.264's increased efficiency and in-loop deblocking filter provide better high resolution picture quality at modest bitrates, so I suspect most VMS vendors will work hard to support it ASAP.

Re: Testing Vivotek IP7161 - 2MP MPEG-4 Camera

sggoodri — Fri, 05 Jun 2009 12:03:10 -0000

This is the first camera I've seen that uses MPEG-4 Part 2 for greater than standard resolution (e.g. 720x480).

Most MPEG-4 Part 2 decoders I've seen only handle lower profiles and levels capable of standard definition. Might this limit which third-party video management software can handle decoding this camera at high resolutions?

I suspect that third-party VMS support for high definition H.264 would be better than for high definition MPEG-4 Part 2. Does anyone know otherwise?

Re: Guidelines for Testing IP Cameras

sggoodri — Tue, 26 May 2009 15:14:19 -0000

In my experience, VMS software from the camera manufacturer doesn't transcode (by default, anyway) when creating playable exports, but may require a proprietary player for handling a proprietary container. You may want to find out what the distribution license constraints on the player are, but having access to that might be best. Recipients, however, should note that proprietary players often have nasty effects on one's Windows setup, including installation of codecs that can interfere with other video software, or worse. I recommend running such players on a separate machine that can be restored to a clean slate after each use, or inside a virtual machine.

It's also possible to strip standard elementary streams out of proprietary containers - most cameras claiming to comply with standards actually do use standard codecs even if the container is proprietary - but this would likely be too much effort for non-forensics work.

For forensics purposes, it is actually more common to screen record the proprietary video played at native resolution and store it uncompressed on a fast drive such as a striped array. But that would be overkill for your reviews, except for an occassional single-image resolution comparison shot. Transcoding to a good codec (H.264 or WM9/VC1) at a high quality level (and typically higher bitrate than the original) should be good enough for distributing videos to your audience of interest.

Re: Guidelines for Testing IP Cameras

sggoodri — Tue, 26 May 2009 11:05:05 -0000

When providing AVIs, will you be able to avoid transcoding, so there is no quality loss? It seems to me that some codecs don't work inside an AVI container, and sometimes would work better in other file containers like an appropriate .MP4 variant, or as elementary streams. I've been using Quicktime to play MPEG-4 Part 2 and H.264 content in .MP4 format, and VLC media player or my own hacked-together decoder software for playing some elementary streams.

What software will you use to record the clips? Much of the software provided by camera manufacturers either records to a proprietary file container or may not record at all. Third party VMS software may or may not be able to generate a portable video file format without transcoding - particularly if the camera uses a less common codec like motion-JPEG2000.

Re: Do Megapixel Cameras Provide Better Image Quality?

sggoodri — Tue, 26 May 2009 09:38:34 -0000

For several years now I've been using an IEEE resolution chart (purchased from Edmund Optics) to provide basic resolution measurements. It has worked great so far; however, it maxes out at 1000 TV lines, and newer megapixel cameras claim far higher than this. Also, it is designed for only 4:3 aspect ratio. I can use it for 16:9 by only adjusting for image height, but I'd like to fill the scene with the chart.

I've also done some work in terms of measuring MTF, which is especially useful for comparing lenses and on-camera signal processing like sharpening effects, but I find that the basic resolution chart is good enough for comparing sensor limitations.

What charts are other folks using?

Re: Testing the Axis Q1755 HD Surveillance Camera

sggoodri — Wed, 06 May 2009 10:56:53 -0000

Might the screen recording software interfere with the decoder/player performance? I find that some screen recorders can't access video frames without disabling some of the hardware acceleration features leveraged by video players, straining the CPU even just for scaling and blitting to the screen. Also, capturing and moving that much data off the screen and storing it to file can take up a lot of CPU. Lastly, some video player plugins seem to perform worse in IE than in Chrome or Firefox on some computers.

I've analyzed and decoded H.264 bitstreams from the standard definition Axis devices, and they appear to comply very well to the H.264 standard and to RFC3984. So, it should be technically possible for Axis or others to leverage Microsoft APIs for hardware decoding acceleration in the player, but I doubt that would be a priority to them if a new PC can play the video in software only.