[Neo] f3kdb

[quietvoid]

ConvertBits(16).neo_f3kdb(output_depth=10)

this is making encode look 1 point darker.

example (https://slowpics.org/comparison/e56cafd8-5676-44c8-a352-52b4999b1fe6)

if i use SmoothTweak to increase brightness by 1 point, it becomes fine (mostly).

plain neo_f3kdb() is also fine.

using 3.2+6-f46aa2b (https://msystem.waw.pl/x265/) x265 10bit with color parameters set to BT.709

sample clip (https://www9.zippyshare.com/v/jj04ufhz/file.html)

edit 1 : i think issue might be in x265 as this never happened before
The bit depth conversion is causing a slight hue shift. It's something in your workflow.
There is no difference between x265 3.2+6 and 3.1+8 for me.

[Natty]

The bit depth conversion is causing a slight hue shift. It's something in your workflow.

this shift never happened before.

i have only updated ffms2, neo f3kdb and x265.

I'll test again. :thanks:

edit 1: tested with various videos. it happens only with some sources. couldn't understand why.

[real.finder]

chroma bool parameter seems forgotten

[real.finder]

chroma bool parameter seems forgotten

and I think there are bug
ColorBars(width=640, height=480, pixel_type="yv12")
converttoy8
ConvertBits(16)
neo_f3kdb

https://i.postimg.cc/xTymQcQH/Untitled.png (https://postimages.org/)

[MeteorRain]

I have uploaded r3 which is marked as pre-release yet. r3 is based on new dual synth platform and should not change functionality.

Y8 greyscale format issue is fixed.

chroma bool parameter -- what does it do? If you want to skip chroma processing you can set cb = cr = grainc = 0 and it will only copy data and change bit depth if required.

Let me know how it works, and I'll release it if all is well.

[real.finder]

now I got this https://i.imgur.com/mVH3Iva.png

with any bit depth

[ChaosKing]

vsedit does not even open the preview window. It just crashes with r3-pre.

[tormento]

now I got this
The color of love! :D

[l00t]

r3 prerelease is causing VSEditor to crash immediately upon function call. Furthermore y, cb, cr, grainy and grainc is renamed to Y, Cb, Cr, grainY, grainC. It would be good to document if you change variable names, as VapourSynth is case sensitive.

[MeteorRain]

Parameter name change was unintended. I'll check and change name according to last version.

I personally tested on AVS and VS with msvc-x64 and YUV420Pxx on VD2 and I didn't see any crashes.

Can you guys please provide (1) Program used and whether 32/64 bit (2) What colorspace did you pass in (3) If possible, a minimum reproducible BlankClip script.

It's very strange to me that I tested locally without problem and no one else can get it working..... Let's see what I missed.
https://www.hanselman.com/blog/content/binary/WindowsLiveWriter/IntroducingRockScroll_C29C/works-on-my-machine-starburst_3.png IRL.

[ChaosKing]

clip = core.std.BlankClip(format=vs.YUV420P8, width=1920, height=1080, length=500)
clip = clip.neo_f3kdb.Deband()

clang and msvc are crashing. tested only 64bit in vsedit.

[ChaosKing]

vspipe showed me this now (same script above used)
Cannot output clips with varying dimensions

[MeteorRain]

lol that was a stupid mistake, didn't set output-depth to input-depth if none given.

Let me finish it up and give you r4.

EDIT: Please try r4.

[real.finder]

with r4

https://i.imgur.com/SfuP3bA.png

ColorBars(width=640, height=480, pixel_type="yv12")
converttoy8
ConvertBits(16)
neo_f3kdb

[MeteorRain]

Yea sorry there's a regression. Please re-download.

[real.finder]

Yea sorry there's a regression. Please re-download.

it seems load fine this time :thanks:

[kedautinh12]

it seems load fine this time :thanks:

when you replace f3kdb to neo_f3kdb in f3kdb_s.avsi??

[real.finder]

when you replace f3kdb to neo_f3kdb in f3kdb_s.avsi??

it's already done https://github.com/realfinder/AVS-Stuff/commit/c63dd6b6e991c0ae8a351d473d1e1f23d63d305c#diff-5a47f060779727dcf6c5d1fe85ae4267

[MeteorRain]

FYI: mt and opt are no longer available in new versions.
mt is automatically enabled for planes (so 3 planes = 3 threads).
opt doesn't have too much point for consumers as it always detects supported routine.

[kedautinh12]

it's already done https://github.com/realfinder/AVS-Stuff/commit/c63dd6b6e991c0ae8a351d473d1e1f23d63d305c#diff-5a47f060779727dcf6c5d1fe85ae4267

Thanks

[real.finder]

FYI: mt and opt are no longer available in new versions.
mt is automatically enabled for planes (so 3 planes = 3 threads).
opt doesn't have too much point for consumers as it always detects supported routine.

I think opt is useful when debugging

[kedautinh12]

it's already done https://github.com/realfinder/AVS-Stuff/commit/c63dd6b6e991c0ae8a351d473d1e1f23d63d305c#diff-5a47f060779727dcf6c5d1fe85ae4267

Must load 2 plugins f3kdb.dll and neo-f3kdb? Cause i only load neo-f3kdb.dll replaced f3kdb.dll met error: "don't have function F3KDB"

[MeteorRain]

OK I'll add mt and opt back. I'll leave mt unused, and opt be a non-public parameter.

EDIT: check r5

[tormento]

OK I'll add mt and opt back. I'll leave mt unused, and opt be a non-public parameter.
Is ok to let a MT plugin run its own threads within an already MT i.e. Prefecth() script?

[real.finder]

Must load 2 plugins f3kdb.dll and neo-f3kdb? Cause i only load neo-f3kdb.dll replaced f3kdb.dll met error: "don't have function F3KDB"

did you use the r2 or newer? cuz if it as MeteorRain said, there are some changes (https://forum.doom9.org/showthread.php?p=1907413#post1907413) and I made the f3kdb_3 use the old f3kdb if there are error with neo_f3kdb

edit: maybe r5 should work as before

[real.finder]

OK I'll add mt and opt back. I'll leave mt unused, and opt be a non-public parameter.

EDIT: check r5

as tormento said, I think neo_f3kdb should be see if the Prefecth is used or not and if it used then it set mt=false like jpsdr resize plugin did (IIRC)

[kedautinh12]

did you use the r2 or newer? cuz if it as MeteorRain said, there are some changes (https://forum.doom9.org/showthread.php?p=1907413#post1907413) and I made the f3kdb_3 use the old f3kdb if there are error with neo_f3kdb

edit: maybe r5 should work as before

r5 still error, it's work normally if back to r2

[MeteorRain]

as tormento said, I think neo_f3kdb should be see if the Prefecth is used or not and if it used then it set mt=false like jpsdr resize plugin did (IIRC)

Any idea how to detect prefetch() and get thread count?

Is ok to let a MT plugin run its own threads within an already MT i.e. Prefecth() script?

Yes, it's totally fine.

For example, f3kdb itself initiates 3 threads, then you prefetch(4), that'll make it around 12 threads, but in reality it could spin up less due to thread pool size, so possibly 6 threads with 12 tasks waiting to be processed.

We are still waiting for C++23 where there will be executors and we can than do fine control on thread pool size. For now, it's managed by Windows system thread pool or Intel TBB library, which should be smart enough I'd say.


===

EDIT:
I should also point out that internal multi-threading is almost free to use while MT may come with memory usage penalty.
For example, filters usually allocate internal buffers for all 3 planes, so running 3 threads writing to and reading from their own buffer would not create any race condition. However in MT mode, multiple calls to the same function would cause race condition, and usually we'd have to create extra buffers for each individual thread. That's why in most case internal multi-threading runs lighter than MT.

[MeteorRain]

kedautinh12: Please try r5v2.

[real.finder]

Any idea how to detect prefetch() and get thread count?


I don't know since I am not Knowing c++, better see what pinterf said but in worst cases making mt=false by default and if someone set it to true then the filter should report itself as MT_SERIALIZED like rgtools
RgTools 0.94
Autoregister filter MT modes as NICE_FILTER for Avisynth+
(except for Clense: when reduceflicker is true, MULTI_INSTANCE MT mode is reported)


edit: this may help https://forum.doom9.org/showthread.php?p=1667553#post1667553

[MeteorRain]

real.finder, to be honest I don't like the idea to turn off mt by default and wait for (the less efficient) MT mode.

Like I said, internal mt is almost free to use. And I have been very conservative on number of total threads.
I'm hoping that we can reach to a point where you'll have no needs to go more than prefetch(4) when the heaviest parts are already running parallel.

Eventually we will have mainstream CPU with 32 cores or more. If you do prefetch(32) you could waste dozens of gigabytes of memory in some filters.

Let's see what pinterf has, but I haven't found anything useful yet.

[tormento]

real.finder, to be honest I don't like the idea to turn off mt by default and wait for (the less efficient) MT mode.
Benchmarks are the way to go.

Just run with prefetch with internal MT disabled and with internal MT with prefetch disabled and let's see results.

[MeteorRain]

Tormento, that's not how real world application works. AviSynth is a frame server, you take it as a pre-processor and you'll feed the result to an encoder. Most of the time the encoder should be taking most of your CPU resources, and the filters, in most cases, will only have probably a single core to spare.

The temporal median that I just finished a few days ago, can do 11400fps on a 1280x720 YV12 clip with MT (VapourSynth) but can only do 7500fps single threaded (internal mt). However in former case it took 80% of my CPU while the latter case it only took 20%. Now, those numbers may not be accurate, but it should tell you something. As a frame server it's not the faster the better, it should find a balance between high efficiency AND speed.

[tormento]

Tormento, that's not how real world application works.
Absolutely right.

That is why with "benchmaks" I meant x264/x265 encoding, not syntetic tests such as AVSMeter.

I just posted a message in AviSynth+ main thread where AVSMeter results and real encoding results are different.

[kedautinh12]

kedautinh12: Please try r5v2.

it's work, thanks

[FranceBB]

Just a suggestion: in f3kdb.hpp from line 111 to line 121


#define INVALID_PARAM_IF(cond) \
do { if (cond) { throw("Invalid parameter condition: " #cond); } } while (0)

INVALID_PARAM_IF(in_vi.Format.IsFamilyYUV != true);
INVALID_PARAM_IF(in_vi.Width < 16);
INVALID_PARAM_IF(in_vi.Height < 16);
INVALID_PARAM_IF(in_vi.Format.SSW < 0 || in_vi.Format.SSW > 4);
INVALID_PARAM_IF(in_vi.Format.SSH < 0 || in_vi.Format.SSH > 4);
INVALID_PARAM_IF(in_vi.Frames <= 0);
INVALID_PARAM_IF(in_vi.Format.BitsPerSample < 8 || in_vi.Format.BitsPerSample > INTERNAL_BIT_DEPTH);
INVALID_PARAM_IF(in_vi.Format.IsInteger != true);


Since you're checking for invalid parameters anyway, wouldn't it be better to throw a string describing the error so that non skilled Avisynth users can better understand what they did wrong instead of trowing just #cond?
I mean, I'm totally fine with that, but even if it's self-explanatory, perhaps someone else might not get it at a first glance, so I would do something like:

in_vi.Format.IsFamilyYUV != true

"Your input is not YUV; only YUV inputs are supported"

in_vi.Width < 16

"Input Width is smaller than 16, which is the minimum supported"

in_vi.Height < 16

"Input Hight is smaller than 16, which is the minimum supported"

in_vi.Frames <= 0

"No input frames received. You need at least one frame"

in_vi.Format.BitsPerSample < 8 || in_vi.Format.BitsPerSample > INTERNAL_BIT_DEPTH

"Your input is either smaller than 8, which is the minimum supported bit depth, or larger than 16, which is the maximum internal bit depth precision of this filter"

etc

I didn't really want to bother you, it's just a little hint for the future.
By the way, thank you for the keeping f3kdb alive and working on XP as well. :)

[jpsdr]

Any idea how to detect prefetch() and get thread count?

From the few tests i've made, it seems it's not possible to have the prefetch value used in the script neither in the AvisynthPluginInit3 or the Create_xxx function and not even in the constructor of the filter.
Only in the GetFrame method you can have access to this information.
Unfortunately, in my case, it's too late, i need the information in the Create_xxx function... :(
I'm unable to remember how i had access to the information...

Edit
I've been able to retrieve the information. You have to call :
IScriptEnvironment2::GetProperty(AEP_FILTERCHAIN_THREADS)
But as i said, the value returned is not correct even at the constructor stage of the filter.

[StainlessS]

In Avisynth, constructors are called in script [EDIT: FLOW] order, and so if Prefetch is last in script, so its constructor has not yet been called when your filters constructor is called.

[MeteorRain]

Thanks, that's useful. Do you think it makes sense to turn off internal MT when prefetch is large? (Like 6+)

[real.finder]

Do you think it makes sense to turn off internal MT when prefetch is large? (Like 6+)

I do, maybe it better if prefetch more than half of cpu cores then turn off internal MT

[StainlessS]

Have revised prev post to

In Avisynth, constructors are called in script [EDIT: FLOW] order, and so if Prefetch is last in script, so its constructor has not yet been called when your filters constructor is called.

So Program Flow order would include and eg looping or calls to script functions etc.
Also, eg Variables are assigned in program flow order, and so are then availalbe for use when eg calling filter contructor. Calling a filter is just calling its constructor.

The whole shabang, start to end program flow just builds the filter graph.

During some runtime environment (eg Scriptclip::GetFrame called via eg some other GetFrame), you enter another short lived period where a temp filter graph is created and each constructor within the runtime script is called,
finally delivering a single (current_frame) frame to the filter GetFrame that requested it of Scriptclip.

Sort of.

[MeteorRain]

I do, maybe it better if prefetch more than half of cpu cores then turn off internal MT

So I thoroughly thought about it, and I think I'm not gonna disable internal MT at this moment.

f3kdb has internal state cache, which means the more you enable external MT the more you'll be wasting memory space, by a LOT.

Running 10 threads external MT with iMT disabled will have the same speed as running 4 threads with iMT enabled but you are looking at doubling the memory usage. (That means it may go from 1GB to 2GB, per instance, and you gain nothing at all.)

So for f3kdb, instead of disabling iMT, I'd ask user to reduce MT threads to prevent wasting.

[real.finder]

So I thoroughly thought about it, and I think I'm not gonna disable internal MT at this moment.

f3kdb has internal state cache, which means the more you enable external MT the more you'll be wasting memory space, by a LOT.

Running 10 threads external MT with iMT disabled will have the same speed as running 4 threads with iMT enabled but you are looking at doubling the memory usage. (That means it may go from 1GB to 2GB, per instance, and you gain nothing at all.)

So for f3kdb, instead of disabling iMT, I'd ask user to reduce MT threads to prevent wasting.

isn't f3kdb NICE_FILTER? if it not, what about make report itself as MT_SERIALIZED when iMT is on?

[MeteorRain]

Never mind. Obviously f3kdb and fft3d got mixed in my mind. f3kdb is fine.

[Stereodude]

Sorry if this is a stupid question or has been discussed before. I didn't see any discussion on it. Where did the new sampling modes come from, or what is the theory behind them? Is there particular scenarios where one should be better than others, or is it just a try each and see what you like better?

[real.finder]

Sorry if this is a stupid question or has been discussed before. I didn't see any discussion on it. Where did the new sampling modes come from, or what is the theory behind them? Is there particular scenarios where one should be better than others, or is it just a try each and see what you like better?

see from here https://forum.doom9.org/showthread.php?p=1879897#post1879897

[Stereodude]

see from here https://forum.doom9.org/showthread.php?p=1879897#post1879897
That makes it seem like mode 4 is to perform better on synthetic test patterns, not real content (most of the time).

[real.finder]

That makes it seem like mode 4 is to perform better on synthetic test patterns, not real content (most of the time).

mode 4 is balanced and less fierce against the details

and I think in anime/cartoon you can also see mode 4 perform better

anyway, in the end it depends on what you see better, mode 2 still default

[Boulder]

Out of interest, has anyone else made any tests with UHD sources and the filter? I was astonished to notice that removing the line core.neo_f3kdb.Deband(clp, preset="medium", output_depth=16, sample_mode=4) from my test script produced a file that was ~35% bigger than the one with it.. the exact same settings in x265. The test material (Blade Runner 2049) is very clean and you can easily see the effect of debanding if you use DGHDRtoSDR.

[MeteorRain]

Because of the grain you added?