要求
應用程式架構會對相機子系統提出擷取結果的要求。 一項要求對應一組結果。要求封裝了 針對這些結果的擷取及處理設定資訊。 包括解析度和像素格式等等;手動感應器、鏡頭 以及閃光燈控制3A 運作模式;從 RAW 到 YUV 處理控制措施;和 統計資料產生以便進一步掌控實驗結果。 輸出內容和處理流程可能會同時處理多項要求 提交要求屬於非封鎖性質。而且一律會在 接收順序。
HAL 和相機子系統
相機子系統包含相機元件的實作 例如 3A 演算法和處理控制項相機 HAL 提供多種介面,方便您實作這些元件的版本。目的地: 確保多個裝置製造商之間的跨平台相容性 影像訊號處理器 (ISP 或相機感應器) 廠商、相機管道 是虛擬的,且沒有直接對應任何真實的 ISP。不過 與實際的處理管道相似,因此您可以對應至 的硬體效能此外,此架構的摘要也足以讓您 不同的演算法和作業順序,同時又不影響 品質、效率或跨裝置相容性
相機管道也支援應用程式架構可啟動的觸發條件 開啟自動對焦等功能也會將通知傳回 應用程式架構,通知應用程式發生自動對焦鎖定或錯誤等事件。
請注意,上圖中的某些影像處理區塊並未顯示 在初始版本中明確定義了差異相機管道會產生以下結果 假設:
- ISP 內部並未處理 RAW Bayer 輸出內容。
- 系統會根據原始感應器資料產生統計資料。
- 將原始感應器資料轉換為 YUV 的各種處理模塊位於 順序。
- 如果顯示多個比例和裁剪單位,所有縮放器都會共用 輸出區域控制 (數位變焦)。不過,每個單位可能會有 輸出解析度和像素格式
API 使用摘要
以下摘要概述使用 Android Camera API 的步驟。詳情請參閱
「啟動和預期的作業序列」區段,詳細說明
包含 API 呼叫
- 監聽並列舉相機裝置。
- 開啟裝置並連接事件監聽器。
- 設定目標用途的輸出內容 (例如靜態擷取、記錄、 等)。
- 建立目標用途的要求。
- 擷取/重複要求和爆發。
- 接收結果中繼資料和圖片資料。
- 切換用途時,請返回步驟 3。
HAL 作業摘要
- 擷取的非同步要求來自架構。
- HAL 裝置必須依序處理要求。針對每個要求 輸出結果中繼資料,以及一或多個輸出圖片緩衝區。
- 首次傳遞要求和結果,以及針對要求和結果進行優先處理的串流,以及用於 後續要求
- 特定要求的所有輸出內容的時間戳記必須相同,這樣 還能視需要比對這些架構
- 所有擷取設定和狀態 (3A 處理常式除外) 封裝於要求和結果中。
啟動和預期的作業序列
本節將詳細說明使用 相機 API請參閱 HIDL 介面的 platform/hardware/interfaces/camera/ 定義。
列舉、開啟相機裝置,以及建立啟用中的工作階段
- 初始化後,架構會開始監聽任何
採用
ICameraProvider
介面。如果該供應商有 就會嘗試建立連線。 - 架構列舉相機裝置
ICameraProvider::getCameraIdList()
。 - 架構會呼叫對應的新
ICameraDevice
來例項化新的ICameraDevice
ICameraProvider::getCameraDeviceInterface_VX_X()
。 - 架構會呼叫
ICameraDevice::open()
來建立新的 主動擷取工作階段 ICameraDeviceSession。
使用目前的攝影機工作階段
- 架構會呼叫
ICameraDeviceSession::configureStreams()
以及傳送至 HAL 裝置的輸入/輸出串流清單 - 該架構要求下列用途的預設設定:
呼叫
ICameraDeviceSession::constructDefaultRequestSettings()
。 這可能會在ICameraDeviceSession
後隨時發生 由ICameraDevice::open
建立。 - 架構會建構第一個擷取要求,並利用
以一組預設設定為依據,且至少要有一項設定
先前已註冊的輸出內容串流這封
透過
ICameraDeviceSession::processCaptureRequest()
傳入 HAL。 HAL 必須阻止此呼叫的回程,直到它在下次通話準備用為止 要求。 - 架構將持續提交要求和呼叫
ICameraDeviceSession::constructDefaultRequestSettings()
後可領取 用於其他用途。 - 啟動擷取要求的時間 (感應器開始公開
HAL 會使用以下指令呼叫
ICameraDeviceCallback::notify()
: SHUTTER 訊息,包括畫面編號和開始的時間戳記 暴露在風險中。此通知回呼不需發生在processCaptureResult()
呼叫一項要求,但沒有結果 才傳送到應用程式進行拍攝,直到 系統會呼叫該擷取的notify()
。 - 經過一些管道延遲後,HAL 就會開始將完成的擷取傳回,
透過
ICameraDeviceCallback::processCaptureResult()
建立架構 傳回的順序與要求提交的順序相同。多個 可能會同時處理多個要求,視 相機 HAL 裝置
一段時間後,就會發生下列其中一種情況:
- 架構可能會停止提交新要求,並等待
現有的擷取完成 (已填滿所有緩衝區,所有結果)
),然後呼叫
ICameraDeviceSession::configureStreams()
可以選取「重新建立」,再次生成新的提示這會為一組新的 輸入/輸出串流部分串流可能會重複使用先前的內容 此外還會從 0 自動調整資源配置 您完全不必調整資源調度設定接著,架構會從第一個擷取要求繼續 HAL (如果有至少一個) 已註冊的輸出串流會保留。(否則 「ICameraDeviceSession::configureStreams()
」為必要項目。) - 架構可能會呼叫
ICameraDeviceSession::close()
即可結束攝影機工作階段。在未接聽其他電話的情況下,系統可能會隨時撥打電話給你 但呼叫可能會封鎖 已完成傳輸中的擷取作業 (傳回所有結果、所有緩衝區) )。close()
呼叫傳回後,就不會再呼叫 系統允許ICameraDeviceCallback
透過 HAL。產生close()
呼叫進行中,架構不得呼叫任何其他 HAL 裝置功能。 - 如果發生錯誤或其他非同步事件,HAL 必須呼叫
ICameraDeviceCallback::notify()
和適當的 錯誤訊息/活動訊息。 從嚴重的裝置層級錯誤通知傳回後,HAL 應 就像呼叫close()
一樣。然而,HAL 必須 取消 或完成所有未完成的擷取作業,再呼叫notify()
。 這樣一次 呼叫notify()
時發生嚴重錯誤,架構不會 以便接收裝置的後續回呼。排除方法close()
應傳回 - 在notify()
方法從嚴重事件傳回後,之後 ENODEV 或 NULL 錯誤訊息。
硬體等級
相機裝置可以根據硬體等級實作多種硬體等級 即便沒有技術背景,也能因這些工具的功能而受益若需更多資訊,請參閲 支援的硬體級別。
應用程式擷取要求、3A 控制項和處理管道之間的互動
視 3A 控制區塊的設定而定,相機管道會忽略 應用程式擷取要求中的部分參數,並使用值 是由 3A 控制處理常式提供的舉例來說,如果自動曝光為 主動、曝光時間、影格持續時間以及敏感度參數 感應器是由平台 3A 演算法和任何應用程式指定的值所控制 系統會忽略此值。為 3A 常式選擇的影格選擇的值必須回報 然後輸出中繼資料下表說明 3A 控制項區塊和由這些模式控制的屬性。詳情請見 platform/system/media/camera/docs/docs.html 檔案,瞭解這些屬性的定義。
參數 | 狀態 | 資源控管 |
---|---|---|
android.control.aeMode | 關閉 | 無 |
開啟 | android.sensor.exposureTime android.sensor.FrameDuration android.sensor.sensitivity android.lens.aperture (如果支援的話) android.lens.filterDensity (如果支援) | |
ON_AUTO_FLASH | 全部開啟,以及 android.flash.firingPower、android.flash.firingTime 和 android.flash.mode | |
ON_ALWAYS_FLASH | 與 ON_AUTO_FLASH 相同 | |
ON_AUTO_FLASH_RED_EYE | 與 ON_AUTO_FLASH 相同 | |
android.control.awbMode | 關閉 | 無 |
WHITE_BALANCE_* | android.color 更正 ion.transform。針對 android.color 更正 ion.mode 為 FAST 或 HIGH_QUALITY 時的平台專屬調整。 | |
android.control.afMode | 關閉 | 無 |
FOCUS_MODE_* | android.lens.focusDistance | |
android.control.videoStabilization | 關閉 | 無 |
開啟 | 可調整 android.scaler.cropRegion ,實作影片防震功能 | |
android.control.mode | 關閉 | AE、AWB 和 AF 已停用 |
自動 | 使用個別 AE、AWB 和 AF 設定 | |
場景模式* | 可覆寫上述所有參數。系統會停用個別 3A 控制項。 |
圖 2 中影像處理區塊中的控制項,都是針對 原則上,每個區塊通常有三種模式
- 關閉:這個處理區塊已停用。去馬賽克、色彩校正及 無法停用色調曲線調整區塊。
- 快速:在此模式下,處理區塊可能不會減緩輸出影格速度 相較於關閉模式,應能產生 輸出流量這通常是用於 預覽或錄影模式,或連續拍攝靜態圖片。某些 裝置,此模式可能等同於關閉模式 (如果沒有的話,系統將無法執行處理程序) 減慢影格速率),而且在某些裝置上,有時等同於 HIGH_QUALITY 模式 (最佳品質並不會拖慢畫面更新率)。
- HIGH_QUALITY:在這個模式下,處理區塊應該會產生 品質,請視需要放慢輸出影格速率 通常用於高畫質的靜態拍攝。部分區塊 包含手動控制項,使用者可選擇是否快速選取 FAST 或 HIGH_QUALITY。舉例來說,色彩校正區塊支援色彩 轉換矩陣,而色調曲線調整支援任意全域 色調映射曲線。
相機子系統可支援的影格速率上限是一項功能 影響因素:
- 要求的輸出影像串流解析度
- 圖片工具提供特徵分塊/略過模式
- 圖片工具介面的頻寬
- 各種 ISP 處理模塊的頻寬
由於這些因素可能因各家 ISP 和感應器有極大差異 相機 HAL 介面會嘗試將頻寬限制減至 呈現的模型具有下列特性:
- 圖片感應器一律會設為輸出最小解析度 以因應應用程式所要求的輸出串流大小。最小 解析度的定義至少為要求的最大尺寸 輸出串流大小
- 由於任何要求可能會使用目前設定的任何或所有輸出串流, 必須將感應器和網際網路服務供應商 (ISP) 設為支援單一擷取 全部的串流。
- JPEG 串流就像是針對請求的已處理 YUV 串流一樣 未包含;直接參照的要求中, JPEG 串流。
- JPEG 處理器可以同時在相機管道的其餘部分並行執行, 一次只能處理多筆擷取。