自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
10 位元相機輸出內容
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
對於搭載 Android 13 以上版本的裝置,Android 會透過動態範圍設定檔支援 10 位元相機輸出,相機用戶端可在串流設定中設定這些設定檔。裝置製造商可以新增支援 10 位元動態範圍設定檔,例如 HLG10、HDR 10、HDR 10+ 和 Dolby Vision。
10 位元相機輸出支援功能可讓相機用戶端透過呼叫 getSupportedProfiles
,找出裝置支援的 10 位元動態範圍設定檔。接著,架構會傳回 DynamicRangeProfiles
的例項,其中包含支援的動態範圍設定檔資訊,以及 (如有) 擷取要求限制。必須支援 HLG10
設定檔。建議的動態範圍設定檔會列於 REQUEST_RECOMMENDED_TEN_BIT_DYNAMIC_RANGE_PROFILE
欄位中。
攝影機用戶端可以呼叫 setDynamicRangeProfile
來設定串流組合。如要進一步瞭解強制輸出串流組合,請參閱「一般擷取」中的「10 位元輸出額外保證設定」表格。
需求條件
如要支援 10 位元相機輸出,裝置必須具備 10 位元或更高級別的相機感應器,並支援相應的 ISP。如要進一步瞭解 10 位元支援功能的相關相容性規定,請參閱第 7.5 節。CDD 中的攝影機。
實作
如要支援 10 位元相機輸出,裝置製造商必須執行下列 Camera AIDL HAL 整合作業:
- 在相機功能中加入
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_DYNAMIC_RANGE_TEN_BIT
。
- 將所有支援的動態範圍設定檔和限制的點陣圖填入
ANDROID_REQUEST_AVAILABLE_DYNAMIC_RANGE_PROFILES_MAP
。必須支援 HLG10
設定檔。您也必須加入建議的動態範圍設定檔,告知相機用戶端最佳的支援格式。
- 確保在使用 P010 格式的串流中,串流設定期間支援動態範圍設定檔值,或支援實作定義的格式 (
ImageFormat.PRIVATE
)。
- 根據動態範圍設定檔,在通知攝影機服務前,先設定已處理 Gralloc 4 緩衝區的靜態或動態中繼資料緩衝區。
如要進一步瞭解 Camera HAL 中的 10 位元相機輸出內容,請參閱 metadata_definitions.xml
中的以下內容:
如需支援 10 位元相機輸出的參考相機 HAL 實作方式,請參閱 /hardware/google/camera/devices/EmulatedCamera/hwl
。
驗證
如要驗證 10 位元相機輸出的實作方式,並確保第三方應用程式可啟用這項功能,建議您執行下列三個驗證階段。
如要視覺驗證 10 位元相機輸出內容,系統會假設裝置支援 HDR 顯示 (1000 nits 以上的顯示器),且影片觀看應用程式 (例如 Google 相簿) 支援 HDR 影片播放功能。
測試 API 功能正確性
如要測試 10 位元相機輸出的 API 功能正確性,請執行下列 CTS、相機 ITS 和 VTS 測試:
比較原生相機和第三方應用程式
強烈建議您確保使用第三方應用程式拍攝 10 位元影片的結果與原生相機應用程式相似 (如果不是完全相同的話)。也就是說,曝光、動態範圍和色彩等調整選項應從原生應用程式沿用至第三方應用程式。如要驗證第三方應用程式在裝置上支援 10 位元相機輸出的錄影行為,請使用 GitHub 上的 Camera2Video 範例應用程式。由於感應器、面板、觀看條件和供應商偏好設定會有所不同,因此下列指南僅說明 HDR 的明顯特徵,不提供客觀數字。
建議的比較場景
如要比較原生相機應用程式和第三方應用程式,請使用原生相機應用程式和 Camera2Video 範例應用程式,拍攝多個不同場景的影片。以下是建議用於比較的場景:
- 中度至低光的場景,其中有明亮的物體,例如蠟燭或小型亮光燈,可產生較大的亮度範圍。這麼做可確認自動曝光行為和動態範圍。
- 明亮的戶外場景,含有鮮豔色彩和反光物件,例如車上的鍍鉻保險桿,可產生明亮的亮點。這可確認明亮場景的算繪效果,以及更亮的亮部。
- 中等低動態範圍場景,例如住家或辦公室內的自然室內場景。這可證實在光線較不極端的情況下,系統的運作情況是否如預期。
對於所有場景,我們建議您使用人物和臉孔來驗證曝光、色彩和膚色處理方式。減少鏡頭之間的差異,有助於進行背對背比較。
比較標準動態範圍和高動態範圍
為確保使用 10 位元動態範圍設定檔比使用標準動態範圍設定檔更有益,請比較使用 SDR (沒有 HDR 設定檔) 和 HDR 的影片擷取畫面,確認 HDR 的關鍵元素是否出現在擷取畫面中。如要比較 SDR 和 HDR,請使用 Camera2Video 範例應用程式和建議的場景,比較原生相機應用程式和第三方應用程式。
以下是建議場景中需要驗證的重點。支援 HDR 的螢幕面板亮度等級會有所不同 (以 nit 或流明度為單位),因此以下數字僅供參考:
- 在中度光源到低光源場景中,燭光或小光源的亮部會以 HDR 剪輯片段中的螢幕最高亮度 (可能高達 1000 nit) 算繪,並以 SDR 剪輯片段中的SDR 最高亮度 (約 100 nit) 算繪。在 HDR 短片中,明亮的亮部應會從螢幕上閃爍,捕捉使用者對場景真實動態範圍的感知。相較於 HDR 短片,SDR 短片的色調應較平淡,亮度也較低。
- 在明亮的輸出場景中,HDR 短片的畫面亮度與 SDR 短片有明顯差異,這取決於裝置的調整方式。對於 HDR 短片,整體場景的螢幕亮度 (取決於預留空間) 應較高,例如最高可達 800 nit,而亮部 (例如鍍鉻保險桿) 的亮度則應更高,可達最大亮度。
- 在室內拍攝的 HDR 和 SDR 短片,色彩和色調相似,HDR 短片可能會比 SDR 短片更亮。HDR 不應比 SDR 更暗。如果調整選項無法做到這點,請確保第三方應用程式的行為與原生相機應用程式的行為一致。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-26 (世界標準時間)。
[[["容易理解","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 (世界標準時間)。"],[],[],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."]]