Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 3rd August 2023, 10:20   #2701  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,616
Quote:
Originally Posted by kedautinh12 View Post
It's belong to TransformsPack - Main
My fault. I updated from 2.0.0 to 2.2.0 and I had 2 copies of the same file for main and models.

Thank you!
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 11th August 2023, 11:33   #2702  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,160
Users frequently ask for the use of some new features of mvtools2 in the SMDegrain script. As full-featured latest releases (marked with -a.XX tag) are not stable in many use cases I make some small extract of the most simple and useful features expected to be safe from bugs.

It is release https://github.com/DTL2020/mvtools/r.../r.2.7.46-e.01

Though it is based on latest commits by pinterf in 2021 after 2.7.45 release and not much tested.

It has only 2 new features added:
1. "SuperCurrent" second super clip input in the MAnalyse - so in the use cases with prefiltering or multi-generations MVs refining (when MDegrain used as 'prefilter' from previous generation MVs) 2 super clips may be feed to MAnalyse. The 1st may be original non-distorted by any processing input 'super' clip and second after some pre-processing. It may decrease MVs search errors.

If SuperCurrent input clip is not provided - MAnalyse uses a single super clip for both inputs of MV search algorithm for 'current' and 'reference' frames. As in the versions of 2.7.45 and before.

2. Auto-thSAD feature for MDegrainN - described in the https://forum.doom9.org/showthread.p...83#post1990183

These new features are expected to be independent from block size / bitdepth and work with any combination.

Extracting of more useful features for MDegrainN like interpolated overlap and MVLPF is significantly more complex (also may be more buggy) so expected in some time later if this e.01 extract release will be tested as stable enough. They are also independent of blocksize and bitdepth so may be used in complex universal scripts like SMDegrain.

Last edited by DTL; 11th August 2023 at 17:48.
DTL is offline   Reply With Quote
Old 11th August 2023, 13:39   #2703  |  Link
LeXXuz
21 years and counting...
 
LeXXuz's Avatar
 
Join Date: Oct 2002
Location: Germany
Posts: 716
Quote:
Originally Posted by DTL View Post
2. Auto-thSAD feature for MDegrainN - described in the https://forum.doom9.org/showthread.p...83#post1990183
Oh I want that. Pretty please with a cherry on top @ Dogway
LeXXuz is offline   Reply With Quote
Old 11th August 2023, 14:03   #2704  |  Link
kedautinh12
Registered User
 
Join Date: Jan 2018
Posts: 2,160
No, hard to use cause DTL's MVTools change many things and don't stable with many scripts use Pinterf's MVTools. If copy and change name, it will have 2 function duplicate
kedautinh12 is offline   Reply With Quote
Old 11th August 2023, 14:26   #2705  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,160
Build with -e.01 tag is special edition expected to be compatible with scripts running with 2.7.45 by pinterf. It is based on latest commits to pinterf repository in 2021 (only a few after 2.7.45 release). If it still not stable - I can try to use exact 2.7.45 sources (but they cause some debug assert fail in MDegrainN with default block size 8x8 and it was fixed by pinterf later - looks like this commit https://github.com/pinterf/mvtools/c...be475b1b2e045c ).
DTL is offline   Reply With Quote
Old 11th August 2023, 15:58   #2706  |  Link
anton_foy
Registered User
 
Join Date: Dec 2005
Location: Sweden
Posts: 703
Quote:
Originally Posted by DTL View Post
Build with -e.01 tag is special edition expected to be compatible with scripts running with 2.7.45 by pinterf. It is based on latest commits to pinterf repository in 2021 (only a few after 2.7.45 release). If it still not stable - I can try to use exact 2.7.45 sources (but they cause some debug assert fail in MDegrainN with default block size 8x8 and it was fixed by pinterf later - looks like this commit https://github.com/pinterf/mvtools/c...be475b1b2e045c ).
Lovely! Now I think it is time for me at least to make it into Clay. So the base is Pinterf's build with added features from you DTL? Does mrecalculate not work with this build and mdegrain2 aswell?
anton_foy is offline   Reply With Quote
Old 11th August 2023, 17:33   #2707  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,160
The Auto-thSAD added only to MDegrainN. All other filters are expected to work the same as in the 2.7.45 release. Though latest commits by pinterf in 2021 really have some additions to MAnalyse too (like optSearchOption and optPredictorsType) but I hope if users will not enable them - it should run stable. If some issues with old scripts will be found - I can try to make additions of dual-input to MAnalyse and Auto-thSAD to exact source version from 2.7.45 release by pinterf. I hope I can temporarily disable that debug assertion from MDegrainN with debug build. But as a first attempt to make more new builds with only a few and simple new features added, I get the latest sources from the pinterf's repository also to test if it is still not loaded with newer bugs or non-compatibility with old scripts.

"So the base is Pinterf's build with added features from you DTL?"

It is latest sources from pinterf's repository with some post-2.7.45 commits in 2021 year and added only 2 new simple features of second input to MAnalyse and Auto-thSAD to MDegrainN. Uploaded as separate branch to github - https://github.com/DTL2020/mvtools/t...nterf_last2021 . This branch is 2 commits ahead of pinterf:mvtools-pfmod.

"Does mrecalculate not work with this build and mdegrain2 aswell? "

Everything old expected to work. MDegrainX(1..6) will not have thSADA_a and thSAD_b new params. I do not have lots of required plugins and script libraries installed to test it with 'complex' scripts like QTGMC() or SMDegrain(). But I hope it will work.

Update: first small bugfix - https://github.com/DTL2020/mvtools/r.../r.2.7.46-e.02 . Found while trying to use Auto-thSAD with > 8bit clips.

Last edited by DTL; 11th August 2023 at 19:01.
DTL is offline   Reply With Quote
Old 26th August 2023, 19:58   #2708  |  Link
LeXXuz
21 years and counting...
 
LeXXuz's Avatar
 
Join Date: Oct 2002
Location: Germany
Posts: 716
Dogway I have a problem with sharpening and noise I don't quite understand atm. Does contrasharp work on the entire picture or only the areas SMDegrain denoised. So far I thought the latter to not increase strength of noise in areas mvtools didn't find a match and SMDegrain did NOT denoise.
But I think that's not what I'm actually seeing in my testclip. How does it behave with LSFplus mode and limitS=true?

Last edited by LeXXuz; 26th August 2023 at 21:24.
LeXXuz is offline   Reply With Quote
Old 26th August 2023, 21:45   #2709  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 2,364
@LeXXuz: ex_ContraSharpening() works on denoised (aka blurred) areas, but it incorporates a limiting so to not sharpen noise. The limiting is basically a DoG (edge mask) of the prefiltered (with ex_minblur) denoised clip, so safe to use, this when using spatial limiting of course.

LSFplus is similar in contrasharp mode but it uses different prefilters+edgemasks and additionally adds a non-linear sharpening, what this means is that it does some local contrast to such edgemask to tighten the area (edges) to be sharpened.
__________________
i7-4790K@Stock::GTX 1070] AviSynth+ filters and mods on GitHub + Discussion thread
Dogway is offline   Reply With Quote
Old 26th August 2023, 22:18   #2710  |  Link
LeXXuz
21 years and counting...
 
LeXXuz's Avatar
 
Join Date: Oct 2002
Location: Germany
Posts: 716
Ah, thanks! I have some content here where noise was added in some areas and that noise is so strong that I would have to use settings which would oversmooth the cleaner areas and kill lots of detail which would be worse. So I decided to keep it in there, although I think partially denoised material looks even more ugly than a noisy source...

So, for content that is not completely clean after denoising it may be safer to use contrasharp option in SMDegrain instead of running an external sharpener afterwards? I know I could lower frequency f.e. in ex_unsharp to avoid noise gain, but then I would lose the ability to sharpen very fine detail in other areas.
LeXXuz is offline   Reply With Quote
Old 27th August 2023, 12:35   #2711  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 2,364
If you want to sharpen noisy/grainy content you have to denoise first as you would normally do. Then feed that to ex_ContraSharpening() as denoised and source as source. Then you make a diff from the sharpened and denoised and add that to source, this way you don't sharpen grain/noise but only details.

Code:
source
src=last

SMDegrain()
den=last

ex_ContraSharpening(src) # or LSFplus in contra mode

ex_makeadddiff(last,den,src)
__________________
i7-4790K@Stock::GTX 1070] AviSynth+ filters and mods on GitHub + Discussion thread

Last edited by Dogway; 28th August 2023 at 22:05.
Dogway is offline   Reply With Quote
Old 28th August 2023, 12:55   #2712  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,616
@Dogway

Do you plan to use the new features of DTL MVTools (both the standard ones and the DirectX porting) soon? I am really curious to see improvements in speed and quality, if any.
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 28th August 2023, 14:03   #2713  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 2,364
No, it looks like big work as I'd need to refactor SMDegrain in its entirety, also it looks GPU motion vectors could be a reality soon with either DLSS 3 or FSR 3 if they provide an API.

I'm semi-retired from AVS, also starting classes tomorrow on Flutter+Dart.
__________________
i7-4790K@Stock::GTX 1070] AviSynth+ filters and mods on GitHub + Discussion thread
Dogway is offline   Reply With Quote
Old 28th August 2023, 14:24   #2714  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,752
Quote:
Originally Posted by Dogway View Post
If you want to sharpen noisy/grainy content you have to denoise first as you would normally do. Then feed that to ex_ContraSharpening() as denoised and source as source. Then you make a diff from the sharpened and denoised and add that to source, this way you don't sharpen grain/noise but only details.

Code:
source
src=last

SMDegrain()
den=last

ex_ContraSharpening(src) # or LSFplus in contra mode

ex_makeadddiff(den,src)
Isn't the contrasharpening call an NOP here since ex_makeadddiff uses variables which are not affected by it?
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 28th August 2023, 21:56   #2715  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 2,364
Yes, sorry I forgot that ex_makeadddiff() also accepts two inputs so I was thinking on implicit "last".

it should be:
Code:
ex_makeadddiff(last,den,src)
Also fixed above
__________________
i7-4790K@Stock::GTX 1070] AviSynth+ filters and mods on GitHub + Discussion thread

Last edited by Dogway; 28th August 2023 at 22:05.
Dogway is offline   Reply With Quote
Old 29th August 2023, 02:56   #2716  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,160
Quote:
Originally Posted by Dogway View Post
it looks GPU motion vectors could be a reality soon with either DLSS 3 or FSR 3 if they provide an API.
I do not expect big quality gains of MVs from DLSS/FSR motion estimation engines. Because it looks like they are designed to work with initially clean sources and with low latency (may not allow complex algorithms to run).

It may be good for smooth-video projects acceleration like SVP to free CPU when running with clean noise-free content and to get more intermediate frames generated.

For clean sources even old simple mvtools single pass based on SAD works good enough. You have clean src block and clean ref block and if motion is only translation the SAD-based search (with exhaustive method and enough radius) will output absolutely the best MV with single search. Nothing more to do.

With natural noised content things are going much worse - we do not have clean src block and clean ref blocks. So a simple search algorithm with single pass (based on 2 frames only) will output lots of false MVs and they are correct for the algorithm used - SAD also lowest. So no increase of pel/radius/search method can help in getting more correct MVs.

Motion search for natural noised content needs to use more complex algorithms with many frames analysis and using properties of natural motion to be not very random. Some algorithm targets may be to restore lowest temporal changing blocks over a long sequence of frames (sort of original objects texture restoration).

Sad idea about modern motion search engines - they are not designed to work with noised sources because new video footage computer generated (or from low noise video cams) are of low noise. So denoise is no common public task today and the digital industry does not invest into temporal denoise accelerators development (as software algorithms or hardware ASICs or GPU general compute blocks implementation like ML). Denoise of old film footage and some not common new shoot applications (like low light shots) is a limited task today to amateurs or old content restoration or rare commercial firms. So the general computer hardware industry can not make good money on developing good denoise engines for such a small market.

Possibly best MVs quality from general public hardware engines can be expected from modern MPEG encoders because it more frequently works with natural shot noised content and better motion compensation may make better MPEG compression performance (in theory). But the quality of ME of MPEG encoder also not needed to be best because all not compensated differences between src and ref block may be encoded as additional bits and also make output bitrate higher (if allowed by current rate control). Also MPEG encoders need to run fast so motion search radius and complexity may be limited for better performance.
DTL is offline   Reply With Quote
Old 29th August 2023, 16:32   #2717  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 2,364
Quote:
Originally Posted by DTL View Post
I do not expect big quality gains of MVs from DLSS/FSR motion estimation engines. Because it looks like they are designed to work with initially clean sources and with low latency (may not allow complex algorithms to run).
You can use prefilters anyway but I think denosing is also an area of interest sooner or later as shown with OptiX denoiser and RTX VSR.

Since it is accelerated with specific GPU chips I don't think it would be hard to surpass MVTools quality where the core algos haven't been changed in years.

It would be be interesting to know if it introduces also rotation, zoom and other transformation predictors. But all this depends onthe API options.
__________________
i7-4790K@Stock::GTX 1070] AviSynth+ filters and mods on GitHub + Discussion thread
Dogway is offline   Reply With Quote
Old 29th August 2023, 18:41   #2718  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,160
I still not see progress in new temporal denoisers for natural motion pictures data (from both film and silicon based sensors). The current industry denoisers are about decreasing artificial noise produced by too low quality raytracing engines.

I found demo of NVIDIA OptiX https://developer.nvidia.com/optix-denoiser and also some open denoiser from intel - https://www.openimagedenoise.org/ . But as I see in short description it is spatial single frame denoisers mostly ?

Intel open image denoise may be also interesting to make into AVS plugin to test and maybe test as prefilter. It promised to run at most of todays platforms from SSE4 CPU to many new hardware accelerators.

But I can not found anything about RTX VSR.

So it looks image processing industry still not (or already not) make anything good for natural noised imaging. Looks like close to no one (in general puclic) need to make clean natural images. We lost most of new end-users video cameras market. And smartphones video uses internal image processing and MPEG encoding. So new denoise engines oriented mostly on fixing bad computer renders with raytacing.

Last edited by DTL; 29th August 2023 at 18:46.
DTL is offline   Reply With Quote
Old 29th August 2023, 18:55   #2719  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,409
Quote:
Originally Posted by DTL View Post

I found demo of NVIDIA OptiX https://developer.nvidia.com/optix-denoiser and also some open denoiser from intel - https://www.openimagedenoise.org/ . But as I see in short description it is spatial single frame denoisers mostly ?
Yes, single image, using multiple layer inputs. OptiX and Intel OIDN are designed for 3D render engines, not for "flat 2D video". You need multiple passes and layers (albedo, normals) for best results. Otherwise the results are not good. Of course you don't have that type of data for normal "video"
poisondeathray is offline   Reply With Quote
Old 29th August 2023, 21:07   #2720  |  Link
Dogway
Registered User
 
Join Date: Nov 2009
Posts: 2,364
Yes that's true it's mainly designed for raytracing noise and makes use of normals and other passes, but that's like a bonus for renders, for natural images the raytracing denoising should be good enough on its own as it resembles typical film grain, for example on unbiased (or simply path traced) render engines it's typical to not let finish the render at all to have a natural looking film like grain.
In DLSS 3.5 presented last week the algorithm was improved so the denoiser takes into account the motion vectors and thus avoid the common ghosting and blurring issues it was suffering on previous versions. see the video here

RTX VSR is simply DLSS applied to video (super resolution)
__________________
i7-4790K@Stock::GTX 1070] AviSynth+ filters and mods on GitHub + Discussion thread
Dogway is offline   Reply With Quote
Reply

Tags
avisynth, dogway, filters, hbd, packs

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 21:25.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.