『漫游』酷论坛>『影音数码技术学习交流』>有关新版LanczosResize中 ..

大虾@2007-11-17 22:35

我发现所有颜色空间转换里面，最伤画面的就属转RGB了。
至于DGAVC，那个……shin大大也跟我抱怨过这个似乎还有一些问题。不知道是AVS还是DGAVC的问题。据说这个bug还不是源于AVS或者是DGAVC，而是源于ffmpeg的（记忆比较模糊了，说错了表pia偶），所以……应该比较难于解决吧。
我因为从来不内嵌，所以自然就用不上了……啊哈……啊哈……啊哈哈哈…………

分别用下面方法试验：
1.AVS
复制代码
  1. loadplugin("D:\gk\dgmpgdec\DGDecode.dll")
  2. mpeg2source("jin-roh.d2v",upconv=1)
  3. trim(0,1)
  4. LanczosResize(864,480,5,0,-4,0)
在VDM中选择Direct Stream Copy输出YUY2无压缩AVI。

2.AU（用的刚出的0.99a）
用M2V插件直接加载MPEG。在AU里只做crop和resize，切边像素数和resize分辨率与AVS脚本里相同。同样选取前两帧之后保存成为无压缩YUY2 AVI。

为了避免YV12 Decoder的干扰，使用了YUY2颜色空间的AVI。

对这两个AVI放大到400%进行观感对比，发现AVS保存出来的AVI无论是细节还是颜色都要胜过AU。
照理说，AVS里的Lanczos3Resize是AU移植过去的，效果应该基本相同，差别估计就差在了颜色空间转换上。在AU中，m2v.aui递给AU的是YUY2数据，AU内部处理要先提升到YUV444，保存时又要降低到YUY2。尽管AU的计算精度比AVS高许多，但经过这两折腾，数据损失还是避免不了。尽管差别只有放大到400%才能显示出来，但是丢失了终究是丢失了。在实验中，AVS毕竟还是经过了一次颜色空间转换，如果不经过颜色空间转换，全程YV12的话，一定会更好。
引用

绿叶之砚@2007-11-18 00:14

没记错的话D2V是TMPG出来的？

TMPG是RGB的吧…那么手I意味这颜色空间convert……Orz

说错表打偶…偶DVDRip超级外行
引用

wolfsoft@2007-11-18 12:49

TMPG出来的那东西，对AU只是起个参考作用，类似avs里的TPRivtc

d2v是dgindex嘛....
引用

su_xinling@2007-11-19 03:06

crop()是真切，所以YV12里必须是偶数，resize里是假切所以没有这个限制，YV12里只要最后尺寸是偶数即可。
“先crop()后resize”由于crop是真切，结果是“硬”边缘，范围外已无参考点提供，resize出来的边缘部分比“先resize后crop”有较大瑕疵。但是“先resize”整个画面范围较大速度就慢似乎没必要，所以本该要先切但又似乎要多留几线，等resize后再切掉？这样写脚本好麻烦！但是又有必要，为了方便所以后来resize里就整合crop但是这里是假切也就是设定范围的意思，resize运算时仍然能参考边缘附近数据，同时这样也没就所谓YV12的必须切数偶数的问题。
引用

大虾@2007-11-19 12:41

也就是说，是resize的时候无视要“切掉”的部分了？
如果是的话那就说明我没猜错。
引用

yujin630@2007-11-19 15:41

引用
最初由 su_xinling 发布
crop()是真切，所以YV12里必须是偶数，resize里是假切所以没有这个限制，YV12里只要最后尺寸是偶数即可。
“先crop()后resize”由于crop是真切，结果是“硬”边缘，范围外已无参考点提供，resize出来的边缘部分比“先resize后crop”有较大瑕疵。但是“先resize”整个画面范围较大速度就慢似乎没必要，所以本该要先切但又似乎要多留几线，等resize后再切掉？这样写脚本好麻烦！但是又有必要，为了方便所以后来resize里就整合crop但是这里是假切也就是设定范围的意思，resize运算时仍然能参考边缘附近数据，同时这样也没就所谓YV12的必须切数偶数的问题。


嗯 多谢指点...

又学到东西了 嗯 一开始完全不明白所谓的假切意义何在
引用

雷鸣@2007-11-20 18:25

说到概率性问题，我机子用directshowsource读取rmvb的时候概率性出现a什么v什么的东西，但是直接重来就可以了……真诡异
引用

大虾@2007-11-21 07:15

话说我也经常遇到这个问题。
如果这样，可以尝试一下换一个real media的分离器试试看……不知道管不管用。
我一直用dio大大的完美解码，好像上半年的几个版本都没发现这个问题，可惜以前的安装包都没有留下，无从验证了。
引用

hwb9091@2007-11-22 19:15

过去看看学学！
引用

雷鸣@2007-11-22 20:24

引用
最初由 大虾 发布
话说我也经常遇到这个问题。
如果这样，可以尝试一下换一个real media的分离器试试看……不知道管不管用。
我一直用dio大大的完美解码，好像上半年的几个版本都没发现这个问题，可惜以前的安装包都没有留下，无从验证了。

猜测是windows的directshow的稳定型问题
引用

不败的魔术师@2007-11-22 20:28

引用
最初由 雷鸣 发布
说到概率性问题，我机子用directshowsource读取rmvb的时候概率性出现a什么v什么的东西，但是直接重来就可以了……真诡异






A.....v......
引用

adamhj@2007-12-14 00:54

resize的代码看了半天总算是看明白了点...
首先，resize每次只对一个轴的变换，resize实际上是对一个轴进行缩放再对另外一个轴缩放
滤镜构造的时候，先按照源和目标大小图像宽度，以及所选取resize算法，算出一个窗口大小fir_filter_size来，然后将目标图像上的每个像素为中心，投影到源图像上的坐标pos(浮点数)，将以pos为中心，fir_filter_size为直径范围内的若干个源坐标点实际位置(整型)，通过所选resize算法(func->f())换算到一个权值数组；将所有目标图像上点这样换算出来的权值数组和窗口最左边像素的坐标(实际上是缓冲区的地址)放在一张表里组成了pattern；
之后实际取帧的时候，从pattern里取出窗口位置以及权值数组和源图像的像素取内积后得出目标像素

带crop的resize可以认为是先resize再crop，图像边缘点仍然会用到源图像中(本来应该)被crop掉的像素进行计算。

因此，crop成奇数像素resize实际上只影响到各点加权距阵的计算，实际上用的源图像大小还是mod2的(对YUV而言)
引用

«12»共2页

| TOP