HAL サブシステム

リクエスト

アプリフレームワークは、キャプチャした結果のリクエストをカメラのサブシステムに送信します。1 つのリクエストは 1 群の結果に対応します。リクエストには、結果の取得と処理に関するすべての構成情報がカプセル化されています。この情報には、解像度やピクセル形式、マニュアルセンサー、レンズ、フラッシュコントロール、3A 動作モード、RAW から YUV への処理コントロール、統計情報の生成などが含まれます。これにより、結果の出力と処理をより詳細に制御できます。1 回のリクエストで複数のリクエストを送信でき、リクエストの送信はブロックされません。リクエストは、常に受信した順に処理されます。

図 1. カメラモデル

HAL とカメラのサブシステム

カメラのサブシステムには、3A アルゴリズムや処理制御などのカメラパイプライン内のコンポーネントの実装が含まれます。カメラ HAL は、これらのコンポーネントを実装するためのインターフェースを備えています。複数のデバイスメーカーと画像信号処理装置（ISP またはカメラセンサー）のベンダー間におけるクロスプラットフォームの互換性を維持するため、カメラのパイプラインモデルは仮想モデルであり、実際の ISP には直接対応しません。ただし、実際の処理パイプラインと非常に類似しているため、ハードウェアに対して効率的にマッピングできます。さらに、その抽象性によって、品質や効率性、デバイス間の互換性を損なうことなく、異なる複数のアルゴリズムとオペレーションの順序に対応します。

カメラのパイプラインは、アプリフレームワークで自動フォーカスなどの機能を起動するトリガーもサポートしています。また、自動フォーカスロックやエラーなどのイベントをアプリに通知するための情報をアプリのフレームワークに送信します。

図 2. カメラパイプライン

上の図に示されている画像処理ブロックの一部は、初期リリースでは明確に定義されていません。カメラのパイプラインでは、次のことを前提としています。

RAW Bayer の出力が ISP 内では処理されていない。
統計情報が元のセンサーデータに基づいて生成されている。
センサーの測定データを YUV に変換する各種の処理ブロックが、任意の順序である。
複数のスケールユニットとクロップユニットがある場合は、すべてのスケーラーユニットで出力リージョンコントロール（デジタルズーム）が共有されている。ただし、各ユニットの出力解像度とピクセル形式は異なる場合がある。

API 使用の概要
Android Camera API の使用に関する手順の概要は次のとおりです。この手順の詳細（API 呼び出しを含む）については、起動および必要な操作シーケンスのセクションを参照してください。

カメラデバイスを判別して列挙します。
デバイスを開いてリスナーを接続します。
ターゲットとするユースケースの出力を構成します（静止画撮影、録画など）。
ターゲットとするユースケースのリクエストを作成します。
キャプチャ / リクエストを反復、バーストします。
結果メタデータと画像データを受信します。
ユースケースを切り替える場合は、手順 3 に戻ります。

HAL 操作の概要

キャプチャの非同期リクエストはフレームワークから送信されます。
HAL デバイスはリクエストを順番に処理する必要があります。リクエストごとに、出力結果メタデータ、1 つ以上の出力イメージバッファを生成します。
リクエストと結果、および後続のリクエストで参照されるストリームは FIFO（先入れ先出し）されます。
必要に応じてフレームワークが出力とリクエストを照合できるように、タイムスタンプは特定のリクエストからのすべての出力に対して同一であることが必要です。
すべてのキャプチャ構成および状態（3A ルーティンを除く）は、リクエストと結果にカプセル化されます。

図 3. カメラ HAL の概要

起動および必要な操作シーケンス

ここでは、Camera API の使用時に必要な手順を詳しく説明します。HIDL インターフェースの定義については、platform/hardware/interfaces/camera/ を参照してください。

列挙、カメラデバイスの起動、アクティブなセッションの作成

初期化後、フレームワークが ICameraProvider インターフェースを実装する現在のカメラプロバイダのリッスンを開始します。プロバイダが存在する場合、フレームワークは接続の確立を試みます。
フレームワークが ICameraProvider::getCameraIdList() を介してカメラデバイスを列挙します。
フレームワークがそれぞれの ICameraProvider::getCameraDeviceInterface_VX_X() を呼び出すことで新しい ICameraDevice をインスタンス化します。
フレームワークが ICameraDevice::open() を呼び出して新しいアクティブなキャプチャセッション ICameraDeviceSession を作成します。

アクティブなカメラセッションの使用

フレームワークが HAL デバイスへの入出力ストリームのリストから ICameraDeviceSession::configureStreams() を呼び出します。
ICameraDeviceSession::constructDefaultRequestSettings() の呼び出しにより、フレームワークがいくつかのユースケースのデフォルト設定をリクエストします。これは、ICameraDeviceSession が ICameraDevice::open によって作成された後、常に発生する可能性があります。
既定の設定およびフレームワークによって以前に登録された少なくとも 1 つの出力ストリームに基づいて、フレームワークが最初のキャプチャリクエストを作成して HAL に送信します。これは ICameraDeviceSession::processCaptureRequest() で HAL に送信されます。HAL は、次のリクエストを送信する準備が整うまで、この呼び出しの戻り値をブロックする必要があります。
フレームワークが引き続きリクエストを送信し、ICameraDeviceSession::constructDefaultRequestSettings() を呼び出して、必要に応じて他のユースケースのデフォルト設定バッファを取得します。
リクエストのキャプチャが開始されると（センサーがキャプチャのために露出を開始します）、HAL はフレーム番号と露出開始のタイムスタンプを含む SHUTTER メッセージで ICameraDeviceCallback::notify() を呼び出します。この通知コールバックは必ずしもリクエストによる最初の processCaptureResult() 呼び出しの前に発生する必要はありませんが、そのキャプチャの notify() が呼び出されるまで、キャプチャの結果はアプリケーションに送信されません。
パイプラインの遅延後、HAL は ICameraDeviceCallback::processCaptureResult() を使用して完了したキャプチャについてフレームワークへの戻り値の送信を開始します。これらの値は、リクエストの送信順序と同じ順に返されます。カメラ HAL デバイスのパイプラインの深さに応じて、複数のリクエストを一度に送信できます。

しばらくすると、次のいずれかが発生します。

フレームワークが新しいリクエストの送信を停止し、既存のキャプチャが完了するのを待ってから（すべてのバッファが満たされ、結果がすべて返されます）、再度 ICameraDeviceSession::configureStreams() を呼び出します。これにより、カメラのハードウェアと一連の新しい入出力ストリームのパイプラインがリセットされます。一部のストリームについては、以前の構成から再利用される場合もあります。登録された出力ストリームが 1 つでも残っている場合、フレームワークは最初のキャプチャリクエストから HAL に再度送信します（それ以外の場合は、ICameraDeviceSession::configureStreams() が最初に必要となります）。
フレームワークが、カメラセッションを終了するために ICameraDeviceSession::close() を呼び出す場合があります。フレームワークからの他の呼び出しがアクティブでない場合、いつでもこの呼び出しが実行される可能性がありますが、実行中のキャプチャがすべて完了する（すべての結果が返され、バッファがすべて満たされる）までブロックされます。close() の呼び出しが返された後には、HAL から ICameraDeviceCallback への呼び出しは許可されません。close() の呼び出しを開始すると、フレームワークは他の HAL デバイス関数を呼び出すことができなくなります。
エラーまたは他の非同期イベントが発生した場合、HAL は適切なエラー / イベントメッセージで ICameraDeviceCallback::notify() を呼び出します。デバイス全体に及ぶ致命的なエラーの通知の送信後、HAL は close() が呼び出された場合のように動作します。ただし、HAL は notify() を呼び出す前に未処理のキャプチャをすべてキャンセルまたは完了する必要があるため、致命的なエラーにより notify() が呼び出された場合、フレームワークはデバイスからそれ以上のコールバックを受信しなくなります。close() 以外のメソッドは、notify() メソッドによる致命的なエラーメッセージの送信後に -ENODEV または NULL を返します。

図 4. カメラの操作フロー

ハードウェアレベル

カメラデバイスには、機能に応じて複数のハードウェアレベルを実装できます。詳細については、サポートされているハードウェアレベルを参照してください。

アプリケーションキャプチャリクエスト、3A コントロール、処理パイプライン間での通信

3A コントロールブロックの設定に応じて、カメラパイプラインはアプリケーションのキャプチャリクエストに含まれるパラメータの一部を無視し、3A コントロールルーティンから渡された値を代用します。たとえば、自動露出がアクティブな場合、センサーの露出時間、フレーム間隔、および感度パラメータはプラットフォームの 3A アルゴリズムによって制御され、アプリが指定する値は無視されます。3A ルーティンによりフレームに対して選択された値は、出力メタデータで報告する必要があります。次の表に、3A コントロールブロックのさまざまなモードと、それぞれのモードによって制御されるプロパティを示します。プロパティの定義については、platform/system/media/camera/docs/docs.html にあるファイルを参照してください。

パラメータ	状態	制御されるプロパティ
android.control.aeMode	オフ	なし
	ON	android.sensor.exposureTime、android.sensor.frameDuration、android.sensor.sensitivity、android.lens.aperture（サポートされている場合）、android.lens.filterDensity（サポートされている場合）
	ON_AUTO_FLASH	すべて ON、さらに 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	オフ	なし
	WHITE_BALANCE_*	android.colorCorrection.transform。android.colorCorrection.mode が FAST または HIGH_QUALITY の場合のプラットフォーム固有の補正。
android.control.afMode	オフ	なし
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	オフ	なし
	ON	android.scaler.cropRegion を調整して動画の手ぶれ補正を実装できます
android.control.mode	オフ	AE、AWB、AF は無効です
	自動	個別の AE、AWB、AF の設定が使用されます
	SCENE_MODE_*	上記のすべてのパラメータをオーバーライドできます。個別の 3A コントロールは無効です。

図 2 の画像処理ブロックのコントロールはすべて同様の原則で動作し、通常、各ブロックには次の 3 つのモードが存在します。

OFF: この処理ブロックは無効です。デモザイク、色補正、トーンカーブ調整のブロックは無効にできません。
FAST: このモードでは、処理ブロックによる出力フレームレートを OFF モードと同等以上に保ちながら、最高品質の出力を行います。通常、このモードはプレビュー、ビデオ録画モード、静止画像のバーストキャプチャに使用されます。一部のデバイスでは、これは OFF モードに相当します（あらゆる処理の実行時にフレームレートが低下します）。また、一部のデバイスでは、HIGH_QUALITY モードに相当します（最高品質でもフレームレートは低下しません）。
HIGH_QUALITY: このモードでは、処理ブロックは最高品質の結果を出力し、必要に応じて出力フレームレートを低下させます。通常、このモードは高品質の静止画撮影に使用されます。一部のブロックには、FAST または HIGH_QUALITY の代わりとしてオプション選択が可能な手動コントロールがあります。たとえば、色補正ブロックは色変換マトリックスをサポートしており、トーンカーブ調整は任意のグローバルトーンマッピング曲線をサポートしています。

カメラのサブシステムがサポート可能な最大フレームレートは、次のようなさまざまな要因に左右されます。

リクエストされた、出力画像ストリームの解像度
イメージャのビニングモードとスキップモードの可用性
イメージングインターフェースの帯域幅
さまざまな ISP 処理ブロックの帯域幅

これらの要因は ISP とセンサーによって大きく異なるため、カメラの HAL インターフェースは、帯域幅制限を可能な限り単純なモデルにする抽象化を試みます。このモデルには次の特徴があります。

イメージセンサーは、アプリケーションがリクエストする出力ストリームサイズの最小解像度を出力するように常に構成されます。最小解像度は、リクエストされた最大出力ストリームサイズと同等以上として定義されます。
リクエストにより、現在構成されている出力ストリームの一部またはすべてが使用される可能性もあるため、単一のキャプチャをすべてのストリームに同時にスケーリングできるようにセンサーと ISP を構成する必要があります。
JPEG ストリームは、そのストリーム自体が含まれないリクエスト（このリクエストでは直接参照され、JPEG ストリームとして機能）に対して処理された YUV ストリームと同様に機能します。
JPEG プロセッサは、残りのカメラパイプラインと同時に実行できますが、一度に複数のキャプチャを処理することはできません。