再谈谈动画片的全自动IVTC

diseac

前段时间因IVTC的问题发表了这个帖子（http://www.dgwxx.net/nmmbbs/thread-628-1-1.html），经dgwxx的帮助初步总结出一点经验。我的目的是节约DVDRIP的制作时间，用一码通、全自动的AVS脚本来完成影片的IVTC工作，并使结果能够比较令人满意。因此我想再和大家讨论一下我最近的研究发现。这里我只针对动画片。

TIVTC是个相当不错的IVTC插件，但经过测试，我认为TIVTC在默认设置下有以下的问题：
1、在交错比较微弱(比如even=#000000、odd=#111111)的情况下很难检出interlace，这个问题经常出现在画面淡出淡入的时候。
2、在渐变切换场景的时候，由于不是纯3:2pull down了，会造成interlace的遗留。(我在上一个帖子里提出的问题)
3、在渐变切换场景的时候，如果是由单一色彩向3:2pull down片源渐变（即淡出淡入），这种情况下，由于理论上无法进行场匹配（前后祯由于渐变造成亮度不同导致匹配成功也会有交错），所以会造成大量的interlace遗留。
4、偶尔会发生莫名奇妙的interlace检出失败，画面上明明有很明显的interlace，但TIVTC就是不肯调用后处理。这种情况多发生于非渐变场景切换。

我认为，为动画片做IVTC，主要的难点在于上面提到的2和3。解决的方法一是调整TIVTC的参数以提高精度，二是使用TIVTC的cilp2调用其他函数来使解交错后的画片看起来尽量好一些。

首先来说说TIVTC的精度问题吧。控制TIVTC精度的参数主要有下面6个：
mode = [1] （0-7）场匹配模式，按照默认设置我觉得就比较好了。
slow = [1]  (0-2)  (旧版本是true/false) 这个参数决定TIVTC调用什么函数进行场匹配。2是最慢的也是匹配成功率最高的。手册上这么讲，但是我也没实际发现这3个选项之间有什么不同。
blockx = [16] 数值必须是2的正整数次方，最小值4，最大值2048。作用是设置一个区块的宽度，配合MI参数使用。
blocky = [16] 同上，高度。
MI = [80] 在区块中有多少象素被判定为交错则进行后处理，默认设置下是256个象素中有80个交错就进行后处理。
cthresh = [9] (-1-255) 检测强度，与blockx/blocky/MI的检测方式不同，取5个相邻象素并将cthresh的值代入计算，当满足条件后即判定为交错。这个参数更模糊一些，但硬度要比blockx/blocky/MI来的大。

经过一些测试，我发现，将cthresh设置为8的时候可以基本解决4号问题。设置为2（2比8强度大）可以基本解决1-3号问题，但会造成更多的好祯被误判为交错。特别是在有文字的地方，而且特别是边框式样的文字。
slow一般我都设置为2，虽然我没去看源代码。相信手册吧。blockx/blocky/MI这3个参数一开始我还动一动，后来发现越动越不好使，干脆就保持默认了。
除上面6个参数外，tfm还有一个PP参数（ PP=[6] (0-7) ），这个参数和精度控制无关，它控制的是tfm进行解交错的方式。由于我是用clip2来进行解交错，所以这里用不到它。但是根据手册上说，当PP>1时，tfm会将判定为交错的整个祯送给外部函数，当PP>=5时，tfm会将祯内有交错的象素送给外部函数。根据我的经验，基于运动的解交错会造成动画片的大面积画面崩坏，所以这里PP还是设置为2比较保险。

因此，我的设置为：

1. tfm(slow=2,pp=2,cthresh=2,clip2=***)

复制代码

接下来来说一下后处理。上面我在tfm里用clip2调用了外部的deinterlace函数，那么到底用什么插件来做这个解交错？我想可能每个人的习惯和喜好都不同。我认为TIVTC的交错遗留主要出现在前面提到的2号和3号问题上，也就是渐变中的交错，于是我们有2种方式可以选择：一是保留一个场进行插值，二是奇偶场透明混合。
插值法的优点是不会造成重影，缺点是画面比较难看；混合法的缺点是有重影，但效果比插值好一些。由于我打算解决的是2号和3号问题，也就是渐变产生的交错，所以我觉得用混合法比较好一些。
首先，很多渐变场景动态都不大，不会产生严重的重影，最多也就是让画面模糊些。其次，这种方法能够减少一些TIVTC误判交错带来的损伤。而且，反正渐变也是2个层混在一起，干脆就让它们混合的更强些好了。

这里我使用的插件是TDeint，个人感觉这个插件做的奇偶混合比较好看一些。
由于前面的tfm已经挑出交错祯了，所以在TDeint无须再考虑精度问题。那么下面几个参数需要重点研究。
mthreshL： luma上的运动检测强度，实际上基于运动检测的解交错效果还是不错的，因为这种方法不会对画面中非交错的部分产生损伤，在真人影片中效果不错，在动画片中经常会造成大面积的画面崩坏，因此我设置mthreshL=0关闭它。
mthreshC：同上，chroma。
type：TDeint的解交错方式。
type=0：立方插值法，速度最快效果最烂。
type=1：modified ELA interpolation （不知道是什么意思，但是手册中推荐用这种方法为动画片做解交错）
type=2：中心插值法，是TDeint的默认值，可以由sharp参数控制锐化强度。
type=3：modified ELA-2 interpolation  （ELA的2号算法？手册中同样为动画推荐这个设置）
type=4：透明混合法。
type=5：双向混合法。我理解为向前后寻找一个质量比较好的或者是非交错的祯来进行混合，可能我理解的不对。但实际操作中我看到的画面确实是把其他的祯混进来了。
另外，没有基于运动的混合法，会造成一些锯齿，所以我在TDeint后面加了一个AAA。如果画面过于模糊，还可以再锐化一下。

根据上面的理解，我的参数设置为：

1. dei=tdeint(mthreshL=0,mthreshC=0,full=true,sharp=false,type=5,hints=false)
   
2. \.AAA()
   
3. tfm(slow=2,pp=2,cthresh=2,clip2=dei)
   
4. tdecimate(mode=1)

复制代码

和上一个帖子里总结出的代码有很大改动。经过我的观察和测试，效果还算是不错。但是无论怎样，经过deinterlace处理的渐变画面都是30p的，经过tdecimate的删祯会让画面有跳动感。而且TIVTC的误判太多也是问题。

这里我只总结了一些关于TIVTC的方案，我想方法肯定不止这一种，希望各位朋友看了我的帖子能帮我做一些改进，让一码通、全自动的AVS脚本代替耗时费力的手动IVTC，让制作DVDRIP变成一件轻松快乐的事情是我的初衷。期待您们的意见和建议。

diseac

附一张图：基于运动的解交错造成大面积画面崩坏
tdeint(mthreshL=6,mthreshC=6,full=true,type=5)

dgwxx

不鸣则已，一鸣惊人，一出手就是好文！基本上可以相当于TIVTC的入门教程了。原创+精华+高亮。

我用TIVTC压了也有几百小时了，也多少积累了一些经验。楼主花费精力做实验、码长文，为了表示对楼主钻研精神的尊敬，我也说两句。
TIVTC的场匹配精度是我用过的所有自动IVTC插件中最高的，比当年Decomb高过不知道多少，“能正常通过匹配输出的走PP”的情况大为减少。只要不出现字幕、渐变（无论是cross fade还是white/black fade），正确率基本可以保证99%往上（正确=输出正确的匹配结果，既没有做pp、也没有放过交错）。
但是就像楼主所说的，TIVTC在以下情况中会显得比较脆弱：
1.两种Fade（上面提到的交叉渐变和黑/白渐变）。
  1.1 交叉渐变。两个pulldown之后带交错的场景交叉fade。
  1.2 黑白渐变。pulldown之后的画面通过30i的方式逐渐变暗/亮，直到黑色/白色，反之亦然。（先渐变之后再pulldown的情况因为可以通过IVTC解决，不在讨论范围之内。）
2.字幕。字幕又分三种情况：
  2.1 pulldown画面上叠加30i的渐变字幕。
  2.2 pulldown画面上叠加30i的普通字幕。字幕出现在一帧之类，消失也在一帧之内，但是因为30i，出现的时候会分两个场，于是就产生了交错。
  2.3 画面上叠加黑边白字的字幕。
（pulldown画面叠加30i滚动字幕因为不是IVTC能解决的，所以不在讨论范围之类）

1.2情况和2.1大概可以归为一类，都是TIVTC容易错过的交错，就是说，TIVTC会直接输出交错的帧，不做PP。
1.1和2.2的情况IVTC则回很敏感地捕捉到，走PP。在1.1情况中，因为画面整体运动感较大，走PP不易察觉。但是在2.2的情框中，字幕出现和消失的一瞬间都会抖动一下，非常碍眼。
2.3的情况就更糟糕了，常常会引起TIVTC的误判，一部分帧走了PP，另一部分帧却没有走PP，字幕显示期间都会不断抖动，非常难看。

以上情况都是比较极端的情况，如果只靠自动判断，是不可能解决的（一套参数，不可能适应所有画面）。所以如果想要比较完美地处理OP/ED或者渐变字幕的话，可以通过分析日志+手写ovr文件的形式来处理。
这几天有些忙，过一阵有时间了写一篇日志分析+手写ovr的文章。

bomber1984

个人一个比较不入流的方法

在用一套tivtc参数压一遍的时候顺带上大虾的检测交错的插件

然后压好后看那个文本如果遇到连续好几帧有交错的情况再在相应的地方dinterlace并且重压一遍

如果只是没几帧且不连续的话就算了，毕竟是自动的

毕竟1帧只在画面出现1/24秒对于观众来说可能根本没有发现，只有一些挑剔的ripper才会留意这些

还有说到上面几种情况的tivtc难以处理的，如果楼主有心的话可以去doom9试试animeivtc。

最后感谢楼主的发帖，在这里你也发了不少帖子了，我个人也全部看了一遍你的帖子，发现楼主是那种能从浅入深钻研的很透的人，很高兴能有这样一篇帖子，说实话做了不算短时间的rip有些还是似懂非懂看了你这些帖子后又明白些了。谢谢！！！

[ 本帖最后由 bomber1984 于 2008-7-19 02:58 编辑 ]

diseac

谢谢大家的鼓励！

dgwxx说的关于字幕的问题，有些是我没想到的，谢谢你让我又学到了新东西。非常期待dgwxx关于日志分析+手写ovr的文章！

正如dgwxx所说，一套参数，不可能适应所有画面。很多动画片的OP/ED，没办法用一码通的方式来解决，所以很多时候我只好将OP/ED与正片分开做，这样才能排除文字交错、30p/30i滚动字幕带来的问题（正片中没有字的情况下）。对于1.5分钟的OP/ED来说，手工制作一下也不太麻烦，可对于20多分钟的正片来说，全手工就很费时间了。

bomber1984说的方法，其实也是用程序自动地去检测交错，只要检测工具的精度足够，剩下的就只是用什么插件做解交错的问题而已了。

我看了一下animeIVTC，根据它的手册，我发现以下设置可以制作标准的30i→24p的IVTC
AnimeIVTC(mode=1,aa=0,precision=3)
从下面2行源代码可以看出animeIVTC的工作原理：
1、ht = (precision==3) ? i.tfm(clip2=i.tdeint(2,edeint=i.nnedi(-2),emask=i.tmm(1)),slow=2) : ..................
2、(mode == 1 || mode == 3 || mode == 6) ? ht : ..................
看到这里会发现，animeIVTC只是用了tfm的clip2、slow，以及tdeint的edeint、emask这些参数，并没有更多地做精度上的检测，然后是下面的Kill combing
dec1=todecim.vinverse()
dec2=todecim.vinverseD()
dec = (killcomb==1) ? dec1 : (killcomb==2) ? dec2
在animeIVTC的整合包里，我没发现vinverse的手册。而且这个插件的使用方法我google不到，所以不太了解vinverse的具体工作原理，只能大概认为它是一个deinterlece滤镜。
实际使用animeIVTC的效果的确不佳，在渐变的场景下，仍然存在大量的交错残留。我觉得animeIVTC更象是一个为动画片专门设计的用来处理各种复杂情况的脚本集合，但是在纯IVTC方面个人感觉它并不理想。

[ 本帖最后由 diseac 于 2008-7-19 10:38 编辑 ]

bomber1984

# Vinverse: a small, but effective Function against (residual) combing, by Didée
# sstr: strength of contra sharpening
# amnt: change no pixel by more than this (default=255: unrestricted)
# uv  : chroma mode, as in MaskTools: 1=trash chroma, 2=pass chroma through, 3=process chroma

function VinverseD(clip clp, float "sstr", int "amnt", int "uv")
{
uv   = default(uv,3)
sstr = default(sstr,2.7)
amnt = default(amnt,255)
uv2  = (uv==2) ? 1 : uv
STR  = string(sstr)
AMN  = string(amnt)
vblur  = clp.mt_Convolution("1","50 99 50",U=uv,V=uv)
vblurD = mt_MakeDiff(clp,vblur,U=uv2,V=uv2)
Vshrp  = mt_LutXY(vblur,vblur.mt_Convolution("1","1 4 6 4 1",U=uv2,V=uv2),expr="x x y - "+STR+" * +",U=uv2,V=uv2)
VshrpD = mt_MakeDiff(Vshrp,vblur,U=uv2,V=uv2)
VlimD  = mt_LutXY(VshrpD,VblurD,expr="x 128 - y 128 - * 0 < x 128 - abs y 128 - abs < x y ? 128 - 0.25 * 128 + x 128 - abs y 128 - abs < x y ? ?",U=uv2,V=uv2)
mt_AddDiff(Vblur,VlimD,U=uv,V=uv)
(amnt>254) ? last : (amnt==0) ? clp : mt_LutXY(clp,last,expr="x "+AMN+" + y < x "+AMN+" + x "+AMN+" - y > x "+AMN+" - y ? ?",U=uv,V=uv)
return(last)
}

希望能对楼主有帮助，记得doom9上好像都有

[ 本帖最后由 bomber1984 于 2008-7-20 10:57 编辑 ]

diseac

谢谢bomber1984！
不过AnimeIVTC的整合包里提供的是一个Vinverse.dll文件。
Doom9上有人说Vinverse.dll实际上就是这个脚本的插件版，从代码来看，它是借助masktools来解交错的。masktools我没研究过，很多大型的AVS脚本都用到了masktools，看来我得去看一下这个插件了。
另外我观察到，借助masktools进行3D解交错，貌似不会出现2楼那种现象。——这个只是猜测

diseac

今天找到一个带有很细小笔画文字的片子，正好发张图上来。

测试参数：tfm(pp=1,slow=2,debug=true,display=true,micout=2,cthresh=1)

注意看TIVTC标出来的小方框，在那个“集”字上面。这个字的笔画看起来是不是很象交错？
可是这张画面的MIC只有81（cthresh=1时），只比MI的80大了1点。另外，在整段影片中，被误判为交错的祯MIC值也基本都在90以内，而且方框无一例外地都标在细小笔画的文字上。

这种情况是TIVTC挑剔文字的情况之一，另外还有其他情况，在遇到合适的片子时我会发图上来。

akiduki

呃...大虾你这论坛的代码对ff支持的不好，我又难得开次ie（其实很多时候都在linux下－ｖ－
diseac大说不太清楚TDeint下mode1和mode3用得ELA是什么，其实ELA是Edge-based Line Average的缩写，ELA interpolation是一种常用的非基于运动补偿的（non-motion compensated）解交错算法，关于技术细节，我直接引用附件中的一篇文章的描述了：

Edge-based algorithms provide the best results within the class of intra field deinterlacing methods. These methods try to find the edge direction in the missing pixel’s position and then they interpolate the missing pixels along that edge. Edge-based line averaging (ELA) uses three pixels in the upper and lower lines to detect the edge direction and perform directional interpolation. Modified ELA uses five pixels in the upper and lower lines to detect five edge directions. This method classifies the edges as dominant or non-dominant. It then uses directional interpolation in dominant edges and vertical interpolation in non-dominant edges. Enhanced ELA uses the same algorithm as the modified ELA to detect the dominant edges. Then it uses the median of the directional interpolated pixel and corresponding pixels in the upper and lower lines to prevent the occurrence of bursting pixels.

其实看到这篇文章也是因为很偶然的机会，当时读tdeint的文档发现ela这个术语，和diseac大一样我也不清楚这是啥，doom9的帖子浩如烟海，光去找一个这个显然不划算，我就想起了学校ieee的数据库（没办法，工科学生又搞视频这行的一有问题我先想到的总是ieee的数据库－ｖ－
然后很幸运的找到了一系列关于deinterlaceing的文章，其中有很多与ELA以及其他一些motion compensated的算法（bi-directional, cubic, blend, and etc.,）相关的介绍和研究，附近里面是我现在机子里还保留着的几篇，不过大家注意别乱分享和外发就是了，毕竟学校买的ieee数据库要是抓到是我乱发的这版权问题的腰我可不想再撞第二次了

另外diseac大在楼上提出的这问题，我昨晚压hidamariX365的第一卷，这种密集横向细线条（包括头发、文字、眼睛、甚至点状方格的背景）造成mic略大于mi导致被误判为交错的情况非常多，多的原因我觉得有两个，1是这种场景出现的次数多频率大，2是hidamari中经常使用定格的表现手法，比如tfm输出文件中的这一段：

1. 
   
2. #   30901 (85)
   
3. #   30902 (81)
   
4. #   30903 (85)
   
5. #   30904 (82)
   
6. #   30905 (84)
   
7. #   30906 (85)
   
8. #   30907 (86)
   
9. #   30908 (84)
   
10. #   30909 (84)
    
11. #   30911 (84)
    
12. .....
    
13. .....
    
14. .....
    
15. .....
    
16. #   31015 (82)
    
17. #   31016 (94)
    
18. #   31017 (87)
    
19. #   31018 (89)
    
20. #   31019 (89)
    
21. #   31020 (89)
    

复制代码

其实就是ゆの和宮子头靠着桌子上各发了次呆

1. 
   
2. tfm(d2v=source, pp=1, mode=3, slow=2, chroma=true, debug=true, display=true)
   

复制代码

其实要怪就怪大沼心和新房这两人狼狈为奸－ｖ－
下面还有几张样图，供参考
吉野屋老师的头发：

这个多考眼力啊...

还有像这种场景也容易被判要deinterlaceing...在vdm里我把它放大400%看似乎也没看到交错呢...

------------
又做了些试验，hidamari真是个做ivtc试验的好片子...不过我倒是被搞得越来越扭曲了
片子整体情况其实还不错，也就是说用默认的tfm设置也不会有遗漏的需要pp的帧（第二话中也就op的几个字幕需要过pp），但问题就在被误检出的非交错帧太多了...如果不把交错帧剔出来直接让他过pp我用tfm自带的或者tdeint都会让画面模糊，不过我也没继续在这个点上研究，因为我觉得重点还是应当把不应过pp的帧“自动”挑出来而不是在deinterlacing上想亡羊补牢的办法。
特别是用diseac大的设置，把判定的门槛降低后，新房风格的背景能让每帧都要过pp 不过diseac大的设置针对的问题似乎和hidamari中我遇到的问题正好是两个极端－ｖ－
我也尝试了用blockx/y 加大sample的window以及更改mi参数，但就如同diseac大所言，拆东墙补西墙...要么满屏小方框，要么漏真正要deinterlacing的交错帧...

我最后的办法是调大mi值到110，因为被误判的很多处于80-100附近，处于这个区域内的帧很密集...像Maxwell分布一样...但其实问题还没解决，究竟怎样才能全自动ivtc呢？

然后看着输出的log中还有被误判的帧，我又看不过去自己手写ovr了－ｖ－绕了一大圈回到了起点，傲娇啊傲娇

另，附近文章的title太长超过255个字符我写在这了，要的对应下载吧，希望能对diseac大和大虾有帮助
01261228- A Motion-Adaptive De-interlacing Method Using an Efficient Spatial and Temporal Interpolation
04263402- A Threshold-Based Deinterlacing Algorithm Using Motion Compensation and Directional Interpolation
01452784- Adaptive Denterlacing Algorithm Based on Motion Compensation
lncs4179-Improvement of Conventional Deinterlacing Methods with Extrema Detection and Interpolation

[ 本帖最后由 akiduki 于 2008-9-30 05:13 编辑 ]

chopper

依据TDeint的说明文档 给大大最后的代码精简一下

dei=tdeint(mthreshL=0,mthreshC=0,type=5)
\.AAA()
tfm(slow=2,pp=2,cthresh=2,clip2=dei)
tdecimate(mode=1)

另外发现以上设置压的真人影片效果很好 用不用\.AAA()感觉所谓 反正不用效果也还可以