Android 11 相机图像测试套件发行说明

使用收藏集保持井井有条 根据您的偏好保存内容并进行分类。

本页面总结了 Android 11 中相机图像测试套件 (ITS) 的变更。这些变更分为以下几类：

• 硬件变更
• 强制要求的首个 API 级别测试
• 经过验证的测试照明
• 场景名称变更
• 测试变更和新增内容
• 增加的 LIMITED 相机测试

硬件变更

Android 11 引入了多项硬件变更，旨在降低成本并提高可用性。这些变更分为以下几类：

• 新增制造商
• 统一的制造方法
• 增加平板电脑选项
• 减小平电脑开口
• 新型传感器融合控制器

新增制造商

除现有供应商 MYWAY design 外，Rahi Systems 也获得了生产 ITS 测试箱的资质。资质供应商的公司信息如下：

• Rahi Systems Inc.
  48303 Fremont Blvd, Fremont CA 94538, USA
  rahisystems.com/products/android-device-testing-equipment/
  androidpartner@rahisystems.com
  +1-510-319-3802

• MYWAY design
  4F., No. 163, Fu-Ying Road, XinZhuang District, New Taipei City, Taiwan
  twmyway.com
  sales@myway.tw
  +886-2-29089060

统一的制造方法

rev1 常规视野范围 (RFoV) 箱式 ITS 测试箱经过重新设计，采用了 广角视野范围 (WFoV) 箱 和 传感器融合箱 测试箱中使用的制造方法。功能完全相同，为简单起见，该设计称为rev1a。重新设计后，制造商只需备一种塑料即可制造所有测试箱。此外，平板电脑支架和灯架也经过重新设计，可适应平板电脑和 LED 灯条的更大差异。

要下载最新的描述和机械图纸，请参阅 RFoV 箱（rev1a）和 WFoV 箱（rev2.9）。

增加平板电脑选项

推荐的平板电脑列表中新增了 Samsung Galaxy Tab A 10.1 和 Chuwi Hi9 Air 10.1 等平板电脑。重要的是，平板电脑不能使用脉冲宽度调制 (PWM) 来调节屏幕亮度，以消除拍摄图像中的条带。

有关推荐平板电脑的最新信息，请参阅平板电脑要求。

减小平电脑开口

为了允许使用 Galaxy Tab A 10.1，RFoV (rev1a) 和 WFoV (rev2) 测试箱的平板电脑开口高度略微减小。反映这些变更的修订版本为 rev1a.1 和 rev2.9。有关这些图纸，请参阅 RFoV 箱（rev1a）和 WFoV 箱（rev2.9）。

新型传感器融合控制器

传感器融合控制器的硬件经过重新设计，以提高可制造性。新控制器基于 Arduino，带有一个自定义布线板屏蔽罩，该屏蔽罩安装在 Arduino 的顶部。图 1 显示了屏蔽罩，图 2 显示了箱体的机械图纸。新控制器由单个 5 V 电源供电，该电源直接为电机供电。电子元件完全通过 USB 连接器控制。单独的电源可在控制电子元件和伺服电机之间实现完全隔离。此外，单个控制器最多可控制六个伺服电机。

图 1. Arduino 屏蔽罩的顶视图

图 2. 箱体设计

Android 11 向后兼容现有控制器。要使用基于 Arduino 的控制器调用测试，请使用

python tools/run_all_tests.py device=# camera=# rot_rig=arduino:1 scenes=sensor_fusion

首个 API 级别

在 Android 10 中，ITS 测试被指定为 MANDATED 和 NOT_YET_MANDATED。要作为 Android 10 设备启动，所有 MANDATED 测试都必须通过。NOT_YET_MANDATED 测试可能会失败，但在 CTS 验证程序报告中会被制表为 PASS。MANDATED 测试要求也适用于升级后的设备。升级后的设备必须通过所有 MANDATED 测试的要求导致测试成为 MANDATED 测试的时间被延迟，因为旧设备也必须通过这些测试。

在 Android 11 中，MANDATED 测试由手机属性中的首个 API 级别标记控制。对于升级到 Android 11 的设备，测试以 NOT_YET_MANDATED 测试形式运行，这意味着测试可能会失败，但在 CtsVerifier.apk 中会被制表为 PASS。

例如

• 在 Android 11 中，对于首个 API 级别大于 29 的设备，test_channel_saturation 测试为 MANDATED。
• 在 Android 10 中，对于所有设备，test_channel_saturation 测试均为 MANDATED。

验证场景照明

在 Android 11 中，场景照明通过分析场景角落的亮度进行验证。所有手动场景都会验证照明，而基于平板电脑的场景会验证 RFoV 测试装置中的 RFoV 相机和 WFoV 测试装置中的 WFoV 相机。如果照明水平不足，则会报告错误，且测试失败。

场景名称变更

在 Android 10 中，场景 1 占了大部分测试，以及总测试时间的很大一部分。如果场景 1 中的任何测试失败，则必须重新运行整个场景。按照设计，重新运行整个场景会降低边缘测试的通过率。在 Android 11 中，通过将场景 1 分为两个场景（scene1_1 和 scene1_2）来缩短重新运行时间。

下表显示了 Pixel 4 后置相机在不同场景下的测试时间。测试数量的拆分是为了均衡测试时间，而不是均衡测试数量。

此外，还进行了名称清理。场景 2 使用字母拆分，场景 1 使用数字拆分。不同扩展名的命名法为：

• 使用相同图表但测试不同的场景：*_1,2,3
• 使用不同图表但测试相同的场景：*_a,b,c

测试变更

已更新测试以使用首个 API 级别

在 Android 11 中，下表中的测试已更新为使用首个 API 级别标记。所有这些测试都使用首个 API 级别 29，但 test_tonemap_curve 测试除外，该测试使用首个 API 级别 30。

进行变更的测试

下表中的测试在 Android 11 中进行了更新。“变更说明”列中描述了这些变更。

新测试

下表中的测试在 Android 11 中启用。该表总结了这些测试，以下部分提供了详细说明。

scene0/test_vibration_restriction

此测试不需要特定场景，但待测设备 (DUT) 必须放置或安装在坚硬的表面上。这包括安装在箱式 ITS 测试箱上。

断言

• 相机使用期间无振动

scene2_a/test_jpeg_quality

方法

JPEG 文件的不同部分由 2 字节标记定义。有关详情，请参阅 JPEG。

该测试从 JPEG 拍摄中提取量化矩阵。JPEG 拍摄中量化矩阵的标记是序列 [255, 219]。找到标记后，接下来的两个列表项是大小。JPEG DQT 大小标记通常为 [0, 132] = 256*0+132 = 132，这说明了 JPEG 拍摄中 DQT 数据的大小。嵌入式数据的形式为：[255, 219, 0, 132, 0（亮度标记）、8x8 亮度矩阵、1（色度标记）、8x8 色度矩阵]。

亮度矩阵标记的 0 和色度矩阵标记的 1 对于许多设备（包括将两个矩阵分成 JPEG 文件中单独的 DQT 部分的手机）来说似乎是一致的。与色度矩阵相比，亮度矩阵往往具有更多种类的数值，因为人眼对亮度比对色度更敏感，而 JPEG 图像会考虑到这一点。

下面显示了在 ITS 测试装置中使用场景 2_a 拍摄的 Pixel 4 后置相机在质量因子为 85 和 25 时的提取亮度矩阵和色度矩阵示例。对于较低的质量设置，矩阵值会大幅增加（表示压缩率增加）。仅当应用 debug=True 标记时，这些矩阵才会与脚本一起打印。请注意，与色度矩阵相比，亮度矩阵中的条目变化更大。

    luma matrix (quality = 85)    chroma matrix (quality = 85)

    [[ 5  3  4  4  4  3  5  4]    [[ 5  5  5  7  6  7 14  8]
     [ 4  4  5  5  5  6  7 12]     [ 8 14 30 20 17 20 30 30]
     [ 8  7  7  7  7 15 11 11]     [30 30 30 30 30 30 30 30]
     [ 9 12 17 15 18 18 17 15]     [30 30 30 30 30 30 30 30]
     [17 17 19 22 28 23 19 20]     [30 30 30 30 30 30 30 30]
     [26 21 17 17 24 33 24 26]     [30 30 30 30 30 30 30 30]
     [29 29 31 31 31 19 23 34]     [30 30 30 30 30 30 30 30]
     [36 34 30 36 28 30 31 30]]     [30 30 30 30 30 30 30 30]]

    luma matrix (quality = 25)            chroma matrix (quality = 25)

    [[ 32  22  24  28  24  20  32  28]    [[ 34  36  36  48  42  48  94  52]
     [ 26  28  36  34  32  38  48  80]     [ 52  94 198 132 112 132 198 198]
     [ 52  48  44  44  48  98  70  74]     [198 198 198 198 198 198 198 198]
     [ 58  80 116 102 122 120 114 102]     [198 198 198 198 198 198 198 198]
     [112 110 128 144 184 156 128 136]     [198 198 198 198 198 198 198 198]
     [174 138 110 112 160 218 162 174]     [198 198 198 198 198 198 198 198]
     [190 196 206 208 206 124 154 226]     [198 198 198 198 198 198 198 198]
     [242 224 200 240 184 202 206 198]]     [198 198 198 198 198 198 198 198]]

图 3 显示了 Pixel 4 后置相机的平均矩阵值与 JPEG 质量的关系。随着 JPEG 质量的提高，压缩率水平（亮度/色度 DQT 矩阵平均值）会降低。

图 3. Pixel 4 后置相机亮度/色度 DQT 矩阵平均值与 JPEG 质量的关系

断言

• 对于 [25、45、65、86]，质量每提高 20，量化矩阵平均值降低 20%。
• DQT 矩阵有效负载是平方数。

图 4 显示了一个测试失败的手机示例。请注意，对于极低质量的图像（jpeg.quality < 50），量化矩阵中的压缩率没有提高。

图 4. 失败的测试示例

scene2_d/e test_num_faces

新增了两个人脸检测场景，以增加人脸检测算法检查的人脸多样性。通过对许多相机进行重复测试，预计最具挑战性的人脸是 scene2_d 中最左侧的人脸。特别是，模特戴着帽子和胡须，这在人脸场景中是新的。新场景如图 5 和图 6 所示。

图 5. scene2_d

图 6. scene2_e

断言

• num_faces == 3

scene2_e/test_continuous_picture

方法

test_continuous_picture 测试使用了 scene2_e，但可以使用任何人脸场景启用。在此测试中，使用捕获请求（首先设置 android.control.afMode = 4 (CONTINUOUS_PICTURE)）捕获 50 帧 VGA 分辨率的图像。

预计 3A 系统会在 50 帧捕获结束时稳定下来。

断言

• 3A 在捕获结束时处于收敛状态。

scene_change/test_scene_change

方法

启用了一项新测试，以测试场景变更时是否断言了 android.control.afSceneChange 标记。场景变更利用平板电脑显示人脸场景，然后打开和关闭平板电脑以创建场景变更。该场景重复使用了 scene2_e，但由于需要平板电脑控制，因此位于单独的场景中。

此外，对于手动测试，可以通过在相机前挥手来完成场景变更。

图 7 显示了测试的时序图。屏幕关闭和捕获之间的时序会根据先前捕获的事件结果进行调整。

图 7. test_scene_change 的时序图

偏移条件

• 如果发生场景变更且 afSceneChange == 1，则测试返回 PASS。
• 如果发生场景变更且 afSceneChange == 0，则场景变更会提前 5 帧，以便为 afSceneChange 断言留出更多时间。
• 如果没有发生场景变更且 afSceneChange == 1，则测试返回 FAIL。
• 如果没有发生场景变更且 afSceneChange == 0，则场景变更会提前 30 帧，以便在捕获中获得场景变更。

断言

• 屏幕（场景）切换。
• afSceneChange 标记在 [0, 1] 中。
• 如果没有场景变更，则 3A 会收敛（功能上与 test_continuous_picture 相同）。
• 如果 afSceneChange == 1，则场景中的亮度必须发生变化。
• 在六次尝试内返回 PASS，时序根据先前的结果进行更改。

scene6/test_zoom

方法

测试 android.control.zoomRatioRange 需要一个新场景，因为已建立的场景要么没有小到足以放大的特征（场景 [1、2、4]），要么场景中有许多不易识别的对象，这使得特征提取变得复杂（场景 3）。

图 8 显示了新场景，其中包含规则的圆形阵列。圆形阵列放宽了对 DUT/图表居中的要求，并允许始终在拍摄图像中心附近放置一个圆形。在此场景中，一个带有黑色边框的 9x5 圆形阵列覆盖了整个平板电脑。右上角的一个圆形被正方形替换，以显示方向。对于以约 80 度视场 (FoV) 拍摄的 4000x3000 传感器，圆形尺寸具有约 7500 像素的特征（radius=50pixels）。

图 8. test_zoom 场景

图 9. 像素 4 相机 [0] 变焦 = [1、3.33、5.67、8] 图像，其中包含找到的圆形

图 9 显示了 Pixel 4 后置相机的拍摄图像，因为变焦从 1 倍增加到 8 倍，分为四个步骤。拍摄这组图像时，除了使用带有两个开口的手机测试孔径以支持前置和后置相机的测试外，没有特别注意居中。预计会存在中心偏移，并且观察到图表平板电脑略微偏离中心。此外，该图表似乎足以测试高于 8 倍的变焦比率。

查找圆形

该测试包括一个使用 findContours 的 find_circle() 方法，该方法查找所有轮廓，并通过测试以下内容将轮廓搜索范围缩小到所需的圆形：

• 轮廓的面积必须大于 10 像素。
• 轮廓必须具有 NUM_PTS >= 15。
• 轮廓必须具有黑色中心。
• 轮廓必须类似于圆形，即它们的面积接近轮廓的 pi*r2 面积。

测试范围

android.control.zoomRatioRange 分为 10 个步骤。

• [1, 7] 测试 [1, 1.67, 2.33, 3, 3.67, 4.33, 5, 5.67, 6.33, 7]

如果找到的圆形接触到图像的边界，则停止变焦。检查以确保在测试中达到足够的变焦级别 (10 倍)。

断言

• 在每个变焦设置下至少找到一个圆形。
• 测试 10 倍或 android.control.zoomRatioRange 的最大值。
• 圆形半径随变焦缩放（与预期值的相对容差为 10%）。
• 圆形中心相对于中心的偏移随变焦缩放（与预期值的相对容差为 10%）。
• 达到足够的变焦级别（2 倍）。

增加的 LIMITED 相机测试

在 Android 11 中，下表中的测试用于测试 LIMITED 相机。除了新测试外，scene4/test_aspect_ratio_and_crop 测试已更新，以支持对首个 API 级别为 30 或更高版本的 LIMITED 设备进行测试。

图 10 显示了 Android 11 ITS 秘密解码环。秘密解码环显示了各个测试的门控测试设置。门控以颜色编码，以便于查看。主要的门控项为：

• MANUAL_SENSOR
• READ_3A *需要 MANUAL SENSOR
• COMPUTE_TARGET_EXPOSURES *需要 MANUAL SENSOR
• PER_FRAME_CONTROL
• RAW
• SENSORS *REALTIME
• MULTI_CAMERA

MANUAL SENSOR、READ_3A、COMPUTE_TARGET_EXPOSURES 和 PER_FRAME_CONTROL 控制着大多数测试。此外，以浅绿色突出显示了为 LIMITED 设备启用的测试。

图 10. Android 11 秘密解码环