关于vinverse

arashi

就是处理那种后面的主要画面是无交错的
但是前面有一块是有少量横纹的小画面挡住
需要去除前面的横纹，而且不需要在意前面画中画（？）部分的质量，找到了vinverse，试试确实有用而且很快
想问下这个滤镜对画面的有没有伤害？

a4840639

之前讨论过这个问题
理论上是影响了细节，但是基本看不出

dgwxx

只要是deinterlace肯定损伤细节，但是vinverse基本控制在看不出差别的水平上。
我一般只用vinverse处理黑/白fade。

diseac

想问下这个滤镜对画面的有没有伤害？
arashi 发表于 2009-12-14 13:17

不会用则有，会用则基本没有。

之前讨论过这个问题
理论上是影响了细节，但是基本看不出
a4840639 发表于 2009-12-14 13:45

对不起反驳您一句，一般情况下仔细看可以看的出。
特别是在暗部较多的场景，在一些特殊的情况下，一眼就能看出不同。

我一般只用vinverse处理黑/白fade。
dgwxx 发表于 2009-12-14 13:54

fade处奇偶场差别比较大时，vinverse也会遗留交错的～


总的来说，vinverse可以直接挂到逐行的场景上，基本上影响不大，但对细节的影响是肯定的。
我就曾经因为vinverse而引起了debanding的麻烦。
所以我觉得vinverse需要一个交错判断，而不是无差别地应用到逐行帧上。
比如： conditionalfilter(last,vinverse,last,"IsCombedTIVTC(1)","==","true")

akiduki

回到楼主的问题来 既然大部分已经去了
只是部分细节仍然没杀干净 不妨考虑改造下anibin的destripe呢

arashi

回复 5# akiduki

1. function Destripe(clip clip, int "hh", int "rt", int "sft1", int "sft2", int "addb", int "mode") {
   
2.   addb = default(addb, 0)
   
3.   mode = default(mode, 1)
   
4. 
   
5.   Assert(hh>=1 && hh<=2048,"hhは1～2048")
   
6.   Assert(rt>=1 && rt<=64,"rtは1～64")
   
7.   Assert(sft1>=(-rt*4) && sft1<=(rt*4),"sft1範囲エラー")
   
8.   Assert(sft2>=(-rt*4) && sft2<=(rt*4),"sft2範囲エラー")
   
9.   Assert(addb>=0 && addb<=256 && (addb%2)==0,"addbは0～256の偶数")
   
10.   Assert(mode>=-158 && mode<=100, "modeは-158～100")
    
11. 
    
12.   w = clip.width()
    
13.   c = ((addb == 0) ? clip : clip.AddBorders(0, 0, 0, addb)).Separatefields()
    
14.   ve = c.SelectEven()
    
15.   vo = c.SelectOdd()
    
16.   ve = (mode == 0) ? ve.CullBicubicResize(w, hh, scale=rt, phase=-rt + sft1) : (
    
17.      \ (mode == 1) ? ve.CullSpline36Resize(w, hh, scale=rt, phase=-rt + sft1) : (
    
18.      \ ve.blur(0, -(float(mode) / 100.0)).CullSpline36Resize(w, hh, scale=rt, phase=-rt + sft1)))
    
19.   vo = (mode == 0) ? vo.CullBicubicResize(w, hh, scale=rt, phase=-rt + sft2) : (
    
20.      \ (mode == 1) ? vo.CullSpline36Resize(w, hh, scale=rt, phase=-rt + sft2) : (
    
21.      \ vo.blur(0, -(float(mode) / 100.0)).CullSpline36Resize(w, hh, scale=rt, phase=-rt + sft2)))
    
22.   return Interleave(ve, vo).Weave()
    
23. }

复制代码

日文只略懂一点点，
请问这phase的sft1和sft2是做什么用的，我看到日志里旧版里Addborder出现了，为何addborder不是很明白

dgwxx

翻墙看了一些作者写的资料，发现vinverse和destripe的出发点还是不同的。后者主要针对劣质upconv所造成的线条崩坏。
比如，带交错的720i图像以场为单位进行upconv，提升到1080i之后，线条会产生如下劣化现象：

（原作者制图，转载自http://anibin.blogspot.com/2008/01/blog-post_14.html）
好多非原生1080制作的动画经过upconv之后都成了这个样子。destripe的出发点是解决这个问题，主要用途应该是从录像出来的1440*1080i的TS压成720p RAW的过程中。今天比较晚了，又是在Mac上，所以没有具体进行测试，所以太具体的东西还没办法说。明天上午试过之后再说吧。

dgwxx

实验了一下，Destripe不具有deinterlace的效果，需要配合IVTC使用。
这个脚本+插件的目的是将纵向分辨率回复到upconv以前的状态。正好手头有FAIRY TAIL第一话的TS，就拿它来做实验。这个片子制作时是864*486，然后在交错状态以场为单位upconv到1440*1080i。结果就造成了几乎所有帧看起来都是交错的糟糕状态。
下面这张图是IVTC之后的画面（因为几乎每帧都是i，所以这个片并不能被正确地自动IVTC。所以我从若干废帧中找了一帧正确IVTC的作为例子）。
原始图片尺寸太大，只截取有代表性的一部分。图片比较大，推荐您点击图片，在新窗口中打开之后观看原图。

然后使用Destripe作者推荐的486参数将分辨率降到1440*486（这个过程是在YUY2空间完成的，因为拆场后纵向分辨率变成了243）。

Destripe(243, 8, 3, 1)

lanczosresize(864,486)
这个大概就是upconv以前的原始画面了。

akiduki

回复 7# dgwxx
嗯 没错 但你看楼主的情况是deint之后的残留交错
deint本身也是一种upsampling的过程
所以如果把deint抽象成upsampling过程的话，destripe的作用也或许有用

另外昨天试了下vinverse，觉得如果对已完美deint的场景使用vinverse，线条反而会劣化的（默认参数），我把sharpening和调节pixel改变amount的参数调低到默认的一半仍能观测到明显的劣化...
所以vinverse最后还是分段观察后决定是否使用，而不是一概而论。

dgwxx

回复 9# akiduki
恩，这么做应该是比较合理的。不过，秋月能把劣化的截图贴出来么。我之前好像没怎么观察到这么严重的劣化呢……
我一般都是挑出fade/crossfade的地方分段单独用vinverse。

此外看了作者的帖子还真有不小的震撼呢-v-
原来动画中基本没有FULL HD的，比较好的是1280的，最好的是1440的。原来野球娘的BD是SD upconv上去的，新EVA的BD也是1280的，而轻音竟然是1280的。原来GUIN是1280的，原来新钢炼是960*540的……NARUTO的某个ED竟然是FULL HD的……
本来打算下装甲骑兵剧场版的BD，结果貌似不怎么样，就取消掉了-v-

这参差不齐的还真是初级阶段……

a4840639

回复  akiduki
恩，这么做应该是比较合理的。不过，秋月能把劣化的截图贴出来么。我之前好像没怎么观察到 ...
dgwxx 发表于 2009-12-17 11:02

装甲骑兵这个剧场版我快下完了
记得那个blog上也有分析这个片子的文章，说是原先OVA的部分是SD的，新加的部分在720P左右，因为我没有下完，随便挑了一部分看了下感觉符合实际情况，整个片子加了很重的film grain（我倒是挺喜欢这东西的）

其实要大致判断480 540和720还是挺简单的
我把SAC，MF，DTB的FullHD截图resize到540再re回去，线条损失很小（细节损失挺大的，感觉是我那看图软件的算法问题），但是我把Planetes的FullHD图这么搞的话就能明显看出线条的损失

对于原生分辨率大于720P的东西这招似乎不大管用，反正我在真人片上试了下resize到720P再弄回去，感觉效果很不明显

akiduki

回复 10# dgwxx
大家都是初级阶段
只有米帝是完整状态XD