自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
Android 中的 HDR 屏幕截图
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
自从高动态范围 (HDR) 视频推出以来,在线媒体服务已开始支持在线播放 HDR 视频,并专注于全屏体验。最近,社交媒体应用已开始支持 HDR 视频和 Ultra HDR,这表明用户对在各种应用中采用 HDR 越来越感兴趣。
Android 对 HDR 的支持
以下是 Android 多年的 HDR 技术支持里程碑:
Android 7
- 初步支持 HDR 视频解码和显示。
- 持续改进 HDR 功能。
Android 13
Android 14
多年来,HDR 屏幕截图支持也在不断发展,并经历了许多变化。
HDR 屏幕截图功能的改进
本部分记录了近期 Android 更新中对 HDR 屏幕截图功能进行的改进。
Android 9
Android 的图形合成器 SurfaceFlinger 引入了对 HDR 视频的支持。借助复杂的多项式色调映射器,支持对 HDR 视频和屏幕截图进行 GPU 渲染。此色调映射曲线并不总是等同于显示屏色调映射器,因此屏幕截图与屏幕上的内容会有所不同。
Android 13
为 SurfaceFlinger 的 GPU 渲染块添加了一个色调映射插件,以便 OEM 提供 GPU 着色器来匹配其显示屏的色调映射曲线。屏幕截图几乎与屏幕上显示的内容一致,但存在以下差异:
- 屏幕截图仍会采用 SDR 格式。因此,当与 HDR 场景一起显示时,屏幕截图中的 HDR 区域会显得更暗。
- 未对 SDR 亮度进行管理,这导致屏幕截图中的 SDR 内容看起来与 HDR 内容的亮度相同。
换言之,在屏幕截图中捕获的任何 HDR 视频都会转换为 SDR 视频。
Android 14
Ultra HDR 给屏幕截图带来了重大挑战。与视频不同,图片通常在界面帧缓冲内渲染,这有两个主要影响:
- 图片处理(包括色调映射)不能不同于图片周围的界面。
- 应用在渲染其界面时负责基于源的色调映射。
为了应对这一挑战,目前推出了三种可能的屏幕截图实现方式:
- 保留 Ultra HDR 图片的 HDR 细节,这会导致屏幕截图中的应用界面变暗。
- 保留应用界面细节,这会导致 Ultra HDR 图片被裁剪。
- 在裁剪 HDR 高光的同时,通过调亮应用界面进行折中。
Android 14 实现了第三种方法,即调亮应用界面并剪裁 HDR 高光。
Android 15-QPR1
SurfaceFlinger 包含针对屏幕截图的本地色调映射算法。此过程包括:
- 将输入图片分割成多个较小的图片。
- 计算每张图像中的最大亮度,并舍弃每个部分中的低亮度值。
- 通过模糊处理和重新采样对计算出的亮度进行插值处理。
- 根据插值处理后的亮度值,将参数化 Reinhard 色调映射器应用于输入图片。
此算法能够在 Android 14 和 Android 15-QPR1 之间实现显著的屏幕截图改进,如下例所示:
示例 1 是 Chrome 网页前面叠加的包含 Ultra HDR 的 HDR 视频的屏幕截图。界面颜色在新实现中基本保留,并且图片不再被裁剪。
Android 14 |
Android 15-QPR1 |
|
|
图 1. 示例 1 中 Android 14 与 Android 15-QPR1 之比较。
示例 2 是设置前面叠加的 HDR 视频的屏幕截图,以及后续屏幕截图。在 Android 14 中,屏幕截图颜色会逐渐变暗。在 Android 15-QPR1 中,色调映射器会正确复制和保留界面颜色。
Android 14 |
Android 15-QPR1 |
|
|
图 2. 示例 2 中 Android 14 与 Android 15-QPR1 之比较。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-10。
[null,null,["最后更新时间 (UTC):2025-03-10。"],[],[],null,["# HDR in Android screenshots\n\nSince the introduction of high dynamic range (HDR) video, streaming services\nhave started streaming HDR video, focusing on full-screen\nexperiences. Recently, social media apps\nhave launched support for HDR video and Ultra HDR,\nindicating growing interest in HDR adoption across various apps.\n\nAndroid support for HDR\n-----------------------\n\nThe following are the milestones of Android's support for HDR technology over\nseveral years:\n\n### Android 7\n\n- Initial support for HDR video decoding and display.\n- Continued advancements in HDR capabilities.\n\n### Android 13\n\n- End-to-end support for HDR video capture, encoding, and display.\n- Introduction of [Mixed SDR and HDR composition](/docs/core/display/mixed-sdr-hdr), defining different displayable luminance ranges between SDR and HDR.\n\n### Android 14\n\n- Support for HDR images with [Ultra HDR](https://developer.android.com/media/grow/ultra-hdr).\n\nScreenshot support with HDR has also evolved and undergone a number of changes\nover the years.\n\nAdvancements in HDR screenshot capabilities\n-------------------------------------------\n\nThis section tracks the progression of HDR screenshot capability in recent\nAndroid updates.\n\n### Android 9\n\nSurfaceFlinger, Android's graphics compositor, introduces HDR video support. GPU\nrendering of HDR video and screenshots is supported with a complex polynomial\ntone mapper. This tone-mapping curve isn't always equivalent to the display\ntone-mapper, so screenshots differ from the on-screen content.\n\n### Android 13\n\nA [tone mapping](/docs/core/display/tone-mapping) plugin is added to the\nSurfaceFlinger's GPU rendering block, enabling the OEM to provide a GPU shader\nto match their display's tone-mapping curve. Screenshots almost match what is on\nscreen, but with the following differences:\n\n- Screenshots remain in SDR format. Consequently, when viewed alongside an HDR scene, the HDR regions within the screenshot appear dimmer.\n- SDR luminance isn't managed, resulting in SDR content within the screenshot appearing as bright as HDR content.\n\nIn other words, any HDR video captured in the screenshot is converted to SDR\nvideo.\n\n### Android 14\n\nUltra HDR poses a significant challenge to screenshotting. Unlike videos, images\nare typically rendered within the UI framebuffer, which has two main\nimplications:\n\n- Images can't have image processing, including tonemapping, that differs from the surrounding UI.\n- Apps are responsible for source-based tone mapping when rendering their UI.\n\nTo alleviate this challenge, there are three potential screenshotting\nimplementations:\n\n- Preserve the HDR details of an Ultra HDR image, resulting in a darkened app UI in the screenshot.\n- Preserve the app UI details, causing Ultra HDR image clipping.\n- Compromise by brightening the app UI while clipping HDR highlights.\n\nAndroid 14 implements the third approach of brightening the app UI and clipping\nHDR highlights.\n\n### Android 15-QPR1\n\nSurfaceFlinger includes a local tone-mapping algorithm for screenshots. This\nprocess involves:\n\n- Dividing the input image into smaller images.\n- Computing the maximum luminance in each image, and discarding low luminance values within each section.\n- Interpolating the computed luminances through blurring and resampling.\n- Applying a parameterized Reinhard tonemapper to the input image, based on the interpolated luminance values.\n\nThis algorithm shows significant screenshot improvements between Android 14 and\nAndroid 15-QPR1, as shown in the following examples:\n\n- Example 1 is a screenshot of an HDR video overlaid on top of a Chrome\n page containing Ultra HDR. The UI colors are mostly preserved in the new\n implementation, and the image is no longer clipped.\n\n | Android 14 | Android 15-QPR1 |\n |------------|-----------------|\n | | |\n\n **Figure 1.** Comparison of Android 14 and Android 15-QPR1 for Example 1.\n- Example 2 is a screenshot of an HDR video overlaid on top of **Settings**\n with subsequent screenshots. In Android 14, the screenshot colors are\n successively darker. In Android 15-QPR1, the tonemapper correctly replicates and\n preserves the UI colors.\n\n | Android 14 | Android 15-QPR1 |\n |------------|-----------------|\n | | |\n\n **Figure 2.** Comparison of Android 14 and Android 15-QPR1 for Example 2.\n\n### Android 16\n\nSimilar to [Ultra HDR](https://developer.android.com/media/platform/hdr-image-format),\nHDR screenshots store a gainmap in the screenshot file to recover the HDR\nrepresentation during rendering. However, unlike Ultra HDR, the screenshot\nremains in a PNG format for backward compatibility with systems that ingest\nPNG screenshots.\n\nThe screenshot generation details are as follows:\n\n- When HDR content is displayed on the device, a screenshot is generated using FP16 pixels.\n- The local tone-mapper described in [Android 15-QPR1](/docs/core/graphics/hdr-screenshots#android15qpr-hdr-shot) generates an 8-bit base SDR rendition.\n- An 8-bit gainmap is produced by combining the SDR base rendition with the HDR rendition.\n- The SDR base rendition and the gainmap are encoded into a single PNG file.\n\nThe PNG encoding details are as follows:\n\n- The gainmap is encoded as a PNG image, which includes a gmAP chunk, containing the [ISO 21496-1](https://www.iso.org/standard/86775.html) metadata for the gainmap.\n- The SDR base rendition is encoded as a PNG image, which includes a gmAP chunk, containing the version of the [ISO 21496-1](https://www.iso.org/standard/86775.html) metadata. This PNG image also includes a gdAT chunk, containing the entirety of the encoded gainmap PNG.\n\nThe following figure shows the layout of the PNG chunks:\n\n**Figure 3.** Layout of the PNG chunks.\n\nWith Android 16, the PNG codec supports both encoding\nand decoding of these PNGs. Apps can display a PNG with a gainmap in the same\nmanner as [Ultra HDR](https://developer.android.com/media/grow/ultra-hdr/display)."]]