nnedi3sf: single precision nnedi3 plugin

[feisty2]

binary (x64 winnt) https://github.com/IFeelBloated/NNEDI3SF/releases/tag/r1

source code https://github.com/IFeelBloated/NNEDI3SF

namespace: nnedi3sf.nnedi3 (...)

same thing like http://forum.doom9.org/showthread.php?t=166434

differences:
1. it takes high precision float clips, unlike the original one which works on 8-16 bits int clips only
2. no direct support for YUV4XXPS clips, range UV to [0.0, 1.0] before using it and range them back to [-0.5, 0.5] when it's done, GrayS is the only format got native support
3. "opt" parameter is removed cuz I removed all asm codes, don't ask me why, inject asm stuff to the code urself if u want that and good luck with that
4. "nnedi3_rpow2" is removed cuz I don't need it

[feisty2]

https://github.com/IFeelBloated/NNEDI3SF/releases/tag/r1SSE2

this one got some SSE2 opt, so should work faster more or less

[mastrboy]

differences:
1. it takes high precision float clips, unlike the original one which works on 8-16 bits int clips only
2. no direct support for YUV4XXPS clips, range UV to [0.0, 1.0] before using it and range them back to [-0.5, 0.5] when it's done, GrayS is the only format got native support
3. "opt" parameter is removed cuz I removed all asm codes, don't ask me why, inject asm stuff to the code urself if u want that and good luck with that
4. "nnedi3_rpow2" is removed cuz I don't need it

So the only new feature is support for > 16bit?
Or are there other use cases where this nnedi version is more appropriate to use than the original?

[feisty2]

So the only new feature is support for > 16bit?
Or are there other use cases where this nnedi version is more appropriate to use than the original?

Yeah, it's like that, you got it right, the only advantage over the original one is ultra high bit depth support (32bits float)
I made this mostly for, like a real example, a cool way to learn things about programming, so you know what I mean...

[jackoneill]

Is the prescreener working the same as with 8 bit input? In my tests it flags a lot more pixels for the slow processing. You can check by commenting out the call to evalFunc_1 in nnedi3GetFrame. Look for the white pixels.


import vapoursynth as vs
c = vs.get_core()

src = c.lsmas.LibavSMASHSource("YUV420P8.mp4")
src = c.std.ShufflePlanes(src, planes=0, colorfamily=vs.GRAY)

test1 = c.nnedi3.nnedi3(src, field=1)

test2 = c.z.Depth(src, depth=32, sample=vs.FLOAT)
test2 = c.nnedi3.nnedi3(test2, field=1)
test2 = c.z.Depth(test2, depth=8, sample=vs.INTEGER)

src = c.std.Interleave([test1.text.Text("nnedi3 uint8_t", 5), test2.text.Text("nnedi3 float", 5)])

src.set_output()

[feisty2]

try "test1 = c.nnedi3.nnedi3(src, field=1, pscrn=1), test2 = c.nnedi3.nnedi3(test2, field=1, pscrn=1)"
pscrn is 2 by default on uint8_t clips, but it doesn't work at any higher bit depth, so the default of pscrn becomes 1 at uint16_t and float

[jackoneill]

try "test1 = c.nnedi3.nnedi3(src, field=1, pscrn=1), test2 = c.nnedi3.nnedi3(test2, field=1, pscrn=1)"
pscrn is 2 by default on uint8_t clips, but it doesn't work at any higher bit depth, so the default of pscrn becomes 1 at uint16_t and float

Ah, indeed. Such a silly mistake.