【test】4:2:2 comparison

[zhongpang]

順便寫一個avs內16bit下420->422的範例，至少這樣精度應該還是夠高的，雖然是否準確還要看情況：
[syntax lang="avisynth" lines="f"]# Adjust these settings according to your source clip
matrix = "709"
tv_range = true
chroma_p = "MPEG2"
#
Dither_convert_yuv_to_rgb(matrix=matrix,
\ tv_range=tv_range,
\ cplace=chroma_p,
\ chromak="bicubic",
\ output="rgb48y")
r = SelectEvery(3, 0)
g = SelectEvery(3, 1)
b = SelectEvery(3, 2)
Dither_convert_rgb_to_yuv(r, g, b,
\ matrix=matrix,
\ tv_range=tv_range,
\ cplace=chroma_p,
\ chromak="bicubic",
\ lsb=true, output="YV16")
[/syntax]

请问下为何要转到rgb呢？
不能直接 YUV420->YUV444->YUV422吗？
虽然在16bit下YUV-RGB-YUV 没有什么损失

——————————————————————————————————
444->420->444和444->420->444->422->444
显然都是不能还原出原来444的效果
后者由于涉及多次采样，重采样，效果也许比前者还差
如果说有损压缩编码422比420更有效率
那还不如直接用444来压，播放时也不用重采样了（原始分辨率），
不过444比起420，编码速度下降20%，而且对444对显卡的要求比起420高很多倍
（集显HD4250,10bit,1080P, 用madvr渲染，420 40fps 左右，422 25fps 左右，444 5fps 左右）
不过在某处看到有人说，
444和422比起420，在保持主观质量不变的前提下可以减小码率
不知道原理是什么，也好像还没人证明过

做了些测试，源是rgb32，
在avs里转成10bit YUV 444,422和420
420和422默认的chroma-qp-offset和444的不一样
压444时把chroma-qp-offset改为-6（开psy）
x264 crf相同，其他参数也相同，压出来文件的大小总是444>422>420
不过实验样本较少，也不能说明什么

觉得在源是420的情况下，在相同码率有损编码的情况下，
除非422或444出现的瑕疵比420明显减少（或许反而还会增多），
否则422或444只是增加压制的时间和后期播放的负担

用最简单的最邻近插值法做420->444
由于Y没抽样，最终还原出的画面除了红色边缘，也不会看到很明显的锯齿
用其他插值法，不产生锯齿，也会产生ringing
是要锯齿还是ringring，按个人喜好

最后上一些图

444

422 bicubic

420 bicubic

[06_taro]

這裡討論的是420的源，想輸入RGB源的請另開新帖

420直接resizeUV到422/444其實可以，譬如這樣：

到444

代码： 全选

c16 = U16
U   = c16.UtoY.Dither_resize16(width, height, 0.25, U=1, V=1)
V   = c16.VtoY.Dither_resize16(width, height, 0.25, U=1, V=1)
YtoUV(U, V, c16.ConvertToYV24)

到422

代码： 全选

c16 = U16
U   = c16.UtoY.Dither_resize16(width/2, height, 0.25, U=1, V=1)
V   = c16.VtoY.Dither_resize16(width/2, height, 0.25, U=1, V=1)
YtoUV(U, V, c16.ConvertToYV16)

其實這樣更好些，Y可以完全不動，所以16->10即使不dither也基本上沒問題
只不過這樣的話需要自己處理chroma position（上面全部是用MPEG2的）。
反正不管怎樣輸入420的源都不應該在前期做upsampling，寫出來只是做sample而已，又不會拿去用，所以我懶得把這種直接resize的方法寫成MPEG1/MPEG2/DV的可選擇函數…

[sil_yuzhe]

做了一组简单测试，用imagesource("source",pixel_type = "RGB24")去分别加载两张图片，一张是只有灰度的图片，一张是红色和蓝色的图片，分别如下：


分别进行converttoYV12()处理，用POT内建的捕获工具捕获原始分辨率(720x480)的BMP，扔到PS里观察，结果如下：
灰度的图片在RGB24和YV12下的边缘过度均是2x1的，红蓝图片的边缘RGB24下是2x1，YV12下是2x2，RGB24到YV12的过程已经让边缘过度范围扩大了。
然后在converttoYV12()的基础上继续添加converttoYUY2()，仍旧捕获图像，扔到PS里观察，结果如下：
灰度图片从420转成422之后的边缘范围还是2x1，但是红蓝图片的边缘被扩大成3x3或者3x2了，YV12到YUY2的过程仍旧会让边缘过度范围扩大。
进而继续converttoYV12()，依旧捕获后扔PS观察，结果如下：
无论灰度还是红蓝图片的边缘没有再被扩大了，仍保持在灰度2x1，红蓝3x3或3x2

重新做红蓝的图片测试，加载成RGB24后converttoYUY2()，边缘从2x1变为2x1或3x1，再继续converttoYV12()则不会继续扩大边缘

[06_taro]

這裡討論的是420的源，想輸入RGB源的請另開新帖

[btcdtc]

taro,你又低端黑人家U2了

[angelcat]

受教了

taro,你又低端黑人家U2了

是我選擇不對 跟U2沒有關係

受教了

taro,你又低端黑人家U2了

是我選擇不對 跟U2沒有關係

哦,和前几周U2的小夜弄混了...我又脑残了...

顺便关于"記憶中你好像黑過我 :O("这个问题
我的回答是"恩,人家超喜欢当反串黑的,尤其是看到像你和高数喷SEED巨那样的'大神'的时候"

顺便...那个帖子中"極度的CHROMA偏差，於是進行修正"
什么是極度的CHROMA偏差...球点解

"同樣進行修正，並且去"噪"，保留"星星"的細節"
保留星星的细节也没看懂...意思是去噪会把星星抹掉吗?铜球点解

U2 PM

[btcdtc]

受教了

taro,你又低端黑人家U2了

是我選擇不對 跟U2沒有關係

哦,和前几周U2的小夜弄混了...我又脑残了...

顺便关于"記憶中你好像黑過我 :O("这个问题
我的回答是"恩,人家超喜欢当反串黑的,尤其是看到像你和高数喷SEED巨那样的'大神'的时候"

顺便...那个帖子中"極度的CHROMA偏差，於是進行修正"
什么是極度的CHROMA偏差...球点解

"同樣進行修正，並且去"噪"，保留"星星"的細節"
保留星星的细节也没看懂...意思是去噪会把星星抹掉吗?铜球点解

[06_taro]

今天做了一下具體的測試
avs內部的convert或者sws直接在YUV內up/downsampling都不會出現這種低劣upsampling的現象
唯一出現的是sws做yuv->rgb轉換的時候，用的是類似pixel duplicate的方式
請問小夜菊苣草莓狂熱這片的轉換過程是怎麼做的，中途經過ffms或者dss用ffdshow之類的基於sws走了rgb？

[angelcat]

沒有 純粹是兩個圖的濾鏡不太相同..

這圖最後也不是U2-RIP的成品 你們上面的一切測試都是對的

[fch1993]

[syntax lang="avisynth" lines="f"]# Adjust these settings according to your source clip
matrix = "709"
tv_range = true
chroma_p = "MPEG2"
#
Dither_convert_yuv_to_rgb(matrix=matrix,
\ tv_range=tv_range,
\ cplace=chroma_p,
\ chromak="bicubic",
\ output="rgb48y")
r = SelectEvery(3, 0)
g = SelectEvery(3, 1)
b = SelectEvery(3, 2)
Dither_convert_rgb_to_yuv(r, g, b,
\ matrix=matrix,
\ tv_range=tv_range,
\ cplace=chroma_p,
\ chromak="bicubic",
\ lsb=true, output="YV16")
[/syntax]

这个输出YV24的话该如何修改。查维基的转换没查出来。