RGB24的1677万7216色中，YUV所能表现的颜色数是？
原文标题：1677万7216色の画像をAvisynth 2.6でYV24にしてからRGB24に戻して色を数えてみた[source]感觉还是他先前一篇文章的标题好一点，于是就换了一下（依旧辣鸡翻译）。
在之前的文章中，
使用程序计算了「RGB24的16777216色中，8bit～10bit的YUV所能表示的颜色数」
此次，将要继续那篇文章的内容。
此次将通过
「将包含有RGB24全部色彩的图像先转换为8bit YUV再转换回RGB」
这样的处理，来计算处理后的色彩数。
要使用的工具，原始的图像等如下。
对在x264帖子中告诉我IrfanView拥有统计图像颜色数的人表示感谢。
■使用工具
● Avisynth 2.6 Alpha3 (20110525)
● AvsPmod 2.2.1
● IrfanView 4.32（窓の杜）
■原始图像
● 下面列出的网址中的「all16777216rgb.png」
每个像素的颜色均不相同，
在4096x4096显示了RGB24全部的16777216种颜色。
All 16,777,216 RGB colours - David Naylor: Blog
虽然一直以来都是使用「Avisynth 2.5.8」的，
但是此次的调查中需要使用YUV4:4:4的转换处理，
所以到现在才开始使用「Avisynth 2.6 Alpha3」
在Avisynth 2.6，实现在2.5.8没有的YV24(YUV4:4:4)等
新的色彩空间支持。
（从SEt氏处得知有「Avisynth 2.6 MT」这样的版本存在，
总之，此次先使用「Avisynth 2.6 Alpha3」。）
调查方法如下。
１．建立如下avs文件。
读入图像，先转换为YV24(YUV4:4:4)再转换回RGB。
总之，要在不受周围像素影响的前提下转换为YUV
ImageSource("all16777216rgb.png",end=9,fps=1)
ConvertToYV24(matrix="Rec601")
ConvertToRGB(matrix="Rec601")
２．使用AvsPmod打开avs文件，显示预览画面
右键预览画面→「Save image as...」
保存为PNG文件。
３．使用IrfanView打开２保存的PNG文件，通过
菜单→Image→Information→「Number of unique colors」
来获知图像中所包含的色彩数。
４．变更１中avs的ConvertTo～来分别计算
「Rec601」「PC.601」「Rec709」「PC.709」各个色域所能表现的颜色
如此操作获得的结果，转换后的图像的颜色数如下：
此次的调查结果（将RGB24转换YV24再转换回RGB的图像的颜色数）
8bit-Rec601: 2667378 （与先前调查的差值： -288558）
8bit-PC.601: 3975919 （与先前调查的差值： -286441）
8bit-Rec709: 2760365 （与先前调查的差值： -286059）
8bit-PC.709: 4114580 （与先前调查的差值： -285646）
参考：先前文章中的调查结构（以能把YUV所有值均能取到为前提计算所得颜色数）
8bit-Rec601: 2955936
8bit-PC.601: 4262360
8bit-Rec709: 3046424
8bit-PC.709: 4400226
与先前的文章中的调查结果相比，每个都少了大约28万色。
在先前的文章中，以
「YUV能取到YUV范围内的所有值」
为前提计算。也就是说YUV的值
压缩 Range的情况： Y＝16～235、U,V＝16～240
Full Range的情况： Y＝0～255、U,V＝0～255
的范围内所能取到的，全部的组合计算所得。
但是，在Chikuzen氏的文章中也介绍了
YUVとRGBの比較（DTVかくし味）
YUV所能取到的范围在某些方向比RGB更广。
也就是说存在
「原本与RGB的转换中不被使用，RGB范围外的YUV组合」
这样的情况。
先前的文章中，将这样的RGB范围外的YUV知组合也包含进计算过程，
强行将它们与RGB值相匹配。
于是，就产生了并不是很切合事实的结果・・・。orz
但是，在此次的调查中使用
１．首先，从原始的RGB图像使用ConvertToYV24()求得YUV值。
２．再使用YUV→RGB转换、仅使用RGB在１中转换的来YUV値进行转换。
这样的方法。
所以，以
「不使用RGB范围以外的YUV之组合」
为前提进行变换处理。
也许有其他的原因，我想这里应该能够解释出现28万色误差的原因了。
（这一部分本人的考量或许过于单纯，希望知道详情的人吐槽我・・・）
因为这是是从原本RGB的数据转换得的YUV，所以「YUV所能表现的颜色」
此次的调查结果应该是足以置信的。
所以，粗略地总结的话
「8bit YUV所能表现的色彩数为270万～400万色上下。」
9bit-depth与10bit-depth由于此次调查的方法无法实现、
在先前文章中程序依照如下
RGB24→YUV→RGB24
流程计算应该就差不多了・・・。
★2012/3/13追加：
对先前文章的程序进行修正再计算
→ YUV(8bit～10bit)で表せる色数の再計算
印象中雯姐有做过这样的测试，然后NMM找了一下，我果然没记错_(:3」∠)_
https://www.nmm-hd.org/newbbs/viewtopic.php?f=5&t=707
雯姐的测试结果：
https://www.nmm-hd.org/newbbs/download/file.php?id=598&mode=view
结论：
1.将8bit RGB转换为8bit YCbCr后，损失最小的方式是444采样、PC Range，这点无论从数据上还是截图中都能明显看出来。
2.将8bit RGB用Rounding转换为任意bit的YCbCr的方法中，10bit是可以实现无损转换的最小bit depth。
3.将8bit RGB用Truncate转换为任意bit的YCbCr的方法中，11bit是可以实现无损转换的最小bit depth。
4.不知道为什么，Truncate转换成的10bit比9bit色彩数量还要少，测试多次均为这个结果，不知道是哪里出了问题还是本来就是这样。
5.从截图里看到，使用无Dither的方式转换为8bit 422或8bit 420后，色彩过渡区域不但会出现banding，还会出现条纹状pattern，使用任意一种Dither方式后均能明显改善这种情况。在边缘处420与422会产生较明显的模糊，422只在Horizontal上产生，420则是在Horizontal和Vertical上均产生。 你们俩转来的东西怕是自己都看不懂吧：
1. 8bit 视频放到8bit RGB显示器上，最多也就400W种不同颜色，而分母是1678W。这说明显示器能发挥的细腻度不到24%。（跟vcb-s之前科普文26%数据大致相同，差别主要是转换时候用的工具精度）
2. YUV420P10编码，也就是最常见的10bit编码，能发挥的细腻度高达97%。
LittlePox 发表于 2016-1-2 18:26
你们俩转来的东西怕是自己都看不懂吧：
1. 8bit 视频放到8bit RGB显示器上，最多也就400W种不同颜色，而分 ...
看LP之前写的科普文，一般的圆盘都是用4：2：0采样，这样的话YUV420 8bit编码的视频，最多也就能表现256*128*84≈210万色？
LP这里说的最多400w色是针对YUV422的视频而言的？
說到這個，AMD GPU 明明是給電腦用的預設卻是 YUV444，真的很莫名其妙，電腦用的就應該是 Full Range RGB 啊！ laichiaheng 发表于 2019-2-15 21:28
說到這個，AMD GPU 明明是給電腦用的預設卻是 YUV444，真的很莫名其妙，電腦用的就應該是 Full Range RGB...
應該是HDMI的問題。因爲HDMI一開始是針對TV的，NVIDIA的顯卡在用HDMI連接PC顯示器時會把PC顯示器識別爲HDTV，輸出動態範圍“有限”，不過新版的驅動已經默認改爲“完全”了。AMD的顯卡則是YCbCr 4:4:4。PC顯示器建議使用DisplayPort。詳情可見此文：Correcting HDMI Colour on Nvidia and AMD GPUs
EdveR 发表于 2019-2-15 23:07
應該是HDMI的問題。因爲HDMI一開始是針對TV的，NVIDIA的顯卡在用HDMI連接PC顯示器時會把PC顯示器識別爲HD ...
問題就在於我的顯示器沒有 Display Port，只有 HDMI 和 D-SUB
EW277HDR
这就是大佬们的世界吗.jpg
页:
[1]