在压缩RGB源时,使用bt709和ycgco转换为yuv间的压缩率对比测试。
dwing吧
全部回复
仅看楼主
level 14
787633258 楼主
吧里测编码器和参数的比较多,我来测
(水)点不一样的[滑稽]
测试选用SSIM和GSMD为质量评价算法,计算在RGB48下完成,使用muvsfunc里提供的函数完成计算。
对比为常规的limited range bt709和full range ycgco之间的对比。从关于ycgco的描述来看,ycgco应该配合full range使用。(以下默认bt709为limited range,ycgco为full range)
源使用从《徒花异谭》解包出来的op(720p),并转换为RGB48(放大uv平面使用nnedi3),然后分别转换为bt709和ycgco的yuv444p16,然后round到10bit(避免dither时引入噪点)。
编码器使用x265,基于preset slow稍微(随便)调整了一下,并根据我自己的习惯,在编码yuv444时,设置色度平面的qp偏移为+2。
2020年09月01日 08点09分 1
吧务
level 14
好![滑稽]
2020年09月01日 08点09分 2
level 14
787633258 楼主
2020年09月01日 08点09分 3
level 14
787633258 楼主
2020年09月01日 08点09分 4
level 14
787633258 楼主
可以看到,ycgco在RGB上的整体质量好于bt709,但是在绿色平面的质量表现不如bt709。
对于RGB源,将其编码为ycgco是个不错的选择,能提供整体更好的压缩率。但我不推荐无端地将bt709的源转换为ycgco进行编码。
如果打算使用ycgco,需要注意将crf的值稍微提高一些,在其他参数不变时,同crf,ycgco将得到比bt709高的码率(可能也与一个是full range,一个是limited range相关)。
以上测试结果很可能会受到设置的色度平面qp偏移的值的影响,如果你设的不是+2或者不是yuv444,结果可能发生变动。
2020年09月01日 09点09分 5
ycgco这玩意搜了下居然可以无损RGB互转...另外你这个UV是用算法搞得 用1080p->720p downscale保持UV转RGB48应该更准确一些
2020年09月02日 04点09分
最后喂给x265要做抖动的毕竟正常压制都是这样的 不能脱离实际
2020年09月02日 04点09分
level 8
虽然大佬你也知道我看不懂但是我是必须给你顶帖的[阴险][吐舌]
2020年09月01日 10点09分 6
level 6
学习
2020年09月01日 10点09分 7
level 7
很明显YUV更好,绿色对亮度影响最大,红色差距不大,蓝色YUV稍微弱。
ITU-R BT.709 primaries:
Y=0.2126R+0.7152G+0.0722B
所以还是YUV最终成为事实标准。
同样在HDR颜色空间(rec2020+PQ),ICtCp优于Ycbcr。
2020年09月02日 04点09分 8
一般比都是比亮度的差距,具体怎么求亮度,随便找个变换来算就行,srgb的也可以。
2020年09月02日 04点09分
我就是想比RGB[阴险]
2020年09月02日 05点09分
最后到人眼里的是RGB。
2020年09月02日 05点09分
@空之飞翔之春哥 比亮度存在的问题是,亮度的公式用哪个,以及那个公式是否真的完全分离出亮度。你用709的公式,709那不肯定赢[阴险]
2020年09月02日 05点09分
level 7
人眼对亮度的的灵敏度可以参考CIE的结果,至于个体差异确实存在,但整体大趋势都是这样的。
不过就是换算出亮度,计算的时候gamma怎么取,2.2,2.4,linear,PQ,怎么选?这些都影响计算取值。但不管怎么算,绿色都是最重要的。
2020年09月03日 03点09分 9
1