在线将 SDR 转为 HDR 图片（SDR to HDR online）

前言

看着几年前买的HDR1000显示器跌成白菜价，死板的老任给自己的新掌机加入HDR，Apple终于为Safari加入HDR照片支持，我意识到不远的将来，HDR或许即将真正得到普及。 Ripp一直很喜欢HDR这一显示技术与标准，它就好像Live Photo一样，将原本「死寂」的照片变得更加鲜活，让像素组成的矩阵更贴近现实，无论是亮度还是色彩。说到这里，感触最深的还是PSVR 2——一款支持HDR显示的OLED VR设备，即便分辨率相对较低，它的实际观感在我心中也远超大众眼中的上位替代Quest3。 原因很简单，Quest采用的是LCD屏幕，没有分区调光。这带来的结果是，处于一片漆黑的场景时看到的是灰蒙蒙的一片，宛如浓雾；在灯光与阳光下显示的光点暗淡无比，画面色彩寡淡、毫无生机。而PSVR2的显示效果就更贴近现实——你可以说这是OLED带来的效果，但OLED恰恰是承载HDR最棒的载体，miniled确实只是一个过渡产物（即便如此，也远强于无分区的LCD）。 因此在开发「Gamer」时，Ripp就曾设想全站的静态图片与UI支持HDR，但最终还是因为兼容性问题废弃了。不过在此过程中，发现了一个新的问题：目前网络上的HDR资源似乎还远远少于SDR，并且几乎没有一个便捷的SDR转HDR工具。 于是，这个项目的构想就开始了…… 链接：sdr2hdr.hiripple.com

效果展示 让我们先撇开复杂的代码设计与专有名词，看看效果（以下图片未经过OSS压缩，请确保你的浏览器与显示器支持AVIF HDR）。

（知乎不支持AVIF，请前往博客https://hiripple.com 查看）

从上到下依次是：原图SDR、本项目转化的HDR、RTX_HDR。和市面上效果最好（之一）、老黄家的RTX_HDR相比，本项目的效果似乎也还不错？如果觉得色彩饱和度过高，当然也可以手动调整。 毕竟老黄的RTX_HDR仅限于RTX显卡，背后是强大团队和AI技术的支持，而且只支持视频与部分游戏，无法导出。 说到这里，不得不吐槽一下Windows糟糕的HDR支持：默认HDR显示时，用自带的截图工具截图居然会过曝，开启自动颜色调整又转成了SDR……Steam截图工具可以AVIF截图，但是又仅限于游戏内，老黄的Alt+F1卡bug出不来了…… 一度曾以为，在Windows上截一个HDR图片根本无法实现。偶然间，用Xbox手柄的分享键成功得到了一张巨大的JXR图片，这个格式网页不支持、Pixelmator不支持，在线转化工具——没有。最后终于在GitHub找到了这个项目：github.com/ledoge/jxr_… ，总算搞定了一个AVIF，论截一张图有多么困难…… 技术实现 众所周知，SDR到HDR的转化不可能是无损的，HDR标准包含更多的信息，因此这一过程类似于「超分辨率」的一种上采样过程，用算法尽可能地推测SDR图片中包含的信息，模拟原生HDR的观感。即便如此，转化之后的图片还是可能存在瑕疵，建议：不断微调参数、使用专业工具进行后期处理。 简单来说：

• 亮度范围：SDR目标白约100 nits；HDR常见峰值600–1000+ nits（标准上限到10,000 nits），并且暗部也能更黑
• 色域：SDR多为Rec.709；HDR以BT.2020为主
• 位深：SDR常8-bit；HDR基本10/12-bit
• 元数据：HDR10有静态元数据（MaxCLL/MaxFALL），HDR10+/Dolby Vision有动态元数据，逐场景/逐帧优化

人眼感知最强烈，也是最重要的自然是亮度映射，这一步需要把SDR的「感知亮度」映射为HDR的「物理亮度」。 首先是sRGB→线性：把8-bit sRGB（非线性）解到线性光域，再估计场景亮度并做"逆映射"(iTMO)，用709亮度系数算出SDR的相对亮度Y（≈0..1），再用一条可调曲线把SDR的~100 nits亮度扩展到更高的绝对亮度，以及拉低暗处的亮度。这一部分的相关参数允许在前端调整，以保证最好的效果。 为了不偏色，需要按亮度比例缩放RGB，例如用scale = Y_hdr_nits / (100 * Y)这种方式把每个通道等比放大（Y≈0时做保护）。

其次是色彩空间：Rec.709线性→Rec.2020线性，让颜色容纳在更大的BT.2020色域里；可选地在2020线性空间里做一点饱和度提升/色域扩展。 当然还有位深，HDR输出为10/12-bit（AVIF 10/12-bit），因此在8→高位转换时加上有序抖动（Bayer），降低梯度带状风险。 最后是输出格式，目前选定了唯一的格式AVIF是综合了多方面考量的。如今支持HDR的格式有PNG、JPEG、JXR、HDR、HEIF、EXR、AVIF、MP4、WEBM等，视频格式暂不考虑。 以自己用得最多的Safari为例，据参考资料，Safari支持：

• JPG（requires gain map – supports ISO as well as the legacy Android / Apple encodings）
• AVIF（with or without ISO gain map）
• JXL（without gain map）
• HEIF（with or without Apple gain map – I did not test ISO gain maps）
• PNG（encoded as PQ – I have not tested PNG gain maps）

其中JPG和PNG需要额外的map/编码，HEIF在Chrome浏览器似乎无法显示，而专业格式JXL、HDR、EXR这些需要一个比较「重」的编码库，并且文件大小成倍增长，也很少有浏览器支持。这无论是对Ripp的免费R2对象存储，还是自己跑后端的小主机，都是非常严峻的考验。 因此最终只限定了AVIF作为输出格式，如果真的有用户需要，可能会按照PNG、JPG、HDR这一顺序新增格式。 Update: 目前已经添加了JPEG与PNG作为输出格式。 Web UI

WebUI前端还是使用Next.js打造（刚写完博客，比较顺手），部署在Vercel，整体非常简洁，以功能为主。

前端具有丰富的可调节参数，还有深色/浅色模式，以及机翻的七国语言i18n。 因为涉及到逐像素循环+图片编码，单纯靠Vercel的免费额度可能一天就用完了。综合考虑后，本项目使用前后端分离的方案，Vercel作为网页前端，使用Ripp本地的N100小主机进行后端计算与编码、使用Cloudflare R2对象存储，Supabase作为数据库。 加了一些基本CSP策略后，先上线试试吧～ 小结 欢迎Issues/反馈/Star（本项目正在开发中，暂不开源）：github.com/CelestialRi… 如果有任何内容Ripp表述得不够严谨，也欢迎在下方留言。