2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
10비트 카메라 출력
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Android 13 이상을 실행하는 기기의 경우 Android는 다이내믹 레인지 프로필을 통해 10비트 카메라 출력을 지원합니다. 다이내믹 레인지 프로필은 스트림 구성 과정에서 카메라 클라이언트를 통해 구성할 수 있습니다. 기기 제조업체는 HLG10, HDR 10, HDR 10 이상, Dolby Vision과 같은 10비트 다이내믹 레인지 프로필에 대한 지원을 추가할 수 있습니다.
10비트 카메라 출력이 지원되면 카메라 클라이언트가 getSupportedProfiles를 호출하여 기기에 지원되는 10비트 다이내믹 레인지 프로필을 검색할 수 있습니다.
그러면 프레임워크에서 지원되는 다이내믹 레인지 프로필 및 캡처 요청 제약 조건(있는 경우) 관련 정보가 포함된 DynamicRangeProfiles 인스턴스를 반환합니다. HLG10 프로필이 지원되어야 합니다. 권장되는 다이내믹 레인지 프로필은 REQUEST_RECOMMENDED_TEN_BIT_DYNAMIC_RANGE_PROFILE 필드에 나열되어 있습니다.
카메라 클라이언트는 setDynamicRangeProfile을 호출하여 스트림 조합을 구성할 수 있습니다.
필수 출력 스트림 조합에 관한 자세한 내용은 일반 캡처의 10비트 출력 추가 보장 구성 표를 참고하세요.
요건
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비트 카메라 출력 구현을 검사하고 서드 파티 앱에서 이 기능을 사용 설정할 수 있도록 하려면 다음과 같은 세 가지 검증 단계를 수행하는 것이 좋습니다.
10비트 카메라 출력의 시각적 검증 과정에서는 기기가 HDR(1,000nit 이상의 디스플레이)을 지원하고 동영상 보기 앱(예: Google 포토)이 HDR 동영상 재생을 지원한다고 가정합니다.
API 기능 정확성 테스트
10비트 카메라 출력의 API 기능 정확성을 테스트하려면 다음 CTS, 카메라 ITS, VTS 테스트를 실행합니다.
네이티브 카메라와 서드 파티 앱 비교
서드 파티 앱을 사용하여 10비트 동영상을 캡처한 결과가 네이티브 카메라 앱과 똑같지는 않더라도 유사한지 확인하는 것이 좋습니다. 즉, 노출, 다이내믹 레인지, 색상과 같은 미세 조정 옵션이 네이티브 앱에서 서드 파티 앱으로 전달되어야 합니다. 기기에서 10비트 카메라 출력을 지원하는 서드 파티 앱의 동영상 녹화 동작을 확인하려면 GitHub의 Camera2Video 샘플 앱을 사용합니다. 다음 안내는 센서, 패널, 시청 조건 및 공급업체 환경설정의 가변성으로 인해 목표 수치를 제시하지 않고 HDR의 시각적 측면을 설명합니다.
비교용으로 추천되는 장면
네이티브 카메라 앱과 서드 파티 앱을 비교하려면 네이티브 카메라 앱과 Camera2Video 샘플 앱을 모두 사용하여 여러 장면의 동영상을 캡처합니다. 다음은 비교용으로 추천되는 장면입니다.
- 소형의 밝은 등이나 초와 같이 중요한 밝기 범위를 만드는 밝은 물체가 있고 밝기는 중간에서 낮은 수준의 장면. 자동 노출 동작과 다이내믹 레인지가 확인됩니다.
- 자동차의 크롬 범퍼와 같이 밝은톤을 만드는, 강렬한 색상과 반사 물체가 있는 밝은 야외 장면. 밝은톤이 훨씬 더 밝은 장면의 렌더링이 확인됩니다.
- 집 또는 사무실의 자연스러운 실내 장면과 같은 중간 범위의 낮은 다이내믹 레인지 장면. 비교적 극단적이지 않은 채광 조건이 예상대로 작동하는지 확인할 수 있습니다.
노출과 색상, 피부색 처리를 확인하기 위해 모든 장면에 사람과 얼굴이 들어가는 것이 좋습니다. 장면 간의 변화를 줄이면 연속 비교가 쉬워집니다.
표준 다이내믹 레인지와 HDR(High Dynamic Range) 비교
표준 다이내믹 레인지 프로필보다 10비트 다이내믹 레인지 프로필을 사용할 때 인식되는 이점을 확인하려면 SDR(HDR 프로필 아님)을 사용한 동영상 캡처와 HDR 동영상을 비교하여 캡처에 HDR의 핵심 측면이 표시되는지 확인합니다. SDR과 HDR을 비교하려면 Camera2Video 샘플 앱과 추천 장면을 사용하여 네이티브 카메라 앱과 서드 파티 앱을 비교합니다.
다음은 추천 장면에서 확인해야 할 주요 측면입니다. HDR을 지원하는 디스플레이 패널은 밝기 수준(nit 또는 lumen으로 측정됨)이 다양하므로 아래 제시된 숫자는 예시로 참고만 하세요.
- 밝기가 중간에서 어두운 장면의 경우 촛불이나 소형 조명의 밝은톤은 HDR 클립에서는 디스플레이의 최대 밝기(가능하면 최대 1,000nit)로 렌더링되고, SDR 클립에서는 SDR의 최대 밝기(약 100nit)로 렌더링됩니다. HDR 클립에서는 밝은톤이 디스플레이에서 두드러지게 빛나기 때문에 사용자가 인식하는 장면의 실제 다이내믹 레인지를 포착할 수 있습니다. SDR 클립은 HDR 클립과 비교할 때 더 평면적이고 어둡게 보입니다.
- 밝은 출력 장면에서는 기기의 미세 조정에 따라 HDR 클립이 SDR 클립과 비교하여 화면 밝기에서 확실히 차이가 납니다. HDR 클립의 경우 전체 장면의 화면 밝기(헤드룸에 따라 다름)가 예를 들어 최대 800nit까지 더 밝아야 하며 크롬 범퍼와 같은 밝은톤의 경우 최대 밝기에 맞게 그보다 훨씬 더 밝아야 합니다.
- 중간 범위의 낮은 다이내믹 레인지 실내 캡처에서는 HDR 클립과 SDR 클립은 색상과 색조가 유사하고 HDR 캡처가 SDR보다 더 밝을 수 있습니다. HDR은 SDR보다 어두워서는 안 됩니다. 미세 조정 옵션으로 이렇게 하는 게 불가능한 경우 서드 파티 앱 동작이 네이티브 카메라 앱 동작과 일치하는지 확인합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-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-07-26(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."]]
