自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 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
来配置输出流组合。如需详细了解强制性输出流组合,请参阅常规拍摄中的“10 位输出的其他有保证配置”表。
要求
如需支持 10 位相机输出,设备必须具备 10 位或更高色深的相机传感器以及相应的 ISP 支持。如需详细了解对 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 位相机输出实现并确保第三方应用可启用该功能,建议执行以下三个阶段的验证。
对于 10 位相机输出的视觉验证,假定设备支持显示 HDR(1000 尼特以上的屏幕),且视频观看应用(例如 Google 相册)支持播放 HDR 视频。
测试 API 功能正确性
为了测试 10 位相机输出的 API 功能正确性,请运行以下 CTS 测试、相机 ITS 测试和 VTS 测试:
比较原生相机和第三方应用
我们强烈建议确保使用第三方应用拍摄 10 位视频的结果与使用原生相机应用拍摄的结果哪怕不能完全相同也要相似。这意味着,应将曝光、动态范围和色彩等微调选择从原生应用沿用到第三方应用。如需验证设备上支持 10 位相机输出的第三方应用的视频录制行为,请使用 GitHub 上的 Camera2Video 示例应用。由于传感器、面板、观看条件和供应商偏好设置可发生变化,以下准则用于说明可以目视辨别的 HDR 方面但没有给出目标数字。
建议用于进行比较的场景
如需对原生相机应用和第三方应用进行比较,请在原生相机应用和 Camera2Video 示例应用中使用多个不同场景拍摄视频。以下是建议用于进行比较的场景:
- 中等光线到弱光的场景,有蜡烛或明亮的小灯等可形成显著亮度范围的明亮物体。此场景用于确认自动曝光行为和动态范围。
- 明亮的户外场景,色彩鲜艳并有能产生明亮高光的反光物体,例如汽车上的铬合金保险杠。此场景用于确认能否呈现具有更明亮高光的明亮场景。
- 普通低动态范围场景,例如住宅或办公室中的室内自然场景。此场景用于确认不太极端的光照条件下的行为是否符合预期。
对于所有场景,我们都建议包含人物和人脸,用于验证曝光、色彩和肤色处理。减少镜头间的差异可以简化连续比较。
比较标准动态范围和高动态范围
为了确保能够感知到使用 10 位动态范围配置文件优于标准动态范围配置文件,请将使用 SDR(无 HDR 配置文件)拍摄的视频与 HDR 视频进行比较,确认能够在拍摄中表现出 HDR 的关键方面。如需比较 SDR 和 HDR,请使用 Camera2Video 示例应用和建议使用的场景对原生相机应用和第三方应用进行比较。
以下是在建议使用的场景中需要验证的关键方面。由于支持 HDR 的显示面板具有不同的亮度(以尼特或流明为衡量单位),因此下面给出的数字仅用作示例:
- 在中等光线到弱光的场景中,蜡烛或小灯的明亮高光在 HDR 片段中以屏幕的最大亮度(可能高达 1000 尼特)呈现,而在 SDR 片段中则以 SDR 的最大亮度(约 100 尼特)呈现。在 HDR 片段中,明亮的高光应从屏幕上透出,让用户感知到该场景真正的动态范围。与 HDR 片段相比,SDR 片段应当显得反差较小、亮度较低。
- 在明亮的输出场景中,根据设备的微调选择,HDR 片段的屏幕亮度会显示出与 SDR 片段的明显差异。在 HDR 片段中,整个场景的屏幕亮度(具体取决于动态余量)应更高(例如高达 800 尼特),而铬合金保险杠等明亮高光部位的屏幕亮度甚至更高(差不多达到屏幕最大亮度)。
- 在普通低动态范围室内拍摄中,HDR 和 SDR 片段的色彩和色调相似,只是 HDR 拍摄的亮度可能高于 SDR 拍摄。HDR 的亮度不应低于 SDR。如果因为微调选择而导致不可能做到这一点,请确保第三方应用的行为与原生相机应用的行为一致。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-04-04。
[null,null,["最后更新时间 (UTC):2025-04-04。"],[],[],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."]]