在正式讨论今天我们博客的主题之前，请大家先看一组照片
不知道你初次看到这组对比会有什么感受呢？是不是感觉到左边的图片似乎更灰，但是右边的图片更亮，似乎更能体现出画面的明暗关系，让该亮的地方够亮，让该暗的地方够暗，这便是现在已经普及的很广泛的技术，也是本次博客的主题，叫做「HDR」
什么是 HDR#
现实世界的光照跨度其实非常夸张：深山背阴处的亮度可能只有 0.01 尼特（nit），而直视太阳或水面的反光可以高达几万甚至几十万尼特，人眼很聪明，瞳孔一缩一放，既能看清水底的鹅卵石，也能感知到刺目的阳光，这种从“最黑的阴影”到“最亮的强光”之间的明暗跨度，就叫做「动态范围」（Dynamic Range）
过去几十年，传统的显示器和手机屏幕（即 SDR，标准动态范围）物理上限非常低——最高亮度通常只有 200~300 尼特，对比度勉强达到 1000:1，这就好比现实世界的亮度是一架大三角钢琴，而老屏幕只有八个琴键，过去相机是怎么处理落日大光比的？它只能搞「折中主义」，把很亮的地方拼命压暗，把很暗的地方生硬提亮，强行把大钢琴的曲子塞进八个琴键，结果就是“细节全在，但光影全无”，画面看起来发灰、发平、甚至像一层油画塑料（就是拉杆左边的图一）
所以不难看出，要真正实现 HDR，需要具备这两个条件：硬件得能「物理发光」和数据得知道「怎么发光」
如果你现在用的是 Apple 的设备，比如说 iPhone，并且是 iPhone X 之后的型号，那你大抵是可以看出上组图片的差异，Apple 在追求显示效果上一直很「激进」，如果大家此时使用的是 iPhone 或者是 MacBook Pro 阅读本文，向右拖动拉杆时能直观感受到阳光刺入眼睛的物理亮度；而如果你使用的是 MacBook Air 或普通办公显示器，看到的可能只是颜色更浓郁、对比更强的画面 —— 这恰恰印证了真 HDR 对「物理硬件」的严苛要求
笔者写这篇文章时用的也是一台普通的 MacBook Air，按道理来说，Air 的屏幕只是一块普通的 SDR 屏幕，物理上并不能实现局部的超高亮度发光，但笔者依然能清晰感受到两张图的巨大差距——这得益于现代浏览器对 HDR 图像出色的色调映射（Tone Mapping）以及 P3 广色域，即便在普通屏幕上，它也能让高光吃满当下的极限白，而不像老旧算法那样灰成一片
但如果你手里拿的是 iPhone（OLED） 或是 14/16 寸的 MacBook Pro（Liquid Retina XDR），请一定把拉杆拉到右边感受一下在这些真 HDR 设备上，Apple 引入了一套极其强悍的机制叫 EDR（Extended Dynamic Range）与 EDR Headroom1，当你在室内把屏幕亮度开在 50% 左右（网页白底约为 150–200 nits）阅读本文时，系统会自动将富余的物理亮度「储备」识别出来；一旦滑到右边这张图片，Mini-LED 或 OLED 就会在不晃瞎全屏的前提下，单点把太阳和波光的局部亮度飙到 1000 nits 以上
HDR 素材从哪来#
大家的相册里都躺着 HDR 图片#
-
iPhone 用户：只要是用 iPhone 12 及更新机型拍摄的照片，相机原生保存的 HEIC/JPEG 文件里，默认就内嵌了苹果私有的 Gain Map，大家在相册里划过照片时偶见「突然亮一下」，就是因为素材本身就是 HDR，并且据笔者观察，拍摄的视频也支持 HDR，视频的 HDR 和照片的也不太一样，笔者对视频只是一知半解，在这里不多说
-
Android 用户：升级到 Android 14+ 的主流机型（Pixel、小米、vivo、OPPO、三星等），相机的“高动态光影 / Ultra HDR”功能打开后，直出的 JPEG 同样内嵌了标准的增益图数据，笔者没有 Android 设备，如果说错了就怪 Gemini
如果是直接导出 iPhone 拍出来的照片，大概率会直接得到一个后缀为 .heic 文件，当年 iPhone 用户把照片传到 Windows 电脑、或者发给老款安卓手机时，对方经常显示「无法打开该文件」；即便在 Windows 10/11 上，微软甚至要求用户去应用商店花几块钱购买「HEVC 视频扩展」才能解码。这种糟糕的跨平台体验，自然让大家觉得「这又是苹果在搞封闭壁垒」
为什么 HEIC 文件依赖于 HEVC 扩展？#
HEVC 的全称是：High Efficiency Video Coding（高效视频编码），它是一套纯粹的算法标准，最初是为了解决 4K/8K 视频体积过大而设计的下一代视频编解码技术，如何通过块划分、帧内预测和运动补偿，把像素数据以尽可能高的保真度、压缩到极小的体积
而 HEIC 的全称是：High Efficiency Image Coding（高效图像编码），它是基于 HEIF（高效图像文件格式）标准的一种具体实现，也就是我们常见的 .heic 照片文件，当工程师发现 HEVC 压缩视频单帧画面的能力极强时，便将这个算法借调到了静态摄影领域，把一张照片通过 HEVC 算法压缩，并按照特定规范打包成一个文件，这个文件就是 HEIC
我们不妨用B站上的一个段子举例子2，厂家为了发货，会用液压机和真空袋把一整张大沙发硬生生抽成薄薄的一片，我们可以把 HEVC 类比成压缩打包的这个技术，那么 HEIC 就是用 HEVC 压缩打包好的沙发，贴上了条形码的「实物快递盒」
那为什么 HEIC 并没有得到普及？
其中的一个原因在于 HEVC 的专利池问题
HEVC 的专利授权复杂度，是阻碍 HEIC 成为互联网通用图片格式的重要因素之一，而且它又进一步造成了兼容性问题，即使到现在，HEVC 依然存在专门管理大量标准必要专利的许可池3
以 2026 年 Access Advance 的 HEVC Advance 专利池为例，合规并使用其商标折扣时，Region 1（美国、欧盟、日本等）的费率大致是：
| 产品 | HEVC 专利费大致水平 |
|---|---|
| 手机 / 平板 / 笔记本 | $0.50 / 台 |
| 一般售价 > $80 的设备、HEVC 软件 | $1.00 / 台或份 |
| 4K 电视/显示设备 | 1.50 / 台 |
| Blu-ray 等实体介质 | 约 $0.028 / 份 |
Region 2 通常大约减半，但这还不是问题的关键，关键在于 HEVC 还不止一个专利池
这也成为阻碍 HEIC 文件成为 Web 图片标准格式的原因之一，后面会介绍笔者的博客采用的方案
专业级的相机 HDR 方案#
笔者手中有一台富士 X-T3，与手机推崇的计算摄影（Computational Photography）4不同，专业摄影领域，X-T3 是一台很奇葩的机器，因为它的视频是支持 HDR 直出的（HLG），但是照片不支持，富士还专门为它的视频 HLG 功能做了一段对比的小 demo：
对于 X-T3 的 HDR 照片合成，需要使用「曝光包围」，可以理解为在同一时刻，快门闪好几下，给你连拍好几张，但是参数不一样，之后就直接在 Photoshop，或者是笔者最喜欢的 Capture One 里面合成就好了！
合成好的可以看这张图：
对于博客来说，应该怎么办#
我觉得对于博客来说，兼容性应该是首位的，关于具体的文件格式的兼容，可以查看这个网址：Can I Use ↗
对于我们的 HEIC 文件格式来说（也就是 iPhone 的默认导出格式）5
本站之前使用的一个文件格式是 WebP6，这个也属于老资历了，而且可以看到兼容性也非常好，那为什么现在不用它了呢？
可以看这张表：
| 能力 | WebP | AVIF |
|---|---|---|
| 8-bit SDR | ✅ | ✅ |
| 10-bit | ❌ 主流格式不支持 | ✅ |
| 12-bit | ❌ | ✅ |
| Rec.2020 | 很受限 | ✅ |
| PQ / HDR10 类图像 | ❌ 不适合作为标准 HDR 图像载体 | ✅ |
| HLG | ❌ | ✅ |
| 广色域 | 可借 ICC 表达一部分 | ✅ 原生能力更完整 |
| HDR 静态照片 | 不推荐 | 很适合 |
为了支持 HDR，目前本站的图片之后都会使用 AVIF 格式：
AVIF 相较于 WebP 而言，兼容性略有下降，可能有些非常古早的浏览器没办法正确观看本站的图片，但是我们毕竟是一个个人的网站，所以如果您看不了，可能需要切换一下新的设备，预计之后也会处于各种考量，不再兼容新的技术
对于企业来说，我了解到很多都在使用 WebP，并且可以通过边缘函数，探测请求头，来进行格式的转换7，但对于个人博客来说，我觉得没有必要，而且有可能因为被攻击等原因产生额外的费用
并且需要注意的是，很多工具在进行格式转换的时候，不会考虑要做 HDR 的保留！所以可能更需要你使用一些 Coding Agent 来进行自定义了~