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

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

• Thay đổi về phần cứng
• Các kiểm thử BẮT BUỘC ở cấp độ API đầu tiên
• Đã xác thực ánh sáng thử nghiệm
• Thay đổi tên cảnh
• Kiểm tra các thay đổi và nội dung bổ sung
• Tăng cường kiểm thử camera LIMITED

Thay đổi về phần cứng

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

• Nhà sản xuất khác
• Phương pháp sản xuất thống nhất
• Nhiều lựa chọn hơn về máy tính bảng
• Giảm số lần mở máy tính bảng
• Bộ điều khiển hợp nhất cảm biến mới

Nhà sản xuất khác

Rahi Systems đủ điều kiện sản xuất hộp kiểm thử ITS, ngoài nhà cung cấp hiện tại của chúng tôi là MYWAY Design. Thông tin về công ty của các nhà cung cấp đủ tiêu chuẩ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., No. 163, Fu-Ying Road, XinZhuang District, New Taipei City, Taiwan
  twmyway.com
  sales@myway.tw
  +886-2-29089060

Phương pháp sản xuất hợp nhất

Hộp kiểm thử ITS-in-a-box có trường 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 mà hộp có trường nhìn rộng (WFoV) và hộp kiểm thử hộp kết hợp cảm biến sử dụng. Chức năng này giống hệt nhau và để đơn giản, thiết kế này được gọi là rev1a. Thiết kế mới cho phép 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 hộp kiểm thử. Ngoài ra, giá đỡ máy tính bảng và giá đỡ đèn được thiết kế lại để có thể sử dụng cho nhiều loại máy tính bảng và đèn LED.

Để tải nội dung mô tả và bản vẽ cơ khí mới nhất xuống, hãy xem hộp RFoV (phiên bản 1a) và hộp WFoV (phiên bản 2.9).

Nhiều lựa chọn máy tính bảng hơ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 nên dùng. Đ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 sọc trong hình ảnh chụp được.

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

Giảm số lần mở máy tính bảng

Để cho phép sử dụng Galaxy Tab A 10.1, chiều cao của khe hở máy tính bảng sẽ giảm nhẹ đối với cả hộp kiểm thử 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 (phiên bản 1a) và hộp WFoV (phiên bản 2.9).

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

Phần cứng của bộ điều khiển hợp nhất 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, có vỏ bảng định tuyến tuỳ chỉnh gắn trên Arduino. Hình 1 cho thấy tấm chắn và hình 2 cho thấy bản vẽ cơ khí của vỏ. Bộ điều khiển mới được cấp nguồn bằng một 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 kiểm soát hoàn toàn thông qua giắc cắm USB. Nguồn điện riêng biệt giú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 có thể điều khiển tối đa 6 động cơ servo.

Hình 1. Hình ảnh nhìn từ trên cao của Arduino shield

Hình 2. Thiết kế vỏ

Android 11 tương thích ngược với các bộ điều khiển hiện có. Để gọi kiểm thử 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 thử 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 thử MANDATED đều phải vượt qua. Các kiểm thử NOT_YET_MANDATED có thể không thành công nhưng được lập bảng dưới dạng PASS cho báo cáo của trình xác minh CTS. Yêu cầu về các bài 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 để vượt qua tất cả các kiểm thử MANDATED khiến các kiểm thử bị trì hoãn trong việc trở thành kiểm thử MANDATED vì các thiết bị cũ hơn cũng phải vượt qua các kiểm thử.

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

Ví dụ:

• Trong Android 11, kiểm thử test_channel_saturation là MANDATED đối với các thiết bị có API cấp 1 lớn hơn 29.
• Trong Android 10, quy trình kiểm thử test_channel_saturation là MANDATED cho tất cả các thiết bị.

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

Trong Android 11, ánh sáng trong 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 đều được xác thực cho camera RFoV trong giàn kiểm thử RFoV và camera WFoV trong giàn kiểm thử WFoV. Nếu mức độ chiếu sáng không đủ, hệ thống sẽ báo lỗi và quá trình kiểm thử 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 bài kiểm thử và một tỷ lệ lớn trong tổng thời gian kiểm thử. Nếu có bất kỳ kiểm thử 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ẽ làm giảm số lượng bài kiểm thử cận biên. Trong Android 11, thời gian chạy lại sẽ giảm xuống bằng cách chia cảnh 1 thành 2 cảnh, scene1_1 và scene1_2.

Bảng sau đây cho thấy thời gian kiểm thử được lập bảng cho camera sau của Pixel 4 đối với các cảnh khác nhau. Số lượng kiểm thử được chia để cân bằng thời gian kiểm thử, chứ không phải để cân bằng số lượng kiểm thử.

Ngoài ra, còn có một quy trình 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ố. Quy tắc đặt tên cho các tiện ích 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 có cùng các kiểm thử: *_a,b,c

Kiểm thử các thay đổi

Các kiểm thử được cập nhật để sử dụng cấp độ API đầu tiên

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

Thử nghiệm có thay đổi

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

Số lượng xét nghiệm mới

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

scene0/test_vibration_restriction

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

Xác nhận

• Không rung khi sử dụng camera

scene2_a/test_jpeg_quality

Phương thức

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, hãy xem JPEG.

Thử nghiệm này trích xuất các ma trận lượng tử hoá từ ảnh chụp JPEG. Điểm đánh dấu cho ma trận lượng tử hoá trong ảnh chụp JPEG là chuỗi [255, 219]. Khi tìm thấy điểm đánh dấu, hai mục tiếp theo trong danh sách sẽ là kích thước. Thường thì dấu kích thước DQT JPEG là [0, 132] = 256*0+132 = 132, cho biết 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 độ chói), ma trận độ chói 8x8, 1 (điểm đánh dấu sắc độ), ma trận sắc độ 8x8].

0 cho điểm đánh dấu ma trận độ chói 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 2 ma trận thành các phần DQT riêng biệt trong tệp JPEG. Ma trận độ chói thường có nhiều giá trị hơn so với ma trận sắc độ vì mắt người nhạy cảm với độ chói hơn sắc độ và hình ảnh JPEG có tính đến điều này.

Các ma trận độ chói và sắc độ được trích xuất mẫu được trình bày bên dưới cho các hệ số chất lượng 85 và 25 đối với camera sau của Pixel 4 khi chụp cảnh 2_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) đối với chế độ 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ự khác biệt lớn hơn về các mục trong ma trận độ chói 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 cho thấy các giá trị ma trận trung bình cho camera sau của Pixel 4 so với chất lượng JPEG. Khi chất lượng JPEG tăng lên, mức độ nén (giá trị trung bình của ma trận DQT luma/chroma) sẽ giảm.

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

Xác nhận

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

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

Hình 4. Ví dụ về trường hợp kiểm thử không thành công

scene2_d/e test_num_faces

Hai cảnh phát hiện khuôn mặt mới được thêm vào để tăng tính đa dạng về khuôn mặt trong các bước kiểm tra của thuật toán phát hiện khuôn mặt. Với nhiều lần kiểm thử một số camera, khuôn mặt khó nhận diện nhất dự kiến sẽ là khuôn mặt ở bên trái cùng trong scene2_d. Cụ thể, mô hình này có cả mũ và râu, đây là điểm mới trong các cảnh khuôn mặt. Các cảnh mới được minh hoạ trong hình 5 và 6.

Hình 5. scene2_d

Hình 6. scene2_e

Xác nhận

• num_faces == 3

scene2_e/test_continuous_picture

Phương thức

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

Hệ thống 3A dự kiến sẽ ổn định vào cuối quá trình chụp 50 khung hình.

Xác nhận

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

scene_change/test_scene_change

Phương thức

Một thử nghiệm mới được bật để kiểm tra xem cờ android.control.afSceneChange có được xác nhận bằng một thay đổi cảnh hay không. Cảnh thay đổi 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 cảnh thay đổi. Cảnh này sử dụng lại scene2_e nhưng nằm trong một cảnh riêng biệt do yêu cầu về chế độ điều khiển bằng máy tính bảng.

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

Hình 7 cho thấy sơ đồ thời gian của quy trình kiểm thử. Thời gian giữa lúc màn hình tắt và lúc chụp được điều chỉnh dựa trên kết quả của 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 thay đổi:

• Nếu có thay đổi về cảnh và afSceneChange == 1, thì thử nghiệm sẽ trả về PASS.
• Nếu có thay đổi cảnh và afSceneChange == 0, thì thay đổi cảnh sẽ diễn ra sớm hơn 5 khung hình để có thêm thời gian cho afSceneChange xác nhận.
• Nếu không có thay đổi nào về cảnh và afSceneChange == 1, thì thử nghiệm sẽ trả về FAIL.
• Nếu không có cảnh nào thay đổi và afSceneChange == 0, thì cảnh thay đổi sẽ chuyển 30 khung hình trước đó để ghi lại cảnh thay đổi.

Xác nhận

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

scene6/test_zoom

Phương thức

Bạn cần có một cảnh mới để kiểm thử 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, gây khó khăn cho việc trích xuất tính năng (cảnh 3).

Hình 8 cho thấy cảnh mới với một mảng các hình tròn thông thường. Mảng các vòng tròn nới lỏng các yêu cầu về việc 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 đã chụp. Trong cảnh này, một mảng gồm 9x5 vòng tròn có đường viền màu đ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 để cho biết hướng. Các vòng tròn có một đặc điểm với diện tích khoảng 7.500 pixel (radius=50pixels) đối với cảm biến 4000x3000 được chụp với góc 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] hình ảnh có vòng tròn được tìm thấy

Hình 9 cho thấy hình ảnh được chụp bằng camera sau của Pixel 4 khi mức thu phóng tăng từ 1 đến 8 lần qua 4 bước. Bộ hình ảnh này được chụp mà không cần chú ý 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ỗ để cho phép thử nghiệm cả camera trước và sau. Dự kiến sẽ có độ lệch so với tâm và độ lệch này được quan sát thấy khi bảng biểu nằm hơi lệch về bên trái tâm. Ngoài ra, biểu đồ này có vẻ đủ để kiểm thử với tỷ lệ thu phóng cao hơn 8 lần.

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

Bài kiểm thử bao gồm một phương thức find_circle() sử dụng findContours để tìm tất cả các đường viền và thu hẹp phạm vi tìm kiếm đường viền xuống các vòng tròn mong muốn bằng cách kiểm thử 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.
• Đường viền phải giống với một hình tròn, tức là diện tích của đường viền gần bằng diện tích pi*r2 của đường viền.

Phạm vi kiểm thử

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

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

Thao tác thu phóng sẽ dừng lại 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 kiểm thử (gấp 10 lần).

Xác nhận

• Ít nhất một vòng tròn sẽ xuất hiện ở mỗi chế độ cài đặt thu phóng.
• Thử nghiệm 10 lần hoặc tối đa android.control.zoomRatioRange.
• Bán kính vòng tròn điều chỉnh theo tỷ lệ thu phóng (RTOL 10% so với dự kiến).
• Độ lệch tâm của vòng tròn so với tâm tỷ lệ với mức thu phóng (RTOL 10% so với dự kiến).
• Đã đạt đến mức thu phóng đủ (2x).

Tăng cường kiểm thử camera LIMITED

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

Hình 10 minh hoạ vòng giải mã bí mật của ITS Android 11. Vòng giải mã bí mật cho biết những chế độ cài đặt kiểm thử mà các kiểm thử riêng lẻ được kiểm soát. Việc phân loại được mã hoá bằng màu để dễ xem. Các mục chính cần có để đủ điều kiện 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 sẽ kiểm soát phần lớn các thử nghiệm. Ngoài ra, những kiểm thử được bật cho các thiết bị LIMITED sẽ được đánh dấu bằng màu xanh lục nhạt.

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