[Neo] f3kdb

[Natty]

Originally Posted by MeteorRain

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/stab...g-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.

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

[MeteorRain]

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]

understood

[StvG]

Originally Posted by ChaosKing

x64 seems to work now...

I have no crashes too.

Thanks for this version.

[FranceBB]

Originally Posted by MeteorRain

Original post

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 - 16bit stacked - 10bit planar

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]

input depth, input mode and output mode dont work. only output depth works. I like it. just hope it works correctly internally.

[MeteorRain]

Originally Posted by FranceBB

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]

Originally Posted by MeteorRain

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]

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]

is it possible to disable masking in F3KDB?

[MeteorRain]

Can you be more precise? I'm not very familiar with the core part of f3kdb.

[real.finder]

Originally Posted by MeteorRain

Can you be more precise? I'm not very familiar with the core part of f3kdb.

with

ImageSource("uonzj6V.png")
PointResize(720,480)
ConvertToYV12()
mt_merge(last,FlipHorizontal(),BlankClip(last,color = $FFFFFF).FadeIO(500))
f3kdb()
luma_histogram()

you can see masking artifacts in the dividing line

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

[real.finder]

Originally Posted by HolyWu

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.

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]

Originally Posted by HolyWu

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]

Originally Posted by HolyWu

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 or something)

[DJATOM]

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]

Originally Posted by DJATOM

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]

@MeteorRain The download link on the first page is not working.

[MeteorRain]

Fixed the link. But I'm planning to clean up the building system a little bit and then release a GA version.

[Stereodude]

GA version?

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