Glimpse - Continuous, real-time object recognition on mobile devices

Glimpse - Continuous, real-time object recognition on mobile devices

Abstract

Glimpse:

针对于移动设备相机的连续实时的物体检测系统

捕捉视频、定位物体、识别标注、逐帧跟踪

运行在服务器上

使用保存在移动设备上的active cache来帮助检测跟踪物体

计算trigger frame发送到服务器进行识别和标注

实验结果：

安卓智能手机、谷歌眼镜、校园Wi-Fi

在移动设备硬件人脸检测的加持下，Glimpse在连续人脸识别中能达到96.4%-99.8%的精确度，比没有Glimpse时提升了1.8-2.5倍

在没有移动设备硬件人脸检测的加持下，Glimpse在连续人脸识别中比没有Glimpse时提升了1.6-5.5倍

在没有移动设备硬件检测器的加持下，Glimpse在连续道路标志识别中能达到75%-80%的精确度。在没有Glimpse时连续检测处于不可用状态

Introduction

将一个视频帧传到服务器进行识别再传回来需要700ms，传回来的时候视频已经过了20帧了，可能会导致定位错误。

本文展示了Glimpse的设计、实现及评估。Glimpse通过在移动设备上保留active cache来达到高度跟踪性，使用来自服务器的过时结果进行标注；通过只发送trigger frames来达到减少带宽消耗的目的。

Background and design

Object recognition pipeline

detection
使用物体一些差异化的特征检测出其感兴趣的物体并定位，但是不进行标注（不明确这个物体是什么，只是知道这是感兴趣的物体）。

feature extraction
处理被定位的内容，提取特征。

recognition/labeling
识别物体进行标注。训练时提取特征向量，构造模型；在线推理时把特征向量输入模型即可。

Object tracking

物体追踪的目的是在视频流中逐帧跟随一个移动的物体。

Glimpse使用Lucas-Kanade tracking算法：

提取代表移动物体的特征点
可以利用pipeline中提到的detection和feature extraction。

估计下一帧特征点的位置
通过计算帧之间特征点的速度等来进行估计。

Challenges and approach

一些数据：

移动设备上计算太慢了（10倍以上），也导致了消耗能量的增加（10倍以上）。训练好的模型太大了，移动设备没有这么大的内存。

不过，很多移动设备在硬件上集成了人脸检测，使得移动设备人脸检测时间减少了6倍；但是特征提取和识别依然最好是放在服务器上执行。

同时，物体追踪在移动设备上执行很快（几十毫秒）

结论：

把物体识别任务迁移到服务器上是很重要的

但迁移会带来延迟问题，导致识别错位

Glimpse架构：

客户端
- 接受、储存视频帧，把trigger frame发给服务器
- 接受来自服务器的包围盒、标签、特征点等信息，利用active cache，只处理帧当中的一部分，将包围盒调整到现在的帧上，让用户看到持续的物体识别包围盒和标签

服务器
对收到的每一帧运行物体识别流水线，生成带有标签和特征点的包围盒

Active Cache

解决问题：怎么在移动设备上通过“过时”的（因为延迟）、从服务器发送来的定位信息，来定位移动的物体？

Glimpse采用的基本方法：计算服务器处理的帧与用户现在看到的帧之间的optical flow（光流），利用服务器返回的特征点信息将包围盒移动到当前用户所见帧的正确位置上。不过这种方法只适用于帧之间物体位置变化不大的场景。

所以，Glimpse保留了中间帧的active cache，通过其中的一个子集来运行物体追踪。简而言之，Glimpse保存了一堆中间帧作为“桥梁”，将包围盒一步一步的从服务器处理的帧移动到用户看到的帧上。但是处理中间帧也需要时间，如果使用全部的中间帧作为桥梁是没法接受的，因此Glimpse采用了“子采样"的方法，从中取一个子集进行处理。

留下两个问题：

选多大的子集？

选哪些作为子集？

How many frames to select?

选择的帧占比取决于网速和设备计算能力。网速越快，能选择的帧比例就越高；设备计算能力越差，能选择的帧比例就越少。通过实验来获取相关经验。

Which frames to select?

按照平均间隔均匀采样不太可取，因为帧之间的变换并不一定是均匀的，需要寻找一个容易计算的标准来衡量两帧之间的变化量。

本文做法：采用两帧灰度值之差并累加作为衡量变化量的标准，接着选择帧的问题就成了动态规划问题：将一个帧序列分l为组，使所有组的变化量最大和最小。

原型问题：线性分割问题

Trigger Frames

Glimpse策略：

当本地追踪失败的时候将帧发给服务器

当场景有显著变化的时候将帧发给服务器

当场景持续变化的时候，通过跟踪发送中的帧数来避免发送过多的帧

Detecting tracking failure

当大小、角度、外观变化的时候跟踪特征点就会偏离正确位置导致跟踪性能降低。当跟踪性能降低的时候，客户端就发送一帧到服务器来得到一些新的跟踪特征点。

怎么衡量跟踪性能呢？当物体逐帧移动时，这些点的移动距离应当是相似的。我们使用两帧之间所有跟踪点移动距离的标准差来衡量跟踪性能，当标准差大于某个阈值时，就发送trigger frame。

Detecting scene changes

使用上面”选择帧“中的变化量衡量算法来判断场景是否变化。

Limiting the number of frames in flight

当场景持续变化时，上述的启发式算法可能发送过多的帧给服务器，Glimpse限制了发送中帧的数量，当已经有一定量的帧处于发送中时，如果再来了一个trigger frame，客户端就会先停下来等待去接受来自服务器的信息，接收到后再发送这个新来的trigger frame。

Implementation

客户端

Android - OpenCV C++ / JNI
实验表明，C++的速度比Java快近10倍。

单独的线程接受相机帧、单独的线程用于计算

物体追踪 - Lucas-Kanade算法

使用灰度图片，640*480，JPEG格式

如果客户端没法连接到服务器，则会周期性重试；同时如果能在本地进行追踪，那就在本地追踪

服务端

道路标志识别

- 使用轮廓、形状、颜色等进行检测，通过并行加速检测

- 使用BVLC GoogleNet进行特征提取

- 使用SVM进行识别

人脸识别

- 使用Microsoft Face SDK来进行人脸检测

- boosted shape regression - 特征点提取

- 使用SVM进行人脸识别（分类）

Evaluation

Data collection

手工打标签、使用包围盒标注物体，因为并不知道有可用的公共移动视频数据集。

人脸数据
包括和朋友购物、饭店聊天、地铁站等待等等，总共收集到54020帧、35824张人脸。

道路标识数据
油管下载的视频，包括63003帧、5424个道路标识

通过数据可以发现，数据集中的物体大多会在视频中连续出现几秒到十几秒不等；两帧之间物体的移动距离基本不会超过20个像素；光照密度也有比较大的范围。

Experimental setup

为了保证可再现性，使用Linux跑客户端，使用Windows跑服务器，使用Mahimahi模拟网络环境，进行模拟。

Evaluation Metrics

Result

server only

no active cache
没有缓存；当收到前一帧的回复后才发送下一帧。

active cache only (no trigger frame)
有缓存；当收到前一帧的回复后才发送下一帧。

End-to-end performance

在人脸识别上，server only方案的精确率/召回率均明显低于active cache/active cache and trigger frame方案（2到3倍的差距）

在道路标志识别上，由于道路标志在视频中连续出现的时间比较短，当客户端收到响应的时候标志都不见了，导致server only方案的精确率召回率接近于0，而Glimpse能保持在至少60%以上的水平，提升了70到114倍。

当网络延迟增加的时候召回率降低，因为物体连续出现的时间比延迟还要短。

在道路标志识别上，召回率也比较低，原因同上。

Glimpse能显著降低带宽使用。

一些移动设备硬件继承了人脸检测的功能，在有硬件支持的情况下，Glimpse只需要在追踪失败或者硬件检测到新人脸出现的时候发送trigger frame，且trigger frame只需要包括人脸部分。相比于没有Glimpse的情况，使用Glimpse提高了1.8倍到2.3倍的追踪性能。

这些结果表明，只要有延迟发生，Glimpse都能有效的使用active cache隐藏掉延迟。

除此之外，本文还用详细的实验数据展示了Glimpse在active cache、trigger frame、能量消耗上的优势及影响因素，证明了Glimpse的综合实力和优秀。