本頁面由 Cloud Translation API 翻譯而成。

Android 11 相機影像測試套件發行說明

本頁總結了 Android 11 中相機影像測試套件 (ITS)的變更。這些變更分為以下幾類：

硬體變化
第一個 API 等級強制測試
測試照明已驗證
場景名稱更改
測試更改和添加
增加有限的相機測試

硬體變化

Android 11 引入了多項硬體更改，以降低成本並提高可用性。這些變化分為以下幾類：

附加製造商
統一製造方法
增加平板電腦選項
減少片劑開口
新型感測器融合控制器

附加製造商

除了我們現有的供應商 MYWAY 設計之外，Rahi Systems 有資格生產 ITS 測試外殼。合格供應商的公司資訊如下：

拉希系統公司
48303 弗里蒙特大道，弗里蒙特 CA 94538，美國
rahisystems.com/products/android-device-testing-equipment/
androidpartner@rahisystems.com
+1-510-319-3802
我的方式設計
台灣新北市新莊區富英路163號4樓
twmyway.com
sales@myway.tw
+886-2-29089060

統一製造方法

rev1 常規視野 (RFoV) 盒裝 ITS測試外殼經過重新設計，以使用寬視野 (WFoV) 盒和感測器融合盒測試外殼所使用的製造方法。功能是相同的，為簡單起見，設計稱為rev1a 。重新設計允許製造商儲存單一類型的塑膠來製造所有測試外殼。此外，平板電腦支架和燈座經過重新設計，可應對平板電腦和 LED 燈條的更大變化。

若要下載最新的說明和機械圖紙，請參閱RFoV box (rev1a)和WFoV box (rev2.9) 。

增加平板電腦選項

三星 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 連接器進行控制。獨立的電源允許控制電子設備和伺服馬達之間完全隔離。此外，單一控制器最多可以控制六個伺服馬達。

Arduino 的頂視圖

圖 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 的裝置MANDATED test_channel_saturation測試。
在 Android 10 中，所有裝置都MANDATED進行test_channel_saturation測試。

驗證場景照明

在 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

場景	測試次數	Pixel 4 運轉時間（分：秒）
0	11	1:12
1_1	22 號	5:12
1_2	13	5:20
2_a	5	3:22
2_b	1	0:24
2_c	1	0:24
3	6	2:04
4	2	2:46

測試變更

測試更新為使用第一個 API 級別

在 Android 11 中，下表中的測試已更新為使用第一個 API 等級標誌。所有這些測試都使用第一個 API 等級 29，但test_tonemap_curve測試除外，該測試使用第一個 API 等級 30。

場景	測試名稱	第一 API 級別	描述
0	`test_tonemap_curve`	30	確保管道具有具有線性色調圖和理想影像輸入的正確色彩輸出（依賴`test_test_patterns` ）。
1	`test_ae_precapture_trigger`	29	使用預捕獲觸發器時測試 AE 狀態機。確保在停用 AE 的情況下預先擷取觸發器沒有效果。
1	`test_channel_saturation`	29	確保 RGB 通道飽和到相似的值，以消除飽和區域的色調。
2_a/b/c	`test_num_faces`	29	增加臉部場景中的年齡多樣性。

進行更改測試

下表中的測試已在 Android 11 中更新。變更描述在變更說明列中。

場景	測試名稱	第一 API 級別	變更說明
1	`test_burst_sameness_manual`	30	將公差降低至 2%。
4	`test_aspect_ratio_and_crop`	30	更改為在有限的設備上運行。
4	`test_multi_camera_alignment`	30	如果不支援多相機捕獲，則單獨瀏覽相機。重新設計相機選擇邏輯以適應三相機和四相機系統，並跳過單聲道、僅深度和紅外線相機。

新測試

下表中的測試在 Android 11 中啟用。表中總結了這些測試，並在以下部分中提供了詳細說明。

場景	測試名稱	第一 API 級別	描述
0	`test_vibration_restrictions`	30	確保影像擷取期間不會啟動警報和振動。
2_a	`test_jpeg_quality`	30	測試量化表是否會降低壓縮率以提高 JPEG 品質。
2_d/2_e	`test_num_faces`	30	增加臉部年齡多樣性。
2_e	`test_continuous_picture`	30	確保 3A 穩定在`android.control.afAvailableModes = CONTINUOUS_PICTURE.`
改變	`test_scene_change`	31	`android.control.afSceneChange`在場景更改時斷言。
6	`test_zoom`	30	測試`android.control.zoomRatioRange` 。

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

對於許多設備（包括將兩個矩陣分成 JPEG 檔案中單獨的 DQT 部分的手機），亮度矩陣標記的0和色度標記的1看起來是一致的。與色度矩陣相比，亮度矩陣往往具有更多種類的值，因為人眼對亮度比色度更敏感，而 JPEG 影像考慮到了這一點。

下面顯示了使用 ITS 測試裝備捕捉 scene2_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 矩陣平均值）會降低。

Pixel 4 平均矩陣值

圖 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 所示。

場景2_d

圖 5. scene2_d

場景2_e

圖 6. scene2_e

斷言

num_faces == 3

scene2_e/test_連續_圖片

方法

test_continuous_picture測試使用 scene2_e，但可以在任何面部場景中啟用它。在此測試中，擷取請求首先設定android.control.afMode = 4 (CONTINUOUS_PICTURE)來擷取 50 幀 VGA 解析度。

3A 系統預計在 50 幀捕獲結束時穩定下來。

斷言

圖3A在捕捉結束時處於收斂狀態。

場景更改/測試場景更改

方法

啟用了一個新測試來測試android.control.afSceneChange標誌是否在場景更改時斷言。場景變化利用平板電腦顯示臉部場景，然後開啟和關閉平板電腦以創建場景變化。此場景重複使用了 scene2_e，但由於需要平板電腦控制，因此位於單獨的場景中。

此外，對於手動測試，可以透過在相機前揮動手來完成場景切換。

圖 7 顯示了測試的時序圖。螢幕關閉和捕獲之間的時間根據先前捕獲的事件結果進行調整。

test_scene_change 的時序圖

圖 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 ，但時間根據先前的結果進行了更改。

場景6/test_zoom

方法

需要一個新場景來測試android.control.zoomRatioRange ，因為已建立的場景要么沒有足夠小的特徵可以放大（場景 [1, 2, 4]），要么場景中有許多不易識別的對象，使特徵提取複雜化（場景3）。

圖 8 顯示了帶有規則圓圈陣列的新場景。圓陣列放寬了對 DUT/圖表居中的要求，並允許圓始終位於捕捉影像的中心附近。在此場景中，帶有黑色邊框的 9x5 圓圈陣列覆蓋了整個平板電腦。右上角的一個圓圈被替換為一個正方形以顯示方向。對於以約 80 度的視場 (FoV) 捕獲的 4000x3000 感測器，圓圈大小具有面積約為 7500 像素（ radius=50pixels ）的特徵。

測試縮放場景

圖 8. test_zoom 場景

Pixel 4 發現圓圈

圖 9. Pixel 4 cam[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 倍）。

斷言

在每個縮放設定下至少發現一個圓圈。
測試了android.control.zoomRatioRange的 10 倍或最大值。
圓半徑隨縮放而縮放（RTOL 比預期高 10%）。
圓心與中心的偏移量隨著縮放而縮放（RTOL 與預期相差 10%）。
已達到足夠的縮放等級 (2x)。

增加有限的相機測試

在 Android 11 中，下表中的測試測試了LIMITED相機。除了新測試之外，還更新了scene4/test_aspect_ratio_and_crop測試，以支援對第一個 API 等級為 30 或更高等級的LIMITED設備進行測試。

場景	測試名稱
0	`test_vibration_restrictions`
2_a	`test_jpeg_quality`
2_d/2_e	`test_num_faces`
4	`test_aspect_ratio_and_crop`
6	`test_zoom`

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