Log in

View Full Version : [Neo] f3kdb


Pages : [1] 2 3 4 5

MeteorRain
27th June 2019, 18:12
Neo filters family is not to be confused with AviSynth-Neo. Neo filters family is not affiliated in any way with AviSynth-Neo.

[Neo] F3KDB → GitHub (https://github.com/HomeOfAviSynthPlusEvolution/neo_f3kdb)

F3kdb is a deband filter. It was originally written for AviUtl (author uncovered) and later ported to AviSynth (Original F3KDB) (https://forum.doom9.org//showthread.php?t=161411) by SAPikachu many years ago.

r5

* New dual synth wrapper platform update.

r2

* Add sample_mode 3 and 4.

r1

* Added AviSynth+ native high bit depth, based on 2.0 branch.
* Supporting YUV4xxP8/P10/P12/P14/P16 and I420.
* Dropped support for legacy AviSynth versions.

real.finder
27th June 2019, 22:23
:thanks:

any plan for float support?

Natty
27th June 2019, 22:43
thaaaaanks

real.finder
27th June 2019, 22:54
I think there are bugs

ColorBars(width=640, height=480, pixel_type="yv12")
F3KDB()

will give "Unsupported output depth (-1)" in both avs+ and old avs 2.6

with
F3KDB(output_depth=8)

it work, in both avs+ and old avs 2.6

MeteorRain
28th June 2019, 04:01
I see, should have initialized output-depth to be the same as input.

https://down.7086.in/f3kdb-2.1rc2.zip

Regarding floating support, I have no interests on that. Supporting float involves extensive coding that will come with minimum benefits.

For high precision processing, 16 bit should be good enough for most of the cases.

StvG
28th June 2019, 07:04
There is random "access violation writing 0x0000000000000000". Just used:ffvideosource(10-bit.video)
f3kdb()

MeteorRain
28th June 2019, 07:44
StvG: Thanks for the report.

Can you please do ffvideosource(10-bit.video).info and check what colorspace/width/height etc is?

Also are you on latest AviSynth+(2772)? Or an older version?

StvG
28th June 2019, 08:12
avs+ 2772 x64 used. Info (https://images2.imgbox.com/e1/c6/9xx4ukdN_o.png); error (https://images2.imgbox.com/72/80/FpvPA0kO_o.png) (trying to run three times in a row).

Edit: The behavior is the same with 8-bit video too.

MeteorRain
28th June 2019, 15:20
Reviewing the code I actually found an out of bounds array access issue. Will fix it and let you try again.

https://down.7086.in/f3kdb-2.1rc3.zip

Please let me know how it works for you.

StvG
28th June 2019, 18:08
Same behavior. (https://images2.imgbox.com/18/8a/oPtBlQbq_o.png)
Btw no crashes when f3kdb_*_sanitize* stuff (https://github.com/msg7086/flash3kyuu_deband/commit/0ad779c3c736647d97c4146195bc2c1e3e11a6eb) isn't removed but sometimes the speed is lower (~30%).

ChaosKing
28th June 2019, 18:35
only 64bit version seems to be affected, crashes also in 8 bit. 32bit version seems to run fine and is even faster in 16bit - 180fps vs 430fps :O

ffms2(dvd-source)
ConvertBits(16)
f3kdb()

Edit:
avsmeter confirmed the 8bit - 16bit huge fps gap. 16bit is more optimized?

MeteorRain
28th June 2019, 18:38
Oh 64 bit version, missed that. Let me check that part and see if I can find something.

Natty
28th June 2019, 19:59
only 64bit version seems to be affected, crashes also in 8 bit. 32bit version seems to run fine and is even faster in 16bit - 180fps vs 430fps :O

ffms2(dvd-source)
ConvertBits(16)
f3kdb()

Edit:
avsmeter confirmed the 8bit - 16bit huge fps gap. 16bit is more optimized?

convertbits(16)
f3kdb()

gives half green screen

example of 32 bit pls? and you mean 32 is faster than 16?

ChaosKing
28th June 2019, 20:23
32bit = x86 :-)

MeteorRain
28th June 2019, 22:06
but sometimes the speed is lower (~30%).
Seems to be an uninitialized multi-threading flag that caused random results (randomly mt / st).

MeteorRain
28th June 2019, 22:25
32bit version seems to run fine and is even faster in 16bit - 180fps vs 430fps :O

ffms2(dvd-source)
ConvertBits(16)
f3kdb()

Edit:
avsmeter confirmed the 8bit - 16bit huge fps gap. 16bit is more optimized?

Try (dither_algo = 1). 16bit doesn't need dithering and thus is supposedly faster.

Natty
28th June 2019, 23:10
Try (dither_algo = 1). 16bit doesn't need dithering and thus is supposedly faster.

16bit only supports dither_algo=3 according to docs.
https://f3kdb.readthedocs.io/en/stable/usage.html#cmdoption-arg-dither_algo
is this correct? or is there some other docs for your ported version?
and can you enable dither_algo=2 for 16bit? :thanks:

MeteorRain
28th June 2019, 23:16
https://down.7086.in/f3kdb-2.1rc4.zip

Fixed an undefined behavior in C++.
Fixed mt flag not properly set.

MeteorRain
28th June 2019, 23:22
16bit only supports dither_algo=3 according to docs.
https://f3kdb.readthedocs.io/en/stable/usage.html#cmdoption-arg-dither_algo
is this correct? or is there some other docs for your ported version?
and can you enable dither_algo=2 for 16bit? :thanks:

Internal processing was under 16 bit, so for 16 bit output no dithering is needed. This is what I understood by reading the code, please correct me if I was wrong.

"This parameter is ignored if output_depth = 16." is what the doc says. The "ignore" doesn't mean it uses the default, this means it's not needed.

ChaosKing
28th June 2019, 23:47
https://down.7086.in/f3kdb-2.1rc4.zip

Fixed an undefined behavior in C++.
Fixed mt flag not properly set.

x64 seems to work now. It is about 22% faster than the x86 version.

Natty
28th June 2019, 23:55
Internal processing was under 16 bit, so for 16 bit output no dithering is needed. This is what I understood by reading the code, please correct me if I was wrong.

"This parameter is ignored if output_depth = 16." is what the doc says. The "ignore" doesn't mean it uses the default, this means it's not needed.

https://f3kdb.readthedocs.io/en/stable/usage.html#cmdoption-arg-output_depth

till now i thought it will apply floyd dithering as it is default mode of f3kdb in 16bit output. i am confused now. :confused:

that means specifying dither_algo is waste then as f3kdb will ignore it

MeteorRain
29th June 2019, 00:34
Natty:
Dither is only used on downgrading bit depth, i.e. from internal precision (16 bit) down to output bit depth (14 bit for example).
If you want 16 bit output, it just gives out the original result, without touching it at all.

Natty
29th June 2019, 08:34
:thanks: understood

StvG
29th June 2019, 11:55
x64 seems to work now...

I have no crashes too.

Thanks for this version.

FranceBB
29th June 2019, 12:32
Original post (/showthread.php?t=161411)

Added AviSynth+ native high bit depth, based on 2.0 branch.
Supporting YUV4xxP8/P10/P12/P14/P16 and I420.
Dropped support for legacy AviSynth versions.


Hi,
I tried the new version of f3kdb and it works, however I noticed that as you introduced support for regular, planar high bit depth, you removed support for 16bit stacked and 16bit interleaved. I don't actually think this is the right thing to do as it will definitely break things in many other scripts that make use of f3kdb as a filter (dependency) and that were working in either 16bit stacked or 16bit interleaved.
f3kdb was working with basically two modes: input_mode=1 and input_mode=2. Mode 1 means 16bit stacked, while Mode 2 means 16bit interleaved.
I think that you are absolutely right to add support for regular, planar high bit depth, however you should not remove those two modes as they are really important for people relying on the old Avisynth 2.6.1 or for filters that use f3kdb as a sub-filter.


This is an example of what I noticed when I was trying to encode a documentary provided in Apple ProRes 10bit planar that still had banding in low light scenes anyway:

16bit interleaved (https://i.imgur.com/EMmGxwB.png) - 16bit stacked (https://i.imgur.com/AU9iA2P.png) - 10bit planar (https://i.imgur.com/TQwGyKc.jpg)

In this case there's no reason to use 16bit stacked or interleaved, but as I said, removing them will break support for many filters that rely on f3kdb as dependency and will also make life harder to those using Avisynth 2.6.1.

#10bit planar input, 8bit planar output works

video=FFVideoSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\IMN_190319_v2.mov")
audio=FFAudioSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\IMN_190319_v2.mov")
Audiook=MergeChannels(audio, audio, audio, audio)
AudioDub(video, audiook)

f3kdb(range=15, Y=70, Cb=40, Cr=40, grainY=0, grainC=0, sample_mode=2, blur_first=true, dynamic_grain=false, opt=3, mt=true, keep_tv_range=true, output_depth=8)


### ### ###
#10bit planar input -> 16bit planar -> 8bit planar output works

video=FFVideoSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\IMN_190319_v2.mov")
audio=FFAudioSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\IMN_190319_v2.mov")
Audiook=MergeChannels(audio, audio, audio, audio)
AudioDub(video, audiook)

ConvertBits(16)

f3kdb(range=15, Y=70, Cb=40, Cr=40, grainY=0, grainC=0, sample_mode=2, blur_first=true, dynamic_grain=false, opt=3, mt=true, keep_tv_range=true, output_depth=8)


### ### ###
#10bit planar input -> 16bit planar -> 16bit planar output works

video=FFVideoSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\IMN_190319_v2.mov")
audio=FFAudioSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\IMN_190319_v2.mov")
Audiook=MergeChannels(audio, audio, audio, audio)
AudioDub(video, audiook)

ConvertBits(16)

f3kdb(range=15, Y=70, Cb=40, Cr=40, grainY=0, grainC=0, sample_mode=2, blur_first=true, dynamic_grain=false, opt=3, mt=true, keep_tv_range=true, output_depth=8)


### ### ###
#10bit planar input -> 16bit planar ->16bit stacked -> 16bit stacked does not work
#f3kdb does not have a named argument "input mode"

video=FFVideoSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\IMN_190319_v2.mov")
audio=FFAudioSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\IMN_190319_v2.mov")
Audiook=MergeChannels(audio, audio, audio, audio)
AudioDub(video, audiook)

ConvertBits(16)
ConvertToStacked()

f3kdb(range=15, Y=70, Cb=40, Cr=40, grainY=0, grainC=0, sample_mode=2, blur_first=true, dynamic_grain=false, opt=3, mt=true, keep_tv_range=true, input_mode=1, input_depth=16, output_mode=1, output_depth=16)


### ### ###
#10bit planar input -> 16bit planar ->16bit interleaved -> 16bit interleaved does not work
#f3kdb does not have a named argument "input mode"

video=FFVideoSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\IMN_190319_v2.mov")
audio=FFAudioSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\IMN_190319_v2.mov")
Audiook=MergeChannels(audio, audio, audio, audio)
AudioDub(video, audiook)

ConvertBits(16)
ConvertToDoubleWidth()

f3kdb(range=15, Y=70, Cb=40, Cr=40, grainY=0, grainC=0, sample_mode=2, blur_first=true, dynamic_grain=false, opt=3, mt=true, keep_tv_range=true, input_mode=2, input_depth=16, output_mode=2, output_depth=16)

Natty
5th July 2019, 23:07
input depth, input mode and output mode dont work. only output depth works. I like it. just hope it works correctly internally. :p

MeteorRain
6th July 2019, 18:01
however you should not remove those two modes as they are really important for people relying on the old Avisynth 2.6.1 or for filters that use f3kdb as a sub-filter

The only thing that was done in 2.1 was to add high bit depth (and remove legacy stacked and interleave).

If you want to use legacy I/O, simply use the old version (2.0, 1.x, etc).

FranceBB
7th July 2019, 01:07
The only thing that was done in 2.1 was to add high bit depth (and remove legacy stacked and interleave).

If you want to use legacy I/O, simply use the old version (2.0, 1.x, etc).

I know, and having normal high bit depth is great, but I think you should put 16bit stacked and 16bit interleave back because, as I said, there are third party plugins that are calling f3kdb with input and output modes that are now deprecated.

Tl;dr I'm in favor of adding regular planar high bit depth, but I don't think that stacked and interleave support should be removed for compatibility reasons.

MeteorRain
7th July 2019, 09:03
I see your point. However having both format could cause confusion.

Suppose you are f3kdb'ing 8 bit input and asking for 16 bit output. Pre 2.1 output mode defaults to 1 = stacked, and now native YUV420P16. If we return stacked by default, it's confusing for normal usage. If we return native by default, it still breaks compatibility.

My recommendation is that you keep the old version auto loaded, and manually load the native version when needed, until all your existing scripts are converted.

Upgrading to native HBD is a pain process. All moving parts need to be replaced by the HBD version. In my case, that means DGSource, L-Smash-works, Delogo, f3kdb and the final step avs4x26x or whatever piper.

PR welcome, but I'm not going to spend time on reverting the code / adding smart or dumb condition checks to improve compatibility. Sorry.

real.finder
22nd July 2019, 18:24
is it possible to disable masking in F3KDB?

MeteorRain
23rd July 2019, 05:11
Can you be more precise? I'm not very familiar with the core part of f3kdb.

real.finder
23rd July 2019, 05:17
Can you be more precise? I'm not very familiar with the core part of f3kdb.

with

ImageSource("uonzj6V.png (http://i.imgur.com/uonzj6V.png)")
PointResize(720,480)
ConvertToYV12()
mt_merge(last,FlipHorizontal(),BlankClip(last,color = $FFFFFF).FadeIO(500))
f3kdb()
luma_histogram() (https://forum.doom9.org/showthread.php?t=161411)


you can see masking artifacts in the dividing line

edit: to make sure it's masking problem use f3kdb(grainy=0)

real.finder
24th July 2019, 15:22
There is no internal masking in f3kdb. The artifacts you see are resulted from how the reference pixels are selected by the algorithm. By using sample_mode=2 which selects pixels diagonally around the current pixel, the pixels above the dividing line and the pixels below the dividing line differ too much, hence the algorithm will return the original pixels instead of the blurred ones. By making the algorithm select pixels horizontally (let's call it sample_mode=0), the artifacts will go away.

https://i.postimg.cc/ctq0L8BB/Original.png (https://postimg.cc/ctq0L8BB) https://i.postimg.cc/9zTcNJc8/sample-mode-2.png (https://postimg.cc/9zTcNJc8) https://i.postimg.cc/ctQZg4Dy/sample-mode-0.png (https://postimg.cc/ctQZg4Dy)


aside from sample_mode=0 was removed in pre2, with sample_mode=0, grainy=0 the filter didn't do anything and still there are artifacts

edit: I think you had a modified version, it's better to chose 3 instead of 0

edit: adding mode 4 for vertical will be nice, and then the output of both can mixed later

real.finder
24th July 2019, 15:42
Sorry for the confusion. The sample_mode=0 was added by myself in my compiled f3kdb. The functionality is not the same as the old removed one. I only meant to demonstrate the result of selecting the reference pixels horizontally and I just arbitrarily assigned it to sample_mode=0 for distinguishing.

I already get it, no need to be sorry :) see my edit

real.finder
25th July 2019, 05:50
That's exactly what sample_mode=1 does.

ok, what about 3 for horizontal, and 4 for both but separated then mixed (like by simple merge (http://avisynth.nl/index.php/Merge) or something)

DJATOM
25th July 2019, 09:51
Guess you will have the same result with (if I understood your request right)
f3kdb(sample_mode=3)
TurnLeft()
f3kdb(sample_mode=3)
TurnRight()

real.finder
25th July 2019, 17:00
Guess you will have the same result with (if I understood your request right)
f3kdb(sample_mode=3)
TurnLeft()
f3kdb(sample_mode=3)
TurnRight()


for now there are no sample_mode=3, with sample_mode=1 it will work I think, but with more blur and slowness

ChaosKing
4th August 2019, 13:15
@MeteorRain The download link on the first page is not working.

MeteorRain
4th August 2019, 21:23
Fixed the link. But I'm planning to clean up the building system a little bit and then release a GA version.

Stereodude
5th August 2019, 16:56
GA version?

Is there any change we can talk you into integrating madshi's suggested improvements for it? https://forum.doom9.org/showthread.php?p=1652256#post1652256

MeteorRain
5th August 2019, 18:02
Stereodude, I'm not an algorithm guy and have no idea about the actual implementation. If there's an easy-to-integrate patch available I'd love to merge it in. Otherwise It'll be very hard for me to implement it.

I mainly took over the work to create an AVS+HBD compatible plugin and that's all I'm capable of doing.

Natty
6th August 2019, 02:09
:goodpost:

MeteorRain
19th August 2019, 02:53
FranceBB,

After a while of thinking, I believe it's possible to expose a legacy function where it assumes all input and output mode as interleaved (which is effectively the same as HBD), so in the case of referencing f3kdb from foreign scripts, simply changing the function name should do the work, if they were working under interleaved mode. For stacked mode, a conversion is mandatory.

# Proposal1
interleaved_output = interleaved_input.f3kdb_i(input_depth=10, output_depth=12)
stacked_output = stacked_input.ConvertFromStacked().ConvertToDoubleWidth().f3kdb_i(input_depth=10, output_depth=12).ConvertFromDoubleWidth().ConvertToStacked()

The other option is to compile and release a legacy version with function name changed. You keep both DLLs in the system until all legacy scripts move on.

# Proposal2
output = input.f3kdb_legacy(input_depth=10, input_mode=1, output_depth=12, output_mode=2)

Which do you all prefer? I can also do both.

Understanding the difficulties of moving from hacks to HBD, I'd like to reduce even just a bit of pain for you.

real.finder
19th August 2019, 07:51
MeteorRain, but you can do it like this
input_mode=0 mean no hacks (8 bit or HBD)
output_mode=3 mean HBD always

you can also add some check with input_mode > 0 and HBD ThrowError("f3kdb: you can't use input_mode > 0 with HBD")

edit: you can add things I add here https://forum.doom9.org/showthread.php?p=1881052#post1881052 (All or some of them) and of course without change the default settings (mean if you add sample_mode 3 and 4 the default will stay on 2 not like I set it to 4)

MeteorRain
19th August 2019, 13:54
Would it be better if I leave the mode conversion to a wrapper script and call it a day? I'm feeling that we should move on to HBD as fast as possible and not leaving that much legacy code in the code base.

By the way I didn't realize you made f3kdb_3. Do you think it's still necessary to add legacy modes and builds while your script can already deal with it?

Bottom line: I don't want to put modes back, but I'd like to have some sort of mechanism so that people would have no pain living with both version and use whatever version they want, until all plugins are overhauled.

real.finder
19th August 2019, 14:04
Would it be better if I leave the mode conversion to a wrapper script and call it a day? I'm feeling that we should move on to HBD as fast as possible and not leaving that much legacy code in the code base.

By the way I didn't realize you made f3kdb_3. Do you think it's still necessary to add legacy modes and builds while your script can already deal with it?

Bottom line: I don't want to put modes back, but I'd like to have some sort of mechanism so that people would have no pain living with both version and use whatever version they want, until all plugins are overhauled.

well, pinterf didn't remove the lsb from mvtools, even he didn't remove it from masktools (which no one use or even know)

there are some people still use even avs25 but that not important, avs+ plugins work with avs26

anyway I am with keeping lsb and other modes even if I will not use them, I am with you about move on to HBD as fast as possible and also with keep lsb and interleaved format

ChaosKing
19th August 2019, 15:21
well, pinterf didn't remove the lsb from mvtools, even he didn't remove it from masktools (which no one use or even know)

there are some people still use even avs25 but that not important, avs+ plugins work with avs26

anyway I am with keeping lsb and other modes even if I will not use them, I am with you about move on to HBD as fast as possible and also with keep lsb and interleaved format

There is also XP compatibility, but it doesn't mean it should be supported :devil:
Sometimes it's good to drop old stuff -> less bugs and work.

real.finder
19th August 2019, 15:43
There is also XP compatibility, but it doesn't mean it should be supported :devil:
Sometimes it's good to drop old stuff -> less bugs and work.

support old os is different topic

avs26 still has reasons to use it, lsb and interleaved not important only for avs26 but as FranceBB said before there are many scripts has them

and indeed drop old stuff -> less bugs and work but also it's enjoyable to code to support them :D but anyway I am not with add them to plugins that don't has them but I am with only keep them on plugins that already has them

FranceBB
20th August 2019, 07:17
FranceBB,

After a while of thinking, I believe it's possible to expose a legacy function where it assumes all input and output mode as interleaved (which is effectively the same as HBD), so in the case of referencing f3kdb from foreign scripts, simply changing the function name should do the work, if they were working under interleaved mode. For stacked mode, a conversion is mandatory.

# Proposal1
interleaved_output = interleaved_input.f3kdb_i(input_depth=10, output_depth=12)
stacked_output = stacked_input.ConvertFromStacked().ConvertToDoubleWidth().f3kdb_i(input_depth=10, output_depth=12).ConvertFromDoubleWidth().ConvertToStacked()

The other option is to compile and release a legacy version with function name changed. You keep both DLLs in the system until all legacy scripts move on.

# Proposal2
output = input.f3kdb_legacy(input_depth=10, input_mode=1, output_depth=12, output_mode=2)

Which do you all prefer? I can also do both.

Understanding the difficulties of moving from hacks to HBD, I'd like to reduce even just a bit of pain for you.


The first proposal you offered would be better.

As to me, myself, I was thinking about something like this:

(please note that this is written in pseudo-code and won't work in Avisynth):


function f3kdb_mod(clip c, int range, int Y, int Cb, int Cr, int grainY, int grainC,
\ int sample_mode, float seed, bool blur_first, bool dynamic_grain, int opt,
\ bool mt, int dither_algo, bool keep_tv_range, int input_mode,
\ int input_depth, int output_depth, int random_algo_ref,
\ int random_algo_grain, float random_param_ref,
\ float random_param_grain, string preset)

{

#input mode 0 = Planar (8bit planar, 10bit planar, 12bit planar, 14bit planar, 16bit planar)
#input mode 1 = Stacked
#input mode 2 = Interleaved

#output mode 0 = Planar (8bit planar, 10bit planar, 12bit planar, 14bit planar, 16bit planar)
#output mode 1 = Stacked
#output mode 2 = Interleaved

#Input Planar Output Planar
planar_i_planar_o = (input_mode=0 && input_depth >= 8 && output_mode=0) ? true : false

f3kdb = (planar_i_planar_o=true) ? f3kdb(c, range=range, Y=Y, Cb=Cb, Cr=Cr, grainY=grainY,
\ grainC=grainC, sample_mode=sample_mode, seed=seed, blur_first=blur_first
\ dynamic_grain=dynamic_grain, opt=opt, mt=mt, dither_algo=dither_algo,
\ keep_tv_range=keep_tv_range, output_depth=output_depth,
\ random_algo_ref=random_algo_ref, random_algo_grain=random_algo_grain,
\ random_param_ref=random_param_ref, random_param_grain=random_param_grain,
\ preset=preset)


#Input Planar Output Stacked
planar_i_stacked_o = (input_mode=0 && input_depth >= 8 && output_mode=1 && output_depth=16) ? true : false

f3kdb = (planar_i_stacked_o=true) ? f3kdb(c, range=range, Y=Y, Cb=Cb, Cr=Cr, grainY=grainY,
\ grainC=grainC, sample_mode=sample_mode, seed=seed, blur_first=blur_first
\ dynamic_grain=dynamic_grain, opt=opt, mt=mt, dither_algo=dither_algo,
\ keep_tv_range=keep_tv_range, output_depth=output_depth,
\ random_algo_ref=random_algo_ref, random_algo_grain=random_algo_grain,
\ random_param_ref=random_param_ref, random_param_grain=random_param_grain,
\ preset=preset).ConvertToStacked()

#Input Planar Output Interleaved
planar_i_interleaved_o = (input_mode=0 && input_depth >= 8 && output_mode=2 && output_depth=16) ? true : false

f3kdb = (planar_i_stacked_o=true) ? f3kdb(c, range=range, Y=Y, Cb=Cb, Cr=Cr, grainY=grainY,
\ grainC=grainC, sample_mode=sample_mode, seed=seed, blur_first=blur_first
\ dynamic_grain=dynamic_grain, opt=opt, mt=mt, dither_algo=dither_algo,
\ keep_tv_range=keep_tv_range, output_depth=output_depth,
\ random_algo_ref=random_algo_ref, random_algo_grain=random_algo_grain,
\ random_param_ref=random_param_ref, random_param_grain=random_param_grain,
\ preset=preset).ConvertToDoubleWidth()


#Input Stacked output Stacked
stacked_i_stacked_o = (input_mode=1 && input_depth=16 && output_mode=1 && output_depth=16) ? true : false

f3kdb = (stacked_i_stacked_o=true) ? ConvertFromStacked().f3kdb(c, range=range, Y=Y, Cb=Cb, Cr=Cr, grainY=grainY,
\ grainC=grainC, sample_mode=sample_mode, seed=seed, blur_first=blur_first
\ dynamic_grain=dynamic_grain, opt=opt, mt=mt, dither_algo=dither_algo,
\ keep_tv_range=keep_tv_range, output_depth=output_depth,
\ random_algo_ref=random_algo_ref, random_algo_grain=random_algo_grain,
\ random_param_ref=random_param_ref, random_param_grain=random_param_grain,
\ preset=preset).ConvertToStacked()


#Input Stacked output Interleaved
stacked_i_interleaved_o = (input_mode=1 && input_depth=16 && output_mode=2 && output_depth=16) ? true : false

f3kdb = (stacked_i_stacked_o=true) ? ConvertFromStacked().f3kdb(c, range=range, Y=Y, Cb=Cb, Cr=Cr, grainY=grainY,
\ grainC=grainC, sample_mode=sample_mode, seed=seed, blur_first=blur_first
\ dynamic_grain=dynamic_grain, opt=opt, mt=mt, dither_algo=dither_algo,
\ keep_tv_range=keep_tv_range, output_depth=output_depth,
\ random_algo_ref=random_algo_ref, random_algo_grain=random_algo_grain,
\ random_param_ref=random_param_ref, random_param_grain=random_param_grain,
\ preset=preset).ConvertToDoubleWidth()


#Input Interleaved output Interleaved
interleaved_i_interleaved_o = (input_mode=2 && input_depth=16 && output_mode=2 && output_depth=16) ? true : false

f3kdb = (stacked_i_stacked_o=true) ? ConvertFromDoubleWidth().f3kdb(c, range=range, Y=Y, Cb=Cb, Cr=Cr, grainY=grainY,
\ grainC=grainC, sample_mode=sample_mode, seed=seed, blur_first=blur_first
\ dynamic_grain=dynamic_grain, opt=opt, mt=mt, dither_algo=dither_algo,
\ keep_tv_range=keep_tv_range, output_depth=output_depth,
\ random_algo_ref=random_algo_ref, random_algo_grain=random_algo_grain,
\ random_param_ref=random_param_ref, random_param_grain=random_param_grain,
\ preset=preset).ConvertToDoubleWidth()


#Input Interleaved output Stacked
interleaved_i_interleaved_o = (input_mode=2 && input_depth=16 && output_mode=1 && output_depth=16) ? true : false

f3kdb = (stacked_i_stacked_o=true) ? ConvertFromDoubleWidth().f3kdb(c, range=range, Y=Y, Cb=Cb, Cr=Cr, grainY=grainY,
\ grainC=grainC, sample_mode=sample_mode, seed=seed, blur_first=blur_first
\ dynamic_grain=dynamic_grain, opt=opt, mt=mt, dither_algo=dither_algo,
\ keep_tv_range=keep_tv_range, output_depth=output_depth,
\ random_algo_ref=random_algo_ref, random_algo_grain=random_algo_grain,
\ random_param_ref=random_param_ref, random_param_grain=random_param_grain,
\ preset=preset).ConvertToStacked()


#Error handling
Assert (output_mode=1 && output_depth<=16) chr(10) + "Stacked output is supported with 16bit only!" + chr(10))
Assert (output_mode=2 && output_depth<=16) chr(10) + "Interleaved output is supported with 16bit only!" + chr(10))


return f3kdb
}

MeteorRain
30th August 2019, 00:03
https://down.7086.in/AviSynthPlus%20Filters/f3kdb-2.0-NBD-r1.zip

1. I think it might be better to use 2.0-NBD instead of 2.1 to avoid confusion. Original 2.0 will be re-compiled as 2.0-Legacy with function name f3kdb_legacy. Let me know what you think.

2. Added f3kdb_i with input_depth (default: 8) and always accepts and produces 8 bit (double width) video.

input_depth > 8 → double width input
output_depth > 8 → double width output

3. Since SAP is not actively maintaining this project, I'm going to host the project in my organization, and not merging back to his repo.

4. I'm trying to move the compiling system to cmake, and the binaries above is the production of cmake. Let me know what you think.