自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
Android 螢幕截圖中的 HDR
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
自從推出高動態範圍 (HDR) 影片後,串流服務就開始串流 HDR 影片,並著重於全螢幕體驗。近期,社群媒體應用程式已推出 HDR 影片和 Ultra HDR 支援功能,顯示各式應用程式對 HDR 採用率的興趣日益增加。
Android 支援 HDR
以下是 Android 多年來支援 HDR 技術的里程碑:
Android 7
- 初步支援 HDR 影片解碼和顯示功能。
- 持續改善 HDR 功能。
Android 13
Android 14
HDR 螢幕截圖支援功能也不斷演進,並在多年後經歷了許多變化。
HDR 螢幕截圖功能的進展
本節將追蹤 HDR 螢幕截圖功能在近期 Android 更新中的進展。
Android 9
Android 的圖形合成器 SurfaceFlinger 推出 HDR 影片支援功能。複雜的多項式色調對應器支援 GPU 算繪 HDR 影片和螢幕截圖。這個色調對應曲線不一定等同於顯示器色調對應器,因此螢幕截圖與螢幕上的內容會有所差異。
Android 13
色調對應外掛程式已新增至 SurfaceFlinger 的 GPU 轉譯區塊,讓原始設備製造商 (OEM) 提供 GPU 著色器,以符合其螢幕的色調對應曲線。螢幕截圖幾乎與畫面上的內容相符,但有以下差異:
- 螢幕截圖仍會以 SDR 格式顯示。因此,當 HDR 場景與螢幕截圖一同顯示時,螢幕截圖中的 HDR 區域會顯得較暗。
- 未管理 SDR 亮度,導致螢幕截圖中的 SDR 內容看起來與 HDR 內容一樣亮。
換句話說,任何在螢幕截圖中擷取的 HDR 影片都會轉換為 SDR 影片。
Android 14
要擷取 Ultra HDR 畫面相當困難,與影片不同,圖片通常會在 UI Framebuffer 中轉譯,這有兩個主要意涵:
- 圖片不得進行圖片處理作業 (包括色調對應),以免與周圍 UI 不同。
- 應用程式在轉譯 UI 時,必須負責執行以來源為準的色調對應作業。
為瞭解決這個問題,有三種可能的螢幕截圖實作方式:
- 保留 Ultra HDR 圖片的 HDR 細節,導致螢幕截圖中的應用程式 UI 變暗。
- 保留應用程式 UI 詳細資料,導致 Ultra HDR 圖片裁剪。
- 在 HDR 高光部分裁剪的同時,提高應用程式 UI 的亮度。
Android 14 實作第三種方法,即將應用程式 UI 調亮,並裁剪 HDR 亮點。
Android 15-QPR1
SurfaceFlinger 包含螢幕截圖的本機色調對應演算法。這項程序包括:
- 將輸入圖片分割成較小的圖片。
- 計算每張圖片的最大亮度,並捨棄各個區段中的低亮度值。
- 透過模糊處理和重新取樣,對計算的亮度進行內插。
- 根據內插的亮度值,將參數化 Reinhard 色調轉換器套用至輸入圖片。
這個演算法顯示 Android 14 和 Android 15-QPR1 之間的螢幕截圖有顯著改善,如下列範例所示:
範例 1 是 HDR 影片的螢幕截圖,疊加在含有 Ultra HDR 的 Chrome 頁面上。在新的實作方式中,UI 顏色幾乎都會保留,且圖片不會再遭到裁剪。
Android 14 |
Android 15-QPR1 |
|
|
圖 1. 範例 1 的 Android 14 和 Android 15-QPR1 比較。
範例 2 是 HDR 影片疊加在「設定」畫面上的螢幕截圖,後續的螢幕截圖也是如此。在 Android 14 中,螢幕截圖的顏色會逐漸變暗。在 Android 15-QPR1 中,tonemapper 會正確複製及保留 UI 顏色。
Android 14 |
Android 15-QPR1 |
|
|
圖 2. 範例 2 中 Android 14 和 Android 15-QPR1 的比較。
Android 16
與 Ultra HDR 類似,HDR 螢幕截圖會在螢幕截圖檔案中儲存增益圖,以便在算繪期間復原 HDR 表示法。不過,與 Ultra HDR 不同的是,螢幕截圖仍會以 PNG 格式儲存,以便與攝入 PNG 螢幕截圖的系統相容。
螢幕截圖產生詳細資料如下:
- 當 HDR 內容顯示在裝置上時,系統會使用 FP16 像素產生螢幕截圖。
- Android 15-QPR1 中所述的本機色調轉換器會產生 8 位元基本 SDR 轉譯。
- 將 SDR 基本轉譯結果與 HDR 轉譯結果結合,即可產生 8 位元增益圖。
- SDR 基本轉譯和增益圖會編碼為單一 PNG 檔案。
PNG 編碼詳細資料如下:
- 增益圖會編碼為 PNG 圖片,其中包含 gmAP 區塊,內含增益圖的 ISO 21496-1 中繼資料。
- SDR 基礎呈現會編碼為 PNG 圖片,其中包含 gmAP 區塊,其中包含 ISO 21496-1 中繼資料的版本。這個 PNG 圖片也包含 gdAT 區塊,其中包含已編碼的增益圖 PNG 的完整內容。
下圖顯示 PNG 區塊的版面配置:
圖 3. PNG 區塊的版面配置。
在 Android 16 中,PNG 編解碼器支援這些 PNG 的編碼和解碼。應用程式可以以與 Ultra HDR 相同的方式,顯示含有增益圖的 PNG。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[[["容易理解","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-27 (世界標準時間)。"],[],[],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)."]]