Subsistem HAL

Halaman ini menjelaskan subsistem HAL, termasuk permintaan, subsistem kamera, urutan startup dan operasi, tingkat hardware, dan interaksi.

Permintaan

Framework aplikasi mengeluarkan permintaan untuk hasil yang diambil ke subsistem kamera. Satu permintaan sesuai dengan satu set hasil. Permintaan mencakup semua informasi konfigurasi tentang pengambilan dan pemrosesan hasil tersebut. Hal ini mencakup hal-hal seperti resolusi dan format piksel; sensor manual, lensa, dan kontrol flash; mode operasi 3A; kontrol pemrosesan RAW ke YUV; dan pembuatan statistik. Hal ini memungkinkan kontrol yang jauh lebih besar atas output dan pemrosesan hasil. Beberapa permintaan dapat dikirim sekaligus, dan pengiriman permintaan tidak memblokir. Selain itu, permintaan selalu diproses sesuai urutan penerimaannya.

Model permintaan kamera

Gambar 1. Model kamera.

HAL dan subsistem kamera

Subsistem kamera mencakup implementasi untuk komponen dalam pipeline kamera seperti algoritma 3A dan kontrol pemrosesan. HAL kamera menyediakan antarmuka bagi Anda untuk menerapkan versi komponen ini. Untuk mempertahankan kompatibilitas lintas platform antara beberapa produsen perangkat dan vendor Image Signal Processor (ISP, atau sensor kamera), model pipeline kamera bersifat virtual dan tidak secara langsung sesuai dengan ISP nyata mana pun. Namun, pipeline ini cukup mirip dengan pipeline pemrosesan nyata sehingga Anda dapat memetakannya ke hardware secara efisien. Selain itu, algoritma ini cukup abstrak untuk memungkinkan beberapa algoritma dan urutan operasi yang berbeda tanpa mengurangi kualitas, efisiensi, atau kompatibilitas lintas perangkat.

Pipeline kamera juga mendukung pemicu yang dapat dimulai oleh framework aplikasi untuk mengaktifkan hal-hal seperti fokus otomatis. Hal ini juga mengirimkan notifikasi kembali ke framework aplikasi, yang memberi tahu aplikasi tentang peristiwa seperti penguncian fokus otomatis atau error.

Lapisan abstraksi hardware kamera

Gambar 2. Pipeline kamera.

Perhatikan bahwa beberapa blok pemrosesan gambar yang ditampilkan dalam diagram di atas tidak didefinisikan dengan baik dalam rilis awal. Pipeline kamera membuat asumsi berikut:

  • Output Bayer RAW tidak mengalami pemrosesan di dalam ISP.
  • Statistik dibuat berdasarkan data sensor mentah.
  • Berbagai blok pemrosesan yang mengonversi data sensor mentah menjadi YUV berada dalam urutan arbitrer.
  • Meskipun beberapa unit skala dan pangkas ditampilkan, semua unit penskalaan berbagi kontrol wilayah output (zoom digital). Namun, setiap unit mungkin memiliki resolusi output dan format piksel yang berbeda.

Ringkasan penggunaan API

Berikut ringkasan singkat langkah-langkah untuk menggunakan Android Camera API. Lihat bagian Startup dan urutan operasi yang diharapkan untuk mengetahui perincian mendetail dari langkah-langkah ini, termasuk panggilan API.

  1. Mendengarkan dan menghitung perangkat kamera.
  2. Buka perangkat dan hubungkan pemroses.
  3. Mengonfigurasi output untuk kasus penggunaan target (seperti pengambilan gambar diam atau perekaman).
  4. Buat permintaan untuk kasus penggunaan target.
  5. Merekam/mengulangi permintaan dan burst.
  6. Menerima metadata hasil dan data gambar.
  7. Saat beralih kasus penggunaan, kembali ke langkah 3.

Ringkasan operasi HAL

  • Permintaan asinkron untuk pengambilan gambar berasal dari framework.
  • Perangkat HAL harus memproses permintaan secara berurutan. Untuk setiap permintaan, hasilkan metadata hasil output, dan satu atau beberapa buffer gambar output.
  • First-in, first-out untuk permintaan dan hasil, serta untuk aliran yang dirujuk oleh permintaan berikutnya.
  • Stempel waktu harus identik untuk semua output dari permintaan tertentu, sehingga framework dapat mencocokkannya jika diperlukan.
  • Semua konfigurasi dan status pengambilan (kecuali untuk rutin 3A) dienkapsulasi dalam permintaan dan hasil.
Ringkasan HAL Kamera

Gambar 3. Ringkasan HAL Kamera.

Urutan operasi yang diharapkan dan saat memulai

Bagian ini berisi penjelasan mendetail tentang langkah-langkah yang diharapkan saat menggunakan API kamera. Untuk definisi antarmuka HIDL, lihat platform/hardware/interfaces/camera/.

Mencantumkan, membuka perangkat kamera, dan membuat sesi aktif

  1. Setelah inisialisasi, framework mulai memproses penyedia kamera yang ada yang menerapkan antarmuka ICameraProvider. Jika penyedia atau penyedia tersebut ada, framework akan mencoba membuat koneksi.
  2. Framework menghitung perangkat kamera melalui ICameraProvider::getCameraIdList.
  3. Framework membuat instance ICameraDevice baru dengan memanggil ICameraProvider::getCameraDeviceInterface_VX_X masing-masing.
  4. Framework memanggil ICameraDevice::open untuk membuat sesi pengambilan aktif ICameraDeviceSession baru.

Menggunakan sesi kamera aktif

  1. Framework memanggil ICameraDeviceSession::configureStreams dengan daftar aliran input/output ke perangkat HAL.
  2. Framework meminta setelan default untuk beberapa kasus penggunaan dengan panggilan ke ICameraDeviceSession::constructDefaultRequestSettings. Hal ini dapat terjadi kapan saja setelah ICameraDeviceSession dibuat oleh ICameraDevice::open.
  3. Framework membuat dan mengirim permintaan pengambilan pertama ke HAL dengan setelan berdasarkan salah satu set setelan default, dan dengan setidaknya satu aliran output yang telah didaftarkan sebelumnya oleh framework. Ini dikirim ke HAL dengan ICameraDeviceSession::processCaptureRequest. HAL harus memblokir kembalinya panggilan ini hingga siap untuk mengirim permintaan berikutnya.
  4. Framework terus mengirimkan permintaan dan memanggil ICameraDeviceSession::constructDefaultRequestSettings untuk mendapatkan buffer setelan default untuk kasus penggunaan lain sesuai kebutuhan.
  5. Saat pengambilan permintaan dimulai (sensor mulai mengekspos untuk pengambilan), HAL memanggil ICameraDeviceCallback::notify dengan pesan SHUTTER, termasuk nomor frame dan stempel waktu untuk awal eksposur. Callback notifikasi ini tidak harus terjadi sebelum panggilan processCaptureResult pertama untuk permintaan, tetapi tidak ada hasil yang dikirimkan ke aplikasi untuk pengambilan hingga setelah notify untuk pengambilan tersebut dipanggil.
  6. Setelah beberapa penundaan pipeline, HAL mulai menampilkan pengambilan yang telah selesai ke framework dengan ICameraDeviceCallback::processCaptureResult. Respons ini ditampilkan dalam urutan yang sama dengan pengiriman permintaan. Beberapa permintaan dapat berjalan sekaligus, bergantung pada kedalaman pipeline perangkat HAL kamera.

Setelah beberapa waktu, salah satu hal berikut akan terjadi:

  • Framework berhenti mengirimkan permintaan baru, menunggu penyelesaian pengambilan gambar yang ada (semua buffer terisi, semua hasil ditampilkan), lalu memanggil ICameraDeviceSession::configureStreams lagi. Tindakan ini akan mereset hardware dan pipeline kamera untuk serangkaian aliran input/output baru. Beberapa streaming dapat digunakan kembali dari konfigurasi sebelumnya. Kemudian, framework melanjutkan dari permintaan pengambilan pertama ke HAL, jika setidaknya satu aliran output terdaftar tetap ada. (Jika tidak, ICameraDeviceSession::configureStreams harus dilakukan terlebih dahulu.)
  • Framework dapat memanggil ICameraDeviceSession::close untuk mengakhiri sesi kamera. Metode ini dapat dipanggil kapan saja saat tidak ada panggilan lain dari framework yang aktif, meskipun panggilan mungkin diblokir hingga semua pengambilan data yang sedang berlangsung selesai (semua hasil ditampilkan, semua buffer diisi). Setelah panggilan close ditampilkan, tidak ada lagi panggilan ke ICameraDeviceCallback yang diizinkan dari HAL. Setelah panggilan close sedang berlangsung, framework tidak dapat memanggil fungsi perangkat HAL lainnya.
  • Jika terjadi error atau peristiwa asinkron lainnya, HAL harus memanggil ICameraDeviceCallback::notify dengan pesan error/peristiwa yang sesuai. Setelah kembali dari notifikasi error fatal di seluruh perangkat, HAL harus bertindak seolah-olah close telah dipanggil. Namun, HAL harus membatalkan atau menyelesaikan semua pengambilan gambar yang belum selesai sebelum memanggil notify, sehingga setelah notify dipanggil dengan error fatal, framework tidak akan menerima panggilan balik lebih lanjut dari perangkat. Metode selain close harus menampilkan -ENODEV atau NULL setelah metode notify menampilkan pesan error fatal.
Alur operasi kamera

Gambar 4. Alur pengoperasian kamera.

Tingkat hardware

Perangkat kamera dapat menerapkan beberapa tingkat hardware, bergantung pada kemampuannya. Untuk mengetahui informasi selengkapnya, lihat tingkat hardware yang didukung.

Interaksi antara permintaan pengambilan aplikasi, kontrol 3A, dan pipeline pemrosesan

Bergantung pada setelan di blok kontrol 3A, pipeline kamera mengabaikan beberapa parameter dalam permintaan pengambilan gambar aplikasi dan menggunakan nilai yang diberikan oleh rutin kontrol 3A. Misalnya, saat eksposur otomatis aktif, parameter waktu eksposur, durasi frame, dan sensitivitas sensor dikontrol oleh algoritma 3A platform, dan nilai yang ditentukan aplikasi akan diabaikan. Nilai yang dipilih untuk frame oleh rutin 3A harus dilaporkan dalam metadata output. Tabel berikut menjelaskan berbagai mode blok kontrol 3A dan properti yang dikontrol oleh mode ini. Lihat file platform/system/media/camera/docs/docs.html untuk mengetahui definisi properti ini.

Parameter Negara Bagian Properti yang dikontrol
android.control.aeMode OFF Tidak ada.
ON android.sensor.exposureTime, android.sensor.frameDuration, android.sensor.sensitivity, android.lens.aperture (jika didukung), dan android.lens.filterDensity (jika didukung).
ON_AUTO_FLASH Semuanya adalah ON, ditambah android.flash.firingPower, android.flash.firingTime, dan android.flash.mode.
ON_ALWAYS_FLASH Sama seperti ON_AUTO_FLASH.
ON_AUTO_FLASH_RED_EYE Sama seperti ON_AUTO_FLASH.
android.control.awbMode OFF Tidak ada.
WHITE_BALANCE_* android.colorCorrection.transform. Penyesuaian khusus platform jika android.colorCorrection.mode adalah FAST atau HIGH_QUALITY.
android.control.afMode OFF Tidak ada
FOCUS_MODE_* android.lens.focusDistance
android.control.videoStabilization OFF Tidak ada.
ON Dapat menyesuaikan android.scaler.cropRegion untuk menerapkan stabilisasi video.
android.control.mode OFF AE, AWB, dan AF dinonaktifkan.
AUTO Setelan AE, AWB, dan AF individual digunakan.
SCENE_MODE_* Dapat mengganti semua parameter yang tercantum di atas. Kontrol 3A individual dinonaktifkan.

Semua kontrol dalam blok pemrosesan gambar pada Gambar 2 beroperasi dengan prinsip yang serupa, dan setiap blok memiliki tiga mode:

  • OFF: Blok pemrosesan ini dinonaktifkan. Blok penyesuaian demosaik, koreksi warna, dan kurva nada tidak dapat dinonaktifkan.
  • FAST: Dalam mode ini, blok pemrosesan mungkin tidak memperlambat kecepatan frame output dibandingkan dengan mode OFF, tetapi harus menghasilkan output berkualitas terbaik yang dapat dihasilkan mengingat batasan tersebut. Biasanya, ini akan digunakan untuk mode pratinjau atau perekaman video, atau pengambilan gambar burst untuk gambar diam. Pada beberapa perangkat, hal ini mungkin setara dengan mode OFF (tidak ada pemrosesan yang dapat dilakukan tanpa memperlambat kecepatan frame), dan pada beberapa perangkat, hal ini mungkin setara dengan mode HIGH_QUALITY (kualitas terbaik tetap tidak memperlambat kecepatan frame).
  • HIGH_QUALITY: Dalam mode ini, blok pemrosesan harus menghasilkan hasil kualitas terbaik yang mungkin, sehingga memperlambat kecepatan frame output sesuai kebutuhan. Biasanya, ini akan digunakan untuk pengambilan gambar diam berkualitas tinggi. Beberapa blok menyertakan kontrol manual yang dapat dipilih secara opsional, bukan FAST atau HIGH_QUALITY. Misalnya, blok koreksi warna mendukung matriks transformasi warna, sedangkan penyesuaian kurva nada mendukung kurva pemetaan nada global arbitrer.

Kecepatan frame maksimum yang dapat didukung oleh subsistem kamera adalah fungsi dari banyak faktor:

  • Resolusi yang diminta dari aliran gambar output
  • Ketersediaan mode pengelompokan/pengecualian pada imager
  • Bandwidth antarmuka imager
  • Bandwidth berbagai blok pemrosesan ISP

Faktor-faktor ini dapat sangat bervariasi antara ISP dan sensor yang berbeda, sehingga antarmuka HAL kamera mencoba mengabstraksi batasan bandwidth ke dalam model sesederhana mungkin. Model yang ditampilkan memiliki karakteristik berikut:

  • Sensor gambar selalu dikonfigurasi untuk menghasilkan resolusi terkecil yang mungkin diberikan ukuran aliran output yang diminta aplikasi. Resolusi terkecil ditentukan sebagai setidaknya sama besar dengan ukuran streaming output terbesar yang diminta.
  • Setiap permintaan dapat menggunakan satu atau semua aliran output yang saat ini dikonfigurasi, sehingga sensor dan ISP harus dikonfigurasi untuk mendukung penskalaan pengambilan tunggal ke semua aliran secara bersamaan.
  • Streaming JPEG bertindak seperti streaming YUV yang diproses untuk permintaan yang tidak menyertakannya; dalam permintaan yang merujuknya secara langsung, streaming JPEG bertindak sebagai streaming JPEG.
  • Prosesor JPEG dapat berjalan secara bersamaan dengan pipeline kamera lainnya, tetapi tidak dapat memproses lebih dari satu pengambilan gambar dalam satu waktu.