Dogway's Filters Packs

[anton_foy]

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

Oops looks like I hit a 3 somehow. Typo sorry.

[LeXXuz]

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.

Have to work remotely on my machine via VNC from here so I don't have the visual fidelity like I would have by directly sitting in front of the screen. But I can still see a lot of ghosting in the prefilter clip. So I don't think it is suitable but surely was worth a try. :)

Your clip is wobbling a little on the left side in the archway. At least I think so, or is it just light flickering?
And it has a little bit too much noise for my taste. But still looks way better than the jelly look I came up with so far. :D

I'm sure now I have done something wrong. Because trying to merge your deflickering script bits with ex_autolevels into my scripts produced a lot of noticeable brightness changes along scenes which clearly is the opposite of what was intended. :o

[Dogway]

Have to work remotely on my machine via VNC from here so I don't have the visual fidelity like I would have by directly sitting in front of the screen. But I can still see a lot of ghosting in the prefilter clip. So I don't think it is suitable but surely was worth a try. :)
If you think that has ghosting I don't know what would be your stance on Calm(). The good part is you can protect more lowering thSAD, and prefilter doesn't need to be perfect either.

Your clip is wobbling a little on the left side in the archway. At least I think so, or is it just light flickering?
That's local luma flicker, and can't be fixed at all, only reduced with temporal denoise. There might be a tiny bit of wobbling left here and there, but I would be curious to see how you improve that any further, that's the best you gonna get regarding that.

[LeXXuz]

If you think that has ghosting I don't know what would be your stance on Calm().

Whoops. That actually was my stance on Calm() that anton_foy provided. Sorry for any misunderstanding. :o


That's local luma flicker, and can't be fixed at all, only reduced with temporal denoise.

I see. Well, I can accept that. :) What can't be fixed, can't be fixed as they say. And I don't have to bother with that anymore. :D

Could you please provide the script to your last sample clip. I'd like to give that a try on the whole film and see what it looks like in other scenes. :)

[Dogway]

Yes, it's the last one in this post (https://forum.doom9.org/showthread.php?p=1982586#post1982586), you can also try the one above, and play with some values if you want. Hope it's stable enough with SceneStats(), luckily pinterf fixed a memory leak in ScriptClip that could make things more stable (for next version).

[LeXXuz]

Yes, it's the last one in this post (https://forum.doom9.org/showthread.php?p=1982586#post1982586), you can also try the one above, and play with some values if you want. Hope it's stable enough with SceneStats(), luckily pinterf fixed a memory leak in ScriptClip that could make things more stable (for next version).

Ah yes. I couldn't make that work because I couldn't find a StabPlus2() function in your repo. :o

Also I tried to process entirely in 16bit because I encode to 10bit afterwards. But when I removed that convert to 8bit in your upper sample script, I got an overlay error message in the output file shown saying something about bit depth mismatch. Can I run that in 16bit somehow?

[Dogway]

Stab2 is the proxy name I gave to Fred's stabilization example:
# https://forum.doom9.org/showthread.php?p=1981048
function Stabilize(clip c, int "offset", bool "info") {

in = Default(info, false)
of = Default(offset, 40)

c
vectors = MSuper().MAnalyse(isb=false)
mdata = MDepan(vectors, rot=false, zoom=false, error= 65)

DePanStabilize(data=mdata,dxmax=of, dymax=of, zoommax=0, rotmax=0, method=1, mirror=15, prev=1, next=1, info=in)
}

The script works for me, even at 16-bit removing the ConvertBits(8,dither=1) call after ex_Luma_Rebuild(). Don't use StabPlus(), Stabilization Tools Pack is outdated, use Fred's example.

[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.



Have to work remotely on my machine via VNC from here so I don't have the visual fidelity like I would have by directly sitting in front of the screen. But I can still see a lot of ghosting in the prefilter clip. So I don't think it is suitable but surely was worth a try. :)

Your clip is wobbling a little on the left side in the archway. At least I think so, or is it just light flickering?
And it has a little bit too much noise for my taste. But still looks way better than the jelly look I came up with so far. :D

I'm sure now I have done something wrong. Because trying to merge your deflickering script bits with ex_autolevels into my scripts produced a lot of noticeable brightness changes along scenes which clearly is the opposite of what was intended. :o

I found what was failing on Terka's function, the code is basically QTGMC's prefilter function when TR0=2 and SrchClipPP=3, but he omitted KeepOnlyBobShimmerFixes(). This gets rid of most ghosting, but leaves some behind though that might not impact output result (except for anime though). You can use my suggestion above raising thSAD even higher or use the alternative below.
function Calm2 (clip clp) {

# temporal gaussian average
clp.ex_blur3D(0,0,2,"weighted",UV=3)

# Remove areas of difference between temporal blurred motion search clip and
# bob that are not due to bob-shimmer - removes general motion blur
QTGMCp_KeepOnlyBobShimmerFixes(clp,4,true,fulls=true)

# Gaussian blur, or Smart blur for less damaged sources
# vsTCanny(1.5,mode=-1,u=3,v=3)
ex_sbr(3,UV=3) }

For very unstable sources this might be better as it will protect less and hence produce more stable output and less wobbling, it's also faster albeit a bit blurrier than TemporalGauss with SMDegrain. For your source replace ex_sbr(3) with the vsTCanny call. And I call this function as the last "pre" before SMDegrain()

[anton_foy]

I found what was failing on Terka's function, the code is basically QTGMC's prefilter function when TR0=2 and SrchClipPP=3, but he omitted KeepOnlyBobShimmerFixes(). This gets rid of most ghosting, but leaves some behind though that might not impact output result (except for anime though). You can use my suggestion above raising thSAD even higher or use the alternative below.
function Calm2 (clip clp) {

# temporal gaussian average
clp.ex_blur3D(0,0,2,"weighted",UV=3)

# Remove areas of difference between temporal blurred motion search clip and
# bob that are not due to bob-shimmer - removes general motion blur
QTGMCp_KeepOnlyBobShimmerFixes(clp,4,true,fulls=true)

# Gaussian blur, or Smart blur for less damaged sources
# vsTCanny(1.5,mode=-1,u=3,v=3)
ex_sbr(3,UV=3) }

For very unstable sources this might be better as it will protect less and hence produce more stable output and less wobbling, it's also faster albeit a bit blurrier than TemporalGauss with SMDegrain. For your source replace ex_sbr(3) with the vsTCanny call. And I call this function as the last "pre" before SMDegrain()

This I forgot. But what about the vertical only shimmering in "QTGMCp_KeepOnlyBobShimmerFixes"? Can it be altered to fix horizontal and vertical shimmer since it is a progressive source?
Haven't tried but just removing mode_vertical can maybe screw it up.

[Dogway]

This I forgot. But what about the vertical only shimmering in "QTGMCp_KeepOnlyBobShimmerFixes"? Can it be altered to fix horizontal and vertical shimmer since it is a progressive source?
Haven't tried but just removing mode_vertical can maybe screw it up.

I would run it twice in that case, with TurnLeft()
By the way, I noticed that in QTGMC the source is blurred vertically before prefiltering, so I added spatial blur before ex_blur3d()
At the end I applied a deconvolution so it mimics more what QTGMC prefilter looks.
function Calm2 (clip clp) {

# temporal gaussian average
blr = clp.removegrain(12)
blr1 = clp.ex_boxblur(0,1,"weighted")
blr2 = clp.ex_boxblur(1,0,"weighted")
blr.ex_blur3D(0,0,2,"weighted",UV=3)

# Remove areas of difference between temporal blurred motion search clip and
# bob that are not due to bob-shimmer - removes general motion blur
QTGMCp_KeepOnlyBobShimmerFixes(blr1, 4,true,true)
TurnLeft()
QTGMCp_KeepOnlyBobShimmerFixes(blr2.TurnLeft(),4,true,true)
TurnRight()

# Final edge blur
removegrain(20)
ex_unsharp(-0.25,Fc=width()/2.5) }

But this showed more wobbling than my previous example. Using your alternative to turn "vertical" into "square" in KeepOnlyBobShimmerFixes() removes the wobbling, but that's because now the Calm prefiltering isn't removing ghosting at all. So it's kind of a balance, maybe using my SMDegrain approach with a high enough thSAD could be the better alternative (also has SCD) even if some ghosting makes it through it should be safer.

EDIT: So for wobbling the best option is an unprotected temporal gauss as prefilter, later in my script I use MotionMask() to use a more protective denoiser to motion areas.
function pref_DeWobble(clip clp) {

# temporal gaussian average
clp.ex_blur3D(0,0,2,"weighted",UV=3)

# Final edge blur
removegrain(20)
ex_unsharp(-0.3,Fc=width()/2.5) }

And here the script
ffvideosource("noisy_original.mkv")
propSet("_FieldBased",0)

ConvertBits(16)
ex_Luma_Rebuild(15.0, 0.004, 21, tv_out=true)
ConvertBits(8,dither=1)

Stabilize()
crop(2,2,-6,-2)
SceneStats("Range+Stats")

pref = ex_autolevels( true ,true, true,Deflicker=true,tv_out=false)
pref = ex_autolevels(pref,false,true,false,Deflicker=true,tv_out=false)
pref3 = pref_DeWobble(pref)

bk=SMDegrain(tr=2,mode="TemporalSoften",blksize=16,thSAD=400,LFR=false,refinemotion=true,prefilter=pref3)
ft=SMDegrain(tr=2,mode="MDegrain" ,blksize=16,thSAD=300,LFR=false,refinemotion=true,prefilter=bk)
ex_merge(bk, ft, MotionMask(pref3,scale=10,sharpness=5))

ex_unsharp(0.3)
# And some film grain here

[anton_foy]

now the Calm prefiltering isn't removing ghosting at all
Usually I use temporaldenoiser().repair(src, mode=13) to remove motionblur, but I don't know if there are many downsides to that.

[Dogway]

Thanks, yes that's a great idea, it's actually used in some stages of LSFplus and SMDegrain, anyway I tested and it brings back some wobbling so the unprotected version is ok with the above code, but only for wobbling, for high noise I would motion protect it in some way.

[anton_foy]

Thanks, yes that's a great idea, it's actually used in some stages of LSFplus and SMDegrain, anyway I tested and it brings back some wobbling so the unprotected version is ok with the above code, but only for wobbling, for high noise I would motion protect it in some way.

Yes it seems some thresholding (or something) should be involved, I noticed it too.

[LeXXuz]

Stab2 is the proxy name I gave to Fred's stabilization example:
# https://forum.doom9.org/showthread.php?p=1981048
function Stabilize(clip c, int "offset", bool "info") {

in = Default(info, false)
of = Default(offset, 40)

c
vectors = MSuper().MAnalyse(isb=false)
mdata = MDepan(vectors, rot=false, zoom=false, error= 65)

DePanStabilize(data=mdata,dxmax=of, dymax=of, zoommax=0, rotmax=0, method=1, mirror=15, prev=1, next=1, info=in)
}

The script works for me, even at 16-bit removing the ConvertBits(8,dither=1) call after ex_Luma_Rebuild(). Don't use StabPlus(), Stabilization Tools Pack is outdated, use Fred's example.

I agree with you, Fred's script works better. I tried that example on a film where the entire scene wobbles with my usual SMDegrain script. And I could hardly notice any wobble, which is great, but still have to tweak on denoising strength since the picture now looks like the noise has been made stand still, like a curtain over the picture. Kinda hard to describe. If I can reduce that some more the result is very satisfying.

But I will also try your latest script idea and see how that performs in comparison.

And everything now works in 16-bit as well. I've updated everything from your repo and no weird on screen message about bitdepth-missmatch anymore. :D

Speaking of QTGMC. The film is progressive but the transfer was bad and has field drops here and there from capturing causing field shifts.
So I let Ceppos tools run with your version of QTGMC+ at the very beginning of my script, like:
#
LoadPlugin("C:\Video Editing\MeGUI (x64)\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("H:\WORK\test.mkv")
#
AssumeFPS(25)
CTelecine()
CPostProcessing()
propSet("_FieldBased",0)
#
(Denoising script here)
#

Could this cause problems regarding wobbling? Or is there a better approach taking care of phase shifts in PAL DVDs?

[anton_foy]

like the noise has been made stand still, like a curtain over the picture

FFT3Dfilter can be good for it.

[Dogway]

Since the source is progressive I'm not sure what you are doing there before, but as long the outcome is also progressive there shouldn't be any problem.

Using the pref_DeWobble() as in my above script example gives virtually no wobble, that prefilter is not motion protected but it passes through one SMDegrain and then another one as prefilters masking out any blending in the process. For the grain curtain adding some grain in the end helps mask out the effect, as well as add some hallucination and psychovisual sharpness. Personally I don't like FFT3DFilter because it's too slow, and the output can be worm-like.

Here the result: Link ("https://www.mediafire.com/file/jd04nq34ezdcvuq)

And this is a before-after comparison, download for best quality: https://drive.google.com/file/d/1iI3BnbI4Q0K1LMALhV6WyOy-0iBwn-ib

[LeXXuz]

Since the source is progressive I'm not sure what you are doing there before, but as long the outcome is also progressive there shouldn't be any problem.


Maybe I explained it wrong. You see the source is supposed to be progressive but during poor digitisation sometimes a field of a frame is missing or the field order is shifted. Making it appear interlaced. Back in the first years of DVD production a lot of studios didn't care about this because it would not matter when playing these DVDs on old PAL TV-sets because of the way the picture was created by their electron-beam tubes. Since we are long past that aera, on modern flatscreen TVs this is a visual issue. Especially when the source is flagged progressive and the playback device doesn't do any field processing you can clearly see those field mismatches.

With Ceppos tools I can fix that and put the fields back in the right order. It uses QTGMC in the process but I have no idea how exactly and to what extend.

Since you talked about QTGMC I thought it could maybe abet the wobbling effect when processing the picture? If no, I'm fine. If it maybe does, I have to look for some other tools that check for the correct field order of a PAL frame and shuffles them back in the right sequence or duplicates a field if there is one missing.

[anton_foy]

Here the result: Link
But come on that looks amazing! Too good for me I enjoy the "imperfections" of celluloid though.:D

Edit: Yes fft3d is probably a bit slow but it actually helped me alot. The combination of fft3d(spatio-temporal) with mvtools is pretty smooth. Knlmeanscl is for me too slow (2013 old setup) and temporally jittery. I would love to love able to stabilize the jitter/shimmer/dancing of fft3d or any other good spatial filter to get a fine result. Just so you know @Dogway I read your scripts with a magnifying glass. Loads of great inspiration.

[LeXXuz]

Can't really complain about speed. I used neo_fft3d quite a lot before mainly using SMDegrain. Or the latest GPU version which also worked fine but lacks a few parameters.

[kedautinh12]

But common that looks amazing! Too good for me I enjoy the "imperfections" of celluloid though.:D

Edit: Yes fft3d is probably a bit slow but it actually helped me alot. The combination of fft3d(spatio-temporal) with mvtools is pretty smooth. Knlmeanscl is for me too slow (2013 old setup) and temporally jittery. I would love to love able to stabilize the jitter/shimmer/dancing of fft3d or any other good spatial filter to get a fine result. Just so you know @Dogway I read your scripts with a magnifying glass. Loads of great inspiration.

Here have replace CL of KNLMeansCL with Cuda ver but only in VS, you can waiting for someone port it to avs
https://github.com/AmusementClub/vs-nlm-cuda

[DTL]

Added fixed version of mvtools based on pinterf 2.7.45 with partially fixed chroma fetching for subsampled chroma formats (4:2:0 and 4:2:2) for testing (based on issue https://github.com/pinterf/mvtools/issues/59) - https://github.com/DTL2020/mvtools/releases/tag/r.2.7.45-fix02 . Changed both MAnalyse (with chroma=true) and MDegrain/MCompensate (the MRecalculate may also use it from common PlaneofBlocks header). So it may make difference in both SMDegrain and QTGMC and other MCompensate-based scripts.

Though the best chroma placement for processing in chroma subsampled formats may be still subject of more testing (like top-left or center ?).

Also for highest quality processing still only all processing in 4:4:4 (both MAnalyse and MDegrain/MCompensate) is recommended. The precision of current MSuper for pel=1,2,4 is not enough for best motion compensation for subsampled chroma formats. And current fix only decrease motion compensation position error about 2 times.
It looks initially mvtools was designed to 4:4:4 processing and subsampled chroma was added with not best quality. Mostly for better performance. Also mvtools do not read and do not use chroma placement frame/clip properties. Feeding non-optimal chroma placement in chroma subsampled format to mvtools may cause additional quality degradation.

So for higher quality processing mode it may be added to SMDegrain script forcing of conversion to 4:4:4 (and with correctly read from input chroma placement data) for using with mvtools.

[kedautinh12]

Any chance for x86??? Thanks

[DTL]

I think no one use 32bit systems nowdays in 2023. Added 32bit build and updated release files. Also I still not receive any report from these fix and not know if it work for all currently used cases. All versions still mostly compatible with 32bit builds.

@Dogway: If you have GTX1070 board and Win10 now - can you test that idea https://forum.doom9.org/showthread.php?p=1984126#post1984126 of using 2 different full-speed DX12-ME accelerators from GTX1070 board ? Do it really allow to run 2 MAnalyse (with optSearchOption 5 or 6) faster in compare with usage of single accelerator interface ?

[kedautinh12]

They still use avs+ x86 in x64 machine cause some old plugins only support x86

[Selur]

A few plugins that come to mind that are only available for 32bit afaik :

amDCT: https://forum.doom9.org/showthread.php?t=174433
HDRAGC: http://avisynth.nl/index.php/HDRAGC
Deen: http://avisynth.nl/index.php/Deen
NoiseGenerator: http://avisynth.nl/index.php/NoiseGenerator
ColorBalance: http://avisynth.nl/index.php/ColorBalance
ChannelMixer: http://avisynth.nl/index.php/ChannelMixer
UnBlock: http://www.avisynth.nl/users/fizick/unblock/unblock.html
DeblockPP7: http://avisynth.nl/index.php/DeblockPP7
DeCrawl: http://avisynth.nl/index.php/DeCrawl
PeachSmoother


Cu Selur

[kedautinh12]

DeblockPP7 had another ver is vsDeblockPP7 now
https://github.com/Asd-g/AviSynth-vsDeblockPP7

[Selur]

Ah, good to know. Thanks for the info.

[DTL]

Well, here is something I'm really scratching my head on.

I'm still struggling with a bluring effect with SMDegrain in moving areas which really disturbs the overall look of the picture.
I may have misunderstood the entire concept of mc denoising,
but (beside better noise removal on moving objects) - shouldn't a motion compensated denoiser prevent exactly this from happening?

One more approach against blurring in motion with mvtools only - https://forum.doom9.org/showthread.php?p=1984140#post1984140

Example uses only onCPU MAnalyse (and optPredictorType=1 for faster processing with still trymany enabled).

Not sure how it will work on medium and high noised sources and also with real motion blur in frames.
With that sample from film:
Frames 99,100,101 from script (gen 6, gen2, gen1 (standard 1pass MDegrainN)), 2x enlarged with BSpline resize in XnView:
https://i.ibb.co/mXycJYC/fr99-g6.png (https://ibb.co/mXycJYC)
https://i.ibb.co/wN82fTk/fr100-g2.png (https://ibb.co/wN82fTk)
https://i.ibb.co/6BwBbpW/fr101-g1.png (https://ibb.co/6BwBbpW)

Best average may be something between gen 2 and 6. Or may be some more scripting may be used to extract more detailed areas from higher-generations where exist.

Frame 64 and 65 of interleaving g2-out and your file test_enc_thSAD200.mkv
https://i.ibb.co/StVVCwh/fr64-g2.png (https://ibb.co/StVVCwh)
https://i.ibb.co/DpNdQbd/fr65-test-enc200.png (https://ibb.co/DpNdQbd)

[LeXXuz]

I found what was failing on Terka's function, the code is basically QTGMC's prefilter function when TR0=2 and SrchClipPP=3, but he omitted KeepOnlyBobShimmerFixes(). This gets rid of most ghosting, but leaves some behind though that might not impact output result (except for anime though).

Sorry to hijack this Sensei, but you inbox seems to be full. Doom9 is a parsimonious place. :D

[LeXXuz]

One more approach against blurring in motion with mvtools only - https://forum.doom9.org/showthread.php?p=1984140#post1984140


Thank you very much DTL. That looks very promising. I sure will have a closer look into that. :thanks:

[madey83]

Hello,

i have dolby vison source with lot of grain in some part of video. Grain looks like on the screenshot
https://imgur.com/DMbH2Hp
https://imgur.com/7KBXD4B

Could you please advice how to deal with it?
if necesary i could provide some example of the source...

thank you in advance :)

[Dogway]

@LeXXuZ: Post here as I don't have time delete PM, also people can learn.

@madey83: First, you need to convert to SDR as prefilter, read the suggestion at the top of SMDegrain or docs examples. Also I just updated ExTools with 'IQMST' algorithm, and added as prefilter to SMDegrain. It's a mostly motion protected spatio-temporal median/box blur but with a personal structuring element. Works well with grainy HD sources. Give it a try with prefilter=4, as it replaces FluxSmoothST.

By the way, I also added a twist to SMDegrain 'LFR', now it's always passed through the motion mask, so not much DCT flicker is recovered, should be now mostly fool proof even with DCTFlicker=false.

[Guest]

Also I just updated ExTools with 'IQMST' algorithm, and added as prefilter to SMDegrain. It's a mostly motion protected spatio-temporal median/box blur but with a personal structuring element. Works well with grainy HD sources. Give it a try with prefilter=4, as it replaces FluxSmoothST.


I can't believe that you've significantly changed things, AGAIN !!

So now I have to go thru and update a lot of my scripts, and now some of them aren't even going to work anymore.

You should really drop a quick post when you've changed things, as the notifying function for github doesn't seem to work that well with these changes.

[anton_foy]

I can't believe that you've significantly changed things, AGAIN !!

So now I have to go thru and update a lot of my scripts, and now some of them aren't even going to work anymore.

You should really drop a quick post when you've changed things, as the notifying function for github doesn't seem to work that well with these changes.

But he did post, right? If you do not want to update then use your current smdegrain.avsi as is?

[madey83]

@LeXXuZ: Post here as I don't have time delete PM, also people can learn.

@madey83: First, you need to convert to SDR as prefilter, read the suggestion at the top of SMDegrain or docs examples. Also I just updated ExTools with 'IQMST' algorithm, and added as prefilter to SMDegrain. It's a mostly motion protected spatio-temporal median/box blur but with a personal structuring element. Works well with grainy HD sources. Give it a try with prefilter=4, as it replaces FluxSmoothST.

By the way, I also added a twist to SMDegrain 'LFR', now it's always passed through the motion mask, so not much DCT flicker is recovered, should be now mostly fool proof even with DCTFlicker=false.

@Dogway,

i haven't see this in doc, and my encode with Dolby Vision was done without this DGHDRtoSDR and looks fine with me - but i would like to do this in proper way.

Your proposition is to use prefilter (prefilter=4), but how can i use defined prefilter at the same time with "pre2=ex_BM3D...."

this is my SMDegrain part based on your earlier suggestions/guidance:


#SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetMemoryMax()
ConvertBits(16)

deep_resize(1920,edge="Zopti1080")
pre=DGHDRtoSDR(mode="pq",white=ceil(59.49080238715383)) # Check different white levels depending on source

# Remove big chroma "blocks"
CCD(15)

# Remove blocking and smooth out jagged edges (only applies where motion match fails)
mb=Deblock_QED(quant1=30, quant2=40, aOff1=1, aOff2=1, bOff1=2, bOff2=2, uv=1)
mb=mb.ex_smooth(1, mode="SG", limit=true, sharp=true)


pre2=ex_BM3D(pre, sigma=5,preset="normal",radius=3,UV=1,gpuid=0,tv_range=true)

SMDegrain(prefilter=pre2, mfilter=mb, tr=3, thSAD=300, thSADC=150, thSCD1=400, thSCD2=120, LFR=false, plane=4, limits=false, DCTFlicker=false, refinemotion=true, search=5, subpixel=3)


and how can i check white levels on the source to replace "ceil(59.49080238715383)"

[Guest]

But he did post, right?

Yeah, this time he mentioned it, but....

[Guest]

@Dogway,

i haven't see this in doc, and my encode with Dolby Vision was done without this DGHDRtoSDR and looks fine with me - but i would like to do this in proper way.

Your proposition is to use prefilter (prefilter=4), but how can i use defined prefilter at the same time with "pre2=ex_BM3D...."

Go here, and see if it makes sense to you...

Line 301 (https://github.com/Dogway/Avisynth-Scripts/blob/master/SMDegrain/SMDegrain.avsi#L301)

(prefilter== 4) ? pref.ex_Median(mode="IQMST", UV=Chr, thres=255).ex_sbr(3,UV=Chr)

Maybe pre3=ex_Median ???

[Dogway]

@madey83: The prefiltering depends on the source, my suggestion was for the image samples you posted which looked grainy. So simply use ex_Median(mode="IQMST", UV=3, thres=255) as a prefilter, probably after BM3D, although I would replace it entirely. This new prefilter is quite good but also strong. As for the white level try between 59 and 100. It should be dependent on MaxFALL so if you don't know that try several values.

[madey83]

@madey83: The prefiltering depends on the source, my suggestion was for the image samples you posted which looked grainy. So simply use ex_Median(mode="IQMST", UV=3, thres=255) as a prefilter, probably after BM3D, although I would replace it entirely. This new prefilter is quite good but also strong. As for the white level try between 59 and 100. It should be dependent on MaxFALL so if you don't know that try several values.

Hello Dogway,

i undestand part with replacing prefilter, but i do not catch how to hooked up HDR2SDR with SMDegrain.

My source MaxFALL has 111.91nits according to DV RPU information.

and one more question. Is there an option to specify stronger SMDgrain value between stecific frames, like 10000-20000 and for other would be weaker?

[LeXXuz]

I can't believe that you've significantly changed things, AGAIN !!


To be honest, I don't get your problem! Since the last version was not broken or anything, you do NOT HAVE to update anything if your current scripts are working for you. :rolleyes:

And the changes and optimizations are a benefit for the script which IS a work in progress.

Why don't you just set prefilters yourself, instead of relying on the ones included in SMDegrain? That's what I do, so I don't have to worry about switches or changes in prefilters anymore. ;)

@LeXXuZ: Post here as I don't have time delete PM, also people can learn.
I had a question that does not necessarily belong here. But no problem. ;)

[Boulder]

and one more question. Is there an option to specify stronger SMDgrain value between stecific frames, like 10000-20000 and for other would be weaker?

You can work with segments and join them later. For example:

a = Trim(0,9999).SMDegrain(...)
b = Trim(10000,19999).SMDegrain(...)
a+b

It will be much more memory hungry though.

[Guest]

To be honest, I don't get your problem! Since the last version was not broken or anything, you do NOT HAVE to update anything if your current scripts are working for you. :rolleyes:

I am just puzzled why a filter option was completely replaced, instead of just adding another one. I'm sure I won't be the only user, impacted by the change.

And the changes and optimizations are a benefit for the script which IS a work in progress.

I realise it's a WIP, but same issue as above comment. There's no doubt the new addition is good, but it should be extra !!

Why don't you just set prefilters yourself, instead of relying on the ones included in SMDegrain? That's what I do, so I don't have to worry about switches or changes in prefilters anymore. ;)

No too sure how this would be done (not as experienced as you, obviously) a sample maybe.

But if I want to use SMDegrain, don't I have to set it up as Dogway has written it ??

[LeXXuz]

I realise it's a WIP, but same issue as above comment. There's no doubt the new addition is good, but it should be extra !!


My guess is it's probably not an addition but more of a replacement which makes the old prefilter obsolete for most cases.


No too sure how this would be done (not as experienced as you, obviously) a sample maybe.
But if I want to use SMDegrain, don't I have to set it up as Dogway has written it ??

From my understanding the internal prefilters are for keeping things simple (which is the entire point of SMDegrain script) and to help inexperienced users with prebuild setups for most scenarios.

As you know prefiltering is very important for satisfying results. And the built in prefilters do a very good job for most cases.
But of course you can always optimize that to your needs by simply using your own prefilters. Or using the same prefilters already integrated but with different parameters. I'd consider the internal prefilters more of a starting point for personal tweaks, but certainly not the optimum. They can't be, because every source is different. So you would end up with dozens of prefilters which would not make much sense imho.

It's alright to call the same prefilter externally so you don't have to worry about numbers anymore.

[Guest]

My guess is it's probably not an addition but more of a replacement which makes the old prefilter obsolete for most cases.

Exactly !!!

From my understanding the internal prefilters are for keeping things simple (which is the entire point of SMDegrain script) and to help inexperienced users with prebuild setups for most scenarios.

As you know prefiltering is very important for satisfying results. And the built in prefilters do a very good job for most cases.
But of course you can always optimize that to your needs by simply using your own prefilters. Or using the same prefilters already integrated but with different parameters. I'd consider the internal prefilters more of a starting point for personal tweaks, but certainly not the optimum. They can't be, because every source is different. So you would end up with dozens of prefilters which would not make much sense imho.

It's alright to call the same prefilter externally so you don't have to worry about numbers anymore.

I think I understand what you're saying, I did change my scripts to "names" from "numbers" a couple of SMDegrain builds ago.

And I do mod the scripts a little to suit the footage, and I do end up with a LOT of different scripts, but I haven't got a problem with that.

[madey83]

You can work with segments and join them later. For example:

a = Trim(0,9999).SMDegrain(...)
b = Trim(10000,19999).SMDegrain(...)
a+b

It will be much more memory hungry though.


:thanks:

[Dogway]

@FTLOY: FYI I was never satisfied with FluxSmoothST. It was a recommendation by Didee from the old ages but produced visible ghosting and also not much denoising. IQMST stands better for the name "nifty spatio-temporal median/gauss blur", I will explain my rationale.
-y
-2,-2 2,-2
* * *
-2 -1 * 1 2 *
-z * * * * * + -x + * * * + IQM = IQMST
* -2,2 2,2 *
* * *
Temporal Stability HD Denoising Sharpness Detail + Motion
+ LF Denoise Protection

https://i.imgur.com/6iN41XKm.png

@madey83: I recommend you to use StainlessS ClipClop() as it will have less memory overhead.

[Guest]

@FTLOY: FYI I was never satisfied with FluxSmoothST. It was a recommendation by Didee from the old ages but produced visible ghosting and also not much denoising. IQMST stands better for the name "nifty spatio-temporal median/gauss blur", I will explain my rationale.

I just think it would be just as easy to leave "stuff" that has been part of SMDegrain for a long time, where it is in the "pecking order", and ADD (not replace) the new one's you want to.

And it's a lot easier now that pre-filters names are used, instead of numbers.

There might have been many users that used Flux, and now they can't :(

And as for your "rationale" info, that means absolutely nothing to me, it's just some random letters & numbers, etc, and some little coloured rectangles :scared:

I will definitely get the new "IQMST" to work, and see how it goes.

Don't get me wrong, I, and many others really appreciate what you're doing, but removing stuff is possibly a little counter productive.

Onward & upward !!

EDIT:-

Did some tests:-

This works for me, but it is very slow to start, and encoding is slower than below call :-

SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter="IQMST",str=1.2,refinemotion=true)

This works a lot better:-

pre=ex_Median(mode="IQMST")
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)

On the 5 minute test 4K clip, the top call took 4 minutes longer, and I think the lower call looks a little better.

3 variants :-

pre=ex_Median(mode="IQM")
pre=ex_Median(mode="IQMV")
pre=ex_Median(mode="IQMST")

string "prefilter"="" (""/ "SBR"/ "MinBlur"/ "MinBlur2"/ "MinBlur3"/ "IQMST"/ "DFTTest"/ "KNLMeans"/ "DGDenoise"/ "BM3D")

Thoughts ??

[Dogway]

@FTLOY: It's the structuring element and why I chose that, maybe some users might find it useful/interesting, it's open source after all so you can fork it where you liked. I mean time is relative and FluxSmoothST was never in the pecking order as you could see with my numerous edits. What I don't want to do is to give the false sensation that prefilter="FluxSmoothST" is good, because it's not, and that's why I changed it. I only want things that make sense, are simple and work as you would expect, at any rate is not like I butchered the filter, it's still in ExTools and you can load as prefilter, but if you have followed my development you would have realized already that my scripts are finished after a last 2 weeks crunch and their versioning, and now I'm done unless something exceptional arises or time permits. I'm on other tasks now but still give support here and in Github if anyone asks like with LeXXuz.

@madey83: This is how you use DGHDRtoSDR. I also posted an example for ClipClop, you can add as many clips as you want, I'm using 15 on a personal project and it doesn't slow down. And also the new IQMST just after DGHDRtoSDR as prefilter.
ConvertBits(16)
deep_resize(1920,edge="Zopti1080")

# Remove big chroma "blocks"
CCD(15)

# Remove blocking and smooth out jagged edges (only applies where motion match fails)
mb=Deblock_QED(quant1=30, quant2=40, aOff1=1, aOff2=1, bOff1=2, bOff2=2, uv=1)
mb=mb.ex_smooth(1, mode="SG", limit=true, sharp=true)

pre =DGHDRtoSDR(mode="pq",white=112)
pre2=pre.ex_Median(mode="IQMST", UV=3, thres=255)

r0=SMDegrain(prefilter=pre2, mfilter=mb, tr=3, thSAD=300, thSADC=150, thSCD1=400, thSCD2=120, LFR=false, plane=4, limits=false, DCTFlicker=false, refinemotion=true, search=5, subpixel=3)
r1=SMDegrain(prefilter=pre2, mfilter=mb, tr=4, thSAD=400, thSADC=200, thSCD1=400, thSCD2=120, LFR=false, plane=4, limits=false, DCTFlicker=false, refinemotion=true, search=5, subpixel=3)

ClipClop(r0,r1,SCmd="r0(0,2937);r1(2938,3854);...")

@LeXXuz: I'll make some room and let you know.


EDIT: By the way I found this (https://forum.doom9.org/showthread.php?t=174706) infamous thread and checked the result and actually felt challenged ^^ The guy probably used Video Artifact which is an old payware solution based on AVS, it has good ideas like the motion compensated sharpening (more like deblur though), and the 420 to 444 chroma reconstruction. I was playing with the sharpening (just spatially) and reached to some point, still need to add some temporal as the example showed increased details not present spatially. One thing I could achieve was better high frequency sharpening leading to a much more HD feel. Still more experimentation is needed.

Orig
https://i.imgur.com/U91Obxl.png
Mine
https://i.imgur.com/nWFB1KX.png
VA
https://i.imgur.com/0bGb6fP.png

[Guest]

@Dogway, could you please comment on my Edit, in my previous post, above ??

Difference in the speed.

[LeXXuz]

EDIT:-

Did some tests:-

This works for me, but it is very slow to start, and encoding is slower than below call :-

SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter="IQMST",str=1.2,refinemotion=true)

This works a lot better:-

pre=ex_Median(mode="IQMST")
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)

On the 5 minute test 4K clip, the top call took 4 minutes longer, and I think the lower call looks a little better.

3 variants :-

pre=ex_Median(mode="IQM")
pre=ex_Median(mode="IQMV")
pre=ex_Median(mode="IQMST")

string "prefilter"="" (""/ "SBR"/ "MinBlur"/ "MinBlur2"/ "MinBlur3"/ "IQMST"/ "DFTTest"/ "KNLMeans"/ "DGDenoise"/ "BM3D")
Thoughts ??

The speed difference and slightly visual difference is probably because SMDegrain uses ex_sbr() after ex_Median() when selecting prefilter=4 or mode "IQMST"

(prefilter== 4) ? pref.ex_Median(mode="IQMST", UV=Chr, thres=255).ex_sbr(3,UV=Chr)