Subsistem HAL

Permintaan

Framework aplikasi mengeluarkan permintaan untuk hasil yang diambil ke subsistem kamera. Satu permintaan sesuai dengan satu kumpulan hasil. Permintaan merangkum semua informasi konfigurasi tentang pengambilan dan pemrosesan hasil tersebut. Ini termasuk hal-hal seperti resolusi dan format {i>pixel<i}; sensor manual, lensa, dan kontrol flash; Mode operasi 3A; Kontrol pemrosesan RAW ke YUV; dan pembuatan statistik. Hal ini memungkinkan kontrol yang lebih besar atas hasil output, dan pemrosesan. Beberapa permintaan dapat dilakukan sekaligus, dan mengirim permintaan bersifat tidak memblokir. Permintaan itu selalu diproses di urutan penerimaannya.

Gambar 1. Model kamera

HAL dan subsistem kamera

Subsistem kamera mencakup implementasi untuk komponen dalam kamera seperti algoritma 3A dan kontrol pemrosesan. HAL kamera menyediakan antarmuka bagi Anda untuk menerapkan versi komponen ini. Kepada menjaga kompatibilitas lintas platform antara beberapa produsen perangkat dan Vendor Prosesor Sinyal Gambar (ISP, atau sensor kamera), pipeline kamera adalah model virtual dan tidak secara langsung terkait dengan ISP nyata mana pun. Namun, cukup mirip dengan pipeline pemrosesan nyata sehingga Anda dapat memetakannya ke perangkat keras secara efisien. Selain itu, presentasi ini cukup abstrak untuk memungkinkan banyak berbagai algoritma dan urutan operasi tanpa mengorbankan kualitas, efisiensi, atau kompatibilitas lintas-perangkat.

Pipeline kamera juga mendukung pemicu yang dapat diinisiasi oleh framework aplikasi untuk mengaktifkan fitur seperti fokus otomatis. Alat ini juga mengirimkan notifikasi kembali ke framework aplikasi, yang memberi tahu aplikasi tentang peristiwa seperti kunci fokus otomatis atau error.

Gambar 2. Pipeline kamera

Harap diperhatikan bahwa beberapa blok pemrosesan gambar yang ditampilkan dalam diagram di atas tidak telah didefinisikan dengan baik dalam rilis awal. Pipeline kamera menghasilkan hal berikut: asumsi:

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

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

1. Memproses dan menghitung perangkat kamera.
2. Buka perangkat dan hubungkan pemroses.
3. Mengonfigurasi output untuk kasus penggunaan target (seperti pengambilan gambar, perekaman, dll.).
4. Buat permintaan untuk kasus penggunaan target.
5. Tangkap/ulangi permintaan dan burst.
6. Menerima data gambar dan metadata hasil.
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. Dan untuk setiap permintaan, buat metadata hasil output, dan satu atau beberapa buffer gambar output.
• Yang pertama masuk, yang pertama keluar untuk permintaan dan hasil, dan untuk streaming yang dirujuk oleh terhadap permintaan selanjutnya.
• Stempel waktu harus identik untuk semua output dari permintaan tertentu, sehingga {i>framework<i} dapat mencocokkan mereka bersama jika diperlukan.
• Semua konfigurasi dan status perekaman (kecuali untuk rutinitas 3A) adalah dienkapsulasi dalam permintaan dan hasil.

Gambar 3. Ringkasan Camera HAL

Urutan peluncuran dan operasi yang diharapkan

Bagian ini berisi penjelasan terperinci tentang langkah-langkah yang diharapkan saat menggunakan API kamera. Harap lihat platform/hardware/antarmuka/kamera/ untuk antarmuka HIDL definisi.

Menghitung, membuka perangkat kamera, dan membuat sesi aktif

1. Setelah inisialisasi, framework mulai memproses semua hadiah penyedia kamera yang menerapkan Antarmuka ICameraProvider. Jika penyedia atau ada penyedia, kerangka kerja akan mencoba membuat koneksi.
2. Framework ini menyebutkan perangkat kamera melalui ICameraProvider::getCameraIdList().
3. Framework ini membuat instance ICameraDevice baru dengan memanggil metode ICameraProvider::getCameraDeviceInterface_VX_X().
4. Framework ini memanggil ICameraDevice::open() untuk membuat sesi pengambilan aktif, ICameraDeviceSession.

Menggunakan sesi kamera aktif

1. Framework ini memanggil ICameraDeviceSession::configureStreams() dengan daftar aliran input/output ke perangkat HAL.
2. Framework ini meminta setelan default untuk beberapa kasus penggunaan dengan panggilan ke ICameraDeviceSession::constructDefaultRequestSettings(). Hal ini dapat terjadi kapan saja setelah ICameraDeviceSession ditetapkan dibuat oleh ICameraDevice::open.
3. Kerangka kerja membangun dan mengirim permintaan penangkapan pertama ke HAL dengan setelan berdasarkan salah satu dari set setelan default, dan setidaknya stream output yang telah didaftarkan sebelumnya oleh framework. Ini dikirim ke HAL dengan ICameraDeviceSession::processCaptureRequest(). HAL harus memblokir pengembalian panggilan ini hingga siap untuk panggilan berikutnya untuk dikirim.
4. Framework ini akan terus mengirim permintaan dan panggilan ICameraDeviceSession::constructDefaultRequestSettings() untuk mendapatkan {i>buffer<i} setelan default untuk kasus penggunaan lain sesuai kebutuhan.
5. Saat penangkapan permintaan dimulai (sensor mulai mengekspos menangkap), HAL memanggil ICameraDeviceCallback::notify() dengan pesan SHUTTER, termasuk nomor {i>frame<i} dan stempel waktu untuk memulai dari paparan. Callback notifikasi ini tidak harus terjadi sebelum callback processCaptureResult() panggilan untuk permintaan, tetapi tidak ada hasil dikirim ke aplikasi untuk ditangkap sampai setelah notify() untuk rekaman tersebut akan dipanggil.
6. Setelah penundaan pipeline terjadi, HAL mulai mengembalikan rekaman yang telah selesai ke framework dengan ICameraDeviceCallback::processCaptureResult(). Permintaan ini ditampilkan dalam urutan yang sama dengan permintaan yang dikirimkan. Beberapa permintaan dapat diproses sekaligus, tergantung pada kedalaman pipeline perangkat HAL kamera.

Setelah beberapa waktu, salah satu dari hal berikut akan terjadi:

• Framework mungkin berhenti mengirimkan permintaan baru, menunggu pengambilan gambar yang ada untuk diselesaikan (semua buffer terisi, semua hasil ditampilkan), lalu panggil ICameraDeviceSession::configureStreams() untuk mencoba lagi perintah. Perintah ini mereset hardware dan pipeline kamera untuk serangkaian aliran input/output. Beberapa streaming dapat digunakan ulang dari streaming sebelumnya konfigurasi Anda. Framework ini kemudian melanjutkan dari permintaan pengambilan pertama ke HAL, jika setidaknya satu aliran output yang terdaftar tetap ada. (Atau, ICameraDeviceSession::configureStreams() wajib diisi terlebih dahulu.)
• Framework ini dapat memanggil ICameraDeviceSession::close() untuk mengakhiri sesi kamera. Panggilan ini dapat dilakukan kapan saja saat tidak ada panggilan lain dari framework aktif, meskipun panggilan dapat diblokir hingga semua pengambilan gambar yang sedang berlangsung telah selesai (semua hasil ditampilkan, semua buffer terisi). Setelah panggilan close() dikembalikan, tidak ada lagi panggilan ke ICameraDeviceCallback diizinkan dari HAL. Setelah Panggilan close() sedang berlangsung, framework tidak boleh memanggil panggilan Fungsi perangkat HAL.
• Jika terjadi {i>error<i} atau kejadian asinkron lainnya, HAL harus memanggil ICameraDeviceCallback::notify() dengan pesan error/event. Setelah kembali dari notifikasi {i>error<i} di seluruh perangkat yang fatal, HAL harus bertindak seolah-olah close() telah dipanggil. Namun, HAL harus batalkan juga atau menyelesaikan semua rekaman yang belum direkam sebelum memanggil notify(), sehingga setelah notify() dipanggil dengan error fatal, framework tidak akan menerima callback lebih lanjut dari perangkat. Metode selain close() harus ditampilkan -ENODEV atau NULL setelah metode notify() ditampilkan dari error fatal pesan error.

Gambar 4. Alur operasional kamera

Level hardware

Perangkat kamera dapat menerapkan beberapa tingkat hardware bergantung pada kemampuan IT. Untuk 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 aplikasi dan menggunakan nilai yang disediakan oleh rutinitas kontrol 3A. Misalnya, jika eksposur otomatis aktif, waktu eksposur, durasi frame, dan parameter sensitivitas sensor dikontrol oleh algoritma 3A platform, dan nilai apa pun yang ditentukan aplikasi akan diabaikan. Nilai yang dipilih untuk frame oleh rutinitas 3A harus dilaporkan dalam metadata output. Tabel berikut ini menjelaskan berbagai mode 3Blok kontrol dan properti yang dikontrol oleh mode ini. Lihat platform/system/media/camera/docs/docs.html untuk definisi properti tersebut.

Kontrol dalam blok Pemrosesan Gambar di Gambar 2 semuanya beroperasi pada prinsip serupa, dan umumnya setiap blok memiliki tiga mode:

• NONAKTIF: Blok pemrosesan ini dinonaktifkan. Demozaik, koreksi warna, dan blok penyesuaian kurva nada tidak dapat dinonaktifkan.
• CEPAT: Dalam mode ini, blok pemrosesan mungkin tidak memperlambat frame output dibandingkan dengan mode NONAKTIF, tetapi akan menghasilkan kualitas yang dapat diberikan batasan tersebut. Biasanya, ini akan digunakan untuk mode pratinjau atau perekaman video, atau pengambilan burst untuk gambar diam. Di beberapa perangkat lain, ini mungkin setara dengan mode NONAKTIF (proses tidak dapat dilakukan tanpa memperlambat kecepatan frame), dan pada beberapa perangkat, hal ini mungkin setara dengan Mode HIGH_KUALITAS (kualitas terbaik tetap tidak memperlambat kecepatan frame).
• TINGGI_KUALITAS: Dalam mode ini, blok pemrosesan akan menghasilkan yang terbaik kualitas hasil yang optimal, sehingga memperlambat kecepatan {i>frame<i} {i>output<i} sesuai kebutuhan. Biasanya, ini akan digunakan untuk pengambilan gambar diam berkualitas tinggi. Beberapa blok mencakup kontrol manual yang dapat dipilih secara opsional, bukan FAST atau BERKUALITAS_TINGGI. Misalnya, blok koreksi warna mendukung matriks transformasi, sedangkan penyesuaian kurva nada mendukung representasi global kurva pemetaan nada.

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

• Resolusi yang diminta untuk streaming gambar output
• Ketersediaan mode pengelompokan/melewatkan pada imager
• Bandwidth antarmuka imager
• Bandwidth berbagai blok pemrosesan ISP

Karena faktor-faktor ini dapat sangat bervariasi antara ISP dan sensor yang berbeda, antarmuka HAL kamera mencoba memisahkan pembatasan {i>bandwidth<i} menjadi model. Model yang disajikan memiliki karakteristik berikut:

• Sensor gambar selalu dikonfigurasi untuk menghasilkan resolusi terkecil mungkin mengingat ukuran aliran output yang diminta aplikasi. Terkecil resolusi didefinisikan sebagai setidaknya sebesar ukuran terbesar yang diminta ukuran stream output.
• Karena setiap permintaan dapat menggunakan salah satu atau semua {i>output stream<i} yang dikonfigurasi saat ini, sensor dan ISP harus dikonfigurasi untuk mendukung penskalaan satu tangkapan ke semua streaming secara bersamaan.
• Streaming JPEG bertindak seperti {i>stream<i} YUV yang diproses untuk permintaan yang tidak termasuk; dalam permintaan yang direferensikan secara langsung, permintaan ini bertindak sebagai Streaming JPEG.
• Prosesor JPEG dapat berjalan secara bersamaan ke seluruh pipeline kamera tetapi tidak dapat memproses lebih dari satu tangkapan sekaligus.