Subsistem HAL

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

Permintaan

Framework aplikasi mengeluarkan permintaan untuk hasil yang diambil ke subsistem kamera. Satu permintaan sesuai dengan satu set hasil. Permintaan merangkum semua informasi konfigurasi tentang pengambilan dan pemrosesan hasil tersebut. Hal ini mencakup hal-hal seperti resolusi dan format piksel; kontrol sensor, lensa, dan flash manual; 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 berjalan sekaligus, dan pengiriman permintaan tidak memblokir. Permintaan selalu diproses sesuai urutan penerimaannya.

Model permintaan kamera

Gambar 1. Model kamera.

Subsistem HAL dan kamera

Subsistem kamera menyertakan implementasi untuk komponen dalam pipeline kamera seperti algoritma 3A dan kontrol pemrosesan. HAL kamera menyediakan antarmuka untuk Anda 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. Namun, model ini cukup mirip dengan pipeline pemrosesan nyata sehingga Anda dapat memetakannya ke hardware secara efisien. Selain itu, model ini cukup abstrak untuk memungkinkan beberapa algoritma dan urutan operasi yang berbeda tanpa mengorbankan kualitas, efisiensi, atau kompatibilitas lintas perangkat.

Pipeline kamera juga mendukung pemicu yang dapat diinisiasi oleh framework aplikasi untuk mengaktifkan hal-hal seperti fokus otomatis. Pipeline ini juga mengirimkan notifikasi kembali ke framework aplikasi, yang memberi tahu aplikasi tentang peristiwa seperti kunci 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 ditentukan dengan baik dalam rilis awal. Pipeline kamera membuat asumsi berikut:

  • Output Bayer RAW tidak menjalani pemrosesan di dalam ISP.
  • Statistik dibuat berdasarkan data sensor mentah.
  • Berbagai blok pemrosesan yang mengonversi data sensor mentah ke YUV berada dalam urutan arbitrer.
  • Meskipun beberapa unit skala dan pemangkasan ditampilkan, semua unit penskala 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 API kamera Android. Lihat bagian Urutan operasi dan startup yang diharapkan untuk mengetahui detail langkah-langkah ini, termasuk panggilan API.

  1. Memproses dan menghitung perangkat kamera.
  2. Membuka perangkat dan menghubungkan pemroses.
  3. Mengonfigurasi output untuk kasus penggunaan target (seperti pengambilan gambar atau perekaman).
  4. Membuat permintaan untuk kasus penggunaan target.
  5. Mengambil/mengulang 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 streaming yang direferensikan oleh permintaan berikutnya.
  • Stempel waktu harus identik untuk semua output dari permintaan tertentu, sehingga framework dapat mencocokkannya jika diperlukan.
  • Semua konfigurasi dan status pengambilan gambar (kecuali untuk rutin 3A) dienkapsulasi dalam permintaan dan hasil.

Ringkasan HAL Kamera

Gambar 3. Ringkasan HAL kamera.

Urutan operasi dan startup yang diharapkan

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

Menghitung, membuka perangkat kamera, dan membuat sesi aktif

  1. Setelah inisialisasi, framework mulai memproses penyedia kamera yang ada yang menerapkan antarmuka ICameraProvider. Jika penyedia tersebut atau penyedia 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 yang sesuai.
  4. Framework memanggil ICameraDevice::open untuk membuat sesi pengambilan gambar aktif baru ICameraDeviceSession.

Menggunakan sesi kamera aktif

  1. Framework memanggil ICameraDeviceSession::configureStreams dengan daftar streaming 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 mengirimkan permintaan pengambilan gambar pertama ke HAL dengan setelan berdasarkan salah satu set setelan default, dan dengan setidaknya satu streaming output yang telah didaftarkan sebelumnya oleh framework. Hal ini dikirim ke HAL dengan ICameraDeviceSession::processCaptureRequest. HAL harus memblokir pengembalian 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 jika diperlukan.
  5. Saat pengambilan gambar permintaan dimulai (sensor mulai mengekspos untuk pengambilan gambar), HAL memanggil ICameraDeviceCallback::notify dengan pesan SHUTTER, termasuk nomor frame dan stempel waktu untuk awal eksposur. Callback notifikasi ini tidak harus terjadi sebelum panggilan pertama processCaptureResult untuk permintaan, tetapi tidak ada hasil yang dikirimkan ke aplikasi untuk pengambilan gambar hingga setelah notify untuk pengambilan gambar tersebut dipanggil.
  6. Setelah beberapa penundaan pipeline, HAL mulai menampilkan pengambilan gambar yang telah selesai ke framework dengan ICameraDeviceCallback::processCaptureResult. Pengambilan gambar ini ditampilkan dalam urutan yang sama dengan permintaan yang dikirimkan. 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 pengambilan gambar yang ada selesai (semua buffer terisi, semua hasil ditampilkan), lalu memanggil ICameraDeviceSession::configureStreams lagi. Tindakan ini akan mereset hardware dan pipeline kamera untuk set streaming input/output baru. Beberapa streaming dapat digunakan kembali dari konfigurasi sebelumnya. Framework kemudian melanjutkan dari permintaan pengambilan gambar pertama ke HAL, jika setidaknya satu streaming output terdaftar tetap ada. (Jika tidak, ICameraDeviceSession::configureStreams harus dilakukan terlebih dahulu.)
  • Framework dapat memanggil ICameraDeviceSession::close untuk mengakhiri sesi kamera. Hal ini dapat dipanggil kapan saja saat tidak ada panggilan lain dari framework yang aktif, meskipun panggilan mungkin diblokir hingga semua pengambilan gambar yang sedang berjalan selesai (semua hasil ditampilkan, semua buffer terisi). Setelah panggilan close ditampilkan, tidak ada lagi panggilan ke ICameraDeviceCallback 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 sedang berlangsung sebelum memanggil notify, sehingga setelah notify dipanggil dengan error fatal, framework tidak akan menerima callback 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 operasional 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 gambar 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, waktu eksposur, durasi frame, dan parameter 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 Semua 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.

Kontrol di blok pemrosesan gambar pada Gambar 2 beroperasi berdasarkan prinsip yang sama, dan setiap blok memiliki tiga mode:

  • OFF: Blok pemrosesan ini dinonaktifkan. Blok demosaic, koreksi warna, dan penyesuaian 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, mode ini akan digunakan untuk pratinjau atau perekaman video, atau pengambilan gambar burst untuk gambar. Di beberapa perangkat, mode ini mungkin setara dengan OFF mode (tidak ada pemrosesan yang dapat dilakukan tanpa memperlambat kecepatan frame), dan di beberapa perangkat, mode ini mungkin setara dengan HIGH_QUALITY mode (kualitas terbaik tetap tidak memperlambat kecepatan frame).
  • HIGH_QUALITY: Dalam mode ini, blok pemrosesan harus menghasilkan hasil berkualitas terbaik, memperlambat kecepatan frame output sesuai kebutuhan. Biasanya, mode ini akan digunakan untuk pengambilan gambar 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 streaming gambar output
  • Ketersediaan mode binning/skipping 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 mengingat ukuran streaming output yang diminta aplikasi. Resolusi terkecil ditentukan sebagai setidaknya sebesar ukuran streaming output terbesar yang diminta.
  • Setiap permintaan dapat menggunakan salah satu atau semua streaming output yang saat ini dikonfigurasi, sehingga sensor dan ISP harus dikonfigurasi untuk mendukung penskalaan satu pengambilan gambar ke semua streaming secara bersamaan.
  • Streaming JPEG bertindak seperti streaming YUV yang diproses untuk permintaan yang tidak disertakan ; dalam permintaan yang direferensikan secara langsung, streaming JPEG bertindak sebagai streaming JPEG.
  • Prosesor JPEG dapat berjalan secara serentak dengan bagian pipeline kamera lainnya, tetapi tidak dapat memproses lebih dari satu pengambilan gambar sekaligus.