我对公司人脸产品的看法
每个系统的工作流程都可以抽象为：输入+执行+输出管理。系统的核心在于执行。科研实验室从执行单元的产品入手，选最好的输入得出最后的输出结果。最初的执行单元与最后可以商业化的执行单元的区别就是它的输入变复杂了，执行单元本身也更强大了。我们的核心产品是做人像识别的执行单元。为了实现这个执行单元的商业化，我们做了简化输入和输出管理的系统并包装成了门禁，远程监控和人脸大库比对系统。
我们的门禁已经把输入包装成功了一个很好看的输入硬件。用户不用再担心采集硬件的问题。
远程监控里面的盒子包装成功了一个输入控制硬件。
人像识别的输入是人像,视觉文化时代到来和平安城市的号召带来我们执行单元更多应用的可能，也使得它应该处理的输入变得复杂起来。比如除了人像静态图片外还有人像视频，比如人像视频又有不同场景下的视频。我们期望获取最好的类似于FERET人脸数据库里面的输入，但是那些不同场景下的视频输入离最初实验室的输入却越来越远。排除其他因素，我们希望人脸表情正常，被摄像的人头不要晃动， 譬如下面几种情况
人低头的时候（看手机or书）
人的头部靠着东西的时候（躺着）
人头被一个东西罩着不接触的时候（街头电话厅）
人下半身固定的时候（坐着聊天，开车）
人站着往前看的时候（开门，我们的门禁）
人站着往前定睛细看的时候（排队买火车票，取钱）
人在行走的时候（机场通道）
人头不完全对准摄像头的时候（随意走动）
由上到下，我们容易获取到一个比较好的人脸姿态就越难。
作为一个输入单元，人脸门禁需要解决这些输入的难度，从上面的排序来看它的输入控制难度不算最大，但是输入后它要进入一个针对静态图片的执行单元。然后再提供一个不能容忍很高误识率的认证功能。所以从应用的彻重点来说，不重视误识率的人脸远程监控报警就容易让用户接受得多。实际上对监控的用户，只要能检测出人脸来了就能报警了，就能解除一部分他们的工作了，既然还可能识别出一些类似的人，为什么不用呢。
所以我觉得执行单元SDK，我们现在是个DLL,其实也应该是个大的平台。
所以，它可以分别提供
静态人像图片的人脸验证版本SDK。
人像图片序列的人脸验证版本SDK。
基于性别（或者其他人脸大分类）人脸验证版本SDK.
这样输入和执行单元合作愉快的时候我们要搭建一个好性能的系统就容易很多了。
所以我的第一个建议是：SDK分版包装（静态人像，视频人像，性别分类人像或其他等等）
人脸大库比对系统，我觉得它的可挖掘能力在于比对输出人像图片的管理。哪些图片是对SDK适应性好的，哪些是适应性差的，输出的管理反过来可以再给SDK提供训练的样本。
基于人脸大库比对系统，我想提第二个建议：
建立一个自己的图像库。这个图像库至少可以保证SDK各种定位下的测试数据。
为什么我建议有我们自己图像库？
第一个原因：它可以帮助研发定位。在做深圳追逃项目的时候，我们由于没有测试数据，开发时用了一些北京这边的老数据，开发出来的程序在深圳跑。结果深圳就是跑不出效果，北京这边就是找不出问题。人跑到深圳一看，很快就发现问题了。
Google现在也提供了人像识别的应用。它发展很快。
先推出的是图像搜索，
输入北京关键词
http://images.google.cn/images?hl=zh-CN&q=北京&btnG=搜索图片&gbv=2&aq=f&oq=
再做的人脸搜索（人脸检测）
http://images.google.cn/ 搜索出相关图片后用户手工在搜索网址后增加 &imgtype=face
再做的人脸相似
http://picasa.google.com/intl/en_us/features-nametags.html
我觉得它发展快有一点原因是基于它的数据平台。所以在这个数据平台上它发展得很从容。
第二个原因：应对不同的场景，我们在推销产品的时候可以马上拿出一些人脸数据演示。
我想提的第三点建议是：
建立对SDK的测试平台.这样王博士每次的更改性能可以很快就放这个平台上做测试。
第四点建议：
做一个快速裁剪的系统原型。根据不同的应用选用不同的人脸检测和识别算法。这样不仅可以让用户预计到增殖空间也可以估计到增殖成本。
第五点建议：
是关于Mis应用类，或者是人脸大库比对系统上面的。我们指纹积累的客户基本是公安，公安的特征是有权获取人的生物特征，他们的数据量大，基本上是海量。海量数据容易导致查询率，分类效率低。所以我觉得Mis是不是可以提供数据挖掘的功能，帮客户挠到痒处留住客户。另外人脸大库比对系统黑盒子里面包的数据也是日积月累的很大的数据，这些人像图片目前是没标记的放着。如果做做数据挖掘聚类什么的应该能找出一些除了为SDK服务外额外的价值。
我们的门禁已经把输入包装成功了一个很好看的输入硬件。用户不用再担心采集硬件的问题。
远程监控里面的盒子包装成功了一个输入控制硬件。
人像识别的输入是人像,视觉文化时代到来和平安城市的号召带来我们执行单元更多应用的可能，也使得它应该处理的输入变得复杂起来。比如除了人像静态图片外还有人像视频，比如人像视频又有不同场景下的视频。我们期望获取最好的类似于FERET人脸数据库里面的输入，但是那些不同场景下的视频输入离最初实验室的输入却越来越远。排除其他因素，我们希望人脸表情正常，被摄像的人头不要晃动， 譬如下面几种情况
人低头的时候（看手机or书）
人的头部靠着东西的时候（躺着）
人头被一个东西罩着不接触的时候（街头电话厅）
人下半身固定的时候（坐着聊天，开车）
人站着往前看的时候（开门，我们的门禁）
人站着往前定睛细看的时候（排队买火车票，取钱）
人在行走的时候（机场通道）
人头不完全对准摄像头的时候（随意走动）
由上到下，我们容易获取到一个比较好的人脸姿态就越难。
作为一个输入单元，人脸门禁需要解决这些输入的难度，从上面的排序来看它的输入控制难度不算最大，但是输入后它要进入一个针对静态图片的执行单元。然后再提供一个不能容忍很高误识率的认证功能。所以从应用的彻重点来说，不重视误识率的人脸远程监控报警就容易让用户接受得多。实际上对监控的用户，只要能检测出人脸来了就能报警了，就能解除一部分他们的工作了，既然还可能识别出一些类似的人，为什么不用呢。
所以我觉得执行单元SDK，我们现在是个DLL,其实也应该是个大的平台。
所以，它可以分别提供
静态人像图片的人脸验证版本SDK。
人像图片序列的人脸验证版本SDK。
基于性别（或者其他人脸大分类）人脸验证版本SDK.
这样输入和执行单元合作愉快的时候我们要搭建一个好性能的系统就容易很多了。
所以我的第一个建议是：SDK分版包装（静态人像，视频人像，性别分类人像或其他等等）
人脸大库比对系统，我觉得它的可挖掘能力在于比对输出人像图片的管理。哪些图片是对SDK适应性好的，哪些是适应性差的，输出的管理反过来可以再给SDK提供训练的样本。
基于人脸大库比对系统，我想提第二个建议：
建立一个自己的图像库。这个图像库至少可以保证SDK各种定位下的测试数据。
为什么我建议有我们自己图像库？
第一个原因：它可以帮助研发定位。在做深圳追逃项目的时候，我们由于没有测试数据，开发时用了一些北京这边的老数据，开发出来的程序在深圳跑。结果深圳就是跑不出效果，北京这边就是找不出问题。人跑到深圳一看，很快就发现问题了。
Google现在也提供了人像识别的应用。它发展很快。
先推出的是图像搜索，
输入北京关键词
http://images.google.cn/images?hl=zh-CN&q=北京&btnG=搜索图片&gbv=2&aq=f&oq=
再做的人脸搜索（人脸检测）
http://images.google.cn/ 搜索出相关图片后用户手工在搜索网址后增加 &imgtype=face
再做的人脸相似
http://picasa.google.com/intl/en_us/features-nametags.html
我觉得它发展快有一点原因是基于它的数据平台。所以在这个数据平台上它发展得很从容。
第二个原因：应对不同的场景，我们在推销产品的时候可以马上拿出一些人脸数据演示。
我想提的第三点建议是：
建立对SDK的测试平台.这样王博士每次的更改性能可以很快就放这个平台上做测试。
第四点建议：
做一个快速裁剪的系统原型。根据不同的应用选用不同的人脸检测和识别算法。这样不仅可以让用户预计到增殖空间也可以估计到增殖成本。
第五点建议：
是关于Mis应用类，或者是人脸大库比对系统上面的。我们指纹积累的客户基本是公安，公安的特征是有权获取人的生物特征，他们的数据量大，基本上是海量。海量数据容易导致查询率，分类效率低。所以我觉得Mis是不是可以提供数据挖掘的功能，帮客户挠到痒处留住客户。另外人脸大库比对系统黑盒子里面包的数据也是日积月累的很大的数据，这些人像图片目前是没标记的放着。如果做做数据挖掘聚类什么的应该能找出一些除了为SDK服务外额外的价值。
