Things missing in Vapoursynth,....

[Selur]

Here are a few things I miss in Vapoursynth:

RemoveDirt port where RestoreMotionBlocks works; works for some resolutions mods (https://forum.doom9.org/showthread.php?t=185121)
DeSpot filter (lostfuncs DeSpot simple isn't the same and lacks tons of options)
sRestore port as a filter
AnimeIVTC port
ColorYUV, SmoothTweak, SmoothCurve, AutoAdjust, AutoLeves, HDRAGC port
amDCT port
Waveform filter to see audio wave
Exblend port
An option to disable autoloading for a script.
Waveform port
TDecimate which works with mode=2 (https://github.com/dubhater/vapoursynth-tivtc/issues/4)
InpaintDelogo port
Proper Overlay port that works like in Avisynth (https://forum.doom9.org/showthread.php?t=186264)
Histogram (https://github.com/dubhater/vapoursynth-histogram) port with high bit depth support
Deflicker port



Cu Selur

[ChaosKing]

Cdeblend suffers from the same problem as srestore (linear cache)

[Selur]

Added DeScratch which I really like.

[Myrsloik]

Added DeScratch which I really like.

Is this the most recent version of the source code? Should be a quick port
http://www.avisynth.nl/index.php/DeScratch

[Selur]

I think so, at least that is the latest version I know of.
A port would be nice.

Cu Selur

[Myrsloik]

I think so, at least that is the latest version I know of.
A port would be nice.

Cu Selur

Would you happen to have a small test clip and some reasonable settings so I can verify that my port works?

[Selur]

Not so small clip example: https://forum.videohelp.com/threads/407079-Restoring-an-old-dirty-scratched-film-%28manually-if-possible%29
usually, I takes multiple calls:

f = f.DeScratch(maxgap=5,minlen=30,maxangle=55)
f = f.DeScratch(maxgap=25,minlen=25,maxangle=30)

to remove static scratches, but it's really helpful with scratches in old captures.
(+ you often use it scene by scene)

Cu Selur

[Myrsloik]

Please test and report your findings before I make a proper release. See it as the one true successor fork since I support both avs and vs and cleaned up the code quite a bit.
https://github.com/vapoursynth/descratch/releases/tag/Test1

[poisondeathray]

Thanks, DeScratch appears to work ok (same results as v1.1.0 avs version). Is it possible to support other pixel formats than YV12 ?

[Selur]

Will do some test later today and report back.

[Myrsloik]

Thanks, DeScratch appears to work ok (same results as v1.1.0 avs version). Is it possible to support other pixel formats than YV12 ?

Sure, YV16 and YV24 added and appear to work since the planes are separately processed anyway.

Higher bitdepths is probably just a waste of time anyway. It's also somewhat annoying since the code mixes up row size and width.

[Selur]

Works fine here too. YV16 and YV24 would be nice. I agree, high bit depth should not be really needed since I have never used this on anything but old tape scans or similar. :)
Thanks for porting this!

Cu Selur

[Myrsloik]

Works fine here too. YV16 and YV24 would be nice. I agree, high bit depth should not be really needed since I have never used this on anything but old tape scans or similar. :)
Thanks for porting this!

Cu Selur

First and probably only release is up. Would be great if someone edits the avisynth wiki so more people can find it.

[Reel.Deel]

First and probably only release is up. Would be great if someone edits the avisynth wiki so more people can find it.

Will do. Thanks for the update!

[Myrsloik]

This is the most recent source and the correct despot version?
http://avisynth.nl/index.php/DeSpot

Looks like YV24 support and YV16 is easily doable as improvement (only has the ancient YUY2 planar hack and nobody likes that).

[Selur]

Yes, v3.6.3.1 is the latest version.

[Selur]

@myrsloik: seeing that you started to do a proper port of Despot over at https://github.com/vapoursynth/despot I just wanted to know if there is hope for a release? :)

[Myrsloik]

@myrsloik: seeing that you started to do a proper port of Despot over at https://github.com/vapoursynth/despot I just wanted to know if there is hope for a release? :)

My time ran out before I could add VS support. At the moment it's just a cleaned up avs+ version if you bother to compile it.

The main problem is that the code uses convoluted ways to avoid memory allocation and is by modern standards quite insane. Except in some modes where it forgets all about it and allocates like crazy. Maybe I'll have time to poke it again in a few weeks. Code archeology at its finest...

[Selur]

Thanks for the info!

[juanitogan]

Please test and report your findings before I make a proper release. See it as the one true successor fork since I support both avs and vs and cleaned up the code quite a bit.
https://github.com/vapoursynth/descratch/releases/tag/Test1
Has anyone completed filtering a full-length HD film with DeScratch V2.0 in VS?

I've tried several times with Hybrid and it keeps failing after a few minutes. Never on the same frame. Have tried two different films with the same results. The older AS version of this filter in Hybrid works fine on the same content.

To me, it looks like a memory leak. I start the job with about 5GB of mem full, out of 12GB. It creeps up to 12GB, bounces around up there for a few minutes, until, presumably, DeScratch steals it all and crashes. It encodes about 2-3 minutes of HD material before it quits. I can get it to go a bit longer if I turn off Hybrid's built-in feature and add DeScratch as a custom command with YUV422P8 color instead of YUV444P8. And another bit longer with YUV420P8.

Another observation is that this new VS version of DeScratch is better at avoiding false positives between the characters in overlay text (or the text itself), versus the AS version (with the same settings, of course). With the AS version, I have to set the minlen 2 or 3 times taller than the text (red text, btw). This version simply ignores the text regardless of how low I set minlen. I had a hunch this was due to YUV444P8 and, sure enough, when I set it to YUV420P8, the VS version runs just like the AS version on this front. Thus, it would be extra nice to run on YUV444P8, assuming that's not a glitch.

[Myrsloik]

Has anyone completed filtering a full-length HD film with DeScratch V2.0 in VS?

I've tried several times with Hybrid and it keeps failing after a few minutes. Never on the same frame. Have tried two different films with the same results. The older AS version of this filter in Hybrid works fine on the same content.

To me, it looks like a memory leak. I start the job with about 5GB of mem full, out of 12GB. It creeps up to 12GB, bounces around up there for a few minutes, until, presumably, DeScratch steals it all and crashes. It encodes about 2-3 minutes of HD material before it quits. I can get it to go a bit longer if I turn off Hybrid's built-in feature and add DeScratch as a custom command with YUV422P8 color instead of YUV444P8. And another bit longer with YUV420P8.

Another observation is that this new VS version of DeScratch is better at avoiding false positives between the characters in overlay text (or the text itself), versus the AS version (with the same settings, of course). With the AS version, I have to set the minlen 2 or 3 times taller than the text (red text, btw). This version simply ignores the text regardless of how low I set minlen. I had a hunch this was due to YUV444P8 and, sure enough, when I set it to YUV420P8, the VS version runs just like the AS version on this front. Thus, it would be extra nice to run on YUV444P8, assuming that's not a glitch.

Fixed and updated.

[Selur]

Thanks, I us DeScratch usually only on specific scenes, which is probably why I didn't encounter the problem.

[juanitogan]

Thank you for the very quick fix. Sorry it took a few day for me to test it and report back. I had only Hybrid installed, which is still on VS API 4.0, and this was compiled for API 4.1. Thus, I just now got around to installing VS portable for a quick vspipe to ffmpeg test on the same material.

83 minutes of 1440x1080 was just processed without issue; default DeScratch settings, YUV444P8.

[juanitogan]

Now, to answer the original post, for what my 2 cents is worth. With AutoAdjust, or maybe AutoLevels, I would likely never have to go back to Avisynth again. I'm just a hobbyist and don't have time to level each scene, so it's either auto, or leave as is.

[hydra3333]

ColorYUV, SmoothLevels, SmoothTweak, SmoothCurve, AutoAdjust, HDRAGC port
[/list]


At the risk of being entirely wrong, I suspect DG may be conducive to considering one or more variants of these, perhaps including HDRAGC which would be handy for automatic full-clip "close enough on average" fixing, in upcoming cusdasynth (cuda enabled) filters.

One could maybe consider reading about or even providing encouragement by posting support for such over in a relevant thread, possibly https://rationalqm.us/board/viewtopic.php?f=14&t=671 ?

Of course GPU enabled filters would, in general, be super fast as compared to cpu based filters, especially with the cudasynth approach of (as I understand it anyway) maintaining frames in gpu memory and being passed between gpu filters rather than performing (comparatively expensive) data round trips up and down the bus. As always, ymmv I guess.

[Selur]

New filters are always welcome. :) A better HDRAGC would be nice.
Hoping that the "Currently, the utility filters DGDenoise(), DGBob(), etc., are available only when DGDecodeNV is used in native Avisynth mode." thing will be gone too someday. :)

[hydra3333]

Cool. I'm not sure whether that applies to the new cudasynth dgsource which has those filters in with it, or to the other ?single dll with multiple filters? thing which has been proposed.

[hydra3333]

To clarify, the single dll thing is a planned "DGFilters()" which will include ALL DG filters while not requiring DGSource() as the source filter. They will be cudasynth enabled and hopefully include one or more of the aforementioned filters.
So, I guess that means load the single dll and then bob's your uncle in using the included gpu filters.
I gather they will be vapoursynthized, whatever that entails.

[Selur]

@Myrsloik:
trying to use R2, I get:
Python exception: Core only supports API R4.0 but the loaded plugin requires API R4.1; Filename: F:/Hybrid/64bit/vsfilters/DenoiseFilter/DeScratch/DeScratch.dll; Name: DeScratch for Vapoursynth and friends
This does mean, that I can't use it with Vapoursynth R65, right?
can't use R66 atm. due to Python 3.12 which isn't supported by some pytorch stuff, Hybrid uses.
=> would it be possible to also release a R4.0 compatible version? (if it's too much hassle, that is fine too; I'll remove DeScratch from Hybrid till I can transition to R66 then)

[Myrsloik]

@Myrsloik:
trying to use R2, I get:

This does mean, that I can't use it with Vapoursynth R65, right?
can't use R66 atm. due to Python 3.12 which isn't supported by some pytorch stuff, Hybrid uses.
=> would it be possible to also release a R4.0 compatible version? (if it's too much hassle, that is fine too; I'll remove DeScratch from Hybrid till I can transition to R66 then)

I plan to make API 4.1 opt-in in the VS headers since they contain very little of general filter interest. Maybe I'll recompile it as a test.

[juanitogan]

can't use R66 atm. due to Python 3.12 which isn't supported by some pytorch stuff, Hybrid uses.

Ooooh... that partly explains why I wasn't able to upgrade Hybrid's VS to R66 on my own. I brought in the portable version with Python 3.12 but, yeah, couldn't see all that it was breaking. Fiddling with that is another reason why it took me so long to test the last compile of DeScratch. But that's on me for hoping I could figure it out without asking.

[Selur]

@juanitogan: Switchting to R66 will break on two ends:
a. vsViewer needs to be compiled against it
b. using the torch-addon doesn't work atm. since some dependencies are not Python 3.12 compatible (iirc. I could get everything except BasicVSR++ working; there the problem is the mmcv dependency)

Cu Selur

[Myrsloik]

@Myrsloik:
trying to use R2, I get:

This does mean, that I can't use it with Vapoursynth R65, right?
can't use R66 atm. due to Python 3.12 which isn't supported by some pytorch stuff, Hybrid uses.
=> would it be possible to also release a R4.0 compatible version? (if it's too much hassle, that is fine too; I'll remove DeScratch from Hybrid till I can transition to R66 then)

Descratch R3 released which works with all versions

[Selur]

Thanks a lot! I can confirm that it works fine with R65. :)

Cu Selur

[Selur]

My time ran out before I could add VS support. At the moment it's just a cleaned up avs+ version if you bother to compile it.

The main problem is that the code uses convoluted ways to avoid memory allocation and is by modern standards quite insane. Except in some modes where it forgets all about it and allocates like crazy. Maybe I'll have time to poke it again in a few weeks. Code archeology at its finest...
@Myrsloik: Ping :) Just hoping you find some time to look into it. :)

[Myrsloik]

@Myrsloik: Ping :) Just hoping you find some time to look into it. :)

Time not found. But feel free to continue the work. The real blocker is untangling the insane memory handling in it.

[Selur]

Fair enough, just wanted to check. (Sadly I have no clue about memory handling.)

btw. removed Inpainting from the list since ProPainter does a good job there. :)

Cu Selur

[Selur]

added 'TDecimate which works with mode=2'.

[Selur]

added 'Overlay'