在android中检测面部地标点

Question

我正在开发应用程序,我需要在镜像凸轮或化妆凸轮等凸轮上获得面部标记点.我希望它也适用于iOS.请指导我一个强大的解决方案.我用过Dlib和Luxand.

DLIB:https://github.com/tzutalin/dlib-android-app

Luxand:http://www.luxand.com/facesdk/download/

Dlib很慢,大约有2秒的延迟(请查看git页面上的演示视频)和luxand是可以的,但它已付费.我的首要任务是使用开源解决方案.我也使用谷歌的愿景,但他们没有提供太多的面部地标点.所以请给我一个解决方案,使dlib快速工作或任何其他选项保持跨平台的优先级.提前致谢.

Answer 1

如果你采取一些快捷方式,你可以让Dlib在Android(20-30 fps)上实时检测面部地标.这是一个很棒的图书馆.

初始化

首先,您应该遵循Evgeniy的答案中的所有建议,特别是确保您只初始化frontal_face_detector和shape_predictor对象一次而不是每一帧.frontal_face_detector如果从文件反序列化它而不是使用该get_serialized_frontal_faces()函数,则会更快地初始化.将shape_predictor需要从100MB的文件进行初始化,并需要几秒钟.序列化和反序列化函数被编写为跨平台并对数据执行验证,这是强大的但是使其非常慢.如果您准备对endianness做出假设,那么您可以编写自己的反序列化函数,这将更快.该文件主要由136个浮点值的矩阵组成(大约120000个,总共16320000个浮点数).如果将这些浮点数量化为8或16位,则可以节省大量空间(例如,您可以将最小值和(max-min)/ 255存储为每个矩阵的浮点数,并分别进行量化).这将文件大小减小到大约18Mb,并且它在几百毫秒而不是几秒内加载.使用量化值的质量下降似乎可以忽略不计,但YMMV.

人脸检测

您可以将相机框架缩小到240x160(或其他任何一个,保持纵横比正确)的小尺寸,以便更快地进行面部检测.这意味着您无法检测到较小的面孔,但根据您的应用程序可能不会出现问题.另一种更复杂的方法是自适应裁剪和调整用于面部检测的区域:首先检查更高分辨率图像中的所有面部(例如480x320),然后裁剪区域+/-前一个位置周围的一个面宽,缩小如果需要的话.如果您未能在一帧中检测到面部,则恢复为检测下一个面部的整个区域.

面部追踪

对于更快的面部跟踪,您可以在一个线程中连续运行面部检测,然后在另一个线程中,跟踪检测到的面部并使用跟踪的矩形执行面部特征检测.在我的测试中,我发现面部检测需要100到400毫秒,具体取决于我使用的手机(大约240x160),我可以在中间帧上进行7或8个面部特征检测.如果脸部移动很多,这可能会有点棘手,因为当您获得新的面部检测(将在400毫秒之前)时,您必须决定是否继续跟踪新检测到的位置或跟踪的位置.以前的检测.DLIB包括correlation_tracker但遗憾的是我没能得到这个运行时间超过250毫秒左右每帧更快,缩小分辨率(甚至是非常大的)并没有多大的差别.修改内部参数会增加速度但跟踪不良.我最终使用了基于预览帧的色度UV平面的CAMShift跟踪器,根据检测到的面部矩形生成颜色直方图.在OpenCV中有一个CAMShift的实现,但是滚动你自己也很简单.

希望这会有所帮助,这主要是为了优先选择优秀的低成果并继续前进,直到你开心它足够快.在Galaxy Note 5上,Dlib在大约100ms处进行面部+特征检测,即使没有所有这些额外的复杂功能,也可能足以满足您的需要.

Answer 2

对于大多数情况,Dlib足够快.大部分处理时间用于检测图像上的脸部区域,因为现代智能手机正在生成高分辨率图像(10MP +)

是的,面部检测在3-5MP图像上可能需要2秒以上,但它会尝试找到尺寸为80x80像素的非常小的面部.我确信你在高分辨率图像上不需要这么小的面孔,这里的主要优化是在找到面部之前减小图像的大小.

找到面部区域后,下一步 - 面部标志检测非常快,一面需要<3 ms,此时间不依赖于分辨率.

dlib-android端口现在没有正确使用dlib的探测器.以下是如何使dlib-android端口工作更快的建议列表:https: //github.com/tzutalin/dlib-android/issues/15

它非常简单,你可以自己实现它.我预计性能提升约2x-20x

Answer 3

除了 OpenCV 和 Google Vision 之外，还有广泛可用的 Web 服务，例如 Microsoft 认知服务。优点是它将完全独立于平台，您已将其列为主要设计目标。我个人还没有在实现中使用过它们，但根据一段时间的演示，它们看起来相当强大；它们非常准确，并且可以根据您想了解的内容提供相当多的详细信息。（顺便说一句，其他供应商也提供类似的解决方案）。

类似的东西的两个主要潜在缺点是可能增加网络流量和 API 定价（取决于您使用它们的程度）。

就定价而言，微软目前每月免费提供多达 5,000 笔交易，并且增加的交易量不超过一分钱（取决于流量，您实际上可以在交易量大时获得折扣），但如果您这样做，例如，每月数百万笔交易，费用可能会以惊人的速度开始增加。这实际上是一个相当典型的定价模型；在您选择供应商或实施此类解决方案之前，请确保您了解他们将如何向您收费以及您最终可能支付的费用以及如果扩大用户群您可能需要支付的费用。根据您的流量和商业模式，它可能非常合理，也可能成本过高。

添加的网络流量可能会或可能不会成为问题，具体取决于您的应用程序的编写方式以及您发送的数据量。如果您可以异步处理并保证相当快速的 Wi-Fi 访问，这显然不会成为问题，但不幸的是您可能有也可能没有这种奢侈。