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 design
  4F., 臺灣新北市新莊區福營路 163 號
  twmyway.com
  sales@myway.tw
  +886-2-29089060

統一製造方法

rev1 一般視野 (RFoV) ITS-in-a-box 測試外殼經過重新設計，採用廣角視野 (WFoV) 盒裝和感應器融合盒裝測試外殼使用的製造方法。功能完全相同，為求簡化，設計稱為 rev1a。重新設計後，製造商只要儲備單一類型的塑膠，就能製造所有測試外殼。此外，平板電腦支架和燈架也經過重新設計，可支援更多不同型號的平板電腦和 LED 燈條。

如要下載最新說明和機械圖，請參閱 RFoV box (rev1a) 和 WFoV box (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 box (rev1a)」和「WFoV box (rev2.9)」。

全新感應器融合控制器

感應器融合控制器硬體經過重新設計，可提升製造能力。新控制器以 Arduino 為基礎，並採用自訂的 路由板擴充板，安裝在 Arduino 上方。圖 1 顯示護罩，圖 2 則顯示外殼的機械圖。新控制器由單一 5V 電源供電，可直接為馬達供電。電子元件完全透過 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 測試可能會失敗，但會以 PASS 形式列入 CTS 驗證器報告。升級裝置也須通過 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 測試外殼上。

Asserts

• 使用相機時不會震動

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 測試架上擷取 scene2_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 品質比較

Asserts

• 對於 [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

Asserts

• num_faces == 3

scene2_e/test_continuous_picture

方法

test_continuous_picture 測試會使用 scene2_e，但可透過任何臉部場景啟用。在這項測試中，系統會先使用擷取要求設定 android.control.afMode = 4 (CONTINUOUS_PICTURE)，擷取 50 個 VGA 解析度的影格。

3A 系統預計會在擷取 50 個影格後完成調整。

Asserts

• 3A 在擷取結束時處於聚合狀態。

scene_change/test_scene_change

方法

系統會啟用新測試，確認 android.control.afSceneChange 旗標是否已透過場景變更進行判斷。場景變化：使用顯示臉部場景的平板電腦，然後開啟及關閉平板電腦，即可建立場景變化。場景會重複使用 scene2_e，但由於需要平板電腦控制項，因此位於不同的場景。

此外，如要手動測試，只要在攝影機前揮手，即可變更場景。

圖 7 顯示測試的時序圖。系統會根據先前擷取的事件結果，調整螢幕關閉和擷取之間的時間。

圖 7. test_scene_change 的時序圖

排班條件：

• 如有場景變更和 afSceneChange == 1，測試會傳回 PASS。
• 如有場景變化，場景變化會提前 5 個影格，讓 afSceneChange 有更多時間進行判斷。afSceneChange == 0
• 如果沒有場景變更和 afSceneChange == 1，測試會傳回 FAIL。
• 如果沒有場景變更和 afSceneChange == 0，場景變更會提前 30 個影格，以便在擷取畫面中取得場景變更。

Asserts

• 切換畫面 (場景)。
• afSceneChange 旗標位於 [0, 1] 之間。
• 如果沒有場景變化，3A 會收斂 (功能與 test_continuous_picture 相同)。
• 如果值為 afSceneChange == 1，則必須變更場景中的亮度。
• PASS，最多嘗試六次，並根據先前的結果調整時間。

scene6/test_zoom

方法

測試 android.control.zoomRatioRange 時需要使用新場景，因為現有場景不是沒有夠小的特徵可供放大 (場景 [1、2、4])，就是有許多不易辨識的物件，導致特徵擷取作業變得複雜 (場景 3)。

圖 8 顯示新的場景，其中包含圓圈的規則陣列。圓圈陣列可放寬 DUT/圖表置中要求，並確保圓圈一律位於擷取影像的中心附近。在這個場景中，9x5 的圓圈陣列帶有黑色邊框，覆蓋整個平板電腦。右上角的圓圈會變成正方形，表示方向。圓圈大小的特徵區域約為 7500 像素 (radius=50pixels)，適用於以約 80 度的視野 (FoV) 拍攝的 4000x3000 感應器。

圖 8. test_zoom 場景

圖 9.Pixel 4 cam[0] zoom = [1, 3.33, 5.67, 8] images with found circle

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

Asserts

• 每個縮放設定至少會找到一個圓圈。
• 系統會測試 10 倍或最多 android.control.zoomRatioRange。
• 圓形半徑會隨著縮放比例調整 (與預期值相差 10% 的 RTOL)。
• 圓圈中心偏離中心，並隨縮放比例調整 (與預期值相差 10% 的 RTOL)。
• 達到足夠的縮放等級 (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 密碼解碼環