版面规则
提问时请注意:尽量详细描述操作过程、AVS脚本内容等,最好能写出片名,只贴图有时无法看出问题原因。
提示:发布原创内容请尽量使用附件上传。使用网盘会出现过期失效的问题,请注意。
头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

LumaDBLite v0.6 - 16bit版LumaDB高速Y平面debanding脚本

LumaDB的16-bit版本,俗称“撸马碉堡了”,和GrainFactoryLite一样输入输出都可以是8bit或者16bit的,靠"lsb"与"lsb_in"参数控制。

一些注意事项:
0. 因為16-bit處理非常耗內存,腳本開始請加上SetMemoryMax(1024),否則因為內存限制,速度會非常非常慢,尤其是分辨率高的時候(感謝304提出這個“非常慢”的問題= =)
1. 与GrainFactoryLite一样去掉了g*tex,
2. 同上g*const与temp_avg控制的噪点动态性改成用g*soft来控制,大于等于100时为静态噪声,
3. 与LumaDB不同的是默认的噪点是动态的,对debanding来说这样其实好些。
4. 自定义的"dither"和"grain"也不限定是8bit或者16bit,可以用d_lsb/d_lsb_in以及g_lsb/g_lsb_in控制(其实本来想做成只接受16bit自定义滤镜的,看了下连flash3kyuu_deband这种神器也只能输出16bit而不能输入16bit(扯蛋,很快就要有了……),所以还是加入8bit支持了……)
5. 原来的LumaDB如果自定义dither或者grain为"none"的时候dither或者grain过程为无处理,现在改成了"nop"或者"nop()",其实以前LumaDB就想这样用内置函数nop的,不过我个人习惯是不太喜欢在函数里用太多last处理,因为函数会比较乱囧,所以即使现在也不是当作last之后nop()而是直接比较字符串,所以请不要写成"nop( )"(加了空格)这样的形式。
► 显示剧情透露 用法举例:
► 显示剧情透露 所需外部插件
Download:

LumaDBL-0.6.7z(仅LumaDBLite.avsi与GrainFactoryLite):
MediaFirenmm备份

LumaDBL-0.2+Requirements.7z(包括Requirements里的其他滤镜):
MediaFirenmm备份
上次由 06_taro 在 2012-03-14 20:37,总共编辑 7 次。
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。
头像
-o-o-304-o-o-
超级版主
帖子: 640
注册时间: 2010-10-10 20:00
来自: US
联系: 网站

Re: LumaDBLite v0.1 - 16bit版LumaDB高速Y平面debanding脚本

拜谢taro大
► 显示剧情透露 En Taro 06!Taro Pie NC Fanclub project始动!聊天用Q群开放中
► 显示剧情透露 胸中有万言,退敌无一策,是谓书生误国"
► 显示剧情透露 前辈们的信念
► 显示剧情透露 妇联招新广告,走过路过可以看看撒
► 显示剧情透露 香芋派,后期菊苣们的一致选择
► 显示剧情透露 众菊苣喜评香芋派
► 显示剧情透露 聊天用工具
头像
ikamusume
帖子: 77
注册时间: 2011-03-02 23:13

Re: LumaDBLite v0.1 - 16bit版LumaDB高速Y平面debanding脚本

問問taro大 其他例子也可以 8bit輸入8bit輸出麼 {:cat_18}
头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

Re: LumaDBLite v0.1 - 16bit版LumaDB高速Y平面debanding脚本

是的,凡是有lsb=false就是8bit输出,凡是有lsb_in就是8bit输入。至于d/g_lsb和d/g_lsb_in只是控制自定义的dither和grain滤镜的输入输出bit depth,与全局输入输出的bit depth无关。

譬如我用

代码: 全选

LumaDBL(lsb=false, lsb_in=false, dither="GradFun3(lsb=true, lsb_in=true)", d_lsb=true, d_lsb_in=true, grain="Dither_add_grain16(lsb_in=true)", g_lsb=true, g_lsb_in=true)
尽管内部自定义的dither和grain都是16bit输入输出,LumaDBL的输入输出仍然是8bit的

反之如果

代码: 全选

LumaDBL(lsb=true, lsb_in=true, dither="GradFun3(lsb=false, lsb=false)", d_lsb=false, d_lsb_in=false, grain="AddGrainC()", g_lsb=false, g_lsb_in=false)
尽管内部自定义的dither和grain都是8bit输入输出,LumaDBL的输入输出仍然是16bit的。

不过使用自定义8bit滤镜来代替LumaDBL内置dither/grain的做法并不推荐,尤其是grain最好别用8bit的自定义滤镜,因为LumaDBL内部数据传递时,输入的如果是16bit则保持不变,如果是8bit则先转成16bit,然後在16bit下做dither和grain处理,而输入->dither->grain整个过程中都没有down8的步骤,从而保证内置dither和grain效果的最大化。整个过程内部只有生成mask的过程是8bit的,因为mask没有16bit的必要(数字图像处理的角度上讲高频数据容易影响mask的准确性及作用,因此一般这里的mask都要经过blur来做低通处理,而16bit再blur一下和8bit基本上没有什么区别,所以mask没有16bit的必要),而将mask用到最后merge时仍然是16bit的。但是如果自定义的grain滤镜是8bit输入输出的话,dither之后的结果会先down8,做完grain滤镜后再up16,这样之前16bit精度的dither效果就损失了。嘛如果喂给LumaDBL的就是8bit,dither是自定义8bit处理,grain也是8bit处理就无所谓了,不过那样的话为了速度还不如用LumaDB呢……

至于为什么要有d/g_lsb和d/g_lsb_in,主要是由于LumaDBL没法智能判断自定义的dither和grain到底是8bit还是16bit的处理,所以要手动设定,而不是用来对LumaDBL本身输入输出的bit depth作影响的。实际上正常使用下靠内置d/g而不用自定义d/g的话就没这问题了。
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。
头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

Re: LumaDBLite v0.2 - 16bit版LumaDB高速Y平面debanding脚本

0.2,"g*soft"的type定义修正,原来错误地把int写成了bool囧……
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。
头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

Re: LumaDBLite v0.6 - 16bit版LumaDB高速Y平面debanding脚本

0.6,增加自定义mclip,支持Chroma处理,当lsb=false时最终dither down方案略调整,增加一堆参数来调整这个dither down过程,反正不喜欢的可以自定义ditherC(本来很多人说LumaDBL效果不如LumaDB,其实主要是16-bit下做完的处理dither回8-bit预览时dither down的过程把效果都毁掉了,另外就是GrainFL的参数和GrainFactory3mod是略有区别的)
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。

回到 “AviSynth”