谷歌HDR+研读（三）
谷歌HDR+研读（一）
谷歌HDR+研读（二）
6整理
对齐和合并捕获的拜耳原始帧会生成具有较高比特深度和SNR的单个原始图像。在实践中，我们的输入是10位原始数据，我们将其合并到12位以保留从合并获得的精度。这张图片现在必须经过校正，去马赛克和色调映射 - 这些操作通常由ISP来执行，但在我们的情况下，这些操作是软件，并且包括动态范围压缩的关键附加步骤。按应用顺序，这些操作是：
1.黑色级别减法可以减少所有像素的偏移量，使得不接收光线的像素变为零。我们从传感器上的光学屏蔽像素获得这种偏移。
2.透镜阴影校正。增强图像的角落以补偿透镜渐晕，并校正由于光以斜角照射传感器而在空间上变化的颜色。这些更正是使用ISP提供的低分辨率RGGB图像执行的。
3.白平衡。线性缩放四个（RGGB）通道，以便场景中的灰度映射到图像中的灰色。这些比例因子由ISP提供。
4. Demosaicking。将图像从Bayer原始图像转换为每像素12位的全分辨率线性RGB图像。我们使用Gunturk等人的技术组合。包括带有加权平均的边缘插入插值，基于恒定色调的插值和作为校正项的二阶梯度。
5.色度去噪。减少暗光低光图像中的红色和绿色斑点。为此，我们使用一个近似的双边滤波器，使用YUV中的两遍应用的稀疏3×3抽头非线性核来实现。
6.色彩校正使用ISP提供的3x3矩阵将图像从传感器RGB转换为线性sRGB。
7.动态范围压缩。请参阅下面的描述。
8.除雾 通过应用全局色调曲线来降低眩光的影响，该曲线将低像素值推到更低的位置，同时保留中间调和高光。具体来说，我们允许多达0.1％的像素被钳位到零，但只能调整低于白色电平7％的像素。
9.全局色调调节，通过将S形对比度增强色调曲线与标准sRGB色彩分量传输功能连接起来，以提高对比度并应用sRGB伽玛校正。
10.色差校正，以隐藏横向和纵向色差。我们不假设镜头模型，而是沿着高对比度边缘查找像素，并将其附近像素的色度替换为不太可能受色差影响的像素。
11.锐化，使用由3级卷积金字塔构造的高斯内核的总和来实现不锐利的掩蔽[Farbman et al。 2011]。
12.色调特定的颜色调整，使蓝天和蔬菜看起来更具吸引力，通过将蓝蓝色和紫色转换为淡蓝色来实现，并且通常会增加蓝色和绿色的饱和度。
13.抖动，当从每像素12位减少到8位显示时，通过添加来自预计算表的蓝噪声来实现量化伪像。动态范围压缩。对于高动态范围场景，我们使用本地色调映射来减少高光和阴影之间的对比度，同时保留局部对比度。我们选择的色调映射方法是曝光融合的变体[Mertens et al。 2007年]。给定以不同亮度级别描绘相同场景的输入图像时，曝光融合使用图像金字塔来混合输入图像的最佳曝光部分，以生成单一输出图像，看起来很自然并且具有比输入更少的曝光不足区域。
通常将曝光融合应用于使用方括号捕获的图像。在我们的流水线中，我们采用恒定曝光捕捉多个帧，而不是包围。为了使曝光融合适应我们的流水线，我们通过对其进行增益和伽马校正，从中间HDR图像中推导出“合成曝光”，然后将它们融合，就好像它们已经使用包围拍摄一样。我们以灰度进行这些提取，我们只创建两个合成曝光 - 一个短和一个长。短时间曝光告诉我们有多少像素会被吹出，并成为捕捉过程中使用的整体曝光，而短曝光和长曝光之间的比例告诉我们正在应用多少动态范围压缩。这两个值都来自我们的自动曝光算法。
融合灰度而不是彩色图像，只使用两个合成曝光，可以减少计算和内存要求。与Mertens等人的工作相比，它还使我们能够简化每像素混合权重。 [2007]。特别是，我们使用亮度固定的加权函数，有利于中等亮度的像素。
该函数可以表示为一维查找表。 融合合成曝光之后，我们撤消所得灰度图像的伽马校正，并通过复制原始线性RGB图像中的每像素色度比值来对其进行重新着色。
7结果
图10显示了使用我们的系统并排拍摄由传统成像管线生成的单次曝光照片的示例照片。我们的系统几乎总能产生优于传统单一曝光管线的效果，并且在动态范围较大或光线较弱的场景中，改善效果通常很明显 - 较少的高光溢出或压碎的阴影，较少的噪点，较少的运动模糊，较好的色彩，更清晰的细节和更多的纹理。虽然我们的结果受益于选择一个尖锐的参考框架，但我们的系统对替代选择非常有效;它可以将任何突发转换为去噪视频。
图10：将我们的方法产生的照片与同一设备上的标准单次曝光处理流水线产生的类似照片进行比较。在作物中，我们还将我们的管线结果应用于单个框架，以展示合并的好处。鼓励读者放大。最上面一行显示了一个经典的HDR场景：教堂里的彩色玻璃窗。在这个例子中，我们的方法在明亮的窗户和周围较暗的墙壁中保留了更多细节。中间一行显示一个黑暗的场景（3勒克斯大致相当于烛光）。这里我们的方法产生比标准管道更亮的图像。另外，通过减少空间去噪，我们可以保留低对比度的细节。最下面的一行显示了中等光线下的一个快速移动的物体。在这种情况下，我们使用比传统流水线中的单次曝光更短的曝光时间来减少运动模糊。我们还从这个场景中获益，从幸运成像中选择最接近爆发开始时可以找到的最清晰的帧。
为了更详细地评估我们的系统的对齐和合并方法，证明其与现有技术的连拍融合相比的稳健性[Liu et al。 2014; Dabov等人2007年a; Adobe Inc. 2016; Heide等人2014]，请参阅附录。
失败情况。尽管总体图像质量良好，但我们的系统在极端情况下确实失败。我们设计了它在这些情况下优雅地退化，但我们希望它更好。其中一些情况如图11所示。
图11：我们处理不好的情况。 上图：在这个非常高的动态场景中，我们优先曝光面部和建筑物内部，从而在明亮的开放门道上丢失细节。 中：在快速运动的低光场景中，我们会将曝光时间缩短，产生过多噪音以避免运动模糊。 机身：由于我们使用了曝光融合，高对比度的场景可以呈现轻微的中频晕（天空中的深蓝色斑点）。
我们最严重的失败模式是，在非常低的光照水平下，ISP的自动对焦和白平衡估计开始失败。尽管合并和对齐可能仍然有效，但照片可能会失焦或产生偏色。图1中可以看到轻微的模型。
性能。为了使我们的流水线足够快以部署在移动设备上，我们选择了算法来提高计算效率。这意味着要避免非本地通信和数据依赖性，避免并行化，消耗尽可能少的内存，并尽可能采用定点算法。这些同样的担忧妨碍了使用具有全局迭代的算法（例如，FlexISP [Heide等人，2014]），大的或动态的空间支持（例如，BM3D [Dabov等人2007b]）或昂贵的色调映射（例如局部拉普拉斯滤波器[Aubry等2014]）。
我们的系统已在具有12-13 Mpix传感器的设备上发货，我们在该设备上捕获最多8帧的突发数据。因此，我们可能需要存储和处理每张输出照片104万像素。虽然我们选择了效率算法，但处理这么多数据仍然需要高度优化的实现。我们的大部分代码都是用Halide编写的[Ragan-Kelley et al。 2012]，使我们能够更容易地融合流水线阶段，并使用SIMD和线程并行。另外，由于我们计算了许多用于对齐和合并的小2D实数DFT，我们在Halide中实现了自己的FFT。对于我们管道中的小型DFT，这种实现比基于ARM的移动电话上的FFTW [Frigo和Johnson 2005]快5倍。
总结一下，在Qualcomm Snapdragon 810不受热调节的情况下，产生输出照片所需的时间范围为2.5至4秒，具体取决于连拍中的帧数。对于4秒钟的低光照，这种情况分解为1秒捕获帧，500毫秒对齐，1200毫秒合并，1600毫秒完成。对于日光拍摄
2.5秒，我们测量100毫秒的捕获，250毫秒的对齐，合并为580毫秒，完成为1600毫秒。
8结论
在本文中，我们描述了一种捕获曝光不足帧的系统，对齐和合并这些帧以产生高比特深度的单个中间图像，并对该图像进行色调映射以产生高分辨率照片。我们的结果比传统成像管道生成的单次曝光照片具有更好的图像质量，特别是在高动态范围或低光照场景中，并且几乎不会显示令人反感的伪影。该系统部署在几款大规模生产的手机中，在Nexus 6,5X和6P中作为“HDR +”销售。使用我们系统的消费者不知道他们在每次快门按下时都会拍摄帧，或者他们的最终照片是使用计算摄影从多个图像生成的。
在技术论文中很难证明我们对超级图像质量的一般要求，或覆盖我们的系统强有力处理的角落案例的范围。然而，我们的系统在新闻界得到了积极的评价，在独立评估[DxO Inc. 2015]中获得的评分高于大多数竞争商业系统，并且每周消费者捕获的数百万张照片中，我们没有看到灾难性的结果。
为了让其他人可以判断我们的图像质量并改进我们的算法，我们创建了DNG格式的数千个原始图像阵列的存档[Google Inc. 2016b]。对于每个突发，我们都包含我们的合并原始输出和最终的JPEG输出。 EXIF标签和附加文件描述了我们的摄像机参数，噪声模型和用于生成结果的其他元数据。
局限性和未来的工作。我们系统的最大缺点是，用户按下快门后，在爆发开始并捕获参考帧之前存在明显的滞后。由于此框架设置了照片的构图，因此可能很难在动作场景中捕捉正确的时刻。这种滞后的部分原因是我们的自动曝光算法，有些针对Camera2的软件结构，另一些针对我们使用的幸运成像，它根据选择哪个帧作为参考增加了可变延迟。
为了避免快门时滞，许多手机采用零快门时滞（ZSL），其中相机连续捕捉全分辨率帧，将它们存储在循环缓冲区中，并通过从该缓冲区中选择一个图像来完成并存储快门按钮。由于焦点，曝光和白平衡在目标期间不断变化，处理ZSL将需要放松我们对恒定曝光突发的假设。这是未来工作的主题。我们系统的另一个限制是，计算输出照片需要几秒钟，并且占用大量内存直到完成。如果用户快速连续按下快门几次，我们可以很容易地耗尽内存，导致相机应用程序失速。可编程硬件可能会解决这个问题，但是将这些硬件并入批量生产的移动设备并不容易。
最后，我们的ISP生成的取景器和软件生成的照片之间的差异产生了不理想的用户体验。在极端情况下，用户可能会放弃拍摄场景，因为它在取景器中看起来很差，实际上，我们的软件会生成该场景的可用照片。可编程硬件也可以解决这个问题。
致谢
如果没有与Android相机团队的密切合作，我们的系统与Google相机应用的集成将不可能实现。我们感谢他们在HDR +上的产品和工程贡献，以及他们对图像质量的宝贵反馈。特别感谢[Liu et al。 2014]和[Heide et al。 2014]为他们的实验比较提供帮助。我们也感谢Peyman Milanfar进行有益的讨论，并感谢匿名评论者对论文的反馈意见。