Android 11 Camera Image Test Suite 版本資訊

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

本頁面概要說明 Android 11 中 Camera Image Test Suite (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., 臺灣新北市新莊區福營路 163 號
  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 級別標記。除了 test_tonemap_curve 測試使用第一個 API 級別 30 以外，所有測試都使用第一個 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 時，從中擷取的 luma 和色彩矩陣範例，品質因子分別為 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 後置鏡頭 luma/chroma 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 個帶有黑色邊框的圓形陣列會覆蓋整個平板電腦。右上角的一個圓圈會改為方塊，用來顯示方向。圓圈大小的功能在 4000x3000 感應器中，其視野 (FoV) 約為 80 度，面積約為 7500 像素 (radius=50pixels)。

圖 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 倍)。

斷言

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

增加 LIMITED 相機測試

在 Android 11 中，下表中的測試會測試 LIMITED 相機。除了新測試外，scene4/test_aspect_ratio_and_crop 測試也已更新，可測試 LIMITED 裝置的初始 API 級別為 30 以上。

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