2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
10 ビットカメラ出力
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Android 13 以降を搭載しているデバイスでは、Android によってダイナミック レンジ プロファイルを介した 10 ビットカメラ出力がサポートされます。カメラ クライアントは、ダイナミック レンジ プロファイルをストリーム構成の一部として構成できます。デバイス メーカーは、HLG10、HDR 10、HDR 10+、ドルビー ビジョンなどの 10 ビット ダイナミック レンジ プロファイルのサポートを追加できます。
10 ビットカメラ出力のサポートにより、カメラ クライアントは getSupportedProfiles
を呼び出して、デバイスでサポートされている 10 ビット ダイナミック レンジ プロファイルを検出できます。その後、フレームワークは、サポートされているダイナミック レンジ プロファイルとキャプチャ リクエストの制約(存在する場合)に関する情報を含む DynamicRangeProfiles
のインスタンスを返します。HLG10
プロファイルがサポートされている必要があります。推奨されるダイナミック レンジ プロファイルが、REQUEST_RECOMMENDED_TEN_BIT_DYNAMIC_RANGE_PROFILE
フィールドに一覧表示されます。
カメラ クライアントは、setDynamicRangeProfile
を呼び出してストリームの組み合わせを構成できます。必須の出力ストリームの組み合わせについて詳しくは、Regular capture の「10-bit output additional guaranteed configurations」の表をご覧ください。
要件
10 ビットカメラ出力をサポートするには、デバイスに、ISP がサポートされている 10 ビット以上対応のカメラセンサーが搭載されている必要があります。10 ビットのサポートに関連する互換性の要件について詳しくは、CDD のセクション 7.5. カメラをご覧ください。
実装
10 ビットカメラ出力をサポートするには、デバイス メーカーは次のカメラ AIDL HAL 統合を行う必要があります。
- カメラ機能に
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_DYNAMIC_RANGE_TEN_BIT
を含めます。
ANDROID_REQUEST_AVAILABLE_DYNAMIC_RANGE_PROFILES_MAP
に、サポートされているすべてのダイナミック レンジ プロファイルとそれらの制約のビットマップを入力します。HLG10
プロファイルがサポートされている必要があります。また、サポートされている最適な形式をカメラ クライアントに伝えるために、推奨されるダイナミック レンジ プロファイルを含める必要があります。
- P010 形式を使用するストリームのストリーム構成中にダイナミック レンジ プロファイル値をサポートするか、実装定義形式(
ImageFormat.PRIVATE
)をサポートするようにします。
- ダイナミック レンジ プロファイルに応じて、カメラサービスに通知する前に、処理された Gralloc 4 バッファの静的または動的メタデータ バッファを設定します。
カメラ HAL の 10 ビットカメラ出力について詳しくは、metadata_definitions.xml
内の以下をご覧ください。
10 ビットカメラ出力をサポートするカメラ HAL リファレンス実装については、/hardware/google/camera/devices/EmulatedCamera/hwl
をご覧ください。
検証
10 ビットカメラ出力の実装を検証し、サードパーティ アプリでこの機能を有効にできるようにするには、次の 3 つの段階の検証を行うことをおすすめします。
10 ビットカメラ出力の視覚的な検証では、デバイスが HDR の表示(1,000 ニト以上のディスプレイ)をサポートし、動画再生アプリ(Google フォトなど)が HDR 動画の再生をサポートしていることを前提としています。
API 機能の正確性をテストする
10 ビットカメラ出力の API 機能の正確性をテストするには、次の CTS、カメラ ITS、VTS テストを実行します。
ネイティブ カメラとサードパーティ アプリを比較する
サードパーティ アプリで 10 ビットの動画を撮影した結果が、ネイティブ カメラアプリと同一でないとしても、同様のものになるようにすることを強くおすすめします。つまり、露出、ダイナミック レンジ、色などの調整オプションを、ネイティブ アプリからサードパーティ アプリに引き継ぐ必要があります。デバイスで 10 ビットカメラ出力をサポートするサードパーティ アプリの録画の動作を確認するには、GitHub の Camera2Video サンプルアプリを使用します。センサー、パネル、視聴条件、ベンダーの設定はさまざまなため、以下のガイダンスでは、目標の数値を示さずに HDR の視覚的な側面について説明します。
比較に推奨されるシーン
ネイティブ カメラアプリとサードパーティ アプリを比較するには、ネイティブ カメラアプリと Camera2Video サンプルアプリの両方で、複数の異なるシーンを使用して動画を撮影します。比較での使用に推奨されるシーンは次のとおりです。
- 幅広い明るさを作り出す明るい物体(キャンドルや小さな明るいライトなど)がある、中程度の光量から少ない光量のシーン。これにより、自動露出動作とダイナミック レンジを確認できます。
- 明るいハイライトを作り出す鮮やかな色と反射物(車のクローム バンパーなど)がある、明るい屋外シーン。これにより、さらに明るいハイライトがある明るいシーンのレンダリングを確認できます。
- 自宅やオフィスの屋内の自然なシーンなど、標準的な低ダイナミック レンジのシーン。これにより、あまり極端ではない照明条件が想定どおりに動作することを確認できます。
すべてのシーンで、露出、色、肌色の処理を確認するために人物と顔を入れることをおすすめします。ショット間のばらつきを減らすと、連続して比較しやすくなります。
標準ダイナミック レンジとハイ ダイナミック レンジを比較する
標準のダイナミック レンジ プロファイルよりも 10 ビットのダイナミック レンジ プロファイルを使用する際にメリットが感じられることを確かめるには、SDR を使用した動画キャプチャ(HDR プロファイルなし)と HDR 動画を比較し、キャプチャに HDR の主要な側面が見られることを確認します。SDR と HDR を比較するには、Camera2Video サンプルアプリと、ネイティブ カメラアプリとサードパーティ アプリを比較する際に推奨されるシーンを使用します。
推奨されるシーンで確認すべき主要な側面は次のとおりです。HDR に対応しているディスプレイ パネルは明るさのレベル(ニトまたはルーメンで測定)がさまざまであるため、以下の数値は一例です。
- 中程度の光量から少ない光量のシーンでは、キャンドルや小さいライトの明るいハイライトは、HDR クリップではディスプレイの最大輝度(場合によっては最大 1,000 ニト)でレンダリングされ、SDR クリップでは SDR の最大輝度(約 100 ニト)でレンダリングされます。HDR クリップでは、明るいハイライトがディスプレイから輝きを放ち、ユーザーがシーンの実際のダイナミック レンジを認識できるようにする必要があります。HDR クリップと比較すると、SDR クリップは平坦で明るさが抑えられているように見える必要があります。
- 明るい出力シーンでは、デバイスの調整に応じて、HDR クリップでは SDR クリップと比較して画面の明るさに明らかな違いが現れます。HDR クリップの場合、シーン全体の画面の明るさ(ヘッドルームによって異なる)を上げる必要があり(最大 800 ニトなど)、クローム バンパーなどの明るいハイライトではさらに上げる必要があります(最大輝度近く)。
- 標準的な低ダイナミック レンジの屋内のキャプチャでは、HDR クリップと SDR クリップの色とトーンは類似していますが、HDR キャプチャのほうが SDR よりも明るい可能性があります。HDR は SDR より暗くしないでください。調整オプションによりこれが不可能な場合は、サードパーティ アプリの動作がネイティブのカメラアプリの動作と一致するようにします。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-04-04 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-04-04 UTC。"],[],[],null,["# 10-bit camera output\n\nFor devices running Android 13 and higher, Android\nsupports 10-bit camera output through dynamic range profiles that can be\nconfigured by the camera client as part of the stream configuration. Device\nmanufacturers can add support for 10-bit dynamic range profiles such as HLG10,\nHDR 10, HDR 10+, and Dolby Vision.\n\n10-bit camera output support lets camera clients discover supported 10-bit\ndynamic range profiles of a device by calling\n[`getSupportedProfiles`](https://developer.android.com/reference/android/hardware/camera2/params/DynamicRangeProfiles#getSupportedProfiles()).\nThe framework then returns an instance of\n[`DynamicRangeProfiles`](https://developer.android.com/reference/android/hardware/camera2/params/DynamicRangeProfiles),\nwhich includes information about supported dynamic range profiles and, if\navailable, capture request constraints. The\n[`HLG10`](https://developer.android.com/reference/android/hardware/camera2/params/DynamicRangeProfiles#HLG10)\nprofile must be supported. The recommended dynamic range profile is listed in\nthe\n[`REQUEST_RECOMMENDED_TEN_BIT_DYNAMIC_RANGE_PROFILE`](https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics#REQUEST_RECOMMENDED_TEN_BIT_DYNAMIC_RANGE_PROFILE)\nfield.\n\nCamera clients can configure stream combinations by calling\n[`setDynamicRangeProfile`](https://developer.android.com/reference/android/hardware/camera2/params/OutputConfiguration#setDynamicRangeProfile(long)).\nFor more information on mandatory output stream combinations, see the\n*10-bit output additional guaranteed configurations* table in\n[Regular capture](https://developer.android.com/reference/android/hardware/camera2/CameraDevice#regular-capture).\n\nRequirements\n------------\n\nTo support 10-bit camera output, the device must have a 10-bit or higher\ncapable camera sensor with respective ISP support. For details about related\ncompatibility requirements for 10-bit support, see section\n[7.5. Cameras](/docs/compatibility/13/android-13-cdd#75_cameras) in the CDD.\n\nImplementation\n--------------\n\nTo provide support for 10-bit camera output, device manufacturers must perform\nthe following Camera AIDL HAL integrations:\n\n- Include `ANDROID_REQUEST_AVAILABLE_CAPABILITIES_DYNAMIC_RANGE_TEN_BIT` in camera capabilities.\n- Populate `ANDROID_REQUEST_AVAILABLE_DYNAMIC_RANGE_PROFILES_MAP` with all supported dynamic range profiles and a bitmap of their constraints. The [`HLG10`](https://developer.android.com/reference/android/hardware/camera2/params/DynamicRangeProfiles#HLG10) profile must be supported. You must also include a recommended dynamic range profile to inform camera clients of the optimal supported format.\n- Ensure support for the dynamic range profile value during stream configuration for streams using the [P010](https://developer.android.com/reference/android/graphics/ImageFormat#YCBCR_P010) format or support for an implementation-defined format ([`ImageFormat.PRIVATE`](https://developer.android.com/reference/android/graphics/ImageFormat#PRIVATE)).\n- Depending on the dynamic range profile, set the static or dynamic metadata buffer of processed Gralloc 4 buffers before notifying the camera service.\n\nFor further details on 10-bit camera output in the Camera HAL, see the\nfollowing in [`metadata_definitions.xml`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/media/camera/docs/metadata_definitions.xml):\n\n- [`DYNAMIC_RANGE_TEN_BIT`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/media/camera/docs/metadata_definitions.xml?q=DYNAMIC_RANGE_TEN_BIT)\n- HAL details for [`availableDynamicRangeProfilesMap`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/media/camera/docs/metadata_definitions.xml?q=availableDynamicRangeProfilesMap)\n- [`recommendedTenBitDynamicRangeProfile`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/media/camera/docs/metadata_definitions.xml?q=recommendedTenBitDynamicRangeProfile)\n- [`10BIT_OUTPUT`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/media/camera/docs/metadata_definitions.xml?q=10BIT_OUTPUT)\n\nFor a reference Camera HAL implementation supporting 10-bit camera output, see\n[`/hardware/google/camera/devices/EmulatedCamera/hwl`](https://cs.android.com/android/platform/superproject/+/android-latest-release:hardware/google/camera/devices/EmulatedCamera/hwl/).\n\nValidation\n----------\n\nTo validate your implementation of 10-bit camera output and ensure that\nthird-party apps can enable the feature, we recommend performing the following\nthree stages of validation.\n\n- [Test API functional correctness](#test-api-functional-correctness)\n- [Compare native camera and third-party app](#compare-native-third-party-app)\n- [Compare standard dynamic range and high dynamic range](#compare-sdr-hdr)\n\nFor visual validation of 10-bit camera output, it's assumed that the device\nsupports displaying HDR (1000+ nits display), and the video viewing app (for\nexample, Google Photos) supports playback of HDR video.\n\n### Test API functional correctness\n\nTo test the API functional correctness of 10-bit camera output, run the\nfollowing CTS, camera ITS, and VTS tests:\n\n- [`hardware/interfaces/camera/provider/aidl/vts/`](https://cs.android.com/android/platform/superproject/+/android-latest-release:hardware/interfaces/camera/provider/aidl/vts/): Tests for basic discovery, configuration, and streaming, and checks for the presence of HDR metadata where required.\n- [`tests/camera/src/android/hardware/camera2/cts/`](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/tests/camera/src/android/hardware/camera2/cts): Ensures that the camera behaves according to the AOSP API specifications.\n- [`cts/apps/CameraITS`](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/apps/CameraITS): Confirms general video behavior is consistent when HDR profiles are used. The specific test is [`tests/scene4/test_video_aspect_ratio_and_crop.py`](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/apps/CameraITS/tests/scene4/test_video_aspect_ratio_and_crop.py).\n\n### Compare native camera and third-party app\n\nWe strongly recommend ensuring that the results of capturing 10-bit videos with\na third-party app are similar, if not identical, to the native camera app. This\nmeans that tuning choices, such as exposure, dynamic range, and color, should\ncarry forward from the native app to third-party apps. To verify the video\nrecording behavior of a third-party app supporting 10-bit camera output on your\ndevice, use the\n[Camera2Video sample app](https://github.com/android/camera-samples/tree/main/Camera2Video)\non GitHub. The following guidance serves to illustrate the visible aspects of\nHDR without objective numbers, due to the variability of sensors, panels,\nviewing conditions, and vendor preferences.\n\n#### Suggested scenes for comparison\n\nTo make a comparison between the native camera app and a third-party app,\ncapture videos using several different scenes with both the native camera app\nand the Camera2Video sample app. The following are suggested scenes to use for\ncomparison:\n\n- A mid-light to low-light scene with a bright object, such as a candle or small bright light that creates a significant range of brightness. This confirms the auto exposure behavior and dynamic range.\n- A bright outdoor scene with vibrant colors and reflective objects such as chrome bumpers on a car, which creates bright highlights. This confirms the rendering for bright scenes with even brighter highlights.\n- A mid-range, low dynamic range scene such as an indoor natural scene in a home or office. This confirms that less extreme lighting conditions behave as expected.\n\nFor all scenes, we recommend having people and faces to verify exposure, color,\nand skin tone handling. Reducing shot-to-shot variation eases back-to-back\ncomparisons.\n\n### Compare standard dynamic range and high dynamic range\n\nTo ensure that there's a perceived benefit of using a 10-bit dynamic range\nprofile over a standard dynamic range profile, compare video captures using SDR\n(no HDR profile) against HDR videos to confirm that key aspects of HDR appear in\nthe captures. To compare SDR and HDR, use the\n[Camera2Video sample app](https://github.com/android/camera-samples/tree/main/Camera2Video)\nand [suggested scenes](#suggested-scenes) for comparing the native camera\napp and third-party apps.\n\nThe following are key aspects to verify in the suggested scenes. Display panels\ncapable of HDR vary in brightness levels (measured in nits or lumens), so the\nfollowing numbers given are meant to be examples:\n\n- In the mid-light to low-light scene, the bright highlights of the candle or small light are rendered at *max brightness for the display* (possibly up to 1000 nits) in the HDR clip, and rendered at *max brightness for SDR* (approximately 100 nits) in the SDR clip. In the HDR clip, the bright highlights should shine out of the display, capturing the user's perception of what the scene's true dynamic range was. Compared to the HDR clip, the SDR clip should appear as flatter and less bright.\n- In the bright output scene, depending on the device's tuning, the HDR clip shows an apparent difference in screen brightness as compared to the SDR clip. For the HDR clip, the screen brightness for the overall scene (depending on headroom) should be higher, for example, up to 800 nits, and even more so for the bright highlights such as the chrome bumpers, around maximum brightness.\n- In the mid-range, low dynamic range indoor capture, the HDR and SDR clips are similar in color and tone, with the HDR capture being potentially brighter than the SDR. The HDR shouldn't be darker than the SDR. If tuning choices make this impossible, ensure that the third-party app behavior matches the native camera app behavior."]]