Catatan rilis Camera Image Test Suite Android 11

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Halaman ini meringkas perubahan pada Camera Image Test Suite (ITS) di Android 11. Perubahan ini termasuk dalam kategori berikut:

• Perubahan hardware
• Pengujian MANDATED level API pertama
• Pencahayaan pengujian divalidasi
• Perubahan nama scene
• Menguji perubahan dan penambahan
• Meningkatkan pengujian kamera LIMITED

Perubahan hardware

Android 11 memperkenalkan beberapa perubahan hardware untuk mengurangi biaya dan meningkatkan ketersediaan. Perubahan ini termasuk dalam kategori berikut:

• Produsen tambahan
• Metode manufaktur terpadu
• Penambahan opsi tablet
• Mengurangi pembukaan tablet
• Pengontrol penggabungan sensor baru

Produsen tambahan

Rahi Systems memenuhi syarat untuk memproduksi enklosur pengujian ITS selain pemasok kami yang sudah ada, MYWAY design. Informasi perusahaan untuk vendor yang memenuhi syarat adalah sebagai berikut:

• 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., No. 163, Fu-Ying Road, XinZhuang District, New Taipei City, Taiwan
  twmyway.com
  sales@myway.tw
  +886-2-29089060

Metode manufaktur terpadu

Penutup pengujian ITS-in-a-box bidang pandang reguler (RFoV) revisi 1 didesain ulang untuk menggunakan metode manufaktur yang digunakan oleh penutup pengujian kotak bidang pandang lebar (WFoV) dan kotak penggabungan sensor. Fungsinya identik, dan untuk memudahkan, desain disebut sebagai rev1a. Desain ulang memungkinkan produsen menyimpan satu jenis plastik untuk memproduksi semua penutup pengujian. Selain itu, dudukan tablet dan holder lampu didesain ulang untuk menangani variasi yang lebih besar pada tablet dan lampu LED.

Untuk mendownload deskripsi dan gambar mekanis terbaru, lihat kotak RFoV (rev1a) dan kotak WFoV (rev2.9).

Peningkatan opsi tablet

Tablet termasuk Samsung Galaxy Tab A 10.1 dan Chuwi Hi9 Air 10.1 ditambahkan ke daftar tablet yang direkomendasikan. Tablet tidak boleh memiliki pulse width modulation (PWM) untuk menyesuaikan kecerahan layar guna menghilangkan banding dalam gambar yang diambil.

Untuk informasi terbaru tentang tablet yang direkomendasikan, lihat Persyaratan tablet.

Mengurangi pembukaan tablet

Untuk memungkinkan penggunaan Galaxy Tab A 10.1, tinggi pembukaan tablet sedikit dikurangi untuk penutup pengujian RFoV (rev1a) dan WFoV (rev2). Revisi yang mencerminkan perubahan ini adalah rev1a.1 dan rev2.9. Untuk gambar ini, lihat kotak RFoV (rev1a) dan kotak WFoV (rev2.9).

Pengontrol penggabungan sensor baru

Hardware untuk pengontrol penggabungan sensor didesain ulang untuk meningkatkan kemampuan manufaktur. Pengontrol baru ini berbasis Arduino, dengan shield papan pemilihan rute kustom yang dipasang di atas Arduino. Gambar 1 menunjukkan pelindung dan gambar 2 menunjukkan gambar mekanis untuk penutup. Pengontrol baru diberi daya oleh satu catu daya 5 V yang langsung memberi daya pada motor. Elektronik dikontrol sepenuhnya melalui konektor USB. Catu daya terpisah memungkinkan isolasi lengkap antara elektronik kontrol dan motor servo. Selain itu, satu pengontrol dapat mengontrol maksimal enam motor servo.

Gambar 1. Tampilan atas shield Arduino

Gambar 2. Desain enklosur

Android 11 kompatibel dengan pengontrol yang ada. Untuk memanggil pengujian dengan pengontrol berbasis Arduino, gunakan:

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

API level pertama

Di Android 10, pengujian ITS ditetapkan sebagai MANDATED dan NOT_YET_MANDATED. Untuk diluncurkan sebagai perangkat Android 10, semua pengujian MANDATED harus lulus. Pengujian NOT_YET_MANDATED dapat gagal, tetapi ditabulasi sebagai PASS untuk pelaporan verifier CTS. Persyaratan pengujian MANDATED juga berlaku untuk perangkat yang diupgrade. Persyaratan ini untuk perangkat yang diupgrade agar lulus semua pengujian MANDATED menyebabkan pengujian tertunda menjadi pengujian MANDATED karena perangkat lama juga harus lulus pengujian.

Di Android 11, pengujian MANDATED dibatasi oleh flag level API pertama dari properti ponsel. Untuk perangkat yang diupgrade ke Android 11, pengujian dijalankan sebagai pengujian NOT_YET_MANDATED, yang berarti pengujian dapat gagal, tetapi ditabulasi sebagai PASS di CtsVerifier.apk.

Contoh:

• Di Android 11, pengujian test_channel_saturation adalah MANDATED untuk perangkat dengan level API pertama yang lebih besar dari 29.
• Di Android 10, pengujian test_channel_saturation adalah MANDATED untuk semua perangkat.

Memvalidasi pencahayaan scene

Di Android 11, pencahayaan scene divalidasi dengan menganalisis kecerahan di sudut scene. Semua scene manual divalidasi untuk pencahayaan, dan scene berbasis tablet divalidasi untuk kamera RFoV di rig pengujian RFoV dan kamera WFoV di rig pengujian WFoV. Jika tingkat pencahayaan tidak memadai, error akan dilaporkan dan pengujian akan gagal.

Perubahan nama scene

Di Android 10, scene 1 mencakup sebagian besar pengujian dan persentase besar dari total waktu pengujian. Jika ada pengujian dalam scene 1 yang gagal, seluruh scene harus dijalankan ulang. Secara desain, menjalankan ulang seluruh tampilan akan mengurangi keberhasilan pengujian marginal. Di Android 11, waktu pengulangan dikurangi dengan membagi scene 1 menjadi dua scene, scene1_1 dan scene1_2.

Tabel berikut menunjukkan waktu pengujian yang ditabulasi untuk kamera belakang Pixel 4 untuk berbagai scene. Jumlah pengujian dibagi untuk menyamakan waktu pengujian, bukan untuk menyamakan jumlah pengujian.

Selain itu, ada pembersihan nama. Scene 2 dibagi dengan huruf dan scene 1 dibagi dengan angka. Nomenklatur untuk berbagai ekstensi adalah:

• Scene dengan diagram yang sama, tetapi pengujian yang berbeda: *_1,2,3
• Scene dengan diagram yang berbeda, tetapi pengujian yang sama: *_a,b,c

Menguji perubahan

Pengujian diperbarui untuk menggunakan level API pertama

Di Android 11, pengujian dalam tabel berikut diupdate untuk menggunakan flag API level pertama. Semua pengujian ini menggunakan API level pertama 29, kecuali pengujian test_tonemap_curve, yang menggunakan API level pertama 30.

Pengujian dengan perubahan

Pengujian dalam tabel berikut diperbarui di Android 11. Perubahan dijelaskan di kolom Deskripsi perubahan.

Pengujian baru

Pengujian dalam tabel berikut diaktifkan di Android 11. Pengujian dirangkum dalam tabel dan deskripsi mendetail diberikan di bagian berikut.

scene0/test_vibration_restriction

Pengujian ini tidak memerlukan scene tertentu, tetapi perangkat yang sedang diuji (DUT) harus diletakkan atau dipasang di permukaan yang keras. Hal ini mencakup pemasangan pada penutup pengujian ITS-in-a-box.

Menyatakan

• Tidak ada getaran selama penggunaan kamera

scene2_a/test_jpeg_quality

Metode

Berbagai bagian file JPEG ditentukan oleh penanda 2 byte. Untuk mengetahui informasi selengkapnya, lihat JPEG.

Pengujian mengekstrak matriks kuantisasi dari pengambilan JPEG. Penanda untuk matriks kuantisasi dalam pengambilan JPEG adalah urutan, [255, 219]. Saat penanda ditemukan, dua item daftar berikutnya adalah ukuran. Penanda ukuran JPEG DQT biasanya [0, 132] = 256*0+132 = 132, yang memperhitungkan ukuran data DQT dalam pengambilan JPEG. Data tersemat memiliki bentuk: [255, 219, 0, 132, 0 (penanda luma), matriks luma 8x8, 1 (penanda kroma), matriks kroma 8x8].

0 untuk penanda matriks luma dan 1 untuk penanda kroma tampak konsisten untuk sejumlah perangkat, termasuk ponsel yang memisahkan kedua matriks menjadi bagian DQT terpisah dalam file JPEG. Matriks luma cenderung memiliki variasi nilai yang lebih tinggi dibandingkan dengan matriks kroma karena mata manusia lebih sensitif terhadap luma daripada kroma dan gambar JPEG memperhitungkannya.

Contoh matriks luma dan kroma yang diekstrak ditampilkan di bawah untuk faktor kualitas 85 dan 25 untuk kamera belakang Pixel 4 yang merekam scene2_a dengan rig pengujian ITS. Nilai matriks meningkat (menunjukkan peningkatan kompresi) secara substansial untuk setelan kualitas yang lebih rendah. Matriks ini hanya dicetak dengan skrip jika flag debug=True diterapkan. Perhatikan variasi entri yang lebih besar dalam matriks luma dibandingkan dengan matriks kroma.

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

Gambar 3 menunjukkan nilai matriks rata-rata untuk kamera belakang Pixel 4 versus kualitas JPEG. Saat kualitas JPEG ditingkatkan, tingkat kompresi (rata-rata matriks DQT luma/chroma) akan menurun.

Gambar 3. Rata-rata matriks DQT luma/kroma kamera belakang Pixel 4 versus kualitas JPEG

Menyatakan

• Untuk [25, 45, 65, 86], kualitas +20 memiliki rata-rata matriks kuantisasi pengurangan 20%.
• Payload matriks DQT adalah bilangan kuadrat.

Gambar 4 menunjukkan contoh ponsel yang gagal dalam pengujian. Perhatikan bahwa untuk gambar berkualitas sangat rendah (jpeg.quality < 50), tidak ada peningkatan kompresi dalam matriks kuantisasi.

Gambar 4. Contoh pengujian yang gagal

scene2_d/e test_num_faces

Dua scene deteksi wajah baru ditambahkan untuk meningkatkan keragaman wajah dari pemeriksaan algoritme deteksi wajah. Dengan pengujian berulang terhadap sejumlah kamera, wajah yang paling menantang diharapkan menjadi wajah paling kiri di scene2_d. Secara khusus, ada topi dan janggut pada model, sesuatu yang baru di adegan wajah. Scene baru ditampilkan dalam gambar 5 dan 6.

Gambar 5. scene2_d

Gambar 6. scene2_e

Menyatakan

• num_faces == 3

scene2_e/test_continuous_picture

Metode

Pengujian test_continuous_picture menggunakan scene2_e, tetapi dapat diaktifkan dengan salah satu scene wajah. Dalam pengujian ini, 50 frame resolusi VGA diambil dengan setelan pertama permintaan pengambilan android.control.afMode = 4 (CONTINUOUS_PICTURE).

Sistem 3A diharapkan telah stabil di akhir pengambilan 50 frame.

Menyatakan

• 3A dalam status gabungan di akhir pengambilan.

scene_change/test_scene_change

Metode

Pengujian baru diaktifkan untuk menguji apakah tanda android.control.afSceneChange dinyatakan dengan perubahan scene. Perubahan scene menggunakan tablet yang menampilkan scene wajah, lalu mengaktifkan dan menonaktifkan tablet untuk membuat perubahan scene. Adegan menggunakan kembali scene2_e, tetapi berada dalam adegan terpisah karena kontrol tablet yang diperlukan.

Selain itu, untuk pengujian manual, perubahan scene dapat dilakukan dengan melambaikan tangan di depan kamera.

Gambar 7 menunjukkan diagram pengaturan waktu pengujian. Pengaturan waktu antara layar mati dan pengambilan disesuaikan berdasarkan hasil peristiwa dari pengambilan sebelumnya.

Gambar 7. Diagram pengaturan waktu untuk test_scene_change

Kondisi shift:

• Jika ada perubahan scene dan afSceneChange == 1, pengujian akan menampilkan PASS.
• Jika ada perubahan scene dan afSceneChange == 0, perubahan scene akan bergeser 5 frame lebih awal untuk memberi lebih banyak waktu bagi afSceneChange untuk menyatakan.
• Jika tidak ada perubahan scene dan afSceneChange == 1, pengujian akan menampilkan FAIL.
• Jika tidak ada perubahan scene dan afSceneChange == 0, perubahan scene akan bergeser 30 frame lebih awal untuk mendapatkan perubahan scene dalam pengambilan.

Menyatakan

• Tombol layar (adegan).
• Flag afSceneChange berada di [0, 1].
• Jika tidak ada perubahan scene, 3A akan berkonvergensi (secara fungsional identik dengan test_continuous_picture).
• Jika afSceneChange == 1, kecerahan harus berubah dalam tampilan.
• PASS dalam enam percobaan dengan pengaturan waktu yang diubah berdasarkan hasil sebelumnya.

scene6/test_zoom

Metode

Scene baru diperlukan untuk menguji android.control.zoomRatioRange karena scene yang ditetapkan tidak memiliki fitur yang cukup kecil untuk diperbesar (scene [1, 2, 4]) atau scene memiliki banyak objek yang tidak mudah diidentifikasi, sehingga mempersulit ekstraksi fitur (scene 3).

Gambar 8 menunjukkan tampilan baru dengan array lingkaran reguler. Array lingkaran melonggarkan persyaratan pada pemusatan DUT/diagram dan memungkinkan lingkaran selalu berada di dekat pusat gambar yang diambil. Dalam tampilan ini, array lingkaran 9x5 dengan batas hitam menutupi seluruh tablet. Satu lingkaran diganti dengan persegi di sudut kanan atas untuk menunjukkan orientasi. Ukuran lingkaran memiliki fitur dengan area sekitar 7.500 piksel (radius=50pixels) untuk sensor 4.000x3.000 yang diambil dengan bidang pandang (FoV) sekitar 80 derajat.

Gambar 8. Tampilan test_zoom

Gambar 9. Zoom cam[0] Pixel 4 = [1, 3,33, 5,67, 8] gambar dengan lingkaran yang ditemukan

Gambar 9 menunjukkan gambar yang diambil untuk kamera belakang Pixel 4 saat zoom bertambah dari 1 hingga 8x dengan empat langkah. Kumpulan gambar ini diambil tanpa perhatian khusus yang dilakukan dalam memusatkan kecuali untuk menggunakan apertur pengujian ponsel dengan dua bukaan untuk memungkinkan pengujian kamera depan dan belakang. Offset dari tengah diharapkan, dan diamati saat tablet diagram sedikit ke kiri dari tengah. Selain itu, diagram tampaknya cukup untuk diuji dengan rasio zoom yang lebih tinggi dari 8x.

Menemukan lingkaran

Pengujian ini mencakup metode find_circle() menggunakan findContours yang menemukan semua kontur dan mempersempit penelusuran kontur ke lingkaran yang diinginkan dengan menguji hal berikut:

• Kontur harus memiliki area lebih besar dari 10 piksel.
• Kontur harus memiliki NUM_PTS >= 15.
• Kontur harus memiliki bagian tengah berwarna hitam.
• Kontur harus menyerupai lingkaran, yaitu, areanya dekat dengan area pi*r2 dari kontur.

Rentang pengujian

android.control.zoomRatioRange dibagi menjadi 10 langkah.

• [1, 7] menguji [1, 1,67, 2,33, 3, 3,67, 4,33, 5, 5,67, 6,33, 7]

Zoom akan dihentikan jika lingkaran yang ditemukan menyentuh batas gambar. Ada pemeriksaan untuk memastikan tingkat zoom yang memadai tercapai dalam pengujian (10x).

Menyatakan

• Setidaknya satu lingkaran ditemukan di setiap setelan zoom.
• 10x atau maksimum android.control.zoomRatioRange diuji.
• Radius lingkaran diskalakan dengan zoom (RTOL 10% dari yang diharapkan).
• Offset pusat lingkaran dari skala tengah dengan zoom (RTOL 10% dari yang diharapkan).
• Tingkat zoom yang memadai tercapai (2x).

Meningkatkan pengujian kamera LIMITED

Di Android 11, pengujian dalam tabel berikut menguji kamera LIMITED. Selain pengujian baru, pengujian scene4/test_aspect_ratio_and_crop diperbarui untuk memungkinkan pengujian perangkat LIMITED dengan API level pertama 30 atau yang lebih tinggi.

Gambar 10 menunjukkan cincin decoder secret Android 11 ITS. Cincin decoder secret menunjukkan setelan pengujian yang digunakan untuk mengontrol setiap pengujian. Pembatasan diberi kode warna agar mudah dilihat. Item utama yang membatasi adalah:

• MANUAL_SENSOR
• READ_3A *memerlukan MANUAL SENSOR
• COMPUTE_TARGET_EXPOSURES *memerlukan MANUAL SENSOR
• PER_FRAME_CONTROL
• RAW
• SENSORS *REALTIME
• MULTI_CAMERA

MANUAL SENSOR, READ_3A, COMPUTE_TARGET_EXPOSURES, dan PER_FRAME_CONTROL mengontrol sebagian besar pengujian. Selain itu, pengujian yang diaktifkan untuk perangkat LIMITED ditandai dengan warna hijau muda.

Gambar 10. Cincin dekode rahasia Android 11