Android 11 Camera Image Test Suite 版本資訊

本頁概述 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 設計
  4F.、臺灣新北市新莊區福營路 163 號
  twmyway.com
  sales@myway.tw
  +886-2-29089060

整合式製造方法

rev1 標準視野 (RFoV) ITS-in-a-box 測試外殼經過重新設計，採用寬視野 (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 級別 30 的 test_tonemap_curve 測試以外，所有這些測試都使用第一個 API 級別 29。

根據變更進行測試

下表中的測試已在 Android 11 中更新。變更內容會列於「變更說明」欄。

新測試

下表中的測試已在 Android 11 中啟用。表格中列出各項測試，並在後續章節中詳細說明。

scene0/test_vibration_restriction

這項測試不需要特定情境，但測試中的裝置 (DUT) 必須放在或安裝在堅硬的表面上。包括安裝在 ITS-in-a-box 測試外殼上。

斷言

• 使用相機時未震動

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 色度矩陣]。

在許多裝置 (包括將兩個矩陣分隔為 JPEG 檔案中個別 DQT 區段的手機) 中，亮度矩陣標記的 0 和色度標記的 1 似乎都一致。與色彩矩陣相比，亮度矩陣的值通常會更多樣化，因為人眼對亮度的敏感度高於色彩，而 JPEG 圖片會考量這一點。

下方顯示擷取出的亮度和色域矩陣樣本，以瞭解 Pixel 4 後置鏡頭透過 ITS 測試腳架擷取場景 2_a 的品質因素 (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

我們新增了兩個臉部偵測場景，可提高臉部偵測演算法檢查的臉部多樣性。因此，透過重複測試多部攝影機，最有挑戰性的臉應在情境 2_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

方法

由於已建立的場景不具備足夠小的功能可放大 (場景 [1, 2, 4])，或是場景包含許多不易辨識的物件，導致功能擷取作業變得複雜 (場景 3)，因此必須使用新的場景來測試 android.control.zoomRatioRange。

圖 8 顯示新場景，其中包含規則的圓形陣列。圓形陣列會放寬 DUT/圖表中心的要求，並允許在擷取圖片中央附近一律顯示圓形。在這個場景中，9x5 個帶有黑色邊框的圓形陣列會覆蓋整個平板電腦。右上角的一個圓圈會改為方塊，用來顯示方向。圓形大小具有約 7,500 像素 (radius=50pixels) 的面積，用來拍攝 4000x3000 感應器的視野 (FoV) 約為 80 度。

圖 8：test_zoom 場景

圖 9.Pixel 4 cam[0] zoom = [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 倍)。

斷言

• 在每個縮放設定中找到至少一個圓圈。
• 測試的裝置數量是 android.control.zoomRatioRange 的 10 倍或最多 10 倍。
• 圓形半徑可隨變焦 (距離預期為 RTOL 10%)。
• 圓形中心與縮放中心的偏移量 (與預期值相差 10%)。
• 已達足夠的縮放等級 (2x)。

增加 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 密碼解碼器