支援多相機拍攝

Android 9 推出 API，支援多相機裝置，方法是使用由兩個以上實體相機裝置組成的新邏輯相機裝置，這些裝置指向相同方向。邏輯攝影機裝置會向應用程式公開為單一 CameraDevice/CaptureSession，方便與 HAL 整合式多鏡頭功能互動。應用程式可選擇性存取及控制底層實體攝影機串流、中繼資料和控制項。

支援多部攝影機

圖 1. 支援多部攝影機

在這張圖中，不同的攝影機 ID 以不同顏色標示。應用程式可以同時從每個實體攝影機串流原始緩衝區。此外，您也可以設定個別控制項，並從不同的實體攝影機接收個別中繼資料。

範例和來源

宣傳多鏡頭裝置時，必須使用邏輯多鏡頭功能。

相機用戶端可以呼叫 getPhysicalCameraIds()，查詢特定邏輯攝影機是由哪些實體裝置組成。然後使用結果中傳回的 ID，透過 setPhysicalCameraId() 個別控制實體裝置。如要查詢這類個別要求的結果，請叫用 getPhysicalCameraResults()，從完整結果中查詢。

個別實體攝影機要求可能僅支援部分參數。如要取得支援的參數清單，開發人員可以呼叫 getAvailablePhysicalCameraRequestKeys()。

實體攝影機串流僅支援非重新處理要求，且僅支援單色和拜耳感應器。

實作

支援檢查清單

如要在 HAL 端新增邏輯多鏡頭裝置，請按照下列步驟操作：

如果是搭載 Android 9 的裝置，相機裝置必須支援以兩部實體相機的實體串流，取代一個大小相同 (不適用於 RAW 串流) 和格式相同的邏輯 YUV/RAW 串流。這項異動不適用於搭載 Android 10 的裝置。

如果裝置搭載 Android 10，且相機 HAL 裝置版本為 3.5 以上，相機裝置就必須支援 isStreamCombinationSupported，應用程式才能查詢是否支援含有實體串流的特定串流組合。

串流設定地圖

如果是邏輯攝影機，特定硬體層級的攝影機裝置強制串流組合，與 CameraDevice.createCaptureSession 中規定的組合相同。串流設定對應中的所有串流都必須是邏輯串流。

如果邏輯攝影機裝置支援 RAW 功能，且有不同尺寸的實體子攝影機，應用程式設定邏輯 RAW 串流時，邏輯攝影機裝置不得切換至感應器尺寸不同的實體子攝影機。確保現有的 RAW 拍攝應用程式不會中斷。

如要在擷取 RAW 影像時切換實體子攝影機，藉此運用 HAL 實作的光學變焦功能，應用程式必須設定實體子攝影機串流，而非邏輯 RAW 串流。

保證串流組合

邏輯攝影機和底層實體攝影機都必須保證裝置層級所需的必要串流組合。

邏輯攝影機裝置的運作方式應與實體攝影機裝置相同，具體取決於硬體層級和功能。建議其功能集是個別實體攝影機的超集。

在搭載 Android 9 的裝置上，針對每個保證的串流組合，邏輯相機必須支援：

  • 以兩個大小和格式相同的實體串流取代一個邏輯 YUV_420_888 或原始串流，前提是實體攝影機支援該大小和格式。

  • 如果邏輯攝影機未宣傳 RAW 功能，但基礎實體攝影機有，則新增兩個原始串流，分別來自每個實體攝影機。這通常發生在實體攝影機的感應器大小不同時。

  • 使用實體串流取代大小和格式相同的邏輯串流。如果實體和邏輯串流的最低影格時間長度相同，這項作業不得降低擷取作業的影格速率。

效能和電力考量

  • 成效：

    • 設定及串流播放實體串流時，可能會因資源限制而降低邏輯攝影機的擷取率。
    • 如果將基礎攝影機設為不同的影格速率，套用實體攝影機設定可能會降低擷取速率。

  • 電源：

    • HAL 的電源最佳化功能在預設情況下會繼續運作。
    • 設定或要求實體串流可能會覆寫 HAL 的內部電源最佳化設定，導致耗電量增加。

自訂

您可以透過下列方式自訂裝置導入作業。

  • 邏輯攝影機裝置的融合輸出內容完全取決於 HAL 實作方式。應用程式和 Android 相機架構會透明地決定如何從實體攝影機衍生出融合的邏輯串流。
  • 系統可視需要支援個別實體要求和結果。這類要求中可用的參數集也完全取決於特定 HAL 實作。
  • 從 Android 10 開始，HAL 可以選擇不在 getCameraIdList 中宣傳部分或所有 PHYSICAL_ID，藉此減少應用程式可直接開啟的相機數量。呼叫 getPhysicalCameraCharacteristics 必須傳回實體攝影機的特徵。

驗證

邏輯多鏡頭裝置必須通過攝影機 CTS，就像其他一般攝影機一樣。 如要查看以這類裝置為目標的測試案例，請前往 LogicalCameraDeviceTest 模組。

這三項 ITS 測試適用於多鏡頭系統，可協助正確融合影像：

場景 1 和場景 4 測試會使用 ITS-in-a-box 測試架執行。test_multi_camera_match 測試會確認兩個攝影機都啟用時，圖片中央的亮度是否一致。這項 test_multi_camera_alignment測試會確認相機間距、方向和變形參數是否已正確載入。如果多鏡頭系統包含廣角視野相機 (FOV > 90 度)，則必須使用第 2 版 ITS 盒。

Sensor_fusion 是第二個測試裝置，可重複執行規定的手機動作，並確認陀螺儀和影像感應器時間戳記相符，以及多鏡頭畫面同步。

所有包裝盒均可透過 AcuSpec, Inc. (www.acuspecinc.com、fred@acuspecinc.com) 和 MYWAY Manufacturing (www.myway.tw、sales@myway.tw) 取得。此外，您也可以透過 West-Mark (www.west-mark.com、dgoodman@west-mark.com) 購買 rev1 ITS 盒裝。

最佳做法

如要充分運用多鏡頭啟用的功能，同時維持應用程式相容性，請在實作邏輯多鏡頭裝置時，遵循下列最佳做法：

  • (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 和 ANDROID_STATISTICS_FACE_LANDMARKS 的座標系統，將縮放後的視野視為感應器有效陣列。如要進一步瞭解 ANDROID_SCALER_CROP_REGION 如何與 ANDROID_CONTROL_ZOOM_RATIO 搭配運作，請參閱 camera3_crop_reprocess#cropping。
  • 如果是具備實體相機的多相機裝置，且這些相機的功能各不相同，請務必確認裝置只會在整個變焦範圍支援特定值或範圍時，宣傳支援該值或範圍的控制項。舉例來說，如果邏輯攝影機是由超廣角、廣角和望遠攝影機組成，請執行下列操作：
    • 如果實體攝影機的有效陣列大小不同，相機 HAL 必須將實體攝影機的有效陣列對應至邏輯攝影機的有效陣列，以用於 ANDROID_SCALER_CROP_REGION、ANDROID_CONTROL_AE_REGIONS、ANDROID_CONTROL_AWB_REGIONS、ANDROID_CONTROL_AF_REGIONS、ANDROID_STATISTICS_FACE_RECTANGLES 和 ANDROID_STATISTICS_FACE_LANDMARKS，這樣從應用程式的角度來看，座標系統就是邏輯攝影機的有效陣列大小。
    • 如果廣角和望遠鏡頭支援自動對焦，但超廣角鏡頭為固定對焦，請確保邏輯攝影機會宣傳自動對焦支援功能。HAL 必須模擬超廣角相機的自動對焦狀態機，這樣當應用程式縮小到超廣角鏡頭時，應用程式就會忽略基礎實體相機是定焦的事實，支援的自動對焦模式的自動對焦狀態機也會如預期運作。
    • 如果廣角和望遠鏡頭支援 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，這樣一組緩衝區佇列就能支援兩個面向應用程式的介面，進而減少記憶體用量。