Subsistem HAL

Permintaan

Framework aplikasi mengeluarkan permintaan untuk hasil yang diambil ke subsistem kamera. Satu permintaan sesuai dengan satu set hasil. Permintaan mencakup semua informasi konfigurasi tentang pengambilan dan pemrosesan hasil tersebut. Hal ini mencakup hal-hal seperti resolusi dan format piksel; sensor manual, lensa, dan kontrol flash; 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 mencakup 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 secara langsung sesuai dengan ISP nyata mana pun. Namun, cukup mirip dengan pipeline pemrosesan nyata sehingga Anda dapat memetakannya ke hardware secara efisien. Selain itu, API 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 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 didefinisikan 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 pangkas ditampilkan, semua unit penskalaan berbagi kontrol wilayah output (zoom digital). Namun, setiap unit mungkin memiliki resolusi output dan format piksel yang berbeda.

Ringkasan penggunaan API
Ini adalah ringkasan singkat langkah-langkah untuk menggunakan Android Camera API. Lihat bagian Startup dan urutan operasi yang diharapkan untuk mengetahui perincian mendetail dari langkah-langkah ini, termasuk panggilan API.

1. Mendengarkan dan menghitung perangkat kamera.
2. Buka perangkat dan hubungkan pemroses.
3. Mengonfigurasi output untuk kasus penggunaan target (seperti pengambilan gambar diam, perekaman, dll.).
4. Buat permintaan untuk kasus penggunaan target.
5. Merekam/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 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 aliran 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 rutin 3A) dienkapsulasi dalam permintaan dan hasil.

Gambar 3. Ringkasan HAL Kamera

Urutan operasi yang diharapkan dan saat memulai

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

Mencantumkan, membuka perangkat kamera, dan membuat sesi aktif

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

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 set setelan default, dan dengan setidaknya satu aliran output yang telah didaftarkan sebelumnya oleh framework. Ini dikirim ke HAL dengan ICameraDeviceSession::processCaptureRequest(). HAL harus memblokir kembalinya 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 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 awal eksposur. Panggilan balik pemberitahuan 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 menampilkan rekaman yang telah selesai ke framework dengan ICameraDeviceCallback::processCaptureResult(). Respons ini ditampilkan dalam urutan yang sama dengan pengiriman permintaan. Beberapa permintaan dapat dikirim sekaligus, bergantung pada kedalaman pipeline perangkat HAL kamera.

Setelah beberapa waktu, salah satu hal berikut akan terjadi:

• Framework dapat berhenti mengirimkan permintaan baru, menunggu penyelesaian pengambilan gambar yang ada (semua buffer terisi, semua hasil ditampilkan), lalu memanggil ICameraDeviceSession::configureStreams() lagi. Tindakan ini akan mereset hardware dan pipeline kamera untuk serangkaian aliran input/output baru. Beberapa streaming dapat digunakan kembali dari konfigurasi sebelumnya. Kemudian, framework melanjutkan dari permintaan pengambilan pertama ke HAL, jika setidaknya satu aliran output terdaftar tetap ada. (Jika tidak, ICameraDeviceSession::configureStreams() harus diisi terlebih dahulu.)
• Framework dapat memanggil ICameraDeviceSession::close() untuk mengakhiri sesi kamera. Fungsi ini dapat dipanggil kapan saja saat tidak ada panggilan lain dari framework yang aktif, meskipun panggilan dapat diblokir hingga semua pengambilan dalam proses selesai (semua hasil ditampilkan, semua buffer diisi). 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. Namun, HAL harus membatalkan atau menyelesaikan semua pengambilan gambar yang belum selesai sebelum memanggil notify(), sehingga setelah notify() dipanggil dengan error fatal, framework tidak akan menerima panggilan balik lebih lanjut dari perangkat. Metode selain close() harus menampilkan -ENODEV atau NULL setelah metode notify() ditampilkan dari pesan error fatal.

Gambar 4. Alur pengoperasian 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 perekaman 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, parameter waktu eksposur, durasi frame, dan 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	Status	Properti yang dikontrol
android.control.aeMode	NONAKTIF	Tidak ada
	AKTIF	android.sensor.exposureTime android.sensor.frameDuration android.sensor.sensitivity android.lens.aperture (jika didukung) android.lens.filterDensity (jika didukung)
	ON_AUTO_FLASH	Semuanya AKTIF, 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	NONAKTIF	Tidak ada
	WHITE_BALANCE_*	android.colorCorrection.transform. Penyesuaian khusus platform jika android.colorCorrection.mode adalah FAST atau HIGH_QUALITY.
android.control.afMode	NONAKTIF	Tidak ada
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	NONAKTIF	Tidak ada
	AKTIF	Dapat menyesuaikan android.scaler.cropRegion untuk menerapkan stabilisasi video
android.control.mode	NONAKTIF	AE, AWB, dan AF dinonaktifkan
	OTOMATIS	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 semuanya beroperasi dengan prinsip yang serupa, dan umumnya setiap blok memiliki tiga mode:

• NONAKTIF: Blok pemrosesan ini dinonaktifkan. Blok penyesuaian demosaik, koreksi warna, dan kurva nada 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 dihasilkan mengingat batasan tersebut. Biasanya, ini akan digunakan untuk mode pratinjau atau perekaman video, atau pengambilan gambar burst untuk gambar diam. Di beberapa perangkat, hal ini mungkin setara dengan mode NONAKTIF (tidak ada pemrosesan yang dapat dilakukan tanpa memperlambat kecepatan frame), dan di beberapa perangkat, hal ini mungkin setara dengan mode KUALITAS_TINGGI (kualitas terbaik tetap tidak memperlambat kecepatan frame).
• HIGH_QUALITY: Dalam mode ini, blok pemrosesan harus menghasilkan hasil kualitas terbaik yang mungkin, sehingga memperlambat kecepatan frame output 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 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 aliran gambar output
• Ketersediaan mode pengelompokan/melewati pada imager
• Bandwidth antarmuka imager
• Bandwidth berbagai blok pemrosesan ISP

Karena faktor-faktor ini dapat sangat bervariasi antara berbagai ISP dan sensor, 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 memungkinkan mengingat ukuran aliran output yang diminta aplikasi. Resolusi terkecil didefinisikan setidaknya sama besar dengan ukuran streaming output terbesar yang diminta.
• Karena setiap permintaan dapat menggunakan satu atau semua aliran output yang saat ini dikonfigurasi, sensor dan ISP harus dikonfigurasi untuk mendukung penskalaan pengambilan tunggal ke semua aliran secara bersamaan.
• Streaming JPEG bertindak seperti streaming YUV yang diproses untuk permintaan yang tidak menyertakannya; dalam permintaan yang secara langsung mereferensikannya, streaming JPEG bertindak sebagai streaming JPEG.
• Prosesor JPEG dapat berjalan secara serentak dengan pipeline kamera lainnya, tetapi tidak dapat memproses lebih dari satu pengambilan gambar dalam satu waktu.