要求
應用程序框架向相機子系統發出對捕獲結果的請求。一個請求對應一組結果。請求封裝了有關捕獲和處理這些結果的所有配置信息。這包括分辨率和像素格式等內容;手動傳感器、鏡頭和閃光燈控制; 3A工作模式; RAW轉YUV處理控制;和統計生成。這允許對結果的輸出和處理進行更多控制。多個請求可以同時進行,並且提交請求是非阻塞的。並且請求總是按照接收到的順序進行處理。
HAL 和相機子系統
相機子系統包括相機管道中組件的實現,例如 3A 算法和處理控制。相機 HAL 為您提供接口來實現這些組件的版本。為了保持多個設備製造商和圖像信號處理器(ISP,或相機傳感器)供應商之間的跨平台兼容性,相機管道模型是虛擬的,不直接對應任何真實的 ISP。但是,它與真實的處理管道非常相似,因此您可以有效地將其映射到您的硬件。此外,它足夠抽象,可以允許多種不同的算法和操作順序,而不會影響質量、效率或跨設備兼容性。
相機管道還支持應用程序框架可以啟動的觸發器以打開自動對焦等功能。它還將通知發送回應用程序框架,通知應用程序自動對焦鎖定或錯誤等事件。
請注意,上圖中顯示的一些圖像處理模塊在初始版本中沒有明確定義。相機管道做出以下假設:
- RAW Bayer 輸出在 ISP 內部不進行任何處理。
- 統計數據是根據原始傳感器數據生成的。
- 將原始傳感器數據轉換為 YUV 的各種處理塊的順序是任意的。
- 雖然顯示了多個縮放和裁剪單元,但所有縮放器單元共享輸出區域控件(數字縮放)。但是,每個單元可能具有不同的輸出分辨率和像素格式。
API使用總結
這是使用 Android 相機 API 的步驟的簡要總結。有關這些步驟(包括 API 調用)的詳細分解,請參閱啟動和預期操作順序部分。
- 偵聽並枚舉相機設備。
- 打開設備並連接監聽器。
- 為目標用例配置輸出(例如靜止捕獲、記錄等)。
- 為目標用例創建請求。
- 捕獲/重複請求和突發。
- 接收結果元數據和圖像數據。
- 切換用例時,返回步驟 3。
HAL操作總結
- 捕獲的異步請求來自框架。
- HAL 設備必須按順序處理請求。並為每個請求生成輸出結果元數據,以及一個或多個輸出圖像緩衝區。
- 請求和結果以及後續請求引用的流的先進先出。
- 給定請求的所有輸出的時間戳必須相同,以便框架可以在需要時將它們匹配在一起。
- 所有捕獲配置和狀態(3A 例程除外)都封裝在請求和結果中。
啟動和預期的操作順序
本節包含對使用相機 API 時預期步驟的詳細說明。請參閱platform/hardware/interfaces/camera/了解 HIDL 接口定義。
枚舉、打開相機設備並創建活動會話
- 初始化後,框架開始偵聽任何現有的實現
ICameraProvider
接口的相機提供程序。如果存在這樣的提供者或提供者,框架將嘗試建立連接。 - 該框架通過
ICameraProvider::getCameraIdList()
枚舉相機設備。 - 該框架通過調用相應的
ICameraProvider::getCameraDeviceInterface_VX_X()
來實例化一個新的ICameraDevice
。 - 框架調用
ICameraDevice::open()
來創建一個新的活動捕獲會話 ICameraDeviceSession。
使用活動的相機會話
- 框架調用
ICameraDeviceSession::configureStreams()
並帶有 HAL 設備的輸入/輸出流列表。 - 該框架通過調用
ICameraDeviceSession::constructDefaultRequestSettings()
來請求某些用例的默認設置。這可能發生在ICameraDeviceSession
由ICameraDevice::open
創建後的任何時候。 - 框架構造第一個捕獲請求並將其發送到 HAL,其中包含基於一組默認設置的設置,以及框架之前已註冊的至少一個輸出流。這通過
ICameraDeviceSession::processCaptureRequest()
發送到 HAL。 HAL 必須阻止此調用的返回,直到它準備好發送下一個請求。 - 框架繼續提交請求並調用
ICameraDeviceSession::constructDefaultRequestSettings()
以根據需要獲取其他用例的默認設置緩衝區。 - 當請求捕獲開始時(傳感器開始為捕獲公開),HAL 使用 SHUTTER 消息調用
ICameraDeviceCallback::notify()
,包括幀號和開始曝光的時間戳。此通知回調不必在第一次processCaptureResult()
調用請求之前發生,但在調用該捕獲的notify()
之前,不會將結果傳遞給應用程序進行捕獲。 - 經過一些管道延遲後,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()
並出現致命錯誤,框架將不會從設備接收進一步的回調。在notify()
方法從致命錯誤消息返回後,除了close()
之外的方法應該返回 -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 | 離開 | 沒有任何 |
白平衡_* | android.colorCorrection.transform。如果 android.colorCorrection.mode 為 FAST 或 HIGH_QUALITY,則進行特定於平台的調整。 | |
android.control.afMode | 離開 | 沒有任何 |
焦點模式_* | android.lens.focusDistance | |
android.control.videoStabilization | 離開 | 沒有任何 |
上 | 可以調整android.scaler.cropRegion實現視頻穩定 | |
android.control.mode | 離開 | AE、AWB 和 AF 被禁用 |
汽車 | 使用單獨的 AE、AWB 和 AF 設置 | |
SCENE_MODE_* | 可以覆蓋上面列出的所有參數。個別 3A 控制被禁用。 |
圖 2 中的 Image Processing 模塊中的控件都按照類似的原理運行,一般每個模塊都有三種模式:
- OFF:禁用此處理塊。去馬賽克、色彩校正和色調曲線調整塊不能被禁用。
- FAST:在這種模式下,與 OFF 模式相比,處理塊可能不會減慢輸出幀速率,但在其他情況下,它應該會在該限制下產生最佳質量的輸出。通常,這將用於預覽或視頻錄製模式,或用於靜態圖像的連拍。在某些設備上,這可能相當於 OFF 模式(不減慢幀率就無法進行任何處理),而在某些設備上,這可能相當於 HIGH_QUALITY 模式(最佳質量仍然不會減慢幀率)。
- HIGH_QUALITY:在此模式下,處理塊應盡可能產生最佳質量結果,並根據需要減慢輸出幀速率。通常,這將用於高質量的靜態捕捉。一些塊包括一個手動控制,可以選擇性地選擇而不是 FAST 或 HIGH_QUALITY。例如,顏色校正塊支持顏色變換矩陣,而色調曲線調整支持任意全局色調映射曲線。
相機子系統可以支持的最大幀速率是多種因素的函數:
- 輸出圖像流的請求分辨率
- 成像儀上的分級/跳過模式的可用性
- 成像儀接口帶寬
- 各種 ISP 處理模塊的帶寬
由於這些因素在不同的 ISP 和傳感器之間可能會有很大差異,因此相機 HAL 接口試圖將帶寬限制抽象為盡可能簡單的模型。提出的模型具有以下特點:
- 圖像傳感器始終配置為根據應用程序請求的輸出流大小輸出可能的最小分辨率。最小分辨率被定義為至少與請求的最大輸出流大小一樣大。
- 由於任何請求都可能使用任何或所有當前配置的輸出流,因此必須將傳感器和 ISP 配置為支持將單個捕獲同時擴展到所有流。
- 對於不包含它們的請求,JPEG 流就像處理過的 YUV 流一樣;在直接引用它們的請求中,它們充當 JPEG 流。
- JPEG 處理器可以與相機管道的其餘部分同時運行,但一次不能處理多個捕獲。