HAL 子系統

要求

應用程式架構會對相機子系統提出擷取結果的要求。 一項要求對應一組結果。要求封裝了 針對這些結果的擷取及處理設定資訊。 包括解析度和像素格式等等;手動感應器、鏡頭 以及閃光燈控制3A 運作模式;從 RAW 到 YUV 處理控制措施;和 統計資料產生以便進一步掌控實驗結果。 輸出內容和處理流程可能會同時處理多項要求 提交要求屬於非封鎖性質。而且一律會在 接收順序。

相機要求模型

圖 1. 相機型號

HAL 和相機子系統

相機子系統包含相機元件的實作 例如 3A 演算法和處理控制項相機 HAL 提供多種介面,方便您實作這些元件的版本。目的地: 確保多個裝置製造商之間的跨平台相容性 影像訊號處理器 (ISP 或相機感應器) 廠商、相機管道 是虛擬的,且沒有直接對應任何真實的 ISP。不過 與實際的處理管道相似,因此您可以對應至 的硬體效能此外,此架構的摘要也足以讓您 不同的演算法和作業順序,同時又不影響 品質、效率或跨裝置相容性

相機管道也支援應用程式架構可啟動的觸發條件 開啟自動對焦等功能也會將通知傳回 應用程式架構,通知應用程式發生自動對焦鎖定或錯誤等事件。

相機硬體抽象層

圖 2. 相機管道

請注意,上圖中的某些影像處理區塊並未顯示 在初始版本中明確定義了差異相機管道會產生以下結果 假設:

  • ISP 內部並未處理 RAW Bayer 輸出內容。
  • 系統會根據原始感應器資料產生統計資料。
  • 將原始感應器資料轉換為 YUV 的各種處理模塊位於 順序。
  • 如果顯示多個比例和裁剪單位,所有縮放器都會共用 輸出區域控制 (數位變焦)。不過,每個單位可能會有 輸出解析度和像素格式

API 使用摘要
以下摘要概述使用 Android Camera API 的步驟。詳情請參閱 「啟動和預期的作業序列」區段,詳細說明 包含 API 呼叫

  1. 監聽並列舉相機裝置。
  2. 開啟裝置並連接事件監聽器。
  3. 設定目標用途的輸出內容 (例如靜態擷取、記錄、 等)。
  4. 建立目標用途的要求。
  5. 擷取/重複要求和爆發。
  6. 接收結果中繼資料和圖片資料。
  7. 切換用途時,請返回步驟 3。

HAL 作業摘要

  • 擷取的非同步要求來自架構。
  • HAL 裝置必須依序處理要求。針對每個要求 輸出結果中繼資料,以及一或多個輸出圖片緩衝區。
  • 首次傳遞要求和結果,以及針對要求和結果進行優先處理的串流,以及用於 後續要求
  • 特定要求的所有輸出內容的時間戳記必須相同,這樣 還能視需要比對這些架構
  • 所有擷取設定和狀態 (3A 處理常式除外) 封裝於要求和結果中。
相機 HAL 總覽

圖 3. 相機 HAL 總覽

啟動和預期的作業序列

本節將詳細說明使用 相機 API請參閱 HIDL 介面的 platform/hardware/interfaces/camera/ 定義。

列舉、開啟相機裝置,以及建立啟用中的工作階段

  1. 初始化後,架構會開始監聽任何 採用 ICameraProvider 介面。如果該供應商有 就會嘗試建立連線。
  2. 架構列舉相機裝置 ICameraProvider::getCameraIdList()
  3. 架構會呼叫對應的新 ICameraDevice 來例項化新的 ICameraDevice ICameraProvider::getCameraDeviceInterface_VX_X()
  4. 架構會呼叫 ICameraDevice::open() 來建立新的 主動擷取工作階段 ICameraDeviceSession。

使用目前的攝影機工作階段

  1. 架構會呼叫 ICameraDeviceSession::configureStreams() 以及傳送至 HAL 裝置的輸入/輸出串流清單
  2. 該架構要求下列用途的預設設定: 呼叫 ICameraDeviceSession::constructDefaultRequestSettings()。 這可能會在 ICameraDeviceSession 後隨時發生 由 ICameraDevice::open 建立。
  3. 架構會建構第一個擷取要求,並利用 以一組預設設定為依據,且至少要有一項設定 先前已註冊的輸出內容串流這封 透過 ICameraDeviceSession::processCaptureRequest() 傳入 HAL。 HAL 必須阻止此呼叫的回程,直到它在下次通話準備用為止 要求。
  4. 架構將持續提交要求和呼叫 ICameraDeviceSession::constructDefaultRequestSettings()後可領取 用於其他用途。
  5. 啟動擷取要求的時間 (感應器開始公開 HAL 會使用以下指令呼叫 ICameraDeviceCallback::notify(): SHUTTER 訊息,包括畫面編號和開始的時間戳記 暴露在風險中。此通知回呼不需發生在 processCaptureResult() 呼叫一項要求,但沒有結果 才傳送到應用程式進行拍攝,直到 系統會呼叫該擷取的 notify()
  6. 經過一些管道延遲後,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 錯誤訊息。
相機操作流程

圖 4. 攝影機運作流程

硬體等級

相機裝置可以根據硬體等級實作多種硬體等級 即便沒有技術背景,也能因這些工具的功能而受益若需更多資訊,請參閲 支援的硬體級別

應用程式擷取要求、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 處理器可以同時在相機管道的其餘部分並行執行, 一次只能處理多筆擷取。