2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
メタデータと制御
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Android フレームワークで RAW 画像ファイルの保存をサポートするには、センサーの特性に関する詳細なメタデータが必要です。メタデータには、色空間やレンズ シェーディング関数などの情報が含まれます。
こうした情報はほとんどがカメラ サブシステムの静的プロパティであるため、出力パイプラインを構成したりリクエストを送信したりする前にクエリを実行できます。新しいカメラ API では、getCameraInfo()
メソッドによって提供される情報を大幅に拡張して、この情報をアプリに提供します。
さらに、カメラ サブシステムを手動で制御するには、それぞれのデバイスの現在の状態と、特定のフレームのキャプチャに使用される実際のパラメータに関するフィードバックが必要です。出力メタデータには、ハードウェアで実際に使用する制御値(露出時間、フレーム間隔、感度)が含まれている必要があります。これらの値は、クランプまたは端数処理が行われたタイミングをアプリが把握し、画像の撮影に使用する実際の設定を補正するために必須となります。
たとえば、アプリがリクエストでフレーム間隔を 0 に設定した場合、HAL はフレーム間隔をそのリクエストの実際の最小フレーム間隔でクランプし、出力結果のメタデータでその最小間隔を報告します。
そのため、アプリにカスタム 3A ルーティンを実装する必要がある場合(たとえば、HDR バーストを適切に測定する場合など)、受信した最新の結果をキャプチャして次のリクエストの設定を更新するために使用される設定をアプリが把握する必要があります。したがって、新たなカメラ API により、キャプチャしたそれぞれのフレームに相当量の動的メタデータが追加されます。これには、キャプチャに使用するリクエストされたパラメータと実際のパラメータ、およびタイムスタンプや統計ジェネレータ出力などといった追加のフレームごとのメタデータが含まれます。
設定ごとの制御
ほとんどの設定では、出力フレーム ストリームに大幅な途切れや遅延が発生せず、フレームごとに変更可能であることが望ましいとされます。出力フレームレートの制御がキャプチャ リクエストのフレーム間隔フィールドのみで行われ、処理ブロックの構成の変更に依存しないのが理想的です。実際には、カメラ パイプラインの出力解像度や出力形式、レンズの焦点距離などの物理デバイスに影響する制御など、特定の制御については変更に時間がかかることがわかっています。各制御セットの詳細な要件については後述します。
RAW センサーデータのサポート
新たな API では、高度なカメラアプリと RAW 画像ファイルをサポートするため、従来の API でサポートされるピクセル形式に加えて RAW センサーデータ(Bayer RAW)のサポート要件が追加されています。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-03-26 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-03-26 UTC。"],[],[],null,["# Metadata and controls\n\nMetadata support\n----------------\n\nTo support the saving of raw image files by the Android framework, substantial\nmetadata is required about the sensor's characteristics. This includes\ninformation such as color spaces and lens shading functions.\n\nMost of this information is a static property of the camera subsystem and can\ntherefore be queried before configuring any output pipelines or submitting any\nrequests. The new camera APIs greatly expand the information provided by the\n`getCameraInfo()` method to provide this information to the\napp.\n\nIn addition, manual control of the camera subsystem requires feedback from the\nassorted devices about their current state, and the actual parameters used in\ncapturing a given frame. The actual values of the controls (exposure time, frame\nduration, and sensitivity) as actually used by the hardware must be included in\nthe output metadata. This is essential so that apps know when either\nclamping or rounding took place, and so that the app can compensate for\nthe real settings used for image capture.\n\nFor example, if an app sets frame duration to 0 in a request, the HAL\nmust clamp the frame duration to the real minimum frame duration for that\nrequest, and report that clamped minimum duration in the output result metadata.\n\nSo if an app needs to implement a custom 3A routine (for example, to\nproperly meter for an HDR burst), it needs to know the settings used to capture\nthe latest set of results it has received to update the settings for\nthe next request. Therefore, the new camera API adds a substantial amount of\ndynamic metadata to each captured frame. This includes the requested and actual\nparameters used for the capture, as well as additional per-frame metadata such\nas timestamps and statistics generator output.\n\nPer-setting control\n-------------------\n\nFor most settings, the expectation is that they can be changed every frame,\nwithout introducing significant stutter or delay to the output frame stream.\nIdeally, the output frame rate should solely be controlled by the capture\nrequest's frame duration field, and be independent of any changes to processing\nblocks' configuration. In reality, some specific controls are known to be slow\nto change; these include the output resolution and output format of the camera\npipeline, as well as controls that affect physical devices, such as lens focus\ndistance. The exact requirements for each control set are detailed later.\n\nRaw sensor data support\n-----------------------\n\nIn addition to the pixel formats supported by\nthe old API, the new API adds a requirement for support for raw sensor data\n(Bayer RAW), both for advanced camera apps as well as to support raw\nimage files."]]