多相機支持

Android 9 透過由兩個或多個指向同一方向的實體相機裝置組成的新邏輯相機裝置引入了對多相機裝置的 API 支援。邏輯相機設備作為單一 CameraDevice/CaptureSession 暴露給應用程序，允許與 HAL 整合的多相機功能進行互動。應用程式可以選擇存取和控制底層實體攝影機串流、元資料和控制項。

多攝像頭支援

圖1 。多攝像頭支援

在此圖中，不同的攝影機 ID 採用顏色編碼。該應用程式可以同時從每個實體相機傳輸原始緩衝區。還可以設定單獨的控制並從不同的實體相機接收單獨的元資料。

範例和來源

多相機設備必須宣傳邏輯多相機功能。

相機用戶端可以透過呼叫getPhysicalCameraIds()查詢來構成特定邏輯相機的實體裝置的相機 ID。作為結果的一部分傳回的 ID 然後用於透過setPhysicalCameraId()單獨控制實體設備。可以透過呼叫getPhysicalCameraResults()從完整結果中查詢來自此類單獨請求的結果。

單獨的實體相機請求可能僅支援有限的參數子集。要接收支援的參數列表，開發人員可以呼叫getAvailablePhysicalCameraRequestKeys() 。

僅支援非重新處理請求以及單色和拜耳感測器的實體相機串流。

執行

支援清單

在HAL端添加邏輯多相機設備：

對於運行 Android 9 的設備，相機設備必須支援將一個邏輯 YUV/RAW 流替換為來自兩個實體相機的相同大小（不適用於 RAW 流）和相同格式的實體流。這不適用於運行 Android 10 的裝置。

對於運行 Android 10 且相機 HAL 設備版本為3.5或更高版本的設備，相機設備必須支援isStreamCombinationSupported ，以便應用查詢是否支援包含實體流的特定流組合。

碼流配置圖

對於邏輯攝影機，某個硬體層級的攝影機裝置的強制流組合與CameraDevice.createCaptureSession中所需的串流組合相同。流配置映射中的所有流都必須是邏輯流。

對於支援RAW功能且實體子攝影機尺寸不同的邏輯攝影機設備，如果應用程式配置了邏輯RAW串流，則邏輯攝影機設備不得切換到具有不同感測器尺寸的實體子攝影機。這可以確保現有的 RAW 捕獲應用程式不會崩潰。

要透過在 RAW 捕獲期間在物理子攝影機之間切換來利用 HAL 實現的光學變焦，應用程式必須配置物理子攝影機流而不是邏輯 RAW 流。

保證流組合

邏輯攝影機及其底層實體攝影機都必須保證其設備等級所需的強制流組合。

根據其硬體等級和功能，邏輯相機設備應以與實體相機設備相同的方式運作。建議其功能集是單一實體相機功能集的超集。

在運行 Android 9 的裝置上，對於每個保證的串流組合，邏輯攝影機必須支援：

  • 將一個邏輯 YUV_420_888 或原始流替換為兩個相同大小和格式的物理流，每個流來自單獨的實體相機，前提是實體相機支援該大小和格式。

  • 如果邏輯攝影機不宣傳 RAW 功能，但底層實體攝影機宣傳 RAW 功能，則添加兩個原始串流，每個實體攝影機一個。當實體相機具有不同的感測器尺寸時，通常會發生這種情況。

  • 使用物理流代替相同大小和格式的邏輯流。當物理流和邏輯流的最小幀持續時間相同時，這不得降低捕獲的幀速率。

性能和功耗考慮因素

  • 表現：

    • 由於資源限制，配置和傳輸實體流可能會降低邏輯攝影機的擷取速率。
    • 如果底層相機設定為不同的幀速率，則套用實體相機設定可能會降低捕捉速率。

  • 力量：

    • HAL 的功耗優化在預設情況下繼續發揮作用。
    • 配置或請求物理流可能會覆蓋 HAL 的內部功耗最佳化並導致更多的功耗。

客製化

您可以透過以下方式自訂您的裝置實現。

  • 邏輯相機設備的融合輸出完全取決於 HAL 實作。關於如何從實體相機導出融合邏輯流的決定對於應用程式和 Android 相機框架來說是透明的。
  • 可以選擇支援單獨的實體請求和結果。此類請求中的可用參數集也完全取決於特定的 HAL 實作。
  • 從 Android 10 開始，HAL 可以透過選擇不在getCameraIdList中公佈部分或全部 PHYSICAL_ID 來減少應用程式可以直接開啟的相機數量。然後呼叫getPhysicalCameraCharacteristics必須傳回實體相機的特性。

驗證

邏輯多攝影機設備必須像任何其他常規攝影機一樣通過攝影機 CTS。可以在LogicalCameraDeviceTest模組中找到針對此類裝置的測試案例。

這三項 ITS 測試針對多相機系統，以促進影像的正確融合：

場景 1 和場景 4 測試使用盒裝 ITS測試裝置運作。 test_multi_camera_match測試斷言當兩個攝影機均啟用時影像中心的亮度匹配。 test_multi_camera_alignment測試斷言相機間距、方向和畸變參數已正確載入。如果多攝影機系統包含寬 FoV 攝影機 (>90o)，則需要 ITS 盒的 rev2 版本。

Sensor_fusion是第二個測試裝置，可實現重複的、規定的手機運動，並斷言陀螺儀和影像感測器時間戳匹配以及多相機幀同步。

所有包裝盒均可透過 AcuSpec, Inc.（ www.acuspecinc.com 、fred@acuspecinc.com）和 MYWAY Manufacturing（ www.myway.tw 、sales@myway.tw）購買。此外，rev1 ITS 盒子可透過 West-Mark 購買（ www.west-mark.com 、dgoodman@west-mark.com）。

最佳實踐

要充分利用多攝影機啟用的功能，同時保持應用程式相容性，請在實現邏輯多攝影機裝置時遵循以下最佳實踐：

  • （Android 10 或更高版本）從getCameraIdList隱藏實體子相機。這減少了應用程式可以直接打開的相機數量，從而無需應用程式具有複雜的相機選擇邏輯。
  • （Android 11 或更高版本）對於支援光學變焦的邏輯多相機設備，請實作ANDROID_CONTROL_ZOOM_RATIO API，並僅使用ANDROID_SCALER_CROP_REGION進行寬高比裁切。 ANDROID_CONTROL_ZOOM_RATIO使設備能夠縮小並保持更好的精度。在這種情況下，HAL 必須調整ANDROID_SCALER_CROP_REGION 、 ANDROID_CONTROL_AE_REGIONS 、 ANDROID_CONTROL_AWB_REGIONS 、 ANDROID_CONTROL_AF_REGIONS 、 ANDROID_STATISTICS_FACE_RECTANGLES ;R) ANDROID_STATISTICS_FACE_LANDMARKS 。有關ANDROID_SCALER_CROP_REGION如何與ANDROID_CONTROL_ZOOM_RATIO配合使用的更多信息，請參閱camera3_crop_reprocess#cropping 。
  • 對於具有不同功能的實體攝影機的多攝影機設備，請確保僅當整個變焦範圍支援某個值或範圍時，該設備才會通告對控制項的某個值或範圍的支援。例如，如果邏輯相機由超廣角、廣角和長焦相機組成，請執行以下操作：
    • 如果實體相機的活動數組大小ANDROID_STATISTICS_FACE_LANDMARKS ，則相機 HAL 必須為ANDROID_SCALER_CROP_REGION 、 ANDROID_CONTROL_AE_REGIONS 、 ANDROID_CONTROL_AWB_REGIONS 、 ANDROID_CONTROL_AF_REGIONS ISTINTA_RIONS 矩陣到邏輯組，的映射ANDROID_STATISTICS_FACE_RECTANGLES以便從應用程式的從角度來看，座標係是邏輯相機的活動陣列大小。
    • 如果廣角和長焦相機支援自動對焦，但超廣角相機是定焦的，請確保邏輯相機宣傳自動對焦支援。 HAL 必須模擬超廣角相機的自動對焦狀態機，以便當應用程式縮小到超廣角鏡頭時，底層實體相機是固定焦點的事實對應用程式以及支援的 AF 模式的自動對焦狀態機是透明的按預期工作。
    • 如果廣角和長焦相機支援4K @ 60 fps，而超廣角相機僅支援4K @ 30 fps，或1080p @ 60 fps，但不支援4K @ 60 fps，請確保邏輯相機不會在廣告中宣傳4k @ 60 fps。其支援的流配置。這保證了邏輯相機功能的完整性，確保應用程式不會遇到在ANDROID_CONTROL_ZOOM_RATIO值小於 1 時無法實現 4k @ 60 fps 的問題。
  • 從 Android 10 開始，邏輯多相機不需要支援包含實體串流的串流組合。如果 HAL 支援與物理流的組合：
    • （Android 11 或更高版本）為了更好地處理立體深度和運動追蹤等用例，請使物理流輸出的視野與硬體所能實現的一樣大。然而，如果物理流和邏輯流源自於同一台實體相機，則硬體限制可能會強制物理流的視場與邏輯流相同。
    • 為了解決由多個物理流引起的記憶體壓力，如果物理流預計空閒一段時間，請確保應用程式使用discardFreeBuffers來取消分配空閒緩衝區（由消費者釋放，但尚未由生產者出列的緩衝區）的時間。
    • 如果來自不同實體相機的實體流通常不會附加到相同請求，請確保應用程式使用surface group ，以便使用緩衝區佇列來支援兩個面向應用程式的表面，從而減少記憶體消耗。