Dogway's Filters Packs

[Dogway]

I was playing a moment ago with 21 grams and found another good prefiltering with a single SMDegrain pass, haven't updated the docs as I'm keeping it for next (final?) revision and overall feedback.
pre=ex_bm3d(60,3,preset="noisy")
SMDegrain(tr=2,mode="TemporalSoften",blksize=32,prefilter=pre,thSAD=600,refinemotion=true)
ex_unsharp(0.2,Fc=width()/2) # Remove the dreamy/softness look

It has its strengths and flaws, overall is on the soft side, but keeps shading and detail, but better of all is it doesn't warp the content as with the 16mm example you talked to me about.

Also added a new 'mode' called TemporalGauss, it's like TemporalSoften but with binomial weighting, so it keeps more details, the main difference with TemporalSoften is that you can use recursion on it with rTemporalGauss so further cleanup is possible. It all depends on the content.

At first I wasn't getting any denoising and realized I broke it when fitting thSCD1, so for these two I added a new fit and also tweaked DCTR and scaleUV, the problem is only when RefineMotion=true. So now I can get back the results I was having with 21 grams sample, Carrie, etc.

You don't need to set tv_range as my example above as it will be read from frameprops, but if you are unsure simply set tv_range=true if your source is in tv_range. fsp is a handler for 'Fulls', so if frameprops is not 'Fulls' (!fsp) it means it's tv_range=true.

[LeXXuz]

I was playing a moment ago with 21 grams and found another good prefiltering with a single SMDegrain pass, haven't updated the docs as I'm keeping it for next (final?) revision and overall feedback.
[CODE]pre=ex_bm3d(60,3,preset="noisy")
SMDegrain(tr=2,mode="TemporalSoften",blksize=32,prefilter=pre,thSAD=600,refinemotion=true)
ex_unsharp(0.2,Fc=width()/2) # Remove the dreamy/softness look

Sigma of 60? :eek: Is there anything left in the prefilter clip? :D I'm probably too cautious. But as you said it highly depends on the source. "Lock, Stock and Two Smoking Barrels" is also such a nightmare with very coarse grain.


Also added a new 'mode' called TemporalGauss, it's like TemporalSoften but with binomial weighting, so it keeps more details, the main difference with TemporalSoften is that you can use recursion on it with rTemporalGauss so further cleanup is possible. It all depends on the content.

I sure will try that out. Luckily I have a few days off to play around with those new options. :D



You don't need to set tv_range as my example above as it will be read from frameprops, but if you are unsure simply set tv_range=true if your source is in tv_range. fsp is a handler for 'Fulls', so if frameprops is not 'Fulls' (!fsp) it means it's tv_range=true.

Ah thanks. I didn't know it will be read from frameprops. So I can safely remove that from the call.

[anton_foy]

I was playing a moment ago with 21 grams and found another good prefiltering with a single SMDegrain pass, haven't updated the docs as I'm keeping it for next (final?) revision and overall feedback.
pre=ex_bm3d(60,3,preset="noisy")
SMDegrain(tr=2,mode="TemporalSoften",blksize=32,prefilter=pre,thSAD=600,refinemotion=true)
ex_unsharp(0.2,Fc=width()/2) # Remove the dreamy/softness look

It has its strengths and flaws, overall is on the soft side, but keeps shading and detail, but better of all is it doesn't warp the content as with the 16mm example you talked to me about.

Also added a new 'mode' called TemporalGauss, it's like TemporalSoften but with binomial weighting, so it keeps more details, the main difference with TemporalSoften is that you can use recursion on it with rTemporalGauss so further cleanup is possible. It all depends on the content.

At first I wasn't getting any denoising and realized I broke it when fitting thSCD1, so for these two I added a new fit and also tweaked DCTR and scaleUV, the problem is only when RefineMotion=true. So now I can get back the results I was having with 21 grams sample, Carrie, etc.

You don't need to set tv_range as my example above as it will be read from frameprops, but if you are unsure simply set tv_range=true if your source is in tv_range. fsp is a handler for 'Fulls', so if frameprops is not 'Fulls' (!fsp) it means it's tv_range=true.

Major! Gotta try this out especially the TemporalGauss.
I have tried to repair the ghosting/smearing problem with mocomped temporalsoften using repair(mode=13) with good results. Do you have any ideas regarding this method?

[Dogway]

Sigma of 60? :eek: Is there anything left in the prefilter clip?
I was checking visually and it didn't stop filtering grain until 60, but I was using a 21 grams sample which is the grainiest example I have ever seen. It had a sort of a Kuwahara median look, but it worked fine as prefiltering.

Major! Gotta try this out especially the TemporalGauss.
I have tried to repair the ghosting/smearing problem with mocomped temporalsoften using repair(mode=13) with good results. Do you have any ideas regarding this method?
Yes, TemporalGauss (Weighted Mean) is designed for the cases with excessive ghosting/smearing from TemporalSoften (Average Mean). It's more conservative so it may degrain less, but you can compensate that by using recursion (a double call) and approximate more the denoising levels of TemporalSoften while producing less artifacts, it will also be slower though.

Try with:
SMDegrain(3,mode="rTemporalGauss",thSAD=700 or more, refinemotion=true)

[LeXXuz]

I get a script error with 4.0.0d RC3.
It states ConverttoYUV444 does not have a named argument 'param1' in line 1171 :confused:

I think I've updated every package with switching to 4.0.0d from 3.6.0d. Any idea what I may have missed? :o

[Dogway]

Try to download latest pinterf AVS+ version, test6.

I just uploaded RC4 of SMDegrain, mainly cosmetics but you can check the docs as I added the above ex_bm3d() example. I think this might be a good candidate for final.

[DTL]

I get a script error with 4.0.0d RC3.
It states ConverttoYUV444 does not have a named argument 'param1' in line 1171 :confused:

I think I've updated every package with switching to 4.0.0d from 3.6.0d. Any idea what I may have missed? :o

It is for that build of AVS+ or later - https://forum.doom9.org/showthread.php?p=1983250#post1983250

[LeXXuz]

Didn't know an update of Avisynth was required. Working again. Thank you guys! :)

[Tempter57]

Dogway

Has installed SMDegrain.avsi v4.0.0d RC7, there was an error
"I don't know what 'rgb' means. (C:\Program Files (x86)\AviSynth+\plugins64\SMDegrain.avsi,line 102)"

[Dogway]

Thanks, yes an oversight, updating in a few moments.

By the way I'm experiencing some memory leaks using QTGMC+, I'm debugging but not sure if it was a commit on my side or simply a recent AVS+ issue.

[LeXXuz]

By the way I'm experiencing some memory leaks using QTGMC+, I'm debugging but not sure if it was a commit on my side or simply a recent AVS+ issue.

Speaking of memory. Has there been any changes regarding ex_BM3D() since 3.6 in SMDegrain? GPU memory load almost doubled which exceeds physical memory on my 6GB/8GB cards and forces them to swap out with a hefty performance penalty of course.
I reverted back to 3.6 incl. its older package packs and memory problem was gone. Don't quite understand it, because from the looks of it I don't see any difference in ex_BM3D(). Using BM3DCUDA test10 atm. Maybe I have to ask Wolfgang what's going on there...

[Dogway]

What's your call and clip dimensions?
The recent changes to ex_BM3D() were only to ConvertTo___ using param1 and param2 new args. Unless you are using TemporalSoften 'mode' which now uses 'noisy' profile.

[LeXXuz]

Well this one for example. Its a profile I use for some of the nastier 1080p sources. I could run it before with around 5/6GB of memory load on GPU.
Now it uses up all 10GB and quits with a memory allocation error. Disabled AVS multithreading already but still exceeding memory limits.
Had to go down to a radius of 2 now for BM3D or disable one of its calls or I can't even load the script.

EDIT: I can easily run a 'standalone' cascade of two BM3D instances with these settings and without even getting remotely close to a GPU memory limitation.

[kedautinh12]

Radius=BMradius=6??? Very much. I think rad=2 or 3 enough

[LeXXuz]

Radius=BMradius=6??? Very much. I think rad=2 or 3 enough

No its not. It hardly affects performance on GPU but greatly increases accuracy as long as you have enough RAM.

[Dogway]

Works fine for me at stable 2Gb Vram, but I only ran the ex_BM3D call, I don't think I can run your full script.
ex_BM3D(sigma=5,radius=6,preset="Noisy",UV=3,gpuid=0)

For safety I use always pinterf builds, currently test7 I think. I'm keeping in MSVC compiled as I didn't see an improvement on performance on real world scripts.

EDIT: I found the memory leak in QTGMC+, it's in nnedi3wrap(), will dig up further.

[LeXXuz]

Works fine for me at stable 2Gb Vram, but I only ran the ex_BM3D call, I don't think I can run your full script.
ex_BM3D(sigma=5,radius=6,preset="Noisy",UV=3,gpuid=0)


No problem. It needs quite a lot of hardware resources. That script ran on a Ryzen 7950x with 128GB RAM and a RTX3080 10GB. I used to run that script for 1080p with stages from 1 to 10, depending on source quality (and a few prefilter tweaks here and there if necessary), with very neat results. But not anymore. :(

I can run two instances of ex_BM3D() with radius of up to 12 as standalone. No problem, even on a RTX3060 with 8GB. But not inside SMDegrain as prefilter. That kills my GPU's mem now. Odd. :(

[Tempter57]

Dogway

There was a problem at handling interlaced video, if to set

ConvertToYV12(interlaced=true)
pre=SMD_UnfoldFieldsVertical ().STTWM ().SMD_FoldFieldsVertical () # Tailored SeparateFields then Interleaving back
SMDegrain (tr=2,thSAD=300,interlaced=true,prefilter=pre,contrasharp=true)

That arises an error:
"Evaluate: operands of '==' and '!=' must be comparable
(C:/Program Files (x86)/AviSynth+/plugins64/SMDegrain.avsi, line318)
(C:/Program Files (x86)/AviSynth+/plugins64/SMDegrain.avsi, line661)"
If in SMDegrain to delete parametre interlaced=true, errors do not arise

[Dogway]

Thanks, should be fixed now.

EDIT: I found the issue on memory leak for QTGMC+, it's due to recurrent runtime frameprops assignments that I added to ex_bob() and nnedi3wrap() (deinterlacing only). It's the right thing to do, recompute per frame frameprops, but it causes memory issues on AVS+, so I added an argument called 'props' to disable the runtime.

Also I'm finding a way to make QTGMC+ faster, I did some edits and should improve a little but I have one pending that can make it improve much further, waiting for Asd-g on a crash report for a plugin to do the update.

EDIT2: I found a way to make QTGMC+ much faster but it's not a match to previous version, it isn't worse or better, just different or so it seems as it employs slightly different weights. Maybe you can have a look and tell me if it makes it worse or not.
Instead of making 2 different TemporalSoften calls and mix them later with an ex_lutxyz(), I just chain the both TemporalSoften calls (the same method is applied to MDegrain), it gives slightly more weighting to further frames.

Current QTGMC+
ts1=TemporalSoften( 1, 255, 0, 28, 2 )
ts2=TemporalSoften( 2, 255, 0, 28, 2 )
ex_lutxyz(ts1,ts2,last,"x 0.5625 * y 0.3125 * z 0.125 * + +", UV=3) # 263
Alternative
TemporalSoften( 2, 255, 0, 28, 2 )
TemporalSoften( 2, 255, 0, 28, 2 ) # 289
Ideal if it had SC
ex_blur3D(0,z=2,mode="weighted") # 432

[Guest]

@ Dogway.

Holy sh*t dude, when is this going to all be finalised ?

There have literally been dozens of revision's in the past week or so...how are we supposed to keep up ?

I have the "Watch" function enabled, but it doesn't seem to work, I have to manually check, on a "several times a day" basis.

I know we ALL appreciate what you're doing, but..........

[LeXXuz]

Dogway, just a short question about Globals in SMD.

from the docs:
Some parameters MUST MATCH those from the processed vectors stage (e.g. Globals=2 or 3) and the read vectors stage (e.g. Globals=1). pel=, subpixel=, chroma= and vpad/hpad.
Other than that the only settings that work when reading (Globals=1) are: tr=, thSAD=, plane, limit, limitc, contrasharp, CClip and the interlaced parameters. Others are ignored.
Global names that can be reused are: Super, bv1, fv1, bv2, fv2, bv3, fv3, bv4, fv4, bv6, fv6, vmulti.


What about LFR, DCTFlicker parameters? Are LFR and DCT part of the mv calculation process so they are also ignored when using globals=1?
And I think you may have forgotten that blksize must also match.

[Dogway]

LFR and DCTFlicker work because they are a post-process. I don't think blksize must match strictly but I will run some tests in the evening.

I was waiting for a bug described by ErazorTT where there's a chroma shift in MDegrain when processing chroma, but I tested yesterday and it doesn't seem to be the case, so probably tonight I release the final version.
QTGMC+ final was released yesterday because I don't think TemporalGauss plugin (with internal SC) is happening soon, so all my projects are finished by now, except TransformsPack obviously, but will take that one slowly.

This week I prepare the graphs for the HVS thread.

[LeXXuz]

LFR and DCTFlicker work because they are a post-process. I don't think blksize must match strictly but I will run some tests in the evening.


Thank you. I wasn't quite sure if it's pp or somewhere in the mv process. :o

It's quite strange with block size. On one machine it didn't bother, I had 16 in the 1st and 24 in the 2nd call.
On the other system it only worked when both were equal.

And I don't need to set prefilter explicitely to -1 in the 2nd call as it is obviously not needed when using globals, right?


QTGMC+ final was released yesterday because I don't think TemporalGauss plugin (with internal SC) is happening soon, so all my projects are finished by now, except TransformsPack obviously, but will take that one slowly.



Is it possible to get a version of QTGMC+ that does not require sysinfo? Or could you tell me which info I have to set manually to make it work without sysinfo?
I still have trouble on two of my systems with other software when installing the dll version sysinfo requires. I've already spent hours on that problem and finally gave up.:(

[Dogway]

Prefilter is for the motion vectors, so it only makes sense in the first Output Vectors SMDegrain call.
As for the SysInfo issue you mean the Visual C++ 2010 x64 Redis version? Can you try with v10.040219? It's the one I have and got no issues.
This is important, if it causes more problems than what it tries to solve I may consider removing it.

EDIT: I loaded it in Dependencies (https://github.com/lucasg/Dependencies)and it requires MSVCP100 and MSVCR100, but no idea how to retrieve the version required or whether this has issues on Win11 for example.

Didn't have time today so SMDegrain final delayed to tomorrow.

[LeXXuz]

Prefilter is for the motion vectors, so it only makes sense in the first Output Vectors SMDegrain call.
As for the SysInfo issue you mean the Visual C++ 2010 x64 Redis version? Can you try with v10.040219? It's the one I have and got no issues.
This is important, if it causes more problems than what it tries to solve I may consider removing it.

EDIT: I loaded it in Dependencies (https://github.com/lucasg/Dependencies)and it requires MSVCP100 and MSVCR100, but no idea how to retrieve the version required or whether this has issues on Win11 for example.

Didn't have time today so SMDegrain final delayed to tomorrow.

Yes, it's the problems described here: https://forum.doom9.org/showthread.php?p=1981377#post1981377

Sysinfo refuses to run with anything 10.040219.### on those machines. Both have Win11 Pro running. It was already a pain to get some of my older video softwares running. And that 'recommended' installer from abbodi was a nightmare which killed everything. I wasn't so lucky as Emulgator and had to setup a lot of software on both systems from scratch again. Took me almost a whole day. Since then I don't touch any redist installer anymore. I'd rather do without sysinfo and any filter that needs it than go through this ever again. :(

[Dogway]

Ok, as I see you were already using 10.0.40219.325 which is the one I have. Unless it has other unknown dependencies it could be said this plugin is unsupported for Win11 and since it's not maintained probably also for any newer CPUs.

AFAIK you can't check OS within Avisynth+ so I'm going to remove the dependency overall and default logical cores (threads) to 8, as a safe minimum.

EDIT: All finished : D

Oh, forgot to say, 'blksize' is ignored in Globals read as it's a MV arg, you can only change those args present in MDegrain or MMask/MCompensate if not using MDegrain mode.

[LeXXuz]

AFAIK you can't check OS within Avisynth+ so I'm going to remove the dependency overall and default logical cores (threads) to 8, as a safe minimum.

EDIT: All finished : D


That's awesome! Thank you very much! :thanks:

[simple_simon]

I updated all filterpacks to the latest ones and now santiagmod & grainfactory3mod no longer work.

This is the error I get for grainfactory3mod:

https://i.ibb.co/rG7G6DQ/2023-03-02-23-27-37-New-File-1-Avs-Pmod.jpg
grainfactory3mod()


And this is the one I'm getting for santiamod:

https://i.ibb.co/gFjH25S/2023-03-02-23-40-50-F-USER-Desktop-Conversions-gumbyd2-C3-t03-mkv-avs-Avs-Pmod.jpg
santiagmod(gpuid=-1)


No other filters in the chain except dgsource()

[Guest]

Hi,

I'm wanting to convert some SDR bt709 videos to "HDR" or at least bt2020, and neither z_ConvertFormat or colormatrix are working for me.

After doing a small encode, and checking with MediaInfo, it's still showing bt709.

Has anyone got some suggestion's that might work ??

[DTL]

"convert some SDR bt709 videos to "HDR" or at least bt2020, "

Converting 709 colour gamut to 2020 is only required if your display device do not understand 709 at all. And display badly saturated colours when playback of 709 content. It is possibly no way to expand colour gamut until you will manually do manual colour remastering of each scene with individual artistic adjustment of saturation of each object separately (using good visual tool like may be Davinchi). Simple remapping of 709 to 2020 keeping saturation very require to go from 8 to 10 bitdepth (or add dithering to UV) or you will get more colour banding if operate with 2020 in 8bit.

If you want to try to expand luma dymanic range from SDR to HDR - it is possibly better to use 'preset LUT' from some collection and LUT-converting plugin. Or again manual per-scene remastering.

"After doing a small encode, and checking with MediaInfo, it's still showing bt709."

MediaInfo only report metadata in file - it is your encoding tool put 709 records in output file. You need to configure encoder and muxer tool to put correct metadata after you actually convert source.

[Guest]

"convert some SDR bt709 videos to "HDR" or at least bt2020, "

Converting 709 colour gamut to 2020 is only required if your display device do not understand 709 at all. And display badly saturated colours when playback of 709 content. It is possibly no way to expand colour gamut until you will manually do manual colour remastering of each scene with individual artistic adjustment of saturation of each object separately (using good visual tool like may be Davinchi). Simple remapping of 709 to 2020 keeping saturation very require to go from 8 to 10 bitdepth (or add dithering to UV) or you will get more colour banding if operate with 2020 in 8bit.

If you want to try to expand luma dymanic range from SDR to HDR - it is possibly better to use 'preset LUT' from some collection and LUT-converting plugin. Or again manual per-scene remastering.

"After doing a small encode, and checking with MediaInfo, it's still showing bt709."

MediaInfo only report metadata in file - it is your encoding tool put 709 records in output file. You need to configure encoder and muxer tool to put correct metadata after you actually convert source.

When Googling this subject, there is a lot of reference to DaVinci Resolve as being the go-to, for this type of conversion.

Might also try some of FranceBB LUT's.

Thanks for the explanation.

[Dogway]

I updated all filterpacks to the latest ones and now santiagmod & grainfactory3mod no longer work.

This is the error I get for grainfactory3mod:

https://i.ibb.co/rG7G6DQ/2023-03-02-23-27-37-New-File-1-Avs-Pmod.jpg
grainfactory3mod()


And this is the one I'm getting for santiamod:

https://i.ibb.co/gFjH25S/2023-03-02-23-40-50-F-USER-Desktop-Conversions-gumbyd2-C3-t03-mkv-avs-Avs-Pmod.jpg
santiagmod(gpuid=-1)


No other filters in the chain except dgsource()

Thanks, updated.

Hi,

I'm wanting to convert some SDR bt709 videos to "HDR" or at least bt2020, and neither z_ConvertFormat or colormatrix are working for me.

After doing a small encode, and checking with MediaInfo, it's still showing bt709.

Has anyone got some suggestion's that might work ??

If you plan to do some chroma manipulation in Avisynth it might be useful to convert to 2020 in HBD. So you can change vibrance, temperature (my filters inside GradePack), and either encode as 2020@10-bit for also better YUV to RGB conversion at display level or simply dither down to 709-8-bit before encoding (ideally with gamut compression).

[DTL]

At SMDegrain https://github.com/Dogway/Avisynth-Scripts/blob/master/SMDegrain/SMDegrain.avsi I do not found 'trymany' param switch for MAnalyse. At my some tests and from internals it looks like best search mode (though slowest because of refine around each predictor). Why you do not enable it in the SMDegrain ? It is disabled in MAnalyse by default (to make processing faster).

From https://github.com/pinterf/mvtools/blob/d8bdff7e02c15a28dcc6e9ef2ebeaa9d16cc1f56/Sources/PlaneOfBlocks.cpp#L1020
when trymany=true it selects best of multi-best MV from refining searches around each predictor. And with trymany=false the refining is performed only around best predictor only once.

[Dogway]

Referencing my conclusion sheet for Zopti optimizations I wrote; "trymany=true gives a slight quality edge but it's considerably slower, add only for placebo". So it never made the pareto front. I would need to undust my tables.

EDIT: Here (https://docs.google.com/spreadsheets/d/1U5mFANtbfWUFg9JgolZKvEH6AGjzHgN1/edit?usp=sharing&ouid=112050534269511439571&rtpof=true&sd=true)'s a small table. Basically halves the speed or 3 times slower.

[DTL]

It looks trymany=false was made for fast motion interpolation at playback (of clean enough content) where small errors are not very visible.

And with noised content if some predictor give best (while with predictors only) but not really correct vector and even worse of a long length - the refining performed with small radius only around not best vector and the better vector is totally lost. Also the 'coherency' algorithm of MAnalyse start to use this wrong vector as predictor for next surrounding vectors and it can create large group of bad MVs around some place.

With trymany=true all predictors including zero is totally refined (checking all positions around with given method and radius) so finally only really best of the best position is going to output and it saves from starting and propagation in surrounding blocks of significant search error that sometime happens at low contrast low details noised areas.

So with trymany=true: Refine around all predictors independent of their initial quality and select best of the best MV for output (more exhaustive search, more quality, slower).
With trymany=false: Refine only around initially looking best predictor (faster, have more probability of lost of best MV with noisy sources, may create long bad MVs in static areas because skipping of zero predictor check, may initiate creation of large groups of bad MVs in low contrast low detailed noise areas).

[simple_simon]

Thanks, updated.

Thanks for the quick update. The same thing needs to be fixed in your filmgrain script. Line 284.

And I'm also getting this error when trying to downscale with deep_resize

https://i.ibb.co/TB5Fm9k/2023-03-03-14-56-33-F-USER-Downloads-q-Bittorent-Judas-and-Jesus-2009-WEBRip-AVC-720-mp4-avs.jpg
propSet("_FieldBased",0).deep_resize(720,480,grain=0,qual=2,gpuid=-1,show=false)

[DTL]

Here (https://docs.google.com/spreadsheets/d/1U5mFANtbfWUFg9JgolZKvEH6AGjzHgN1/edit?usp=sharing&ouid=112050534269511439571&rtpof=true&sd=true)'s a small table. Basically halves the speed or 3 times slower.

Yes - it expected to be significantly slower because refining around all predictors (about 6 or 7 if temporal also used) is much more of computing.

But there is an idea to check if some of the predictors add more value to output so may be added one more param like bitmask of 1 or 0 - use or not some predictor in trymany=true refinement process. So it may adjust performance more smoothly bewteen extreme points of trymany=false and trymany=true.

And with software optimizers it may be tested if some of the predictors have bigger weight in output quality.

Currently only single bool option exist - either faster or slower mode. So for users with high quality expectations and with good hardware resources may be add switch to SMDegrain about enabling max quality MAnalyse mode with warning about significant performance penalty.

[LeXXuz]

And with noised content if some predictor give best (while with predictors only) but not really correct vector and even worse of a long length - the refining performed with small radius only around not best vector and the better vector is totally lost. Also the 'coherency' algorithm of MAnalyse start to use this wrong vector as predictor for next surrounding vectors and it can create large group of bad MVs around some place.


Is this maybe what causes this ugly 'wobbling' effect of some textures in the denoised output of quite noisy old sources?

[Dogway]

Is this maybe what causes this ugly 'wobbling' effect of some textures in the denoised output of quite noisy old sources?

Just tested with trymany=true for your 16mm clip and still get the wobbling, even with DCT=5 which is said to help with luma flicker.

In my conclusion I considered still to be valuable, but as a placebo preset of some sort. Finally I didn't make a preset system since I found you could get very high quality with reasonable speeds with the defaults given (there's some parametrization fits there as well).
But I'm going to let my filters rest for a while, maybe later in Win10 I can check back things from time to time.

And I'm also getting this error when trying to downscale with deep_resize

It's working for me, what's your source details? Can you update TransformsPack - Main (https://github.com/Dogway/Avisynth-Scripts/blob/master/TransformsPack%20-%20Main.avsi) and check again?
EDIT: nono, my fault. Updating. I will also update filmgrain, to make it functional but the filter is still a proof of concept (WIP)

[DTL]

Is this maybe what causes this ugly 'wobbling' effect of some textures in the denoised output of quite noisy old sources?

It may add to this effect too. But typically errors in MVs cause additional blurring. Both static and moving objects.

Also it looks MDegrain (and other mvtools motion compensation parts) may still have some issue with chroma placement in case of processing 4:2:0 (and 4:2:2) formats - https://github.com/pinterf/mvtools/issues/59 . It cause additional chroma blocks shifting to random sides (because of 'quantization noise'). So it is expected some either complete bugfix or may be workaround in some close enough future. Current only existing workaround is to convert to 4:4:4 before MDegrain. So may be before SMDegrain too if it can not provide internal conversion to 4:4:4 before MDegrain call if required (may be some settings exist to force 4:4:4 processing with MDegrain internally in SMDegrain script ?).

[LeXXuz]

Just tested with trymany=true for your 16mm clip and still get the wobbling, even with DCT=5 which is said to help with luma flicker.


Damn. There goes my hope... :D

[Dogway]

IIRC the script I made a few weeks ago was aceptable concerning the wobbling, I think you just have to iterate the denoising or the MV and find a sweet spot as DTL also explained. Removing the flicker previously also helps to ameliorate the effect.

Just updated FilmGrain and GrainFactory3mod with the above bug reports.

[simple_simon]

Just updated FilmGrain and GrainFactory3mod with the above bug reports.

Everything's working now except filmgrain. I'm getting this error:

https://i.ibb.co/g6BHVBV/C1-t01-mkv000000.jpg

I had the old script working by adjusting line 284 (or at least it wasn't throwing an error) but it looks like more than that got changed in the new one. I liked the look of it though. I'll probably turn the chroma noise down or off for most things but I still like the look of the default settings.

[LeXXuz]

IIRC the script I made a few weeks ago was aceptable concerning the wobbling, I think you just have to iterate the denoising or the MV and find a sweet spot as DTL also explained. Removing the flicker previously also helps to ameliorate the effect.


Yes, but it still leaves quite a lot of noise in the picture. And that's my dilemma when watching on bigger screens. Often a just partly denoised film looks worse than the source. Because the picture looks non-homogeneous when parts are clean while others are still noisy. Or the fine grain was removed while the stronger/coarser grain remains in the picture. Both doesn't look good. Of course this scales with screen size. A lot of films look good on my desk monitors and then utterly fail when watching them on the big screen.

And I think there is a general fault or problem with MVtools as soon as denoising exceeds a certain threshold or there are certain kinds of noise in the source.
I can reproduce that wobble on almost any source as long as it's noisy enough. It's not just flicker causing this. I have several examples here showing wobbly textures where the source has no noticeable flicker at all, but has different kinds of noise, not just simple filmgrain.

Agreed, prefiltering plays the most important role here, but also has its limits. From my testing I got the best results with prefilters like Fluxsmooth regarding wobble. Block matching and DFT look worse and non-local means really fails with these sources.

As of now, SMDegrain is the best denoising script I ever had, no question! But I wouldn't use it as a general purpose filter anymore, even with customised prefiltering. Which has its limits.

DTL mentioned a lot of interesting details where Mvtools is still too rudimentary and needs improvement. And maybe this will change things one day for people like me who have to rely on scripts like yours, because we simply don't have the knowledge about digital image processing that you possess. :o

[Dogway]

Everything's working now except filmgrain. I'm getting this error:
I fixed FilmGrain and also ported its fixes to GrainFactory3mod, it was the cstr=0 case which I think I missed to update.

Anyway filmgrain is a proof of concept, it produces more "noise" than grain, I mean lack of grain structure, unless I raise coarsenness to 30, but the parameters are not well parametrized.

I had an idea yesterday and I will run some tests today, it may produce better results at faster speeds. I'm very interested on this since I like grain at least on non-digital films, it increases perceptual sharpness and texture richness.

Agreed, prefiltering plays the most important role here, but also has its limits. From my testing I got the best results with prefilters like Fluxsmooth regarding wobble. Block matching and DFT look worse and non-local means really fails with these sources.

If you share a small clip with the issue and without any kind of flicker I can give it a look. Maybe it's just a combination of pre/filters. Then I can add it to docs examples. One trick I learned from audio restoration is to apply low strength denoising iteratively, maybe it works.

[LeXXuz]

If you share a small clip with the issue and without any kind of flicker I can give it a look. Maybe it's just a combination of pre/filters. Then I can add it to docs examples. One trick I learned from audio restoration is to apply low strength denoising iteratively, maybe it works.

Trying to create some small samples next week. Family is keeping me busy this weekend.

And I think I have to work myself again through those anti-flicker scripts you provided for my last sample and how to merge them better with my script calls. I get the feeling I'm not using them properly :o

[anton_foy]

Trying to create some small samples next week. Family is keeping me busy this weekend.

And I think I have to work myself again through those anti-flicker scripts you provided for my last sample and how to merge them better with my script calls. I get the feeling I'm not using them properly :o

Maybe the old anti-shimmering scipt as a prefilter and possibly use newer filters as ex_blur3d instead of temporalsoften etc.

function Calm (clip clp)
{
ox = clp.width()
oy = clp.height()

# create linearily weighted temporal averaging
ts1 = clp.temporalsoften(1,255,255,28,2)
ts2 = clp.temporalsoften(2,255,255,28,2)

# construct temporal gaussian average from linear averages
t = ts1.merge(ts2,0.357).merge(clp,0.125)

# Create clip for motion search.
searchclip = t.removegrain(11).gaussresize(ox,oy,0,0,ox+.0001,oy+.0001,p=2)
\ .merge(t,0.1).mt_lutxy(t3,"x 7 + y < x 2 + x 7 - y > x 2 - x 51 * y 49 * + 100 / ? ?",U=3,V=3, scale_inputs="allf")

return searchclip
}

[LeXXuz]

Thanks anton_foy. I'll give that a try soon. Always open to any ideas.

Right now I feel kinda stuck, as nothing I've tried so far on these old films really satisfies me.

[LeXXuz]

Maybe the old anti-shimmering scipt as a prefilter and possibly use newer filters as ex_blur3d instead of temporalsoften etc.

function Calm (clip clp)
{
ox = clp.width()
oy = clp.height()

# create linearily weighted temporal averaging
ts1 = clp.temporalsoften(1,255,255,28,2)
ts2 = clp.temporalsoften(2,255,255,28,2)

# construct temporal gaussian average from linear averages
t = ts1.merge(ts2,0.357).merge(clp,0.125)

# Create clip for motion search.
searchclip = t.removegrain(11).gaussresize(ox,oy,0,0,ox+.0001,oy+.0001,p=2)
\ .merge(t,0.1).mt_lutxy(t3,"x 7 + y < x 2 + x 7 - y > x 2 - x 51 * y 49 * + 100 / ? ?",U=3,V=3, scale_inputs="allf")

return searchclip
}

Is there something missing? Taking a closer look at that script I don't see t3 being predefined :confused:

[Dogway]

The original by Terka uses 't' not 't3', anyway it's basically one of my prefilter recommendations but with ghosting and written in a convoluted manner.

function Calm2 (clip clp) {
SMDegrain(clp,2,thSAD=1400,mode="TemporalGauss",pel=1,rfilter=0,str=0,tv_range=false,plane=0,truemotion=true)
# vsTCanny(1.5,mode=-1,u=3,v=3) # This matched Terka's but I like ex_sbr() better
ex_sbr(3,UV=3) }

And no, it didn't prevent the wobbling.

I don't know what's wrong with the one (https://www.mediafire.com/file/9go3u7gkaccrvz4) I suggested, it has no wobbling.