Google は、黒人コミュニティに対する人種平等の促進に取り組んでいます。取り組みを見る

マルチカメラ サポート

Android 9 では、新しい論理カメラデバイスを使った、マルチカメラ デバイス向けの API サポートが導入されました。論理カメラデバイスは、同じ方向を向いた複数の物理カメラデバイスで構成されます。論理カメラデバイスは 1 つの CameraDevice または CaptureSession としてアプリに公開され、HAL 統合マルチカメラ機能の操作を可能にします。アプリは必要に応じて、基となる物理カメラのストリーム、メタデータ、コントロールにアクセスして制御できます。

マルチカメラ サポート

図 1. マルチカメラ サポート

この図では、カメラ ID がそれぞれ色分けされています。アプリは、各物理カメラからの RAW バッファを同時にストリーミングできます。また、コントロールを個別に設定して、物理カメラごとに別々にメタデータを受け取ることもできます。

例とソース

マルチカメラ デバイスは、論理マルチカメラ機能を使用してアドバタイズする必要があります。

カメラ クライアントは getPhysicalCameraIds() を呼び出して、特定の論理カメラを構成している物理デバイスのカメラ ID を照会できます。結果の一部として返される ID は、setPhysicalCameraId() によって物理デバイスを個別に制御するために使用されます。結果全体に対してこのような個々のリクエスト結果を照会するには、getPhysicalCameraResults() を呼び出します。

個々の物理カメラ リクエストでサポートされるパラメータは限られています。サポートされるパラメータのリストを確認するには、getAvailablePhysicalCameraRequestKeys() を呼び出します。

物理カメラ ストリームは非再処理リクエストでのみサポートされ、モノクロ センサーとベイヤー センサーにのみ対応しています。

実装

サポート チェックリスト

論理マルチカメラ デバイスを HAL 側に追加するには:

Android 9 搭載デバイスの場合、カメラデバイスは 1 つの論理 YUV または RAW ストリームを、2 台の物理カメラからの同じサイズ（RAW ストリームには適用されない）と形式の物理ストリームで置き換えられる必要があります。これは Android 10 搭載デバイスには当てはまりません。

カメラ HAL デバイスのバージョンが 3.5 以降の Android 10 搭載デバイスの場合、物理ストリームを含む特定のストリームの組み合わせがサポートされているかどうかをアプリが照会できるように、カメラデバイスで isStreamCombinationSupported がサポートされている必要があります。

ストリーム構成マップ

論理カメラの場合、特定のハードウェア レベルのカメラデバイスで必須となるストリームの組み合わせは、CameraDevice.createCaptureSession で必要な組み合わせと同じです。ストリーム構成マップ内のすべてのストリームは、論理ストリームである必要があります。

サイズの異なる物理サブカメラを使用した RAW 機能をサポートする論理カメラデバイスでは、アプリで論理 RAW ストリームが構成された場合に、センサーサイズが異なる物理サブカメラに切り替える必要はありません。これにより、既存の RAW キャプチャ アプリが壊れることがなくなります。

RAW キャプチャ時に物理サブカメラを切り替えて HAL 実装の光学ズームを利用するには、アプリで論理 RAW ストリームではなく物理サブカメラ ストリームが構成される必要があります。

保証されるストリームの組み合わせ

論理カメラとその構成要素である物理カメラの両方で、それぞれのデバイスレベルに必要な必須ストリームの組み合わせが保証される必要があります。

論理カメラデバイスは、ハードウェア レベルと機能に基づいて物理カメラデバイスと同様に動作する必要があります。論理カメラの機能セットは、個々の物理カメラのスーパーセットであることが推奨されます。

Android 9 搭載デバイスでは、保証されるストリームの組み合わせごとに、論理カメラで次の操作が可能である必要があります。

  • 1 つの論理 YUV_420_888 または RAW ストリームを、各物理カメラからのサイズと形式が同じ 2 つの物理ストリームで置き換える（物理カメラでそのサイズと形式がサポートされている場合）。

  • 論理カメラが RAW 機能をアドバタイズせずに、その構成要素である物理カメラがアドバタイズしている場合（通常は物理カメラのセンサーサイズが異なるときに発生する）、2 つの RAW ストリーム（各物理カメラから 1 つずつ）を追加する。

  • 同じサイズと形式の論理ストリームの代わりに物理ストリームを使用する（物理ストリームと論理ストリームの最小フレーム時間が同じである場合は、キャプチャのフレームレートが下がらないようにする必要があります）。

パフォーマンスと電力に関する考慮事項

  • パフォーマンス:

    • 物理ストリームを構成してストリーミングすると、リソースの制約により論理カメラのキャプチャ レートが低下することがあります。
    • 物理カメラの設定を適用すると、基盤となるカメラのフレームレートが異なる場合に、キャプチャ レートが低下することがあります。

  • 電源:

    • デフォルトのケースでは、HAL の電力最適化が引き続き機能します。
    • 物理ストリームを構成またはリクエストすると、HAL の内部電力最適化がオーバーライドされて消費電力が増える場合があります。

カスタマイズ

デバイスの実装は次の方法でカスタマイズできます。

  • 論理カメラデバイスの融合出力は、HAL 実装によって異なります。物理カメラからの融合論理ストリームの導出方法に関する決定は、アプリと Android カメラ フレームワークに対して透過的です。
  • 必要に応じて、個々の物理リクエストと結果をサポートできます。このようなリクエストで使用できる一連のパラメータも、HAL 実装によって異なります。
  • Android 10 以降では、HAL を使用すると、getCameraIdList の一部またはすべての PHYSICAL_ID をアドバタイズしないことを選択して、アプリで直接開けるカメラの数を減らせます。getPhysicalCameraCharacteristics を呼び出すと、物理カメラの特性が返されます。

検証

論理マルチカメラ デバイスは、他の通常のカメラと同様にカメラ CTS に合格する必要があります。このタイプのデバイスをターゲットとするテストケースは、LogicalCameraDeviceTest モジュールで確認できます。

次の 3 つの ITS テストは、画像の適切な融合を容易にするマルチカメラ システムをターゲットにしています。

scene 1 テストと scene 4 テストは、ITS-in-a-box テスト装置を使って行います。test_multi_camera_match テストでは、2 台のカメラが両方とも有効になっているときに、画像の中心の明るさが一致することを確認します。test_multi_camera_alignment テストでは、カメラの間隔、向き、歪みのパラメータが正常に読み込まれていることを確認します。マルチカメラ システムに広角（90 度を超える）カメラが含まれている場合は、リビジョン 2 バージョンの ITS ボックスが必要です。

2 つ目のテスト装置である Sensor_fusion は、所定のスマートフォン動作の繰り返しを有効化し、ジャイロスコープとイメージ センサーのタイムスタンプが一致してマルチカメラ フレームが同期していることを確認します。

すべてのボックスは、AcuSpec, Inc.（www.acuspecinc.com、fred@acuspecinc.com）と MYWAY Manufacturing（www.myway.tw、sales@myway）から入手できます。また、リビジョン 1 の 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、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 は、ウルトラワイド カメラでオートフォーカス状態マシンをシミュレートすることで、アプリがウルトラワイド レンズにズームアウトしたときに、基盤となる物理カメラが固定フォーカスであるという事実がそのアプリに対して透過的となり、サポートされている AF モードの自動フォーカス状態マシンが想定どおりに機能するようにします。
    • ワイドカメラと望遠カメラで 4K / 60 fps をサポートしていて、ウルトラワイド カメラが 4K / 30 fps または 1080p / 60 fps のみをサポートし、4K / 60 fps をサポートしていない場合、サポートされているストリーム構成で論理カメラが 4K / 60 fps をアドバタイズしていないことを確認します。これにより、論理カメラ機能の整合性が保証され、1 より小さい ANDROID_CONTROL_ZOOM_RATIO の値で 4k / 60 fps を達成できないという問題がアプリで発生することを回避できます。
  • Android 10 以降、論理マルチカメラは、物理ストリームを含むストリームの組み合わせをサポートする必要はありません。HAL が次の物理ストリームとの組み合わせをサポートしている場合、以下を実行します。
    • （Android 11 以降）ステレオやモーション トラッキングからの奥行きなどのユースケースを適切に処理するには、物理ストリーム出力の視野角をハードウェアで達成できる限り大きくします。ただし、物理ストリームと論理ストリームが同じ物理カメラから発生している場合、ハードウェア制限により、物理ストリームの視野角が論理ストリームの視野角と同じになってしまう場合があります。
    • 複数の物理ストリームによって発生するメモリ負荷に対処するには、物理ストリームが一定期間アイドル状態になると予想される場合に、アプリが discardFreeBuffers を使用して、空きバッファ（コンシューマーによってリリースされたが、プロデューサーによってキューからまだ除外されていないバッファ）の割り当てを解除するようにしてください。
    • 通常、異なる物理カメラからの物理ストリームが同じリクエストに付与されていない場合は、アプリで surface group を使用していることを確認します。そうすることにより、1 つのバッファキューが 2 つのアプリとのサーフェスをバックアップするために使用され、メモリ消費量が削減されます。