AVISynth minideen() x64 request

[SaurusX]

In order to use my preferred derainbowing method, using DFMDerainbow, I need an x64 version of deen(). A version of deen that only involves the "a2d" method used in DFMDerainbow was ported to VapourSynth and called minideen.

https://github.com/dubhater/vapoursynth-minideen

Is it too much to ask that this minideen be ported to AVISynth as a 64-bit filter? I'm sure it would be appreciated by others as well.

[MeteorRain]

Please try and let me know.

MiniDeen(radius=1, thrY=10, thrUV=12, y=3 or 2 or 1, u=3 or 2 or 1, v=3 or 2 or 1)

Source code: https://github.com/HomeOfAviSynthPlusEvolution/MiniDeen

[SaurusX]

This works great! Thanks so much for going through the trouble. It seems to work just slightly better than DFMDerainbow with the original deen() if that makes sense.

I plugged minideen into the DFMDerainbow script by replacing the deen calls with minideen like so:

fixed_u=org_u.FluxSmoothST(17,14).FluxSmoothT(17).Deen("a2d",4,14,14).Blur(1.0)
fixed_v=org_v.FluxSmoothST(17,14).FluxSmoothT(17).Deen("a2d",4,14,14).Blur(1.0)

fixed_u=org_u.FluxSmoothST(17,14).FluxSmoothT(17).minideen(4,14,14).Blur(1.0)
fixed_v=org_v.FluxSmoothST(17,14).FluxSmoothT(17).minideen(4,14,14).Blur(1.0)

And now, I use DFMDerainbow with the masked and motion compensated routine from the MVTools guide like so:

prerb = last
derbmask = last.tedgemask(threshY=7).mt_deflate()
prefiltered = last.FFT3Dfilter(sigma=1.5,bw=16,bh=16,bt=3,ow=8,oh=8,plane=0)
derbsuperfilt = MSuper(prefiltered) # all levels for MAnalyse
derbsuper = MSuper(levels=1) # one level is enough for MCompensate
derbbackward_vectors = MAnalyse(derbsuperfilt, truemotion = true, isb = true, chroma=false)
derbforward_vectors = MAnalyse(derbsuperfilt, truemotion = true, isb = false, chroma=false)
# use not-prefiltered (super) clip for motion compensation
derbforward_compensation = MCompensate(derbsuper, derbforward_vectors)
derbbackward_compensation = MCompensate(derbsuper, derbbackward_vectors)
# create interleaved 3 frames sequences
interleave(derbforward_compensation,last,derbbackward_compensation)
dfmderainbow(maskthresh=8)
selectevery(3,1) # return filtered central (not-compensated) frames only
mt_merge(prerb,last, derbmask,luma=true)

And here are the results:

Routine without DFMDeRainbow and instead using old Derainbow(), notice the hand.


Rotuine with DFMDerainbow and x86 deen()


Routine with DFMDerainbow and new x64 minideen(). The same!


And here's another comparison with a closeup:

Original raw
x86 deen()
x64 minideen()

[MeteorRain]

You are very welcome.
The source code was very easy to work with, so it didn't take me long.
I'll organize the source code and put it onto GitHub soon.

[MeteorRain]

On the other hand, You can use u=1, v=1 to skip processing the UV plane.
Or make use of plane processing and combine some operations, if possible.

[SaurusX]

Originally Posted by MeteorRain

On the other hand, You can use u=1, v=1 to skip processing the UV plane.
Or make use of plane processing and combine some operations, if possible.

I'm looking at this from the position of derainbowing. Don't we need to process chroma to handle the chroma cross-talk of the rainbows? And I don't know what you mean in your second statement. But anything to make DFMDerainbow more efficient or more effective would be welcome.

[MeteorRain]

fixed_u=org_u.FluxSmoothST(17,14).FluxSmoothT(17).minideen(4,14,14).Blur(1.0)
fixed_v=org_v.FluxSmoothST(17,14).FluxSmoothT(17).minideen(4,14,14).Blur(1.0)

You see, u and v were extracted from origin, so they only have Y channel valid.
By saying minideen(4,14,14) which implies processing all planes (including valid Y, garbage U, garbage V), you are wasting your precious time.

What I was saying, is either adding u=1, v=1 to skip processing the garbage UV plane, or,
maybe check if you can modify the whole DFMDerainbow script to process 3 channels in one shot.

I didn't look deep into it, so just my 2 cents.

[SaurusX]

Originally Posted by MeteorRain

What I was saying, is either adding u=1, v=1 to skip processing the garbage UV plane, or,
maybe check if you can modify the whole DFMDerainbow script to process 3 channels in one shot.

I didn't look deep into it, so just my 2 cents.

Ah! Reading the DFMDerainbow script I do see that fixed_u and fixed_v only have valid Y planes, so processing all three in minideen() is a waste of time. I'll add the u=1 and v=1 parameters to the call.

[ChaosKing]

@MeteorRain will you also make a release on https://github.com/HomeOfAviSynthPlusEvolution/MiniDeen ?
Delogohd and lsmash can now be installes via avsrepo. Would like to add MiniDeen as well ;-)

[MeteorRain]

You got it.

Also your signature links are wrong.

[StvG]

There is error "only 8..16 bit integer clips with constant format are supported." when color space is I420.

Edit: For example:

ffvideosource(8-bit.video)
minideen()

[MeteorRain]

*Dead link removed*

Support I420 and also RGBPxx color format. Let me know how it works, and I'll make a tagged release if you are happy.

[real.finder]

original deen can work with 0-255 why minideen can't?


edit: and in avs 2.6 (test with SEt mt one) minideen(2, 5 , 2, 3, 1, 1)

it's important since I add it in DeHaloHmod https://forum.doom9.org/showthread.p...88#post1883288

[real.finder]

ok, Found this and know why, https://forum.doom9.org/showthread.p...98#post1846298 (but don't know why it's say 2 not 1 maybe because the video is yv12?)

maybe you can make it silently change u and v from 3 to 2 if it 0 (and ignore the Threshold if u and v not 3)

and still we have the avs 2.6 problem https://i.imgur.com/xXtw5f0.png

[jackoneill]

Originally Posted by real.finder

original deen can work with 0-255 why minideen can't?


edit: and in avs 2.6 (test with SEt mt one) minideen(2, 5 , 2, 3, 1, 1)

it's important since I add it in DeHaloHmod https://forum.doom9.org/showthread.p...88#post1883288

A threshold of 1 would result in an average calculated only from identical pixels, for example (10 + 10 + 10 + 10) / 4 = 10. The result is no change to the image. A threshold of 0 would result in an average calculated only from one single pixel, for example 10 / 1 = 10. Again, the result is no change to the image.

[MeteorRain]

# 5 = Avisynth      2.6.0 (SEt's multi-threaded build)
loadplugin("Release_r2\x86\minideen.dll")
colorbars()
converttoyv12
minideen(2, 5, 2, 3, 1, 1)
info

Gives me pretty correct result. Do you have other precondition to reproduce this behavior?

[real.finder]

Originally Posted by MeteorRain

# 5 = Avisynth      2.6.0 (SEt's multi-threaded build)
loadplugin("Release_r2\x86\minideen.dll")
colorbars()
converttoyv12
minideen(2, 5, 2, 3, 1, 1)
info

Gives me pretty correct result. Do you have other precondition to reproduce this behavior?

# 5 = Avisynth      2.6.0 (SEt's multi-threaded build)
loadplugin("Release_r2\x86\minideen.dll")
colorbars()
converttoyv12
Spline36Resize(880,496) #or any resizer
minideen(2, 5, 2, 3, 1, 1)
info

or just colorbars(880,496) without any resizer

[real.finder]

Originally Posted by jackoneill

A threshold of 1 would result in an average calculated only from identical pixels, for example (10 + 10 + 10 + 10) / 4 = 10. The result is no change to the image. A threshold of 0 would result in an average calculated only from one single pixel, for example 10 / 1 = 10. Again, the result is no change to the image.

thanks for reply

then in this case isn't better to silently change u and v or even Y from 3 to 2 if the threshold is 0 or 1? and ignore the Threshold if u and v or even Y is not 3

[MeteorRain]

As I expected, memory alignment issue.

I can do threshold 0 1.

[MeteorRain]

*Dead link removed* Please test and let me know.

Also r4 that changes SIMD logic a little bit.