HAL 子系統

要求

應用程式框架向相機子系統發出捕獲結果的請求。一個請求對應一組結果。請求封裝了有關捕獲和處理這些結果的所有配置資訊。這包括解析度和像素格式等；手動感應器、鏡頭和閃光燈控制； 3A工作模式； RAW轉YUV處理控制；和統計資料產生。這允許對結果的輸出和處理進行更多的控制。多個請求可以同時進行，並且提交請求是非阻塞的。並且請求始終按照收到的順序進行處理。

圖 1.相機模型

HAL 和相機子系統

相機子系統包括相機管道中組件的實現，例如 3A 演算法和處理控制。相機 HAL 為您提供介面來實現這些元件的您的版本。為了保持多個設備製造商和影像訊號處理器（ISP，或相機感測器）供應商之間的跨平台相容性，相機管道模型是虛擬的，不直接對應於任何真實的ISP。然而，它與真實的處理管道非常相似，因此您可以將其有效地映射到您的硬體。此外，它足夠抽象，允許多種不同的演算法和操作順序，而不會影響品質、效率或跨裝置相容性。

相機管道還支援應用程式框架可以啟動的觸發器來開啟自動對焦等功能。它還將通知發送回應用程式框架，通知應用程式發生自動對焦鎖定或錯誤等事件。

圖 2.相機管道

請注意，上圖中顯示的一些影像處理區塊在初始版本中沒有明確定義。相機管道做出以下假設：

• RAW Bayer 輸出在 ISP 內部不進行任何處理。
• 統計數據是根據原始感測器數據生成的。
• 將原始感測器資料轉換為 YUV 的各種處理區塊的順序是任意的。
• 雖然顯示了多個縮放和裁剪單元，但所有縮放器單元共用輸出區域控制項（數位縮放）。然而，每個單元可能具有不同的輸出解析度和像素格式。

API使用總結
這是使用 Android 相機 API 的步驟的簡要總結。有關這些步驟（包括 API 呼叫）的詳細細分，請參閱啟動和預期操作序列部分。

1. 監聽並列舉攝影機設備。
2. 開啟裝置並連接偵聽器。
3. 配置目標用例的輸出（例如靜態捕捉、錄製等）。
4. 為目標用例建立請求。
5. 捕獲/重複請求和突發。
6. 接收結果元資料和影像資料。
7. 切換用例時，返回步驟 3。

HAL操作總結

• 非同步捕獲請求來自框架。
• HAL 裝置必須依序處理請求。對於每個請求，產生輸出結果元資料以及一個或多個輸出影像緩衝區。
• 請求和結果以及後續請求引用的流都是先進先出的。
• 對於給定請求的所有輸出，時間戳必須相同，以便框架可以在需要時將它們匹配在一起。
• 所有捕獲配置和狀態（3A 例程除外）都封裝在請求和結果中。

圖 3.相機 HAL 概述

啟動和預期操作順序

本節包含使用相機 API 時預期步驟的詳細說明。請參閱platform/hardware/interfaces/camera/了解 HIDL 介面定義。

列舉、打開攝影機設備並建立活動會話

1. 初始化後，框架開始偵聽任何實作ICameraProvider介面的現有相機提供者。如果存在這樣的提供者，框架將嘗試建立連線。
2. 該框架透過ICameraProvider::getCameraIdList()枚舉相機設備。
3. 此框架透過呼叫對應的ICameraProvider::getCameraDeviceInterface_VX_X()來實例化一個新的ICameraDevice 。
4. 框架呼叫ICameraDevice::open()來建立新的活動擷取工作階段 ICameraDeviceSession。

使用活動相機會話

1. 此框架使用 HAL 裝置的輸入/輸出流清單來呼叫ICameraDeviceSession::configureStreams() 。
2. 該框架透過呼叫ICameraDeviceSession::constructDefaultRequestSettings()來請求某些用例的預設設定。在ICameraDevice::open建立ICameraDeviceSession之後的任何時間都可能發生這種情況。
3. 框架構造第一個捕獲請求並將其發送到 HAL，該請求具有基於一組預設設置的設置，並且具有框架先前註冊的至少一個輸出流。這透過ICameraDeviceSession::processCaptureRequest()發送到 HAL。 HAL 必須阻止此呼叫的返回，直到準備好發送下一個請求。
4. 框架繼續提交請求並呼叫ICameraDeviceSession::constructDefaultRequestSettings()以根據需要取得其他用例的預設設定緩衝區。
5. 當請求的捕獲開始時（感測器開始曝光以進行捕獲），HAL 會使用 SHUTTER 訊息呼叫ICameraDeviceCallback::notify() ，其中包括幀編號和曝光開始的時間戳。此通知回調不必在第一次呼叫請求的processCaptureResult()之前發生，但在呼叫該notify()之前，不會將任何結果傳遞到應用程式以進行捕獲。
6. 經過一段管道延遲後，HAL 開始使用ICameraDeviceCallback::processCaptureResult()將完成的擷取回到框架。這些傳回的順序與提交請求的順序相同。多個請求可以同時進行，具體取決於相機 HAL 裝置的管道深度。

一段時間後，將發生以下情況之一：

• 框架可能會停止提交新請求，等待現有擷取完成（所有緩衝區已填充，所有結果已返回），然後再次呼叫ICameraDeviceSession::configureStreams() 。這會重置相機硬體和管道以獲取一組新的輸入/輸出流。某些流可以重複使用先前的配置。如果至少還有一個已註冊的輸出流，則框架會從第一個擷取請求繼續到 HAL。 （否則，首先需要ICameraDeviceSession::configureStreams() 。）
• 框架可以呼叫ICameraDeviceSession::close()來結束相機會話。當框架中沒有其他呼叫處於活動狀態時，可以隨時呼叫此函數，儘管該呼叫可能會阻塞，直到所有正在進行的捕獲完成（返回所有結果，填充所有緩衝區）。 close()呼叫返回後，不再允許從 HAL 呼叫ICameraDeviceCallback 。一旦close()呼叫正在進行，框架就不能呼叫任何其他 HAL 裝置函數。
• 如果發生錯誤或其他非同步事件，HAL 必須使用適當的錯誤/事件訊息呼叫ICameraDeviceCallback::notify() 。從致命的設備範圍錯誤通知返回後，HAL 的行為應該就像呼叫了close()一樣。但是，HAL 必須在呼叫notify()之前取消或完成所有未完成的捕獲，以便一旦呼叫notify()並出現致命錯誤，框架將不會從裝置接收進一步的回調。在notify()方法從致命錯誤訊息傳回後， close()以外的方法應傳回-ENODEV 或NULL。

圖 4.相機操作流程

硬體等級

相機設備可根據其功能實現多個硬體等級。有關詳細信息，請參閱支援的硬體層級。

應用程式擷取請求、3A 控制和處理管道之間的交互

根據 3A 控制區塊中的設置，相機管道會忽略應用程式擷取請求中的某些參數，並改用 3A 控制例程提供的值。例如，當自動曝光處於活動狀態時，感測器的曝光時間、幀持續時間和靈敏度參數由平台 3A 演算法控制，並且忽略任何應用程式指定的值。 3A 例程為幀選擇的值必須在輸出元資料中報告。下表描述了 3A 控制塊的不同模式以及這些模式控制的屬性。有關這些屬性的定義，請參閱platform/system/media/camera/docs/docs.html檔案。

圖 2 中的影像處理區塊中的控制項均按照相似的原理運行，通常每個區塊有三種模式：

• OFF：該處理區塊已停用。無法停用去馬賽克、色彩校正和色調曲線調整方塊。
• FAST：在此模式下，與 OFF 模式相比，處理區塊可能不會減慢輸出幀速率，但在該限制下應產生最佳品質的輸出。通常，這將用於預覽或錄影模式，或靜態影像的連拍捕捉。在某些裝置上，這可能相當於OFF 模式（在不降低幀速率的情況下無法進行任何處理），而在某些裝置上，這可能相當於HIGH_QUALITY 模式（最佳品質仍然不會降低幀速率）。
• HIGH_QUALITY：在此模式下，處理區塊應產生盡可能最佳品質的結果，並根據需要減慢輸出幀速率。通常，這將用於高品質的靜態捕捉。某些區塊包含手動控制，可以選擇此手動控制來取代 FAST 或 HIGH_QUALITY。例如，顏色校正方塊支援顏色變換矩陣，而色調曲線調整支援任意全域色調映射曲線。

相機子系統可支援的最大幀速率是多種因素的函數：

• 輸出影像流的請求分辨率
• 成像儀上分級/跳過模式的可用性
• 成像儀介面的頻寬
• 各種 ISP 處理區塊的頻寬

由於這些因素在不同的 ISP 和感測器之間可能存在很大差異，因此相機 HAL 介面嘗試將頻寬限制抽象化為盡可能簡單的模型。所提出的模型具有以下特點：

• 影像感測器始終配置為根據應用程式請求的輸出流大小輸出可能的最小解析度。最小解析度定義為至少與最大請求的輸出流大小一樣大。
• 由於任何請求都可能使用任何或所有目前配置的輸出流，因此感測器和 ISP 必須配置為支援同時將單一擷取擴展到所有流。
• 對於未包含 JPEG 流的請求，JPEG 流的作用類似於經過處理的 YUV 流；在直接引用它們的請求中，它們充當 JPEG 流。
• JPEG 處理器可以與相機管道的其餘部分同時運行，但一次不能處理多個捕獲。