Subsistem HAL

Permintaan

Framework aplikasi mengeluarkan permintaan untuk hasil yang diambil ke subsistem kamera. Satu permintaan sesuai dengan satu kumpulan hasil. Permintaan mengenkapsulasi 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 dikirim sekaligus, dan pengiriman permintaan tidak memblokir. Selain itu, permintaan selalu diproses sesuai urutan penerimaannya.

Gambar 1. Model kamera

HAL dan subsistem kamera

Subsistem kamera menyertakan 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 langsung sesuai dengan ISP sebenarnya. Namun, hal ini cukup mirip dengan pipeline pemrosesan yang sebenarnya sehingga Anda dapat memetakan ke hardware secara efisien. Selain itu, 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 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 kunci fokus otomatis atau error.

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 mengalami 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 penskalaan memiliki kontrol region output yang sama (zoom digital). Namun, setiap unit mungkin memiliki resolusi output dan format piksel yang berbeda.

Ringkasan penggunaan API
Ini adalah ringkasan singkat tentang langkah-langkah untuk menggunakan API kamera Android. Lihat bagian Urutan operasi startup dan yang diharapkan untuk mengetahui perincian detail langkah-langkah ini, termasuk panggilan API.

1. Memproses dan menghitung perangkat kamera.
2. Membuka perangkat dan menghubungkan pemroses.
3. Konfigurasikan output untuk kasus penggunaan target (seperti pengambilan gambar diam, perekaman, dll.).
4. Buat permintaan untuk kasus penggunaan target.
5. Menangkap/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 berasal dari framework.
• Perangkat HAL harus memproses permintaan secara berurutan. Dan untuk setiap permintaan, hasilkan metadata hasil output, dan satu atau beberapa buffering gambar output.
• Masuk pertama, keluar pertama untuk permintaan dan hasil, serta untuk streaming 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 rutinitas 3A) dienkapsulasi dalam permintaan dan hasil.

Gambar 3. Ringkasan HAL kamera

Urutan operasi startup dan yang diharapkan

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

Mengurutkan, membuka perangkat kamera, dan membuat sesi aktif

1. Setelah inisialisasi, framework mulai memproses penyedia kamera yang ada yang mengimplementasikan antarmuka ICameraProvider. Jika penyedia tersebut ada, framework akan mencoba membuat koneksi.
2. Framework ini 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 baru ICameraDeviceSession.

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 kumpulan setelan default, dan dengan setidaknya satu stream output yang telah didaftarkan sebelumnya oleh framework. Hal ini dikirim ke HAL dengan ICameraDeviceSession::processCaptureRequest(). HAL harus memblokir pengembalian panggilan ini hingga siap untuk permintaan berikutnya dikirim.
4. Framework ini terus mengirimkan permintaan dan memanggil ICameraDeviceSession::constructDefaultRequestSettings() untuk mendapatkan buffer setelan default untuk kasus penggunaan lainnya 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 memulai eksposur. Callback pemberitahuan ini tidak harus terjadi sebelum panggilan processCaptureResult() pertama untuk permintaan, tetapi tidak ada hasil yang dikirim ke aplikasi untuk pengambilan hingga setelah notify() untuk pengambilan tersebut dipanggil.
6. Setelah beberapa penundaan pipeline, HAL mulai menampilkan rekaman yang telah selesai ke framework dengan ICameraDeviceCallback::processCaptureResult(). Data ini ditampilkan dalam urutan yang sama dengan urutan pengiriman permintaan. Beberapa permintaan dapat berjalan sekaligus, bergantung pada kedalaman pipeline perangkat HAL kamera.

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

• Framework dapat berhenti mengirimkan permintaan baru, menunggu rekaman yang ada selesai (semua buffering terisi, semua hasil ditampilkan), lalu memanggil ICameraDeviceSession::configureStreams() lagi. Tindakan ini akan mereset hardware dan pipeline kamera untuk kumpulan streaming input/output baru. Beberapa streaming dapat digunakan kembali dari konfigurasi sebelumnya. Framework kemudian berlanjut dari permintaan pengambilan pertama ke HAL, jika setidaknya satu streaming output terdaftar tetap ada. (Jika tidak, ICameraDeviceSession::configureStreams() diperlukan terlebih dahulu.)
• Framework dapat memanggil ICameraDeviceSession::close() untuk mengakhiri sesi kamera. Ini dapat dipanggil kapan saja saat tidak ada panggilan lain dari framework yang aktif, meskipun panggilan dapat diblokir hingga semua pengambilan dalam penerbangan selesai (semua hasil ditampilkan, semua buffer terisi). Setelah panggilan close() ditampilkan, 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 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 di dalamnya. Namun, HAL harus membatalkan atau menyelesaikan semua pengambilan yang belum selesai 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() ditampilkan dari pesan error fatal.

Gambar 4. Alur operasional kamera

Tingkat hardware

Perangkat kamera dapat menerapkan beberapa tingkat hardware, bergantung pada kemampuannya. 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, saat eksposur otomatis aktif, parameter waktu eksposur, durasi frame, dan 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 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.

Semua kontrol di blok Pemrosesan Gambar pada Gambar 2 beroperasi berdasarkan prinsip yang serupa, dan umumnya setiap blok memiliki tiga mode:

• NONAKTIF: Blok pemrosesan ini dinonaktifkan. Blok demosaic, koreksi warna, dan penyesuaian kurva tone tidak dapat dinonaktifkan.
• CEPAT: Dalam mode ini, blok pemrosesan mungkin tidak memperlambat kecepatan frame output dibandingkan dengan mode NONAKTIF, tetapi harus menghasilkan output berkualitas terbaik yang dapat diberikan dengan batasan tersebut. Biasanya, ini akan digunakan untuk mode pratinjau atau perekaman video, atau pengambilan burst untuk gambar diam. Di beberapa perangkat, ini mungkin setara dengan mode NONAKTIF (tidak ada pemrosesan yang dapat dilakukan tanpa memperlambat kecepatan frame), dan di beberapa perangkat, ini mungkin setara dengan mode HIGH_QUALITY (kualitas terbaik masih tidak memperlambat kecepatan frame).
• HIGH_QUALITY: Dalam mode ini, blok pemrosesan akan menghasilkan hasil kualitas terbaik, sehingga memperlambat kecepatan frame output sesuai kebutuhan. Biasanya, mode 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 tone mendukung kurva pemetaan tone 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 penggabungan/lewati pada pemindai gambar
• Bandwidth antarmuka pemindai gambar
• Bandwidth berbagai blok pemrosesan ISP

Karena faktor ini dapat sangat bervariasi di antara ISP dan sensor yang berbeda, antarmuka HAL kamera mencoba memisahkan batasan bandwidth menjadi model sesederhana mungkin. Model yang disajikan memiliki karakteristik berikut:

• Sensor gambar selalu dikonfigurasi untuk menghasilkan resolusi sekecil mungkin dengan mempertimbangkan ukuran streaming output yang diminta aplikasi. Resolusi terkecil ditentukan setidaknya sama besar dengan ukuran streaming output terbesar yang diminta.
• Karena setiap permintaan dapat menggunakan salah satu atau semua streaming output yang saat ini dikonfigurasi, sensor dan ISP harus dikonfigurasi untuk mendukung penskalaan satu pengambilan ke semua streaming secara bersamaan.
• Streaming JPEG berfungsi seperti streaming YUV yang diproses untuk permintaan yang tidak menyertakannya; dalam permintaan yang mereferensikannya secara langsung, streaming tersebut berfungsi sebagai streaming JPEG.
• Pemroses JPEG dapat berjalan secara serentak dengan pipeline kamera lainnya, tetapi tidak dapat memproses lebih dari satu pengambilan sekaligus.