十年磨一剑：从 FCam 到 Pixel 4 看计算摄影的发展

Matrix 精选

Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。

文章代表作者个人观点，少数派仅对标题和排版略作修改。

FCam 与诺基亚 N900：一切的开始

聊到手机界的摄影翘楚，Google 是肯定绕不过去的。在过去的十年中，Google 一直是手机界计算摄影（computational photography）的领军人物，Google Pixel 在计算摄影方面的深厚功力，有很大的一部分则要归功于背后出身斯坦福的计算摄影团队。

让我们把时钟拨回 2010 年。

那一年，乔布斯在旧金山莫斯考尼西举行的 WWDC 上发布了 iPhone 4，而就在半个小时车程外的斯坦福大学里，教授们正在调试一台看起来分外简单，甚至有些丑陋的黑盒子。

他们可能没有想到的是，这个「黑盒子」的蝴蝶效应会掀起一场计算摄影的风暴，这场风暴来得是如此的猛烈而影响又是如此深远——不夸张地说，这个黑盒子直接或间接地影响了十年后地球上几乎每一台智能手机拍出的每一张照片。

研究人员们的出发点是很简单的，他们想要一个可编程的摄影平台，然而当时市面上所有的摄影设备都不能满足这一需求：卡片机和单反相机虽然能提供较高的画质，但缺乏相关的算力，也不开放可供编程的底层，新兴的以 iPhone 为代表的智能手机虽然具有很大的潜力，但其孱弱的成像质量以及 Apple 封闭的软件系统也使得相关软件的开发无从开展。

既然没有，那么就自己动手造吧。

由斯坦福大学牵头，加州大学、乌尔姆大学参与，联合诺基亚研究中心和迪士尼，研究人员使用开发出了 FCam。

FCam 的全称是 FrankenCamera¹，取自《科学怪人》里被科学赋予生命的怪物。这台相机拥有开放、可定义且基于 C++ 的 API，使用 Linux 系统，是一个可以在毫秒级时间内对硬件进行控制的计算摄影（computational photography）平台。

这套系统并不依赖特殊的硬件，因此研究人员随后就把它移植到了一台诺基亚 N900 手机上，用同样的 API 实现了六大功能：

HDR 取景与拍摄
低照度环境取景与拍摄
增强动态范围的全景拍摄
视网膜摄影
基于传感器的手抖检测
重复摄影（Rephotography）

FCam 和那台 N900 为我们打开了移动设备计算摄影的新世界大门，在随后的十年中，这些功能逐渐走出实验室，来到了每一台智能手机上。

Camera 2.0/HAL3：计算摄影的 API 基石

在斯坦福做出 FCam 以后不久，这支团队就被 Google 挖走，领导 Android 相机框架团队的研发。

相较于只能调整光圈、快门、ISO 等极少数参数的传统相机（Camera 1 API），智能手机拥有更强大的感知能力，更强大的计算能力，更便捷的互联互通的能力以及用户语境感知能力。但由于软件上的限制，这些潜力并没有被很好地发挥出来。

2014 年，Google 在 I/O 大会上发布了 Android L，Android L 带来了许多重磅功能，比如全新的 Material Design 设计、ART 编译器以及一个全新的 API，它被称为 Camera 2 API²，而对应的硬件抽象层则被称为 Hardware Abstraction Layer v3（HAL3）。

在 Nexus 5 上，新的 API 在提供了更多控制，同时带来了超过十倍的性能提升并减少了延迟。

有了 Camera2API 的加持，HDR+ 算法也就成为了可能。

HDR+：破局的新思路

传统上的暗光拍摄会使用以下方法来提高画面亮度：

提升 ISO
使用更大的光圈
使用更长的曝光时间
闪光灯

这些方案都有自己的问题：

一方面，提升 ISO 虽然会有效提高画面亮度，但却同时放大了噪声，牺牲了画质；虽然使用大光圈模组是好事，但在移动设备上由于体积和厚度的限制，一味提升光圈也是不可能的。

另一方面，使用更长的曝光时间会增大手抖糊片的概率，光学防抖虽然能解决部分手抖的问题，但很难用于移动的物体；闪光灯并不适用于所有场景，有些时候我们不能打扰拍摄对象。

对于高动态范围成像，传统的 HDR 算法拍摄多张不同曝光时间的照片并进行合成，比如 iPhone 引入的拍摄过曝、欠曝、正常曝光三张 JPEG 照片并进行合成的 HDR 算法就是这一算法的典型代表。不过这种算法往往会带来伪像（artifact），比如高对比度物体边缘的光晕（Halo）。

如何破局呢？

Google 的答案是基于 ETTR 测光思想和人工智能技术的同曝光堆栈算法，也就是大名鼎鼎的 HDR+。

Google 的研究者们首先抛弃掉包围曝光的想法：不同曝光时间给对齐照片带来的问题是很难解决的，场景发生变化（比如画面内有运动物体）也会导致画面对齐失败。研究者们转而使用连拍多张相同曝光参数的照片，并且选择其中一张作为参照帧，将其它的照片向这张照片对齐并堆栈。

由于参照帧的存在，仅有确定属于该图片的部分才会被合成，这就改善了传统算法里的伪像问题，同时由于单张曝光时间短，因此使用该模式也不容易糊片。

这一思路后来被其它手机厂商借鉴，并广泛应用于各种夜景模式中。

进击的 AI 测光

测光，顾名思义，是对摄影画面中光线强度进行测量的技术。

传统的测光方式有两大流派，一个是照顾直出观感，另一个是为了后期空间而优化，即向右曝光（Exposure to the right，ETTR）。

第一个流派我们非常熟悉，它其实就是相机取景器里那个常见的曝光指示器。相机会提供多种测光模式，如全局测光、分区测光、和点测光等，这些测光模式适用于不同的场景，需要拍摄者根据实际情况使用，还需要时常根据经验来进行曝光补偿。

举个例子：当你在海滩边拍摄日落的时候，常见的测光算法会选择优先保证占画面主体的部分正确曝光，代价是牺牲掉一部分高光和阴影。但这就会导致太阳高光部分炸掉，而并不是画面重点的沙滩却获得了正确曝光——这个时候就需要点测光太阳附近，然后根据经验或者直方图来调整曝光。

为了方便新手，入门级相机上常有为各种场景优化的模式，但这些模式需要手动选择，并且也常常不够细化。

在 Camera 2 API 的时代，Google 要如何解决这个问题呢？

答案是数据分析。

Google 使用一个 28416 张图片的数据集⁴来训练自己的测光算法，调优后保留下来大概 4500 多个场景模式，并且抛弃了传统的利用直方图分析图像亮度的方式，转而对图像 RGB 通道的最大值和平均值分别进行分析。

为了照顾细微的影调变化，在每个通道上都有高达 64 个非均匀分布的采样点被用于数据分析——这一切都不需要用户介入，不需要用户去手动开启 AI 增强模式。

Google 对它非常自信，在现在的 Google Camera 中它已经取代传统测光成为了默认的测光模式。

对齐的艺术

接下来就是要把拍摄到的一串照片对齐了。

如何对齐运动物体呢？如果直接叠加上去，由于物体在画面中产生了移动，会出现一种叫鬼影（ghosting）的伪像，这是需要避免的。

早期 HDR+ 使用了一种叫 Pyramid based 的对齐技术，而在 Pixel 3 系列引入 SuperRes 技术后，Google 使用光流追踪（Optical Flow），把画面分割成小方块并追踪每个方块的运动，从而判断移动物体和静止物体。接下来对不同物体分别进行对齐，这个做法不仅能有效抑制鬼影，还让对齐失败的图片也能被用来降噪，不浪费任何一帧的信息。

最早在 Nexus 5 上，受制于时代，Google 使用了 YUV 堆栈，这一技术可以溯源到为 Google Glass 准备的相关研究，而随着 CMOS 速度和算力的提高，直接使用 RAW 信息进行堆栈成为可能。

关联阅读：用 Nexus 挑战单反，谷歌工程师的极限低光拍摄实验

PVC：强劲的芯，更开放的生态

随着 CMOS 和移动处理器性能的提升，Google 在后来的 Nexus 手机里引入了 ZSL（Zero Shutter Lag）模式，压缩快门限制（1/10s）并且把快门前后的照片持续写入缓存，这意味着按下快门即可成像，无需等待。这一技术的引入为 HDR+ 提供了抓拍的能力。

同时，Google 保留了更加激进的 HDR+ Enhanced 模式。这个模式需要手动开启，开启后相机会在对焦完成后才开始拍摄，快门限制放宽（1/5s），堆栈张数更多，画质也更好。

在 Pixel 2 上，Google 还引入了一颗独立的图像算法处理器，被称为 Pixel Visual Core⁵，这颗芯片让第三方应用也能享受到 HDR+ 带来的高画质。Pixel Visual Core 是一颗强劲的芯片，它有着独立的定制版 Linux 系统、闪存和内存，不过在面对新的应用场景（比如 Top Shot）时算力还是有些捉襟见肘。

所以在今年的 Pixel 4/4XL 中，Google 将其升级并更名为 Pixel Neural Core⁶。Pixel Neural Core 在图像合成算法处理上将发挥多大的作用我们暂时还不得而知，但 Google 已经为这颗芯片赋予了图像算力任务以外的额外使命——你在发布会上看到的下一代 Google Assistant、能够即时将音频转换成文字的录音应用，背后都有这颗芯片的功劳。

GCam：Mod 群体的狂欢

由于 Google 的这些算法都不依赖特殊硬件，因此它可以被移植到其它的设备上。

一位叫 BSG 的俄罗斯开发者首发了 Google 相机的移植，他当时手持一部小米 5S，处理器和 CMOS 都与 Google 的第一代 Pixel 相同。由于小米提供的算法并不理想，成像效果也不如人意，这位开发者有了把谷歌 Pixel 的相机移植过去的想法。

结果非常成功，移植版谷歌相机完全可以在其它机型上运行。由此，Google 相机 Mod 群体开启了一场狂欢，许多原来谷歌并没有提供的功能和选项被纷纷开发出来。

比如曝光时间控制，原来谷歌的策略最高是到 1/5s 快门，但开发者们通过修改设置提供了高达 8 倍的曝光时间选项、1.6s 快门来获得更好的画质；再比如 Google 的策略是自动堆栈 9 张，开发者们则改出了高达 45-60 张的极致画质选项。

此外，开发者们还从图像处理管线里「偷」出了 RAW 文件，使谷歌相机获得了 RAW 拍摄能力。这张 RAW 文件并不是其它手机里单张曝光的、低品质的 10bit RAW，而是多张 raw 堆栈而成的高品质 14bit RAW 文件——理想情况下，这张 RAW 的信噪比已经可以逼近 APS-C 的相机，动态范围上更是让一些相机厂商（咳咳某 C 开头的）汗颜。

还有开发者为谷歌相机适配了部分双摄机型，让中焦/超广角镜头也能调用 HDR+ 算法，进一步提升画质，或致力于优化谷歌相机的直出，为其加入了高光和阴影色调的调整，以及噪声模型的校正功能。这些改动虽然最开始是为第三方机型开发，但回过头也反哺到了 Pixel 机型上，让其拍摄能力更上一层楼。

可以说，Mod 和非 Mod 版谷歌相机完全是两个产品，原版谷歌相机注重各方面的平衡，Mod 版牺牲了不少，却把 HDR+ 算法的潜力全部发挥出来，实现极致画质。

关联阅读：Google Camera with HDR+ - 超黑科技点亮照片的美

Pixel 3：Mod 社区的反哺

第三方开发者玩的这么欢，Google 自然是要拿出一点新东西来镇场子，在 Pixel 3 和 Pixel 4 上，我们都能看到不少受 GCam Mod 启发的产物。

在 Pixel 3 上，Google 带来了全新的拍照策略，在你打开相机的那个瞬间，CMOS 就会一直往缓存里面喂 RAW 文件，在你按下快门的瞬间手机就会在缓存里调取最近拍摄的照片进行堆栈。

这是不同于此前任何一款拍摄设备的——按下快门的动作并不是告诉相机开始拍摄过程，而是告诉相机结束拍摄过程，因此可以视为真正的零快门迟滞。

Pixel 3 还带来了一个叫做 Top Shot 的新功能，它可以让你选择按下快门前后里最好的一张照片，而且这些照片都是经过 HDR+ 处理的，其性能要求是如此的巨大，哪怕是算法强大如 Google 也不得不限制了这个模式下的分辨率。今年 Pixel 4 发布并没有提这个功能是否得到改进，估计还是受制于算力吧。

此外，为了加强对运动物体的捕捉能力，HDR+ 在 Pixel 3 上加入了基于深度学习的物体识别与追踪。

再者是超像素变焦（Super Res Zoom），熟悉索尼相机的朋友应该知道，在新的 a7R 系列相机上搭载了一个叫像素偏移（Pixel Shift）的功能，可以通过抖动防抖组件来为每个像素提供 RGGB 的信息，从而实现更高的画质，不过缺陷就是对运动物体的处理不好，无法手持拍摄，并且需要后期导入电脑合成。

Google 超像素变焦的功能原理是一样的，不过其 OIS 组件能同时补偿手抖并照顾到每个像素的色彩信息，结合 HDR+ 算法对运动物体的处理，可以实现单摄媲美、甚至超越其它手机搭载的光学中焦镜头的效果。

这一功能甚至在检测到手机「过于稳定」时会自动启动 OIS 抖动来获得更多的信息。

至于 Mod 社区已经玩得飞起的 RAW 功能则变成了 Pixel 相机的自带功能，它在细节上会比 MOD 版更好，不过目前只能堆 15 张 RAW，比起 Mod 版暴力的 45~60 张 RAW 还是有显著的差距。但去年的「夜视模式（Night Sight）」通过类似的方法放宽了快门速度（1/3s），堆栈帧数也增加到了 15 张，再结合机器学习填色，夜拍效果令人印象深刻。

最后，通过机器学习，谷歌还进一步优化了单摄的景深探测和虚化模拟，同时带来了自拍柔光功能。