我完全无法理解这人在说什么
https://www.chiphell.com/thread-2458539-1-1.html链接地址如上，有谁看懂了吗？
看上去说的好高大上，但是以我理解的内容去理解它的内容完全无法理解。
===========================================
对比另一篇文章，简直就是简单易懂（强烈推荐大家看一下）
http://lt.hd199.com/thread/1883102
本帖最后由 sommio 于 2022-11-13 09:19 编辑
大概相当于“浏览器输入 URL 后发生了什么”的复杂版，标准答案是：
[*]DNS解析域名到ip地址
[*]浏览器发送请求
[*]服务器接受到请求进行处理
[*]服务器返回响应
[*]浏览器针对响应进行解码，获取到html
[*]浏览器渲染html、构建dom节点、加载css、运行脚本
但光 DNS 的 RFC 文档就一大坨……
这个问题的“标准答案”应该是 HDR 显示器使用 DCI-P3，它的范围比 sRGB 更大。因此当查看 sRGB 图像时它会被“拉伸”以匹配 DCI-P3 从而导致过饱和，为了避免这种情况厂家有预设的“sRGB 模式” sommio 发表于 2022-11-13 09:02
大概相当于“浏览器输入 URL 后发生了什么”的复杂版，标准答案是：
[*]DNS解析域名到ip地址
我不觉得它说的内容是把问题复杂化而是很多地方说错了。
其实很多点都是自相矛盾的，就比如1. 识别窗口的 tag , 区分素材是 SDR 还是 HDR这一点跟SDR素材进HDR发灰问题这两点是自相矛盾的。如果windows能正确区分SDR跟HDR，你会认为微软会犯不做yc处理这种低级错误吗？而且也不存在把sdr内容强制转换为HDR内容，因为这样的结果只会造成画面过爆而不是发灰。如果他们说的结果是正确的，而我的结论就是windows不会去tag区分SDR跟HDR，也不会针对SDR的内容去处理，就会造成原本灰阶0-255的SDR硬套在HDR0-1024灰阶范围内，这样就会造成原本255是白色的硬套在0-1024下变成灰色，因为0-1024下的255这个节点就是灰色。
还有一个问题
另一个问题在于...... 一些 HDR 400 的显示器如果在低亮度下严格遵循 Hard Clip , 那么很可能在 HDR 下的细节还没有 SDR 来得多。但 Windows 强制以标准 PQ EOTF 来做上变换的特性意味着如果在低亮度下进行一定的 roll off , 系统 HDR 下的 SDR 可用性会变得十分糟糕。
就如上面问题所说，如果windows本身做PQ EOTF处理，那么不就造成二次映射问题了吗？所以我不觉得window会对HDR信号进行处理。开启windows HDR color意义只是把原本只能接受0-255 srgb的内容扩展到 0-1024 bt.2020范围。最终映射的处理依然是靠显示设备自身来处理。
本帖最后由 sommio 于 2022-11-13 18:55 编辑
hsmms 发表于 2022-11-13 13:40
我不觉得它说的内容是把问题复杂化而是很多地方说错了。
其实很多点都是自相矛盾的，就比如1. 识别窗口 ...
如果显示器可以处理，那用于 GNU/Linux 的窗口管理器 Mutter 就没必要做这些工作了
Split HDR support in following parts.
Phase 1:
HDR support (Pt. 1, EDID: Parsing HDR and Colorimetry) - !2351 (merged)
HDR support (Pt. 2, Wayland-protocols: Wayland-protocols for HDR) - Wayland-protocols for HDR
HDR support (Pt. 3, Implement HDR & Colorspace protocol support) - this MR !2356
HDR support (Pt. 4, Add HDR10 mode support) - backends/native: Add HDR10 mode support
HDR support (Pt. 5, DRM: HDR metadata passthrough for fullscreen surfaces) - this MR !2356
HDR support (Pt. 6, Test: Wayland client app for HDR) - Wayland HDR video client app
Phase 2:
HDR support (Pt. 7, Clutter: Tone mappings from PQ to SDR)
HDR support (Pt. 8, Clutter: Colorspace conversions from Rec2020 to sRGB)
HDR support (Pt. 9, Clutter: Signal mapping from sRGB to PQ)
HDR support (Pt. 10, DRM: Tone & Gamut mappings, transformation for fullscreen surfaces) - TODO - naveenk2
Phase 3:
Future Plans:
Add the support for other Colorspaces & TF
Maybe allow metadata pass-through for non-fullscreen surfaces
其它操作系统支持 HDR 需要开发的特性参阅 HDR in Linux: Part 1 - Jeremy Cline's Blog & HDR in Linux: Part 2 - Jeremy Cline's Blog sommio 发表于 2022-11-13 18:50
如果显示器可以处理，那用于 GNU/Linux 的窗口管理器 Mutter 就没必要做这些工作了
你这内容并没有看出系统本身涉及到tone mapping的问题
本帖最后由 sommio 于 2022-11-13 19:45 编辑
hsmms 发表于 2022-11-13 19:32
你这内容并没有看出系统本身涉及到tone mapping的问题
开发草稿已经很清楚的写了
When a HDR surface is fullscreen and can be unredirected, pass the metadata the client provided via the Wayland protocol to KMS, allowing fully correct presented result. i.e. tone & gamut mapping, transformation (PQ/Rec.2020 to sRGB & vice versa)
窗口管理器是桌面操作系统的一部分，Windows Vista 之后的窗口管理器被称为 Windows DWM 本帖最后由 hsmms 于 2022-11-13 20:18 编辑
sommio 发表于 2022-11-13 19:38
开发草稿已经很清楚的写了
When a HDR surface is fullscreen and can be unredirected, pass the metada ...
仔细看了下你这内容完全跟我主贴里的内容不相关吧？
关键HDR视频本身都会带元数据，不是更应该指的是Phase 1: HDR Metadata pass-through for fullscreen surfaces这一条吗？
还有最关键的一点系统要是做色调映射处理，那么按照哪个节点做拐点处理？直接按照标准的PQ EOTF曲线来？这对于满足标准的显示设备来说没有问题但是对于非满足标准的显示设备来说这样做只会造成糟糕的结果。而且对于超过1000nit亮度以上的场景难道直接HARD CLIP？
所以我不认为系统会对HDR视频做色调映射处理，因为这样做会造成的问题太多了。
本帖最后由 Starlight 于 2022-11-13 23:18 编辑
其实很多点都是自相矛盾的，就比如1. 识别窗口的 tag , 区分素材是 SDR 还是 HDR这一点跟SDR素材进HDR发灰问题这两点是自相矛盾的。如果windows能正确区分SDR跟HDR，你会认为微软会犯不做yc处理这种低级错误吗？而且也不存在把sdr内容强制转换为HDR内容，因为这样的结果只会造成画面过爆而不是发灰。如果他们说的结果是正确的，而我的结论就是windows不会去tag区分SDR跟HDR，也不会针对SDR的内容去处理，就会造成原本灰阶0-255的SDR硬套在HDR0-1024灰阶范围内，这样就会造成原本255是白色的硬套在0-1024下变成灰色，因为0-1024下的255这个节点就是灰色。
默认 203nit，RGB_sdr(1, 1, 1)约等于 RGB_hdr(0.58, 0.58, 0.58)
HDR设置里的那个滑块就是用来调这个数字的
有C2用户将这个点拉到大约160nit避免全屏白时ABL带来亮度变化
也有lcd hdr屏幕用户觉得203太暗把这个拉到300+nit的
比起亮度映射问题，色域映射才是主要问题
大部分的变灰不是亮度问题而是显示器没有clip色域，而是把收到的2020直接传到了显示器内部系统的不知道什么色域范围去了
还有一个问题
另一个问题在于...... 一些 HDR 400 的显示器如果在低亮度下严格遵循 Hard Clip , 那么很可能在 HDR 下的细节还没有 SDR 来得多。但 Windows 强制以标准 PQ EOTF 来做上变换的特性意味着如果在低亮度下进行一定的 roll off , 系统 HDR 下的 SDR 可用性会变得十分糟糕。
就如上面问题所说，如果windows本身做PQ EOTF处理，那么不就造成二次映射问题了吗？所以我不觉得window会对HDR信号进行处理。开启windows HDR color意义只是把原本只能接受0-255 srgb的内容扩展到 0-1024 bt.2020范围。最终映射的处理依然是靠显示设备自身来处理。
并不
假定 sdr 是 8bpc, 那么它 （sdr黑点至上一个段落设置的sdr白点）有 255 个电平可用
此时假定 hdr 是 10bpc，那么它有接近 600 个电平可用
内处理精度一般是 16bit，因为没有理由色彩管理不用显卡硬件加速，而现在的所有显卡原生半精度浮点 float16
更低的内处理精度只能节约显存而不能节约浮点算力
还有最关键的一点系统要是做色调映射处理，那么按照哪个节点做拐点处理？直接按照标准的PQ EOTF曲线来？这对于满足标准的显示设备来说没有问题但是对于非满足标准的显示设备来说这样做只会造成糟糕的结果。而且对于超过1000nit亮度以上的场景难道直接HARD CLIP？
拐点是 Metadata_smpte2086.maxLuminance, 有 profile 的话系统设置里会直接显示出来，没有就按 10000 处理。
高于该点的地方会 chroma mapping 直至变白，而不是 tone mapping 变黑。
本帖最后由 hsmms 于 2022-11-14 00:06 编辑
Starlight 发表于 2022-11-13 23:09
默认 203nit，RGB_sdr(1, 1, 1)约等于 RGB_hdr(0.58, 0.58, 0.58)
HDR设置里的那个滑块就是用来调这个数 ...
Metadata_smpte2086.maxLuminance是什么鬼？你说的不会是maxcll吧？如果你说的是maxcll的化那么大部分设备并不会按照maxcll来做柺点。
有 profile 的话系统设置里会直接显示出来，这个profile是什么鬼？能有相关图片吗？
chroma mapping变白，tone mapping变黑又是什么鬼？
没有理由色彩管理不用显卡硬件加速?就又是什么鬼？我没听说过色彩管理需要用到显卡硬件加速啊？
如果是显示器没有做clip色域难道结果不是应该过饱和吗？
========================================
并不
假定 sdr 是 8bpc, 那么它 （sdr黑点至上一个段落设置的sdr白点）有 255 个电平可用
此时假定 hdr 是 10bpc，那么它有接近 600 个电平可用
内处理精度一般是 16bit，因为没有理由色彩管理不用显卡硬件加速，而现在的所有显卡原生半精度浮点 float16
更低的内处理精度只能节约显存而不能节约浮点算力
这一段内容又是什么鬼？浮点算力什么的跟发灰有什么关联？
本帖最后由 Starlight 于 2022-11-14 00:27 编辑
SMPTE ST 2086 "Mastering Display Color Volume" static metadata.maxLuminance
峰值亮度
BT.2446 Conversion Method C 同时提出了两者的映射，分别应用于低于/高于目标白点的部分
因为这就是那么自然的事情，不需要特地标明实现者就会用显卡硬件加速
打个比方 709 的 1.0 绿 在rec2020 上正确显示是 0.58 绿
系统将一个正确映射到 2020 的 0.58 绿传给显示器，显示器却是 p3 色域， 显示了 0.58 p3 绿，这就欠饱和了
会导致 sdr 到 hdr 灰阶不准的问题是因为内处理精度不足，可用电平是远超 8bpc sdr 需要用的
这一段我没看见哪里说到灰了
页:
[1]
2