HAvsFunc

[poisondeathray]

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

That does what you wanted, bright brighter, dark darker, increases contrast . But it also depends what you started with

The filter is not cutting and throwing. Clipping will be done by the RGB conversion for display if you have Y <16 , or >235 , not by the filter in YUV. The data is still there in YUV

Maybe you are not describing things correctly ? Maybe you want it closer to Y 16-235 ? Maybe posting a sample video would help?

[monohouse]

YUV420P, ffms2
problem start since version 72c1f8e6672c4aafabfd54d57a96eef9e969591d
whare it show mutch bigger squares than you see in this picture

it ok I fixed the contrast :)
clip = adj.Tweak(clip, bright=-1, cont=1.00392156862745098, coring=False)

[poisondeathray]

For smoothlevels, you can also use Lmode for limiting strength at the bright and dark ends 16-235. But it's not working in vapoursynth version . AVS version works ok

eg.
clip = haf.SmoothLevels(clip, input_low=16, gamma=1, input_high=235, output_low=0, output_high=255, Lmode=3)


"Python exception: SmoothLevels: Ecurve=0 is unusable at the moment due to missing sin operator in Expr"

:(



I can't reproduce the LSFMod error. What are your clip dimensions?

[monohouse]

720x480

[HolyWu]

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)

Cannot reproduce it with the exactly same arguments. Have you tried core.std.SetMaxCPU("none")?


For smoothlevels, you can also use Lmode for limiting strength at the bright and dark ends 16-235. But it's not working in vapoursynth version . AVS version works ok

eg.
clip = haf.SmoothLevels(clip, input_low=16, gamma=1, input_high=235, output_low=0, output_high=255, Lmode=3)

"Python exception: SmoothLevels: Ecurve=0 is unusable at the moment due to missing sin operator in Expr"

Ecurve=1 is still usable for Lmode. Or maybe I should default Ecurve to 1 in the meantime...

[poisondeathray]

Ecurve=1 is still usable for Lmode. Or maybe I should default Ecurve to 1 in the meantime...

Yes, Ecurve=1 works...

(I thought there was an issue with Lmode=3, but the numbers correspond differently compared to AVS version. Lmode=1 is for both bright and dark in the VPY version)

[monohouse]

yip, look like you guys was right :) core.std.SetMaxCPU("none") fixed the problem :)

thank :) I tested
clip = haf.SmoothLevels(clip, input_low=2, gamma=1, input_high=254, output_low=0, output_high=255, Lmode=3, Ecurve=1)
but it look too bright and I don't know whay but also incrased noise, some geometry distortions too
clip = adj.Tweak(clip, bright=-2, cont=1.00392156862745098, coring=False)
worked bether in this movie, it also increased effect of all the other plugins when in the top of the list :)

[HolyWu]

Update r33:

aaf: Fix argument type error.
Add functions daa3mod and mcdaa3.
Make FineDehalo_contrasharp an external function.
Add 32 bit float support to Overlay, LSFmod, Deblock_QED, DeHalo_alpha, FineDehalo, Vinverse, Vinverse2, GrainFactory3, SmoothLevels, and FastLineDarkenMOD.
QTGMC: Always mark the output as frame based before returning clip.
Overlay: Add new blend modes addition, average, burn, darken, difference, divide, dodge, exclusion, extremity, freeze, glow, grainextract, grainmerge, hardlight, hardmix, heat, lighten, linearlight, multiply, negation, overlay, phoenix, pinlight, reflect, screen, softlight, subtract, and vividlight.
Overlay: Add parameters planes and mask_first_plane.
DeHalo_alpha: Fix division by zero in Expr.
DeHalo_alpha: Explicitly use Mitchell-Netravali in some Bicubic resizing since zimg has changed the default to Catmull-Rom and the filtering result differs.
EdgeCleaner, FineDehalo, HQDeringmod, MCTemporalDenoise: Create mask by AvsPrewitt instead of Sobel to more closely match the result.
LSFmod: Add Smode=3 and change the defaults.
LSFmod: Add new preblur modes.
SmoothLevels: Change default useDB to false.
SmoothLevels: Change default Ecurve to 1.
SMDegrain: Use MinBlur for prefilter 1 and 2 again.

[ChaosKing]

clip = mvf.Depth(clip, 32)
clip = haf.FineDehalo(clip, rx=2.7, darkstr=1, contra=0.5)
vapoursynth.Error: CTMF: only constant format 8, 10, 12, 14 or 16 bits integer input supported

And with haf.DeHalo_alpha(clip, rx=2.7, darkstr=1)
https://i.imgur.com/PRljbEA.png

[HolyWu]

clip = mvf.Depth(clip, 32)
clip = haf.FineDehalo(clip, rx=2.7, darkstr=1, contra=0.5)
vapoursynth.Error: CTMF: only constant format 8, 10, 12, 14 or 16 bits integer input supported

And with haf.DeHalo_alpha(clip, rx=2.7, darkstr=1)

Oops! DeHalo_alpha float issue should be fixed now. For CTMF...I totally forgot about it still not supporting float. Will add float support specifically for radius 2 later.

[ChaosKing]

32 looks good now.
But if you look closely 8 bit and 16bit are also a bit different...

EDIT
I had a mistake in my script, all good now.

[ChaosKing]

c32 = mvf.Depth(clip, 32)
c32 = haf.daa3mod (c32)

vapoursynth.Error: znedi3: failed to create nnedi3

8-16 = ok

[HolyWu]

vapoursynth.Error: znedi3: failed to create nnedi3

8-16 = ok

https://github.com/sekrit-twc/znedi3/commit/169b9958bd4fdb5131a6e81feb837bb32f33731b

Go pushing author to release a new version. :devil:

[feisty2]

I guess smdegrain could support arbitrary temporal radius (tr > 3) and cosine annealing (thSAD2), these features are present in the avs version and are now also natively supported by my fork of mvtools.
the logic would probably be something like

MAnalyze = None
MDegrain = None
if BitsPerSample == 32 or tr > 3 or thSAD2 is not None:
MAnalyze = core.mvsf.Analyze
MDegrain = core.mvsf.Degrain
else:
MAnalyze = core.mv.Analyse
MDegrain = core.mv.Degrain1/2/3

[HolyWu]

I guess smdegrain could support arbitrary temporal radius (tr > 3) and cosine annealing (thSAD2), these features are present in the avs version and are now also natively supported by my fork of mvtools.

Yeah...except its slowness outweighs usefulness for most users due to lack of SIMD optimizations. I'd rather just have a GPU port of mvtools for full 8-32 bit support...when I eventually decide to begin coding it.

[ChaosKing]

A GPU port would be a dream :eek:

[ChaosKing]

https://github.com/sekrit-twc/znedi3/commit/169b9958bd4fdb5131a6e81feb837bb32f33731b

Go pushing author to release a new version. :devil:

done, next problem:
vapoursynth.Error: Repair: Only 8-16 bit int formats supported

[HolyWu]

done, next problem:
vapoursynth.Error: Repair: Only 8-16 bit int formats supported

Currently I don't explicitly give an error for functions not supporting 32 bit float since in the end the underlying filters being used will throw an error anyway and hence the users will know it.

[ChaosKing]

For some reason I thought daa3mod was also mentioned in the "Add 32 bit float support to ..." line :o

[Soichiro]

Hi, since updating to r33, I get an error "AttributeError: There is no attribute or namespace named dfttest" when trying to use `havsfunc.MCTemporalDenoise`. I was able to use this filter before updating, and I attempted reinstalling dfttest as well. I'm on Arch Linux, Vapoursynth R50.

[HolyWu]

Hi, since updating to r33, I get an error "AttributeError: There is no attribute or namespace named dfttest" when trying to use `havsfunc.MCTemporalDenoise`. I was able to use this filter before updating, and I attempted reinstalling dfttest as well. I'm on Arch Linux, Vapoursynth R50.

I don't think your error has anything to do with havsfunc. You can try core.std.BlankClip().dfttest.DFTTest() without using havsfunc at all to make sure.

Did you compile DFTTest from source or install it via distribution package? Is it r6 or r7? What happen if you try the other version?

[Soichiro]

You're right, the example with BlankClip also does not work. I am installing dfttest (and all VS plugins) from the Arch AUR. I've tested with both r6 and r7 of dfttest, and r32 and r33 of muvsfunc. On manually adding a LoadPlugin call, I'm able to get vapoursynth to output the error that it can't find the symbol `fftwf_make_planner_thread_safe`, even though I have fftw installed. (Of course with autoloading, Vapoursynth just silently fails on plugins that have issues...) So, you're right, it does seem like a local machine issue, and not sure how my machine ended up in this state, but that means I'll keep debugging the separate issue. Thanks.

[Soichiro]

It looks like the issue is that, at least on Arch, fftw's pkgconfig files do not include -lfftw3f_threads, which is needed for dfttest to work. So, in case anyone else on Linux runs into the issue, the workaround is to add -lfftw3f_threads to the libs line in /usr/lib/pkgconfig/fftw3f.pc, then rebuild dfttest.

[HolyWu]

It looks like the issue is that, at least on Arch, fftw's pkgconfig files do not include -lfftw3f_threads, which is needed for dfttest to work. So, in case anyone else on Linux runs into the issue, the workaround is to add -lfftw3f_threads to the libs line in /usr/lib/pkgconfig/fftw3f.pc, then rebuild dfttest.

Ah, I missed that. Updated meson.build accordingly. :goodpost:

[Soichiro]

Thanks! Confirmed that the meson fix in dfttest fixes the issue.

[NullNix]

I finally tracked down the proximate cause of the bug I reported earlier where vapoursynth was generating horrifically chopped-up frames when QTGMC was run over it, at least enough to have a workaround of sorts. As others suggested, the source was at fault, though I still don't quite understand why.

If I use the (makemkv-derived) MKV as the vspipe source, all is well: if I mkvextract the video stream from it and use that (which is what I've been doing without incident for years before now), the chopped-up mess results, even though vspipe is only meant to be using the video stream in any case. I thought video streams were meant to be more-or-less separable from their containers, but this doesn't seem to be true with this one. mpv says that the extracted stream has no timestamps and that ffmpeg is going to make them up, and get them horribly wrong: maybe this is an unusual input, or maybe makemkv's behaviour has changed and it's sticking timestamps in in some unusual fashion now such that mkvextract is no longer cleanly extracting them (one downside of closed-source software is that I can't easily tell which it might be).

So... I guess I'll take my ever-more-obviously catastrophic ignorance on this subject and go away :) sorry to bother everyone.

[lansing]

Your github readme needs update to show the new functions. I was looking for the overlay function but couldn't find it until I searched for a specific overlay mode.

[lansing]

bug report, I Overlay() a YUV444P16 clip on top of a GRAY16 clip but there's no warning about format mismatch.


clip_yuv16 = core.resize.Bicubic(clip, format=vs.YUV444P16)
overlay_clip = core.std.BlankClip(clip_yuv16, color=[0, 220/255*MaxSize16bit, 0])
output_clip = haf.Overlay(clip_yuv16, overlay_clip, mode="lighten")


And here the "lighten" doesn't look right. I compared the result to "lighten" overlay in photoshop and they're so different.

And setting mode="darken" gives a greenish frame.

[poisondeathray]

bug report, I Overlay() a YUV444P16 clip on top of a GRAY16 clip but there's no warning about format mismatch.


clip_yuv16 = core.resize.Bicubic(clip, format=vs.YUV444P16)
overlay_clip = core.std.BlankClip(clip_yuv16, color=[0, 220/255*MaxSize16bit, 0])
output_clip = haf.Overlay(clip_yuv16, overlay_clip, mode="lighten")


And here the "lighten" doesn't look right. I compared the result to "lighten" overlay in photoshop and they're so different.

And setting mode="darken" gives a greenish frame.


That's not GRAY16 . GRAY16 has 1 channel

Photoshop works in RGB . RGB is an additive color model. You would expect different visual results with blend modes in YUV

[lansing]

That's not GRAY16 . GRAY16 has 1 channel

Photoshop works in RGB . RGB is an additive color model. You would expect different visual results with blend modes in YUV

I was reporting three separate issues, the code was referring to the second issue with "lighten" overlay mode.

I just tested with a RGB24 clip overlay on a RGB24 clip, the result matches the one from photoshop. So the Overlay function only works on RGB, it should have a check to restrict it to RGB clips only.

[poisondeathray]

I just tested with a RGB24 clip overlay on a RGB24 clip, the result matches the one from photoshop. So the Overlay function only works on RGB, it should have a check to restrict it to RGB clips only.

For some of the other blend modes the math only makes sense to work in RGB.

But in "normal" mode it works ok with other pixel formats . It's used all the time in YUV. Other programs like browsers use YUVA overlays (YUVA444P, YUVA420P) too . It's one of the main benefits of using Overlay in avisynth/vapoursynth or mt_merge . YUV overlays. No additional deterioration from going into RGB back to YUV.

[MythCreator]

A issue about r33. I put CAS.dll under plugin64 folder, but when I use LSFmod, the Editor keep send error code "There is no attribute or namespace named cas"

[ChaosKing]

Sound like cas.dll is not loaded. Try to load it manually and see what error code it shows. std.Loadplugin()

[MythCreator]

Sound like cas.dll is not loaded. Try to load it manually and see what error code it shows. std.Loadplugin()

Thanks. std.Loadplugin works fine.

[l00t]

Dear HolyWu,

If you have some spare time, would you be so kind to port InpaintDelogo to VS? I only found DelogoHD available for VS, but making an lgd file is a pain-in-the-a** compared to VoodooFX's automated process...

https://forum.doom9.org/showthread.php?t=176860

Thanks in advance!

[Adub]

InpaintDelogo requires AvsInpaint, which is a Avisynth plugin. So, a manual load of the Avisynth plugin may be required, since there's no native Vapoursynth equivalent. I have no idea if LoadPlugin works for AvsInpaint (it might - I haven't tried), but I'd be a little surprised if HolyWu wanted to add support for a function that requires non-native Vapoursynth plugins.

[lansing]

When running QTGMC, I'm getting a log "AvstpWrapper: cannot find avstp.dll.Usage restricted to single threading" in the console

[Jukus]

When running QTGMC, I'm getting a log "AvstpWrapper: cannot find avstp.dll.Usage restricted to single threading" in the console
I don't confirm.

[ChaosKing]

When running QTGMC, I'm getting a log "AvstpWrapper: cannot find avstp.dll.Usage restricted to single threading" in the console

Can you show your parameters? I never have seen this message with qtgmc.

[lansing]

Can you show your parameters? I never have seen this message with qtgmc.

I was catching this log in the Qt Creator's debug console. I tried all QTGMC presets and they all have this message.

[ChaosKing]

Ah yes, I can see it in DebugView++ now. Could be some of the used filters in QTGMC. I think I saw once Myrsloik posting an image of the generated filter graph by a VS script. I can't find it right now, but could be handy to quickly check which plugins are beiing used...

edit
Avisynth has DumpFilterGraph(), does VS has something similar build in?

[Myrsloik]

Ah yes, I can see it in DebugView++ now. Could be some of the used filters in QTGMC. I think I saw once Myrsloik posting an image of the generated filter graph by a VS script. I can't find it right now, but could be handy to quickly check which plugins are beiing used...

edit
Avisynth has DumpFilterGraph(), does VS has something similar build in?

Only in the API R4 test builds.

[HolyWu]

When running QTGMC, I'm getting a log "AvstpWrapper: cannot find avstp.dll.Usage restricted to single threading" in the console

https://github.com/EleonoreMizo/fmtconv/blob/4f187bf5b7fe116d98a55910d597146b6b3a79a8/src/AvstpWrapper.cpp#L160

[lansing]

https://github.com/EleonoreMizo/fmtconv/blob/4f187bf5b7fe116d98a55910d597146b6b3a79a8/src/AvstpWrapper.cpp#L160

So does that mean I'm running something single thread?

[Julek]

Since you have ported TDeint, is there any chance that you also port MTCombMask?
https://github.com/Asd-g/MTCombMask
In some cases it does better than the current CombMask, capturing some areas that CombMask ignores.

[lansing]

QTGMC() needs update as of R56 since filters under core.misc namespace has been changed.

[ChaosKing]

Namespace has been changed? misc is an external plugin now. So "vsrepo install misc" and everything is back to where it was.

[lansing]

Namespace has been changed? misc is an external plugin now. So "vsrepo install misc" and everything is back to where it was.

Thanks it works.

[cogman]

Any path forward for us linux folk? How hard is it to build the v3 libs and use them with v4?

[Myrsloik]

Any path forward for us linux folk? How hard is it to build the v3 libs and use them with v4?

Same as windows. Very easy. Almost all API3 stuff still works.

All split out plugins can be found here. Build system included with most.
https://github.com/vapoursynth