HAvsFunc

[Boulder]

KNLMeans is applied as prefilter.Only affects the detection of motion, indirectly to the results.

Again: higher tr means more precise results as motion vectors.

Now there is a dilemma we all often have to deal with. How do you know the motion vector predicted to for example 10 frames in the future is any good? Often the detection is difficult already for 2-3 frames from the current frame.

[tormento]

Now there is a dilemma we all often have to deal with. How do you know the motion vector predicted to for example 10 frames in the future is any good? Often the detection is difficult already for 2-3 frames from the current frame.
Unless scene change (and it is the main limit of MVTools), object mostly tend to move in a way that the more frames you sample, the best interpolation you can get. I don't know exactly the MV algorithm but at least on math, to have good interpolation and extrapolation, you need data, the more, the better.

[ChaosKing]

Also every mvtools based deboiser can't really denoise single frames with sudden changes like flashes, explosions etc (typically found in action animes) becouse it does not have any reference frames to work with.

[tormento]

Also every mvtools based demoiser can't really denoise single frames with sudden changes like flashes, explosions etc (typically found in action animes) becouse it does not have any reference frames to work with.



Nothing last one frame only, unless it is flash from a photo. The more frames you can sample, the better results. With very grainy noise, it’s absolutely impossible to denoise a fast moving object with tr=3. You could have to rise until 9 on some material. I did many many times. I have a collection of almost 3 thousand DVD and BD, plus digital transfers of reels. I am not rich, I simply collect things people want to throw. I know what I am talking about.

[Boulder]

By the way, changing SMDegrain to support tr 1-6 should not be very hard. If you take a look at MCTemporalDenoise inside havsfunc, you can see how it is done there. I didn't check the function thoroughly, but there are a few things that need to be done, basically copying the functionality which is already done for deltas 1-3 and then do the degraining with weighted merging.

[feisty2]

By the way, changing SMDegrain to support tr 1-6 should not be very hard. If you take a look at MCTemporalDenoise inside havsfunc, you can see how it is done there. I didn't check the function thoroughly, but there are a few things that need to be done, basically copying the functionality which is already done for deltas 1-3 and then do the degraining with weighted merging.

the result is different from native MDegrain(tr=6), the mdegrain algorithm is here (https://github.com/IFeelBloated/vapoursynth-mvtools-sf/blob/master/src/MVDegrains.h), do the math.

[Boulder]

the result is different from native MDegrain(tr=6), the mdegrain algorithm is here (https://github.com/IFeelBloated/vapoursynth-mvtools-sf/blob/master/src/MVDegrains.h), do the math.

Too bad I suck at maths. What is the actual real-world difference? Just a different output but impossible to tell which one looks better or something that can be pointed out as a real flaw in the workaround?

[feisty2]

Too bad I suck at maths. What is the actual real-world difference? Just a different output but impossible to tell which one looks better or something that can be pointed out as a real flaw in the workaround?

the difference is pretty notable, the home-assembled version in MCTD is usually notably blurrier. there's no better or worse, just two completely different algorithms

[Boulder]

I don't think tormento would mind blurring :) And the limit parameter could be used to control it quite well as the default seems to be 255..

[feisty2]

this is insane, just grab dubhater's code and do some copy-paste and you got a legit MDegrain6 in less than 5 minutes, why bother with all that homegrown mess.

[tormento]

I don't think tormento would mind blurring :) And the limit parameter could be used to control it quite well as the default seems to be 255..
I'd like to see results on par as with AVS+ or it would be useless, don't you think?

If VS would prove to be faster, with same quality, as AVS+, I could consider to jump on the wagon for every day jobs. For the rare ones, unfortunately, my VS script programming in not existing.

[Boulder]

I don't know if there is any substantial difference in speed between the two frameworks. The biggest thing VS brought was 100% stable multithreading out of the box and the latest AVS+ builds by pinterf should be quite good indeed.

[tormento]

I don't know if there is any substantial difference in speed between the two frameworks.
That is what I want to discover...

I have absolutely no problems here with AVS+ and MT but 1fps more sometimese can make big difference.

[Boulder]

Should be quite easy to test. Create a simple script with enough frames and with the same settings (tr=3 in SMDegrain) and run "vspipe -p script.vpy ." and you'll see how many fps you get. Then do the same with AVS+, AVSMeter should be able to do the same thing.

[tormento]

Should be quite easy to test. Create a simple script with enough frames and with the same settings (tr=3 in SMDegrain).

Already did with tr=3. The difference is 1 FPS on 12 of average. I need to know with heavier tasks.

[NullNix]

So I was trying to use TemporalDegrain2 for the umpteenth time (version now off-the-net) to do some denoising of the X-Men blurays in conjunction with vapoursynth 49 and it was going badly: frames from the start were duplicated several seconds later, and other frames were dropped, changing the length of the clip and desynchronizing the audio and video. Since denoising blurays is not optional for me (the link to my home cinema is wifi and can't handle the bandwidth of a noisy bluray, even if the pointless noise didn't give me a headache), this is unfortunate.

But that's OK, I thought! I'll use QTGMC! I've denoised with that before and it was all fine: QTGMC is my go-to workhorse and always does a good-enough job, even if it doesn't quite keep all the detail TemporalDegrain2 does. But... it really isn't. The damage is so severe that it is visible even in ShowNoise=True mode: several frames of *unmodified* clip appear half a second or so after the clip's start. In non-ShowNoise mode it's even more obvious, with frames displaced up to half a second from their proper places and with some settings (see below) frames removed entirely, as previously observed with TemporalDegrain2. This is with havsfunc HEAD as of today, commit b2258c21f1713a6592a0dfd948fb358351850124.

This is all on Linux, vapoursynth r49, 10-core hyperthreaded Broadwell EP (E5-2640v4), AVX2-capable (but not AVX512-capable), everything compiled with GCC 9.3.0 (a bit after the 9.3.0 release, commit c78b41b23b360e21a43bb161c7381c71680da8f3). Python from the 3.8 branch, commit 8c3ab189ae552401581ecf0b260a96d80dcdae28.

Example (biggish uncompressed original clip, QTGMCed output, script to do it) is at http://www.esperi.org.uk/~nix/encoding/. And holy hell is this horrible. Look at the unbelievable mess around 7.5s in! At least the frame count is unchanged so the audio and video are still in sync: they're just in very much the wrong order (most obvious at 34s in, where some speech happens).

From the above link, the QTGMC call I'm using here is

ret = hv.QTGMC(ret, InputType=1, Preset="slower", EZDenoise=1.5, NoisePreset="Slower", StabilizeNoise=False)

If you take EZDenoise out, the obvious frame-chopping is gone, but you *do* suddenly get desynchronized audio, exactly as I observed with TemporalDegrain2, so the number of frames has been changed (obviously a bad thing): this actually happens in the first second or two of the clip, but it's quite hard to see in this sample. Changing the denoiser has no effect; nor does dropping StabilizeNoise.

QTGMC has never given me problems like this before, so I presume something very silly is going on, and I bet it's my fault. So, what have I done wrong? :)

(Alternatively, it might be another instance of the zero-divide-yields-NaN bug: but I doubt it somewhat, because TemporalDegrain2 was rife with them, so I squashed them, and nothing changed. Or vapoursynth itself, or one of the libraries havsfunc depends on, is being miscompiled...)

[Boulder]

Sounds more like problems with the source filter.

[NullNix]

Sounds more like problems with the source filter.

Now why didn't I think of that?! Probably because my eye skips over it because it's so routine.

... but no, source filter blameless: you do *need* a call to QTGMC in there. Going straight from source to set_output is fine.

I'm going to have to bisect this to see if it's purely a vs core bug: since I know QTGMC *used* to work perfectly well back in the vapoursynth r45.1 days and it's not the only thing now failing, that's a strong possibility. That's going to be extra fun given the Python 3.7 -> 3.8 transition in there :( (GCC got upgraded too, but for now I'll ignore that one.)

[NullNix]

I'm going to have to bisect this to see if it's purely a vs core bug: since I know QTGMC *used* to work perfectly well back in the vapoursynth r45.1 days and it's not the only thing now failing, that's a strong possibility. That's going to be extra fun given the Python 3.7 -> 3.8 transition in there :( (GCC got upgraded too, but for now I'll ignore that one.)

OK, it can't be just the vs core: I have proof that r48 worked late last year, but now, rebuilding r48, it has the same problem. So it is one of the other changes (GCC, Python 3.7 -> 3.8, Cython 0.29.14 -> 0.29.16, or even zimg or tesseract though I doubt it) or the source material. I'll try some source material I know worked and see if it still works.

[NullNix]

OK, it can't be just the vs core: I have proof that r48 worked late last year, but now, rebuilding r48, it has the same problem. So it is one of the other changes (GCC, Python 3.7 -> 3.8, Cython 0.29.14 -> 0.29.16, or even zimg or tesseract though I doubt it) or the source material. I'll try some source material I know worked and see if it still works.

More things it isn't: the input (re-ripped input that used to work now fails); Python 3.7 -> 3.8; GCC (at least as applied to VS or Python, since I restored the old versions from backups rather than recompiling with the newer GCC); MakeMKV (reripping with a version that used to work now produces ripped output that when vapoursynthed fails: the output from MakeMKV is not visibly flawed). I'm running out of ideas for things to revert and might have to resort to actually trying to debug this rather than just trying to find some combination of things that works, since nothing appears to work any more. (Not that I have any real idea where to start when trying to debug this.)

[NullNix]

OK, it can't be just the vs core: I have proof that r48 worked late last year, but now, rebuilding r48, it has the same problem. So it is one of the other changes (GCC, Python 3.7 -> 3.8, Cython 0.29.14 -> 0.29.16, or even zimg or tesseract though I doubt it) or the source material. I'll try some source material I know worked and see if it still works.

I've been doing a bit of idle parameter-space searching. This does not happen with the ultrafast preset, but does happen with Slower. Of the settings Slower changes, Rep0 = 4 (rather than, say, 0) causes the massive frame-chopping: TR0 > 0 causes the extra frames (early frame mangling/duplication) and audio desync. Ultimate cause not yet known: will dig deeper, but it feels to me like Merge or AverageFrames in the vs core must be fubar somehow. I fear miscompilation... particularly if (as seems likely) nobody else is seeing this.

[lansing]

I'm using R49, and I didn't see the frame skipping problem with your script.

[jackoneill]

but it feels to me like Merge or AverageFrames in the vs core must be fubar somehow.

You can put

core.std.SetMaxCPU("none")

before QTGMC. If the problem goes away then try also "sse2" and "avx2" instead of "none".

This only affects the internal filters. Several bugs were introduced in recent versions in the SSE2/AVX2 functions. Maybe you found another one.

[ChaosKing]

I had also the feeling that the AverageFrames function did nothing, but it was late so I thought I just used it wrong...

Tested again and:
clip.misc.AverageFrames(weights=30) # or any other weights value -> seems to do nothing at all. setting setcpu to none does not help
clip.misc.AverageFrames(weights=3, scale=1) -> pink image even with a blank YUV420P8 clip, rgb seems fine with a blank clip. But is looks like a rainbow with a rgb video

EDIT: https://github.com/vapoursynth/vapoursynth/issues/565

[Myrsloik]

I had also the feeling that the AverageFrames function did nothing, but it was late so I thought I just used it wrong...

Tested again and:
clip.misc.AverageFrames(weights=30) # or any other weights value -> seems to do nothing at all. setting setcpu to none does not help
clip.misc.AverageFrames(weights=3, scale=1) -> pink image even with a blank YUV420P8 clip, rgb seems fine with a blank clip. But is looks like a rainbow with a rgb video

EDIT: https://github.com/vapoursynth/vapoursynth/issues/565

If I'm not mistaken the scale is the sum of weights unless it's explicitly specified. So no change sounds about right. (multiply by 30 and then divide by 30)
The second one generates a huge amount of overflow so no wonder it looks bad.
Basically the case with only one weight is pointless.

[ChaosKing]

ok but is a pink image correct or not?
left clip.misc.AverageFrames(weights=5, scale=1.1), right untouched
https://i.imgur.com/T3kQUGZ.png

The doc says "If a single clip is supplied then an odd number of weights are needed and they will instead be temporally centered on the current frame of the clip"
shouldn't I be seeing temporal "artifacs" then, lets say, weights=5?

[Myrsloik]

ok but is a pink image correct or not?
left clip.misc.AverageFrames(weights=5, scale=1.1), right untouched
https://i.imgur.com/T3kQUGZ.png

Does it look identical to expr "x 5 * 1.1 /" applied to all planes? If so the answer is mostly yes.

[ChaosKing]

It looks almost the same. MergeDiff diff shows some differences on edges and black hair, basically on dark colors. Is this to be expected?

a = clip.misc.AverageFrames(weights=5, scale=1.1)
e = core.std.Expr([clip], expr=["x 5 * 1.1 /"])
#clip = core.std.StackHorizontal([a,e])
clip = core.std.MergeDiff(e,a)

[HolyWu]

shouldn't I be seeing temporal "artifacs" then, lets say, weights=5?

There is no temporal processing since you specified only one weight with a single clip. To have actual temporal processing with a single clip you need specify at least three weights.

[NullNix]

You can put

core.std.SetMaxCPU("none")

before QTGMC. If the problem goes away then try also "sse2" and "avx2" instead of "none".

This only affects the internal filters. Several bugs were introduced in recent versions in the SSE2/AVX2 functions. Maybe you found another one.

All problems persist even with "none". But this eliminates a bunch of tricksy assembler in the vs core as a possible cause, as well as its corresponding non-assembler variants, which is extremely valuable! Thank you!

(hmm, that's an idea. I'll roll back not only vapoursynth but also all vs plugins containing native code to the versions as of last year and see if the problem persists.)

[ChaosKing]

There is no temporal processing since you specified only one weight with a single clip. To have actual temporal processing with a single clip you need specify at least three weights.

Ahh yes, now I can see what I expected to see :p
:thanks:

[NullNix]

All problems persist even with "none". But this eliminates a bunch of tricksy assembler in the vs core as a possible cause, as well as its corresponding non-assembler variants, which is extremely valuable! Thank you!

(hmm, that's an idea. I'll roll back not only vapoursynth but also all vs plugins containing native code to the versions as of last year and see if the problem persists.)

No effect. What on earth is going on?!

So let's look closer. The clip I've been using starts out with blankness, concealing any funny stuff going on at its start. If you slice that blankness off (and take advantage of that to reduce the clip length to 10s to speed up experiments), it's clear that even with preset="ultra fast", TR=2, funny stuff is definitely still going on: it's just concentrated entirely at the start. It's obvious even without the soundtrack. The first frame is preserved, but the next second of the input appears to be silently erased: http://www.esperi.org.uk/~nix/encoding/slice.orig.vid vs the post-QTGMC http://www.esperi.org.uk/~nix/encoding/slice.qtgmc.y4m.

Small wonder the audio and video are desynchronized after that!

I'm fairly sure QTGMC isn't meant to silently drop frames :(

[HolyWu]

"screen" is not in the overlay avs version, but it's one of the more common compositing/photoshop blend modes used

More blend modes are added now. Please give it a try.

[poisondeathray]

More blend modes are added now. Please give it a try.

Thanks,

Something is buggy with the "normal" overlay mode with mask in the 20200624 version.

The overlay is partially transparent (but mask area seems correct; 100% white, 1023 in 10bit), and background colors change.

If I revert back to an older version, say 20200524 , it works ok

Test example
https://www.mediafire.com/file/fgyvklebtemnvoe/overlay_tests.7z/file


v = core.imwri.Read(r'RGB_10bit_grad_1024x480.dpx')
v = core.resize.Point(v, width=1024 , height=480, format=vs.YUV444P10, matrix_s="709", range_s="full")

ovr = core.imwri.Read(r'8bit_overlay.png', alpha=True)

ovr[0] = core.resize.Point(ovr[0], format=vs.YUV444P10, matrix_s="709", range_s="full")
ovr[1] = core.resize.Point(ovr[1], format=vs.YUV444P10, matrix_s="709", range_s="full")

v2 = haf.Overlay(v, ovr[0], mask=ovr[1])

#ovr[0].set_output()
#ovr[1].set_output()
#v.set_output()
v2.set_output()

[monohouse]

hi I have some problem with MCTD, it creates more noise looks like adding noise, it looks like white squares, very visible in the top left but if you look closely they are everywhare :x
http://manoa.dream.org.il/Pics/noise.png

import vapoursynth as vs
import havsfunc as haf

core = vs.get_core()
core.set_max_cache_size(7000)

clip = core.ffms2.Source("/mnt/2TWDPrimary/Babylon 5/Season 1/03. Born to the Purple.mkv")
clip = haf.QTGMC( clip, TFF=True, Preset="Placebo", ShowSettings=False, opencl=False, TR0=2, TR1=2, SourceMatch=0, TR2=0, Lossless=0, Sharpness=0 )
clip = haf.MCTemporalDenoise(clip, radius=3, limit=2, twopass=False, limit2=2, refine=True, useTTmpSm=True, stabilize=True, maxr=1, TTstr=1, chroma=False, MVsharp=False, sigma=0, pfMode=-1,search=3, searchparam=4, pel=4, pelsearch=4, bwbh=512, owoh=256, blksize=4, overlap=2, deblock=False, post=0,bt=4,thSAD=2000, thSAD2=2000, thSCD1=1000, thSCD2=200)
clip = haf.LSFmod(clip, defaults="slow",strength=20,Smode=3,Smethod=3,Lmode=0,overshoot=0,preblur="OFF",secure=False,edgemode=0,soft=0,soothe=False,ss_x=1.00,ss_y=1.00)
clip.set_output()

don't affraid the parameters, my system do this with encoding in 48 hours :)

this problem only exist in my new linux compiled vapoursynth system, I build all from source include the plugins, the python the vs iteself, the problem don't exist on windows, I tested without the QTGMC and without the LFSMOD to see that it's the MCTD the problem, funny there are no error messages, it just running and adding this noise, I try everything: remove and invert many of the MCTD parameters, nothing have effect, the processor is phenom 2 1090T, linux is devuan jessi.

edited: core.std.SetMaxCPU("none") fixed the problem :) ..... what's going on ?

[ChaosKing]

Could be a bug in the sse code path.

But does sigma=0 make sense?

You can also use presets and override them
settings : Global MCTemporalDenoise settings [default="low"] |
- "very low" |
- "low" |
- "medium" |
- "high" |
- "very high

[monohouse]

yhe I tested sigma many times, it was a littel too strong at the time.... but at the time I was doing radius=2 limit=1, now with radius=3 limit=2 it possible that sigma might beter :) the true is I don't realy know the real diffrence between radius+limit and sigma, my guess is that sigma is design for speed and radius+limit design for quality.

you know I realy like this system, almost all if not all plugins vectorized, many have vectorization written manually :) some have AVX2, even many latest games don't use AVX2 and use at most AVX1 if you lucky
I can't wait to build my faildozer system to see diffrence from phenom 2 becuase he have AVX1
the 4790K system runs some laps around the phenom 2, 3 times faster, all cpu no openCL, for some reason I don't get that mutch from OpenCL, mybe 0.04 fps faster out of 0.90
x264 also don't get almost nothing from OpenCL and I using latest version v160-3000, the card is almost not used at all like highest I ever see was 5%
someone with modern system that have AVX512 probably run many laps around the 4790K xD

[HolyWu]

The overlay is partially transparent (but mask area seems correct; 100% white, 1023 in 10bit), and background colors change.

When you manually convert a clip of Gray format to YUV format, the pixel values of chroma planes are set to 512 rather than 0, hence you get 50% transparency in the chroma planes during masking. Preferably the users should just leave the mask as Gray format when the mask is already of Gray format. Anyway I just added a mask_first_plane parameter to let the users decide whether only the first plane of the mask is used for masking.

[poisondeathray]

When you manually convert a clip of Gray format to YUV format, the pixel values of chroma planes are set to 512 rather than 0, hence you get 50% transparency in the chroma planes during masking. Preferably the users should just leave the mask as Gray format when the mask is already of Gray format. Anyway I just added a mask_first_plane parameter to let the users decide whether only the first plane of the mask is used for masking.

Right,

The problem in this case is the base clip is 10bit, but the overlay is 8bit, so you have to either scale on or the other to match.

So use Gray10 instead of YUV . And since there is no Gray10, you have to register it. I think you mentioned this already earlier...


ovr[1] = core.resize.Point(ovr[1], format=core.register_format(vs.GRAY, vs.INTEGER, 10, 0, 0).id, matrix_s="709", range_s="full")


Thanks for adding that parameter; I think many people are used to using a YUV clip with the "Y" plane as the mask

[HolyWu]

this problem only exist in my new linux compiled vapoursynth system, I build all from source include the plugins, the python the vs iteself, the problem don't exist on windows, ..., the processor is phenom 2 1090T, linux is devuan jessi.

edited: core.std.SetMaxCPU("none") fixed the problem :) ..... what's going on ?

Interestingly, you are using the same CPU as the one at https://github.com/vapoursynth/vapoursynth/issues/531, um...or you two are the same person? :D

If core.std.SetMaxCPU("none") fixed your problem, then there must be undiscovered bugs lying around, most probably Expr. Could you reproduce it with using only one function? Using three complex functions at once is difficult to hunt down the culprit.

[monohouse]

here it says that I runned 3 but the problem happen when only MCTD running, MCTD is the problem

I am testing now this
import vapoursynth as vs
import havsfunc as haf

core = vs.get_core()
core.set_max_cache_size(7000)

clip = core.ffms2.Source("/mnt/2TWDPrimary/Babylon 5/Season 1/03. Born to the Purple.mkv")
core.std.SetMaxCPU("sse2")
clip = haf.QTGMC( clip, TFF=True, Preset="Placebo", ShowSettings=False, opencl=False, TR0=2, TR1=2, SourceMatch=0, TR2=0, Lossless=0, Sharpness=0 )
core.std.SetMaxCPU("none")
clip = haf.MCTemporalDenoise(clip, radius=3, limit=2, twopass=False, limit2=2, refine=True, useTTmpSm=True, stabilize=True, maxr=1, TTstr=1, chroma=False, MVsharp=False, sigma=0, pfMode=-1,search=3, searchparam=4, pel=4, pelsearch=4, bwbh=512, owoh=256, blksize=4, overlap=2, deblock=False, post=0,bt=4,thSAD=2000, thSAD2=2000, thSCD1=1000, thSCD2=200)
core.std.SetMaxCPU("sse2")
clip = haf.LSFmod(clip, defaults="slow",strength=20,Smode=3,Smethod=3,Lmode=0,overshoot=0,preblur="OFF",secure=False,edgemode=0,soft=0,soothe=False,ss_x=1.00,ss_y=1.00)
clip.set_output()

but I have a new problem, probably nonsence but I don't know what it is :x

File "src/cython/vapoursynth.pyx", line 1956, in vapoursynth.vpy_evaluateScript
File "src/cython/vapoursynth.pyx", line 1957, in vapoursynth.vpy_evaluateScript
File "/mnt/b5/01. 3.vpy", line 23, in <module>
clip = haf.LSFmod(clip, defaults="slow",strength=20,Smode=3,Smethod=3,Lmode=0,overshoot=0,preblur=0,secure=False,edgemode=0,soft=0,soothe=False,ss_x=1.00,ss_y=1.00)
File "/mnt/apps/python-3.6.9/lib/python3.6/site-packages/havsfunc.py", line 4913, in LSFmod
normsharp = pre.cas.CAS(sharpness=min(Str, 1))
File "src/cython/vapoursynth.pyx", line 1233, in vapoursynth.VideoNode.__getattr__
AttributeError: There is no attribute or namespace named cas

this could be it ? https://github.com/HomeOfVapourSynthEvolution/VapourSynth-CAS

[ChaosKing]

this could be it ? https://github.com/HomeOfVapourSynthEvolution/VapourSynth-CAS
correct

[monohouse]

should I change the parameters like strenth or the new CAS method look the same in term of amount ?

I wanne ask you something else: phenom 2, have SSE3 (not suplemental) and SSE4A, some other call 3dnow and some mmx, whay all this is not used with manually written asembly in any of the plugins ?
they are not used in vs iteself too

I am testing now this
import vapoursynth as vs
import havsfunc as haf

core = vs.get_core()
core.set_max_cache_size(7000)

clip = core.ffms2.Source("/mnt/2TWDPrimary/Babylon 5/Season 1/03. Born to the Purple.mkv")
core.std.SetMaxCPU("sse2")
clip = haf.QTGMC( clip, TFF=True, Preset="Placebo", ShowSettings=False, opencl=False, TR0=2, TR1=2, SourceMatch=0, TR2=0, Lossless=0, Sharpness=0 )
core.std.SetMaxCPU("none")
clip = haf.MCTemporalDenoise(clip, radius=3, limit=2, twopass=False, limit2=2, refine=True, useTTmpSm=True, stabilize=True, maxr=1, TTstr=1, chroma=False, MVsharp=False, sigma=0, pfMode=-1,search=3, searchparam=4, pel=4, pelsearch=4, bwbh=512, owoh=256, blksize=4, overlap=2, deblock=False, post=0,bt=4,thSAD=2000, thSAD2=2000, thSCD1=1000, thSCD2=200)
core.std.SetMaxCPU("sse2")
clip = haf.LSFmod(clip, defaults="slow",strength=20,Smode=3,Smethod=3,Lmode=0,overshoot=0,preblur="OFF",secure=False,edgemode=0,soft=0,soothe=False,ss_x=1.00,ss_y=1.00)
clip.set_output()

edited: this is working correctly :)

[cwk]

Interestingly, you are using the same CPU as the one at https://github.com/vapoursynth/vapoursynth/issues/531, um...or you two are the same person? :D


No, that was me :). And I'm only using the Phenom II until my Ryzen 3950 arrives...

I should note that I have not experience the expr issue with R49 or R50 of Vapoursynth. The expr bug has been fixed. @monohouse, be sure you are using current Vapoursynth if you are still experiencing this issue.

[monohouse]

is there a vs plugin that allow to adjust contrast ?

[poisondeathray]

is there a vs plugin that allow to adjust contrast ?



It depends on what you mean by "contrast".

adjust.py has "contrast" from avisynth's tweak ; or you can use smoothlevels or levels, or curve to adjust levels, and thus contrast

[monohouse]

thank :) adjust is nice :) whare do you think best to put it in this script ?
I used cont but he is not doing contrast, he is just putting everything down :x
contrast I meen: bright is a littel brighter, dark is a littel darker

I tryed this: haf.SmoothLevels(clip, input_low=8, output_low=0, input_high=247, output_high=255, gamma=1)
but what he is doing is cutting everything below 8 and throw it, I dont wanne cut it off and throw, I wanne reduce it, a littel and increase a littel

[poisondeathray]

contrast I meen: bright is a littel brighter, dark is a littel darker

You can use levels, smoothlevels, or curve

[monohouse]

LSFmod Smode=2 broked with git version
clip = haf.LSFmod(clip, defaults="slow",strength=20,Smode=2,Smethod=3,Lmode=0,overshoot=0,preblur=-1,secure=False,edgemode=0,soft=0,soothe=False,ss_x=1.00,ss_y=1.00)
http://manoa.dream.org.il/Pics/Smode2.png

[poisondeathray]

LSFmod Smode=2 broked with git version
clip = haf.LSFmod(clip, defaults="slow",strength=20,Smode=2,Smethod=3,Lmode=0,overshoot=0,preblur=-1,secure=False,edgemode=0,soft=0,soothe=False,ss_x=1.00,ss_y=1.00)

<snip>


Works for me as expected without those errors

What pixel type? what source filter?

Maybe it's related to one of the CPU instruction bugs ?