苏辰汐 发表于 2023-3-9 21:54:27

本帖最后由 苏辰汐 于 2023-3-9 21:58 编辑

hsmms 发表于 2023-3-9 21:44
对于HDR转SDR来说我并推荐使用bt.1886作为转换后的EOTF曲线。

你可以下这两组对比图你就会明白

你和我说的不是一个问题,你这个看上去像是madvr下两者的对比

我不是在说bt.1886曲线本身的准确性合不合适,而是HDR映射SDR时mpv在使用icc进行色彩管理它的bt.1886错误的黑点补偿行为
这本身不是bt.1886的问题,而是mpv自身的奇怪行为(target-prim色彩管理方式下mpv的bt.1886行为是正常的

至于bt.1886和gamma2.2/2.4的选择超出了本贴的讨论范围,本贴仅针对mpv的icc色彩管理和bt.1886行为进行讨论

hsmms 发表于 2023-3-9 22:08:50

苏辰汐 发表于 2023-3-9 21:54
你和我说的不是一个问题,你这个看上去像是madvr下两者的对比

我不是在说bt.1886曲线本身的准确性合不合 ...

请问你使用的哪种tone mapping曲线以及你前面的测试片源告诉我下

苏辰汐 发表于 2023-3-9 22:13:47

本帖最后由 苏辰汐 于 2023-3-9 22:34 编辑

hsmms 发表于 2023-3-9 22:08
请问你使用的哪种tone mapping曲线以及你前面的测试片源告诉我下
这和tone mapping曲线选择没有关系,虽然有的tone mapping曲线会积极地提亮黑暗场景,但是有无ICC色彩管理下的黑点补偿行为是截然不同的,AB对比即可(测试为默认值auto

同样,这和HDR片源也没有关系,只需测试低亮度下的黑暗场景表现即可(全片高亮度当我没说)。测试场景是最后生还者第5集00:17:41.685

友情提醒:如果使用gamma2.4的icc文件可以得到相对正确的黑点补偿行为,使用bt.1886的icc文件应该会得到完全符合预期的行为(未测试)

hsmms 发表于 2023-3-9 22:55:07

本帖最后由 hsmms 于 2023-3-9 23:03 编辑

苏辰汐 发表于 2023-3-9 22:13
这和tone mapping曲线选择没有关系,虽然有的tone mapping曲线会积极地提亮黑暗场景,但是有无ICC色彩管理 ...
对了你用的是否是mpv-lazy?

你测试不同的icc的时候建议你先着色器——清空下配置参数。

我这里发现一个问题当切换icc配置文件时候会导致开启auto后整个视频黑位不正常


=========================================

进一步更新

又测试了下又正常了

之前的10楼应该也是同样的问题会莫名奇妙的开启auto后黑位亮度大幅度下降



苏辰汐 发表于 2023-3-9 23:08:01

hsmms 发表于 2023-3-9 22:55
对了你用的是否是mpv-lazy?

你测试不同的icc的时候建议你先着色器——清空下配置参数。

你又在跑题了,shader着色器一般不会影响mpv的bt.1886行为。伪装成hdr屏通过着色器接管内部处理的骚操作另说

我使用的mpv配置在签名里有,不是mpv-lazy
不过这个无关紧要,以上测试均为--no-config --vo=gpu-next下分别测试对比的,没有任何其他影响参数
ps:--vo=gpu-next不是必须的,--vo=gpu下同前提的行为基本接近

hsmms 发表于 2023-3-9 23:18:11

苏辰汐 发表于 2023-3-9 23:08
你又在跑题了,shader着色器一般不会影响mpv的bt.1886行为。伪装成hdr屏通过着色器接管内部处理的骚操作另 ...

没跑题,我之前10楼的测试以为结果就是那样,但之后又测试了一遍发现又正常了。然后刚才又发现出现同样的问题,具体原因不明。

你难道测试的过程中没发现这类问题?


hsmms 发表于 2023-3-10 00:03:33

苏辰汐 发表于 2023-3-9 23:08
你又在跑题了,shader着色器一般不会影响mpv的bt.1886行为。伪装成hdr屏通过着色器接管内部处理的骚操作另 ...
经过一段时间测试,你这问题大概率是因为加载了错误的icc导致的。

排除以上说的问题

就我测试下来的结果就是我自己的icc配置文件正常,但加载sRGB.icc或者其它的icc文件就出现你上面的问题。

我认为的原因有可能是读取了错误的黑点亮度从而导致错误的计算处理,因为读取的黑点亮度是0以为是无限对比度所以并不需要黑点补偿。加载我自己的ICC配置文件由于能获取正确的黑点亮度进行了相对的补偿。


苏辰汐 发表于 2023-3-10 00:11:08

本帖最后由 苏辰汐 于 2023-3-10 00:18 编辑

hsmms 发表于 2023-3-10 00:03
经过一段时间测试,你这问题大概率是因为加载了错误的icc导致的。

排除以上说的问题

你的结论是没问题的,我说的大前提也是“就我个人而言不会使用icc色彩管理”
原因很简单,我并没有专业校色后的icc配置文件,而使用icc-profile-auto或手动去加载srgb的icc文件就会导致以上问题
不得不面对的一个事实是大多数人都没有专门校色后的icc配置文件,所以无脑使用icc-profile-auto是绝对错误的建议和行为

没有经过专门校色的显示设备下应该使用的mpv色彩管理方式只能是mpv默认的target-prim和target-trc参数,广色域屏和不同gamma在此基础上进行相应调整

hsmms 发表于 2023-3-10 00:15:48

本帖最后由 hsmms 于 2023-3-10 00:22 编辑

苏辰汐 发表于 2023-3-10 00:11
你的结论是没问题的,我说的大前提也是“就我个人而言不会使用icc色彩管理”
原因很简单,我并没有专业校 ...
其实这问题我一开始就说过了

bt.1886是基于显示设备的黑电平设计的,也就是说如果给出错误的黑点亮度那么就会造成你那样的问题。

gamma 2.2 /2.4不会出现这类问题是因为他们是针对观看环境设计的,本身黑点亮度就是从0开始处理的。

=====================================

其实这问题也很好解决就是让mpv添加一个黑点亮度的参数就行(数值在0-1之间)

sommio 发表于 2023-3-10 01:13:04

本帖最后由 sommio 于 2023-3-10 04:06 编辑

boday 发表于 2023-3-9 18:13
@sommio

> 在使用正确的 icc profile,并且 vo_gpu 使用了正确的对比度(mpv 中的 black level 控制)时, ...
确实存在存在歧义,感谢勘误,已经改成了“补偿”

我认为主要问题还是跟 MadVR 等 Windows 用户主流播放方案画面不同,也跟科普系列中的其它播放器不同
小白发现画面不同也不会第一时间排查到是 icc-profile-auto 导致的,翻文档找 icc-force-contrast 并理解更是要花费不少时间
我无意讨论 gamma 之争,但我想应该至少加个 warn,告诉任何人他们可能的期望值是无害的
针对有厂商 icc profile 的用户,我认为有必要提一下 vf=format:gamma
它位于文档中复杂且不显眼的地方,不知道是不是历史原因




页: 1 2 3 [4] 5 6
查看完整版本: 关于 mpv 使用 icc profile 默认行为及是否应该无脑开启 icc-profile-auto 的讨论