随着现代智能手机普遍开始支持 HDR 照片的拍摄和 Lightroom 等专业摄影软件开始支持 HDR 工作流，HDR 图片的生产正在变得越来越方便，也越来越常见。甚至，通过合适的工作流，我们可以将旧介质的照片（如胶片）重新数字化为 HDR 图片。对于从一开始就无法 HDR 化的早期数字图片，我们现在也可以通过 AI 重建其 HDR 信息。
数字化为 HDR 的胶片照片。如果你的设备和浏览器支持 HDR，请注意比 SDR 白色更亮的云彩细节。
与此同时，网页中的 HDR 显示正在变得逐渐可用，在网页中广泛使用 HDR 的时机已经成熟。这篇文章简要总结了我在近期项目的 HDR 支持开发中碰到的问题和要点。请注意，这篇文章中含有许多 HDR 媒体，包括一些用于测试的、包含极端亮度的图片和文字。建议不要在昏暗的环境下阅读本文。
本文写作于 2025 年 7 月。由于 HDR 相关规范的快速发展和变化，本文中的内容在你阅读时可能已经过时，请务必自行检查。
在开始之前，你需要确定你的设备和浏览器组合能否正确显示 HDR 内容。截至 2025 年 7 月，如果你正在使用 Firefox 或 Safari（除 Safari 26+ 外），你可能会看不到接下来的某些或全部 HDR 内容。不同浏览器的支持情况可能会有差异。
目前，还没有一个完全可靠的方法检查你的设备和浏览器组合是否支持 HDR 显示。不过，检查 (dynamic-range: high) 的媒体查询将可以覆盖绝大多数的情况。Safari 可能需要结合 screen.colorDepth 一起检查。
如果你搜索如何检查浏览器 HDR 支持的相关内容，你可能会看到诸如
(dynamic-range: high) and (color-gamut: p3)的媒体查询。这是错误的。(dynamic-range: high)和(color-gamut: p3)是两个不同的媒体查询，支持 HDR 的设备或浏览器不一定有 P3 色域（尽管它们通常一起出现），反之亦然。
你的浏览器在当前显示器上的检查结果：
(dynamic-range: high):(color-gamut: p3): （不影响 HDR）- 颜色深度: （在支持 HDR 时应大于 24）
接下来是一些真实情况测试。建议将页面切换到亮色模式。
如果你发现上方右侧图片左上角的高光区域明显比左侧图片亮，且比页面背景白色（漫射白色）更亮，那么你的浏览器可以正确显示包含增益图的 HDR JPEG 图片。
如果你在上方同时看到一个显著亮于漫射白色的白色方形区域和一个明显比漫射白色更亮的表情包，那么你的浏览器可以正确显示包含 Rec2020 PQ ICC 的 HDR 图片。请注意，iOS Safari 18 及以下版本的 HDR 图片支持很不稳定，会出现一部分图片正确显示 HDR 一部分变成 SDR 的情况（包括这个测试）。以上两张图片有完全一致的嵌入 ICC，应有一致的表现。
如果你在上方看到一些显著亮于漫射白色的文字和形状，那么你的浏览器可以显示 HDR 颜色。这项测试是非标准的，如果你在此测试中看不到任何 HDR 内容，这并不意味着你的设备和浏览器不能正确显示 HDR。
为啥要 HDR
如果你对摄影略有了解，你可能已经听说过另一个不同的 HDR 的概念。在摄影中，HDR 通常指的是高动态范围摄影，即使用多张曝光不同的照片，通过后期合成，来获得比普通照片更宽的动态范围。但在网页或其他数字媒体中，HDR 通常指的是高动态范围显示，即使用比 SDR 更宽的动态范围来显示内容。最直观的体现就是，HDR 媒体中的峰值亮度在屏幕上看起来通常比标准动态范围 SDR 中的最亮的白色更亮。为什么要 HDR？SDR 下的各种设计都被曾经的屏幕技术限制，而 HDR 可以充分发挥现代屏幕的能力。显然，它能让各类媒体，包括网页自己，在屏幕上看起来更好。甚至在浏览器中，这不只是 HDR 的事，而是色彩管理相关能力的拓展。
你可能听到过一个说法，前端没有色彩管理，只有 sRGB。这句话放在几年之前可能还是正确的，但随着 HDR 的内容越来越多，浏览器对 HDR 内容的支持变好，这句话已经不再正确了——现在我们确实能在现代浏览器中做一定程度的色彩管理了。等一下，你可能会问，这和 HDR 有什么关系？HDR 相对 SDR 最直观的体现就是亮度范围的拓展，当亮度被拓展后，我们无法再使用传统 sRGB 的 8 位/通道来表示颜色了，8 位下的 HDR 会出现严重的色彩断层（通常，即使有良好的曲线，HDR 内容也需要至少 10 位来避免颜色断层）；同时，2.2 的伽马曲线也不再适合 HDR，需要使用为 HDR 优化的色彩空间和曲线来表示颜色。我们需要对 CSS 和 JavaScript 进行严肃的色彩管理拓展。
如果你像我一样曾经分不清色域和色彩空间：简单来说，色域 (Gamut) 就是颜色可以被表示的范围，也就是通常你在色域图上看到的那些三角形。常见的色域有 sRGB、P3、Adobe RGB 等；而色彩空间 (Color space) 和色域不同，描述的是颜色被表示的方式，更像是一套坐标，或是一种编码颜色的方式。色彩空间通过定义原色坐标、白点等参数来定义如何描述一个颜色。P3 是色域，而 Display-P3 在 P3 下定义了 D65 白点，2.2 的伽马曲线等等，属于色彩空间。
于是，在 CSS Color 4 中，我们有了 color() 函数，可以让我们使用特定的色彩空间来描述颜色；还有了 oklch() 和 oklab() 等新的色彩空间，可以让我们使用更符合人类直觉的色彩空间来描述颜色…有了这些好东西，我们现在能在网页中随意使用 HDR 了吗？是，也不是。我们可以在网页中使用 HDR 图片和视频了，但同时我们还缺少很多东西，包括真正的 HDR 色彩空间、对 HDR 内容的管理能力和 canvas 的 HDR 支持等等。HDR 相关规范正在发展，这正是一个写文章介绍这个概念好时机。
HDR 图片
HDR 图片的生产流程不在本文的讨论范围内。如果你使用现代移动设备，很可能已经可以轻松拍摄、分享 HDR 图片。如果你使用 Lightroom 等专业摄影软件，则现在已经可以轻松导出 HDR 图片了。Adobe 有一篇很棒的文章介绍了如何使用 Lightroom HDR 工作流。遗憾的是，目前在消费级设备中还没有可靠的方法校准 HDR 显示器。
让我们从拿到 HDR 图片开始。要在网页中显示 HDR 图片，大概有两种办法：一是使用直接进行 HDR 色彩管理的图片（包括嵌入 HDR ICC Profile 和使用 nclx 色彩类型的 AVIF）；二是使用带有增益图的 HDR 图片。直接进行 HDR 色彩管理的图片很显然，甚至前段时间已经被广泛讨论了（嵌入了 HDR ICC 的表情包），但什么是带有增益图的 HDR 图片？
HDR = 底图 × 增益图
带有增益图的 HDR 图片本质上是一张正常的 SDR 图片加一张增益辅助图。在渲染时，支持增益图的软件会正常读取 SDR 底图，然后读取增益图来调整图片不同区域的亮度（和颜色）。对于不支持 HDR 的软件或设备，或在不理解增益图的软件中，增益图会被忽略，图片会优雅降级为 SDR。
这种方法和好处在于，内容创作者可以精确控制图片在 SDR 和 HDR 下的表现。而如果直接使用 HDR 图片，在 SDR 设备上，图片会被软件色调映射到 SDR，但这一过程是特定于平台的，创作者无法保证图片在 SDR 设备上能一致、正确地表现创作意图。不过，使用增益图的代价是相比 SDR 图片大小会增加大约 30%。
色调映射对比
从上面的例子可以看到，平台默认的色调映射算法通常无法取得最佳效果。当前版本的 Chrome (138) 中的色调映射算法在这个例子中的 HDR ICC 图片上会带来明显的暖色偏移，同时丢失对比度；而带有增益图的图片在色调映射后则更接近 HDR 原图的表现。HDR 到 SDR 的色调映射不是一件简单的事情，不同平台可能会有不同的表现，进而导致结果良莠不齐。带有底图和增益图的图片相当于带有标准答案，可以尽可能在所有平台和设备上都能取得一致的、符合创作者意图的表现。
目前，我们可以在 JPEG 或 AVIF 格式下嵌入 HDR 增益图。然而，尽管 JPEG 增益图格式支持良好， AVIF 增益图的浏览器支持度仍正在提高，要使用带有增益图的 AVIF 图片，你还需要等待一段时间。在目前，如果需要使用 HDR 图片，推荐使用带增益图的 JPEG 以获得最广泛的支持。
需要注意的是，尽管带增益图的 JPEG 图片本身是一张正确的 SDR JPEG 图片，但我们不能简单将其作为普通 JPEG 图片放入目前常见的图像处理工作流中，否则极容易丢失正确的 HDR 效果。例如，如果使用 Exiftool 清理图片的 Exif 信息：
$ exiftool -all= --icc_profile:all hdr.jpg
你会发现图片的 HDR 效果丢失了，这显然是因为所有与 HDR 增益图相关的信息都被清除了。如何才能保留增益图呢？图像处理小课堂开课了。
实际上，JPEG HDR 增益图有两个版本。在其被 ISO 规范化之前，谷歌就在使用类似格式保存 HDR 图片，谷歌称之为 UltraHDR。在不久之前，谷歌、苹果等厂商一起将这一格式标准化，出版为 ISO 21496-1。这两种格式有少许不同。如果你在 2024 年从 Lightroom 导出过 JPEG HDR 图片，这大概率在使用 UltraHDR 格式；最近导出的图片则很可能使用 ISO 21496-1 格式。我们可以使用 Exiftool 来检查：
$ exiftool -G1 -a -s hdr.jpg | grep hdrgm [XMP-hdrgm] Version: 1.0
旧格式在 XMP 中有一个 hdrgm:Version 字段。通常为了兼容性，使用新的标准格式导出的图片也会保留这一字段。
$ exiftool -G1 -a -s new_hdr.jpg | grep APP2 [APP2] UniformResourceName: urn:iso:std:iso:ts:21496:-1
新的标准格式则会在 APP2 段中添加一个 UniformResourceName 字段，其值为 urn:iso:std:iso:ts:21496:-1，表示这一图片使用 ISO 21496-1 标准的增益图。
$ exiftool -MPF:all -G1 new_hdr.jpg [MPF0] MPF Version : 0100 [MPF0] Number Of Images : 2 [MPImage2] MP Image Flags : (none) [MPImage2] MP Image Format : JPEG [MPImage2] MP Image Type : Gain Map Image // 对于旧格式，这一项为 none (0) [MPImage2] MP Image Length : 974155 [MPImage2] MP Image Start : 1535216 [MPImage2] Dependent Image 1 Entry Number: 0 [MPImage2] Dependent Image 2 Entry Number: 0 [MPImage2] MP Image 2 : (Binary data 974155 bytes, use -b option to extract)
新旧格式都把增益图放在 MP Image 2 中。这会是一个合法的 JPEG 文件。旧格式中，MP Image 2 的类型为 none，而新格式中，这一项的类型为 Gain Map Image。如果图片丢失了 UniformResourceName 但 MP Image 2 是 Gain Map Image，则图片解码器通常会忽略 MP Image 2 将图片解释为 SDR。
而 HDR 相关的参数则被塞在了 MP Image 2 的 XMP 中。我们可以使用 Exiftool 的 -ee (Extract Embedded) 选项来查看：
$ exiftool -G1 -a -s -ee new_hdr.jpg | grep hdrgm [XMP-hdrgm] Version : 1.0 // 这个是图片本身的 XMP [XMP-hdrgm] Version : 1.0 // 从这里开始是 MP Image 2 的 XMP [XMP-hdrgm] BaseRenditionIsHDR: False [XMP-hdrgm] HDRCapacityMin : 0 [XMP-hdrgm] HDRCapacityMax : 2.263458 [XMP-hdrgm] OffsetSDR : 0.015625 [XMP-hdrgm] OffsetHDR : 0.015625 [XMP-hdrgm] GainMapMin : -1.894775, -0.331843, -0.360353 [XMP-hdrgm] GainMapMax : 2.197754, 1.913239, 1.535431 [XMP-hdrgm] Gamma : 1.321106, 0.624804, 0.815203
以上这些意味着，在图片通过处理管线时，我们需要保留图片的 XMP hdrgm 信息、APP2 段和 MPF 段。任意一项内容的丢失都会导致图片的 HDR 效果丢失。此外，在对图片进行变换时，我们需要一并处理增益图。目前，许多图片处理库还不能正确地处理带有增益图的图片。如果你需要自己开发，请注意：
- 不要将增益图视为图片并尝试进行常见的图像压缩和优化，这可能会导致最终的 HDR 不正确。将其视为用于将 SDR 图片映射到 HDR 图片的计算矩阵。
- 增益图和底图之间的计算使用乘法，因此请注意接近 0 的像素值。意外的 0 像素会导致最终结果中出现 0，这可能会产生断层和伪影。
- 不要修改增益图的 HDR 元数据，即使已知的最大值/最小值像素已经被裁切或不存在在增益图中。增益图中的其他像素仍然可能需要这些值进行正确的计算。
现在我们终于拿到了生产就绪的 HDR 图片。让我们把它放进页面。这可能是最简单的一步。如果你使用增益图 JPEG 图片，并且没有 SDR 的后备，直接把图片放进 img 标签就可以了。如果你使用基于 HDR 色彩管理的 AVIF 图片，则可以使用 picture 元素让浏览器自己选择合适的图片，避免糟糕的 SDR 色调映射：
<picture> <source srcset="hdr.avif" type="image/avif" media="(dynamic-range: high)"> <img src="sdr.jpg"> </picture>
iOS Safari 18 及以下不支持 HDR 图片，但会宣称自己支持 (dynamic-range: high) 媒体查询，且支持 JPEG，因此需要通过 JavaScript 来切换正确的图片。我们需要同时检查 (dynamic-range: high) 媒体查询和 screen.colorDepth > 24 来判断。不过随着 iOS 26 的发布，这个问题将会逐渐得到解决。
现在 HDR 图片应该可以正确显示了。但这还没结束。有的时候，我们作为开发者无法控制用户生成的 HDR 内容，或是不得不使用一些带有极端亮度的 HDR 图片。直接显示这些图片可能会严重损害用户体验，甚至带来健康风险。有任何办法控制页面上 HDR 内容的极端值吗？有什么办法可以让用户在亮色模式下看到完整的动态范围，同时在暗色模式下限制动态范围吗？有的兄弟有的。
dynamic-range-limit: no-limit
dynamic-range-limit: constrained
dynamic-range-limit: standard
通过 CSS Color HDR 规范中定义的 dynamic-range-limit 属性，我们可以限制页面上的 HDR 内容表现。这里我们有三个选择，no-limit 表示不限制动态范围，constrained 表示限制极端亮度，将 HDR 峰值亮度限制在比漫射白色略高，但仍然保持一部分 HDR 表现，standard 表示限制为 SDR 范围。具体色调映射方式由浏览器决定。显然，如果要取得最佳色调映射效果，我们需要使用带有增益图的 HDR 图片。
那打印网页时会发生什么呢？显然我们无法在物理纸张上打印 HDR 效果（废话），在打印时，浏览器会将页面上所有 HDR 内容都色调映射到 SDR。再一次，如果要取得最佳色调映射效果，我们需要使用带有增益图的 HDR 图片。如果有其他内容需要调整，则可以使用 CSS dynamic-range 媒体查询。
HDR 颜色
目前，我们还无法规范地在浏览器中指定和使用 HDR 颜色。尽管 CSS Color 4 规范中定义了 Display-P3 和 Rec2020 等看似支持 HDR 的色彩空间，但实际上 CSS Color 4 只定义了在 SDR 下的色彩空间，并没有定义任何 HDR 色彩空间，因此，在新的 CSS Color HDR 规范被广泛采纳之前，我们无法规范地使用 HDR 颜色。
尽管如此，你应该还记得在文章开头，我们确实进行了 HDR 颜色测试。如果你的设备支持 HDR，你应该能看到比白色更亮的颜色。这是怎么做到的呢？
在 CSS Color 4 中，我们引入了一个新的 color() 函数，它允许我们使用特定的色彩空间来描述超越 sRGB 的颜色，例如 color(display-p3 1 0 0)，我们可以用一个色彩空间名称加上三个 0-1 的成分值（RGB 或 XYZ）来描述颜色。更妙的是，由于现在 CSS 支持不同色彩空间中的颜色转换，实际上在指定颜色时，成分值并不要求在 0-1 之间，而是可以超出这个范围。例如 color(rec2020 0.42053 0.979780 0.00579) 在转换为 Display-P3 颜色时会变为 color(display-p3 -0.6112 1.0079 -0.2192)。你可以注意到这里的值都已经超出了 0-1 的范围。尽管这个颜色并不在 CSS 定义的 Display-P3 色彩空间中，但这仍然是一个有效的颜色。
CSS Color 4 极大地拓展了 CSS 中颜色的灵活性。这不是一个简单的话题，可能值得另写一篇文章来讨论。
这时，如果我们指定的值超出了色彩空间，会发生什么呢？CSS Color 4 规范中写道：
成分值超出 0-1 的范围意味着颜色超出色彩空间。这些值并非无效，且在中间计算中会被保留；但在显示时，它们会通过相对色度意图进行 CSS 色彩空间映射，将值在显示颜色空间中映射到实际值的 0-1 范围内。
这意味着，我们可以定义成分值大于 1 的颜色，如果能被显示，成分值大于 1 就会使得该成分超出 SDR 范围。不过，光保留无效值还不够，我们还需要避免浏览器将超出范围的值转换为 SDR 范围。这实际上是由 ardov 发现的一个 bug。在实际操作中，满足以下条件时：
- 页面中有任意包含 Rec2020 ICC 的图片
- 超出范围的颜色被 CSS 用作背景色
Chrome 会保留所有超出色彩空间范围的值，并不经过映射就提交渲染；不过 iOS Safari 无需这两个条件，可以直接使用超出范围的 HDR 颜色。这意味着，我们可以定义成分值大于 1 的颜色，只要支持，浏览器就会将其渲染为比 SDR 更亮的颜色。此外，为了在 Chrome 中的文字上使用，我们需要将颜色设置为背景色并使用 background-clip: text 来裁剪背景色。在文章开头的例子中，我们实际上使用的颜色是 color(display-p3 2 2 2)，显示为比白色更亮的白色。尽管不符合规范，这一 hack 已经稳定存在了超过两年。我的猜测是，Chrome 在页面中有使用 Rec2020 ICC 的图片时，浏览器会将整个页面都合成为 Rec2020 颜色，在这个过程中，超出范围的背景颜色意外跳过了映射。而 iOS Safari 则疑似会将所有颜色的亮度统一为一个比 SDR 稍亮的亮度，且不会超过屏幕最高亮度。
在上面的例子中，SDR 范围为 0-1 区间。当然我们还可以使用其他 HDR 颜色。
虽然这是一个比较脏的 hack，但通过这种方法，我们可以充分利用现代显示设备的能力，在网页中一窥真正的 EDR UI 的样貌了。由于在 SDR 设备上颜色会被自动映射，我们不必担心用户在 SDR 设备上看到太奇怪的颜色，颜色自己会映射到 SDR 范围。当然，由于是自动映射，我们无法保证颜色在所有设备上都有合理的、一致的表现。
如果你无法看到上面的 HDR 效果：
相机拍摄的 HDR 效果。这无法完美还原实际观看感觉
必须要说明的是，CSS Color 4 中定义的色彩空间本质上都在 SDR 下，这样使用 HDR 颜色显然是不规范且不准确的。一方面浏览器的行为随时有可能变更；另一方面，由于用户浏览器和显示器可能不支持 HDR，或拥有能力不同的 HDR 显示器，如此定义的颜色由于会经过基于设备能力的颜色映射，并不能保证在所有设备上都有一致的表现，无法稳定地在生产环境中使用。此外，我们之前讨论过的 dynamic-range-limit CSS 属性目前也无法用于限制除图片和视频以外的内容，包括使用 HDR 颜色的其他元素。滥用 HDR 颜色可能会严重降低用户体验，甚至产生健康损害，而用户无法对此做出限制，这是不可取的。
要在网页中规范地使用 HDR 颜色，我们需要等待 CSS Color HDR 规范的最终发布，其中定义了 Rec2100 等的真 HDR 色彩空间，以及 dynamic-range-limit 等实用属性。CSS Color HDR 计划为 CSS 引入 rec2100-pq、rec2100-hlg 和 rec2100-linear 等色彩空间。若浏览器支持，我们将可以使用如 color(rec2100-pq 1.0 1.0 1.0) 的颜色。rec2100-pq 是绝对亮度的色彩空间，这一颜色表示亮度为 10,000 cd/m² 的白色（当然，现在还没有什么普通显示器能显示这个）。还有计划添加一个 color-hdr 函数，以便开发者在不同的 HDR 余量（即 HDR 峰值亮度相对于 SDR 的倍数。SDR 下的余量为 0）下显示不同的颜色。由于准确的 HDR 余量被考虑为浏览器指纹，开发者无法不授权就获取确切的 HDR 余量，但是将可以定义这样的颜色：
--color: color-hdr(color(rec2100-linear 0.9 1.0 0.8) 0, color(rec2100-linear 1.8 2.0 1.5) 2);
这时，当用户处在 SDR 显示器下时，该函数将返回前一个颜色；而在余量大于 2 时，返回后一个颜色；在 0-2 之间时，返回插值颜色。
HDR 视频和 HDR 画布
HDR 视频和 HDR 画布其实是两个极端：大部分浏览器很早就支持了 HDR 视频（由于视频通常是单独提交渲染的，不与页面中的其他 SDR 元素合成，支持很方便），但目前所有浏览器对 HDR 画布的支持都还在初级阶段。但这都导致关于它们的内容没法写太多，我将它们合并为了一个章节。
在网页中使用 HDR 视频可以很复杂也可以很简单，主要问题在于选择合适的视频编码。浏览器对 HDR 视频编码的支持各不相同，通常，HEVC HDR 的浏览器支持程度较好，AV1 的支持程度也在慢慢增加。要在浏览器中检查 HDR 的支持程度，可以首先检查 navigator.mediaCapabilities.decodingInfo：
const capability = await navigator.mediaCapabilities.decodingInfo({
type: 'media-source',
video: {
contentType: 'video/webm; codecs="vp09.00.10.08"',
width: 1920,
height: 1080,
bitrate: 2646242,
framerate: '25',
transferFunction: 'pq',
colorGamut: 'p3',
hdrMetadataType: 'smpteSt2086', // HDR 10
}
})
capability // { powerEfficient: true, smooth: true, supported: true }
其中 transferFunction, colorGamut 和 hdrMetadataType 即为 HDR 相关内容检查。如果返回结果为 supported: true 即为支持当前编码组合。Firefox 尚不支持此 API。
在使用 video 元素嵌入视频时，我们还可以在 source 元素的 type 属性中加入编码信息，帮助浏览器选择正确的源：
<video> <source src="movie_pq.mp4" type='video/mp4; codecs="hvc1.2.4.L153.B0"'> </video>
最后，由于部分设备（如电视）可能不支持网页其他内容的 HDR 但支持视频的 HDR，CSS MediaQueries 5 中还有一个 (video-dynamic-range: high) 媒体查询的提案，用法和 dynamic-range 媒体查询一样，但仅用于视频。该媒体查询目前只有 Firefox 支持，Chrome 需启用 flag。
对于画布，情况就复杂一些。由于开发者不仅需要在兼容 HDR 的平台上显示 HDR 内容，还需要针对不同的 HDR 余量甚至 SDR 做色调映射和色彩管理，而 Canvas 最初就是围绕 sRGB 的 8 位/通道设计的。这需要对 Canvas、WebGL 和 WebGPU 的规范都进行不小的修改，牵扯的范围比较广。目前的提案包括：
- 为 2D Canvas、WebGL 和 WebGPU 添加 HDR 色彩空间
- 为 2D Canvas 添加 16 位浮点颜色支持
- 允许为 2D Canvas 设置 HDR 元数据
- 为 WebGL 和 WebGPU 添加拓展的动态范围
- 为 2D Canvas、WebGL 和 WebGPU 添加默认色调映射，未来可能支持自定义色调映射
- 允许 2D Canvas、WebGL 和 WebGPU 在导入纹理或图像时不经过 SDR 映射
...等等。目前已有部分特性可以通过启用 Chrome 的 enable-experimental-web-platform-features flag 使用。例如，在 WebGPU 中，我们可以使用：
const context = canvas.getContext('webgpu')
context.configure({
device,
format: 'rgba16float',
colorSpace: 'display-p3',
toneMapping: { mode: 'extended' },
})
来启用 HDR。目前只支持 Display P3 色彩空间，未来可能会添加 rec2100-linear 等色彩空间；同时目前仅有 Chrome 支持 HDR 画布，需要启用上文提到的 flag。Firefox 和 Linux 上的 Chrome 可能需要额外设置以启用 WebGPU。此外还有一些问题阻止我们在生产中使用 HDR 画布，例如现在无法导入 HDR 纹理，这意味着如果要使用 HDR 图像，我们必须手动解码并将原始像素值传递给画布。这在代码复杂度和性能上都是无法接受的，仍需要等待相关提案的落实。HDR Canvas 目前也无法导出或另存为 HDR 图片。
如果你的浏览器/显示器支持 HDR WebGPU，你应该能在上方看到一个右侧明显比漫射白色更亮的画布，并且渐变区域中的颜色没有明显断层或分界线。
此外，还有一些优秀的 HDR WebGPU 示例可供参考，如 Ultraviolet Photogrammetry, WebGPU HDR Example 和 WebGPU Particles Sample。
总结
现实情况是，目前不同浏览器对不同 HDR 特性的支持情况差距非常大。Chrome 拥有较为完善的支持，Safari 26 正在迎头赶上，而 Firefox 则有些落后了。此外，还有大量 HDR 相关提案正在标准化的过程中，不稳定的 API 和不确定的浏览器支持使得许多 HDR 特性还无法在生产环境中使用。不过至少 HDR 视频和 HDR 图片已经基本可用了——尽管浏览器之间的行为还有许多混乱与不同，但可以预见很快我们就将会有完善的 HDR 图片与视频支持。我最近为我的照片集 Axton Gallery 加上了 HDR 图片支持，使得部分照片在支持的平台上得以充分利用显示器的动态范围，提供更好的观看体验。
其他 HDR 特性则仍有待标准化与浏览器的进一步支持。相信不久之后，我们就可以在浏览器中充分发挥现代显示器的能力了。
发表回复