10-bit camera output

For devices running Android 13 and higher, Android supports 10-bit camera output through dynamic range profiles that can be configured by the camera client as part of the stream configuration. Device manufacturers can add support for 10-bit dynamic range profiles such as HLG10, HDR 10, HDR 10+, and Dolby Vision.

10-bit camera output support lets camera clients discover supported 10-bit dynamic range profiles of a device by calling getSupportedProfiles. The framework then returns an instance of DynamicRangeProfiles, which includes information about supported dynamic range profiles and, if available, capture request constraints. The HLG10 profile must be supported. The recommended dynamic range profile is listed in the REQUEST_RECOMMENDED_TEN_BIT_DYNAMIC_RANGE_PROFILE field.

Camera clients can configure stream combinations by calling setDynamicRangeProfile. For more information on mandatory output stream combinations, see the 10-bit output additional guaranteed configurations table in Regular capture.

Requirements

To support 10-bit camera output, the device must have a 10-bit or higher capable camera sensor with respective ISP support. For details about related compatibility requirements for 10-bit support, see section 7.5. Cameras in the CDD.

Implementation

To provide support for 10-bit camera output, device manufacturers must perform the following Camera AIDL HAL integrations:

  • Include ANDROID_REQUEST_AVAILABLE_CAPABILITIES_DYNAMIC_RANGE_TEN_BIT in camera capabilities.
  • Populate ANDROID_REQUEST_AVAILABLE_DYNAMIC_RANGE_PROFILES_MAP with all supported dynamic range profiles and a bitmap of their constraints. The HLG10 profile must be supported. You must also include a recommended dynamic range profile to inform camera clients of the optimal supported format.
  • Ensure support for the dynamic range profile value during stream configuration for streams using the P010 format or support for an implementation-defined format (ImageFormat.PRIVATE).
  • Depending on the dynamic range profile, set the static or dynamic metadata buffer of processed Gralloc 4 buffers before notifying the camera service.

For further details on 10-bit camera output in the Camera HAL, see the following in metadata_definitions.xml:

For a reference Camera HAL implementation supporting 10-bit camera output, see /hardware/google/camera/devices/EmulatedCamera/hwl.

Validation

To validate your implementation of 10-bit camera output and ensure that third-party apps can enable the feature, we recommend performing the following three stages of validation.

For visual validation of 10-bit camera output, it's assumed that the device supports displaying HDR (1000+ nits display), and the video viewing app (for example, Google Photos) supports playback of HDR video.

Test API functional correctness

To test the API functional correctness of 10-bit camera output, run the following CTS, camera ITS, and VTS tests:

Compare native camera and third-party app

We strongly recommend ensuring that the results of capturing 10-bit videos with a third-party app are similar, if not identical, to the native camera app. This means that tuning choices, such as exposure, dynamic range, and color, should carry forward from the native app to third-party apps. To verify the video recording behavior of a third-party app supporting 10-bit camera output on your device, use the Camera2Video sample app on GitHub. The following guidance serves to illustrate the visible aspects of HDR without objective numbers, due to the variability of sensors, panels, viewing conditions, and vendor preferences.

Suggested scenes for comparison

To make a comparison between the native camera app and a third-party app, capture videos using several different scenes with both the native camera app and the Camera2Video sample app. The following are suggested scenes to use for comparison:

  • 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.
  • 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.
  • 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.

For all scenes, we recommend having people and faces to verify exposure, color, and skin tone handling. Reducing shot-to-shot variation eases back-to-back comparisons.

Compare standard dynamic range and high dynamic range

To ensure that there's a perceived benefit of using a 10-bit dynamic range profile over a standard dynamic range profile, compare video captures using SDR (no HDR profile) against HDR videos to confirm that key aspects of HDR appear in the captures. To compare SDR and HDR, use the Camera2Video sample app and suggested scenes for comparing the native camera app and third-party apps.

The following are key aspects to verify in the suggested scenes. Display panels capable of HDR vary in brightness levels (measured in nits or lumens), so the following numbers given are meant to be examples:

  • 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.
  • 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.
  • 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.