ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release
แทน aosp-main
เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
เอาต์พุตกล้อง 10 บิต
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
สำหรับอุปกรณ์ที่ใช้ Android 13 ขึ้นไป Android จะรองรับเอาต์พุตกล้อง 10 บิตผ่านโปรไฟล์ช่วงไดนามิกที่ไคลเอ็นต์กล้องสามารถกําหนดค่าได้เป็นส่วนหนึ่งของการกำหนดค่าสตรีม ผู้ผลิตอุปกรณ์สามารถเพิ่มการรองรับโปรไฟล์ช่วงไดนามิก 10 บิต เช่น HLG10, HDR 10, HDR 10+ และ Dolby Vision
การรองรับเอาต์พุตกล้อง 10 บิตช่วยให้ไคลเอ็นต์กล้องค้นพบโปรไฟล์ช่วงไดนามิก 10 บิตที่รองรับของอุปกรณ์โดยการเรียกใช้ getSupportedProfiles
จากนั้นเฟรมเวิร์กจะแสดงอินสแตนซ์ของ 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 ที่ประมวลผลแล้วก่อนแจ้งบริการกล้อง โดยขึ้นอยู่กับโปรไฟล์ช่วงไดนามิก
ดูรายละเอียดเพิ่มเติมเกี่ยวกับเอาต์พุตกล้อง 10 บิตใน HAL ของกล้องได้ที่หัวข้อต่อไปนี้ใน metadata_definitions.xml
ดูการใช้งาน Camera HAL อ้างอิงที่รองรับเอาต์พุตกล้อง 10 บิตได้ที่
/hardware/google/camera/devices/EmulatedCamera/hwl
การตรวจสอบความถูกต้อง
หากต้องการตรวจสอบการติดตั้งใช้งานเอาต์พุตกล้อง 10 บิตและตรวจสอบว่าแอปของบุคคลที่สามเปิดใช้ฟีเจอร์นี้ได้ เราขอแนะนำให้ทำการตรวจสอบ 3 ระยะต่อไปนี้
สำหรับการยืนยันภาพเอาต์พุตของกล้อง 10 บิต ระบบจะถือว่าอุปกรณ์รองรับการแสดงผล HDR (จอแสดงผลที่ความสว่างมากกว่า 1,000 นิต) และแอปดูวิดีโอ (เช่น Google Photos) รองรับการเล่นวิดีโอ HDR
ทดสอบความถูกต้องของฟังก์ชันการทํางานของ API
หากต้องการทดสอบความถูกต้องของฟังก์ชัน API สำหรับเอาต์พุตกล้อง 10 บิต ให้ทำการทดสอบ CTS, ITS ของกล้อง และ VTS ต่อไปนี้
เปรียบเทียบกล้องในตัวกับแอปของบุคคลที่สาม
เราขอแนะนำอย่างยิ่งว่าผลลัพธ์ของการจับภาพวิดีโอ 10 บิตด้วยแอปของบุคคลที่สามควรคล้ายกับแอปกล้องในตัว หากไม่เหมือนกันทั้งหมด ซึ่งหมายความว่าตัวเลือกการปรับแต่ง เช่น การเปิดรับแสง ช่วงไดนามิก และสี ควรใช้กับแอปของบุคคลที่สามได้ หากต้องการยืนยันลักษณะการบันทึกวิดีโอของแอปของบุคคลที่สามที่รองรับเอาต์พุตกล้อง 10 บิตในอุปกรณ์ ให้ใช้แอปตัวอย่าง Camera2Video ใน GitHub คำแนะนำต่อไปนี้มีไว้เพื่อแสดงภาพด้านที่มองเห็นได้ของ HDR โดยไม่มีตัวเลขที่เป็นกลาง เนื่องจากเซ็นเซอร์ แผง สภาพการรับชม และความต้องการของผู้ให้บริการมีความแตกต่างกัน
ฉากที่แนะนำสำหรับการเปรียบเทียบ
หากต้องการเปรียบเทียบระหว่างแอปกล้องในตัวกับแอปของบุคคลที่สาม ให้บันทึกวิดีโอโดยใช้ฉากต่างๆ หลายฉากด้วยทั้งแอปกล้องในตัวและแอปตัวอย่าง Camera2Video ฉากที่แนะนําให้ใช้เปรียบเทียบมีดังนี้
- ฉากที่มีแสงปานกลางถึงแสงน้อยซึ่งมีวัตถุสว่าง เช่น เทียนหรือแสงสว่างเล็กๆ ที่สว่าง ซึ่งสร้างช่วงความสว่างที่กว้าง ซึ่งจะยืนยันลักษณะการทํางานของการเปิดรับแสงอัตโนมัติและช่วงไดนามิก
- ฉากกลางแจ้งที่สว่างซึ่งมีสีสันสดใสและวัตถุสะท้อนแสง เช่น กันชนโครเมียมของรถยนต์ ซึ่งทำให้เกิดจุดไฮไลต์ที่สว่าง ซึ่งจะยืนยันการแสดงผลสำหรับฉากที่สว่างโดยมีไฮไลต์ที่สว่างยิ่งขึ้น
- ฉากช่วงกลางที่มีช่วงไดนามิกต่ำ เช่น ฉากในอาคารที่เป็นธรรมชาติในบ้านหรือที่ทำงาน ซึ่งยืนยันว่าสภาพแสงที่ไม่รุนแรงมากจะทำงานตามที่คาดไว้
สำหรับฉากทั้งหมด เราขอแนะนำให้มีผู้คนและใบหน้าเพื่อยืนยันการจัดการการเปิดรับแสง สี และโทนสีผิว การลดความแตกต่างของช็อตแต่ละช็อตช่วยให้เปรียบเทียบช็อตต่อช็อตได้ง่ายขึ้น
เปรียบเทียบช่วงไดนามิกมาตรฐานกับช่วงไดนามิกสูง
เปรียบเทียบวิดีโอที่บันทึกโดยใช้ SDR (ไม่มีโปรไฟล์ HDR) กับวิดีโอ HDR เพื่อให้แน่ใจว่าผู้ชมจะได้รับประโยชน์จากการใช้โปรไฟล์ช่วงไดนามิก 10 บิตมากกว่าโปรไฟล์ช่วงไดนามิกมาตรฐาน หากต้องการเปรียบเทียบ SDR กับ HDR ให้ใช้แอปตัวอย่าง Camera2Video และฉากที่แนะนำเพื่อเปรียบเทียบแอปกล้องในตัวกับแอปของบุคคลที่สาม
ต่อไปนี้คือแง่มุมสำคัญที่ต้องยืนยันในฉากที่แนะนำ แผงจอแสดงผลที่รองรับ HDR มีความสว่างแตกต่างกันไป (วัดเป็นนิตหรือลูเมน) ดังนั้นตัวเลขต่อไปนี้เป็นเพียงตัวอย่าง
- ในฉากที่มีแสงปานกลางถึงแสงน้อย ระบบจะแสดงผลไฮไลต์ที่สว่างของเทียนหรือแสงขนาดเล็กที่ความสว่างสูงสุดสำหรับจอแสดงผล (อาจสูงถึง 1,000 นิต) ในคลิป HDR และแสดงผลที่ความสว่างสูงสุดสำหรับ SDR (ประมาณ 100 นิต) ในคลิป SDR ในคลิป HDR ไฮไลต์ที่สว่างควรโดดเด่นบนจอแสดงผล ซึ่งจะสื่อถึงสิ่งที่ผู้ใช้รับรู้เกี่ยวกับช่วงไดนามิกจริงของฉาก เมื่อเทียบกับคลิป HDR คลิป SDR ควรปรากฏว่าดูจืดชืดและสว่างน้อยกว่า
- ในฉากเอาต์พุตที่สว่าง คลิป HDR จะแสดงความสว่างของหน้าจอที่แตกต่างอย่างชัดเจนเมื่อเทียบกับคลิป SDR ทั้งนี้ขึ้นอยู่กับการปรับแต่งของอุปกรณ์ สำหรับคลิป HDR ความสว่างของหน้าจอสำหรับฉากโดยรวม (ขึ้นอยู่กับ Headroom) ควรสูงกว่า เช่น สูงสุด 800 นิต และยิ่งกว่านั้นสำหรับไฮไลต์ที่สว่าง เช่น กันชนโครเมียม ควรมีความสว่างสูงสุด
- ในการจับภาพในอาคารที่มีช่วงไดนามิกต่ำระดับกลาง คลิป HDR และ SDR จะมีสีและโทนคล้ายกัน โดยคลิป HDR อาจสว่างกว่า SDR HDR ต้องไม่มืดกว่า SDR หากการปรับแต่งตัวเลือกทำให้การดำเนินการนี้ไม่สามารถทำได้ ให้ตรวจสอบว่าลักษณะการทํางานของแอปของบุคคลที่สามตรงกับลักษณะการทํางานของแอปกล้องที่มาพร้อมเครื่อง
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ 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."]]