24、HDR与广色域：HDR10/HLG适配、色彩空间转换、Tone Mapping优化
说实话，HDR这块内容，我当年刚接触的时候也是一头雾水。什么PQ曲线、伽马曲线、色彩原色矩阵……一堆概念砸过来。但等你真正在项目里踩过坑，就会发现，HDR适配的核心其实就三件事：格式识别、色彩转换、亮度映射。今天咱们就把这三件事掰开揉碎了讲清楚。
一、HDR格式：HDR10与HLG的区别
先聊聊最常见的两种HDR格式。HDR10和HLG，说白了就是两种不同的“编码哲学”。
HDR10用的是感知量化（PQ）曲线。它假设你有一个固定的显示环境，比如暗室。所以它的亮度映射是绝对的——1000尼特就是1000尼特，不会因为环境光变化而改变。我最早做HDR播放器时，在暗光环境下看HDR10内容效果惊艳，但拿到户外阳光下，画面就黑成一团了。
HLG则不同。它用的是混合对数伽马曲线。HLG的设计初衷是兼容SDR和HDR显示设备。它的亮度映射是相对的——亮部保留高动态范围，暗部兼容SDR。我记得有一次在广电项目里，需要同时支持机顶盒和手机播放，HLG简直就是救星。因为它不需要元数据，解码器直接根据显示设备的能力做映射。
核心区别总结：
- HDR10：绝对亮度映射，需要元数据（MaxFALL、MaxCLL），适合固定环境
- HLG：相对亮度映射，无需元数据，适合广播电视和混合场景
二、色彩空间转换：从BT.2020到DCI-P3
HDR内容通常使用BT.2020色彩空间。但问题是，绝大多数手机屏幕只能覆盖DCI-P3，甚至有些低端设备只支持sRGB。这就涉及色彩空间转换了。
色彩空间转换的核心是矩阵乘法。说白了，就是把一个三维颜色向量，通过一个3x3矩阵，映射到另一个色彩空间。公式长这样：
// 从BT.2020转换到DCI-P3
// 假设输入RGB值已经归一化到[0,1]
float[][] matrix = {
{ 0.6274, 0.3293, 0.0433 },
{ 0.0691, 0.9195, 0.0114 },
{ 0.0164, 0.0880, 0.8956 }
};
float r_p3 = matrix[0][0] * r_2020 + matrix[0][1] * g_2020 + matrix[0][2] * b_2020;
float g_p3 = matrix[1][0] * r_2020 + matrix[1][1] * g_2020 + matrix[1][2] * b_2020;
float b_p3 = matrix[2][0] * r_2020 + matrix[2][1] * g_2020 + matrix[2][2] * b_2020;
嗯，这里要注意：矩阵系数不是随便写的。它由两个色彩空间的原色坐标和白点坐标计算得出。我在项目中遇到过一个问题——直接用网上找的矩阵，结果颜色偏紫。后来才发现，不同厂商的BT.2020原色坐标有细微差异，必须从设备的EDID或色彩特性文件中读取。
个人经验：色彩空间转换最好在线性空间中进行。先把伽马校正后的RGB值反量化到线性，再做矩阵乘法，最后重新应用目标空间的伽马曲线。跳过这一步，颜色精度会损失不少。
三、Tone Mapping：把大象装进冰箱
Tone Mapping，直译就是“色调映射”。但我觉得更形象的比喻是——把1000尼特的动态范围，压缩到500尼特甚至300尼特的屏幕上。这就像把一头大象装进冰箱，关键是怎么装才能不显得别扭。
常见的Tone Mapping算法有几种：
- Reinhard全局映射：简单粗暴，用一个公式把亮度整体压缩。优点是计算快，缺点是暗部细节容易丢失。
- Filmic映射：模拟胶片响应曲线。亮部压缩平滑，暗部保留好。我比较喜欢这种，视觉上最自然。
- 分段映射：把亮度分成暗部、中间调、亮部三段，分别用不同曲线处理。精度高，但参数调起来很麻烦。
我曾经在一个直播项目里，需要实时做Tone Mapping。Reinhard算法虽然快，但画面发灰。后来我改用Filmic映射，配合一个简单的自适应曝光——根据每帧的平均亮度动态调整映射参数。效果好了很多，而且性能开销只增加了不到5%。
四、Android平台上的HDR适配实践
在Android上做HDR适配，我建议你关注这几个点：
- 检测设备能力：通过
Display.getHdrCapabilities()获取支持的HDR类型和亮度范围。别假设所有设备都支持HDR10。 - SurfaceView vs TextureView：HDR内容推荐用SurfaceView。因为它有独立的显示合成层，能绕过一些色彩管理限制。TextureView在部分设备上会导致色彩空间转换错误。
- MediaCodec配置：解码HDR视频时，记得设置
KEY_HDR10_PLUS_INFO或KEY_COLOR_TRANSFER_REQUEST。否则解码器可能默认输出SDR内容。
// 检测HDR能力示例
Display display = getWindowManager().getDefaultDisplay();
Display.HdrCapabilities hdrCaps = display.getHdrCapabilities();
if (hdrCaps != null) {
int[] types = hdrCaps.getSupportedHdrTypes();
for (int type : types) {
if (type == Display.HdrCapabilities.HDR_TYPE_HDR10) {
// 支持HDR10
} else if (type == Display.HdrCapabilities.HDR_TYPE_HLG) {
// 支持HLG
}
}
}
避坑指南：我曾经在某个国产手机上发现，它声称支持HDR10，但实际解码后色彩完全不对。后来排查发现，是系统层的色彩管理把BT.2020当成了BT.709处理。解决方案是：在渲染前手动做一次色彩空间转换，不要依赖系统自动处理。
五、性能优化：别让HDR变成“耗电大户”
HDR渲染比SDR更耗性能，这是事实。原因有三：
- 色彩空间转换需要额外的矩阵运算
- Tone Mapping需要逐像素处理
- HDR内容通常分辨率更高（4K起步）
我的优化思路是：能省则省，能合则合。
比如，把色彩空间转换和Tone Mapping合并到一个Shader里。这样只需要一次纹理采样，一次计算，就能同时完成两项工作。我在项目中实测，合并后GPU负载降低了约30%。
另外，对于不支持HDR的设备，直接跳过所有HDR处理流程。别做无谓的转换。我见过一些应用，不管设备支不支持，都先解码HDR再转SDR，白白浪费性能。
六、知识体系总览
下面这张图，是我自己整理的HDR适配知识体系。你可以把它当作一个检查清单：
你看，整个HDR适配流程其实就是一个识别→转换→映射→优化的闭环。每个环节都有坑，但只要你理解了背后的原理，适配起来就不会手忙脚乱。
最后说一句：HDR不是银弹。有些低端设备强行开启HDR模式，反而会让画面变差。我的建议是——根据设备能力做降级。支持HDR10就用HDR10，只支持HLG就用HLG，什么都不支持就老老实实走SDR。用户不会因为你没上HDR而骂你，但会因为画面发灰、颜色失真而卸载你的App。
公众号:蓝海资料掘金营，微信deep3321