[Neo] f3kdb

[MeteorRain]

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

F3kdb is a deband filter. It was originally written for AviUtl (author uncovered) and later ported to AviSynth (Original F3KDB) 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]

any plan for float support?

[Natty]

thaaaaanks

[real.finder]

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]

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]

There is random "access violation writing 0x0000000000000000". Just used:

ffvideosource(10-bit.video)
f3kdb()

[MeteorRain]

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]

avs+ 2772 x64 used. Info; error (trying to run three times in a row).

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

[MeteorRain]

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]

Same behavior.
Btw no crashes when f3kdb_*_sanitize* stuff isn't removed but sometimes the speed is lower (~30%).

[ChaosKing]

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]

Oh 64 bit version, missed that. Let me check that part and see if I can find something.

[Natty]

Originally Posted by ChaosKing

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]

32bit = x86 :-)

[MeteorRain]

Originally Posted by StvG

but sometimes the speed is lower (~30%).

Seems to be an uninitialized multi-threading flag that caused random results (randomly mt / st).

[MeteorRain]

Originally Posted by ChaosKing

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]

Originally Posted by MeteorRain

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/stab...rg-dither_algo
is this correct? or is there some other docs for your ported version?
and can you enable dither_algo=2 for 16bit?

[MeteorRain]

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

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

[MeteorRain]

Originally Posted by Natty

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

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]

Originally Posted by MeteorRain

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.