主动智能视频监控系统

上海交通大学　蔡 韬　汪晟骢　李 奇

指导教师: 黄 征

摘 要

视频监控是当前保障公共安全的常规手段之一, 现今监控系统的主动智能化成为一个主流的发展趋势。 我们利用计算机视觉技术自主开发了一套可独立运行同时又可集中管理的监控系统网络, 结合我们设计的简化Codebook背景建模算法、 轨迹跟踪算法、 异常检测算法, 能有效地对特定的异常情况进行实时预警, 并具有良好的实时性和检测结果。 相对传统监控设备, 同时具有智能监控的人力资源解放、即时预警和嵌入式的部署便捷、 价格低廉、 运行稳定的优点。

关键字: 视频监控; 计算机视觉技术; 嵌入式; 实时预警; 简化Codebook

Abstract

Video surveillance is nowadays a popular way to maintain public safety. Within the field, the development of active smart video surveillance system has become a major trend. Using computer vision technology, we developed a system which can work independently or in a centralized management network. This system, with the support of our simplified Codebook algorithm to build background, track objects and detect abnormal behavior, is capable of detecting and alerting users of some certain kinds of abnormal behaviors with great speed and accuracy. Compared with traditional video surveillance system, our system acquires at the same time the advantages of smart surveillance, which are liberation of manpower and real time warning, as well as the advantages of embedded systems, which are flexible, cheap and steady.

Key words: video surveillance; computer vision technology; embedded system; real time surveillance warning; simplified Codebook

1 概述

1.1 相关研究现状

自20世纪80年代起, 视频监控系统就逐渐在交通枢纽、 政府部门、 校园、 银行等场所广泛部署,在公共安全领域起着无可替代的作用。 而随着高速网络、 计算机视觉等技术的不断发展, 智能视频监控技术也日益成熟。 Valera等将智能视频监控技术的发展划分为三个阶段: ①传统模拟闭路电视系统;②结合计算机视觉技术的半自动闭路视频监控系统; ③广域自动视频监视系统。 目前, 智能视频监控系统是国际上图像处理类会议与杂志: 如图像和视觉计算(IVC: Image and Vision Computing)、 国际计算机视觉会议(ICCV: International Conference on Computer Vision)的热点话题。

结合计算机视觉技术的智能监控系统, 国际上已有不少成熟的案例, 如美国国防高级研究项目署(DARPA)信息系统处, 自1997年起, 联合卡耐基梅隆大学、 麻省理工学院等开展的重大视频监控项目VSAM(Visual Surveillance and Monitoring); IBM公司研发的S3智能监控系统等。 本项目所开发系统就可以归类为这种类型的智能监控系统。

1.2 需求分析

由于传统视频监控系统的弱点, 市场需要更便于部署的、 又有一定智能预警功能的监控摄像头, 故我们决定开发一款基于TI平台的嵌入式主动智能监控系统。 首先, 嵌入式监控系统有如下几点优势:

(1) 数字化监控视频信号可以通过网络传输, 扩大监控的范围;

(2) 作为专门设计、 功能单一的设备, 系统不受其他软硬件影响, 运行更稳定;

(3) 系统不依赖服务端, 是可以独立运行的设备, 便于安装、 维护。

本系统在嵌入式监控系统的基础上, 增加了主动、 智能检测的功能, 可以使监控系统同时具有嵌入式监控系统和智能监控系统的优点, 如下:

(1) 辅助用户进行半自动监控, 提高用户监控的效率, 从而降低人力成本。

(2) 降低由于人为因素(如视觉疲劳)造成的漏检。

(3) 相比无人干预的, 仅可记录、 取证用的闭路监控系统, 可以提供一定的预警功能。

1.3 特点与创新

根据对研究现状的详细调研, 我们发现, 在结合计算机视觉技术的智能视频监控系统中, 基于嵌入式平台的实现并不常见。 主要原因是主流算法不适用于嵌入式较弱的运算能力。 如混合高斯背景建模,对处理器性能要求较高, 嵌入式开发板几乎无法达到实时检测的要求; 而效果比较好的SURF特征算法, 速度同样无法满足要求。

因此, 为了实现项目目标, 我们需要充分利用Devkit 8500A开发板的运算能力, 对检测算法进行合理的简化与再创新, 最终提出一套适用于TI平台的, 从背景建模、 物体检测、 跟踪, 到根据运动特征进行预警的完整方案; 并设计了一个PC客户端用于对整个监视系统网络进行集中管理, 形成一套完整的、 可扩展的实时主动智能监控应用系统。

本项目特点在于:

(1) 相比于当前应用最广泛的传统闭路监视系统, 智能视频监控系统可以主动地对监控视频进行基本分析、 预警, 辅助用户进行监控, 提高监控效率, 减少人力资源成本, 降低人为因素导致的漏检情况。

(2) 如果进行产品化, 相比现有成熟产品, 开发板裁剪后造价更为低廉。

(3) 无需服务端进行支持, 部署灵活, 使用方便。 如采用无线网络, 没有复杂的线路, 部署会极其简单; 即便使用更加稳定安全的有线网络, 部署也并不烦琐。

(4) 简化Codebook背景建模算法运行速度快, 满足实时监控的标准。 训练时间可短可长, 具有一定的抗噪能力: 包括光线的轻微变化、 树叶摇动等。 拥有背景更新机制和出错处理机制, 同时保证了系统一定的稳定性。

(5) 通过自动或手动调整参数, 可以适应室内、 室外多种固定场景。 在许多情景下, 经过测试,有良好的表现。

1.4 实现平台介绍

1.4.1 硬件平台

(1) Devkit 8500A开发板1个, AM3715处理器, 集成1GHz的ARM Cortex-A8内核。

(2) CAM8100-U摄像头1个。

(3) 基本配置PC1台, 安装客户端程序。

(4) 迷你音箱1个。

1.4.2 软件平台

(1) 嵌入式Linux系统, 内核版本2.6.32。

(2) 编译器: arm-none-linux-gnueabi-gcc版本4.2.1。

(3) OpenCV开源视觉库, 版本2.0.0。

OpenCV全称是: Open Source Computer Vision Library, 于1999年由Intel建立, 现在由Willow Garage提供支持。 可以运行在Linux、 Windows和Mac OS操作系统上。 它轻量级而且高效——由一系列C函数和少量C++类构成, 同时提供了Python、 Ruby、 MATLAB等语言的接口, 实现了图像处理和计算机视觉方面的很多通用算法。2.0.0版本在2009年10月1日发布。 OpenCV经过嵌入式移植后, 才可运行在Devkit 8500A开发板上。 我们对OpenCV库以及其依赖库, 选择适当的版本链, 进行移植工作。

(4) 基于OpenCV的cvBlobsLib库, 版本8.3。

该函数库提供在完成提取前景的画面中, 圈出成簇的前景物体(Blob)的功能。 我们将其移植到Devkit8500A开发板上。

2 系统设计

2.1 基本原理

一个运动物体在一定时间内一定会使得视频像素在一定区域内发生变化, 捕捉这个变化我们就能够得到物体的大致方位和轮廓, 即背景差法进行物体检测。 同时, 物体的运动在一定时间内一定会呈现一定的规律性, 因此我们可以利用这些物体的特征来进行物体的跟踪。 我们将物体的相关信息和历史运动信息记录下来, 之后不断用新的一帧调整或者创建物体的运动信息, 并以此为依据来进行一场行为的判定, 从所有物体的当前和历史运动信息当中找寻可能存在的异常行为。 如果判定发生了异常行为, 系统就会发出预警, 同时将异常行为的信息保存下来。

2.2 系统方案

本系统是由可以独立运行的智能视频监控终端设备和负责集中化管理的PC客户端组成的系统。图1是我们系统的拓扑图, 图2是整体设计模块图, 从与本系统相连摄像头读入的视频信息, 先传递到开发板进行处理, 之后按照用户所设定的监控需求和参数进行异常匹配, 而后将检测信息、 实时的图像, 以及一些其他监控终端的信息推送到集中管理的客户端进行统一呈现, 用户可以通过客户端查看相应视频窗口、 阅读预警信息和阅读日志的方式获取检测结果。 当异常发生时, 监控终端设备将发出声音警报, 同时客户端会产生预警并且按照用户需求生成相应的日志, 同时客户端显示的视频上也会出现相应的异常标记。

图1 系统拓扑图

嵌入式设备相对传统的监控系统, 拥有较低的成本和部署灵活性。 目前, 摄像头需要架设并且和开发板用USB线相连; 实际产品中, 摄像头应与裁减后的开发板组合, 并一同部署。 监控终端经过简单配置后, 可以独立运行, 这充分体现将监控终端做在嵌入式设备上的好处。 当用户需要进行集中化管理时, 用户可以选择使用客户端。 只需通过网络连接监控终端, 执行相应的操作即可。

2.2.1 系统硬件设计

本套主动智能视频安全监控系统基于TI AM3517处理其实现。 图3是系统的硬件框图, 我们充分利用了平台的各个接口和资源: ①使用一个USB口(2.0HOST, 高速, 480Mb/s)进行摄像头的连接;②使用网口实现和客户端的网络连接; ③音频输出口以及一个小音箱; ④使用TF卡进行异常信息在监控终端的日志记录。

图2 整体设计模块图

图3 硬件框图

硬件部分当中, 摄像头是本套系统的主要数据来源, 开发板能够实时对视频进行分析, 并推送到客户端进行显示。 摄像头选用了CAM-8100-U型号, 在摄像时, 视频大小选取640像素×480像素, 实际进行异常判断时为了加快处理速度进行了减采样。

扩展预警模块为监控终端在现场发出预警提示使用的模块, 在监控终端检测到异常后, 可以在事发现场, 发出如响铃等提示。 这部分是对监控系统的扩展, 用户可以根据具体需求进行定制。 本作品中,我们制作了一个简单的示意用模块, 提供响铃预警功能。 该模块通过音频口接受命令, 操作小音箱进行发声。

我们没有使用开发板自带的液晶屏进行显示,是考虑到在实际投入应用之后, 开发板相当于监控终端的一部分,而监控终端本身无需显示所拍摄的图像,因此视频的呈现由负责集中管理的客户端进行实现。

为了防止视频信息在传输过程中被随意截取或者修改, 从而导致监控的失效, 我们建议将客户端和监控终端连接进同一VPN, 故可以使用带有VPN功能的路由器、 防火墙等。

2.2.2 系统软件设计

系统首先对接收到的来自摄像头的视频进行分析, 如图4所示, 主要包括5个步骤:

图4 开发板软件总体流程

(1) 背景建模, 背景建模是针对当前拍摄场景进行背景训练, 获取相应的背景信息以供之后差分法进行物体检测。 同时, 随着时间的推移, 背景需要被缓慢更新, 以适应背景中可能存在的变化。

(2) 物体检测, 目的在当前场景中使用背景差法将视频分为前景和后景两个部分, 之后圈定运动物体, 再对物体进行筛选, 最后将一个单位帧内的物体信息保存下来, 以便进行轨迹跟踪。

(3) 轨迹跟踪, 目的利用检测到的物体信息和历史轨迹信息进行比对, 按照一定算法, 更新当前的轨迹信息。

(4) 异常判断, 利用当前所有物体的轨迹信息进行异常匹配, 如果发现异常行为, 则进行记录和预警。

(5) 发送监控视频以及预警信息供客户端记录与管理, 客户端进行接收和记录, 之后在监控终端和客户端同时进行记录, 方便用户进行管理。

为了保证实时性, 我们选择了简化的视频流处理算法作为背景建模的算法, 并且不在开发板上使用数据库, 因为一方面所存储的数据量还没有必要使用数据库, 另外数据库的存储和调用将带来更多的延时, 影响实时流媒体的处理速度。 同时系统采用了最近最少使用(LRU)算法作为运动物体信息的更新和淘汰算法, 为了保证匹配的准确性, 我们采用贪婪算法(GOA)来做运动物体的匹配算法。 在异常检测的算法方面, 系统设计的链表结构也减少了异常检测的复杂度。

本设计方案充分运用了AM3715的处理能力, 同时也充分使用了Devkit 8500A开发板提供的各个接口, 包括网口、 USB口等硬件接口, 试图从多个角度给用户以实时视频信息和预警信息的呈现。

2.2.3 系统配套客户端设计

本地客户端是指本系统中提供集中式管理的PC客户端, 仅作为接受监控终端发回的视频、 预警信息等相关信息, 而不参与计算, 所以对于配置上没有要求。

客户端的设计主要着重强调用户的集中式的管理, 以及友善的控制界面。 本系统包含一个基于Emgu库[1]的集中管理程序, 向监控终端的管理人员提供包括: 视频内容、 预警结果、 本地日志记录。方便管理人员能通过这个客户端对多台监控终端进行集中式的管理, 例如设定预警参数, 记录摄像头视频内容等。

PC管理程序划分为主界面、 详细信息、 日志系统以及命令行控制台, 程序利用C#.Net、 Emgu库编程实现。

客户端的流程图如图5所示, 主要分为管理模块、 视频传输模块、 日志记录模块。

图5 客户端流程图

(a) 管理模块; (b) 视频传输模块和日志记录模块

图2.5(a)中描述了管理模块的工作流程, 主要分为连接监控终端以及向监控终端发送指令进行管理两部分。 图2.5(b)中描述的是实时视频传输, 以及日志记录模块的流程图, 根据监控终端传输至客户端的结果, 进行相应的日志记录。

2.3 系统功能

本项目的主要功能是可以通过摄像头或者视频提供物体识别、 轨迹跟踪和异常行为判断, 从而达到预警的功能。

2.3.1 异常检测

(1) 运动物体越界检测。

越界检测是判断在视频监控的范围当中, 运动物体是否发生了越界行为。 现实生活中存在机密的、危险的区域, 不允许随便进入; 越界行为可能预示着偷窃、 窃密或者其他可能存在的威胁, 在这种情况下, 越界检测行为是必要的。

越界边界可以由用户在客户端界面上用鼠标直接画出, 一旦运动物体越界, 在视频上圈住物体的框将变为红色, 同时记录预警信息并进行预警。

(2) 运动物体停留检测。

运动物体停留检测是判断一个物体是否在不恰当的位置停留。 停留行为既可能是犯罪嫌疑人在撬门、 蹲守, 也有可能是行人停留在危险地段, 需要提醒。 因此在特定地点, 我们有必要对长时间的停留行为进行预警并进一步加以判断。

判断是否预警的停留时间将作为参数由用户输入。 如果检测到停留行为, 系统将用一个比运动物体稍大的淡蓝色长方形框圈住物体停留的范围, 然后生成记录停留的位置和停留时长。

(3) 运动物体徘徊检测。

运动物体徘徊检测是判断一个物体是否在监控区域当中, 不断地在一定范围内进行任意形式的徘徊。 徘徊可能是犯罪分子的踩点、 望风或者是等待接头的行为, 因此有必要在仓库、 银行、 政府机关等敏感地点进行徘徊行为的预警。

判断是否徘徊, 用到的参数将由用户指定, 但是我们会根据用户给出的拍摄信息设定参数给出参考值。 被认定为徘徊的运动物体, 轨迹将被标记成深蓝色。

(4) 运动物体聚集检测。

物体聚集检测是判断多个物体在摄像范围内是否存在由分散到聚集的行为。 聚集行为可能是斗殴、滋事、 抗议活动的前兆, 因此需要对这种行为做出预警。

判断出聚集行为之后, 系统将用一个比聚集物体所在位置稍大的黑色长方形框圈住聚集的运动物体, 同时记录下聚集到该位置的人数以及聚集的位置。

(5) 物体丢失检测。

物体丢失检测实时判断某一区域内的物体是否在画面中消失, 从而及时预警, 避免贵重物品的丢失。

该功能主要检测用户自行圈出的监控区域, 这个区域中有可能丢失的静态物品, 如玉石装饰品、 名画, 等等。 监控终端会自动关注这一区域, 当该区域中的物体消失在画面中时, 监控终端和客户端就会发出预警提示并进行日志记录。 这个功能可以广泛应用在家庭、 博物馆等地点。

2.3.2 预警功能

监控终端的预警功能是为了对于异常情况进行现场的警报声的提醒, 从而阻止潜在的危险情况。 在这里, 我们使用一个迷你音响, 放出警报声, 从而达到预警效果。

客户端上的预警功能, 是提醒监控管理人员对于检测出的异常情况进行关注, 从而可以达到人为的提前介入, 并及时采取措施来阻止潜在危害情况的发生。 预警包括客户端界面上的文字显示、 报警声音、 视频红色闪烁以及视频本身轨迹颜色的变化。

2.3.3 日志功能

日志功能主要是为了审计, 事后调取相关日志, 从而达到取证的目的; 另外对于某些异常情况, 例如监控终端与客户端连接中断, 离线的日志记录依然执行记录, 从而保证了数据的记录完整性。 日志功能可以根据用户的设定, 在发生异常时在监控终端和客户端同时记录异常的相关日志信息以及异常发生时的快照。

2.4 核心算法的实现

2.4.1 背景建模: 简化的Codebook算法

在前景提取时我们采用的是主流的背景差法。 所谓背景差法, 即根据背景模型, 将前景与背景分离, 从而实现物体检测的算法。 背景模型的建立方法有直接作差、 单高斯模型、 混合高斯模型以及Co-debook等。

背景建模选用Codebook算法, 该算法是相当常用的一种方法, 该方法的一个重要特点是拥有比较快的速度和相对较好的抗干扰能力, 因此比较适合在嵌入式系统中运用。 Codebook算法在PC平台上的应用已经比较成熟, 还出现了许多算法的改进和变种, 进一步提升了Codebook的检测效果。

Codebook的基本思想在于假设所有像素点之间的颜色变化是独立的,因此就可以分开对每一个像素点进行背景建模。该算法提出的目标,如Kyungnain Kim在2004年时提及,是为了解决预测法建模, 即包括单高斯模型和混合高斯模型等方法无法解决的背景中高频变化物体的行为预测, 因此提出记录每个像素点,或是对每个小区域内的像素在一定时间内的取值。另外还免除了传统算法在背景建模时必须保持场景静止的要求,使得场景建模能在由移动物体的情况下也能正常进行。最早的Codebook算法如下:

在实际运用的过程当中, 使用原始Codebook算法速度一般, 加上Codebook需要较多帧数进行背景建模, 使得整体建模时间过长。 由于我们对精度要求并不很高, 为了加快建模速度, 减少建模时间, 我们将原始的Codebook算法进行了一定的简化, 在更新 (R, G, B) 值的过程当中, 我们使用了两种简化方法:

(1) 系统将一个像素点的(R,G,B)值简化成一个域, 即仅存放3个值的最小值和最大值, 当单位帧像素没有落入域时, 更新最大最小值, 当这个值和原来域偏离过大时不更新这个值, 防止其是噪点。这个方法的一个好处是拥有很快的速度, 能够充分利用摄像头15fps的速度进行建模, 缺点是可能带来一定的漏检。 在室外开阔的一些稳定场景中, 这种处理方法还是比较稳定的。

(2) 仅改变原算法在更新Codeword范围时的算法, 即存储多个Codeword, 不匹配时新建一个Codeword, 匹配时将此Codeword的域进行加减法的线性更新, 而不是采用原算法的均值更新。 这样做也在一定程度上加快了速度, 并且可以适应一些需要高精度的场景。

背景建模还包括背景更新算法, 即当一个物体进入视频范围并且长时间保持静止, 那么我们就认为它是背景的一部分。 比如一辆车进入场景时, 我们将其作为运动物体检测, 当其停车一段时间之后, 我们认为它已经融入背景。 背景更新是一个每帧视频都必须进行的工作, 因此复杂度要求比较高, 对此我们采用最常见的加权平均算法进行更新:

Mn+1=Mn×(1-β)+F×β

式中,Mn+1为下一帧的背景矩阵;Mn为当前的背景矩阵;β为更新速度参数;F为当前视频帧。

前景和背景区域更新速度一般不同, 前景一般为常量, 而背景则作为可调参数。

2.4.2 物体检测

物体检测算法主要是利用背景建模得到的结果进行前后景的分离, 之后在前景当中识别出运动物体。 系统在这个阶段除了能够正确检测出运动物体外, 还要具备一定的抗干扰能力和筛选能力, 因为背景差法必然存在噪点, 如果不能把物体和噪点加以区分, 那么系统很可能将大量噪点当作物体进行跟踪而浪费不必要的资源, 最终导致系统运行速度减慢。

我们调用OpenCV支持库cvBlobslib中的函数CBlobResult: Filter()来圈定运动物体, 该函数用到的算法来自文献。 该算法的大体流程如下: 算法假设所有运动物体均可以用其轮廓来表征, 在扫描一副需要前后景分离的图像时, 采用顺序扫描, 即从上到下或者从左到右扫描。 当扫描到的像素点被认定为轮廓, 无论是物体的外轮廓还是内轮廓, 使用T.D.Haig等所提出的边界跟踪算法, 来确定包含这个像素点的整个轮廓, 并且为轮廓上所有的点分配标记。 当轨迹跟踪回到起始点时, 就继续原来的顺序扫描过程。 当整幅图像扫描完成时, 再回头重新访问已经标记的各条轨迹, 之后将轮廓像素点周围(内侧或者外侧)的黑色像素点也归入该条轮廓, 内外侧可以由函数的参数进行指定。

由以上描述我们可以总结该算法的以下优点:

(1) 相比传统多次扫描算法, 此算法仅扫描一次图像, 虽然轮廓点将会被扫描多次, 但是该次数小于一个常数;

(2) 轮廓的标记是确定的, 无须如传统扫描算法中要多次标记不同的轮廓;

(3) 算法同时确定了像素点在轮廓中的排列顺序;

(4) 该算法由数学和实验证明速度快于传统的多次标记算法。

这个算法完全符合嵌入式简单快速的开发要求, 同时又能达到较好效果。 虽然Open CV的函数库提供了高速便捷的函数进行了前后景分离操作, 不过因为直接使用而不进行筛选将会造成大量的噪点, 故引入了一套自己的筛选机制。

筛选运动物体的指标一共有三个:

(1) 物体大小: 在实际场景当中, 如果是运动物体, 则其大小至少将大于某一定值, 而噪声多以不连续点的形式出现, 因此在圈定前景中的运动物体时, 忽略一些比较小的噪点, 仅选择大于一定大小的物体。

(2) 物体长宽比例筛选: 这项筛选的主要作用是抗干扰。 在实际操作时, 我们发现当场景中风力较大时, 摄像头和场景中一些物体可能存在微小的来回摆动, 从而形成长条状的噪点, 由于摆动持续发生, 背景更新的速度通常落后于噪点产生速度, 从而影响物体检测的精确度, 因此我们决定将长宽比例大于一定值的运动物体丢弃。

(3) 物体位置: 在用户选择系统工作参数时, 有一项边界设置划定了物体出现位置的范围, 即一般物体将从视频的四周进入。 如果场景中有门, 那么物体可能从门处出现。 其余位置突然出现的物体就都可以被认为是噪点, 因为在那里不可能毫无缘由地突然出现运动物体。 用户如果没有给出参数, 我们也根据用户设定的拍摄场景调整默认的参数进行设置。

2.4.3 轨迹跟踪

轨迹跟踪算法的主要任务是将当前帧物体检测的结果和历史的轨迹进行比对, 确定运动物体属于哪一条历史轨迹, 或者是认定为一个新的物体新建一条轨迹进行跟踪。 之后将当前物体的位置信息提取出来按照一定的算法对当前轨迹进行跟踪。

为了能够在较多的情况下以简单快速的算法进行轨迹跟踪, 以避免增加不必要的延时, 我们参考了贪婪算法做跟踪器, 即Greedy Optimal Assignment(GOA)算法。

我们用物体之间运动距离、 速度方向和大小的变化、 物体本身大小的变化这些差异来进行加权求和, 选取差异最小的两个点进行匹配, 将其视为属于同一条轨迹。 而在实际的操作过程当中, 我们选取了运动距离和物体大小两个变化作为比较依据, 速度方向的变化和大小留到异常检测中的徘徊检测时再做考虑。

贪婪算法可能存在一些缺点, 最佳匹配的两个点事实上可能不应该属于同一条轨迹, 例如当两个人擦身而过的时候, 有可能匹配最佳的是另外一个人而不是自己本身, 在这种情况下, 两个人的运动轨迹将发生交错甚至互换, 也有可能轨迹正常不发生错误。 一旦发生了轨迹交错, 那么当两个人分开后算法是无法进行纠错的, 这点是贪婪算法为简单和快速付出的代价。 在实际异常检测过程当中, 轨迹互换的概率很低, 即使发生了轨迹互换, 由于异常检测是针对每条单独轨迹的, 因此检测结果并不会受到影响。

我们不存储每帧物体运动的实际坐标, 而等到物体至少移动出一段距离之后再记录一次实际坐标,否则将上一个轨迹点再推入队列一次。 这样做的好处是, 防止由于圈入物体的框大小变化时所带来的中心点振动, 过多的振动将使得轨迹变得粗糙, 甚至可能发生物体向前走而轨迹向后走的情况, 这对于轨迹的呈现和异常判断都是不利的。

同时, 引入轨迹找回机制(即使用LRU算法), 即在一条轨迹在某一帧没能被匹配时, 我们不马上将轨迹抛弃, 而是保存一定帧数继续进行匹配, 如果匹配则重新启用该轨迹, 在一定帧数后仍没有匹配的轨迹, 我们认为物体离开画面, 将其抛弃。

最后, 我们引入了物体分裂与合并的算法, 因为很有可能进入视频的是走在一起的几个人或者是一辆汽车, 之后几个人分开或者人从汽车上下来, 就会发生物体的分裂行为。 这里我们采取的算法是将处于视频中不能新建物体轨迹位置而又没有得到轨迹匹配的物体进行再一次匹配, 如果匹配成功, 则新建一条轨迹, 复制匹配的轨迹, 并将此物体追加在新的轨迹之后, 这样就完成了轨迹的分裂。 反过来一样, 当多个物体合并时, 贪婪算法会选取匹配最佳的那个物体作为轨迹的延续, 而其他物体的轨迹在数帧之后将被抛弃, 成为一条轨迹。

运动物体的分裂和合并算法可以处理类似人上下车之类的运动物体分类和合并的情况。 该算法借鉴了Ismail Haritaoglu等人的研究成果, 对物体进行分裂和合并处理。

2.4.4 异常检测算法介绍

异常检测算法即通过当前获得的轨迹针对越界、 停留、 徘徊、 聚集、 物体丢失五种异常行为进行判断, 如果发生异常行为, 那么就通知预警模块进行预警。

(1) 越界行为判断。

越界检测物体是否越过了某条边界。 首先根据用户输入的两个边界坐标计算直线函数, 之后判断每条轨迹链表的首项, 即物体当前位置是否越过当前函数线。 如果越过当前函数方程, 将越界异常位置位之后, 在呈现时, 将使用红色的框来圈住这个移动物体。

(2) 停留行为判断。

停留检测了物体是否在一段时间内、 在一个位置保持相对静止。 由于轨迹点是每隔一定距离才更新一次坐标, 如果停留在一个区域之内就重复推入相同的坐标, 那么如果一个运动物体发生停留异常, 那么其轨迹链表的最后多个坐标必然是相同的, 因为其在停留期间没有更新过坐标值。 因此, 我们就可以以此为依据来判断停留, 如果一条轨迹链表的尾部存在一定数量以上的相同坐标, 将停留位置位, 在呈现时将以一个比运动物体稍大的蓝色框圈住停留物体。

(3) 徘徊行为判断。

徘徊检测物体是否在一定时间内在某一区域不停走动。 这里我们引入一个窗口的概念, 将其称作徘徊窗口, 即在一条轨迹当中进行回看。 徘徊是一个长时间的过程, 不是仅看一帧或者几帧就能准确判断的, 而向回查看的帧数因为不同的场景会发生比较大的变化, 因此系统将需要一个参数来确定这个值。对于这个值我们将针对用户的拍摄情况给出一些参考值, 同时也允许用户直接改变这个值。

有了观测窗口的大小, 就可以从一个轨迹队列的尾部开始, 以此观察窗口大小的帧数, 并求取窗口内所有点坐标的平均值, 作为可能的徘徊区域中心。 之后以此中心为范围画出一个正方形区域, 如果在窗口内的所有帧都处于这个区域当中, 那么就认定此运动物体在这个窗口中发生了徘徊异常, 之后徘徊窗口整体前移, 继续判断。 这样的判断方法类似求取方差并规定一个上限, 但是相比直接计算方差来的速度快且复杂度小。

相比对于整条轨迹直接判断或者训练的方法, 本系统使用的算法相对简洁和快速。 徘徊窗口的设定大大减少了循环次数, 更使得一些轨迹程度不到窗口长度的轨迹可以直接跳过不用判断。 同时, 在窗口中判断徘徊异常也比整体判断更集中和直接。 最重要的一点是, 不必等到物体离开轨迹完整就能够实时检测出异常, 可以更早地进行预警, 发生徘徊行为的物体将会在呈现时用蓝色轨迹。

(4) 聚集异常判断

聚集异常判断主要判断画面中原本分立的物体是否在某一段时间内合并到一起。 如果发生了该行为, 就要统计合并物体的数量, 当数量达到一定值时, 我们认为发生了聚集异常。

聚集异常的检测流程是在每一帧的轨迹匹配结束之后, 找到没有新物体匹配的轨迹, 之后将已经匹配的物体重新与该轨迹再次匹配, 如果匹配成功, 那么认为原轨迹对应物体发生合并行为, 该物体对应的轨迹合并次数增加1。 如果匹配失败, 则认为该物体暂时消失或被遮挡, 等待下一帧继续匹配。 与此对应, 在物体发生分裂时, 该轨迹的合并次数减少1。 如果在这个过程中一条轨迹的合并次数超过一定值, 则认为其发生了聚集行为。 发生聚集行为的物体将会在呈现时用一个比物体稍大的黑色框圈住。

(5) 物体丢失判断

物体丢失通过不断对用户选择区域进行前景检测, 如果该区域前景像素点所占比例达到一定程度,并且持续足够帧数时, 我们就发出物体丢失的预警。 用户关注区域的方框可由用户自行画出。

3 系统测试

3.1 测试环境

使用摄像头进行实时测试由于摄像头部署较为困难、 开发板电源距离限制等, 导致一些场景实时测试较为困难。 因此, 我们使用数码相机和三脚架进行监控视频的拍摄, 并通过后期处理, 将视频转化成和摄像头实时拍摄相同的格式、 尺寸、 帧率。 开发板从ROM中读取这段视频, 模拟实时监控的情况。测试拓扑图如图6所示。

图6 录像测试拓扑图

具体而言, 我们获取视频使用的函数是相同的, 仅仅是视频来源不同。 而经过测试, 读取视频和直接录制速度相差5毫秒内。 其次, 录像测试可以大大提高我们的测试效率, 从而测试视频的数量得到提升。 录像测试另一个优点是同样的场景可以反复调试, 帮助我们确定参数选取的公式。

3.1.1 测试视频列表

为了接下来的功能测试和压力测试, 我们共有24段视频样本, 其中10段为实时, 14段为录像。视频信息如表1所示。

表1 测试视频列表

续表

3.2 功能测试

3.2.1 物体跟踪测试

测试物体跟踪效果, 对表1中全部视频进行了测试。 测试结果如表2所示。

表2 物体跟踪测试统计表

3.2.2 异常检测测试

本系统为预警系统, 目的在于预防所有潜在的威胁, 所以对于漏报较为严格, 而适当允许误报的发生。

针对本系统提供的五种异常检测功能, 我们根据视频提供异常类型, 对表1中的视频进行了测试。场景设定方法如下:

越界检测: 指定某一路口行人不可通过, 画出警戒线。

徘徊和停留检测: 假定当前画面为重要仓库、 银行、 军事机关等需要监控场景, 这些场景下, 徘徊和停留的行人可能有不轨企图。

聚集检测: 假设当前画面为广场等场景, 这里聚集的人员值得注意。

物体丢失检测: 模拟当前画面中存在某个贵重物品, 需要注意其是否被人拿走。

测试结果如表3所示。

表3 异常检测功能测试统计表

3.3 压力测试

3.3.1 背景抗噪能力测试

为了衡量背景抗噪能力, 定义噪点数为应当被作为背景的物体被误当作前景物体而圈为Blob的噪点簇的个数。 噪点数越少, 对我们的检测影响越小, 性能越好。

我们选择两段在大风天气进行测试的视频, 监控范围内树叶摇动较为厉害。 测试这两段视频结果如表4所示。

表4 背景抗噪能力测试统计表

说明: 尽管在只有前景的画面上有很多细小的噪点, 我们不认定它们为噪点。 为了呈现大风的场景, 我们选取同一帧进行截图, 比较使用本系统背景建模方法和背景差法的效果。 之所以选择背景差法, 是因为大风天气下, 背景差法无法解决树叶的摇动所带来的噪点。

3.3.2 背景稳定性测试

由于本系统对摄像头稳定性要求较高, 即便对于商品化的版本, 也无法保证监控终端绝对稳定。 因此我们要进行背景的稳定性测试, 在摄像头轻微晃动的情况下, 对系统进行测试。 在整个测试中, 我们出现了4段晃动较为明显的视频, 并用它们进行测试, 结果如表5所示。

表5 背景稳定性测试统计表

说明: 晃动的情况, 如果背景中有墙壁等静物, 会出现物体轮廓状的噪点。 这种噪点是可以通过长宽比例进行排除的。 而其他位置的噪点, 如汽车玻璃, 排除就较为困难, 只能通过未被轨迹匹配而排除, 理论上这些噪点, 被轨迹匹配并不是没有可能。 但是在我们的测试中, 这样的案例非常少, 原因可能是以下几点:

(1) 理论上, 噪点在画面中随机出现, 然而事实上并不是如此。 噪点往往出现在一些特殊的位置,如车窗、 玻璃窗, 等等, 这些位置行人不经常穿过, 因此噪点对检测影响小。

(2) 噪点往往不会连续出现。 这样噪点出现时, 恰好匹配到行人轨迹的概率更低。

(3) 物体跟踪使用GOA算法, 连续移动的物体自身往往比其他物体更容易被匹配。

3.4 测试分析与总结

本次测试证明了我们的系统的异常检测符合要求, 日志功能和客户端运转正常, 一定程度上可以抵抗环境中的噪点和监控终端小幅度的晃动, 长时间运行较为稳定, 测试通过。

虽然测试结果表明本系统指标高于预期, 但是对于一些漏检和误检, 我们对这些漏检误检现象进行了溯源分析, 以便进一步提高系统性能。

(1) 理论上, 交错的轨迹再次分裂时, 很可能出现物体A的轨迹和物体B进行匹配。 我们认为这种情况属于误差范围之内, 因为我们并不关心异常具体发生在哪个人身上, 而关心当前场景中究竟有无异常。 然而, 上述现象出现数量比我们预期的要少, 因为视频中的人物都在正常运动, 没有刻意地去造成人物的混淆。

(2) 大部分跟踪错误的轨迹, 往往持续时间较短, 并不对异常检测造成影响。 例如图7中的情况,错误轨迹出现在边界处, 是行人墙上的影子留下了一条轨迹, 它仅出现4到5帧, 不会被判定为异常,不影响检测结果的判定。

(3) 未进行跟踪的轨迹绝大多数出现在阴影内, 这与摄像头的对于阴影的分辨能力不足有关。 例如图8所示的情况, 圈中所示骑车人未被系统检出, 而我们即便用肉眼也很难看清这个人。

图7 跟踪错误轨迹示例

图8 阴影下轨迹跟踪丢失示例

人物出现在这些区域中未被检出, 这种情况主要有两种原因: ①摄像头本身拍摄质量较差, 阴影区域尤其严重; ②环境设置时, 像素点的阈值偏大, 而为了抵抗噪点, 这个阈值不得不向上调整。 因此,我们提供的解决方案是为监控终端选配更高质量的摄像头, 并且尽量避免强烈日照、 阴影面积大等环境条件较差的场景。

(4) 相比于其他四种异常检测, 停留检测的效果较差, 主要是出现了我们不能容忍的漏检情况。原因主要是停留检测中, 物体运动范围较小, 而当这个运动范围落入物体检测失败的阴影中时, 漏检就发生了, 解决方案同(3)。

4 总结与应用前景

4.1 总结

1) 本项目在大量查阅文献的基础上, 根据TI平台的特点, 设计了背景建模、 前景分离、 物体检测、 轨迹跟踪以及五种异常检测的完整系统流程。

2) 在衡量TI平台计算能力之后, 我们设计了简化Codebook算法、 轨迹跟踪算法、 几种异常检测算法等, 折中了计算速度与检测效果。

3) 移植OpenCV等开源库到Devkit 8500A开发板, 以这些库为基础, 编码完成整套系统。

4) 设计了可对本系统进行集中管理的客户端, 该客户端界面简洁、 用户友好。 并移植OpenSSH,提供给用户调整监控终端的接口。

5) 在开发过程中, 我们进行了大量的实景测试, 从而总结出适用的场景, 并且估算出一套较为准确的参数表(详见附录5.3)。

4.2 应用前景

视频监控是当前保障公共安全的重要手段之一, 如今监控系统的智能化也成为主流, 我们的项目拥有广泛的应用前景。 我们的系统拥有以下的优点。

1) 部署灵活。 传统的部署方式是利用电路交换等方式, 需要大量的线路进行排线, 部署复杂; 而我们的系统利用网络进行传输, 部署快捷, 同时可以拓展使用无线进行连接, 部署将更灵活。

2) 准确预警。 传统的视频监控系统往往需要人力的大量参与, 所有的信息都需要经过人的处理,往往会出现疲劳而出现漏检、 误检; 而我们的系统能够预先进行筛选, 有针对性地进行预警, 提醒监控人员, 从而减少人为失误以及监控人员的工作量, 提高检测准确率。

3) 个性化设置。 监控终端可以根据各个监控的场景进行个性化的参数设置, 针对性地检测某些异常情况, 可以针对性地集中管理监控设备。

4) 独立运行。 设备的运行和数据的存储不依托远端的服务器, 能够独立进行物体检测、 物体跟踪、 异常检测, 并能够现场预警, 并在监控终端本身产生日志用于以后的审计。

5) 价格低廉。 裁剪后进入工业化生产的监控终端, 根据厂商的报价, 我们预估裁剪后我们的设备单个监控终端约在300元以下, 而随着电子元件价格的降低, 这个价格可能会进一步的下降。

6) 体积小, 重量轻。 鉴于此开发板可用于手机开发, 所以裁剪去一些零件后, 最后的体积可能比一个手机更小, 小体积的监控终端更具有隐蔽性, 而且更容易进行快速部署。

5 附录

5.1 源代码清单 (表6)

表6 代码清单

续表

5.2 异常行为视频显示特征列表 (表7)

表7 异常行为视频显示特征列表

5.3 监控终端参考参数

参考拍摄距离:30～50m

稳定帧数:30以上

训练帧数:150～200

像素门限:10左右

边界: 自行选择

最大跟踪距离(平方):2000以上

分裂最大距离(平方):1000以下

轨迹淘汰帧数:15左右

形状差异:20左右

更新速度:0.1

徘徊窗大小:200左右

徘徊距离:70左右

[1] Emgu: OpenCV.NET库: http:∥www.emgu.com