陆伍 发表于 2015-2-4 11:49
谢谢！还有个问题就是，用hdmi连电视能不能电视全屏放电影，然后我用rmbp上网什么的？
不懂怎么操作啊 ...
在偏好设置的显示器设置那里调啊，就是调分辨率那里
如果你是4k电视的话可能只能选5级缩放，那确实就蛋疼了，只能靠第三方工具
配置文件里头加上
fs
fs-screen=1
就是打开文件就默认在第二个屏幕全屏播放第一个屏幕不受影响
本帖最后由 暁美ほむら 于 2015-2-4 15:23 编辑
boday 发表于 2015-2-4 10:50
@暁美ほむら
更正一下，我之前在 #136 说 mpv 开了色彩管理后看起来会亮一些的原因是错的。实际上是因为 m ...
怎么会用这样的方式来提高细节？
这明显错误的方式啊。
正确的不是无论2.2 2.35还是2.4都应该看到细节？
如果真的是默认1.96GAMMA，那么现在情况是
MADVR 3dlut对比MPV 3DLUT在我这里情况是亮度比后者低，GAMMA比后者高（前者是2.2），细节比后者多很多。
如果是拿调整GAMMA或者亮度来提高细节，以我目前知识来看这种方法明显就是错的。
那还有一种可能这只是针对MAC系统下的，根本不适合windows这样做
本帖最后由 boday 于 2015-2-5 00:45 编辑
暁美ほむら 发表于 2015-2-4 14:58
怎么会用这样的方式来提高细节？
这明显错误的方式啊。
这么做的目的不是为了提高细节，而是为了尽可能接近片子的原始效果（工作室参考监视器上的效果）：
https://github.com/haasn/mpv/com ... 15a1d09dcdd94fea3d3
https://github.com/haasn/mpv/com ... 0faf23fa271b1647b80
更详细的讨论见我上面 #156 的链接。老实说，我没把那个超长的讨论看完，也没完全明白这样做的理由。
mpv 使用 vo=opengl:srgb 或者 vo=opengl:icc-profile=xxx 时会看到“亮度”提高，原因即是上面所说。
根据我的测试，madvr 不开色管与 mpv 不开色管的输出是完全一样的，而 madvr 选择“this display is already calibrated”，然后下面选 bt.709、2.2 时，如果播放的是 bt.709 的片子，颜色是不会有任何变化的。也就是说，madvr 此时仍然假设片源的 gamma 就是 2.2。而 mpv 在开了色管的情况下，会默认 bt.709 片源的 gamma 为 1.961。
但我不知道 madvr 使用 3dlut 后会如何处理。从你前面给的截图看，无论是 madvr 还是 mpv 在开了 3dlut 之后的效果是很接近的，而 2.2-1.961 = 0.239 的 gamma 差反映在画面上区别应该是非常明显的。
至于是否需要观看时通过后期调整 gamma 来适应不同环境光亮度，有些人认为需要，也有很多人反对。至少上面讨论里的 @UliZappe 同学是强烈反对这么做的，无论环境光照如何，任何后期对 gamma 的改变在他看起来颜**显得不对。
另外，你说这只是针对 mac 而不适合 windows 是不对的。mac 系统本身的色彩管理功能比较完备，所以按照 cocoa api 来开发的程序基本不需要考虑色彩管理的问题，系统自然会搞好。但是视频播放器因为性能上的考虑，需要自己来处理色彩管理的问题（这也是为什么你必须在 mpv 的配置文件里指定你的 icc 文件）。因此，这里 windows 和 mac 是没有区别的。
陆伍 发表于 2015-2-4 11:49
谢谢！还有个问题就是，用hdmi连电视能不能电视全屏放电影，然后我用rmbp上网什么的？
不懂怎么操作啊 ...
能。我上面说的“再加上两行命令，让视频窗口默认直接出现在你的外接电视上并全屏显示”就是针对你这种用法啊。（那两行命令和 #161 写的那两行作用是相同的，随便选一种就好）
默认设置下达到你说的这种效果是不会有问题的。你如果遇到了问题再来问就好。
本帖最后由 暁美ほむら 于 2015-2-5 01:03 编辑
boday 发表于 2015-2-5 00:37
这么做的目的不是为了提高细节，而是为了尽可能接近片子的原始效果（工作室参考监视器上的效果）：
https ...
你madvr是用什么方式生成3dlut的？
顺便看下这段文字
Q:General: Wacky image colors (swapped colors)
A:Solution: This happens when you created a “XYZ LUT + swapped matrix” profile and is a way to al** you that the software you're using does not support XYZ LUT profiles and falls back to the included matrix (which generally means you'd loose accuracy). If you're having this situation only in some applications, creating a “XYZ LUT + matrix” profile will remedy it (but please keep in mind that those applications not supporting XYZ LUT will still fall back to the matrix, so results can be different from applications that support XYZ LUT correctly). If all colormanaged applications you use show swapped colors, you should create a matrix profile instead. Note that you do not have to re-run any measurements: In dispcalGUI, choose a profile type as suggested previously, adjust quality and profile name if you want, then choose “Create profile from measurement data...” in the “Options” menu and select the profile you had the issue with.
暁美ほむら 发表于 2015-2-5 00:51
你madvr是用什么方式生成3dlut的？
我现在没有给 madvr 用 3dlut（原因我前面说了）。我上面说的是手动告诉 madvr 这台显示器已经校正到 bt.709 色彩空间和 2.2 gamma。
boday 发表于 2015-2-5 00:57
我现在没有给 madvr 用 3dlut（原因我前面说了）。我上面说的是手动告诉 madvr 这台显示器已经校正到 bt. ...
还有这段
Generally you can differentiate between two types of profiles: LUT based and matrix based.
Matrix based profiles are smaller in filesize, somewhat less accurate (though in most cases smoother) compared to LUT based types, and usually have the best compatibility across CMMs, applications and systems — but only support the colorimetric intent for color transforms. For matrix based profiles, the PCS is always XYZ. You can choose between using individual curves for each channel (red, green and blue), a single curve for all channels, individual gamma values for each channel or a single gamma for all channels. Curves are more accurate than gamma values. A single curve or gamma can be used if individual curves or gamma values degrade the gray balance of an otherwise good calibration.
LUT based profiles are larger in filesize, more accurate (but may sacrifice smoothness), in some cases less compatible (applications might not be able to use or show bugs/quirks with LUT type profiles, or c**ain variations of them). When choosing a LUT based profile type, advanced gamut mapping options become available which you can use to create perceptual and/or saturation tables inside the profile in addition to the default colorimetric tables which are always created.
L*a*b* or XYZ can be used as PCS, with XYZ being recommended especially for wide-gamut displays bacause their primaries might exceed the ICC L*a*b* encoding range (Note: Under Windows, XYZ LUT types are only available in dispcalGUI if using Argyll CMS >= 1.1.0 because of a requirement for matrix tags in the profile, which are not created by prior Argyll CMS versions).
As it is hard to verify if the LUT of an combined XYZ LUT + matrix profile is actually used, you may choose to create a profile with a swapped matrix (which I'd recommend), ie. blue-red-green instead of red-green-blue, so it will be obvious if an application uses the (deliberately wrong) matrix instead of the (correct) LUT because the colors will look very wrong (e.g. everything that should be red will be blue, green will be red, blue will be green, yellow will be purple etc).
Note: LUT-based profiles (which contain three-dimensional LUTs) might be confused with video card LUT (calibration) curves (one-dimensional LUTs), but they're two different things. Both LUT-based and matrix-based profiles may include calibration curves which can be loaded into a video card's gamma table hardware.
贴这两段的意思是？我看不出这和我们刚才的讨论有直接联系（我看过这些，应该是 dispcalgui 说明文档的内容）。
boday 发表于 2015-2-5 01:21
贴这两段的意思是？我看不出这和我们刚才的讨论有直接联系（我看过这些，应该是 dispcalgui 说明文档的内容 ...
我的意思是会不是是我用了XYZ LUT+swapped matrix生成配置文件导致这样的情况
我看了下如果软件不支持XYZ LUT的化，使用swapped matrix方式会出现错误的颜色
不行了，尝试调整GAMMA值来提升暗部细节，发现会破坏亮部细节
怎么调都无法达到MADVR+3DLUT那效果
本帖最后由 boday 于 2015-2-5 04:16 编辑
暁美ほむら 发表于 2015-2-5 02:46
我的意思是会不是是我用了XYZ LUT+swapped matrix生成配置文件导致这样的情况
我看了下如果软件不支持XY ...
不会吧。你有看到你刚才贴的这段话里描述的情况吗？
so it will be obvious if an application uses the (deliberately wrong) matrix instead of the (correct) LUT because the colors will look very wrong (e.g. everything that should be red will be blue, green will be red, blue will be green, yellow will be purple etc).
那看起来是会完全错乱的，而不只是看起来“有点怪”的程度。
本帖最后由 boday 于 2015-2-5 04:17 编辑
暁美ほむら 发表于 2015-2-5 03:30
不行了，尝试调整GAMMA值来提升暗部细节，发现会破坏亮部细节
怎么调都无法达到MADVR+3DLUT那效果 ...
是的。理论上说我们甚至可以把 gamma 拉到能把一堆暗部细节看得清清楚楚，但那不是制片人员希望观众看到的样子。
如果你还留着你当初给 madvr 生成 3dlut 文件用的那个 icc 源文件的话（应该就是一个 xyz lut + swapped matrix profile），可以直接把这个 icc 文件喂给 mpv，看 madvr 和 mpv 各自出来的结果（如我在 #137 所说）。我觉得出来的结果区别应该会很小，因为理论上区别仅可能来自 littlecms 和 argyll 在生成 3dlut 时算法（精度）的不同。
boday 发表于 2015-2-5 04:14
是的。理论上说我们甚至可以把 gamma 拉到能把一堆暗部细节看得清清楚楚，但那不是制片人员希望观众看到的 ...
颜色错误是因为MPV不支持XYZ LUT导致的，这点上面那段英文也说了。
还有就是MADVR 3dlut与MPV 3dlut我觉得区别在于前者是按你显示器校色后的实际GAMMA曲线来呈现，而后者是按全部GAMMA 1.96来呈现，但关键是很多显示器根本做不到GAMMA一条直线。
下面是DELL U2713HM GAMMA曲线，跟你显示器应该是同一规格的，只是尺寸不一样。
http://i62.tinypic.com/2qdyemp.png
本帖最后由 暁美ほむら 于 2015-2-6 03:39 编辑
boday 发表于 2015-2-6 02:00
@暁美ほむら
仔细看我上面的回帖。你有看到颜色完全错乱吗？没有的话，你所谓的“颜色有点怪”和 lut prof ...
1.我觉得你搞错了什么，我说的是XYZ LUT，支持LUT profile不代表支持XYZ LUT，就我测试情况MPV是不支持XYZ LUT表达方式的LUT的。颜色上也不能说完全错乱，但就是错的这一点是肯定的。
2.之前我也说过了，暗部细节比MPV多，而亮部没有MPV那么亮，就上面的图上的伽玛曲线就应该能说明了，madvr显示的GAMMA是按照你显示器实际GAMMA曲线来呈现的而不是全部弄成1.961或者2.4,2.4来呈现。而且使用3DLUT后，MADVR是不管色彩，灰阶，亮度和GAMMA这些而是完全交给3DLUT来处理的。
关于GAMMA标准实际上去年才决定下来，决定把GAMMA标准值定位2.4.再这之前其实GAMMA值根本没有一个准确的标准，都是各自为阵。
本帖最后由 暁美ほむら 于 2015-2-6 03:35 编辑
就下面图红色圈那一块，我使用MADVR+3DLUT是能看到细节的（阶梯式楼梯）
而MPV使用3DLUT就是一团黑，而且亮部细节也太亮了。
http://i58.tinypic.com/5n8779.png
测试片源是偶像大师灰姑娘02话ED
知道原因了，因为MADVR的3DLUT我是按照最新的rec.1886 GAMMA标准来实现的
暁美ほむら 发表于 2015-2-6 03:27
1.我觉得你搞错了什么，我说的是XYZ LUT，支持LUT profile不代表支持XYZ LUT，就我测试情况MPV是不支持XYZ ...
1. 何以证明 mpv 不支持 xyz lut profile？如果你没有看到红变蓝、绿变红、蓝变绿这样完全颠倒的颜色，说明你这里认为的“颜色不对”和 swapped matrix 完全无关。lut profile 中多出一个故意颜色颠倒的冗余部分就是为了 debug 用的，一旦出错就会非常明显。
另外，你又如何通过主观判断某一个颜色结果是对的还是错的呢？
2. 对，使用色管（或者说 3dlut）后，那些都是交给 3dlut 来处理的。无论 mpv 还是 madvr 都是这样，没有你想象的按照不同的方式处理 gamma 那回事。关于 1.961 的部分是发生在交给 3dlut 之前的，和 3dlut 完全无关。
暁美ほむら 发表于 2015-2-6 03:53
知道原因了，因为MADVR的3DLUT我是按照最新的rec.1886 GAMMA标准来实现的
于是你得到一样的结果了？
boday 发表于 2015-2-6 07:51
1. 何以证明 mpv 不支持 xyz lut profile？如果你没有看到红变蓝、绿变红、蓝变绿这样完全颠倒的颜色，说 ...
不支持XYZ LUT的化，红不会变成蓝，绿变成红的.我们都知道firefox是不支持XYZLUT的，要不然不会是这样的
http://i60.tinypic.com/k538cx.png
而在这种配置下的RGB三色是正常的
http://i61.tinypic.com/wmo8ww.png
我会这么说是因为跟不支持XYZ LUT的firefox下效果完全就是一样的
firefox
http://i58.tinypic.com/wwey5h.png
MPV
http://i61.tinypic.com/24fem3r.png
===========================================
这么假的颜色用的着主观判断吗？一眼就能看出颜色不正常。
本帖最后由 暁美ほむら 于 2015-2-6 15:12 编辑
boday 发表于 2015-2-6 07:52
于是你得到一样的结果了？
随便查了点资料
BT.1886 GAMMA好像就是用来解决暗部一团黑问题的。
你可以看下此贴，尤其是这贴的95楼
http://www.avsforum.com/forum/13 ... t-1886-gamma-4.html
@boday
所以能不能联系下MPV开发者把GAMMA换成BT.1886 GAMMA?
boday 发表于 2015-2-5 00:51
能。我上面说的“再加上两行命令，让视频窗口默认直接出现在你的外接电视上并全屏显示”就是针对你这种用 ...
谢谢lz，终于知道怎么双屏了，原来鼠标拖过去就行了，囧rz
还有个问题，怎么调字幕的时间啊？
下了个字幕时间比视频快
@陆伍
终于知道怎么双屏了，原来鼠标拖过去就行了，囧rz
是的。两块屏幕在逻辑上是在同一个平面上“连”起来的，你还可以在 系统设置 - 显示 里调整两块屏幕的相对位置。
而我们上面推荐你写的那两行命令就是让 mpv 自动把窗口放在外接的那块屏幕（也就是你的电视）上并全屏显示视频，省得你每次手动用鼠标拖过去并全屏了。
还有个问题，怎么调字幕的时间啊？
下了个字幕时间比视频快
RTFM：https://github.com/mpv-player/mpv/blob/master/DOCS/man/mpv.rst
x and z
Adjust subtitle delay by +/- 0.1 seconds.
本帖最后由 boday 于 2015-2-7 10:21 编辑
@暁美ほむら
不支持XYZ LUT的化，红不会变成蓝，绿变成红的.我们都知道firefox是不支持XYZLUT的对 lut profile 的支持还有对 l*a*b 和 xyz 的区分？比如只支持 l*a*b 而不支持 xyz？
firefox 不支持 xyz lut 吗？我找到一篇两年前的文章，看起来是支持的（但需要打开 iccv4 的支持，否则就回落到 swapped matrix 上出现颠倒的颜色了）。
你发的这张截图是在什么状态下截到的？系统加载你的 xyz lut profile 然后用 firefox 打开 s1？
我会这么说是因为跟不支持XYZ LUT的firefox下效果完全就是一样的没有理解你的意思。你下面第一张 firefox 的截图是如何得到的？你在截图后内嵌了 xyz lut profile 并在firefox 中打开？
而且这两张截图的效果也并不一样，后者显得更亮一点。未经色彩转换的原图是什么样子？
一眼就能看出颜色不正常。我觉得如果你没有长期视频调色和母带制作经验，说这种话要谨慎。如果你只是看习惯了你之前的设置呢？
所以能不能联系下MPV开发者把GAMMA换成BT.1886 GAMMA?我并不肯定 mpv 的这个决定是完全正确的，但是这个决定是基于大量讨论和测试做出的。事实上，将 bt.709 编码的视频 gamma 默认为 1.961 和 bt.1886 标准的提出有着直接关系。如果你真的感兴趣，可以看看这个记录了整个讨论过程的帖子：https://github.com/mpv-player/mpv/issues/534
几个要点：
1. 如你所说，bt.1886 的提出是对之前 bt.709 的补充，希望对混乱的现状划定一个标准，这个标准自然要考虑向后兼容性，即，模拟老式 crt 显示器的特性；
2. 2.4 是对被工作室广泛使用的 reference crt 显示器 gamma 的估计值；
3. 影视制作业界的进化是非常保守的，在很大程度上还没有普及现代数字图像视频的色彩管理概念；
4. 作为在电脑上使用的视频播放器，应该力图把图像以符合色彩管理逻辑的方式呈现，那么，“根据某种特定观看环境来对片源进行的调整”就必须排除在色彩管理链之外；
5. 因此，在 crt 的平均 gamma 值上除去一个对比度增强系数，就得到了实际的 gamma 值。苹果在一个技术文档中明确提到了这一点：
https://developer.apple.com/libr ... /tn2257/_index.html
if you had measured the response of a CRT, most had a gamma of between 2.4 and 2.5 (it is dependent on how the brightness and contrast is set on the monitor). If you choose a value halfway in between, 2.45, and remove the contrast enhancement (the 1.25 gamma boost provided for viewing in dimly lit environments) you'll get a value very close to 1.96 (2.45/1.25 = 1.96).6. 如果 mpv 将 bt.709 编码的视频 gamma 默认为 1.961，bd 原片在 mpv 中的播放结果和同一片源、dvd 版原片和 itunes 出售的原片在 quicktime player x、itunes 中的播放结果一致，且使用 final cut pro x（仅有的拥有完善色彩管理支持的 nle 系统之一）生成的测试影片来测试，几种播放条件下的颜色结果也全部吻合；
7. 苹果是唯一一个参与数字视频标准制定并同时在出售数字影视产品以及用来播放这些产品的硬件的公司，因此具有很大的参考意义。
@暁美ほむら
不管怎样，用户当然有自己的最终选择权。
你可以试试在配置文件 vo 那一行里加上一个 :gamma=0.89136，把 gamma 差值补偿回去，应该可以得到和 madvr 一样的效果。
（1.961/2.2 = 0.89136）
boday 发表于 2015-2-7 10:14
@暁美ほむら
不管怎样，用户当然有自己的最终选择权。
我想要的是暗部的GAMMA降低而亮部的GAMMA升高（按2.2标准来计算）
你这种方法是整个GAMMA线都处理成0.89136，但对于LCD来说不可能做到一条直线，更别说那些中低端的显示器了。
而以上问题BT.1886 GAMMA就能很好解决。
本帖最后由 暁美ほむら 于 2015-2-7 15:08 编辑
boday 发表于 2015-2-7 10:08
@暁美ほむら
对 lut profile 的支持还有对 l*a*b 和 xyz 的区分？比如只支持 l*a*b 而不支持 xyz？
1.firefox是支持XYZ LUT+ matrix但不支持XYZ LUT+swapped matrix
2.下面第一张截图是用MADVR渲染+3DLUT方式直接截图然后丢进XYZ LUT+swapped matrix配置文件firefox里面截的图
3.看那效果根本不需要什么经验，因为那色调太假了，整个白平衡都是错的。
4.关键是以前影视制作业界都没把GAMMA值给统一化，但不知道现在有没有真正的统一化。而BT.1886 GAMMA可以说是解决了这问题。而且由于LCD自身对比度很低导致有时候拍摄的时候用LCD监视器看会发现暗部细节就是一团黑，这时候根本不知道是拍摄的问题还是显示器自身的问题，而BT.1886 GAMMA提出解决了这问题。
BT.1886 GAMMA是接近于rec.709 2.4的，而之前业界也将GAMMA值统一为2.4，那为什么还要去坚持所谓的 1.961 GAMMA标准？这标准压根就没人去遵守。我是坚持改用BT.1886 GAMMA的，因为很好的解决了针对不同显示器暗部一团黑的问题。
本帖最后由 boday 于 2015-2-8 01:58 编辑
@暁美ほむら
你这种方法是整个GAMMA线都处理成0.89136，但对于LCD来说不可能做到一条直线，更别说那些中低端的显示器了。你还是没有明白我前面说的意思。1.961 和你说的这些是完全无关的。
而以上问题BT.1886 GAMMA就能很好解决。可否上一个 mpv 使用 2.2 gamma（:gamma=0.89136）和你的 madvr 在一起的对比截图？
firefox是支持XYZ LUT+ matrix但不支持XYZ LUT+swapped matrix“支持”这个词不是这么用的……这里的逻辑是，要么一个程序支持 xyz lut profile，要么它不支持；而 matrix 部分是用来测试是否支持的。按照你的说法去理解，firefox 应该是不支持 xyz lut profile 的，但你没有看到颠倒的颜色又如何解释？
下面第一张截图是用MADVR渲染+3DLUT方式直接截图然后丢进XYZ LUT+swapped matrix配置文件firefox里面截的图你应该用关掉色管出来的原始画面截取后再用 firefox 打开再截图才对啊。
而之前业界也将GAMMA值统一为2.4，那为什么还要去坚持所谓的 1.961 GAMMA标准？这标准压根就没人去遵守。你这句话和你这段第一句话直接矛盾了。1.961 gamma 不是一个标准，而是根据现实中影视母带制作环境来对被标记为 bt.709 编码的视频的实际 gamma 的一个估计，这是一个“事实标准”。
说实话，我不太想继续这样的讨论了，继续下去也很难把这个问题搞清楚。主要原因是我们都对这个问题没有足够专业的认识，而这个问题本身又因为其标准变化及历史原因变得复杂，再加上网上众多遵循不同习惯标准和持不同意见的业内专家的讨论，让非专业的人理解这个问题变得更加困难。
本帖最后由 暁美ほむら 于 2015-2-8 03:45 编辑
boday 发表于 2015-2-8 01:56
@暁美ほむら
你还是没有明白我前面说的意思。1.961 和你说的这些是完全无关的。
可否上一个 mpv 使用 2.2 g ...
1.我觉得你搞错了什么？我提出使用BT.1886 GAMMA是因为想解决暗部一团黑的问题。我上面说的只不过是讲为什么要使用BT.1886 GAMMA而不是其它。
2.firefox肯定是不支持swapped matrix的，这一点不只我一个提出来。如果不信自己去测试下然后让firefox加载它，看是否正常。
3.让我们去遵循影视母带制作环境本来就是不可能的事情，再加上GAMMA标准还没统一和业界是否在遵循那所谓的事实标准都无法确定，那么为什么要去遵守你那个所谓的事实标准？如果制作者拿个OLED监视器来制作片子，你认为就我们目前用的LCD显示器那可怜的对比度如果按照你所谓的事实标准的化，你能看到完整的暗部细节吗？哪个更好就用哪个，完全没必要去遵守所谓的事实标准。
4.你要的截图,你可以去自己测试，偶像大师灰姑娘第二话ED，你应该能看见后面一团黑的那部分其实有阶梯的影子而不是一团黑。
http://i58.tinypic.com/2im3sxs.png
http://i62.tinypic.com/346s5m0.png
本帖最后由 boday 于 2015-2-8 07:29 编辑
@暁美ほむら
firefox肯定是不支持swapped matrix的硬要说“支持”swapped matrix 的话，那么任何应用程序都不应该能支持它——即加载了它还能显示正确的颜色，否则 swapped matrix 就完全失去意义了。我不由得怀疑你真的明白所谓的 xyz lut+swapped matrix profile 里故意放进一个颜色错误的 swapped matrix 的意义吗？
如果不信自己去测试不是我不信你的结果，而是我没能理解为啥你的 firefox 出现那样的情况。
让我们去遵循影视母带制作环境本来就是不可能的事情没错，正是因为如此，色彩管理才如此必要。这里没有分歧。
再加上GAMMA标准还没统一和业界是否在遵循那所谓的事实标准都无法确定，那么为什么要去遵守你那个所谓的事实标准？
确实是没法确定。mpv 的做法至少可以让“相当一部分”影片看起来符合片源的原始效果，但这个“相当一部分”能占多大比例？在不同国家、市场、影片类型中又有多大分布上的差异？这个确实是不清楚的。
哪个更好就用哪个，完全没必要去遵守所谓的事实标准。这么做当然是没问题，mpv 的 :gamma 选项就是让你做这个用的。作为一个播放器要考虑的是其默认设置能尽可能在大多数情况下输出正确的颜色（*）。而现实是你必须选择某一种“标准”，不可能“什么都不选”，不是吗？
*：这句话只在开启了色彩管理时才成立。因为事实上绝大多数用户是完全不在乎色彩管理的，所以默认设置里色彩管理其实是不开启的，这时 mpv 会保持原样直接输出。
@暁美ほむら
来来来，直接看这个帖子吧，看起来问的是和你一模一样的问题：
https://github.com/mpv-player/mpv/issues/1563
应该可以回答你不少疑问。
ps. cyberbeing 这个人经常可以在 doom9 的 madvr 讨论帖里看到，之前还回复了我在 madshi 的 issue tracker 上的问题；haasn 则是目前负责 mpv 的色彩管理以及移植 madvr 那些缩放算法的人，在 doom9 上的 id 是 nand chan，之前也经常在 madvr 讨论帖里出现。看来互联网上的 videophile 圈子还真是小……
本帖最后由 boday 于 2015-2-8 09:12 编辑
@暁美ほむら
然后是关于截图测试。我自己重新装上 dispcalgui 用我手里的 icc 文件转了个 3dlut 试了下，验证了我上面的推测：
mpv 和 madvr 两者都不开色管，结果完全相同，以下以此为原图基准；
mpv 使用 :srgb 会自动默认片源为 gamma 1.961，表现为比原图 gamma 低（更亮）；
madvr 使用“该显示器已被校正”并选择“bt.709”和“2.2”（相当于 srgb），表现为与原图相同；
mpv 使用 :icc-profile 仍然会自动默认片源为 gamma 1.961，表现为颜色修正，并比原图 gamma 低（更亮）；
madvr 使用 3dlut，表现为颜色修正，gamma 比原图升高（更暗），这里升高的原因是我生成 3dlut 时勾选了 bt.1886 mapping；
mpv 使用 :icc-profile 并加上 :gamma=0.81708（*），得到的结果与 madvr 使用 3dlut 完全相同（**）。
也就是说，使用相同的 icc 文件（以及生成的 3dlut 文件），mpv 使用 gamma 调节可以得到与 madvr 相同的结果。两者的区别仅在于对片源 gamma 值的“猜测”，而不在于色彩管理（即之后的色域转换）这一步上。
那么为啥你 #189 这里的 mpv 截图有那么大的问题呢？这已经不光是暗部细节可见不可见的问题，整个颜色也都不对了（如果你的 madvr 结果是正确的话），而且在很多区域都出现了 banding。如果你给这两者用的是同一个 icc 文件的话，那么也许 littlecms 确实不支持 xyz lut profile。
*：0.81708 = 1.961/2.4。
**：在 #191 的那个帖子里提到，gamma 调节有一定误差并会导致变色（应该是 bug），但肉眼不可见。
本帖最后由 暁美ほむら 于 2015-2-8 15:17 编辑
boday 发表于 2015-2-8 09:10
@暁美ほむら
然后是关于截图测试。我自己重新装上 dispcalgui 用我手里的 icc 文件转了个 3dlut 试了下， ...
相同配置文件
还有你madvr的3dlut是用什么方式生成出来的？是否使用了MADTPG这些都玩意？
boday 发表于 2015-2-8 07:34
@暁美ほむら
来来来，直接看这个帖子吧，看起来问的是和你一模一样的问题：
看了下，Cyberbeing跟我的想法一样，现在等讨论结果吧。
@暁美ほむら
还有你madvr的3dlut是用什么方式生成出来的？是否使用了MADTPG这些都玩意？直接拿我原来的 icc 文件用 dispcalgui 的生成 3dlut 功能做出来的。那个 icc 文件是 spyder 的官方软件做的，应该只是一个简单的 single curve matrix profile。
boday 发表于 2015-2-9 00:59
@暁美ほむら
直接拿我原来的 icc 文件用 dispcalgui 的生成 3dlut 功能做出来的。那个 icc 文件是 spyder...
所以我觉得你应该根据此设置重新弄一遍
http://www.avsforum.com/forum/139-display-calibration/1471169-madvr-argyllcms.html
带来的效果比你现在会好很多
暁美ほむら 发表于 2015-2-9 01:10
所以我觉得你应该根据此设置重新弄一遍
http://www.avsforum.com/forum/139-display-calibration/1471169 ...
我知道。不过我前面说了，我的 spyder 用 dispcalgui 加载后运行不起来，我也不知道为啥。另外这台 windows 本子本来就是放在办公室工作用的，不方便也犯不上花那么大功夫去校色。
boday 发表于 2015-2-9 04:05
我知道。不过我前面说了，我的 spyder 用 dispcalgui 加载后运行不起来，我也不知道为啥。另外这台 windo ...
因为编写方式不一样
本帖最后由 四点 于 2015-3-27 20:48 编辑
vo=opengl-hq:smoothmotion:scale=ewa_lanczos:scale-radius=3:icc-profile-auto按这个跑了下感觉游刃有余
就把scale-radius改到了10，直接卡爆，现在改回了2。
我是用homebrew tap了mpv，然后自动编译的。里边ewa_lanczossharp没有了好像(0.8.3)，我就换到了ewa_lanczos。教程的可以改一下了。
另外smoothmotion效果好像不是很明显？
有没有办法打开靠屏幕边框的磁性？就是说我把视频拖到显示器的角落里，同时不希望让它超出显示器范围