版权声明：原创作品，欢迎转载，但转载请以超链接形式注明文章来源(planckscale.info)、作者信息和本声明，否则将追究法律责任。

甚嚣尘上的VR炒作终于在今年平静了，这大概意味着VR技术开始进入技术成熟度曲线的第三个时期：行业的公众关注进入低谷，人们开始冷静客观评估技术的适用范围和潜力，并逐步发现有效的经营模式。

VR时代的到来是不可避免的，或者说它已经到来，只是还没有推到大众面前。另外，真正具有想象力和冲击力的新技术乃是紧随其后的AR，这一点可能并不像公众预期的那样。这个时代需要由一系列扎实漂亮的产品撑起（不是概念，不是Demo,不是DIY，是产品），我们这次来谈谈全景摄像机的产品化之路上有哪些曲折和挑战。当然，全景摄像机本身并非仅限于VR应用，我们也要包括安防应用。

安防监控领域

泛泛来说有两种全景视频实时拼接方案，即前端（机内）拼接和后端（PC/手机）拼接。在安防领域也是如此。前端拼接直接由全景摄像机输出拼接完成的全景帧，具有很好的兼容性，可以直接像一台普通IPC一样接入旧有系统；而后端拼接是将全景摄像机看做独立的多路IPC,同时接入监控PC服务器，由PC完成实时拼接和监看。后端拼接的优势在于可以完成极高分辨率（目前我们的后端方案全景监控分辨率最高已经有9600万像素）的全景监控，但兼容性不好，需要将全景拼接SDK嵌入平台软件，不能做到“即插即用”。

从实现上来说，大概有如下几种：FPGA/DSP/CUDA/OpenGL/CPU. 前两种用于前端拼接，FPGA的开发和维护都有较高代价，CUDA和OpenGL方案具有最高的处理能力，CPU方案除非无法选择否则是应该排除的。在前端拼接方案里，还要考虑编码问题，全景帧动辄数千万的分辨率编码并不是一个简单问题。这里我们主要谈我们自己比较熟悉的CUDA/OpenGL方案。

安防监控领域对于全景摄像机有一些特殊需求。对于后端拼接全景，其拼接参数应当保存在设备之中，由设备传给平台软件完成实时监看的初始化流程，而平台软件上则对实时拼接的效率，全景模块与其他设备如球机的互动都有颇多要求，我们简单罗列如下。

1. 拼接参数应该是一个很小(几k到几十k)的文件，方便写入设备及在网络上传输；
2. 灵活的裁剪/融合算法。安防全景细分需求繁多，催生大量不同类型的设备，不同目数，不同镜头，不同摆位都会导致非常不一样的应用场景，算法需要在任何场景下都能够完美融合，不产生图像瑕疵。
3. 全景拼接模块应当支持实时的子码流/主码流切换。平台软件实时监看几十上百路网络摄像机，区分子码流/主码流非常重要，这样在小视图模式下采用子码流，而大视图下自动切换到主码流，既保证了性能又保证了操作体验。
4. 全景拼接模块在子码流输入下能够同时完成多达几十路的实时拼接播放。
5. 应该有多种全景投影模式。除了常见的球面/柱面展开，碗形交互式展开在安防监控领域颇受欢迎，如图所示。各种投影模式之间应该能够实时切换。
6. ROI局域放大。
7. 与球机联动，全景纵览全局，球机实现局域放大。
8. 全景像素坐标到输入图像像素坐标的正反向投影。

解决以上需求的任务并非平凡。简单一例，子/主码流实时切换中，除非子码流与主码流具有同样的视野，否则无法在不重新初始化算法的前提下完成切换，这要求算法具备瞬间初始化完毕的性能。同样的性能要求也出现在实时全景投影模式切换中。

从一个算法到一个成熟产品的道路是长远的。行业里很多学术型团队最终败在懂算法不懂软件工程，无法将一个Demo级的算法提升成一款结构良好，功能灵活，充分解决行业内需求的算法产品，令人扼腕。

对于前端拼接来说，要支持交互式全景类型如碗形、柱面等，同样也需要将一个全景播放模块嵌入平台软件，此种情况下，上述需求中除1、2、8外都仍然需要满足。

前端拼接技术的一个需要解决的问题是，以条带展开型全景作为全景帧类型做编码传输，如何节省带宽？将一个全景球展开为一个平面图像就如同将柚子皮拍扁在桌面上，总会像全球地图那样产生一个畸变，这是无法避免的。投影类型选择不好可能会导致相当大的畸变，比如球面两极地区一个像素被拉伸成一行像素。更好的投影类型应该是立方体展开

这一展开方式可以将畸变控制到很小的程度，但它一定程度上损失了条带全景图那种一览无余的直观性，需要特殊的全景播放器将它重新贴图到全景球或全景展开平面上才能够还原全景。当然也有其他采用更高级的数学方案设计的展开方式，这里不再提。

全景摄像机与全景直播

这里特意避免了提“VR全景”这一概念，因为严格来说VR全景和普通的全景摄像机并非同一概念，前者要求具有视觉深度感，后者只是个普通的2D曲面，沉浸感不强。但由于普通全景摄像机技术较前者简单，所以目前市面上大都为此类产品。

我的个人观点是，目前全景摄像机难以普及的一个关键是没有标准格式。并不像传统数码相机，全景输出格式杂乱无标准，全景视频播放器无法自动化决定采用何种投影类型播放，使得全景视频成了少数geek一族的玩具。但在真正的行业标准出现之前，让自己的产品对各种不同的输出格式都做好准备不失一个办法，而且不难。

这类产品中低端以前端拼的双鱼眼为主，高端以后端拼的多目摄像机为主，但迄今几乎没有很让人满意的产品出现。

双鱼眼方案的优势在于廉价且可以极小化拼缝。在所有可能的基于拼接算法的方案里，双鱼眼的拼缝是最小的。拼缝大小取决于多个摄像机投影中心的距离，摄像机的投影中心位置大致在sensor中心向后一个焦距远的地方，通常这是个很短的距离。理论上只有各个摄像机的投影中心重合于一点才能够产生出无缝的全景图，但这种情况下相机的体积需要压缩到极限，几乎不可达到，通常只能将尺寸压缩到极小以期更好的拼缝效果。除了双鱼眼方案，它是可以真的做到投影中心重合的。

所以，对于做基于拼接算法的全景摄像机的厂商，一个忠告是，将相机尺寸做小。

全景直播机似乎有很长一段时间卡在很高的软件授权费和拼接服务器价格上，但这是比较奇怪的，因为这一技术并不困难——至少在安防领域，四年前就已经有公司做到了上千万像素的全景监控。像安防领域一样，最高性能且具有很好平台兼容性的方案就是OpenGL方案，现在的显卡处理几千万像素的全景拼接融合如同砍瓜切菜，顺便搞个硬编码做推流是不难的——我们自己的技术在这方面早已验证过。

全景直播机通常并不是多个摄像机拼一块儿这么简单粗暴，它需要解决两个基本问题，一是摄像机之间的帧同步，一是摄像机之间的成像参数同步。前者保证人通过拼缝时不会出现消失又出现这种诡异效果，后者使得全景画面亮度、色彩具有一致性，不出现尖锐的过渡。

但实际上，我们并不真的需要成像参数同步。理论上，多个摄像机各自自动曝光，可以实现HDR（高动态范围）全景，因而目前在硬件上做成像参数同步只是一个过渡方案，将来为了生成HDR效果全景，这一机制是必然要废弃的。

要有更好的拼接质量，可以选择CUDA或OpenCL,它比OpenGL提供更多控制力，使得开发者可以采用更复杂的图像处理算法。我们目前就在基于CUDA尝试HDR全景算法的开发。

VR全景

VR全景是万众期待众望所归，出于不可描述之原因，这一技术被视作新时代的宅男福利。但一定要冷静！因为我们真还有很多技术问题要解决。

实现3D效果，目前主要有基于传统拼接算法拼左右眼全景图（参见我们的文章《DIY 3D全景摄像机》）和光流算法（Google Jump/Facebook Surround360等）两种。

基于拼接算法基本是没有前途的（所以我们直接做成了DIY教程-_-!）。这一方案的死结在于，3D全景中深度感最强的近景，正好是拼缝最大的，而且你不能够通过缩小设备尺寸来解决，因为它至少应该有人的瞳距（~6.2cm）那么大，否则你戴上眼镜后，会发现自己缩小了——周边的一切都大了一遭。

光流算法是目前给出效果最好的，光流刻画了两个图像的像素是如何对应的，算法利用光流来插值计算没有被相机所采集的光线之颜色，从而产生出完全无缝的全景效果。但目前效率不高，关键是光流本身的计算是相当繁重的，而且算法对于每队图像还需要计算正反向两个光流，再考虑上光流在时间轴上的一致性，带来了非常大的计算开销。

实现VR视频采集，本质上是通过有限个相机采集几个点上的物理光线，然后用这些光线来猜测、插值出其他空间位置上任意光线。这在计算机视觉领域早已研究多年（想想黑客帝国里的子弹时间镜头是怎么来的），这个方向叫做”Image-Based Rendering”.

理想自然是通过采集有限个点上的光线就能够计算出一个邻域上的光场。这一定程度上做得到，而且有很好的工作，但付诸应用仍然有距离。

所以，仅就目前的情况来说，基于光流算法来做后期，做高质量近景VR视频是没问题的，但想要直播，还得等等。