Subsistem HAL

Permintaan

Kerangka aplikasi mengeluarkan permintaan hasil pengambilan ke subsistem kamera. Satu permintaan sesuai dengan satu set hasil. Permintaan merangkum semua informasi konfigurasi tentang pengambilan dan pemrosesan hasil tersebut. Ini mencakup hal-hal seperti resolusi dan format piksel; sensor manual, lensa, dan kontrol lampu kilat; mode operasi 3A; Kontrol pemrosesan RAW ke YUV; dan pembuatan statistik. Hal ini memungkinkan kontrol yang lebih besar terhadap keluaran dan pemrosesan hasil. Beberapa permintaan dapat diajukan sekaligus, dan pengajuan permintaan tidak bersifat pemblokiran. Dan permintaan selalu diproses sesuai urutan penerimaannya.

Gambar 1. Model kamera

Subsistem HAL dan kamera

Subsistem kamera mencakup implementasi untuk komponen dalam saluran kamera seperti algoritma 3A dan kontrol pemrosesan. Kamera HAL menyediakan antarmuka bagi Anda untuk mengimplementasikan versi komponen ini. Untuk menjaga kompatibilitas lintas platform antara beberapa produsen perangkat dan vendor Image Signal Processor (ISP, atau sensor kamera), model saluran kamera bersifat virtual dan tidak berhubungan langsung dengan ISP sebenarnya. Namun, ini cukup mirip dengan pipeline pemrosesan sebenarnya sehingga Anda dapat memetakannya ke perangkat keras Anda secara efisien. Selain itu, 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. Ini juga mengirimkan pemberitahuan kembali ke kerangka aplikasi, memberi tahu aplikasi tentang kejadian seperti kunci fokus otomatis atau kesalahan.

Gambar 2. Pipa kamera

Harap diperhatikan, beberapa blok pemrosesan gambar yang ditunjukkan pada diagram di atas tidak terdefinisi dengan baik pada rilis awal. Pipeline kamera membuat asumsi berikut:

• Output RAW Bayer tidak diproses di dalam ISP.
• Statistik dihasilkan berdasarkan data sensor mentah.
• Berbagai blok pemrosesan yang mengubah data sensor mentah menjadi YUV berada dalam urutan yang berubah-ubah.
• Meskipun beberapa unit skala dan pangkas ditampilkan, semua unit penskala berbagi kontrol wilayah keluaran (zoom digital). Namun, setiap unit mungkin memiliki resolusi keluaran dan format piksel yang berbeda.

Ringkasan penggunaan API
Ini adalah ringkasan singkat langkah-langkah menggunakan API kamera Android. Lihat bagian Startup dan urutan operasi yang diharapkan untuk rincian langkah-langkah ini, termasuk panggilan API.

1. Dengarkan dan perhitungkan perangkat kamera.
2. Buka perangkat dan sambungkan pendengar.
3. Konfigurasikan output untuk kasus penggunaan target (seperti pengambilan gambar diam, perekaman, dll.).
4. Buat permintaan untuk kasus penggunaan target.
5. Tangkap/ulangi permintaan dan burst.
6. Menerima metadata hasil dan data gambar.
7. Saat berpindah kasus penggunaan, kembali ke langkah 3.

Ringkasan operasi HAL

• Permintaan pengambilan yang tidak sinkron berasal dari kerangka kerja.
• Perangkat HAL harus memproses permintaan secara berurutan. Dan untuk setiap permintaan, menghasilkan metadata hasil keluaran, dan satu atau lebih buffer gambar keluaran.
• Masuk pertama, keluar pertama untuk permintaan dan hasil, dan untuk aliran yang direferensikan oleh permintaan berikutnya.
• Stempel waktu harus sama untuk semua keluaran dari permintaan tertentu, sehingga kerangka kerja dapat mencocokkannya jika diperlukan.
• Semua konfigurasi dan status pengambilan (kecuali untuk rutinitas 3A) dirangkum dalam permintaan dan hasil.

Gambar 3. Ikhtisar Kamera HAL

Startup dan urutan operasi yang diharapkan

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

Menghitung, membuka perangkat kamera dan membuat sesi aktif

1. Setelah inisialisasi, kerangka kerja mulai mendengarkan penyedia kamera mana pun yang mengimplementasikan antarmuka ICameraProvider . Jika penyedia atau penyedia tersebut ada, kerangka kerja akan mencoba membuat koneksi.
2. Kerangka kerja ini menghitung perangkat kamera melalui ICameraProvider::getCameraIdList() .
3. Kerangka kerja ini membuat instance ICameraDevice baru dengan memanggil ICameraProvider::getCameraDeviceInterface_VX_X() masing-masing.
4. Kerangka kerja ini memanggil ICameraDevice::open() untuk membuat sesi pengambilan aktif baru ICameraDeviceSession.

Menggunakan sesi kamera aktif

1. Kerangka kerja ini memanggil ICameraDeviceSession::configureStreams() dengan daftar aliran input/output ke perangkat HAL.
2. Kerangka kerja ini meminta pengaturan default untuk beberapa kasus penggunaan dengan panggilan ke ICameraDeviceSession::constructDefaultRequestSettings() . Hal ini dapat terjadi kapan saja setelah ICameraDeviceSession dibuat oleh ICameraDevice::open .
3. Kerangka kerja membangun dan mengirimkan permintaan penangkapan pertama ke HAL dengan pengaturan berdasarkan salah satu set pengaturan default, dan dengan setidaknya satu aliran keluaran yang telah didaftarkan sebelumnya oleh kerangka kerja. Ini dikirim ke HAL dengan ICameraDeviceSession::processCaptureRequest() . HAL harus memblokir kembalinya panggilan ini sampai siap untuk mengirimkan permintaan berikutnya.
4. Kerangka kerja ini terus mengirimkan permintaan dan memanggil ICameraDeviceSession::constructDefaultRequestSettings() untuk mendapatkan buffer pengaturan default untuk kasus penggunaan lain jika diperlukan.
5. Saat pengambilan permintaan dimulai (sensor mulai mengekspos untuk pengambilan), HAL memanggil ICameraDeviceCallback::notify() dengan pesan SHUTTER, termasuk nomor frame dan stempel waktu untuk memulai eksposur. Callback notifikasi ini tidak harus terjadi sebelum panggilan processCaptureResult() pertama untuk suatu permintaan, namun tidak ada hasil yang dikirim ke aplikasi untuk pengambilan hingga notify() untuk pengambilan tersebut dipanggil.
6. Setelah beberapa penundaan alur, HAL mulai mengembalikan tangkapan yang telah selesai ke kerangka kerja dengan ICameraDeviceCallback::processCaptureResult() . Ini dikembalikan dalam urutan yang sama dengan permintaan yang diajukan. Beberapa permintaan dapat dilakukan sekaligus, bergantung pada kedalaman saluran pipa perangkat HAL kamera.

Setelah beberapa waktu, salah satu hal berikut akan terjadi:

• Kerangka kerja mungkin berhenti mengirimkan permintaan baru, menunggu hingga pengambilan yang ada selesai (semua buffer terisi, semua hasil dikembalikan), lalu memanggil ICameraDeviceSession::configureStreams() lagi. Tindakan ini akan menyetel ulang perangkat keras dan saluran kamera untuk serangkaian aliran input/output baru. Beberapa aliran mungkin digunakan kembali dari konfigurasi sebelumnya. Kerangka kerja kemudian melanjutkan dari permintaan penangkapan pertama ke HAL, jika setidaknya ada satu aliran keluaran yang terdaftar. (Jika tidak, ICameraDeviceSession::configureStreams() diperlukan terlebih dahulu.)
• Framework ini dapat memanggil ICameraDeviceSession::close() untuk mengakhiri sesi kamera. Ini dapat dipanggil kapan saja ketika tidak ada panggilan lain dari kerangka kerja yang aktif, meskipun panggilan tersebut dapat diblokir hingga semua pengambilan dalam penerbangan selesai (semua hasil dikembalikan, semua buffer terisi). Setelah panggilan close() kembali, tidak ada lagi panggilan ke ICameraDeviceCallback yang diizinkan dari HAL. Setelah panggilan close() berlangsung, framework tidak boleh memanggil fungsi perangkat HAL lainnya.
• Jika terjadi kesalahan atau kejadian asinkron lainnya, HAL harus memanggil ICameraDeviceCallback::notify() dengan pesan kesalahan/peristiwa yang sesuai. Setelah kembali dari pemberitahuan kesalahan fatal di seluruh perangkat, HAL harus bertindak seolah-olah close() telah dipanggil. Namun, HAL harus membatalkan atau menyelesaikan semua pengambilan yang belum dilakukan sebelum memanggil notify() , sehingga setelah notify() dipanggil dengan kesalahan fatal, framework tidak akan menerima callback lebih lanjut dari perangkat. Metode selain close() harus mengembalikan -ENODEV atau NULL setelah metode notify() kembali dari pesan kesalahan fatal.

Gambar 4. Alur operasional kamera

Tingkat perangkat keras

Perangkat kamera dapat mengimplementasikan beberapa level perangkat keras tergantung pada kemampuannya. Untuk informasi lebih lanjut, lihat tingkat perangkat keras yang didukung .

Interaksi antara permintaan penangkapan aplikasi, kontrol 3A, dan alur pemrosesan

Bergantung pada pengaturan di blok kontrol 3A, alur kamera mengabaikan beberapa parameter dalam permintaan pengambilan aplikasi dan sebagai gantinya menggunakan nilai yang disediakan oleh rutinitas kontrol 3A. Misalnya, saat eksposur otomatis aktif, waktu eksposur, durasi bingkai, dan parameter sensitivitas sensor dikontrol oleh algoritme platform 3A, dan nilai apa pun yang ditentukan aplikasi akan diabaikan. Nilai yang dipilih untuk frame oleh rutinitas 3A harus dilaporkan dalam metadata keluaran. 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.

Kontrol di blok Pemrosesan Gambar pada Gambar 2 semuanya beroperasi dengan prinsip yang sama, dan umumnya setiap blok memiliki tiga mode:

• MATI: Blok pemrosesan ini dinonaktifkan. Blok demosaik, koreksi warna, dan penyesuaian kurva nada tidak dapat dinonaktifkan.
• CEPAT: Dalam mode ini, blok pemrosesan tidak boleh memperlambat kecepatan bingkai keluaran dibandingkan dengan mode OFF, namun sebaliknya harus menghasilkan keluaran dengan kualitas terbaik mengingat batasan tersebut. Biasanya, ini akan digunakan untuk mode pratinjau atau perekaman video, atau pengambilan burst untuk gambar diam. Pada beberapa perangkat, ini mungkin setara dengan mode OFF (tidak ada pemrosesan yang dapat dilakukan tanpa memperlambat kecepatan bingkai), dan pada beberapa perangkat, ini mungkin setara dengan mode HIGH_QUALITY (kualitas terbaik tetap tidak memperlambat kecepatan bingkai).
• HIGH_QUALITY: Dalam mode ini, blok pemrosesan harus menghasilkan hasil dengan kualitas terbaik, memperlambat kecepatan bingkai keluaran 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 yang berubah-ubah.

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

• Resolusi aliran gambar keluaran yang diminta
• Ketersediaan mode binning/skipping pada imager
• Bandwidth antarmuka imager
• Bandwidth dari berbagai blok pemrosesan ISP

Karena faktor-faktor ini dapat sangat bervariasi antara ISP dan sensor yang berbeda, antarmuka HAL kamera mencoba mengabstraksi batasan bandwidth ke dalam model yang sesederhana mungkin. Model yang disajikan memiliki ciri-ciri sebagai berikut:

• Sensor gambar selalu dikonfigurasi untuk mengeluarkan resolusi sekecil mungkin berdasarkan ukuran aliran keluaran yang diminta aplikasi. Resolusi terkecil didefinisikan sebagai setidaknya sama besar dengan ukuran aliran keluaran terbesar yang diminta.
• Karena permintaan apa pun dapat menggunakan salah satu atau semua aliran keluaran yang dikonfigurasi saat ini, sensor dan ISP harus dikonfigurasi untuk mendukung penskalaan satu tangkapan ke semua aliran secara bersamaan.
• Aliran JPEG bertindak seperti aliran YUV yang diproses untuk permintaan yang tidak disertakan; dalam permintaan yang direferensikan secara langsung, mereka bertindak sebagai aliran JPEG.
• Prosesor JPEG dapat berjalan secara bersamaan ke seluruh saluran kamera tetapi tidak dapat memproses lebih dari satu pengambilan dalam satu waktu.