Subsistem HAL

Permintaan

Kerangka kerja aplikasi mengeluarkan permintaan untuk hasil yang diambil ke subsistem kamera. Satu permintaan sesuai dengan satu set hasil. Permintaan merangkum semua informasi konfigurasi tentang penangkapan dan pemrosesan hasil tersebut. Ini mencakup hal-hal seperti resolusi dan format piksel; sensor manual, lensa, dan kontrol lampu kilat; 3A mode operasi; kontrol pemrosesan RAW ke YUV; dan pembuatan statistik. Ini memungkinkan lebih banyak kontrol atas keluaran dan pemrosesan hasil. Beberapa permintaan dapat dalam penerbangan sekaligus, dan mengirimkan permintaan tidak memblokir. 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 pipeline kamera adalah virtual dan tidak secara langsung sesuai dengan ISP nyata mana pun. Namun, ini cukup mirip dengan pipeline pemrosesan nyata sehingga Anda dapat memetakannya ke perangkat keras Anda secara efisien. Selain itu, cukup abstrak untuk memungkinkan beberapa algoritme dan urutan operasi yang berbeda tanpa mengorbankan kualitas, efisiensi, atau kompatibilitas lintas-perangkat.

Saluran kamera juga mendukung pemicu yang dapat dimulai oleh kerangka aplikasi untuk mengaktifkan hal-hal seperti fokus otomatis. Itu juga mengirimkan pemberitahuan kembali ke kerangka aplikasi, memberi tahu aplikasi tentang peristiwa seperti kunci atau kesalahan fokus otomatis.

Gambar 2. Pipa kamera

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

• Output RAW Bayer tidak mengalami pemrosesan 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.
• Sementara beberapa skala dan unit pangkas ditampilkan, semua unit penskala berbagi kontrol wilayah keluaran (zoom digital). Namun, setiap unit mungkin memiliki resolusi output dan format piksel yang berbeda.

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

1. Dengarkan dan sebutkan perangkat kamera.
2. Buka perangkat dan hubungkan 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 ledakan.
6. Menerima metadata hasil dan data gambar.
7. Saat beralih kasus penggunaan, kembali ke langkah 3.

Ringkasan operasi HAL

• Permintaan asinkron untuk tangkapan berasal dari kerangka kerja.
• Perangkat HAL harus memproses permintaan secara berurutan. Dan untuk setiap permintaan, hasilkan metadata hasil keluaran, dan satu atau lebih buffer gambar keluaran.
• Masuk pertama, keluar pertama untuk permintaan dan hasil, dan untuk aliran yang dirujuk oleh permintaan berikutnya.
• Stempel waktu harus identik untuk semua keluaran dari permintaan yang diberikan, sehingga kerangka kerja dapat mencocokkannya jika diperlukan.
• Semua konfigurasi dan status pengambilan (kecuali untuk rutinitas 3A) dienkapsulasi dalam permintaan dan hasil.

Gambar 3. Ikhtisar HAL Kamera

Startup dan urutan operasi yang diharapkan

Bagian ini berisi penjelasan rinci tentang langkah-langkah yang diharapkan saat menggunakan API kamera. Silakan lihat platform/perangkat keras/antarmuka/kamera/ untuk definisi antarmuka HIDL.

Menghitung, membuka perangkat kamera, dan membuat sesi aktif

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

Menggunakan sesi kamera aktif

1. Kerangka kerja memanggil ICameraDeviceSession::configureStreams() dengan daftar aliran input/output ke perangkat HAL.
2. Kerangka kerja meminta pengaturan default untuk beberapa kasus penggunaan dengan panggilan ke ICameraDeviceSession::constructDefaultRequestSettings() . 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 hingga siap untuk mengirim permintaan berikutnya.
4. Kerangka kerja terus mengirimkan permintaan dan memanggil ICameraDeviceSession::constructDefaultRequestSettings() untuk mendapatkan buffer pengaturan default untuk kasus penggunaan lain yang diperlukan.
5. Saat pengambilan permintaan dimulai (sensor mulai terbuka untuk pengambilan), HAL memanggil ICameraDeviceCallback::notify() dengan pesan SHUTTER, termasuk nomor bingkai dan stempel waktu untuk memulai pemaparan. Notifikasi callback 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 mengembalikan tangkapan yang sudah selesai ke kerangka kerja dengan ICameraDeviceCallback::processCaptureResult() . Ini dikembalikan dalam urutan yang sama dengan permintaan yang diajukan. Beberapa permintaan dapat diterbangkan sekaligus, tergantung pada kedalaman saluran perangkat HAL kamera.

Setelah beberapa waktu, salah satu hal berikut akan terjadi:

• Kerangka kerja mungkin berhenti mengirimkan permintaan baru, menunggu pengambilan yang ada selesai (semua buffer terisi, semua hasil dikembalikan), lalu memanggil ICameraDeviceSession::configureStreams() lagi. Ini mengatur ulang perangkat keras dan saluran kamera untuk serangkaian aliran input/output baru. Beberapa aliran dapat digunakan kembali dari konfigurasi sebelumnya. Kerangka kerja kemudian berlanjut dari permintaan penangkapan pertama ke HAL, jika setidaknya satu aliran keluaran terdaftar tetap ada. (Jika tidak, ICameraDeviceSession::configureStreams() diperlukan terlebih dahulu.)
• Kerangka kerja 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 tangkapan dalam penerbangan telah selesai (semua hasil dikembalikan, semua buffer terisi). Setelah panggilan close() kembali, tidak ada lagi panggilan ke ICameraDeviceCallback yang diizinkan dari HAL. Setelah panggilan close() sedang berlangsung, framework mungkin tidak memanggil fungsi perangkat HAL lainnya.
• Jika terjadi kesalahan atau peristiwa 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 tangkapan yang belum selesai 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 menerapkan beberapa tingkat perangkat keras tergantung pada kemampuannya. Untuk informasi lebih lanjut, lihat tingkat perangkat keras yang didukung .

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

Bergantung pada pengaturan di blok kontrol 3A, pipeline 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 yang ditentukan aplikasi apa pun akan diabaikan. Nilai yang dipilih untuk frame oleh rutinitas 3A harus dilaporkan dalam metadata keluaran. Tabel berikut menjelaskan mode yang berbeda dari blok kontrol 3A dan properti yang dikendalikan oleh mode ini. Lihat file platform/system/media/camera/docs/docs.html untuk definisi properti ini.

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

• OFF: Blok pemrosesan ini dinonaktifkan. Blok penyesuaian demosaic, koreksi warna, dan kurva nada tidak dapat dinonaktifkan.
• CEPAT: Dalam mode ini, blok pemrosesan mungkin tidak memperlambat laju bingkai output dibandingkan dengan mode OFF, tetapi sebaliknya harus menghasilkan output kualitas terbaik yang dapat diberikan pembatasan itu. 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 kualitas terbaik, memperlambat laju bingkai keluaran sesuai kebutuhan. Biasanya, ini akan digunakan untuk pengambilan gambar diam berkualitas tinggi. Beberapa blok menyertakan kontrol manual yang dapat dipilih secara opsional sebagai ganti 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 bingkai maksimum yang dapat didukung oleh subsistem kamera adalah fungsi dari banyak faktor:

• Resolusi yang diminta dari aliran gambar keluaran
• 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 untuk mengabstraksikan batasan bandwidth menjadi model sesederhana mungkin. Model yang disajikan memiliki ciri-ciri sebagai berikut:

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