Catatan rilis Camera Image Test Suite Android 11

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

• Perubahan hardware
• Pengujian WAJIB level API pertama
• Pencahayaan pengujian divalidasi
• Perubahan nama adegan
• Menguji perubahan dan penambahan
• Peningkatan 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
• Opsi tablet yang lebih banyak
• Pembukaan tablet yang lebih kecil
• Pengontrol penggabungan sensor baru

Produsen tambahan

Rahi Systems memenuhi syarat untuk memproduksi penutup pengujian ITS selain supplier 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

• Desain MYWAY
  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 dengan sudut pandang reguler (RFoV) rev1 didesain ulang untuk menggunakan metode manufaktur yang digunakan oleh penutup pengujian kotak sudut pandang lebar (WFoV) dan kotak sensor fusion. Fungsinya identik, dan agar lebih sederhana, desain ini disebut sebagai rev1a. Desain ulang ini memungkinkan produsen menyimpan satu jenis plastik untuk memproduksi semua penutup pengujian. Selain itu, dudukan tablet dan dudukan lampu didesain ulang untuk menangani variasi yang lebih besar pada tablet dan batang lampu LED.

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

Opsi tablet yang ditingkatkan

Tablet termasuk Samsung Galaxy Tab A 10.1 dan Chuwi Hi9 Air 10.1 ditambahkan ke daftar tablet yang direkomendasikan. Penting agar tablet tidak memiliki modulasi lebar pulsa (PWM) untuk menyesuaikan kecerahan layar guna menghilangkan banding pada gambar yang diambil.

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

Pengurangan pembukaan tablet

Untuk mengizinkan penggunaan Galaxy Tab A 10.1, bukaan tablet dikurangi sedikit tingginya 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 kualitas manufaktur. Pengontrol baru ini berbasis Arduino, dengan shield papan perutean kustom yang dipasang di atas Arduino. Gambar 1 menunjukkan pelindung dan gambar 2 menunjukkan gambar mekanis untuk penutup. Pengontrol baru ini ditenagai oleh satu catu daya 5 V yang menggerakkan motor secara langsung. Elektronik dikontrol sepenuhnya melalui konektor USB. Catu daya terpisah memungkinkan isolasi lengkap antara elektronik kontrol dan motor servo. Selain itu, satu pengontrol dapat mengontrol hingga enam motor servo.

Gambar 1. Tampilan atas shield Arduino

Gambar 2. Desain pagar jalan

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

Level API 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 alat verifikasi CTS. Persyaratan pengujian MANDATED juga berlaku untuk perangkat yang diupgrade. Persyaratan agar perangkat yang diupgrade 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 adegan

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

Perubahan nama adegan

Di Android 10, scene 1 menyumbang sebagian besar pengujian dan persentase besar dari total waktu pengujian. Jika ada pengujian dalam scene 1 yang gagal, seluruh scene harus dijalankan ulang. Menurut desainnya, menjalankan ulang seluruh adegan akan mengurangi keberhasilan pengujian marginal. Di Android 11, waktu penayangan ulang dikurangi dengan membagi adegan 1 menjadi dua adegan, scene1_1 dan scene1_2.

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

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

• Adegan dengan diagram yang sama, tetapi pengujian yang berbeda: *_1,2,3
• Adegan 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 diperbarui untuk menggunakan tanda level API pertama. Semua pengujian ini menggunakan level API pertama 29, kecuali pengujian test_tonemap_curve, yang menggunakan level API 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 diringkas dalam tabel dan deskripsi mendetail diberikan di bagian berikut.

scene0/test_vibration_restriction

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

Pernyataan

• Tidak ada getaran saat menggunakan kamera

scene2_a/test_jpeg_quality

Metode

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

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

0 untuk penanda matriks luma dan 1 untuk penanda chroma tampak konsisten untuk sejumlah perangkat, termasuk ponsel yang memisahkan dua matriks menjadi bagian DQT terpisah dalam file JPEG. Matriks luma cenderung memiliki variasi nilai yang lebih tinggi dibandingkan dengan matriks chroma karena mata manusia lebih sensitif terhadap luma daripada chroma 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 signifikan untuk setelan kualitas yang lebih rendah. Matriks ini hanya dicetak dengan skrip jika flag debug=True diterapkan. Perhatikan variasi yang lebih besar dalam entri di matriks luma dibandingkan dengan matriks chroma.

    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. Seiring dengan meningkatnya kualitas JPEG, tingkat kompresi (rata-rata matriks DQT luma/chroma) menurun.

Gambar 3. Rata-rata matriks DQT luma/chroma kamera belakang Pixel 4 dibandingkan dengan kualitas JPEG

Pernyataan

• Untuk [25, 45, 65, 86], +20 dalam kualitas 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 gagal

scene2_d/e test_num_faces

Dua adegan deteksi wajah baru ditambahkan untuk meningkatkan keragaman wajah dalam pemeriksaan algoritma deteksi wajah. Dengan pengujian berulang pada sejumlah kamera, wajah yang paling sulit diperkirakan adalah wajah paling kiri di scene2_d. Khususnya, ada topi dan janggut pada model, sesuatu yang baru dalam adegan wajah. Adegan baru ditampilkan pada gambar 5 dan 6.

Figure 5. scene2_d

Gambar 6. scene2_e

Pernyataan

• 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 direkam dengan setelan permintaan pengambilan pertama android.control.afMode = 4 (CONTINUOUS_PICTURE).

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

Pernyataan

• 3A dalam status menyatu di akhir pengambilan.

scene_change/test_scene_change

Metode

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

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

Gambar 7 menunjukkan diagram pengaturan waktu pengujian. Waktu antara layar dinonaktifkan dan pengambilan gambar disesuaikan berdasarkan hasil peristiwa dari pengambilan gambar sebelumnya.

Gambar 7. Diagram waktu untuk test_scene_change

Kondisi peralihan:

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

Pernyataan

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

scene6/test_zoom

Metode

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

Gambar 8 menunjukkan adegan baru dengan susunan lingkaran biasa. Array lingkaran melonggarkan persyaratan pada pemusatan DUT/diagram dan memungkinkan lingkaran selalu berada di dekat bagian tengah gambar yang diambil. Dalam adegan ini, susunan 9x5 lingkaran 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 4000x3000 yang diambil dengan bidang pandang (FoV) sekitar 80 derajat.

Gambar 8. test_zoom scene

Gambar 9. Zoom cam[0] Pixel 4 = [1, 3.33, 5.67, 8] gambar dengan lingkaran yang ditemukan

Gambar 9 menampilkan gambar yang diambil untuk kamera belakang Pixel 4 saat zoom ditingkatkan dari 1 hingga 8x dengan empat langkah. Kumpulan gambar ini diambil tanpa memperhatikan secara khusus pemusatan, kecuali menggunakan apertur pengujian ponsel dengan dua bukaan untuk mengaktifkan pengujian kamera depan dan belakang. Pergeseran dari tengah diharapkan terjadi, dan terlihat saat tablet diagram sedikit di sebelah kiri tengah. Selain itu, diagram tampak 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 yang lebih besar dari 10 piksel.
• Kontur harus memiliki NUM_PTS >= 15.
• Kontur harus memiliki pusat hitam.
• Kontur harus menyerupai lingkaran, yaitu luasnya mendekati luas kontur pi*r2.

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 dihentikan jika lingkaran yang ditemukan menyentuh batas gambar. Ada pemeriksaan untuk memastikan tingkat zoom yang memadai tercapai dalam pengujian (10x).

Pernyataan

• 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).
• Pusat lingkaran yang diimbangi dari pusat diskala dengan zoom (RTOL 10% dari yang diharapkan).
• Tingkat zoom yang memadai tercapai (2x).

Peningkatan 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 pemecah kode rahasia ITS Android 11. Cincin pemecah kode rahasia menunjukkan setelan pengujian yang membatasi pengujian individual. Gerbang diberi kode warna agar mudah dilihat. Item penghalang utamanya 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 membatasi sebagian besar pengujian. Selain itu, pengujian yang diaktifkan untuk perangkat LIMITED ditandai dengan warna hijau muda.

Gambar 10. Cincin dekoder rahasia Android 11