Ghi chú phát hành Bộ kiểm tra hình ảnh máy ảnh Android 11

Trang này tóm tắt các thay đổi đối với Bộ kiểm tra hình ảnh máy ảnh (ITS) trong Android 11. Các thay đổi thuộc các danh mục sau:

• Thay đổi phần cứng
• Các bài kiểm tra BẮT BUỘC cấp độ API đầu tiên
• Kiểm tra ánh sáng đã được xác nhận
• Thay đổi tên cảnh
• Kiểm tra các thay đổi và bổ sung
• Tăng cường thử nghiệm máy ảnh GIỚI HẠN

Thay đổi phần cứng

Android 11 giới thiệu một số thay đổi về phần cứng nhằm giảm chi phí và tăng tính khả dụng. Những thay đổi này thuộc các loại sau:

• Nhà sản xuất bổ sung
• Phương pháp sản xuất thống nhất
• Tùy chọn máy tính bảng tăng lên
• Giảm độ mở của máy tính bảng
• Bộ điều khiển tổng hợp cảm biến mới

Nhà sản xuất bổ sung

Rahi Systems có đủ điều kiện để sản xuất các thùng thử nghiệm ITS ngoài nhà cung cấp hiện tại của chúng tôi, thiết kế MYWAY. Thông tin công ty dành cho các nhà cung cấp đủ điều kiện như sau:

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

• thiết kế MYWAY
  4F., Số 163, Đường Fu-Ying, Quận Tân Trang, Thành phố Đài Bắc mới, Đài Loan
  twmyway.com
  sales@myway.tw
  +886-2-29089060

Phương pháp sản xuất thống nhất

Vỏ thử nghiệm ITS-trong-hộp tầm nhìn thông thường (RFoV) rev1 được thiết kế lại để sử dụng các phương pháp sản xuất đang được sử dụng bởi hộp thử nghiệm trường nhìn rộng (WFoV) và vỏ thử nghiệm hộp tổng hợp cảm biến . Chức năng giống hệt nhau và để đơn giản, thiết kế được gọi là rev1a . Thiết kế lại cho phép các nhà sản xuất dự trữ một loại nhựa duy nhất để sản xuất tất cả các thùng thử nghiệm. Ngoài ra, giá đỡ máy tính bảng và giá đỡ đèn được thiết kế lại để xử lý các biến thể lớn hơn của máy tính bảng và thanh đèn LED.

Để tải xuống các mô tả và bản vẽ cơ khí mới nhất, hãy xem hộp RFoV (rev1a) và hộp WFOV (rev2.9) .

Tùy chọn máy tính bảng tăng lên

Máy tính bảng bao gồm Samsung Galaxy Tab A 10.1 và Chuwi Hi9 Air 10.1 được thêm vào danh sách máy tính bảng được đề xuất. Điều quan trọng là máy tính bảng không có tính năng điều chế độ rộng xung (PWM) để điều chỉnh độ sáng màn hình nhằm loại bỏ hiện tượng tạo dải trong ảnh chụp.

Để biết thông tin mới nhất về máy tính bảng được khuyên dùng, hãy xem Yêu cầu về máy tính bảng .

Giảm độ mở của máy tính bảng

Để cho phép sử dụng Galaxy Tab A 10.1, độ cao của phần mở máy tính bảng được giảm nhẹ đối với cả vỏ thử nghiệm RFoV (rev1a) và WFOV (rev2). Các bản sửa đổi phản ánh những thay đổi này là rev1a.1 và rev2.9. Đối với những bản vẽ này, hãy xem hộp RFoV (rev1a) và hộp WFOV (rev2.9) .

Bộ điều khiển tổng hợp cảm biến mới

Phần cứng của bộ điều khiển tổng hợp cảm biến được thiết kế lại để cải thiện khả năng sản xuất. Bộ điều khiển mới dựa trên Arduino , với tấm chắn bảng định tuyến tùy chỉnh gắn trên đầu Arduino. Hình 1 thể hiện tấm chắn và hình 2 thể hiện bản vẽ cơ khí của vỏ bọc. Bộ điều khiển mới được cấp nguồn bằng nguồn điện 5 V duy nhất cấp nguồn trực tiếp cho động cơ. Các thiết bị điện tử được điều khiển hoàn toàn thông qua đầu nối USB. Nguồn điện riêng biệt cho phép cách ly hoàn toàn giữa thiết bị điện tử điều khiển và động cơ servo. Ngoài ra, một bộ điều khiển duy nhất có thể điều khiển tối đa sáu động cơ servo.

Hình 1. Mặt trên của tấm chắn Arduino

Hình 2. Thiết kế bao vây

Android 11 tương thích ngược với các bộ điều khiển hiện có. Để gọi thử nghiệm bằng bộ điều khiển dựa trên Arduino, hãy sử dụng:

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

Cấp độ API đầu tiên

Trong Android 10, các bài kiểm tra ITS được chỉ định là MANDATED và NOT_YET_MANDATED . Để khởi chạy dưới dạng thiết bị Android 10, tất cả các bài kiểm tra MANDATED phải vượt qua. Các thử nghiệm NOT_YET_MANDATED có thể thất bại nhưng được lập bảng là PASS đối với báo cáo của trình xác minh CTS. Yêu cầu kiểm tra MANDATED cũng áp dụng cho các thiết bị đã nâng cấp. Yêu cầu này đối với các thiết bị đã nâng cấp phải vượt qua tất cả các bài kiểm tra MANDATED đã khiến các bài kiểm tra bị trì hoãn trong việc trở thành bài kiểm tra MANDATED vì các thiết bị cũ hơn cũng phải vượt qua các bài kiểm tra.

Trong Android 11, các bài kiểm tra MANDATED được kiểm soát bằng cờ cấp API đầu tiên từ thuộc tính điện thoại. Đối với các thiết bị nâng cấp lên Android 11, các bài kiểm tra sẽ chạy dưới dạng bài kiểm tra NOT_YET_MANDATED , nghĩa là bài kiểm tra có thể thất bại nhưng được lập bảng là PASS trong CtsVerifier.apk .

Ví dụ:

• Trong Android 11, thử nghiệm test_channel_saturation MANDATED đối với các thiết bị có cấp API đầu tiên lớn hơn 29.
• Trong Android 10, bài kiểm tra test_channel_saturation là MANDATED đối với tất cả các thiết bị.

Xác thực ánh sáng cảnh

Trong Android 11, ánh sáng cảnh được xác thực bằng cách phân tích độ sáng ở các góc của cảnh. Tất cả các cảnh thủ công đều được xác thực về ánh sáng và các cảnh dựa trên máy tính bảng được xác thực cho camera RFoV trong giàn thử nghiệm RFoV và camera WFOV trong giàn thử nghiệm WFOV. Nếu mức độ chiếu sáng không đủ, lỗi sẽ được báo cáo và quá trình kiểm tra không thành công.

Thay đổi tên cảnh

Trong Android 10, cảnh 1 chiếm phần lớn các thử nghiệm và chiếm tỷ lệ lớn trong tổng thời gian thử nghiệm. Nếu bất kỳ thử nghiệm nào trong cảnh 1 không thành công thì toàn bộ cảnh phải được chạy lại. Theo thiết kế, việc chạy lại toàn bộ cảnh sẽ giúp giảm việc vượt qua các thử nghiệm cận biên. Trong Android 11, thời gian chạy lại được giảm bớt bằng cách chia cảnh 1 thành hai cảnh, cảnh1_1 và cảnh1_2.

Bảng sau đây hiển thị thời gian thử nghiệm được lập bảng cho camera sau của Pixel 4 cho các cảnh khác nhau. Số lượng bài thi được chia ra để cân bằng thời gian thi chứ không phải để cân bằng số lượng bài thi.

Ngoài ra còn có tính năng dọn dẹp tên. Cảnh 2 được chia bằng chữ cái và cảnh 1 được chia bằng số. Danh pháp cho các phần mở rộng khác nhau là:

• Các cảnh có cùng biểu đồ nhưng các bài kiểm tra khác nhau: *_1,2,3
• Các cảnh có biểu đồ khác nhau nhưng kiểm tra giống nhau: *_a,b,c

Kiểm tra các thay đổi

Đã cập nhật các thử nghiệm để sử dụng cấp API đầu tiên

Trong Android 11, các thử nghiệm trong bảng sau được cập nhật để sử dụng cờ cấp độ API đầu tiên. Tất cả các thử nghiệm này đều sử dụng cấp API đầu tiên là 29 ngoại trừ thử nghiệm test_tonemap_curve sử dụng cấp API đầu tiên là 30.

Thử nghiệm với những thay đổi

Các thử nghiệm trong bảng sau được cập nhật trong Android 11. Các thay đổi được mô tả trong cột Mô tả thay đổi .

Thử nghiệm mới

Các thử nghiệm trong bảng sau được bật trong Android 11. Các thử nghiệm được tóm tắt trong bảng và mô tả chi tiết được cung cấp trong các phần sau.

cảnh0/test_vibration_restriction

Thử nghiệm này không yêu cầu cảnh cụ thể nhưng thiết bị được thử nghiệm (DUT) phải được đặt hoặc gắn trên bề mặt cứng. Điều này bao gồm việc lắp đặt trên vỏ thử nghiệm ITS-in-a-box.

Khẳng định

• Không bị rung khi sử dụng máy ảnh

cảnh2_a/test_jpeg_quality

Phương pháp

Các phần khác nhau của tệp JPEG được xác định bằng các điểm đánh dấu 2 byte. Để biết thêm thông tin, xem JPEG .

Thử nghiệm trích xuất các ma trận lượng tử hóa từ ảnh chụp JPEG. Điểm đánh dấu cho ma trận lượng tử hóa trong ảnh chụp JPEG là chuỗi [255, 219]. Khi tìm thấy điểm đánh dấu, hai mục danh sách tiếp theo là kích thước. Điểm đánh dấu kích thước JPEG DQT thường là [0, 132] = 256*0+132 = 132, chiếm kích thước của dữ liệu DQT trong ảnh chụp JPEG. Dữ liệu được nhúng có dạng: [255, 219, 0, 132, 0 (điểm đánh dấu độ sáng), ma trận độ sáng 8x8, 1 (điểm đánh dấu sắc độ), ma trận sắc độ 8x8].

Số 0 cho điểm đánh dấu ma trận độ sáng và 1 cho điểm đánh dấu sắc độ xuất hiện nhất quán đối với một số thiết bị, bao gồm cả điện thoại tách hai ma trận thành các phần DQT riêng biệt trong tệp JPEG. Ma trận độ sáng có xu hướng có nhiều giá trị cao hơn so với ma trận sắc độ vì mắt người nhạy cảm với độ sáng hơn so với sắc độ và hình ảnh JPEG có tính đến điều này.

Ma trận độ sáng và sắc độ được trích xuất mẫu được hiển thị bên dưới cho hệ số chất lượng 85 và 25 đối với camera sau của Pixel 4 chụp cảnh2_a bằng giàn thử nghiệm ITS. Các giá trị ma trận tăng lên đáng kể (biểu thị mức độ nén tăng lên) đối với cài đặt chất lượng thấp hơn. Các ma trận này chỉ được in bằng tập lệnh nếu cờ debug=True được áp dụng. Lưu ý sự thay đổi lớn hơn trong các mục trong ma trận độ sáng so với ma trận sắc độ.

    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]]

Hình 3 hiển thị các giá trị ma trận trung bình của camera sau Pixel 4 so với chất lượng JPEG. Khi chất lượng JPEG tăng lên, mức độ nén (trung bình ma trận DQT độ sáng/sắc độ) sẽ giảm.

Hình 3. Giá trị trung bình của ma trận DQT độ sáng/sắc độ DQT của camera sau Pixel 4 so với chất lượng JPEG

Khẳng định

• Đối với [25, 45, 65, 86], +20 về chất lượng có mức trung bình ma trận lượng tử hóa giảm 20%.
• Tải trọng ma trận DQT là số bình phương.

Hình 4 cho thấy một ví dụ về một chiếc điện thoại không vượt qua bài kiểm tra. Lưu ý rằng đối với hình ảnh chất lượng rất thấp ( jpeg.quality < 50 ), độ nén trong ma trận lượng tử hóa không tăng.

Hình 4. Ví dụ thử nghiệm thất bại

cảnh2_d/e test_num_faces

Hai cảnh nhận diện khuôn mặt mới được thêm vào để tăng tính đa dạng của khuôn mặt khi kiểm tra thuật toán nhận diện khuôn mặt. Với việc thử nghiệm lặp đi lặp lại một số máy ảnh, khuôn mặt thách thức nhất dự kiến ​​sẽ là khuôn mặt ngoài cùng bên trái trong scene2_d. Đặc biệt, trên người mẫu còn có cả mũ và râu, có gì đó mới mẻ trong các cảnh quay khuôn mặt. Những cảnh mới được thể hiện trong hình 5 và 6.

Hình 5. scene2_d

Hình 6. cảnh2_e

Khẳng định

• num_faces == 3

scene2_e/test_continuous_picture

Phương pháp

Thử nghiệm test_continuous_picture sử dụng scene2_e nhưng nó có thể được bật với bất kỳ cảnh khuôn mặt nào. Trong thử nghiệm này, 50 khung hình có độ phân giải VGA được chụp với cài đặt đầu tiên của yêu cầu chụp android.control.afMode = 4 (CONTINUOUS_PICTURE) .

Hệ thống 3A dự kiến ​​sẽ ổn định khi kết thúc quá trình chụp 50 khung hình.

Khẳng định

• 3A ở trạng thái hội tụ khi kết thúc quá trình chụp.

cảnh_change/test_scene_change

Phương pháp

Một thử nghiệm mới được kích hoạt để kiểm tra xem cờ android.control.afSceneChange có được xác nhận khi thay đổi cảnh hay không. Việc thay đổi cảnh sử dụng máy tính bảng hiển thị cảnh khuôn mặt, sau đó bật và tắt máy tính bảng để tạo thay đổi cảnh. Cảnh này sử dụng lại cảnh2_e nhưng ở trong một cảnh riêng biệt do yêu cầu phải có điều khiển máy tính bảng.

Ngoài ra, để kiểm tra thủ công, bạn có thể thực hiện thay đổi cảnh bằng cách vẫy tay trước máy ảnh.

Hình 7 thể hiện sơ đồ thời gian của bài kiểm tra. Thời gian từ khi tắt màn hình đến khi chụp được điều chỉnh dựa trên kết quả sự kiện từ các lần chụp trước đó.

Hình 7. Sơ đồ thời gian cho test_scene_change

Điều kiện dịch chuyển:

• Nếu có thay đổi cảnh và afSceneChange == 1 , kiểm tra sẽ trả về PASS .
• Nếu có thay đổi cảnh và afSceneChange == 0 thì thay đổi cảnh sẽ dịch chuyển 5 khung hình sớm hơn để có thêm thời gian cho afSceneChange xác nhận.
• Nếu không có thay đổi cảnh và afSceneChange == 1 , kiểm tra sẽ trả về FAIL .
• Nếu không có thay đổi cảnh và afSceneChange == 0 , thay đổi cảnh sẽ chuyển 30 khung hình sớm hơn để thay đổi cảnh khi chụp.

Khẳng định

• Chuyển đổi màn hình (cảnh).
• Cờ afSceneChange nằm trong [0, 1].
• Nếu không có cảnh thay đổi, 3A sẽ hội tụ (có chức năng giống hệt test_continuous_picture ).
• Nếu afSceneChange == 1 , độ sáng phải thay đổi trong cảnh.
• PASS trong vòng sáu lần thử với thời gian được thay đổi dựa trên kết quả trước đó.

cảnh6/test_zoom

Phương pháp

Cần có một cảnh mới để kiểm tra android.control.zoomRatioRange vì các cảnh đã thiết lập không có tính năng đủ nhỏ để phóng to (cảnh [1, 2, 4]) hoặc cảnh có nhiều đối tượng không dễ xác định , trích xuất tính năng phức tạp (cảnh 3).

Hình 8 hiển thị cảnh mới với một dãy các vòng tròn thông thường. Mảng vòng tròn nới lỏng các yêu cầu về căn giữa DUT/biểu đồ và cho phép vòng tròn luôn ở gần tâm của hình ảnh được chụp. Trong cảnh này, một mảng các vòng tròn 9x5 có viền đen bao phủ toàn bộ máy tính bảng. Một vòng tròn được thay thế bằng một hình vuông ở góc trên bên phải để hiển thị hướng. Kích thước vòng tròn có đặc điểm là có diện tích khoảng 7500 pixel ( radius=50pixels ) cho cảm biến 4000x3000 được chụp với trường nhìn (foV) khoảng 80 độ.

Hình 8. Cảnh test_zoom

Hình 9. Pixel 4 cam[0] zoom = [1, 3.33, 5.67, 8] ảnh có vòng tròn tìm thấy

Hình 9 hiển thị các hình ảnh được chụp bằng camera sau của Pixel 4 khi mức thu phóng tăng từ 1 lên 8 lần với 4 bước. Bộ ảnh này được chụp mà không cần quan tâm cụ thể đến việc căn giữa ngoại trừ việc sử dụng khẩu độ thử nghiệm của điện thoại với hai lỗ mở để cho phép thử nghiệm cả camera trước và sau. Dự kiến ​​sẽ có một khoảng lệch so với tâm và được quan sát thấy khi bảng biểu đồ hơi lệch sang trái một chút so với tâm. Ngoài ra, biểu đồ có vẻ đủ để kiểm tra với tỷ lệ thu phóng cao hơn 8x.

Tìm vòng kết nối

Thử nghiệm bao gồm phương thức find_circle() sử dụng findContours để tìm tất cả các đường viền và thu hẹp tìm kiếm đường viền xuống các vòng tròn mong muốn bằng cách kiểm tra những điều sau:

• Đường viền phải có diện tích lớn hơn 10 pixel.
• Đường viền phải có NUM_PTS >= 15 .
• Đường viền phải có tâm màu đen.
• Các đường viền phải giống hình tròn, nghĩa là diện tích của chúng gần với diện tích pi*r2 của đường viền.

Phạm vi kiểm tra

android.control.zoomRatioRange được chia thành 10 bước.

• [1, 7] kiểm tra [1, 1,67, 2,33, 3, 3,67, 4,33, 5, 5,67, 6,33, 7]

Quá trình thu phóng sẽ bị dừng nếu vòng tròn tìm thấy chạm vào ranh giới của hình ảnh. Có một bước kiểm tra để đảm bảo đạt được mức thu phóng đủ trong thử nghiệm (10x).

Khẳng định

• Ít nhất một vòng tròn được tìm thấy ở mỗi cài đặt thu phóng.
• Đã thử nghiệm gấp 10 lần hoặc tối đa android.control.zoomRatioRange .
• Chia tỷ lệ bán kính vòng tròn với mức thu phóng (RTOL 10% so với dự kiến).
• Độ lệch tâm vòng tròn so với tỷ lệ trung tâm có thu phóng (RTOL 10% so với dự kiến).
• Đã đạt đủ mức thu phóng (2x).

Tăng cường thử nghiệm máy ảnh GIỚI HẠN

Trong Android 11, các thử nghiệm trong bảng sau đây sẽ kiểm tra camera LIMITED . Ngoài các thử nghiệm mới , thử nghiệm scene4/test_aspect_ratio_and_crop được cập nhật để cho phép thử nghiệm LIMITED thiết bị có cấp API đầu tiên từ 30 trở lên.

Hình 10 hiển thị vòng giải mã bí mật ITS của Android 11. Vòng giải mã bí mật hiển thị các cài đặt kiểm tra mà các bài kiểm tra riêng lẻ được kiểm soát. Cổng được mã hóa màu để đơn giản trong việc xem. Các hạng mục cổng chính là:

• MANUAL_SENSOR
• READ_3A *yêu cầu MANUAL SENSOR
• COMPUTE_TARGET_EXPOSURES *yêu cầu MANUAL SENSOR
• PER_FRAME_CONTROL
• RAW
• SENSORS * REALTIME
• MULTI_CAMERA

MANUAL SENSOR , READ_3A , COMPUTE_TARGET_EXPOSURES và PER_FRAME_CONTROL kiểm tra phần lớn các thử nghiệm. Ngoài ra, các thử nghiệm được kích hoạt cho LIMITED thiết bị sẽ được đánh dấu bằng màu xanh nhạt.

Hình 10. Vòng giải mã bí mật Android 11