Dogway's Filters Packs

[Reel.Deel]

Well that really doesn't make sense for deep_resize to be changing the frame properties to 709 colorspace when it isn't. It should either assume the colorspace by the input frame resolution or leave it unspecified.

I looked at the script and the only place that I can guess where the frame properties are being set are in ConvertFormat. There's a few calls to that function withing deep_resize. I'm not sure what color format it converts to, it's hard to follow along.

ColorBars(pixel_type="YV12")
propClearAll()
deep_resize(width*2, height*2, grain=0)
propShow(size=24)

At least 4 properties are being set:
https://i.ibb.co/VCQ8fD8/deep-fp.png



avsresize would look like


z_convertformat(pixel_type=last.pixeltype, colorspace_op="170m:709:709:l=>709:709:709:l")


You no longer recommend full=>full (https://forum.doom9.org/showthread.php?p=1906754&highlight=full#post1906754)?

[poisondeathray]

You no longer recommend full=>full (https://forum.doom9.org/showthread.php?p=1906754&highlight=full#post1906754)?

Good point - Full is probably still better, I don't think anything has changed.

I rarely use colormatrix (or related) anymore for upscaling, because almost everything SD I'm upscaling uses machine learning at some point, so it's converted to RGB early on

[simple_simon]

z_convertformat(pixel_type=last.pixeltype, colorspace_op="170m:709:709:l=>709:709:709:l")


Why wouldn't this be the correct way to do it?

z_ConvertFormat(colorspace_op="470bg:601:170m:full=>709:709:709:full")

And does it matter where in the script chain I do the color conversion? Should it be early in the script or after all the cleanup and resizing is done?

At least 4 properties are being set:
https://i.ibb.co/VCQ8fD8/deep-fp.png

That's what I'm seeing too.

[poisondeathray]

Why wouldn't this be the correct way to do it?

z_ConvertFormat(colorspace_op="470bg:601:170m:full=>709:709:709:full")



Matrices 470bg and 170m have the same values Kr = 0.299, Kb = 0.114, so it's the same mathematically

Transfer also have the same values for "601" and "709" so, it's the same mathematically

Primaries are debatable - you actually shift the colors if you go from 170m to 709. Technically, you're supposed to adjust the primaries, but >95% of the time, it's not actually done upstream for the transfer to the DVD in the first place - so you end up with slightly shifted colors if you adjust them in my experience. Primaries are typically not adjusted for in broadcast, BD, DVD, web streaming either (except for HDR) You only get the "correct" colors, if the primaries were handled correctly all the way through, upstream and downstream and the playback method.


And does it matter where in the script chain I do the color conversion? Should it be early in the script or after all the cleanup and resizing is done?


It probably doesn't matter too much, but I'd generally do it near the end.

OTOH, some types of artifacts related to colormatrix conversion can occur with some types of animation (there are some threads and examples on this on this forum and others), so depending on how picky you are , you might want to filter them farther, so earlier could be better in some cases

[poisondeathray]

Sorry, me again :(

I thought I'd give this a try, and as per usual (for me), I'm getting an error with AVSMeter..

https://github.com/Dogway/Avisynth-Scripts/blob/master/GradePack.avsi#L401

Import("%AVISYNTHPLUGINS%\PD_TOOLS\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\GRADE-PACK\Masks Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\MASK-PACK\Grade Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\RESIZERS-PACK\Resizers Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\SCENES-PACK\Scenes Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\TRANSFORM-PACK\Transforms Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\TRANSFORM-PACK\Transforms Pack-Models.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\TRANSFORM-PACK\Transforms Pack-Transfers.avs")
video=ex_autolevels(video,interval=0.5,th=0.1)



You need to run SceneStats before ex_autolevels . 2pass is probably better with a log file, but might be difficult to do in ripbot alone


video = SceneStats(video, mode="Range+Stats",Y=true,UV=false) #1pass , no log file written
video = ex_autolevels(video, interval=0.5,th=0.1)

[poisondeathray]

Try with a small short test video first to see if it "works" at all on your setup - because it can take a while while calculating

[poisondeathray]

Thanks again, PDR, that got it to work...

But I'd hate to think how long it would take to process a 1080p or 4K movie length :( :confused: :(


It was just a quick test to rule out configuration problems (if any)

Actually you can run the 2pass method, since avsmeter is available in ripbot. The analysis will not seem to "hang" and it will "bake" the analysis results into the text file. ie. use avsmeter to run the 1st pass, change the script for the encoding pass (or passes) . Make sure you run the analysis pass single threaded (no prefetch, or prefetch (1), also source filter with threads=1, and/or use a very robust indexed method like DGSource. You also have to edit the log file, there is a repeated section at the top that you have to delete (open in a text editor, and delete all the lines up to the 2nd "Type string" line)

dogway posts this warning in ScenesPack.avsi - that's what it means

### BEWARE!! For some reason in the exported log the first scene has repeated stats so manually remove those lines before loading the file.


analysis pass

video = SceneStats(video, mode="Range+Stats",Y=true,UV=false, path="path\source_stats.log")


encode pass/passes

video = ReadStats(video, "path\source_stats.log")
video = ex_autolevels(video, interval=0.5,th=0.1)



There are other "auto" leveling filters and methods that you can try out too...

[poisondeathray]

What are the other's ?? ;)


What kind of "auto leveling" are you wanting ?

Is it more "general" brightness/darkness/contrast issues, or to deal with "luminance flicker", or "white balance" / color balance/color cast , or something else?

For the general category, you can try AutoLevels, or AutoAdjust

[poisondeathray]

Well, I have tried several white balance types, and they don't work with RipBot (well they do, but they don't).

I used to use a white balance filter when I was using Adobe Premier, and that worked well, I've even tried 3DLUT's to varying degrees of success.

I find I'm tweaking the colours in most of my encodes, mainly taming down "red's".



For avisynth white balance, I find RGBAdapt_AWB_Process is quite good and customizable - results are close to commercial plugins in some cases - but IIRC you had issues running it. It works in ripbot, loading the video then copy/pasting - I just tried it.

And playing with ripbot - I think I figured out the "no error message" black screen MPCHC ripbot preview issue that you sometimes have. AWB_Func didn't work, at first no error message. It turns out I had a typo, which the now visible error message conveyed. What you need to do is move the seekbar in MPCHC, and the error message will pop up

You can also try coloryuv(autowhite=true) , it' s not as advanced but can do the job adequately in some cases

If you prefer the PP filter's, you can use PP . One option is to frameserve in (Premiere AVS Import plugin) / frameserve out (Advanced Frameserver, or Debugmode Frameserver - now called "Cumincode Framserver") . Or use intermediates. I personally prefer intermediates when using PP

[poisondeathray]

I recall that it DID work that way, BUT it did not invoke the distributed encoding function, which is the basically the whole point of RipBot (as far as encoding is concerned)

Even if you got it working - the results would not be ideal distributed anyways. Any distributed, or chunked method will have potential issues with temporal filters "at the seams". Temporal auto leveling is probably the worst type of filter you could use with chunks - it would predispose you to flicker at the joins. You can reduce some of the issues if you overlap the chunks and discard the overlaps before joining, but I don't think ripbot had that feature the last time I checked



Don't use Premiere anymore, no mkv support :(

You can indirectly import MKV's through an .avs. The AVS import plugin doesn't work for many people, but AVFS (avisynth virtual file system) works for everyone and with just about every program (other NLE's too) . Vapoursynth version of avfs is better - because it has fourcc emulation such as UYVY for 8bit422, v210 for 10bit422 - these are treated as "YUV" in NLE's with YUV capable timelines like PP, instead of being "mishandled" as RGB (many lossless YUV codecs and uncompressed YUV formats are mishandled by most NLE's, and get converted to RGB) . "RGB" is usually not a big issue if you're using some auto leveling/auto white balance plugin - because most will be working in RGB anyways

Another option is if you re-wrap (streamcopy) into MP4, PP can import AVC, HEVC too. Native file import such as MP4 colorspace is handled properly

[Dogway]

Thanks DTL and Dogway for your input. Really appreciate it. :thanks:
Something new to fiddle around with the next couple of days. :D

I updated ex_autolevels(), now it's really robust but as I said it's a global operator, I might look into local in the future.

I also updated ex_luma_rebuild() to allow for ex_levels() type of normalization with 'lo' and 'hi' args, but optimized without any performance penalty.

Also updated StabPlus() with ex_autolevels(). Actually you could hack open the StabPlus() function to reuse some code with the below 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)
StabPlus()
crop(2,2,-6,-2)
SceneStats("Range+Stats")

pref = ex_autolevels(hi=true,tv_out=false)
temp = Pref.TemporalSoften(5,255,0,25,2)
rep = temp.Repair(Pref.TemporalSoften(1,255,0,25,2))

pref = ex_merge(rep, pref, MotionMask(rep,dir=0,scale=3,sharpness=2))
SMDegrain(2, 600, mode="TemporalSoften",str=2,prefilter=pref,RefineMotion=true)


ex_unsharp(0.3)
gr = 1
size = (720/2133.) * 3.3
GrainFactory3mod(g1str=7*gr,g2str=9*gr,g3str=7*gr,g1size=1.7*size,g2size=1.4*size,g3size=1.2*size,g1cstr=0.5*gr,g2cstr=0.3*gr,g3cstr=0.1*gr,temp_avg=1,tv_range=true)


For the new SMDegrain update, I'm still missing a bugfix in ex_retinex() for lvl=1 and highlights=false. Just was burnt out with the latest fixes.

This is the new output: link (https://www.mediafire.com/file/xx19gf0e6pavv21/New_File_%2528328%2529_Dog4.mp4/file)

For comparison I was curious to test videoFred's script, it does a good job on stabilization and luma flicker but there's still some wobble: link (https://www.mediafire.com/file/prmza39fdno27bq/New_File_%2528331%2529_VF.mp4/file)

[anton_foy]

I updated ex_autolevels(), now it's really robust but as I said it's a global operator, I might look into local in the future.

I also updated ex_luma_rebuild() to allow for ex_levels() type of normalization with 'lo' and 'hi' args, but optimized without any performance penalty.

Also updated StabPlus() with ex_autolevels(). Actually you could hack open the StabPlus() function to reuse some code with the below 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)
StabPlus()
crop(2,2,-6,-2)
SceneStats("Range+Stats")

pref = ex_autolevels(hi=true,tv_out=false)
temp = Pref.TemporalSoften(5,255,0,25,2)
rep = temp.Repair(Pref.TemporalSoften(1,255,0,25,2))

pref = ex_merge(rep, pref,MotionMask(rep,scale=10,sharpness=5))
SMDegrain(2, 600, mode="TemporalSoften",str=2,prefilter=pref,RefineMotion=true)


ex_unsharp(0.3)
gr = 1
size = (720/2133.) * 3.3
GrainFactory3mod(g1str=7*gr,g2str=9*gr,g3str=7*gr,g1size=1.7*size,g2size=1.4*size,g3size=1.2*size,g1cstr=0.5*gr,g2cstr=0.3*gr,g3cstr=0.1*gr,temp_avg=1,tv_range=true)


For the new SMDegrain update, I'm still missing a bugfix in ex_retinex() for lvl=1 and highlights=false. Just was burnt out with the latest fixes.

This is the new output: link (https://www.mediafire.com/file/xx19gf0e6pavv21/New_File_%2528328%2529_Dog4.mp4/file)

For comparison I was curious to test videoFred's script, it does a good job on stabilization and luma flicker but there's still some wobble: link (https://www.mediafire.com/file/prmza39fdno27bq/New_File_%2528331%2529_VF.mp4/file)

Looking really good! But something is happening on the right in the bushes when the chef is passing by it. Warping kind of.

[Dogway]

Sure, I said before it's not perfect. For these kind of borked sources the best solution is not a surgeon fix, but call TemporalSoften and fix several issues at once.
You can play with the temporal radius of TemporalSoften and SMDegrain to balance the effect, or use a pyramidal approach where you refine motion vectors further and further.
Maybe applying BM3D with high radius to 'rep' frame can improve some stabilization.

[anton_foy]

Sure, I said before it's not perfect. For these kind of borked sources the best solution is not a surgeon fix, but call TemporalSoften and fix several issues at once.
You can play with the temporal radius of TemporalSoften and SMDegrain to balance the effect, or use a pyramidal approach where you refine motion vectors further and further.
Maybe applying BM3D with high radius to 'rep' frame can improve some stabilization.

Actually this is to me very interesting as I am experimenting with wobble and jitter locally to stab. Not quite there yet though but hundreds of ideas.

[Dogway]

I was curious to test the performance of ex_autolevels() on a synthetic test so I made this gradient patch with alternating lifted blacks and gamma.
https://i.imgur.com/wMEhR2q.gif
This is ex_autolevels:
https://i.imgur.com/nUByuUM.gif
Out of curiosity I also tested Autolevels(), I don't know if I'm doing something wrong here, the call is:
Autolevels(filterRadius=10, output_low=0, output_high=255, ignore=0.05, sceneChgThresh=255)
I had to raise sceneChgThresh as it was detecting flicker as SC
https://i.imgur.com/RY2L8XD.gif

Probably if I run a second pass of ex_autolevels() with original stats it can be stabilized further. Will check that.
EDIT: Yes, it's more stable with a second run but 'lo' and 'hi' have to be disabled to avoid a re-normalization:
ex_autolevels(true ,true,false,reStats=false,tv_in=false)
ex_autolevels(false,true,false,reStats=false,tv_in=false)

[LeXXuz]

Looks very interesting! Where would you suggest to put this in a (double) SMDegrain call?


Out of curiosity I took a much closer look on other transfers I did over the last couple of month.

Now that I developed a certain eye for this texture wobble, I see it in a lot of films I did in the past. SD and HD. Even films where you would not expect this because you can hardly see any luma flickering in the source.

I start to believe this texture wobble is some kind of general side effect of the way SMDegrain removes noise or from the motion compensation. I still understand too little on how the entire process works to judge this.

SMDegrain does a terrific job on films that had a very good AD transfer and where filmgrain really is the only kind of noise present. Same goes for modern digital productions where grain is added in post-processing for some arguable reasons.

But on sources where other types of noise are involved, escpecially these 'unstable' sources, the side effects become clearly superficial when you try to go for a clean overall look.

I just had a SD film here where in one scene almost the whole picture wobbled. Right now I'm playing around with other denoisers on this one to see what they can do.

[anton_foy]

@Dogway I think I found what is causing that wobble in the bushes. MotionMask(rep,dir=0,scale=3,sharpness=2) with the temporalsoften lines above it.
Try and see if you change the temporalsoften params lower if the wobble disappear.

[Dogway]

I've been refining ex_autolevels() and now I get it almost perfectly flicker free.
First I had a bug in ArrayDelVal() in ExTools which I'll update soon. Then I added 'Deflicker' arg to ex_autolevels() to make the normalization per scene (autolevels) or per frame (deflicker).

Effectively running 2 passes makes it balanced enough for the gamma flicker.
ex_autolevels(true ,true,false,Deflicker=true,tv_in=false)
ex_autolevels(false,true,false,Deflicker=true,tv_in=false)
https://i.imgur.com/CDYa8L1.gif

This is how you make a flickering patch:
GradientLinear(zoom=1, positive=true, precision=4)
trim(0,32)
SceneStats("Range")

ScriptClip(function [] () {
lo = rand(30)
gm = (rand(100)-50)/200.+1
ex_levels(0,gm,255,lo,255,tv_range=false)
} )

SceneStats("Stats")

...Deflickering here...

ConvertBits(8,dither=1)

For comparison the next is a double call of Deflicker(scene=255,percent=100)
https://i.imgur.com/GooKnPK.gif


@Dogway I think I found what is causing that wobble in the bushes. MotionMask(rep,dir=0,scale=3,sharpness=2) with the temporalsoften lines above it.
Try and see if you change the temporalsoften params lower if the wobble disappear.

Yes I know, but hadn't time to test a new approach. Want to try with my heavy grain prefilter preset like in 21 grams sample, using pyramidal temporal denoising.

Looks very interesting! Where would you suggest to put this in a (double) SMDegrain call?

I start to believe this texture wobble is some kind of general side effect of the way SMDegrain removes noise or from the motion compensation. I still understand too little on how the entire process works to judge this.

SMDegrain does a terrific job on films that had a very good AD transfer and where filmgrain really is the only kind of noise present. Same goes for modern digital productions where grain is added in post-processing for some arguable reasons.

It's DCT flicker, or in other words low frequency temporal "noise", motion and luma flicker just makes it worse. You can take a lowpassed version, temporally denoise it (tricky) and add it back to source. In any case using a radical approach like with temporalsoften prefilter works, I'm going to test with other forms of hardcore prefilters. For best results stabilize your clip motion and luma flicker beforehand then fix DCT flicker.

EDIT: Here an updated script with less wobble but also less background stabilization. Link (https://www.mediafire.com/file/kw7r6wm8tixyvz5)
I tested with ex_reduceflicker() as the clip presented bob-like jitter and worked very nice, also reduced luma flicker a bit further despite not being designed for that.
ffvideosource("noisy_original.mkv")
propSet("_FieldBased",0)

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

StabPlus()
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)
pref2 = ex_reduceflicker(pref,3,true)
pref3 = SMDegrain(tr=3,mode="temporalsoften",blksize=32,thSAD=900,prefilter=pref2,str=2,contrasharp=false,refinemotion=false)

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

ex_unsharp(0.3)
gr = 1
size = (720/2133.) * 3.3
GrainFactory3mod(g1str=7*gr,g2str=9*gr,g3str=7*gr,g1size=1.7*size,g2size=1.4*size,g3size=1.2*size,g1cstr=0.5*gr,g2cstr=0.3*gr,g3cstr=0.1*gr,temp_avg=1,tv_range=true)

EDIT2: And another variation (https://www.mediafire.com/file/1a5lxv2w0wpwim9), less smearing and wobble but again a bit more nervous background. I also replaced StabPlus() with the next videoFred's suggestion (https://forum.doom9.org/showthread.php?p=1981048#post1981048), so much better that I removed ex_reduceflicker().

ffvideosource("noisy_original.mkv")
propSet("_FieldBased",0)

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

StabPlus2()
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 = SMDegrain(tr=3,mode="temporalsoften",blksize=32,thSAD=900,prefilter=pref,str=2,contrasharp=false,refinemotion=false)

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)
gr = 1
size = (720/2133.) * 3.3
GrainFactory3mod(g1str=7*gr,g2str=9*gr,g3str=7*gr,g1size=1.7*size,g2size=1.4*size,g3size=1.2*size,g1cstr=0.5*gr,g2cstr=0.3*gr,g3cstr=0.1*gr,temp_avg=1,tv_range=true)

[simple_simon]

Anybody have an idea what might be causing the horizontal chroma lines in these two screenshots? They don't exist in the source video.

https://send.cm/d/KEeM
https://send.cm/d/KEeP

This is the script I'm using:
z_convertformat(pixel_type=last.pixeltype, colorspace_op="170m:709:709:full=>709:709:709:full").propSet("_ColorRange",1)
tfm(mode=1, pp=7)
tdecimate(mode=0, dupthresh=1.4)
lsfplus(strength=60,ss_x=1.5,ss_y=1.5,soft=30,overshoot=1)
removegrain(mode=5)
propSet("_FieldBased",0).deep_resize(960,720,grain=0,qual=2,gpuid=-1,show=false)
prefetch(2)

I thought I had my upscaling routine nailed down but I guess I'm going to have to go back and redo everything again.

[poisondeathray]

Anybody have an idea what might be causing the horizontal chroma lines in these two screenshots? They don't exist in the source video.


Move z_convertformat after IVTC. "colormatrix" or similar applied on fields can cause similar issue, because it's applying a progressive transform while still organized in fields. There is an interlaced=true/false switch , but I believe it's non functional. Better just to move it

[simple_simon]

Move z_convertformat after IVTC. "colormatrix" or similar applied on fields can cause similar issue, because it's applying a progressive transform while still organized in fields. There is an interlaced=true/false switch , but I believe it's non functional. Better just to move it

(slaps forehead) I should have realized that would cause a problem converting colorspace before detelecine. Thanks for pointing out my mistake. That fixed it.

[Tempter57]

Dogway

I am sorry, but you could not edit Stabilization Tools Pack.avsi and enter there function StabPlus2 ()

[Arx1meD]

Dogway, ex_autolevels for Avisint 3.7.3 only?

[Dogway]

I am sorry, but you could not edit Stabilization Tools Pack.avsi and enter there function StabPlus2 ()
It was a proxy name, there's nothing special about it so you can name it how you want.
# https://forum.doom9.org/showthread.php?p=1981048#post1981048
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)
}

ex_autolevels for Avisint 3.7.3 only?
Yes because it uses SceneStats() which itself requires PlaneMinMaxStats() with 'average' support which was a late addition.


-------------------------

In conversations in Github I recommended an edge masking for anime alternative to FlatMask() and more similar to VapourSynth's detailmask() sometimes surpassing it. It uses a combination of lumamask() and ex_edge() with final mask merging.


LC = ex_unsharp(2,Fc=width()/4) # increase local contrast
LM = lumamask(LC,30,70,invert=true) # luma mask

ex_edge("frei-chen",lo=4,hi=25)

ex_expand(mode="disk")
ex_deflate()
ex_smooth(2,mode="SG")

ex_blend(LM,mode="overlay") # Improve edge masking with luma mask reinforcement

[Tempter57]

Dogway

Thank you, but in my opinion it would be possible simply in StabPlus to set thanks dxmax=20, dymax=20, to refine image stabilising on a bush

[poisondeathray]

I have a 1920 x 960 clip I would like to downscale to 1280 (by whatever it is supposed to be), and if I use this call :-

video=deep_resize(video,1280,flat="nnedi3",grain=0,qual=2)

It errors with a Line 259 error in Resizers Pack.


https://github.com/Dogway/Avisynth-Scripts/blob/master/ResizersPack.avsi#L259


What is the exact error message?


But if I change it to :-

video=deep_resize(video,1920,flat="nnedi3",grain=0,qual=2)

It works...


It should work, because nothing is being resized at 1920 width - a no-op ie. Filter is bypassed. It's the same as not including it.



This works for me, resulting in 1280x640 (2:1)


video=blankclip(width=1920, height=960, pixel_type="YV12")
video=deep_resize(video,1280,flat="nnedi3",grain=0,qual=2)
return video


So deep_resize script is ok. It means the issue is with your specific video or setup - maybe some props issues in the src video (you can try clearing them), also make sure scripts/dependencies are up to date

[kedautinh12]

I was said you need add height for correct result you expect. If not, result won't 1280x720 if your source not 16:9

[poisondeathray]

Hello again, PDR....

I don't want to have to manually add the width & height....



It's not "manually adding width and height" per se - It's a test script making a blank clip with the same dimensions as your example to debug the script. To test if the deep_resize script itself works - It does, so that's ruled out as the problem

I can encode the blank clip, then load it without entering anything - and it works too. So again, the problem is not deep_resize - it's something either with your setup or your video

When you debug something you break it down into parts ,examine each step



But this seems to work:-

video=ConvertBits(video,16)
video=deep_resize(video,1280,edge="SSIM2")[/CODE]

I added these (in red), to get the last line to do it's thing :)



Obviously this is a different script. Do you no longer care about the old one ?

And you still didn't answer the question about exact error message, but if you don't care, then ignore


So let me ask you this, if I load this 1920 x 960 clip into RipBot and ask it to do a resize down to 1280 x 720, it changes it to 1280 x 692, when it should actually be 1280 x 640 ???

Not sure what Ripbot does, I don't really use it.

You can examine the temp files and log to see what it's really doing



Would that be an Avisynth problem, or the way the resizing has been written into RipBot. ??

Not an avs problem

[poisondeathray]

No error msg, other than referencing line 259, and that's where I got the idea for those extra calls & dependencies ;)



Did you try moving the seekbar in mpchc ?



No, it's still that script from the previous page, I just needed to add those calls...


Not really, do these look the same to you?


video=deep_resize(video,1280,flat="nnedi3",grain=0,qual=2)


vs

video=ConvertBits(video,16)
video=deep_resize(video,1280,edge="SSIM2")






Well, it must be the way Atak wrote the resizing functions, then.

It is. It says so in the brackets. "1280x720 [1,85:1 AR]"

1280x720 is achieved by resizing to 1280x692 (1280/692 = 1.8497 - close enough to 1.85 AR), letterbox borders added to get 1280x720 - this is in the script when you select that preset

[poisondeathray]

Come on PDR, one didn't downscale, and the other does...simple, TMWOT.


If it's the same source video, both should be downscaling



It is. It says so in the brackets. "1280x720 [1,85:1 AR]"

1280x720 is achieved by resizing to 1280x692 (1280/692 = 1.8497 - close enough to 1.85 AR), letterbox borders added to get 1280x720 - this is in the script when you select that preset


But not when it should be 1280 x 640 !!!

The preset is doing what it says it would do.

1280x720 [2:1 AR] would take 1920x960 and resize to 1280x640 with letterbox borders 40px top & bottom each to achieve 1280x720

Anyways, it has nothing to do with Dogways filters or avisynth. You should discuss in ripbot thread

[kedautinh12]

You can read document about AddBorders, this code will add black boredrs to change 1280x640 to 1280x720
video=deep_resize(video,1280,640,flat="nnedi3",grain=0,qual=2)
video=AddBorders(video,0,40,0,40)
http://avisynth.nl/index.php/AddBorders

[poisondeathray]

video=deep_resize(video,1280,flat="nnedi3",grain=0,qual=2)

If I change that 1280 to 1920, it does work, as it's a 1920 source....wasn't this the problem I had with deep_resize a couple of weeks ago ??

If you change it to 1920, it's a no-op - so the line is by passed. So it does not really "work"

Yes I think it's a similar issue to what you 've had in the past, but you never answered dogway's questions directly either...

When you ask for help, usually you should make an attempt to answer questions...otherwise people will be less inclined to help


But this call does NOT work for me.


That's what I was trying to help debug...


What preset are you referring to ??

The hypothetical preset that would solve your specific video situation . The preset you want should say 2:1 AR - but there is none with that AR included in the default ripbot. The one you selected gives you the expected result (not what you want, because it's the wrong preset). Maybe you can hack it to include others, or maybe you can add a custom option

[poisondeathray]

I don't want to start adding borders.


There is a custom preset [x,xx:1] included in ripbot. You can just enter the values such as 1280 , 640 . This would have no borders and the correct DAR of 2:1 .

[LeXXuz]

It's DCT flicker, or in other words low frequency temporal "noise", motion and luma flicker just makes it worse. You can take a lowpassed version, temporally denoise it (tricky) and add it back to source. In any case using a radical approach like with temporalsoften prefilter works, I'm going to test with other forms of hardcore prefilters. For best results stabilize your clip motion and luma flicker beforehand then fix DCT flicker.



Thank you very much for those scripts and the explanation. :)

[poisondeathray]

I was playing around with trying to get MPC-BE to work in RipBot, and I played the preview of the clip I was having problems with, and it displayed a pretty comprehensive error message :)


error messages should be the 1st step to solve all your avs problems. Nearly impossible to debug without error messages

"There is no function named 'SSIM_downsample'"

Just "google" the error message, you don't even have to ask or post unless google doesn't have an answer

https://github.com/Asd-g/AviSynthPlus-Scripts/blob/master/SSIM_downsample.avsi





When using this call on a 1920 clip:-

video=deep_resize(video,1280,flat="nnedi3",grain=0,qual=2)

But change that 1280 to 1920, no more error message :)


Of course, this has been mentioned several times, but several different people - the 1920 is a no-op. It's like deleting the line, or commenting out the line

1280 gives you the error message, because you're missing the SSIM_downsample function. (ie. check your prerequisites )

[kedautinh12]

@TDS Or you can use Dogway's SSIM_downsample
https://github.com/Dogway/Avisynth-Scripts/blob/master/EX%20mods/SimilarityMetrics.avsi

[Dogway]

@TDS, could you open your own thread? The last 8 pages or so have been completely yours with mostly RipBot and basic AVS usage questions, going in rounds like a dog trying to catch his own tail, double posting and whatnot. It's going to be suffering for future readers.

For anyone reading, proper discussion ended in first half of page 96 (URL="https://forum.doom9.org/showthread.php?t=182881&page=104), with some break in previous page (page 104 (https://forum.doom9.org/showthread.php?t=182881&page=104)) for luma deflicker.

On another note, I'm finishing SMDegrain documentation, will probably promote it to v4.0.0 and call it "finished".

[guest]

@TDS, could you open your own thread? The last 8 pages or so have been completely yours with mostly RipBot and basic AVS usage questions, going in rounds like a dog trying to catch his own tail, double posting and whatnot. It's going to be suffering for future readers.

For anyone reading, proper discussion ended in first half of page 96 (URL="https://forum.doom9.org/showthread.php?t=182881&page=104), with some break in previous page (page 104 (https://forum.doom9.org/showthread.php?t=182881&page=104)) for luma deflicker.

Hi Dogway,

I think you're being quite unfair at singling me out for all these "non related" post's, it takes 2 (or more) to tango !!!

It started out as a legit question about deep-resize, and it just went on & on from there.

I do recall mentioning that this should go to the RipBot264 thread, but it didn't.

I'm not going to throw anyone under the bus, but it should be very obvious who the main protagonist's were.

I'm sorry I'm not as experienced or as knowledgable as the ppl involved (and yourself), so it takes me a little while for it to sink in.

So to save you further embarrassment of my posts, I have removed some 62 that were "off topic".

Unfortunately by doing so, it leaves a LOT of posts that are now pointless & irrelevant, so maybe they need to be removed, as well.

I honestly appreciate the endless development of your tool's, and they have been a game changer for me.

But I would doubt you will see anymore posts from me, in this thread, in the future.


https://forum.doom9.org/showthread.php?p=1981416#post1981416 first WARN !!!

https://forum.doom9.org/showthread.php?p=1981903#post1981903 second WARN !!!

https://forum.doom9.org/showthread.php?p=1981904#post1981904 legit question about deep-resize

[Boulder]

You could have asked for a moderator to move them to a separate thread, which they will happily do if requested.

[johnmeyer]

The guy hijacks this thread, complains about being singled out and treated unfairly but, oh by the way, he then deletes 62 posts.

Everyone has their own definition of what it means to hijack a thread, but 62 posts about things not related directly to Dogway's amazing filter packs is pretty much the definition of hijacking.

Dogway did the right thing by asking him to start his own thread. That is precisely what should be done when someone goes off topic. This is especially true of this thread which, because his filter packs are so popular, is now over 100 pages in length. We most definitely do not want to have to wade through several pages of posts that are irrelevant to the topic when we want to find out something about Dogway's software.

[Dogway]

Well, just updated SMDegrain mod to 4.0.0 with fully interlaced and YUY2 direct support for all clip type arguments (input, CClip, mfilter and prefilter).
I'm wrapping up my packs so unless something is really borked these will be final. SMDegrain requires now latest versions of the main packs specially LSFplus and SharpenersPack if using sharpening specially with interlaced content.

I also fixed the remaining issues in ex_retinex() hopefully for the good and a few more updates and cosmetics, most important of all the Documentation is finished, so you can have a glance on how things work now although it's pretty much what I've been posting around here.
It's labeled RC (Release Candidate), if I didn't brake anything in a week or two I edit it out.

It's been long so this is my last presentation card for the release.

http://i.imgur.com/pCiSZdhh.png (https://i.imgur.com/pCiSZdh.png)


I also made a heavy refactor of GrainFactory3mod called FilmGrain, I wanted to leverage the option that AddGrainC has to scale up "grain", although it didn't end too well since the grain shows up as big squares instead of round grain, so it's a proof of concept and still need to play with the bias between AddGrainC scaling and blur strength (scaling so to speak). Will upload soon.

Now, I will be installing Windows 10, having a bit of a rest and from time to time improving TransformsPack.
Also I have almost finished my research on HVS (Human Visual System) and surround environment for viewing conditions. It's a two part study with some final suggestions on my part.
It's not AviSynth related but more like HTPC, so probably will post at General Discussion.

[LeXXuz]

Well, just updated SMDegrain mod to 4.0.0 with fully interlaced and YUY2 direct support for all clip type arguments (input, CClip, mfilter and prefilter).
I'm wrapping up my packs so unless something is really borked these will be final.

Thanks a lot for all your hard work. It's very much appreciated! :):thanks:

Btw I see you re-sorted prefilters again. You'd better give a heads up when doing that or people may wonder why their scripts behave strangely different. :D

ex_Median(mode="IQMV", UV=Chr)

That one looks new to me. When would you use that prefilter instead of Minblur or Flux?

[Guest]

Thanks a lot for all your hard work. It's very much appreciated! :):thanks:

Btw I see you re-sorted prefilters again. You'd better give a heads up when doing that or people may wonder why their scripts behave strangely different. :D

ex_Median(mode="IQMV", UV=Chr)

That one looks new to me. When would you use that prefilter instead of Minblur or Flux?

There has been so many updates in the passed days, it can be frustrating.

As for SMDegrain, the pre-filter order was changed back at build 3.5.8.

3.5.8

pref = !GlobalR ? preclip ? UHDhalf ? pref : prefilter : \
(prefilter==-1) ? pref : \
(prefilter== 0) ? pref.ex_MinBlur(0,Chr) : \
(prefilter== 1) ? pref.ex_MinBlur(1,Chr) : \
(prefilter== 2) ? pref.ex_MinBlur(2,Chr) : \
(prefilter== 3) ? pref.ex_Median(mode="IQMV",UV=Chr) : \
(prefilter== 4) ? pref.ex_FluxSmoothST(2,1,255,0,false,UV=Chr) : \
(prefilter== 5) ? ex_merge(dfttest(pref,sstring="0.0:4.0 0.2:9.0 1.0:15.0",tbsize=1,U=chroma,V=chroma,dither=1,threads=1,sbsize=12,sosize=6,swin=2),pref, \
pref.ex_lut(Format("range_max range_max {Lthres} ymin - / x ymin - * -"),UV=1,clamp_float=true), luma=chroma, UV=Chr) : \
(prefilter== 6) ? pref.ex_KNLMeansCL(a=2,s=2,d=1,h=7.0,wmode=1,chroma=chroma,gpuid=gpuid,LFR=600*(nw/1920.)).ex_boxblur(0.5, mode="weighted", UV=Chr) : \
(prefilter== 7) ? pref.ex_DGDenoise(str=0.10,LFR=nw/2.,UV=Chr). ex_boxblur(0.5, mode="weighted", UV=Chr) : \
(prefilter== 8) ? pref.ex_BM3D(10,1,"normal",UV=Chr,gpuid=gpuid,tv_range=!fsp) : \
Assert(false, "SMDegrain: Prefilter must be between -1~8: "+string(prefilter)) : \
pref

3.5.7

pref = !GlobalR ? preclip ? UHDhalf ? pref : prefilter : \
(prefilter==-1) ? pref : \
(prefilter== 0) ? pref.ex_MinBlur(0,Chr) : \
(prefilter== 1) ? pref.ex_MinBlur(1,Chr) : \
(prefilter== 2) ? pref.ex_MinBlur(2,Chr) : \
(prefilter== 3) ? pref.ex_FluxSmoothST(2,2,255,0,false,UV=Chr) : \
(prefilter== 4) ? ex_merge(dfttest(pref,sstring="0.0:4.0 0.2:9.0 1.0:15.0",tbsize=1,U=chroma,V=chroma,dither=1,threads=1,sbsize=12,sosize=6,swin=2),pref, \
pref.ex_lut(Format("range_max range_max {Lthres} ymin - / x ymin - * -"),UV=1,clamp_float=true), luma=chroma, UV=Chr) : \
(prefilter== 5) ? pref.ex_KNLMeansCL(a=2,s=2,d=1,h=7.0,wmode=1,chroma=chroma,gpuid=gpuid,LFR=600*(nw/1920.)).ex_boxblur(0.5, mode="weighted", UV=Chr) : \
(prefilter== 6) ? pref.ex_DGDenoise(str=0.10,LFR=nw/2.,UV=Chr). ex_boxblur(0.5, mode="weighted", UV=Chr) : \
(prefilter== 7) ? pref.ex_BM3D(10,1,"normal",UV=Chr,gpuid=gpuid,tv_range=!fsp) : \
Assert(false, "SMDegrain: Prefilter must be between -1~7: "+string(prefilter)) : \
pref

I need to apologize for this post being out of sync with the discussion, I had to wait for it to be approved..
And in that time, it has changed a couple of times.

[Dogway]

Btw I see you re-sorted prefilters again. You'd better give a heads up when doing that or people may wonder why their scripts behave strangely different. :D

ex_Median(mode="IQMV", UV=Chr)

That one looks new to me. When would you use that prefilter instead of Minblur or Flux?
Yes, it's explained in the docs now (https://raw.githack.com/Dogway/Avisynth-Scripts/master/SMDegrain/SMDegrain.html#prefilter2), it was changed a month ago in v3.5.8. I was thinking to also create a string type for 'prefilter' so you can define the prefilter preset with absolute terms like "DFTTest", instead of trying to remember the number. Will update with that.

[kedautinh12]

Yes, it's explained in the docs now (https://raw.githack.com/Dogway/Avisynth-Scripts/master/SMDegrain/SMDegrain.html#prefilter2), it was changed a month ago in v3.5.8. I was thinking to also create a string type for 'prefilter' so you can define the prefilter preset with absolute terms like "DFTTest", instead of trying to remember the number. Will update with that.

Are you test with RIFE-denoise and avs_mlrt??

[DTL]

RIFE-denoise is still sort of RIFE-MC only. It still require complex enough blending engine and simplest Average() may create significant blurring and very bad blends where RIFE fail to do ideal motion compensation. For better denoise activity it is require to set new task to developers of its neural-network to create as best possible motion compensated frames with 'current' frame as target. Currently it only hack-like usage of inbetween frame interpolator as motion-conpensation to 'current' timestamp using +N and -N frames only (a pair of frames only). For best results it need to analyse large sets of frames around current frame including current frame (and it will be even much more slower and may take much more memory).

So it is required to go to RIFE core developers, present current state of RIFE-denoise system and its current issues and ask for may be new RIFE core mode for denoise action specifically.


Now, I will be installing Windows 10,

Finally you can try DX12-ME with post-2.7.45 mvtools builds and your GTX1070 card.

[LeXXuz]

Finally you can try DX12-ME with post-2.7.45 mvtools builds and your GTX1070 card.

I'd love to have that in an upcoming build of SMDegrain someday. :rolleyes: :D

[Dogway]

@LeXXuz: Updated with absolute string preset names. Now you can do prefilter="DFTTest". IQMV is very similar to ex_MinBlur(3) but faster, and FluxSmoothST is a spatio-temporal version of MinBlur (only spatial).

I also added "RIFE" as 'mode' denoiser, but I didn't see much value in it, it doesn't denoise much, and warps content a little bit.

EDIT: I'm not convinced enough, so if nobody opposes I remove it in the next revision.

Finally you can try DX12-ME with post-2.7.45 mvtools builds and your GTX1070 card.

Maybe if I have time, I also want to run some AI scaling and delogo on personal projects. My card is not that much but nvidia releases have been a train-wreck lately so...

[LeXXuz]

@LeXXuz: Updated with absolute string preset names. Now you can do prefilter="DFTTest". IQMV is very similar to ex_MinBlur(3) but faster, and FluxSmoothST is a spatio-temporal version of MinBlur (only spatial).


Thanks for that update and the updated docs. The new parts about prefiltering were very interesting.

Because of that I'm fiddling around with a custom prefilter an I was wondering what I have to set for tv_range (true or false) when calling ex.BM3D()?
In SMDegrain it's set to tv_range=!fsp but I couldn't make out the syntax how the fsp variable is set. My Avisynth knowledge is too elementary. :o

[kedautinh12]

You set SMDegrain=true or false, ex_bm3d will set like that

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

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

[Guest]

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

Thnx LeXXuz,

I might change the scripts then..

[madey83]

@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


@Dogway,

thank you so mutch for this... going to test this out. :)

[madey83]

@Dogway,

i have tested your proposition with below

# 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);...")

but unfortunatly convert HDR to SDR mess sothing up with the DV colors and picture is broken.

i have tried to replace
pre =DGHDRtoSDR(mode="pq",white=112)
pre2=pre.ex_Median(mode="IQMST", UV=3, thres=255)

by

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

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=6, thSAD=600, 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);...")

but i still have lots of gain. i can't force SMDegrain to remove more grain.

[anton_foy]

Regarding the topic of motion protecting temporal filtering, could this reasoning be of use/inspiration(?):
function mprotect(clip c, int "tr"){
q=temporalsoften(c,tr,255,255,255,2).repair(c,mode=16).neo_vd() #neo vd is fast
q.ex_blur3D(0,0,tr+1,"weighted",UV=3).ex_AddDiff(ex_MakeDiff(c,q,UV=3),UV=4) #parameters borrowed from Dideé, not sure uv=4 is working with ex_adddiff

return last
}​
Not tested yet. Maybe IQMT would replace temporalsoften+repair in this case?

[DTL]

"i can't force SMDegrain to remove more grain."

To remove more grain it is typically require higher tr and thSAD. tr may be 20 and more. Upper limit is 128. With thSAD user adjust beginning of denoising and amount of blurred details.

Also:
thSAD=600, thSADC=200, thSCD1=400,

thSCD1 must be > thSAD or it will limit degraining to nothing. If thSCD1 is comparable or below noise-SAD it cause to treat all frames as scenechange and no denoising applied at all with any tr.
It is better to set condition check and error-throwing in SMDegrain script if user set thSCD1 < thSAD.

To make adjustments easier you can set user equation like

my_thSAD = N
my_thSCD1 = my_thSAD + 100

thSAD=my_thSAD, thSADC=my_thSAD - 100, thSCD1=my_thSCD1,

[zorr]

Feature request: an optional argument to define prop name in similarity metric functions (GMSD, MDSI, SSIM & others).

Sometimes I need to measure similarity more than once in a Zopti script. For example you can optimize for two different similarities at the same time. Currently you need to rename the similarity metric props before you call the metric the second time. It would be easier (and faster) to be able to define the prop's name in the first place.

For example
GMSD(clip, ref, propName="_PlaneGMSD_first")
GMSD(clip2, ref2, propName="_PlaneGMSD_second")

[madey83]

"i can't force SMDegrain to remove more grain."

To remove more grain it is typically require higher tr and thSAD. tr may be 20 and more. Upper limit is 128. With thSAD user adjust beginning of denoising and amount of blurred details.

Also:
thSAD=600, thSADC=200, thSCD1=400,

thSCD1 must be > thSAD or it will limit degraining to nothing. If thSCD1 is comparable or below noise-SAD it cause to treat all frames as scenechange and no denoising applied at all with any tr.
It is better to set condition check and error-throwing in SMDegrain script if user set thSCD1 < thSAD.

To make adjustments easier you can set user equation like

my_thSAD = N
my_thSCD1 = my_thSAD + 100

thSAD=my_thSAD, thSADC=my_thSAD - 100, thSCD1=my_thSCD1,

Thank you DTL, script has been adjusted to your guidence. :thanks:

[Dogway]

@madey83: Then I need to have a look at the clip, a small sample is enough.

@FTLOY: Yes, internally IQMST also adds ex_sbr(3) so it might be slower, but in contrast it does so over the halved source clip, as by default UHD is using downscaled vectors. You can either set UHDhalf=false, or use another less aggressive prefilter preset.
The different IQMs fill different purposes, IQM is the canonical algo over a 3x3 kernel, IQM5 is the same over a 5x5 kernel, both spatial. IQMV is IQM + IQM5 thresholded by variance, so it's a very good spatial prefilter specially for anime where temporal (pre)filters causes more harm than good, it's similar to what ex_MinBlur(3) would look like but much faster. Then the new IQMST is a spatio-temporal custom kernel as explained above for very grainy live action HD sources, you can also use BM3D for this, but that's more kind of brute force and probably slower. If you want a lighter spatio-temporal prefilter maybe use prefilter=6 or set up a custom one using STTWM.

@anton_foy: I don't understand the script much, I rewrite it here:

function mprotect(clip a, int "tr") {

tr = Default(tr,2)
a
TemporalSoften(tr,255,255,255,2)
repair(a,mode=16)
# or ex_median("IQMT")
neo_vd()
q=last
ex_blur3D(0,0,tr+1,mode="weighted",UV=3)
ex_MakeAddDiff(a,q,last,UV=6) }

So you diff 'a' vs 'q' which is a lot of grain and add it back to ex_blur3D() ? What you get is exactly that, a TemporalGauss with some grain recovered. With 'IQMT' the difference is greater so it's mostly a noop. I still find 'IQMST' the better option, take a bunch of samples, spatial+temporal, remove 50% of the furthermost samples (outliers), make an average of the remaining. You can expand on this idea by using different spatial and temporal kernels depending on your needs like "not much blurring", or "more temporal weighting", etc. For example, an interesting one would be cross(4) + square(9) + cross(4) or dot(1) + cross(4) + square(25) + cross(4) + dot(1)

@zorr: Done, updating in a few moments


BTW I updated QTGMC+ with new EdiModes that preserve details better, so the presets have been changed with new EdiModes but now should look better overall, now speedwise it can't be compared to original QTGMC as it's not an apples to apples. I also fixed an issue on chroma, and a regression in the last version for sourcematch.

[Boulder]

thSCD1 must be > thSAD or it will limit degraining to nothing. If thSCD1 is comparable or below noise-SAD it cause to treat all frames as scenechange and no denoising applied at all with any tr.
It is better to set condition check and error-throwing in SMDegrain script if user set thSCD1 < thSAD.

As far as I've understood, thSCD1 is the SAD threshold to mark a block as a valid scene change. thSCD2 is then the limit to determine if the frame contains enough of such blocks to mark it as a scene change. I suggest using MShow to see how it works and if the thresholds require tuning.

[madey83]

[QUOTE=Dogway;1984444]@madey83: Then I need to have a look at the clip, a small sample is enough.

sample: https://mega.nz/file/4RhxEZSL#CfNkhLSRSaGwSHWSIFr-HUPLqmra8keKAVfwi58nZTg

:thanks:

[Dogway]

@madey83: Then I need to have a look at the clip, a small sample is enough.
sample:
:thanks:
What, are you guys testing me? lol, lots of crap over shading! That's very difficult since you have to refine over and over with 'pre' and 'LFR'. Here an attempt:

src = last
pref = pref_DeWobble()

pre=smdegrain(2,mode="TemporalSoften",thSAD=500,prefilter=pref,mfilter=pref,LFR=true,DCTFlicker=false)
ft =smdegrain(3,mode="MDegrain" ,thSAD=400,prefilter=pre.ex_gaussianblur(2),mfilter=pre,LFR=true,refinemotion=true)
ex_merge(pre.ex_Median(mode="IQM5",thres=255), ft, MotionMask(pref,scale=10,sharpness=0))

ex_LFR(src,LFR=Width()/24.,UV=3)
smdegrain(1,mode="MDegrain",thSAD=400,refinemotion=true)
# Some film grain here

function pref_DeWobble(clip clp) {
clp.ex_blur3D(0,0,2,"weighted",UV=3)
ex_LFR(clp)
ex_gaussianblur(2)
ex_unsharp(-0.3,Fc=width()/2.5)
MergeChroma(clp) }

[LeXXuz]

Then the new IQMST is a spatio-temporal custom kernel as explained above for very grainy live action HD sources, you can also use BM3D for this, but that's more kind of brute force and probably slower. If you want a lighter spatio-temporal prefilter maybe use prefilter=6 or set up a custom one using STTWM.


What does the threshold do in IQMST? Can it be used to adjust the filters strength somehow? Filtering and speed is very good but it's too strong to my taste. BM3D IS a lot slower but it can be adjusted in strength seamlessly.

KNLM has a higher quality than DGDenoise, I guess? The latters speed is unmatched on the other hand.

I can't find STTWM, is this one of your filters?

Regarding my wobbling problem:

With Scenestats enabled and needed for ex_Autolevels() I have a performance problem on longer encodes. It works well for shorter clips or scenes but slows down the script the longer the clip to encode is. Looking in task manager it pauses the encode every couple of seconds for a few seconds (probably gathering scene data?) then continues. But these pauses get longer and longer. Inflating the overall encode time quite a lot.
Is this maybe because scene data is gathered on the fly? Maybe it would be better to gather data for the entire video and store it in a file?

[madey83]

What, are you guys testing me? lol, lots of crap over shading! That's very difficult since you have to refine over and over with 'pre' and 'LFR'. Here an attempt:

pref = pref_DeWobble()

pre=smdegrain(2,mode="TemporalSoften",thSAD=500,prefilter=pref,mfilter=pref,LFR=true,DCTFlicker=false)
ft =smdegrain(3,mode="MDegrain" ,thSAD=400,prefilter=pre.ex_gaussianblur(2),mfilter=pre,LFR=true,refinemotion=true)
ex_merge(pre.ex_Median(mode="IQM5",thres=255), ft, MotionMask(pref,scale=10,sharpness=0))

smdegrain(1,mode="MDegrain",thSAD=400,refinemotion=true)
ex_LFR(pre,LFR=Width()/16.,UV=3)
# Some film grain here

function pref_DeWobble(clip clp) {
clp.ex_blur3D(0,0,2,"weighted",UV=3)
ex_LFR(clp)
ex_gaussianblur(2)
ex_unsharp(-0.3,Fc=width()/2.5) }


Hi Dogway,

i'm not testing You, i'm looking for help from you how to handle that shitty source.

I'm going to test your call. Thank you for that :)

[anton_foy]

@anton_foy: I don't understand the script much, I rewrite it here:

Code:
function mprotect(clip a, int "tr") {

tr = Default(tr,2)
a
TemporalSoften(tr,255,255,255,2)
repair(a,mode=16)
# or ex_median("IQMT")
neo_vd()
q=last
ex_blur3D(0,0,tr+1,mode="weighted",UV=3)
ex_MakeAddDiff(a,q,last,UV=6) }
So you diff 'a' vs 'q' which is a lot of grain and add it back to ex_blur3D() ? What you get is exactly that, a TemporalGauss with some grain recovered. With 'IQMT' the difference is greater so it's mostly a noop. I still find 'IQMST' the better option, take a bunch of samples, spatial+temporal, remove 50% of the furthermost samples (outliers), make an average of the remaining. You can expand on this idea by using different spatial and temporal kernels depending on your needs like "not much blurring", or "more temporal weighting", etc. For example, an interesting one would be cross(4) + square(9) + cross(4) or dot(1) + cross(4) + square(25) + cross(4) + dot(1)


Damn sorry, I copied and pasted and modified an old script so I think I mixed up somethings. My idea was to use temporalsoften.repair mode=16 and neo_vd'spixels to get the difference (the temporal with hard motion ptotection of mode=16 then extra pixels of neo_vd) in order for the applied temporal filter to be "limited" to those pixels of the difference. But I did not test it so I screwed up :D
My reasoning is to get away from too much prefiltering and get such a good motion protected temporal filtering technique so that medium-to-high motion is not smeared or motion blurred and to let the spatial handle that part.

[Dogway]

@LeXXuz: Not strength per se but threshold, by default it's set to around 20 when used standalone with ex_median() as it recovers some details. For prefilter this is not important as edges should be soft. It's meant for VERY grainy sources. If you don't like STTWM() (inside ExTools) simply use IQMST and with a lut dial back some strength like "x y + 0.5 *". There are alternative kernels I explained in the last page, but they have to be built.

KNLMeansCL is spatio-temporal, while DGDenoise can only do temporal and it's CUDA based so maybe those 2 reasons are why it's much faster, I haven't benchmarked though

On SceneStats, yes, for every new scene it looks ahead all the scene's information, then proceeds as normal. The longer the scene the longer the pause, but it shouldn't repercute whether you are in the begginning of the encode or later on, it only depends on scene's length. Now there might be memory leak issues in ScriptClip as I reported to pinterf. He should be releasing the fix soon in next test build. SceneStats is a proof of concept, to show that a scene based workflow is possible, ideally someone should port it to a plugin for best performance.

@madey83: I updated the script, give it a test.

@anton_foy: Read my suggestion to LeXXuz, you can dial back IQMST with a lut. If you want motion discretization for a fast alternative to SMDegrain use MotionMask() as shown in the above script.

[madey83]

@madey83: I updated the script, give it a test.




testing...

is there an option to put this whole call to one variable and assignt it to
ClipClop(r0,r1....)?

[Dogway]

Yes, call back the src pointer.

r0=xx
r2=xx

src=last

[the above script]

r1=last
src

ClipClop(r0,r1,r2...)

[madey83]

Yes, call back the src pointer.

r0=xx
r2=xx

src=last

[the above script]

r1=last
src

ClipClop(r0,r1,r2...)


Your script does some "black magic" (would be super to know what exactly each line does - if you have time for explanation of course) with this video. It looks increadible.

Thank you, Thank you for Your help. :D:D:D:D:D:D:D

[madey83]

Yes, call back the src pointer.

r0=xx
r2=xx

src=last

[the above script]

r1=last
src

ClipClop(r0,r1,r2...)


i think i did what you explained:

mb=Deblock_QED(quant1=30, quant2=40, aOff1=1, aOff2=1, bOff1=2, bOff2=2, uv=3)
mb=mb.ex_smooth(1, mode="SG", limit=true, sharp=true)

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

my_TR = 3
my_thSAD = 250
my_thSCD1 = my_thSAD + 100

r0=SMDegrain(prefilter=pre, mfilter=mb, tr=my_TR, thSAD=my_thSAD, thSADC=my_thSAD-100, thSCD1=my_thSCD1, thSCD2=120, LFR=false, plane=4, limits=false, DCTFlicker=false, refinemotion=true, search=5, subpixel=3)

src = last
pref = pref_DeWobble()

pre=smdegrain(2,mode="TemporalSoften",thSAD=500,prefilter=pref,mfilter=pref,LFR=true,DCTFlicker=false)
ft =smdegrain(3,mode="MDegrain" ,thSAD=400,prefilter=pre.ex_gaussianblur(2),mfilter=pre,LFR=true,refinemotion=true)
ex_merge(pre.ex_Median(mode="IQM5",thres=255), ft, MotionMask(pref,scale=10,sharpness=0))

ex_LFR(src,LFR=Width()/24.,UV=3)
smdegrain(1,mode="MDegrain",thSAD=400,refinemotion=true)
# Some film grain here

function pref_DeWobble(clip clp) {
clp.ex_blur3D(0,0,2,"weighted",UV=3)
ex_LFR(clp)
ex_gaussianblur(2)
ex_unsharp(-0.3,Fc=width()/2.5)
MergeChroma(clp) }

r1=last
src

ClipClop(r0,r1,SCmd="r0(0,24400);r1(24401,32210);r0(32211,41679)")

Script error: ConverttoYUV444 does not have a named argument 'param1' SMDgrain.avsi, line 1147

:scared::scared:

[LeXXuz]

Script error: ConverttoYUV444 does not have a named argument 'param1' SMDgrain.avsi, line 1147

:scared::scared:

Update to Avisynth+ 3.7.3 test 7 (20230223):
https://forum.doom9.org/showthread.php?t=181351

[madey83]

Update to Avisynth+ 3.7.3 test 7 (20230223):
https://forum.doom9.org/showthread.php?t=181351

thank you LeXXuz, but still the same..

[LeXXuz]

Have you updated plugins and system files from the package correctly? Check version you are using with version() command. What does it show?

[madey83]

Have you updated plugins and system files from the package correctly? Check version you are using with version() command. What does it show?

[Avisynth info]
VersionString: AviSynth+ 3.7.3 (r3940, master, x86_64)
VersionNumber: 2.60
File / Product version: 3.7.3.0 / 3.7.3.0
Interface Version: 10
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\SYSTEM32\avisynth.dll
Avisynth.dll time stamp: 2023-02-23, 15:54:11 (UTC)
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+


[C++ 2.6 Plugins (64 Bit)]
C:\Program Files (x86)\AviSynth+\plugins64+\ConvertStacked.dll [2023-02-23]
C:\Program Files (x86)\AviSynth+\plugins64+\DirectShowSource.dll [2022-04-19]
C:\Program Files (x86)\AviSynth+\plugins64+\ImageSeq.dll [2023-02-23]
C:\Program Files (x86)\AviSynth+\plugins64+\Shibatch.dll [2023-02-23]
C:\Program Files (x86)\AviSynth+\plugins64+\TimeStretch.dll [2023-02-23]
C:\Program Files (x86)\AviSynth+\plugins64+\VDubFilter.dll [2023-02-23]

[Scripts (AVSI)]
C:\Program Files (x86)\AviSynth+\plugins64+\colors_rgb.avsi [2021-01-11]

[Uncategorized files]
C:\Program Files (x86)\AviSynth+\plugins64+\colors_rgb.txt [2021-01-11]

i think i forgot to update my StaxRip folder dlls....


edit: no longer error apears :). Thank you :D

[LeXXuz]

@LeXXuz: Not strength per se but threshold, by default it's set to around 20 when used standalone with ex_median() as it recovers some details.
So, the higher the threshold the more it recovers, or vice versa? So far I like the speed and result on very noisy sources. Looks more homogeneous than with BM3D indeed. And leaves more detail intact. BM3D kills too much fine detail when used with higher sigma values.


...simply use IQMST and with a lut dial back some strength like "x y + 0.5 *".
I tried to figure out how to do that, but couldn't make it work. Could you give me hint?

As for STTWM. It works good on sources with fine grain.
But I wonder where to adjust from the default call STTWM(sw=24,tw=49,aw=1,sthres=5,tthres=5,UV=3), to modify 'strength' a little if it can be called that way.
Sw/tw or sthres/tthres? Do those thresholds work similar as with IQMST?

[Lan4]

I have a question about SharpenersPack. Tell me, what speed filters are recommended to use now?

I liked Finesharp (HBD mod). But now I've tried DetailSharpen (by Dogway) and I see some of its benefits. Which of these filters do you prefer? Or maybe use both?

I do not need to diligently select the best video processing option. Some distortion and file size increase are acceptable. My videos are middle quality (or worse), a lot of phone videos. Before the sharpen filter, I use down resize (UserDefined2ResizeMT), down bitrate (VCEEnc 265 CQP), denoise (FFT3DGPU AMD). I would really like it if you could use one processing method for all videos, even if this is not the best option.

[Dogway]

So, the higher the threshold the more it recovers, or vice versa?

I tried to figure out how to do that, but couldn't make it work. Could you give me hint?

As for STTWM. It works good on sources with fine grain.
But I wonder where to adjust from the default call

You can test though, the higher the thres the less protection. Just like TemporalSoften using 255 is unprotected.

To balance the strength use the following, change 0.3 to anything between 0.1 and 0.9:
pre=ex_Median(mode="IQMST",thres=255)
ex_lutxy(pre,"x dup y - 0.3 * -")

After you comment the other day I revised STTWM and set new defaults (not uploaded yet), as the old ones were mostly noop. I also noted so examples:
# STTWM(sw=20,tw=80,aw=100,sthres=255,tthres=7) # Strong temporal
# STTWM(sw=40,tw=60,aw=100,sthres=255,tthres=5) # Strong spatial
# STTWM(sw=50,tw=50,aw=100,sthres= 5,tthres=5) # Balanced
# STTWM(sw=50,tw=50,aw= 10,sthres= 5,tthres=5) # Light

This is more for fine grain as you say, not for sticky grain. 'sw' and 'tw' are meant to sum 100, but is not mandatory, it will be scaled internally to a range of 100 if they don't sum that.
Also you can try now the ex_autolevels() script, AVS+ test 9 might have fixed the memory leak issues we talked about.

I have a question about SharpenersPack. Tell me, what speed filters are recommended to use now?

I liked Finesharp (HBD mod). But now I've tried DetailSharpen (by Dogway) and I see some of its benefits. Which of these filters do you prefer? Or maybe use both?

I do not need to diligently select the best video processing option. Some distortion and file size increase are acceptable. My videos are middle quality (or worse), a lot of phone videos. Before the sharpen filter, I use down resize (UserDefined2ResizeMT), down bitrate (VCEEnc 265 CQP), denoise (FFT3DGPU AMD). I would really like it if you could use one processing method for all videos, even if this is not the best option.

I do like ex_unsharp() a lot, and lately use it oftenly not only to sharpen, but also for deconvolution. You can sharpen or blur different frequencies, it's very fast and can use the 'safe' arg to alleviate ringing. Anyhow it's not masked so it will also sharpen grain, since your videos lack grain I think it might be a nice solution. I also like FineSharpPlus quite a bit, I implemented the non-linearity of LSFplus but I found to dislike the default 'xstr' value, IMO set 'xstr' to 0.0. Another option with masking is LSFplus with 'LSF' preset, but this last option is a bit slower than the other two solutions. Also experiment with the other filters, I haven't done a thorough quality comparison.

[DTL]

" down resize (UserDefined2ResizeMT)"

It can be already 'very sharp' if use low enough b and c values. Though to add sharpnes at output it require not very blurry source and large enough downsaize ratio (like 2 and more). Also I forgot to upload of pre-release of version with also adjustable 'support/s' param. In old versions it is fixed to 2 (2.0) but it was found can visibly add 'sharpness/acutance' (increasing width of halo) if adjusting to the larger value (in range 2..3 is the most visible difference). So in newer versions it is expected to adjust in range 1.5..15 with default to 2.2. Unfortunately latest updates from jpsdr require MFC for VisualStudio to build and I typically not install it. Trying to download and install now to make a pre-release build for users to test.

The pull-request to jpsdr plugins and main AVS core is created at Febuary of 2023 but it may takes again months and/or years for accepting after some user tests and reports.

If your source is very blurry you need sharpeners with larger 'radius' or kernel size - you can try GeneralConvolution with kernels from 5x5 and larger. See example at https://forum.doom9.org/showthread.php?p=1984297#post1984297 .

[Lan4]

Dogway, thank you for answer.
your videos lack grain I think
Yes. I mainly need a sharpener to remove the blur that appears in the previous steps.

I also like FineSharpPlus
I don't understand how hdmp works in FineSharpPlus. I take the values I need from FineSharp and use them in FineSharpPlus. And the video becomes blurry compared to FineSharp. Always, no matter what value of hdmp I set.

The values in FineSharp are something like this:
mode=1, sstr=3.9, cstr=0.1, xstr=0, lstr=1.2, pstr=4, ldmp=1.3

[LeXXuz]

To balance the strength use the following, change 0.3 to anything between 0.1 and 0.9:
pre=ex_Median(mode="IQMST",thres=255)
ex_lutxy(pre,"x dup y - 0.3 * -")

Thanks! Is it possible to replace the number by a variable? I guess not, as this is probably read as a whole string, right?


After you comment the other day I revised STTWM and set new defaults (not uploaded yet), as the old ones were mostly noop. I also noted so examples:
# STTWM(sw=20,tw=80,aw=100,sthres=255,tthres=7) # Strong temporal
# STTWM(sw=40,tw=60,aw=100,sthres=255,tthres=5) # Strong spatial
# STTWM(sw=50,tw=50,aw=100,sthres= 5,tthres=5) # Balanced
# STTWM(sw=50,tw=50,aw= 10,sthres= 5,tthres=5) # Light
This is more for fine grain as you say, not for sticky grain. 'sw' and 'tw' are meant to sum 100, but is not mandatory, it will be scaled internally to a range of 100 if they don't sum that.


Took a quick test with those presets. Exactly what I was looking for on films with fine grain. :)


Also you can try now the ex_autolevels() script, AVS+ test 9 might have fixed the memory leak issues we talked about.

Already running a test. :D

Could you take a quick look over this template? I'm still uncertain on how to use filter 'cascades' correctly and if the filter chain works in the order I intended.
What it should do is:

First DeWobble is used with ex_autolevels() on the clip. Then this should be denoised by IQMST, which is strength controlled by ex_lutxy().
Lastly brightness and gamma corrected to be fed as prefilter for 1st stage of SMDegrain, mode=TemporalSoften.
Then all this is fed as prefilter to the 2nd stage of SMDegrain, with a 2nd and weaker instance of IQMST as mfilter for those motion areas where MVtools can't find a match.
Lastly some final sharpening and minor debanding.


ConvertBits(16)
crop(4, 4, -4, -4)
SceneStats("Range+Stats")
#
Stage=06#
#
PREl1 = ex_autolevels( true ,true, true,Deflicker=true,tv_out=false)
PREl2 = ex_autolevels(PREl1,false,true,false,Deflicker=true,tv_out=false)
PREmo = ex_Median(mode="IQMST", UV=3,thres=min(100,(Stage*10)))
PREmv = ex_Median(mode="IQMST", UV=3,thres=min(200,(Stage*20)))
PREm = ex_lutxy(PREmo,"x dup y - 0.3 * -").ex_sbr(1,UV=3)
PREv = pref_DeWobble(PREl2).ex_lutxy(PREmv,"x dup y - 0.6 * -").ex_sbr(2,UV=3).Levels(0,1.25,255*256,(((Stage*2)-2)*256),((208-(Stage*8))*256))
#
PREs = SMDegrain(mode="TemporalSoften", tr=6, thSAD=(Stage*70), thSADc=(Stage*60), thSCD1=max(400,(Stage*80)), Str=2.0, contrasharp=false, LFR=false, DCTFlicker=false, refinemotion=false, truemotion=true, blksize=16, search=5, pel=2, subpixel=3, prefilter=PREv, chroma=true, plane=4, gpuid=-1, interlaced=false)
#
SMDegrain(mode="MDegrain", tr=6, thSAD=(Stage*60), thSADc=(Stage*50), thSCD1=max(400,(Stage*70)), Str=2.0, contrasharp=true, LFR=true, DCTFlicker=true, refinemotion=true, truemotion=true, blksize=16, search=5, pel=2, subpixel=3, mfilter=PREm, prefilter=PREs, chroma=true, plane=4, gpuid=-1, interlaced=false)
ex_unsharp(Stage/40.).ex_unsharp((Stage/20.),Fc=width()/1.5)
F3KDB_3(range=20, Y=32, Cb=24, Cr=24, grainY=24, grainC=16, dither_algo=2)
#
Prefetch(48)
Return(Last)
#
#
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) }


I decided not to use MotionMask as it doesn't work well on scenes with high motion.
And I don't want to chop the film in countless areas to treat differently.
It is not that stable of course and leaves a little wobble but it's a compromise between effort and filtering quality.

[DTL]

Finally build a test release of ResampleMT with added s-param to UserDefined2Resize - https://forum.doom9.org/showthread.php?p=1984621#post1984621

Default s-param is not 2 as was in old processing versions but 2.2f so old scripts will give somehow 'sharper' output (larger amplitude and/or wider 'halo' around transients) or require to set s=2.0 manually. For best possible 'linear' processing in sinc-based workflows s-value of >3.0 is recommended (max is currently limited to 15). Though it can not create as thin 'peaking' as possible with limiting s to about 2. For semi-non-linear the s-value may be tested around from ~1.8..1.9 to ~2.5 (also depends on size reduction ratio significantly).

[Dogway]

Yes. I mainly need a sharpener to remove the blur that appears in the previous steps.
I'm trying to devise a new method to unblur, which is something different than sharpening. You can see an experiment 2 pages back (108 (https://forum.doom9.org/showpost.php?p=1984264&postcount=2148)), although it's not happening soon and it will surely be a stack of filters, not a one liner algorithm.

I don't understand how hdmp works in FineSharpPlus. I take the values I need from FineSharp and use them in FineSharpPlus. And the video becomes blurry compared to FineSharp. Always, no matter what value of hdmp I set.
Please try now. I updated FineSharpPlus, maybe I screwed things up when implementing the non-linearity.


Thanks! Is it possible to replace the number by a variable? I guess not, as this is probably read as a whole string, right?
pre=ex_Median(mode="IQMST",thres=255)
str=0.3
ex_lutxy(pre,Format("x dup y - {str} * -"))

I'll have a look on the code in the afternoon. At a glance I don't know if IQMST works as intended for your case (16mm clip?) since it was meant as a replacement for pref_DeWobble() and you are applying both(?). Will elaborate later.

[Boulder]

What light denoising filters from your pack would you recommend as coupled with MDegrain for areas where motion match fails?

[Lan4]

" down resize (UserDefined2ResizeMT)"
It can be already 'very sharp' if use low enough b and c values. Though to add sharpnes at output it require not very blurry source and large enough downsaize ratio (like 2 and more).
You mean you can do without a sharpener? I think it's not, I've tried different down resize methods. The image is blurry due to the decrease in bitrate and the action of the denoiser.

If your source is very blurry you need sharpeners with larger 'radius'
The source is slightly blurry, generally normal. I need to make amends for my own actions. In other words, return the sharpness that was in the source. It is possible to increase the sharpness a little.

[Dogway]

What light denoising filters from your pack would you recommend as coupled with MDegrain for areas where motion match fails?
A good spatial only filter, NLMeans for anime and ex_MinBlur() for live action ("IQM" is similar but not quite there or as fast). Use sharp=true if you don't want to blur edges, or leave at default false for a kinda motion blur effect.
The source is slightly blurry, generally normal. I need to make amends for my own actions. In other words, return the sharpness that was in the source. It is possible to increase the sharpness a little.
You can also use ex_contrasharpening() for that. If your downscale is big like 1.5 or 2.0 ratio you can leverage the downscaler as a sharpener as DTL mentioned. Depending on source and target dimensions you can use any of the following (https://github.com/Dogway/Avisynth-Scripts/blob/b6695de081072f27ff5edae89d4ea2225db53221/TransformsPack%20-%20Main.avsi#L1954). Simply use as RatioResize(0.5, "%", kernel="ZoptiH")

[DTL]

You mean you can do without a sharpener?

The source is slightly blurry, generally normal. I need to make amends for my own actions. In other words, return the sharpness that was in the source. It is possible to increase the sharpness a little.

It is better to show a sample of input before resize and a required sharpened output.

The SinPow and UserDefined2 (also classic Bicubic) resizers have adjustable 'sharp' effect when downsizing. See 'acutance' effect caused by 'peaking or edges enhancement' description - https://en.wikipedia.org/wiki/Acutance

The SinPow and UserDefined2 designed to have adjustable 'acutance' while downsizing while saving from ringing as much as possible at sinc-based workflows. Bicubic typically can not save from ringing but also can change 'edge enhancement'.

[Lan4]

If your downscale is big like 1.5 or 2.0 ratio you can leverage the downscaler as a sharpener as DTL mentioned. Depending on source and target dimensions you can use any of the following. Simply use as RatioResize(0.5, "%", kernel="ZoptiH")
Honestly, I do not have such knowledge to understand how to use it. But you also want to say that sharpeners are not usually used, and you need to look for other methods of image compensation?

[Dogway]

Honestly, I do not have such knowledge to understand how to use it. But you also want to say that sharpeners are not usually used, and you need to look for other methods of image compensation?
My videos are middle quality (or worse), a lot of phone videos. Before the sharpen filter, I use down resize (UserDefined2ResizeMT) (...)
If you are going to downscale anyway you can sharpen within the resizer kernel, with Bicubic's 'b' and 'c' params, or with the suggestions by DTL. It's better you can upload a sample, an frame shot is also fine at original size and tell what you want to do, so we can help you better with specific filters. So yes, there many ways to do the same thing (sharpening) depending on source and goal.

[Guest]

Is this in the proper order...?

pre=ex_Median(mode="IQMST")
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)

OR

pre=ex_Median(mode="IQMST")
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)

OR not recommended ??

[Dogway]

Is this in the proper order...?
pre=ex_Median(mode="IQMST")
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)
Yes, the first example, I doubt you will do much running it after SMDegrain. And if you are not getting what you want directly from SMDegrain tune the filter settings or modify the prefilter. My stance is to never use spatial filtering for video unless tackling a very specific issue.

By the way, and this is also for LeXXuz, since I'm very expression oriented I used a bad example for modulating IQMST's strength.
You can use the proper filter for that and probably at no extra perf cost.
pre=ex_Median(mode="IQMST",thres=255)
ex_blend(pre,"blend",opacity=0.3)

[LeXXuz]

By the way, and this is also for LeXXuz, since I'm very expression oriented I used a bad example for modulating IQMST's strength.
You can use the proper filter for that and probably at no extra perf cost.
pre=ex_Median(mode="IQMST",thres=255)
ex_blend(pre,"blend",opacity=0.3)

Works a little faster. If the output is nearly the same or even better, I'll take it. :D

Btw. what is the actual order within SMDegrain?

1)
(Gamma/Luma correction with str/amp) -> (Prefilter 0-8) -> (MVTools)
or
2)
(Prefilter 0-8) -> (Gamma/Luma correction with str/amp) -> (MVTools)

[Dogway]

Yes, second. Not long ago I modified it to allow normalization also for external prefilters. Also it reads its frameprops so no problem if they are already in PC levels, only dark enhancement is performed.

[Lan4]

Please try now. I updated FineSharpPlus, maybe I screwed things up when implementing the non-linearity.
The values above approximately HDMP = 0.12 will give strong distortion and a huge file size. It should be?

An increase in "PSTR" should soften sharpness and blur the image, and reduce the size of the file. But the result is opposite, the sharpness and size of the file increases.

Total, it seems to me the FineSharpPlus less changes the original image, optimally increases sharpness, makes noise less, makes less file size. I correctly understand the meaning of FineSharpPlus compared to FineSharp?

[Dogway]

Yes, it's normal. I forgot to remap the values as 0.01 made reference to the non reciprocal value, now it aligns more to LSFplus with a range between 0 and 255 and default of 48. The problem was that LSFplus uses a limiter while here it doesn't. I added a fast one now when HDMP>0. Not sure if I want to turn this into a mini LSFplus though hehe.

Will be uploading in a moment. I'll have a look at PSTR.

EDIT: No, PSTR increases the non-linear exponent, thus making the sharpening more acute. Check the graph here (https://www.desmos.com/calculator/gefrbv9tum).

[madey83]

ConvertBits(16)
crop(4, 4, -4, -4)
SceneStats("Range+Stats")
#
Stage=06#
#
PREl1 = ex_autolevels( true ,true, true,Deflicker=true,tv_out=false)
PREl2 = ex_autolevels(PREl1,false,true,false,Deflicker=true,tv_out=false)
PREmo = ex_Median(mode="IQMST", UV=3,thres=min(100,(Stage*10)))
PREmv = ex_Median(mode="IQMST", UV=3,thres=min(200,(Stage*20)))
PREm = ex_lutxy(PREmo,"x dup y - 0.3 * -").ex_sbr(1,UV=3)
PREv = pref_DeWobble(PREl2).ex_lutxy(PREmv,"x dup y - 0.6 * -").ex_sbr(2,UV=3).Levels(0,1.25,255*256,(((Stage*2)-2)*256),((208-(Stage*8))*256))
#
PREs = SMDegrain(mode="TemporalSoften", tr=6, thSAD=(Stage*70), thSADc=(Stage*60), thSCD1=max(400,(Stage*80)), Str=2.0, contrasharp=false, LFR=false, DCTFlicker=false, refinemotion=false, truemotion=true, blksize=16, search=5, pel=2, subpixel=3, prefilter=PREv, chroma=true, plane=4, gpuid=-1, interlaced=false)
#
SMDegrain(mode="MDegrain", tr=6, thSAD=(Stage*60), thSADc=(Stage*50), thSCD1=max(400,(Stage*70)), Str=2.0, contrasharp=true, LFR=true, DCTFlicker=true, refinemotion=true, truemotion=true, blksize=16, search=5, pel=2, subpixel=3, mfilter=PREm, prefilter=PREs, chroma=true, plane=4, gpuid=-1, interlaced=false)
ex_unsharp(Stage/40.).ex_unsharp((Stage/20.),Fc=width()/1.5)
F3KDB_3(range=20, Y=32, Cb=24, Cr=24, grainY=24, grainC=16, dither_algo=2)
#
Prefetch(48)
Return(Last)
#
#
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) }

.

@LeXXuz,

could it be possible to add some comments to your script - to have same basic understand what each line does - exept SMDegrain ;)?

And to what kind of film grain source it could be used ?

[LeXXuz]

pre=ex_Median(mode="IQMST",thres=255)
str=0.3
ex_lutxy(pre,Format("x dup y - {str} * -"))

I'll have a look on the code in the afternoon. At a glance I don't know if IQMST works as intended for your case (16mm clip?) since it was meant as a replacement for pref_DeWobble() and you are applying both(?). Will elaborate later.

Did you have a chance to look at the script template I provided? :)
https://forum.doom9.org/showthread.php?p=1984619#post1984619

It's not so much about the outcome, but more if my description provided about what the filter chain should do is correct, or I'm still misunderstanding the way filter chains can be interconnected. :o
That would be a big help, so I don't create more crap. :D

And I followed your advice and removed the pref_dewobble() from that chain. Seems to work a little better with not really more wobble than before. :)

Btw:
I noticed an effect on moving objects before textured backgrounds. Here are two screenshots for comparison:
https://abload.de/thumb/originaluscz5.jpg (https://abload.de/image.php?img=originaluscz5.jpg)https://abload.de/thumb/denoised2pcke.jpg (https://abload.de/image.php?img=denoised2pcke.jpg)

Notice the blurred area left of the actor, who is moving from left to right in that scene. Any idea what causes this, and how to reduce it a little? Don't tell me MotionMask pls. :D

I've noticed this in other noisy films before, so not only in this one with the script provided above. What they have/had in common was using 2 stages of SMDegrain. Either directly after another or like in this case with one being the prefilter of the other one. Can't be from the IQMST oder STTWM (pre)filters or the dewobbling/autolevels stuff as I hadn't used them back then.

[LeXXuz]

@LeXXuz,

could it be possible to add some comments to your script - to have same basic understand what each line does - exept SMDegrain ;)?

And to what kind of film grain source it could be used ?

Well, that is not really for general use. It's more of an adaption of some of Dogway's little magic :D we talked about earlier, starting here:
https://forum.doom9.org/showthread.php?p=1982511#post1982511

It's an attempt to stabilze a very noisy and quite unstable SD source I provided samples for to Dogway and here in the forums.

The goal was to reduce an ugly wobbling effect that occured especially strong on that film when trying to denoise with SMDegrain.

[Dogway]

Let me update the script as you would have it now:
SceneStats("Range+Stats")

PREl1 = ex_autolevels( true ,true, true,Deflicker=true,tv_out=false)
PREl2 = ex_autolevels(PREl1,false,true,false,Deflicker=true,tv_out=false)
PREmo = ex_Median(mode="IQMST", UV=3,thres=min(100,(Stage*10)))
PREmv = ex_Median(mode="IQMST", UV=3,thres=min(200,(Stage*20)))
PREm = ex_blend(PREmo,"blend",opacity=0.3).ex_sbr(1,UV=3)
PREv = pref_DeWobble(PREl2).ex_lutxy(PREmv,"x dup y - 0.6 * -").ex_sbr(2,UV=3).Levels(0,1.25,255*256,(((Stage*2)-2)*256),((208-(Stage*8))*256))
#
PREs = SMDegrain(mode="TemporalSoften", tr=6, thSAD=(Stage*70), thSADc=(Stage*60), thSCD1=max(400,(Stage*80)), Str=2.0, contrasharp=false, LFR=false, DCTFlicker=false, refinemotion=false, truemotion=true, blksize=16, search=5, pel=2, subpixel=3, prefilter=PREv, chroma=true, plane=4, gpuid=-1, interlaced=false)
#

SMDegrain(mode="MDegrain", tr=6, thSAD=(Stage*60), thSADc=(Stage*50), thSCD1=max(400,(Stage*70)), Str=2.0, contrasharp=true, LFR=true, DCTFlicker=true, refinemotion=true, truemotion=true, blksize=16, search=5, pel=2, subpixel=3, mfilter=PREm, prefilter=PREs, chroma=true, plane=4, gpuid=-1, interlaced=false)

ex_unsharp(Stage/40.).ex_unsharp((Stage/20.),Fc=width()/1.5)
F3KDB_3(range=20, Y=32, Cb=24, Cr=24, grainY=24, grainC=16, dither_algo=2)

Since IQMST was supposed to replace pre_DeWobble() it should read the autoleveled clip. Also you use search=5 which I don't know if it improves something on your end.
SceneStats("Range+Stats")
PREl1 = ex_autolevels( true ,true, true,Deflicker=true,tv_out=false)
PREl2 = ex_autolevels(PREl1,false,true,false,Deflicker=true,tv_out=false)
PREmo = ex_Median(PREl2,mode="IQMST", UV=3,thres=min(100,(Stage*10)))
PREm = ex_blend(PREl2,PREmo,"blend",opacity=0.3).ex_sbr(1,UV=3)
#
PREs = SMDegrain(mode="TemporalSoften", tr=6, thSAD=(Stage*70), thSADc=(Stage*60), thSCD1=max(400,(Stage*80)), Str=2.0, contrasharp=false, LFR=false, DCTFlicker=false, refinemotion=false, truemotion=true, blksize=16, search=5, pel=2, subpixel=3, prefilter=PREmo, chroma=true, plane=4, gpuid=-1, interlaced=false)
#

SMDegrain(mode="MDegrain", tr=6, thSAD=(Stage*60), thSADc=(Stage*50), thSCD1=max(400,(Stage*70)), Str=2.0, contrasharp=true, LFR=true, DCTFlicker=true, refinemotion=true, truemotion=true, blksize=16, search=5, pel=2, subpixel=3, mfilter=PREm, prefilter=PREs, chroma=true, plane=4, gpuid=-1, interlaced=false)

ex_unsharp(Stage/40.).ex_unsharp((Stage/20.),Fc=width()/1.5)
F3KDB_3(range=20, Y=32, Cb=24, Cr=24, grainY=24, grainC=16, dither_algo=2)


The MotionMask trick was for the 16mm source that was shaking or motion flickering like hell, and was very unstable on what was supposed to be static areas. The MotionMask helped to use a very strong TemporalSoften SMDegrain for backgrounds, and a refined MV for moving objects. I don't think you need it in most cases.

Referring to your sample image I don't see a reason to use TemporalSoften prefilter? This is only for very specific corrupted sources, not really for generalized use. So what you see is motion occluded areas like the wall texture, same side effects than when using RIFE an motion interpolation filters. You can also reduce 'tr' to alleviate the effect.

Also I would encourage you to fine tune the LFR arg instead of relying on default since you already know what you are doing but only for sources that don't wobble, or if passing through the MotionMask.

[LeXXuz]

Thanks for the code update and explanation. Will try out those changes you suggested. Much appreciated, as always. :) :thanks:

[Lan4]

EDIT: No, PSTR increases the non-linear exponent, thus making the sharpening more acute. Check the graph here (https://www.desmos.com/calculator/gefrbv9tum).
Obviously, in FineSharp (HBD mod), the PSTR option makes soft edges on hard objects, like text on walls. Otherwise, when the strength of sharp is increased, the edges of such text look like "cracked ice".

LSTR also softens the image, but in a different way.

[Guest]

Yes, the first example, I doubt you will do much running it after SMDegrain. And if you are not getting what you want directly from SMDegrain tune the filter settings or modify the prefilter. My stance is to never use spatial filtering for video unless tackling a very specific issue.

By the way, and this is also for LeXXuz, since I'm very expression oriented I used a bad example for modulating IQMST's strength.
You can use the proper filter for that and probably at no extra perf cost.
pre=ex_Median(mode="IQMST",thres=255)
ex_blend(pre,"blend",opacity=0.3)

Thanks for that.

Tried that call you attached, and I'm getting an error:-

There is no function named 'ex_blend'.....

But then I figured out that I needed to add your Grade Pack :)

Some might say that this post is somewhat pointless, but it might help someone....

[LeXXuz]

Dogway I get an error message within ex_autolevels() when using this on an old HD animation film.
I noticed strange artefacts in scene fades and camera pans and after several hours of searching I finally found the reason: :D
https://abload.de/thumb/ex_autolevels_error_1geef6.jpg (https://abload.de/image.php?img=ex_autolevels_error_1geef6.jpg)

It's an overlay error message in the prefiltering clip from ex_autolevels.

Both packs are up to date and this message does NOT appear on my SD sources I encoded so far. Thank god. :D

First I thought it's the HD resolution. So I resized it down to 720x540 from 1440x1080. But it stays the same.
Also added frameprops before calling SMDegrain, just to be sure. But no effect either.

used custom prefilter is what we already spoke about:


PREl1 = ex_autolevels( true ,true, true,Deflicker=true,tv_out=false)
PREl2 = ex_autolevels(PREl1,false,true,false,Deflicker=true,tv_out=false)
PREmv = ex_Median(PREl2,mode="IQMST", UV=3,thres=min(255,(Stage*50)))
PREv = ex_blend(PREl2,PREmv,"blend",opacity=(Stage/10.)).ex_sbr(3,UV=3)


Don't really know what else to do here and why it causes a syntax error in ArrayOps. :o
Could you maybe take a look into this? :)

[madey83]

@Dogway,

below code i use as prefiler as you proposed and it is better (picture looks just better) and it's process quicker than ex_BM3D
pre=ex_Median(mode="IQMST",thres=155)
ex_blend(pre,"blend",opacity=0.3).ex_sbr(1,UV=3)

thank you :)

[Dogway]

@LeXXuz: Yes I also had some issues (Error with 'Inf') on a clip I was working on, but used another script and forgot to keep the source for investigation. One of the things I wanted to do is to check with the previous AVS+ test versions like 7 or 6 to know if it's a bug related to the recent refactor on frameprops or not. Your issue seems a little different so most likely there's some issue on the function that I need to address, if you can share a small clip which shows the issue I can have a look, but first since it's an animation try with anime=true in case it's not an intraframe only clip. About the memory leaks do you still get them? And the clip you shared, can you post the script that was used?

By the way, this week I've been spending time with ChatGPT to resolve long standing research questions of different projects and topics. It's the free version so you need some time and question massaging to get it to some point, and you need to revise the answers but it's helping me. Probably will pay a 1 or 2 months suscriptions later on when they update ChatGPT 4/5 to 2023 dataset. The bot doesn't understand AviSynth by they way.

In any case it helped me to understand a few things and ported myself a checkerboard dedither kernel from RA's slang shaders:
function ex_dedither(clip a, float "blend", int "UV") {

rgb = isRGB(a)
isy = isy(a)
bi = BitsPerComponent(a)
fs = propNumElements (a,"_ColorRange") > 0 ? \
propGetInt (a,"_ColorRange") == 0 : rgb

bl = Default(blend, 1.0 )
UV = Default(UV, rgb ? 3 : 128)
un = Undefined()
si = fs ? "allf" : "all"

str = Format("f32 x[-1,-1] UL^ x[-1,0] U^ x[1,-1] UR^
x[-1,0] L^ x[0,0] C^ x[0,1] R^
x[-1,1] DL^ x[1,0] D^ x[1,1] DR^

L R max LRM@ C max L R min LRN@ C min -
1 {bl} - * DIFF@

1 + 0.5 * C * 1 DIFF - 0.125 * L R U D + + + * +

LRM C min U D max C min max
LRN C max U D min C max min clip")

isy ? Expr(a, str , scale_inputs=si) : \
UV == 1 ? Expr(a, str, "" , scale_inputs=si) : \
Expr(a, str, ex_UVexpr(str, UV, bi, rgb, un), scale_inputs=si) }

I hope to keep investigating and implement a decrawl algo which was one of my original quests in 2021.

[LeXXuz]

@LeXXuz: Yes I also had some issues (Error with 'Inf') on a clip I was working on, but used another script and forgot to keep the source for investigation. One of the things I wanted to do is to check with the previous AVS+ test versions like 7 or 6 to know if it's a bug related to the recent refactor on frameprops or not. Your issue seems a little different so most likely there's some issue on the function that I need to address, if you can share a small clip which shows the issue I can have a look, but first since it's an animation try with anime=true in case it's not an intraframe only clip. About the memory leaks do you still get them? And the clip you shared, can you post the script that was used?


Our postings collided. So I better put my last edit in here as a general reply.


EDIT: In addition, there also seems to be an error occuring along fades with consecutive faults causing artefacts and disturbances and ending in an error overlay message until the next scene change.
Video:
https://send.cm/d/MOUt

Screenshots of prefilter clip:
https://abload.de/thumb/01qhexf.png (https://abload.de/image.php?img=01qhexf.png) https://abload.de/thumb/02lpdnr.png (https://abload.de/image.php?img=02lpdnr.png) https://abload.de/thumb/03wbf1h.png (https://abload.de/image.php?img=03wbf1h.png) https://abload.de/thumb/04j1ftb.png (https://abload.de/image.php?img=04j1ftb.png) https://abload.de/thumb/05ebezf.png (https://abload.de/image.php?img=05ebezf.png) https://abload.de/thumb/06rtirw.png (https://abload.de/image.php?img=06rtirw.png) https://abload.de/thumb/079hch5.png (https://abload.de/image.php?img=079hch5.png) https://abload.de/thumb/08u2eyg.png (https://abload.de/image.php?img=08u2eyg.png) https://abload.de/thumb/09lue4m.png (https://abload.de/image.php?img=09lue4m.png) https://abload.de/thumb/10aodo7.png (https://abload.de/image.php?img=10aodo7.png)

Of course I can send you some original clips of the source HD anime and this scene of the old film we started the wobble discussion with some weeks ago.

Script for that HD anime was:
LoadPlugin("C:\Video Editing\MeGUI (x64)\tools\ffms\ffms2.dll")
FFVideoSource("G:\WORK\test.mkv", fpsnum=24, fpsden=1, threads=1)
crop(220, 0, -220, 0)
#
ConvertBits(16)
SceneStats("Range+Stats")
#
Stage=08
PREl1 = ex_autolevels( true ,true, true,Deflicker=true,tv_out=false)
PREl2 = ex_autolevels(PREl1,false,true,false,Deflicker=true,tv_out=false)
PREmv = ex_Median(PREl2,mode="IQMST", UV=3,thres=min(255,(Stage*50)))
PREv = ex_blend(PREl2,PREmv,"blend",opacity=(Stage/10.))#.ex_sbr(3,UV=3)
#
SMDegrain(show=true,mode="MDegrain", tr=12, thSAD=(Stage*80), thSADc=(Stage*60), thSCD1=max(400,(Stage*90)), Str=2.0, contrasharp=true, LFR=false, DCTFlicker=false, refinemotion=true, truemotion=false, blksize=24, search=5, pel=2, subpixel=3, prefilter=PREmv, chroma=true, plane=4, gpuid=-1, interlaced=false)
ex_unsharp(Stage/50.)
F3KDB_3(range=20, Y=32, Cb=24, Cr=24, grainY=24, grainC=16, random_algo_ref=2, random_algo_grain=2, output_depth=16, sample_mode=2)
#
Prefetch(32)
Return(Last)


And script for the SD film:

SetMemoryMax(48*1024)
SetCacheMode(0)
#
LoadPlugin("C:\Video Editing\MeGUI (x64)\tools\ffms\ffms2.dll")
FFVideoSource("H:\WORK\test.mkv", fpsnum=25, fpsden=1, threads=1)
#
AssumeFPS(25)
CTelecine()
CPostProcessing()
propSet("_FieldBased",0)
crop(0, 4, -8, -4)
ConvertBits(16)
Levels(2*256,0.9,255*256,0,225*256).Tweak(sat=0.95)
SceneStats("Range+Stats")
#
Stage=07
#
PREl1 = ex_autolevels( true ,true, true,Deflicker=true,tv_out=false)
PREl2 = ex_autolevels(PREl1,false,true,false,Deflicker=true,tv_out=false)
PREmo = ex_Median( mode="IQMST", UV=3,thres=min(255,(Stage*25)))
PREmv = ex_Median(PREl2,mode="IQMST", UV=3,thres=min(255,(Stage*50)))
PREm = ex_blend(PREmo,"blend",opacity=(Stage/20.)).ex_sbr(2,UV=3)
PREv = ex_blend(PREl2,PREmv,"blend",opacity=(Stage/10.)).ex_sbr(3,UV=3)
#
SMDegrain(show=true,mode="MDegrain", tr=12, thSAD=(Stage*50), thSADc=(Stage*40), thSCD1=max(400,(Stage*60)), Str=2.0, contrasharp=true, LFR=true, DCTFlicker=true, refinemotion=true, truemotion=true, blksize=16, search=5, pel=4, subpixel=3, mfilter=PREm, prefilter=PREv, chroma=true, plane=4, gpuid=-1, interlaced=false)
ex_unsharp(Stage/40.).ex_unsharp((Stage/20.),Fc=width()/1.5)
F3KDB_3(range=10, Y=32, Cb=24, Cr=24, grainY=24, grainC=16, random_algo_ref=2, random_algo_grain=2, output_depth=16, sample_mode=2)
#
Prefetch(32)
Return(Last)



I have not run into memory problems yet. But they occured mostly with BM3D involved. And, like madey83 already mentioned,
I also replaced BM3D completely by IQMST or STTWM as both produce superior results with less CPU load than BM3D.

Even run in CUDA mode, the final CPU based aggregation needed more CPU time than the new filters. So I see no reason to keep using BM3D at the moment.

EDIT2:
Source scene of SD film: https://send.cm/d/MOix
Source scene of HD anime: https://send.cm/d/MOkL

I'm using pinterf's AVS+ 3.7.3 test9 at the moment.

[Dogway]

You need to send me again the SD film source because the DDL is capped.

Talking about the animation film, I didn't get any error (although I use different prefetch values) nor I saw any luma flicker, so you don't need the autolevels, specially with Deflicker. You can use autolevels though if you want to normalize the clip, but that's going to change the SAD value on a per-scene basis. So they go out.
By the way as I mentioned SceneStats should be SceneStats("Range+Stats", anime=true) in this case, but we don't need it anymore due to lack of flicker.

Another thing is IQMST, looks a bit overkill for this source, this is more like medium grain, and being 2D animation probably NLMeans should be best suited. NLMeans has temporal unlike DGDenoise so it will prefilter a bit more I think.
SMDegrain(mode="MDegrain", tr=3, thSAD=(Stage*80), Str=2.0, contrasharp=true, refinemotion=true, prefilter=6, chroma=true, plane=4)

If you want to stabilize the background you can run a stronger SMDegrain and then merge them with the MotionMask workaround I posted in previous pages. I mean, IQMST is not perfect so it's only suited for very damaged live action sources. I tried to add limiting like the next example:
pre=ex_Median(mode="IQMST", UV=3, thres=15)
pre=ex_blend(pre,"blend",opacity=0.5).ex_sbr(2,UV=3)

SMDegrain(mode="TemporalGauss", tr=6, thSAD=640, Str=2.0, contrasharp=true, refinemotion=true, prefilter=pre, chroma=true, plane=4)
and alternative
pre=ex_Median(mode="IQMST", UV=3,thres=15)
pre=ex_blend(pre,"blend",opacity=0.5).ex_median("IQMV").ex_sbr(1,UV=3)

SMDegrain(mode="TemporalSoften", tr=5, thSAD=640, Str=2.0, contrasharp=true, refinemotion=true, prefilter=pre, chroma=true, plane=4)
But even so when framestepping you will notice of some line warping before a head movement or so, and that's even using thres=15 and halving the IQMST effect. Yes you can use repair to fix the line warping passing it through a mix of motion and edge masks, but you see things get that complicated.

Passed DigitalFilmV5 over it to see how far I could take it:

http://i.imgur.com/RuSHIFdm.png (https://i.imgur.com/RuSHIFd.png) http://i.imgur.com/4H2t5mXm.png (https://i.imgur.com/4H2t5mX.png)

[LeXXuz]

You need to send me again the SD film source because the DDL is capped.

Odd. Just tested the DL. Still working. If it still doesn't work for you I will send you a new version via PM.


Talking about the animation film, I didn't get any error (although I use different prefetch values) nor I saw any luma flicker, so you don't need the autolevels, specially with Deflicker. You can use autolevels though if you want to normalize the clip, but that's going to change the SAD value on a per-scene basis. So they go out.
By the way as I mentioned SceneStats should be SceneStats("Range+Stats", anime=true) in this case, but we don't need it anymore due to lack of flicker.


There are other scenes showing a little flicker and more sticky kind of noise, that's why I put autolevels in, just to play it safe. I haven't run another test yet with anime=true. But I can give that another try to see what happens.

I need that high prefetch to fill up my CPUs mostly. Running two encodes with a lower prefetch adds too much overhead and the overall framerate is lower.


Another thing is IQMST, looks a bit overkill for this source, this is more like medium grain, and being 2D animation probably NLMeans should be best suited. NLMeans has temporal unlike DGDenoise so it will prefilter a bit more I think.
SMDegrain(mode="MDegrain", tr=3, thSAD=(Stage*80), Str=2.0, contrasharp=true, refinemotion=true, prefilter=6, chroma=true, plane=4)


Well what I usually do is, I set up my SMDegrain template with stage=1 and then add greyscale() or a color tint to mfilter. Then I take a preview of the denoised output and rank up the stage until there are only little grey/tinted areas around moving objects while the stills/background show no colour changes. Then I consider that source as cleaned. As there is only little content left where MVtools didn't find a suitable match.
It may be just "quick and dirty" or even false to do so, but I must say it served me quite well so far over many many tests. At least far better than setting up SMDegrain by looking for faint residual noise on my office monitor which I can hardly see with me old eyes and getting a big surprise later on in my living room when watching on my OLED TV which is very picky regarding noise. :D

So, I usually add one "Stage"-step for safety. And so I ended up with Stage=7 (~ 7*80=560 thSAD) for that anime with that prefilter setup. Like I said before, there are other scenes that look much more noisy with other grain, especially night shots.


If you want to stabilize the background you can run a stronger SMDegrain and then merge them with the MotionMask workaround I posted in previous pages. I mean, IQMST is not perfect so it's only suited for very damaged live action sources. I tried to add limiting like the next example:
[CODE]pre=ex_Median(mode="IQMST", UV=3, thres=15)
pre=ex_blend(pre,"blend",opacity=0.5).ex_sbr(2,UV=3)

Maybe I still get this limiting threshold wrong? I thought reducing it from the default 255 means less pixels or pixel differences get into consideration for processing? Or is that false? Then how would you best describe what this threshold actually does?


But even so when framestepping you will notice of some line warping before a head movement or so, and that's even using thres=15 and halving the IQMST effect. Yes you can use repair to fix the line warping passing it through a mix of motion and edge masks, but you see things get that complicated.

I think you're right that's getting too complex and maybe will cause problems in other scenes, especially with MotionMask. And I don't want to end up with clip chopping and dozens of different settings. That'd be way too much effort.

It's a compromise and I was quite happy with the results, besides those overlay error messages of course, which surely must have a reason for appearing?

I may not need autolevels on that anime, but I really need it on that SD film or the wobble is killing me. But I have no idea what that overlay message I showed in the screeshots above is trying to tell me...

[Dogway]

Now I could download after the server wait time.

Deflicker is not something you can apply lightly or blindly. There's a lot going on, from SceneStats which is fine but causes a lot of non linear frame access, to ex_autolevels which requires the flicker to be of higher frequency than the content. I updated recently the ScenesPack to reflect this aspect after finding an anime source that had a smooth flicker of maybe 1 or 2 seconds, it didn't work.
A fade in or fade out is the same, a smooth flicker-like behavior. If you need to deflicker a high freq luma flicker over some part it's better to apply trims or simply ClipClop.

The examples above for Lucky Luke are the first for retaining a film vibe, and the second with the stronger TemporalSoften for a more original cel look. The NN model runs slow on my machine, like 0.05fps or so, but my card is old.

Well what I usually do is, I set up my SMDegrain template with stage=1 and then add greyscale() or a color tint to mfilter
Yes that's a great trick, I have used it myself before, but nowadays I'm too lazy. I simply raise thSAD until I like it, then add mfilter if deemed necessary.

For the 'thres' in ex_median() play with it visually. You can see that below 30 it starts to recover some edges and the lower you go more details are recovered until you start to recover noise also. Basically it reads as "Only allow changes below a difference of 'thres'", or "Block all changes above a diff of 'thres'".

You can get funny with the masks, it's entertaining when you get the grasp of it. I simply mean that you can go as entropic as you want, didn't want to confuse you further.

For example:
em = ex_edge().extracty()
mm = motionmask()
msk = ex_logic(em,mm).ex_expand().ex_deflate().ex_deflate()

rp = src.ex_smooth(2,sharp=true)
pre = ex_merge(rp,msk)

As for the SD clip, you need to take out the fades. This is how you do it with ClipClop:
r0=SMPTE_legal(false) # to PC levels

r1 = ex_autolevels( true ,true, true,Deflicker=true,tv_out=false)
PREl1 = ClipClop(r0,r1,sCmd="r1(0,45); r0(46,66); r1(67,165)")
r2 = ex_autolevels(PREl1,false,true,false,Deflicker=true,tv_out=false)
PREl2 = ClipClop(r0,r2,sCmd="r1(0,45); r0(46,66); r1(67,165)")

Maybe you can get away with the second ClipClop only. I know there's a way to put any var name into ClipClop, but the docs are hard to grasp so conformed to r#

[madey83]

@Dogway,

you mentioned to LeXXuz that IQMST is to strong, is there any option to reduce its strength, some additional paramiter or something like that?

pre=ex_Median(mode="IQMST",thres=155)
ex_blend(pre,"blend",opacity=0.3).ex_sbr(1,UV=3)

[LeXXuz]

@Dogway,

you mentioned to LeXXuz that IQMST is to strong, is there any option to reduce its strength, some additional paramiter or something like that?

pre=ex_Median(mode="IQMST",thres=155)
ex_blend(pre,"blend",opacity=0.3).ex_sbr(1,UV=3)

ex_Median does not have a strength option in general. That is why you blend it with the original clip via ex_blend. You can modify the strength this way with the opacity setting. You already use only 30% of the filter strength in that example.

What Dogway meant was that IQMST as prefilter may be too strong for the sample I provided and suggested a different approach for that.

In general IQMST is very strong but still beats BM3D with a sigma of 10 or more in my opinion. But that's just my personal taste.

[madey83]

ex_Median does not have a strength option in general. That is why you blend it with the original clip via ex_blend. You can modify the strength this way with the opacity setting. You already use only 30% of the filter strength in that example.

What Dogway meant was that IQMST as prefilter may be too strong for the sample I provided and suggested a different approach for that.

In general IQMST is very strong but still beats BM3D with a sigma of 10 or more in my opinion. But that's just my personal taste.

hi,

so if i understood you correctly to reduce strength of IQMST i can change value for " opacity " from 0.3 to 0.1 as an example?

[LeXXuz]

A fade in or fade out is the same, a smooth flicker-like behavior. If you need to deflicker a high freq luma flicker over some part it's better to apply trims or simply ClipClop.
...
As for the SD clip, you need to take out the fades. This is how you do it with ClipClop:
r0=SMPTE_legal(false) # to PC levels

r1 = ex_autolevels( true ,true, true,Deflicker=true,tv_out=false)
PREl1 = ClipClop(r0,r1,sCmd="r1(0,45); r0(46,66); r1(67,165)")
r2 = ex_autolevels(PREl1,false,true,false,Deflicker=true,tv_out=false)
PREl2 = ClipClop(r0,r2,sCmd="r1(0,45); r0(46,66); r1(67,165)")

Maybe you can get away with the second ClipClop only. I know there's a way to put any var name into ClipClop, but the docs are hard to grasp so conformed to r#

Thanks again about that deflicker explanation. I was afraid you might say that and I have to invest a little more time to handle fades.

But if I want to be lazy on some less important encodes it would be a help if you could disable those overlay error messages, or give an option to do so.
That way those fades would look a little better, because those artefacts won't appear from the overlay messages leaving just that kind of posterization from ex_autolevels.

Or are these messages happening on Avisynth level and I have to ask pinterf to add an option to disable these? If there already isn't one, of course.


Yes that's a great trick, I have used it myself before, but nowadays I'm too lazy. I simply raise thSAD until I like it, then add mfilter if deemed necessary.

I'm relieved that I was on the right track with this for once. :D I really have trouble in judging my scripts by watching for residual noise. This way its much easier for me to see.


For the 'thres' in ex_median() play with it visually. You can see that below 30 it starts to recover some edges and the lower you go more details are recovered until you start to recover noise also. Basically it reads as "Only allow changes below a difference of 'thres'", or "Block all changes above a diff of 'thres'".

I did. And I think I know what you meant by now. And that my old thresholds were too high and merely for the trash can. :rolleyes:


You can get funny with the masks, it's entertaining when you get the grasp of it. I simply mean that you can go as entropic as you want, didn't want to confuse you further.

For example:
em = ex_edge().extracty()
mm = motionmask()
msk = ex_logic(em,mm).ex_expand().ex_deflate().ex_deflate()

rp = src.ex_smooth(2,sharp=true)
pre = ex_merge(rp,msk)

I know. :D I already played around with it since the first time you provided me that sample with MotionMask().
But I think this leaves the area of simple denoising and enters the field of scene or even frame-based restoration as you have to treat scenes differently depending on their motion content.
And I don't have the time for that. Sadly.

[LeXXuz]

hi,

so if i understood you correctly to reduce strength of IQMST i can change value for " opacity " from 0.3 to 0.1 as an example?

Yes, you can adjust the "strength" by adjusting the opacity of the blend somewhere between 0 (no denoise filter effect) and 1.0 (full denoise filter effect)

But if you have just some fine grain better use something different like STTWM. Dogway provided examples for that some posts above and they can also be found in his ExTools package ~line 2194. :)

[madey83]

Yes, you can adjust the "strength" by adjusting the opacity of the blend somewhere between 0 (no denoise filter effect) and 1.0 (full denoise filter effect)

But if you have just some fine grain better use something different like STTWM. Dogway provided examples for that some posts above and they can also be found in his ExTools package ~line 2194. :)

thank you :) for sure i will try it as well.

[Boulder]

Is there a fundamental difference (in HBD) between using ex_blend and ex_limitchange to limit the amount of change in the result? I suppose the granularity is better with the former?

[Dogway]

Is there a fundamental difference (in HBD) between using ex_blend and ex_limitchange to limit the amount of change in the result? I suppose the granularity is better with the former?
ex_blend(mode="blend") just mixes the two clips (similar or different), it works as an opacity layer with the top layer blended with the bottom one at 'opacity' ratio.

ex_limitchange() is different, you need to provide a clip and a filtered version of it, then based on the diff (limit and bias args) you merge those differences to the original clip. It's like ex_merge(orig,filt,msk) but with the mask embedded. ex_limitdif() probably is more useful as you can control the threshold and elasticity for a non-linear merge.

[Boulder]

ex_blend(mode="blend") just mixes the two clips (similar or different), it works as an opacity layer with the top layer blended with the bottom one at 'opacity' ratio.

ex_limitchange() is different, you need to provide a clip and a filtered version of it, then based on the diff (limit and bias args) you merge those differences to the original clip. It's like ex_merge(orig,filt,msk) but with the mask embedded. ex_limitdif() probably is more useful as you can control the threshold and elasticity for a non-linear merge.

My use case is for applying the proposed spatial filter like ex_minblur() to the clip fed to MDegrain, but often the blurring becomes a bit too visible in flat background areas as I tend to like a bit grainier image. I don't know why MDegrain is not applied there since they should be low SAD areas but maybe there's just some weighing involved.

[LeXXuz]

Hmm... I can't get KNLMeansCL to work properly on Win11 with 3.7.3+test9 on a RTX30 card unless I set it to minimal settings. 1080p source.

Which means (a=1, s=def, d=0, wmode=0, chroma=false) and even then it eats up 97% of my 8GB VRAM.
With the settings in SMDegrain as prefilter-6 it won't even start.

Is there a recommended version to use?
The latest I could find is pinterf's version of Nov 2020:
https://github.com/pinterf/KNLMeansCL/releases/tag/v1.1.1e

[Dogway]

My use case is for applying the proposed spatial filter like ex_minblur() to the clip fed to MDegrain, but often the blurring becomes a bit too visible in flat background areas as I tend to like a bit grainier image. I don't know why MDegrain is not applied there since they should be low SAD areas but maybe there's just some weighing involved.

I also noticed that on the Lucky Luke sample, even if I apply a strong median prefilter like IQMV. This is probably because of grain/noise temporal convergence, the solution is to increase 'tr' and/or use stronger modes like 'TemporalSoften'. I certainly don't like spatial filters applied directly because they destroy texture detail, but you can apply ex_minblur(sharp=true) and pass it through ex_limitdif() and see how it looks, specially by tuning its args. Another option is pass it through FlatMask masking in case it's 2D animation.

@LeXXuz: What are the source details? I'm not having any issues, might it be driver related? Also pure GPU scripts don't like prefetch(>1). That one is the latest version. Debug a little and I will have it a look, alongside SceneStats during this weekend.

[LeXXuz]

@LeXXuz: What are the source details? I'm not having any issues, might it be driver related? Also pure GPU scripts don't like prefetch(>1). That one is the latest version. Debug a little and I will have it a look, alongside SceneStats during this weekend.

The source was that HD anime clip. I have latest Nvidia Studio drivers installed.

Uhm... now that you mention it, it may be a good time to check my mtmodes.avsi again. Haven't done that in quite a while. :D
ex_DGDenoise() works just fine, but is not my first choice obviously.

Thanks for taking a look into SceneStats. :)

[madey83]

The source was that HD anime clip. I have latest Nvidia Studio drivers installed.

Uhm... now that you mention it, it may be a good time to check my mtmodes.avsi again. Haven't done that in quite a while. :D
ex_DGDenoise() works just fine, but is not my first choice obviously.

Thanks for taking a look into SceneStats. :)


Lucky Luke, hmm, nice cartoon of my youth :).

I would be nice to have it in this quality...

Where i can find it?

[LeXXuz]

Probably on Amazon :D
That's where I bought my Blu-ray collection with 4 films of Lucky Luke. ;)

[Guest]

I have a bit of a project...

I have an interlaced anime @ 23.976, and using BWDIF to de-interlace brings it up to 59.94, but then it needs to go double again to 119.88.

Would Frameconverter do that, if it was de-interlaced first ??

Some script suggestions would be greatly appreciated.

[LeXXuz]

@LeXXuz: What are the source details? I'm not having any Also pure GPU scripts don't like prefetch(>1).

It is the prefetch. Although MT mode is set to 3 for KNLmeansCL and cache mode to 0.
Then how do you run SMD with that prefilter at a decent speed:confused:

EDIT: Well I can get it to run @ Prefetch(16). Then 7.8/8.0Gb of that GPU's VRAM is used.
And only because it's 1440x1080. For the full HD resolution I have to go even lower. :rolleyes:

Damn I hate Nvidia for being so cheap about VRAM for their GPUs. :mad:
Would prefer ATI... pardon me... AMD :D anyway.
But can't run any CUDA filters then obviously :(

[Guest]

It is the prefetch. Although MT mode is set to 3 for KNLmeansCL and cache mode to 0.
Then how do you run SMD with that prefilter at a decent speed:confused:

EDIT: Well I can get it to run @ Prefetch(16). Then 7.8/8.0Gb of that GPU's VRAM is used.
And only because it's 1440x1080. For the full HD resolution I have to go even lower. :rolleyes:

Damn I hate Nvidia for being so cheap about VRAM for their GPUs. :mad:
Would prefer ATI... pardon me... AMD :D anyway.
But can't run any CUDA filters then obviously :(

I always thought that AMD GPU's were better for KNLMeansCL...

[LeXXuz]

Well, just for fun and giggles I started that script on my Ryzen 7950x machine and selected the internal GPU as renderer.
And it runs, even with Prefetch(32) :D

The internal GPU takes ~10.5GB of systems DDR5 memory for that job. Of course it was not meant to run compute jobs and it runs only at ~1.5FPS, but it runs at least. :D
Take that Nvidia! :p

https://abload.de/img/radeoncqdck.png (https://abload.de/image.php?img=radeoncqdck.png)

[Guest]

Well, just for fun and giggles I started that script on my Ryzen 7950x machine and selected the internal GPU as renderer.
And it runs, even with Prefetch(32) :D

The internal GPU takes ~10.5GB of systems DDR5 memory for that job. Of course it was not meant to run compute jobs and it runs only at ~1.5FPS, but it runs at least. :D
Take that Nvidia! :p


Yep, the iGPU's of the Ryzens are pretty piss- weak alright, only 1 compute unit I believe :(

[DTL]

Well, just for fun and giggles I started that script on my Ryzen 7950x machine and selected the internal GPU as renderer.
And it runs, even with Prefetch(32) :D

The internal GPU takes ~10.5GB of systems DDR5 memory for that job. Of course it was not meant to run compute jobs and it runs only at ~1.5FPS, but it runs at least. :D
Take that Nvidia! :p



If the task is memory-limited - the very cheap 128bit bus width datacompute accelerator (endusers 'video card' today) will easily outperform integrated GPU with very slow typically 2-channels DDR5 RAM of the very old and very slow x86(64) intel-architecture. Its peak memory transfer typically below 100 GB/s. And if we take medium segment 'videocard' with RAM >200..300 GB/s it will be even better visible. The top PC DCAs like Tesla A100 have already about 2000 GB/s memory performance in a single full-sized PCIe x16 card of 2slots size - thanks to new HBM RAM.

So it may be only some benefit if run very compute-extensive task into large register file and cache of integrated GPU in CPU.

[LeXXuz]

Of course the iGPU is very weak and extremely limited in bandwith. It was just to proof it is working, nothing more. ;)

The iGPU is meant to be used for desktop work and maybe watch some media. But certainly not for computational purposes or gaming.

Or, as in my case, if you just need the CPU, spares you to buy a dedicated graphics card. :)

[LeXXuz]

Sorry, me again Dogway. :o

Should these two be identical in output?

PRE=ex_Median(mode="IQMST", UV=3,thres=255)

PRE0=ex_Median(mode="IQMST", UV=3,thres=255)
PRE=ex_blend(PRE0,"blend",opacity=1)

Since opacity is clamped between 0,1 in ex_blend
-output with opacity=0 seems identical with the last clip, as it should.
-output with opacity=1 seems not identical with the blend clip, which I would've expected.

Also I noticed some flickering in the output when opacity is used with anything but 0.
Quite subtle but noticeable in some backgrounds when you're very susceptible to flicker. Could these be rounding errors from the blending process by any chance?

I'm not so sure atm if this is a good way to control that prefilter's strength. Same seems to be the case with ex_lutxy().

[Dogway]

Sorry, I felt very sick today so probably will get things going at a slower pace from now on.
Yesterday I managed to streamline ex_KNLMeansCL() as KNLMeansCL expects a simple YUV444 source, so yes it's slower, but tell me back if it fixes the memory leak issues.
I don't think the previous version was at fault either, just the way KNLM handles memory.

function ex_KNLMeansCL (clip c, float "h", int "d", int "a", int "s", int "wmode", clip "rclip", float "LFR", bool "DCT", bool "chroma", int "gpuid", float "wref", string "knlm_params") {

h = Default( h, 7.0) # Sigma
d = Default( d, 0) # Temporal radius
a = Default( a, 1) # Spatial radius
s = min(Default( s, a*2),8) # Spatial radius of the similarity neighborhood
wmode = Default( wmode, 0)
wref = Default( wref, 1.0)
gpuid = Default( gpuid, 0) # Set to -1 for "cpu" mode (currently -2022- not implemented)
chroma = Default( chroma, true)
LFR = Default( LFR, wmode < 1 || d > 0 ? min(2,d+1)*300*(c.width()/1920.) : 0) # Restore low frequency details, specially on wmode=0, and more specially with d > 0 (motion estimation is very bad in KNLMeansCL). Set to 0 to disable.
DCT = Default( DCT, true)
knlm_params = Defined( knlm_params) ? ","+knlm_params : ""
device_type = gpuid < 0 ? "cpu" : "auto"

pID = color_propGet(c)
mat = pID[2]+(pID[6]?":l":":f")

isy = c.isy()
rgb = c.isrgb()
is44 = c.is444()

UV = rgb ? "auto" : isy || !chroma ? "Y" : "YUV"
dwclip = Defined( rclip )
wclip = dwclip ? rclip : Undefined()

c
isy ? last : \
rgb ? ConvertToPlanarRGB() : \
!is44 ? ConvertToYUV444(matrix=mat,chromaresample=!chroma?"point":"bicubic",param1=0,param2=0.5) : last
al = last

Eval("KNLMeansCL(D=d, A=a, h=h, s=s, device_type=device_type, device_id=max(0,gpuid), rclip=wclip, wmode=wmode, wref=wref, mode_9_to_15bits=1, channels=UV" + knlm_params + ")")
LFR > 50 ? ex_LFR(last,al,LFR,DCT,UV=chroma?3:2) : last

isy || rgb || is44 ? last : \
chroma ? MatchClip(c,matrix=pID[2]) : \
CombinePlanes(last,c,planes="YUV",pixel_type=PixelType(c))

propCopy(c,true,props="_ChromaLocation") }

After confirmation I upload SMDegrain with some other fixes.

Will have a look on ex_blend(), bug reports are always appreciated.

I have a bit of a project...

I have an interlaced anime @ 23.976, and using BWDIF to de-interlace brings it up to 59.94, but then it needs to go double again to 119.88.

Would Frameconverter do that, if it was de-interlaced first ??

Some script suggestions would be greatly appreciated.

After deinterlacing using RIFEwrap with the anime model, it's in ResizersPack

[LeXXuz]

Sorry, I felt very sick today so probably will get things going at a slower pace from now on.


No worries! Take things slow and watch your health. All this here can wait ;)

All the best and get well soon! :)

[Guest]

After deinterlacing using RIFEwrap with the anime model, it's in ResizersPack

Thanks for the tip, but looking at RIFEwrap, I'm non-the-wiser, and confused :(

Line 578 (https://github.com/Dogway/Avisynth-Scripts/blob/master/ResizersPack.avsi#LL578)

function RIFEwrap(clip a, int "model", int "FrameNum", int "FrameDen", bool "FrameDouble", bool "Anime", int "gpuid")

md = Default(model, 22) # model: 3 - for Anime or lineart, 17,6,22 - for photos or live action (in ascending order of qual/speed)
num = Default(FrameNum, num)
den = Default(FrameDen, den)
fd = Default(FrameDouble, !(numD || denD))
an = Default(Anime, false)
gid = Default(gpuid, 0)

Regards

[Dogway]

Just do:
RIFEwrap(model=3, anime=true)

[Guest]

Just do:
RIFEwrap(model=3, anime=true)

There seems to be something wrong here, it's VERY slow to load, then processes 1 frame, and then tries to start again...remove that call, and it's fine...

Does RIFE need something else ?

Anyway, I've been able to achieve what I needed with FrameRateConverterMIX.

[Dogway]

Yes, it's meant to be slow, but for the restart thing... I don't know. I'm checking now.

EDIT: no problem for me with RIFEwrap(). Encoded HD clip at around 2.5fps, and no problem either in AvsPmod.

By the way, if anyone can confirm my above refactored ex_KNLMeansCL() for the memory leak issues I can upload SMDegrain update today.

[LeXXuz]

By the way, if anyone can confirm my above refactored ex_KNLMeansCL() for the memory leak issues I can upload SMDegrain update today.

The memory load is about the same on my systems with the new code. I guess it's either the filter or AVS+ causing this huge VRAM demand.

[Dogway]

Ok, so with above function refactor KNLMeansCL still does memory leak, updating SMDegrain now.

[Guest]

Yes, it's meant to be slow, but for the restart thing... I don't know. I'm checking now.

EDIT: no problem for me with RIFEwrap(). Encoded HD clip at around 2.5fps, and no problem either in AvsPmod.


I've heard that it's S-L-O-W, but does RIFE need some dependency, like Vulkan ??

[kedautinh12]

I've heard that it's S-L-O-W, but does RIFE need some dependency, like Vulkan ??

Of course yes

[Guest]

Of course yes

SDK or Runtime ?

[poisondeathray]

SDK or Runtime ?

Vulkan device. Look under Requirements
https://github.com/Asd-g/AviSynthPlus-RIFE

[kedautinh12]

SDK or Runtime ?

If you install GPU driver, it's will support Vulkan

[Guest]

Vulkan device. Look under Requirements
https://github.com/Asd-g/AviSynthPlus-RIFE

I've got ALL them !

[kedautinh12]

So that slow cause this plugin very slow and only fast with high-end GPU card

[Guest]

So there's been several updates of Dogway's filters...

SMDegrain, Extools, Grade Pack & Resizers Pack.

Can someone please clarify, does SMDegrain (or others) use GPU or CPU filter processing by default ?

[kedautinh12]

So there's been several updates of Dogway's filters...

SMDegrain, Extools, Grade Pack & Resizers Pack.

Can someone please clarify, does SMDegrain (or others) use GPU or CPU filter processing by default ?

He prefer speed. If GPU plugins ver faster than CPU ver, he will use it

[Guest]

He prefer speed. If GPU plugins ver faster than CPU ver, he will use it

So would an RTX 3050 / 3060 process faster than a 13900K ?

[kedautinh12]

So would an RTX 3050 / 3060 process faster than a 13900K ?

It's base test from one by one

[Guest]

It's base test from one by one

So you're saying to test each filter, and see what's best for the user ?

That means changing a couple of settings in SMDegrain.avsi (the gpuid, from 0 for GPU, to -1 for CPU)

[LeXXuz]

So would an RTX 3050 / 3060 process faster than a 13900K ?

From my experience: KNLmeansCL and BM3D surely will run faster on a RTX 30 card. DGDenoise needs a Nvidia GPU to run at all anyway.

If you think about buying one, do NOT go for a 3050 or 3060 8GB with 128bit memory bus. They are significantly slower than a 3060 with 192bit mem bus. Learned this the hard way.

[Guest]

From my experience: KNLmeansCL and BM3D surely will run faster on a RTX 30 card. DGDenoise needs a Nvidia GPU to run at all anyway.

If you think about buying one, do NOT go for a 3050 or 3060 8GB with 128bit memory bus. They are significantly slower than a 3060 with 192bit mem bus. Learned this the hard way.

Well, fortunately I don't use those filters...I'm more curious if even using the "lesser" filters, like MinBlur, and just basic SMDegrain filters use the GPU or CPU...from what I've been able to understand, the gpuid of SMDegrain by default is "0", which is a GPU.

And I just checked my RTX's, and they are only 128bit :(

[LeXXuz]

Well, fortunately I don't use those filters...I'm more curious if even using the "lesser" filters, like MinBlur, and just basic SMDegrain filters use the GPU or CPU...from what I've been able to understand, the gpuid of SMDegrain by default is "0", which is a GPU.


SMDegrain does not use GPU in general, the setting may be a little misleading.

Only for some prefilters like the aforementioned and subpixel processing if you explicitly use subpixel=4 (with gpu=0) which means you use GPU based NNEDI3CL. See its dependencies section at the very beginning of the script.

If you don't use subpixel=4, or prefilter=6,7,8 it will not make any difference if you set gpu=0 or -1. Everything else is CPU processed to my knowledge.

I think Dogway set gpu=0 by default, so unexperienced users will use the faster GPU based processing automatically IF they choose to use any of those prefilters or subpixel processing.


And I just checked my RTX's, and they are only 128bit :(

Don't get me wrong. They will still be faster than processing BM3D or KNLM entirely on CPU. But they are not as fast as a 3060 12GB / 3060TI 8GB and above.
My advice was only for people who think about buying a new graphics card. For those it means: stay away from RTX 3050 and RTX 3060 8GB. Buy a RTX 3060 12GB or RTX 3060TI 8GB instead. ;)

[Guest]

SMDegrain does not use GPU in general, the setting may be a little misleading.

Only for some prefilters like the aforementioned and subpixel processing if you explicitly use subpixel=4 (with gpu=0) which means you use GPU based NNEDI3CL. See its dependencies section at the very beginning of the script.

If you don't use subpixel=4, or prefilter=6,7,8 it will not make any difference if you set gpu=0 or -1. Everything else is CPU processed to my knowledge.

I think Dogway set gpu=0 by default, so unexperienced users will use the faster GPU based processing automatically IF they choose to use any of those prefilters or subpixel processing.



Don't get me wrong. They will still be faster than processing BM3D or KNLM entirely on CPU. But they are not as fast as a 3060 12GB / 3060TI 8GB and above.
My advice was only for people who think about buying a new graphics card. For those it means: stay away from RTX 3050 and RTX 3060 8GB. Buy a RTX 3060 12GB or RTX 3060TI 8GB instead. ;)

Thankyou for all that info...and like I said, I very rarely use those higher filters, and I'm quite happy with the newer Median options recently added, so my RTX's will be fine...anything more hi-end, is so much more $'s :(

[madey83]

Yes, you can adjust the "strength" by adjusting the opacity of the blend somewhere between 0 (no denoise filter effect) and 1.0 (full denoise filter effect)

But if you have just some fine grain better use something different like STTWM. Dogway provided examples for that some posts above and they can also be found in his ExTools package ~line 2194. :)

hi LeXXuz,

to use STTWM as prefilter i should skip below
pre=ex_Median(mode="IQMST",thres=155)
ex_blend(pre,"blend",opacity=0.3).ex_sbr(1,UV=3)

and replace it by one of below?

# STTWM(sw=20,tw=80,aw=100,sthres=255,tthres=7) # Strong temporal
# STTWM(sw=40,tw=60,aw=100,sthres=255,tthres=5) # Strong spatial
pre= STTWM(sw=50,tw=50,aw=100,sthres= 5,tthres=5) # Balanced
# STTWM(sw=50,tw=50,aw= 10,sthres= 5,tthres=5) # Light

[LeXXuz]

hi LeXXuz,

to use STTWM as prefilter i should skip below
pre=ex_Median(mode="IQMST",thres=155)
ex_blend(pre,"blend",opacity=0.3).ex_sbr(1,UV=3)

and replace it by one of below?

# STTWM(sw=20,tw=80,aw=100,sthres=255,tthres=7) # Strong temporal
# STTWM(sw=40,tw=60,aw=100,sthres=255,tthres=5) # Strong spatial
pre= STTWM(sw=50,tw=50,aw=100,sthres= 5,tthres=5) # Balanced
# STTWM(sw=50,tw=50,aw= 10,sthres= 5,tthres=5) # Light

Yes. And if you want to use it as prefilter for SMDegrain I would use it without ex_blend for most cases as it is way more subtle than ex_median with IQMST setting.

[madey83]

Yes. And if you want to use it as prefilter for SMDegrain I would use it without ex_blend for most cases as it is way more subtle than ex_median with IQMST setting.


i'm not really sure what you mean. Could you please provide example code for your suggestion?

i see from my test that this pre= STTWM(sw=50,tw=50,aw=100,sthres= 5,tthres=5) # Balanced

have more details but keep also some grain compare to below

pre=ex_Median(mode="IQMST",thres=15)
ex_blend(pre,"blend",opacity=0.2).ex_sbr(1,UV=3)

i'm very happy with resoults of this STTWM(sw=50,tw=50,aw=100,sthres= 5,tthres=5) # Balanced, but i would like to know how to adjust it strengh.

STTWM i can adjust it strengh by rising these sthres= 5, tthres=5 ?

[LeXXuz]

If you use it as a prefilter within SMDegrain you may use this:


pre=STTWM(sw=50,tw=50,aw=100,sthres= 5,tthres=5).ex_sbr(1,UV=3)
SMDegrain("your settings here", prefilter=pre)


STTWM is way less invasive so I don't think there is need for the additional strength adjustment via ex_blend like you may had to use with IQMST before.

If the filtering is too weak try raising "thSAD" and/or "tr" of SMDegrain a little.
If that is not enought the grain of your source may be too strong for STTWM or you need a different prefilter.

In that case try ex_Minblur or ex_Median with "IQM" via the internal prefilters 0-3 if IQMST is too strong and STTWM is too weak for your source.

[madey83]

If you use it as a prefilter within SMDegrain you may use this:


pre=STTWM(sw=50,tw=50,aw=100,sthres= 5,tthres=5).ex_sbr(1,UV=3)
SMDegrain("your settings here", prefilter=pre)


STTWM is way less invasive so I don't think there is need for the additional strength adjustment via ex_blend like you may had to use with IQMST before.

If the filtering is too weak try raising "thSAD" and/or "tr" of SMDegrain a little.
If that is not enought the grain of your source may be too strong for STTWM or you need a different prefilter.

In that case try ex_Minblur or ex_Median with "IQM" via the internal prefilters 0-3 if IQMST is too strong and STTWM is too weak for your source.


:thanks:

edit: Results are very nice with higher TR :)

[madey83]

For sharpening i use this call:
LSFplus(strength=50, preset="LSF", secure=true, Lmode=3, soft=-2, soothe=true, Smode=3, Smethod=3, Szrp=16, Spwr=4, SdmpLo=4, SdmpHi=48, overshoot=1, undershoot=1, Overshoot2=1, Undershoot2=1, keep=20, edgemode=0)

is it any possibility to improve it or replace it by better approach for sharpening?

Could you advice please.... :)

[LeXXuz]

I hardly use Limited Sharpen anymore. I don't like the results, especially on HD sources.

I use contrasharp=true within SMDegrain. And if that is too strong, something more subtle like ex_unsharp() with lower settings after SMDegrain.

try:

SMDegrain(...)
ex_unsharp(0.3) for clean anime

and a double call for films, like:

SMDegrain(...)
ex_unsharp(0.15).ex_unsharp(0.15, Fc=width()/1.5)

The first example sharpens the entire picture the same way, while the 2nd sharpens higher frequencies less to prevent residual grain from being enhanced too much again.

[madey83]

I hardly use Limited Sharpen anymore. I don't like the results, especially on HD sources.

I use contrasharp=true within SMDegrain. And if that is too strong, something more subtle like ex_unsharp() with lower settings after SMDegrain.

try:

SMDegrain(...)
ex_unsharp(0.3) for clean anime

and a double call for films, like:

SMDegrain(...)
ex_unsharp(0.15).ex_unsharp(0.15, Fc=width()/1.5)

The first example sharpens the entire picture the same way, while the 2nd sharpens higher frequencies less to prevent residual grain from being enhanced too much again.


:thanks::thanks::thanks:

[Guest]

I would really like to combine this...

LoadPlugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
LoadPlugin("%AVISYNTHPLUGINS%\MedianBlur2\MedianBlur2.dll")
Import("%AVISYNTHPLUGINS%\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\GRADE-PACK\Grade Pack.avs")
Import("%AVISYNTHPLUGINS%\LSF-PLUS\LSFplus.avs")
Import("%AVISYNTHPLUGINS%\RESIZERS-PACK\Resizers Pack.avs")
Import("%AVISYNTHPLUGINS%\SHARPENERS-PACK\Sharpeners Pack.avs")
Import("%AVISYNTHPLUGINS%\SMDEGRAIN\SMDegrain.avs")
Import("%AVISYNTHPLUGINS%\Zs_RF_Shared\Zs_RF_Shared.avs")
pre=ex_Median(mode="IQMST",thres=255)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)

with this

LoadPlugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
LoadPlugin("%AVISYNTHPLUGINS%\FrameRateConverter\FrameRateConverter-x64.dll")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\GRADE-PACK\Grade Pack.avs")
Import("%AVISYNTHPLUGINS%\FrameRateConverter\FrameRateConverterMIX.avs")
FrameRateConverterMIX(FrameDouble=true)

They both work on their own, but I'd like to combine them..

I haven't had any luck, it must be the order of the calls that I can't get right :(

Thanks.

[LeXXuz]

May I ask why you manually import and load all those filters and scripts from your plugin folder?

I see no need to put them in separate subfolders and loading them manually. Just put them in your main plugin folder and Avisynth will autoload them by itself.
I have way over 100 files in there without any loading issues when needed. And I don't have to care which plugin I have to load for which script.

But if you have to do so. Load filters first, then import your scripts.

And maybe you should use a mt-modes script, which holds all the tested mt-modes for plugins.
Newer filters auto-register their mt-mode correctly but there are still many old filters which do not.
https://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest

[Guest]

May I ask why you manually import and load all those filters and scripts from your plugin folder?

I see no need to put them in separate subfolders and loading them manually. Just put them in your main plugin folder and Avisynth will autoload them by itself.
I have way over 100 files in there without any loading issues when needed. And I don't have to care which plugin I have to load for which script.

But if you have to do so. Load filters first, then import your scripts.

And maybe you should use a mt-modes script, which holds all the tested mt-modes for plugins.
Newer filters auto-register their mt-mode correctly but there are still many old filters which do not.
https://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest

Well, I'm one of the few ppl that use RipBot264, and that's the way it's been built...

StaxRip, and I think Hybrid are setup the same way, so not sure what you're using.

MT is controlled elsewhere, too.

Thanks for the tip on the script's, I'll see how I go.

[Lan4]

I have already asked in several places. I'll try to explain. This is off topic, but there are a lot of filter wizards here.

I'm interested in calculating sharpness. For example, I do several video processing options. And I compare the results in values. In order not to strain your eyesight, do not waste a lot of time. And also because the eyes see differently, today it is like this, and tomorrow it will be different, so the opinion changes. Filters perform calculations before starting work. These calculations can be displayed to the user so that this is a styled plugin?

There are examples of this with photos, although they are not popular.

[Heaud]

Regarding ResizersPack.avsi, does it only work with YV12 input? I tested out waifu2xresize from the resizers pack and it does not work properly with any image format that is not YUV420. There is also an error that comes up from the most recent version of this script:

https://i.imgur.com/1XbjsMo.png

Manually going into the script and replacing the values in that line from 4 : 2 to 2 : 1 allows waifu2xresize to run, although I am not sure if my version of w2xncnnvk (1.0.1) is compatible.

[Dogway]

They both work on their own, but I'd like to combine them..

I haven't had any luck, it must be the order of the calls that I can't get right :(
Tested here without any issues calling FrameRateConverterMIX after SMDegrain. I guess it might be something in your setup, as LeXXuz suggested.

Regarding ResizersPack.avsi, does it only work with YV12 input? I tested out waifu2xresize from the resizers pack and it does not work properly with any image format that is not YUV420. There is also an error that comes up from the most recent version of this script
Thanks, it was a bug in TransformsPack for YUV444 to RGB conversion. Just fixed it, will update soon. As for the error, I don't get it, in the readme (https://github.com/Asd-g/AviSynthPlus-w2xncnnvk) it default's to 2, but it says it can be increased if needed. I tested writing 4 in the arg without issues. Maybe a GPU limitation? Or a combination of settings, like HD, gpu_id, etc.

I'm interested in calculating sharpness. For example, I do several video processing options. And I compare the results in values. In order not to strain your eyesight, do not waste a lot of time. And also because the eyes see differently, today it is like this, and tomorrow it will be different, so the opinion changes. Filters perform calculations before starting work. These calculations can be displayed to the user so that this is a styled plugin?

I made a filter for it called SVM in SimilarityMetrics but these days I was playing with it and didn't quite get convinced. It's based on Laplace but with a sqrt flair to it. So the other day I made a new one a bit more elaborated but haven't uploaded yet as I have to review a few things (speed, consistency...)
function SVM2(clip a, bool "texture", int "show") {

rgb = isRGB(a)
bi = BitsPerComponent(a)
fs = propNumElements (a,"_ColorRange") > 0 ? \
propGetInt (a,"_ColorRange") == 0 : rgb
tx = Default(texture, false)
show = Default(show, 0) # 0: output 'diff' 1: output 'clip' 2: output 'diff' with subtitle

ConvertBits(a,32, dither=-1, fulls=fs, fulld=true)
# This is kroon detail mask
ed = ex_edge("kroon",lo=20,hi=255,scale=0.5)
# This is Gaussian diff mask to extract texture detail (with ex_unsharp a discreet lower freq diff is considered as 20%)
bl = ex_unsharp(-0.75,Fc=width()/1.5)
msk = ex_makediff(bl,dif=false,aug=1)
# This is to remove edges from texture detail mask (will add back with kroon edge mask)
ed2 = ex_luts(mode="min/max", pixels=ex_shape(2,mode="disk"),clamp_float=true,exprf=Format(" 60 255 / - range_max 255 150 60 - / * *"))

!tx ? ex_lutxyz(msk,ed,ed2,"x z - 0 max y + 1 255 / - 0 max sqrt ") : \
ex_lutxy (msk, ed2,"x y - 1 255 / - 0 max 0.3 ^")

vde = ex_inflate()

ScriptClip(show == 1 ? a : vde, function [vde] () {
propSet(last,"_PlaneSharpness", AverageLuma(vde), 0) } )

show != 1 ? ConvertBits(last, bi, dither=-1, fulls=true) : last

show == 2 ? ScriptClip(function [] () {
Subtitle("_PlaneSharpness: "+string(propGetFloat("_PlaneSharpness"))) } ) : last
}

[Guest]

Tested here without any issues calling FrameRateConverterMIX after SMDEgrain. I guess it might be something in your setup, as LeXXuz suggested.

Good to know, I will just shuffle the call's around until it works.

I even checked in Hybrid so see how that generates a script using SMDegrain & FrameConverter, and changed my script to suit, as best I could, and it didn't work...or I didn't have the patience to wait for it to start, after several minutes of waiting.

No luck, what script did you use to test ?

[Dogway]

Simply used:
pre=ex_Median(mode="IQMST",thres=255)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)
FrameRateConverterMIX(FrameDouble=true)
in AvsPmod, and I think without Prefetch() even as I only use it when encoding.
You might need to review your workflow, use avs+ test 9, setmemorymax to an appropiate value, and load the mt-modes.avsi. Also test with other source loaders.

[Guest]

Simply used:
pre=ex_Median(mode="IQMST",thres=255)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)
FrameRateConverterMIX(FrameDouble=true)
in AvsPmod, and I think without Prefetch() even as I only use it when encoding.
You might need to review your workflow, use avs+ test 9, setmemorymax to an appropiate value, and load the mt-modes.avsi. Also test with other source loaders.

So I'm guessing that by using AvsPmod, all the required dependencies for SMDegrain & FrameConverter are auto loaded...

I'm also using AVS r3973, I'm also using prefetch 16, and mt, but that is somewhere else in the process, not in the main scripts.

Also using L-Smash.

[Dogway]

So I'm guessing that by using AvsPmod, all the required dependencies for SMDegrain & FrameConverter are auto loaded...

I'm also using AVS r3973, I'm also using prefetch 16, and mt, but that is somewhere else in the process, not in the main scripts.

Also using L-Smash.

Hitting all the marks for a failure. Use pinterf builds, they are the safest. Also load with ffvideosource, and put your plugins and .avsi into the autoload folder. That would be a good start. My recommendation also, if using my scripts separate real.finder scripts into another folder as Zs_RF_Shared that I saw you loading may interfere. I put them all in a folder with a IMPORT_ALL.avsi loading them, which I can in turn then load all of them with a single line.

[Guest]

Hitting all the marks for a failure. Use pinterf builds, they are the safest. Also load with ffvideosource, and put your plugins and .avsi into the autoload folder. That would be a good start. My recommendation also, if using my scripts separate real.finder scripts into another folder as Zs_RF_Shared that I saw you loading may interfere. I put them all in a folder with a IMPORT_ALL.avsi loading them, which I can in turn then load all of them with a single line.

I still have to ask, why then do those scripts work separately, but not when combine them? Or does it just slow down the whole process so much, that it's not worth it?

And I'm pretty sure that an "autoload" folder does not work with the likes of StaxRip, RipBot264 or Hybrid.

And I don't use AvsPmod or MeGui.

I will try your suggestions about AVS & FFMS2.

UPDATE:- Made no difference at all :(

[Lan4]

I made a filter for it called SVM in SimilarityMetrics but these days I was playing with it and didn't quite get convinced. It's based on Laplace but with a sqrt flair to it. So the other day I made a new one a bit more elaborated but haven't uploaded yet as I have to review a few things (speed, consistency...)
OK, thank you. To be honest, I'm surprised that someone is also interested. what will be the implementation? curve, values, tool? will it be one general parameter or several aspects?

[LeXXuz]

Dogway, SMDegrain is calling mfilter, if it's set, for those areas where MVtools found no matching motion vectors (based on the parameters given), and therefore these will not be denoised, is that about right?

I mentioned, I simply use Greyscale() to identify how much of those areas is still present in the output to determine if I should tinker some more with either prefilter, tr or thSAD.

I did some testing with a source where artificial grain was just added to the luma plane, so I saw no reason to process all three planes.
Ergo disabled chroma processing to gain some speed.
To my surprise the output was ALWAYS completely grey as soon as I set plane=0.

For example with this simple call:
ConvertBits(16)
PREm = Greyscale()
SMDegrain(tr=3, thSAD=1000, mfilter=PREm, chroma=false, plane=0)

Is this a bug or supposed to happen?
Because no chroma was processed => therefore no mv data for U and V => so the entire chroma planes are handed over to mfilter (which then flattens them with greyscale())?

I expected if processing is set to luma only, that only what happens in Y plane determines if mfilter is called or not.

[DTL]

" no mv data for U and V "

Single MV data always applied to all planes selected (in MDegrainX). For total processing yon can disable chroma in MAnalyse for better performance (visible enough benefit, may significantly decrease quality of MV data in some cases) and you can disable denoise of chroma planes in MDegrainX (may be very low performance boost, typically disabled only if user not want to denoise chroma for some use case).

[LeXXuz]

Thanks DTL. Yes, I noticed performance gain is very small.
Decided to play it safe and better process all planes again.

[Dogway]

OK, thank you. To be honest, I'm surprised that someone is also interested. what will be the implementation? curve, values, tool? will it be one general parameter or several aspects?
Did you see the posted function? It will be that or a slightly modified version of it. It only has two arguments, 'texture' to isolate texture alone, and 'show', to output source clip with '_PlaneSharpness' frameprop embedded, or a mask with the value subtitled.
My interest sparked from this issue (https://github.com/libjxl/libjxl/issues/1470)in JXL, they use different metrics to assess quality like Butteraugli or SSIMULACRA2, but they are edge centric metrics and don't take into account (texture) sharpness.
UPDATE:- Made no difference at all :(
Sounds like an issue with the software you are using, ripbot, megui or hybrid. Try to ask them about it.
Dogway, SMDegrain is calling mfilter, if it's set, for those areas where MVtools found no matching motion vectors (based on the parameters given), and therefore these will not be denoised, is that about right?

I mentioned, I simply use Greyscale() to identify how much of those areas is still present in the output to determine if I should tinker some more with either prefilter, tr or thSAD.

I did some testing with a source where artificial grain was just added to the luma plane, so I saw no reason to process all three planes.
Ergo disabled chroma processing to gain some speed.
To my surprise the output was ALWAYS completely grey as soon as I set plane=0.

For example with this simple call:
ConvertBits(16)
PREm = Greyscale()
SMDegrain(tr=3, thSAD=1000, mfilter=PREm, chroma=false, plane=0)

Is this a bug or supposed to happen?
Because no chroma was processed => therefore no mv data for U and V => so the entire chroma planes are handed over to mfilter (which then flattens them with greyscale())?

I expected if processing is set to luma only, that only what happens in Y plane determines if mfilter is called or not.
Interesting topic. TBH my workflow recently has been to pass a high blur like ex_blur(6) to mfilter to identify passthrough.
In any case Greyscale() might not be the way to do it as the effect you'd get is simply greyscaled chroma (luma stays the same) which is hard to spot.
A better option is PREm = ex_lut("range_half",UV=1). That would give you a better view of what's going on. Or rendering it in red PREm = Expr("81","90","250",scale_inputs="int"), temporally using plane=4.

Typically from old workflows it is mfilter.MDegrain(input.MSuper(), ..."prefilter MV"...), so as you see it is indeed using luma and chroma from mfilter. Whichever you don't process, then it passes the mfilter plane. This is done for optimization. Do you think I should swizzle unused planes in from input even if it hits performance?

About processing chroma for MV or not, I did some experiments that resulted in increased quality when taking chroma into account, unless chroma is a crap fest like VHS and other sources. I went to the extent to increase chroma weighting for MV as you can see in the scaleCSAD variable.

[Guest]

Sounds like an issue with the software you are using, ripbot, megui or hybrid. Try to ask them about it.

I doubt that it's an issue with the software I'm using...

I am using 2 of your scripts, that work well on their own, but trying to combine them to do both tasks at the same time, just doesn't work for me.

Have I got all the required dependencies or is the order of the calls messed up ??

here (https://forum.doom9.org/showthread.php?p=1985207#post1985207)

[LeXXuz]

This is done for optimization. Do you think I should swizzle unused planes in from input even if it hits performance?

About processing chroma for MV or not, I did some experiments that resulted in increased quality when taking chroma into account, unless chroma is a crap fest like VHS and other sources. I went to the extent to increase chroma weighting for MV as you can see in the scaleCSAD variable.

I think it's fine the way it is. I simply didn't expect this outcome at first. And I will keep chroma processing in my workflow, as I've seen performance benefit is really small and not worth the trade off for losing some accuracy when not processing chroma for mv.

Btw did you have a chance to take a look into ex_blend and those error message overlays from Scenestats in the meantime? :)

[DTL]

" they are edge centric metrics and don't take into account (texture) sharpness."

As I see we still have very few underlying math analysis tools for random fields for image similarity compare. Most of similarity metrics are based on only 2 underlying math statistical tools - variance and covariance. And some higher-level math playing with these 2 computed values to get 'really nice metric ranging in 0..1 or -1..1' .

For texture quality (similarity) part of metric it looks mostly work covariance value. So at some of my MPB-processing for MDegrainN to keep as nice textures as possible (skip most of texture-damaging blocks from blending blocks pool) I found it may be used simple pure covariance. May be the covariance computing may be somehow additionally enhanced to mark texture sharpness even more.

[Dogway]

LeXXuz, try now, I updated SMDegrain with some improvements. First unprocessed planes are copied from input to mfilter clip when using mfilter obviously, this makes more sense.
Also multi (tr > 6) happened to don't be correct for some modes like LFR, mfilter or mode!="MDegrain", that is fixed now, and also with nice for loops, so less code lines.

About SceneStats that's a delicate issue due to the complexity of the filter. First I'm taking things slower now, and second I decided to wait until the issue happens to me again instead of searching for it, but it's acknowledged and will tackle with it when that happens.

DTL, do you have literature about this approach (covariance for texture/sharpness metrics)? What variables would covariance employ in this case?

[LeXXuz]

Thanks Dogway, updating now. :)

I don't know if that would be any simpler, but if you could just disable that error overlay that would be a big help already.

Otherwise I'll wait with these sources, no problem at all. Enough other stuff to work on from my collection. :D

[Dogway]

I don't think it's that easy, as I said the filter is quite complex, and even if I fix the eventual errors (at least the ones I was having) fades in/out will still need to be trimmed out. If someone comes up with a fade detector that would be welcomed.

[LeXXuz]

I don't think it's that easy, as I said the filter is quite complex, and even if I fix the eventual errors (at least the ones I was having) fades in/out will still need to be trimmed out. If someone comes up with a fade detector that would be welcomed.

Okay, no problem. And thanks for the suggestion with Expr() and ex_lut() for mfilter preview. They show way better which areas are processed. :)

[DTL]

"do you have literature about this approach (covariance for texture/sharpness metrics)? What variables would covariance employ in this case?"

Covariance is major part of most 'complex' metrics (more complex in compare with 'simple' SAD). SSIM and VIF widely uses covariance component. SSIM have 'structure' part based on covariance and VIF also uses covariance in output computing formula. You can look into SSIM and VIF computing functions in mvtools to see how it calculated from blocks arrays samples:

SSIM https://github.com/DTL2020/mvtools/blob/mvtools-pfmod/Sources/SSIMFunctions.cpp

Full SSIM is SSIM_Light * SSIM_Contrast * SSIM_Structure . SSIM_Light is sort of simple average of samples. SSIM_Contrast is some function of (variance_a, variance_b) where variance_a is fsX and variance_b is fsY at https://github.com/DTL2020/mvtools/blob/0a6b093507bc757457783d537bc6cfaaa273989d/Sources/SSIMFunctions.cpp#L57

And SSIM_Structure is function of covariance(a,b) (fsXY) - https://github.com/DTL2020/mvtools/blob/0a6b093507bc757457783d537bc6cfaaa273989d/Sources/SSIMFunctions.cpp#L66 . And after getting all 3 components of SSIM output is simple multiplication.

But for some specific analisys each part of SSIM may be used separately. Most interesting for textures may be SSIM_Structure calculated from covariance.

VIF is https://github.com/DTL2020/mvtools/blob/mvtools-pfmod/Sources/VIFFunctions.cpp

It uses covariance of DWT - https://github.com/DTL2020/mvtools/blob/0a6b093507bc757457783d537bc6cfaaa273989d/Sources/VIFFunctions.cpp#L66 (DWT_a component) for VIF_A part and also some covariance for VIF_E part - https://github.com/DTL2020/mvtools/blob/0a6b093507bc757457783d537bc6cfaaa273989d/Sources/VIFFunctions.cpp#L98

It may be possible to convert C-computing to AVS scripting computing and you can make full or structure-only SSIM in AVS function.

The VIF DWT-based require DWT (it is not complex but more slow). The most diffrerence between SSIM and VIF for structure part is SSIM compute from direct input blocks samples covariance and VIF compute covariance from DWT-transformed blocks (may be sort of low-pass filtering or twice reducing ?).

[Dogway]

Thanks for the links, I will have a look later. If none of covariance components come from a texture analysis it would be a moot point. I have SSIM ported to a function in SimilarityMetrics, but I don't recall any texture extraction.
VIF doesn't sound familiar to me so will have a look (EDIT: ok, VIF -Visual Information Fidelity- from my metrics issue (https://github.com/Dogway/Avisynth-Scripts/issues/36)). DWT is frequency based so that might be useful.

The problem probably with blocks is that small details vanishes from the block average, unless augmentation is performed, that or dynamic sized blocks come into play like x265.

[Boulder]

For visualizing the effect of filters outside MDegrain, I've used the Subtract method like Subtract(finalclip_nonblurred, finalclip.mergechroma(finalclip_nonblurred)).levels(127*256, 1, 132*256, 0*256, 255*256).subtitle("Effect of blur in result", y=40). Here 'finalclip' is the normal output, finalclip_nonblurred the one where there is no denoising other than MDegrain and then I just want to see how luma looks like so the chroma planes are merged from the normal output.

Funny thing is that the filter gets quite a big weight even if you use something like thsad=10000 in MDegrain, it won't change the output much if you limit the effect of MDegrain itself. I was always under the impression that thsad can be used to control which parts of the frame get processed by MDegrain and which parts are skipped because the calculated thsad is too high.

[DTL]

" If none of covariance components come from a texture analysis it would be a moot point. "

Covariance in SSIM is direct math covariance between samples of compared blocks. It shows how the samples of the compared blocks changes in similar way at each sample. If one block is blurry and second is sharp (non-damaged by blur) - the covariance metric will be lower.

Covariance is
fsXY += (float)((pWorkSrc[x] - isuX) * (pWorkRef[x] - isuY));
- sum of multiplication of (blocks values - mean block value (mean DC component)). So if samples changes in same direction from mean value - the mul operation gives higher result. Also it is positive for both positive and negative difference from mean value (DC) if both differences have same sign.

So if some processing start to damage texture in compare with 'initial source' - the covariance metric become lower and it can be detected and the processing may be adjusted to keep texture more non-damaged. Also the processing may be optimized (zopti ?) to maximize covariance metric between input and output.

[LeXXuz]

Funny thing is that the filter gets quite a big weight even if you use something like thsad=10000 in MDegrain, it won't change the output much if you limit the effect of MDegrain itself. I was always under the impression that thsad can be used to control which parts of the frame get processed by MDegrain and which parts are skipped because the calculated thsad is too high.

I think without raising thSCD as well you will not do much, even with thSAD that exorbitant high, since every frame is probably considered a scene change now?

[Boulder]

I think without raising thSCD as well you will not do much, even with thSAD that exorbitant high, since every frame is probably considered a scene change now?

thSAD is not directly connected to scene change detection, you can use a higher thSAD value than thSCD1 and the frame will still show motion vectors with MShow (which is very useful with showsad=true). As far as I know, thSCD1 sets the threshold (per block) and thSCD2 then sets the max amount of blocks triggered by thSCD1.

[DTL]

If you set thSAD to very high value and scene detection still not skip frame - you simply lost protection from bad blends and MDegrainX will work as linear motion compensated blending engine (may be equal to MCompensate + Average()). If MVs are not perfect or there is other non-supported and not-compensated transforms left it will cause either blurring or visible several different blocks blended. thSAD adjustment in MDegrainX is only to protect user for possible artifacts of the very very simple temporal denoise method of different frames blocks weighted averaging.

In a perfect world with ideal transforms compensation no any protection required (see RIFE + Average() denoise example).

thSCD protects from more general error of blending different scenes in single frame.

[Guest]

Simply used:
pre=ex_Median(mode="IQMST",thres=255)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)
FrameRateConverterMIX(FrameDouble=true)
in AvsPmod, and I think without Prefetch() even as I only use it when encoding.
You might need to review your workflow, use avs+ test 9, setmemorymax to an appropiate value, and load the mt-modes.avsi. Also test with other source loaders.

I think I might have figured out what's going on...

What type (resolution) video did you test this script on ?

I am trying to use FrameConverter on 4K HDR10 content, and I think the combination is just too much for it, 'cause it seems to be ok, but slow, on lesser resolution's.

[LeXXuz]

I think I might have figured out what's going on...

What type (resolution) video did you test this script on ?

I am trying to use FrameConverter on 4K HDR10 content, and I think the combination is just too much for it, 'cause it seems to be ok, but slow, on lesser resolution's.

Could be a memory problem. How much RAM does your system have? If you have 32GB for example, try adding


SetMemoryMax(20*1024) # max RAM usage in kilobytes
SetCacheMode(0)

at the very beginning of your script. If your machine has more RAM you can raise that even more.

I have some script combinations which have very high RAM demands and either will not start or be very very slow on higher resolutions, if I don't set MemoryMax correctly.

Also, some filters don't really like caching, especially in multithreading with a high prefetch count, so I have to set cache mode explicitely to zero.

[Guest]

Could be a memory problem. How much RAM does your system have? If you have 32GB for example, try adding


SetMemoryMax(20*1024) # max RAM usage in kilobytes
SetCacheMode(0)

at the very beginning of your script. If your machine has more RAM you can raise that even more.

I have some script combinations which have very high RAM demands and either will not start or be very very slow on higher resolutions, if I don't set MemoryMax correctly.

Also, some filters don't really like caching, especially in multithreading with a high prefetch count, so I have to set cache mode explicitely to zero.

I do only have 32Gb....

And I have this in every script:-

SetCacheMode(1)
SetMemoryMax(16384)

And the Prefetch is 16, but it's not included in the scripts.

[LeXXuz]

I do only have 32Gb....

And I have this in every script:-

SetCacheMode(1)
SetMemoryMax(16384)

And the Prefetch is 16, but it's not included in the scripts.

Try with cache mode 0.

[Boulder]

If you set thSAD to very high value and scene detection still not skip frame - you simply lost protection from bad blends and MDegrainX will work as linear motion compensated blending engine (may be equal to MCompensate + Average()). If MVs are not perfect or there is other non-supported and not-compensated transforms left it will cause either blurring or visible several different blocks blended. thSAD adjustment in MDegrainX is only to protect user for possible artifacts of the very very simple temporal denoise method of different frames blocks weighted averaging.

In a perfect world with ideal transforms compensation no any protection required (see RIFE + Average() denoise example).

thSCD protects from more general error of blending different scenes in single frame.
My case was just an example of trying to emphasize the effect. My default values for thSAD and thSCD1 are 400 and 600 respectively. thSCD1 sometimes needs to be bigger if the source is very grainy (despite heavy prefiltering).

[Guest]

Try with cache mode 0.

Isn't 0 default, so I could simply remove that call...

[LeXXuz]

I don't trust defaults. :D

[Guest]

I don't trust defaults. :D

I might as well raise the "memorymax", too...

[LeXXuz]

You probably have to. 16GB is not very much for more complex filtering of 4k content.

[Boulder]

The default SetMemoryMax plays it too safe. 4K processing can easily require over 10GB of cache :D

[Guest]

You probably have to. 16GB is not very much for more complex filtering of 4k content.

Change of subject...

Is there a way to add .srt subtitles with AVS, and edit font size.

[poisondeathray]

Change of subject...

Is there a way to add .srt subtitles with AVS, and edit font size.

Nothing to do with this thread. You should post somewhere else or start a new one

You can convert to .ass and specify font size there

[Guest]

Nothing to do with this thread. You should post somewhere else or start a new one

You can convert to .ass and specify font size there

Well, you never know what Dogway may have hidden in amongst all his scripts / filters.

[coolgit]

Put .srt sub with same filename as video in same folder and your player will load it and use player to change font size.

[Guest]

Put .srt sub with same filename as video in same folder and your player will load it and use player to change font size.

I do that most of the time, but I want to hardcode them for a series, before editing out lengthy intros, etc.

[Emulgator]

SubtitleEdit is your friend. Go to thread
https://forum.doom9.org/showthread.php?t=162721

[Dogway]

Simply used:
Code:
pre=ex_Median(mode="IQMST",thres=255)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)
FrameRateConverterMIX(FrameDouble=true)
in AvsPmod, and I think without Prefetch() even as I only use it when encoding.
You might need to review your workflow, use avs+ test 9, setmemorymax to an appropiate value, and load the mt-modes.avsi. Also test with other source loaders.
I think I might have figured out what's going on...

What type (resolution) video did you test this script on ?

I am trying to use FrameConverter on 4K HDR10 content, and I think the combination is just too much for it, 'cause it seems to be ok, but slow, on lesser resolution's.

4K changes it all. Look at the script, 4 temporal filters, that requires a lot out of order access. Unless you have a lot of cache or/and use your highest RAM it's going to run very slow, and I'm not sure even if AVS+ is ok for smooth 4K workflows. You might improve it using RequestLinear(2*24) just before FrameRateConverter.

Also being HDR10 you need to supply SMDegrain (and ideally FrameRateConverter) an SDR prefilter, as suggested in the docs or at the top of the SMDegrain script.

Should these two be identical in output?

Code:
PRE=ex_Median(mode="IQMST", UV=3,thres=255)
Code:
PRE0=ex_Median(mode="IQMST", UV=3,thres=255)
PRE=ex_blend(PRE0,"blend",opacity=1)


Since opacity is clamped between 0,1 in ex_blend
-output with opacity=0 seems identical with the last clip, as it should.
-output with opacity=1 seems not identical with the blend clip, which I would've expected.

Also I noticed some flickering in the output when opacity is used with anything but 0.
Quite subtle but noticeable in some backgrounds when you're very susceptible to flicker. Could these be rounding errors from the blending process by any chance?

Sorry I missed this post, I thought you were referring to the SceneStats issue. Yes this is a bug, only when opacity is 1 in 'blend' mode for TV range sources. It's fixed now.
As for the flicker, are you sure about that? it's a basic 2 clips blends, I forgot to say but you could also do Merge(clip1,clip2,0.5), output should be similar, that means it should not show flicker either.

[coolgit]

I do that most of the time, but I want to hardcode them for a series, before editing out lengthy intros, etc.

Don't hardcode them. What if there is a spelling mistake, missing word, lines etc. With subtitleedit you can fix them easily. With hardcode you will have to fix the subs and compress the files all over again.

Hardcode subs are a very bad idea.

[Guest]

Don't hardcode them. What if there is a spelling mistake, missing word, lines etc. With subtitleedit you can fix them easily. With hardcode you will have to fix the subs and compress the files all over again.

Hardcode subs are a very bad idea.

I find it interesting how many continuing comments you can get with an off topic subject :(

This will be the last comment I make about subtitles here, as it is WAY off the thread's topic....kinda wish I hadn't brought it up, here.

I know hard coded has all those issues, but when you want to edit, cut, trim, the video & audio, (for example the first 2 minutes of every Game of Throne episode), you'd have to separately re-time the subtitles to suit the new running time, whereas if the video is hard coded (and double checked for typo's etc), then the trimming will take care of the subtitles :)

@ Emulgator

And I know that "SubtitleEdit is your friend", I have been using it for years, but I don't think you can change the font size for .srt's.

If you want to reply, please send me a PM, not on here.

[Guest]

4K changes it all. Look at the script, 4 temporal filters, that requires a lot out of order access. Unless you have a lot of cache or/and use your highest RAM it's going to run very slow, and I'm not sure even if AVS+ is ok for smooth 4K workflows. You might improve it using RequestLinear(2*24) just before FrameRateConverter.

Also being HDR10 you need to supply SMDegrain (and ideally FrameRateConverter) an SDR prefilter, as suggested in the docs or at the top of the SMDegrain script.

Sorry about the subtitles stuff :scared:

Yes, I will be changing a few things with the info I've got about this, I'm glad I mentioned the 4K HDR10 thing.

But as for the SDR pre-filter, if that is to change the HDR to SDR, I don't want to do that!!

:thanks:

UPDATE:-

OK, I've had some success :cool:

Added TIVTC, so as to use RequestLinear(2*24), and modified the script.

Now using

SetCacheMode()
SetMemoryMax(20480)

I found that using SetCacheMode(0) was a little slower.

And going from SetMemoryMax 16384 (16Gb) to 20480 (20Gb) was a nice little bump, however, going up to 24576 (24Gb), it basically maxed out my 32G of DD5 and didn't really even want to start :(

So if there's anyone else out there that's silly enough to want to use FrameRateConverter on 4K, you need to add all this to the script :cool:

I'm sure that if I upped the system RAM to 64Gb or beyond it would process even faster. but DDR5 RAM is a bit too much $. :devil:

[coolgit]

I find it interesting how many continuing comments you can get with an off topic subject :(

This will be the last comment I make about subtitles here, as it is WAY off the thread's topic....kinda wish I hadn't brought it up, here.

I know hard coded has all those issues, but when you want to edit, cut, trim, the video & audio, (for example the first 2 minutes of every Game of Throne episode), you'd have to separately re-time the subtitles to suit the new running time, whereas if the video is hard coded (and double checked for typo's etc), then the trimming will take care of the subtitles :)


Actually it isn't off topic as Dogway does have a sub filter SwipeSubs https://github.com/Dogway/Avisynth-Scripts/tree/master/EX%20mods therefore your query and hope Well, you never know what Dogway may have hidden in amongst all his scripts / filters. was valid within the realm of this thread even though it not what you wanted.

Re timing the srt files is easy and quicker, 10 seconds per file. I have been doing this for 2 decades. Trust me if you hardcode them you will create more problems and waste more time.

Up to you.

[Guest]

Actually it isn't off topic as Dogway does have a sub filter SwipeSubs https://github.com/Dogway/Avisynth-Scripts/tree/master/EX%20mods therefore your query and hope was valid within the realm of this thread even though it not what you wanted.

Re timing the srt files is easy and quicker, 10 seconds per file. I have been doing this for 2 decades. Trust me if you hardcode them you will create more problems and waste more time.

Up to you.

Well, all right then :)

Yes, it's not really what I'm after, so maybe Dogway might come up with a solution to my situation. :eek:

I know that re-timing would be reasonably easy with just a trim at the start, but when you're chopping out bits throughout the video, makes it pretty difficult.

I've done hard with a few series, and the only issue I have is the font size.

[LeXXuz]

But as for the SDR pre-filter, if that is to change the HDR to SDR, I don't want to do that!!


Not at all. It is just for the prefiltering process before handing the prefiltered clip to mvtools. Since mvtools does not support HDR, you need to change your HDR content to SDR with an additional prefilter like DGHDRtoSDR().

If not, mvtools "sees" the prefilter-clip like you would on a SDR screen, with heavily compressed luma and chroma range. Which reduces the accuracy of the motion estimation quite a lot.


Sorry I missed this post, I thought you were referring to the SceneStats issue. Yes this is a bug, only when opacity is 1 in 'blend' mode for TV range sources. It's fixed now.
As for the flicker, are you sure about that? it's a basic 2 clips blends, I forgot to say but you could also do Merge(clip1,clip2,0.5), output should be similar, that means it should not show flicker either.

Thanks Dogway. :)

Well, since you ask me that way, no, I'm not 100% sure anymore. :D
I'll do some more testing on different sources with the fixed ex_blend() and compare it with merge().

[Guest]

Not at all. It is just for the prefiltering process before handing the prefiltered clip to mvtools. Since mvtools does not support HDR, you need to change your HDR content to SDR with an additional prefilter like DGHDRtoSDR().

If not, mvtools "sees" the prefilter-clip like you would on a SDR screen, with heavily compressed luma and chroma range. Which reduces the accuracy of the motion estimation quite a lot.

OK, thanks for the explanation, would you be so kind to provide a example of a call for DGHDRtoSDR() as a pre-filter ??

Wait, what, I think I found it here:-

DGHDRtoSDR as pre filter (https://forum.doom9.org/showthread.php?p=1984264#post1984264)

Something like this :-

pre=DGHDRtoSDR(mode="pq",white=112)
pre2=ex_Median(mode="IQMST",thres=255) or pre2=pre.ex_Median(mode="IQMST", UV=3, thres=255)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,prefilter=pre2,str=1.2,refinemotion=true)
RequestLinear(2*24)
FrameRateConverterMIX(FrameDouble=true)

[coolgit]

Well, all right then :)

Yes, it's not really what I'm after, so maybe Dogway might come up with a solution to my situation. :eek:

I know that re-timing would be reasonably easy with just a trim at the start, but when you're chopping out bits throughout the video, makes it pretty difficult.

I've done hard with a few series, and the only issue I have is the font size.


If you must use .srt instead of .ass then you can use

assrender("filepath and name.srt", scale=1.2, srt_font="verdana")

Scale adjust size of font.


Or use subtitleedit and load srt file and use <font size="10px">Hello World</font>. For each line.

I surmised assrender would be easier.

[Guest]

If you must use .srt instead of .ass then you can use

assrender("filepath and name.srt", scale=1.2, srt_font="verdana")

Scale adjust size of font.


Or use subtitleedit and load srt file and use <font size="10px">Hello World</font>. For each line.

I surmised assrender would be easier.

:thanks::thanks::thanks::thanks: It works a treat ;)

The only problem is you'd have to change the script's subtitle path for EVERY episode, so you could end up with MANY scripts :(

[LeXXuz]

Something like this :-

pre=DGHDRtoSDR(mode="pq",white=112)
pre2=ex_Median(mode="IQMST",thres=255) or pre2=pre.ex_Median(mode="IQMST", UV=3, thres=255)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,prefilter=pre2,str=1.2,refinemotion=true)
RequestLinear(2*24)
FrameRateConverterMIX(FrameDouble=true)

You can only set one prefilter in SMDegrain and the white point is pretty low. Use 400 and adjust from there. That really depends on the source. Str of 1.2 is also quite below recommended default of 5.0.

Try:

pre=ex_Median(mode="IQMST",thres=255).DGHDRtoSDR(mode="pq",white=400)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)
RequestLinear(2*24)
FrameRateConverterMIX(FrameDouble=true)

[Guest]

You can only set one prefilter in SMDegrain and the white point is pretty low. Use 400 and adjust from there. That really depends on the source. Str of 1.2 is also quite below recommended default of 5.0.

Try:

pre=ex_Median(mode="IQMST",thres=255).DGHDRtoSDR(mode="pq",white=400)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)
RequestLinear(2*24)
FrameRateConverterMIX(FrameDouble=true)

Hi LeXXuz,

Yes, I found that out the hard way, but I think I might have got it going, but I removed the DGHDR call, tho, afterwards.

I tried this, not sure if it worked, tho...

pre=DGHDRtoSDR(mode="pq",white=112)
pre2=ex_Median(mode="IQMST",thres=255)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)
SMDegrain(prefilter=pre2)
RequestLinear(2*24)
FrameRateConverterMIX(FrameDouble=true)

But I will definitely try your script suggestion...

:thanks:

Quick Update:-

Just ran your script (only as a quick preview test), but it worked :)

Next thing I'm curious about is, FrameConverter doubles the original FPS, but is there a script/filter that you can enter the FPS you want ???
There probably is, I just haven't found it yet, or forgotten.

[LeXXuz]

Hi LeXXuz,

Yes, I found that out the hard way, but I think I might have got it going, but I removed the DGHDR call, tho, afterwards.

I tried this, not sure if it worked, tho...

pre=DGHDRtoSDR(mode="pq",white=112)
pre2=ex_Median(mode="IQMST",thres=255)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)
SMDegrain(prefilter=pre2)
RequestLinear(2*24)
FrameRateConverterMIX(FrameDouble=true)


That way you would run SMDegrain twice. And the 2nd time with default settings and no HDR to SDR conversion for the prefilter either which would make your first call with those subtle settings pretty much useless.

Also you have quite low thresholds for 4k but use a pretty strong prefilter with IQMST mode of ex_Median.
You may want to balance that a little more. Your low thresholds plus extra refinement will do you no good to preserve fine details if your prefilter is too strong and kills them in the first place.

[Guest]

That way you would run SMDegrain twice. And the 2nd time with default settings and no HDR to SDR conversion for the prefilter either which would make your first call with those subtle settings pretty much useless.

Also you have quite low thresholds for 4k but use a pretty strong prefilter with IQMST mode of ex_Median.
You may want to balance that a little more. Your low thresholds plus extra refinement will do you no good to preserve fine details if your prefilter is too strong and kills them in the first place.

I'm still learning, and open to suggestions :)

[Dogway]

FilmGrain+ (https://github.com/Dogway/Avisynth-Scripts/blob/master/FilmGrain+.avsi)

I've been working on a new filter, that it's not so new. As you know I've been chasing down a good grain filter for some time. First I modded GrainFactory3, later optimized it only to discover ugly artifacts, so I refactored into what got called FilmGrain. It was like trying to fix what was broken as a whole, so I made a new grain filter from the ground up, new concept with 3 goals, good quality, intuitive/easy to use, and performance. Unless you are on UHD for which is slow I would say I achieved what had planned.
It's the first version, and still need to revise a few things here and there, but try to give it a try and give back some feedback. I still need to add a preset system, with more modes than those listed.

The idea is to finally remove the old filters from the repo.

[kedautinh12]

Hope filmgrain+ don't upsize file too much like grainfactory3

[Guest]

So just a quick question about DGHDRtoSDR, as with a lot of DG's stuff, it requires a CUDA device, so that must mean that a user that only has Intel or AMD GPU's can't use it to its full potential ??

impl="sw" - Software mode (very slow).

Is there an alternative ??

[LeXXuz]

Hope filmgrain+ don't upsize file too much like grainfactory3

Depends on the settings I'd say. Most important is imho it survives later compression by the encoder and not only in parts which looks very ugly as a result.

So just a quick question about DGHDRtoSDR, as with a lot of DG's stuff, it requires a CUDA device, so that must mean that a user that only has Intel or AMD GPU's can't use it to its full potential ??

impl="sw" - Software mode (very slow).

Is there an alternative ??

I remember Donald did a thing with z_convert before creating DGHDRtoSDR() but that required quite a lot of trial and error tweaking and is surely not maintained anymore since he released his filter. Don't really know anything else which gives decent results. And I can't recall that software mode was that slow to be honest.

[Dogway]

FilmGrain+ is not for compressibility but for remaster purposes, to regrain ugly sources after a denoising and then encoding at a higher bitrate. Grain can also mask banding and increase perceptual sharpness.

I just updated v1.1 with a benchmark on first page. It's not that bad performance wise, given that it's so more intuitive to use and has higher quality. With PTH=true it reduces speed greatly so something to be aware.

I still need to port a few more presets.

So just a quick question about DGHDRtoSDR, as with a lot of DG's stuff, it requires a CUDA device, so that must mean that a user that only has Intel or AMD GPU's can't use it to its full potential ??
It's a suggestion for a quick tonemap. You can use CPU tonemappers like those in fmtconv or maybe the ones in TransformsPack - Transfers, but they will be considerably slower.

[Guest]

@ LeXXuz & Dogway,

Thanks for your explanations, but there is still an unanswered question...

With FrameConverter, it "only" does double the original frame rate, but is there another option (or possible option for FrameConverter) to be able to process to a user set frame rate ?? eg:- 50, 60 or even higher.

It would be nice to have a "fast" FrameConverter that just does a UHD standard of 60FPS...

:thanks:

[kedautinh12]

Info about DGHDRtoSDR here:
http://avisynth.nl/index.php/DGHDRtoSDR

[Guest]

Info about DGHDRtoSDR here:
http://avisynth.nl/index.php/DGHDRtoSDR

Thanks, I guess that means its nVidia or bust...

[Dogway]

With FrameConverter, it "only" does double the original frame rate(...)

Just curious, why do you spread falseness? Read the script, it supports any target fps.

[Guest]

Just curious, why do you spread falseness? Read the script, it supports any target fps.

I'm so so sorry Dogway... i only noticed the double rate.

Please realise, this is all new to me.

How do I specify what fps I want..eg:- 60fps ?

[Dogway]

Just read a little (https://github.com/Dogway/Avisynth-Scripts/blob/23086eeab07979898024f7eb4143d8084e62d333/MIX%20mods/FrameRateConverterMIX.avsi#L53).
NewNum=60000,NewDen=1000 for your case.

[Guest]

Just read a little (https://github.com/Dogway/Avisynth-Scripts/blob/23086eeab07979898024f7eb4143d8084e62d333/MIX%20mods/FrameRateConverterMIX.avsi#L53).
NewNum=60000,NewDen=1000 for your case.

Hi Dogway, I do read a lot, however, if it's not "staring me in the face", and obvious, then I have no idea what I'm looking for.

If it's any consolation, I sort of thought it might have been that..

Surely you have to realise that to a large % of ppl would just see a sea of numbers, letters & characters when looking at a filter script, but ppl like yourself that kind of "live & breathe" this stuff, it's just second nature.

I know it can be frustrating when having to explain things that you know, "like the back of your hand", to someone that really hasn't got a clue, unless it's really obvious.

That's why I have to ask.

I'm sure there are things that I know, and have learned to do, that you wouldn't have clue where to start...and it's that, that makes everything work.

We're all different.... different skills, knowledge, experience, etc, etc.

Respect!

EDIT:-

Unfortunately, I have run into another annoying issue, that clearly has nothing to do with FrameConverter, it will work for me with FrameDouble=true, but not NewNum=60000,NewDen=1000 :(

[LeXXuz]

Just a fair bit of warning to everyone using DGHDRtoSDR() for the prefilter chain of SMDegrain.

ALWAYS check the whitepoint manually of the prefilter clip with show=true parameter of SMDegrain. The default value of 400 was way too low for 10 out of 10 different HDR films I tested this with.
And with white=112 what I had seen here on some samples the prefilter clip was always almost black. Which means motion estimation is pretty useless as mvtools is only seeing a somewhat "blank" clip.

For all 10 of my tests I ended up with a whitepoint between 1200 and 1800. And I remember the old default value was ~1500. I have no idea why it is set to 400 now.

[Guest]

Just a fair bit of warning to everyone using DGHDRtoSDR() for the prefilter chain of SMDegrain.

ALWAYS check the whitepoint manually of the prefilter clip with show=true parameter of SMDegrain. The default value of 400 was way too low for 10 out of 10 different HDR films I tested this with.
And with white=112 what I had seen here on some samples the prefilter clip was always almost black. Which means motion estimation is pretty useless as mvtools is only seeing a somewhat "blank" clip.

For all 10 of my tests I ended up with a whitepoint between 1200 and 1800. And I remember the old default value was ~1500. I have no idea why it is set to 400 now.

Well, when I was first introduced the DGHDRtoSDR (just the other day), I did a couple of tests with 112, and it seemed OK, but then 400 was suggested, and that was, I thought, even better.
I have been using a Tweak function to reduce the color & increasing the brightness a little, but I think I can do away with that now :)

I will give that show=true parameter a try, and see how I go.

[LeXXuz]

Thanks, I guess that means its nVidia or bust...

You can try DGToneMap to see if it is any faster for you.
http://avisynth.nl/index.php/DGTonemap

It is the older filter I spoke about. But read the docs carefully. It needs more adjustment to your needs than DGHDRtoSDR.

[Guest]

You can try DGToneMap to see if it is any faster for you.
http://avisynth.nl/index.php/DGTonemap

It is the older filter I spoke about. But read the docs carefully. It needs more adjustment to your needs than DGHDRtoSDR.

I was just confirming that DGHDRtoSDR was optimised for nVidia (as most of DG's stuff is), fortunately, I mostly have nVidia's, so it's not an issue for me :)

[Boulder]

Just a fair bit of warning to everyone using DGHDRtoSDR() for the prefilter chain of SMDegrain.

ALWAYS check the whitepoint manually of the prefilter clip with show=true parameter of SMDegrain. The default value of 400 was way too low for 10 out of 10 different HDR films I tested this with.
And with white=112 what I had seen here on some samples the prefilter clip was always almost black. Which means motion estimation is pretty useless as mvtools is only seeing a somewhat "blank" clip.

For all 10 of my tests I ended up with a whitepoint between 1200 and 1800. And I remember the old default value was ~1500. I have no idea why it is set to 400 now.
I've used the filter default, which is 2000. The Avisynth wiki doesn't seem to have the latest information (v1.15-based) updated.

[anton_foy]

Thanks for Filmgrain+!
If you like I can provide to you 3k scans from various filmstocks in 10-bit dpx. format if you want to mimic the grain. They are just color charts but maybe I have some real life images too. It seems many of the filmstocks grain is less in the red channel. Maybe because the focus when developing the filmtypes was on clean skin tones and textures.

[Dogway]

So what would be a "safe" default to recommend in SMDegrain for DGHDRtoSDR? I set 59 because it worked for one or two cases (around 100 also) but now I'm not sure. Maybe the filter was asking for the reference white and not peak white?
Thanks for Filmgrain+!
If you like I can provide to you 3k scans from various filmstocks in 10-bit dpx. format if you want to mimic the grain. They are just color charts but maybe I have some real life images too. It seems many of the filmstocks grain is less in the red channel. Maybe because the focus when developing the filmtypes was on clean skin tones and textures.
Thanks! Just in time, next update will be re-matching the presets I've done and do the new ones. I prefer plates over grey background because I can study the amplitude and some other aspects better, but ultimately I will cross check with actual film content, so I guess color charts are perfect.
It's not only the film "brand" but within it there are several ISO so my concern is to mimic the shape of the grain, while ISO can be replicated with strength ('str' arg). Next week I will post an example for regraining a clip on scene basis. Instead of adding the filter inside ScriptClip I will add 4 examples at different strengths outside, and depending on a denoise metric, choose either one within ScriptClip.

I need a few frames at least for each stock to appreciate the temporal perception of grain, not only static grain shape. Specially the rarer Kodak ones and also some digital ones, like digital RED, GoPro, Alexa, whatever... Positive film prints also welcome.

[anton_foy]

Thanks! Just in time, next update will be re-matching the presets I've done and do the new ones. I prefer plates over grey background because I can study the amplitude and some other aspects better, but ultimately I will cross check with actual film content, so I guess color charts are perfect.
It's not only the film "brand" but within it there are several ISO so my concern is to mimic the shape of the grain, while ISO can be replicated with strength ('str' arg). Next week I will post an example for regraining a clip on scene basis. Instead of adding the filter inside ScriptClip I will add 4 examples at different strengths outside, and depending on a denoise metric, choose either one within ScriptClip.

I need a few frames at least for each stock to appreciate the temporal perception of grain, not only static grain shape. Specially the rarer Kodak ones and also some digital ones, like digital RED, GoPro, Alexa, whatever... Positive film prints also welcome.

Yes I believe there are a few frames in sequence but Im not sure how large the patches are on the color chart. Have to dig out the harddrive and sort the files out first. I think I have red epic footage aswell if lucky. Kodak 5219, 5213, 5217, 5207, fuji 8543, 8546, 8588, 8552 and more I think but let me see so I have them all in the same place or I need to search some more.

Edit: when I experimented to mimic the filmgrain I found that temporal movement got close to the real thing when generating it in about 8k size and then downsize and adding blur then sharpen. But this is tedious and time consuming for a script. Your solution looks much more efficient.

[Dogway]

Thank you! Yes 5213 is one of the rarer just like 5201. Also the Fuji I think, have no experience with them. You can PM me as I have one PM slot still.

[LeXXuz]

So what would be a "safe" default to recommend in SMDegrain for DGHDRtoSDR? I set 59 because it worked for one or two cases (around 100 also) but now I'm not sure. Maybe the filter was asking for the reference white and not peak white?

Difficult to set a default value I think. Highly depends on how the source was mastered. I tested this with this UHD Blu-ray just yesterday. Film is just mastered in SMPTE ST2086 HDR-10.

from Mediainfo:

Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0050 cd/m2, max: 1000 cd/m2

from DGIndex:

DEPTH 10
CHROMA_LOCATION 2
ASPECT 1 1
COLORIMETRY 9 16 9
IS_444 0

MASTERING 13250 34500 7500 3000 34000 16000 15635 16450 10000000 50

If I run DGHDRtoSDR() with white=400 on this one, the prefilter clip is very dark with no more details in the blacks. With white=100 and below it's almost entirely black.
I set it to 1500 which showed me a good balance between fine nuances still visible in deepest blacks and highest whites. My desk monitors are calibrated with SpyderX.

So far I did not come across anything outside of 1200-1800 range. That doesn't mean the next one could be outside that range, of course. :D

[anton_foy]

Thank you! Yes 5213 is one of the rarer just like 5201. Also the Fuji I think, have no experience with them. You can PM me as I have one PM slot still.

I found some files! I actually have from 5201 too but only in 2k. And the ones in 3k are only photographed with a still camera som the grain size is not accurate to super35 then. But I will send you it is 4.5gb in size. Any suggesion for uploading service that is free? Maybe I can buy extra for my google drive otherwise but that will be in a few days then.

[Dogway]

Difficult to set a default value I think. Highly depends on how the source was mastered.
It's only as a loose guidance, as 59 seemed to be way off... I guess 1500 will do right?
I found some files! I actually have from 5201 too but only in 2k. And the ones in 3k are only photographed with a still camera som the grain size is not accurate to super35 then. But I will send you it is 4.5gb in size. Any suggesion for uploading service that is free? Maybe I can buy extra for my google drive otherwise but that will be in a few days then.
Anything helps, I will also do some hunting and guess from everything I check. I have some gizmos (addons) in Nuke but for some reason they look horrible, more like salt & pepper noise than actually grain and by the looks of it I think grain is better applied in an opponent color model like YCbCr.
Maybe send me one of the 3K shots first, because being photographed instead of scanned might not be sufficient. You can upload to Drive if you have an unused account, OneDrive, Mega... Mediafire has 1Gb upload limit for no accounts.

[anton_foy]

It's only as a loose guidance, as 59 seemed to be way off... I guess 1500 will do right?

Anything helps, I will also do some hunting and guess from everything I check. I have some gizmos (addons) in Nuke but for some reason they look horrible, more like salt & pepper noise than actually grain and by the looks of it I think grain is better applied in an opponent color model like YCbCr.
Maybe send me one of the 3K shots first, because being photographed instead of scanned might not be sufficient. You can upload to Drive if you have an unused account, OneDrive, Mega... Mediafire has 1Gb upload limit for no accounts.

No all of them are scanned by Scanity scanner but only the 2k ones are filmed by a 35mm film camera while the 3k ones are from film stocks used in a analog still photography camera. So all of them are scanned but the area from the still camera negative differs in area and therefor resolution from the film camera ones are only 2k.

Edit: to clarify, all of them are scanned with the Scanity scanner. And some I realized are in 16bt rather than 10 bit.

Edit 2: I found also grey plates with grain in 4k that I bought but mostly bad compression artifacts yet I can send you these too.

[Dogway]

Well maybe, I think there's more value in 4K than 2K if it's not severely harmed because downscaling (or sampling at 1080) changes the grain structure. Anyway I don't need the full loop, one second or maybe less is enough, if it's intra only you can trim them. As for analog still photography film stock, for the time being I'm not going to work on them, have many thing piled to do on many fronts so want to finish this filter ASAP.

[anton_foy]

Well maybe, I think there's more value in 4K than 2K if it's not severely harmed because downscaling (or sampling at 1080) changes the grain structure. Anyway I don't need the full loop, one second or maybe less is enough, if it's intra only you can trim them. As for analog still photography film stock, for the time being I'm not going to work on them, have many thing piled to do on many fronts so want to finish this filter ASAP.

This was scanned 9 years ago so 2k was the only alternative then. The film stock from still photography is actually the motion picture film stocks just using a still camera instead of a motion picture camera. Just to clarify. No still film stocks used at all.

Edit: sorry about the confusion, the "analog still camera" scans that are 3k and the "film camera" scans in 2k. Only "motion picture film stocks used" for both cameras.

[LeXXuz]

It's only as a loose guidance, as 59 seemed to be way off... I guess 1500 will do right?


I think that'll be okay as a starting point. Maybe add this as a global parameter and the hint that it should be controlled via the prefilter preview and adjusted for best results?

[Guest]

I'm sure this has been asked before, but what's the different between the (similarly named) filters in the EX mods & MIX mods ?

Another question, what's the difference or advantages/disadvantages (if any) between using ConvertFPS(), to FrameRateConverter() ?

[kedautinh12]

Ex mods mean Dogway trans to use Ex_functions complete and mix mods mean Dogway almost trans to use ex_finction (not complete)

[Dogway]

EX mods use minimum dependency plugins and try to use EX functions where possible, this makes it more compatible with other OSes and you can edit or fix the functions if you want.
MIX mods use a mix of EX functions and external plugins to maximize speed so they are about 15%-20% faster than EX mods, but have more plugin dependencies.

I don't remember much about ConvertFPS() but I think it simply blend frames whereas FrameRateConverter() interpolates (generates) new frames. Asd-g ported RIFE to avs+ so now you can also use RIFEwrap to interpolate frames with higher quality.

[Guest]

EX mods use minimum dependency plugins and try to use EX functions where possible, this makes it more compatible with other OSes and you can edit or fix the functions if you want.
MIX mods use a mix of EX functions and external plugins to maximize speed so they are about 15%-20% faster than EX mods, but have more plugin dependencies.

I don't remember much about ConvertFPS() but I think it simply blend frames whereas FrameRateConverter() interpolates (generates) new frames. Asd-g ported RIFE to avs+ so now you can also use RIFEwrap to interpolate frames with higher quality.

Thankyou for the great explanation(s).

So that would explain why ConvertFPS() is somewhat faster than FrameConverter()...and I've heard that RIFE functions can be slow, too :(

The RIFEWrap() calls are VERY similar to FrameConverter() calls...

You probably don't want to hear this, but Handbrake does pretty good frame conversions, but being a "closed" app, there's no way to know exactly what its process is :(

UPDATE:-

I tried a RIFEWrap script, and I got some strange errors:-

vkAllocateMemory failed -2

vkQueueSubmit failed -4

I'd suggest that these have something to do with Vulkan.

I'm using a RTX 3060, with "normal" current drivers...

I changed the gpuid from 0 to -1 in Resizers.avsi, but didn't make any difference.

I tried RIFEWrap another way, and only got a black screen with audio and a VERY low video bitrate.

[poisondeathray]

You probably don't want to hear this, but Handbrake does pretty good frame conversions, but being a "closed" app, there's no way to know exactly what its process is :(

Handbrake is open source
https://github.com/HandBrake

HB drops and duplicates frames to achieve the desired framerate for it's framerate conversions

In avisynth lingo - it uses a "ChangeFPS" style conversion. Ie. ChangeFPS(numerator, denominator)

[Guest]

Handbrake is open source
https://github.com/HandBrake

HB drops and duplicates frames to achieve the desired framerate for it's framerate conversions

In avisynth lingo - it uses a "ChangeFPS" style conversion. Ie. ChangeFPS(numerator, denominator)

Well by "closed" I meant that afaik you can't access, edit or preview ANY of the filters or scripts...

Correct me if I'm wrong....I don't use it regularly.

I just tested, it's actually ChangeFPS(60000,1000), doesn't need the num & den, it seems.

But then ConvertFPS(60)

[poisondeathray]

Well by "closed" I meant that afaik you can't access, edit or preview ANY of the filters or scripts...

Correct me if I'm wrong....I don't use it regularly.

I don't really use it either. I just tested HandBrakeCLI to assess the claim "Handbrake does pretty good frame conversions".

[Guest]

I don't really use it either. I just tested HandBrakeCLI to assess the claim "Handbrake does pretty good frame conversions".

OK, I use the GUI, I "hate" CLI :(

[poisondeathray]

I just tested, it's actually ChangeFPS(60000,1000), doesn't need the num & den, it seems.

But then ConvertFPS(60)


You can use ChangeFPS(60) ... if you meant 60/1 . 60 is the numerator, 1 is the denominator (den can be omitted in that case, because the default value for den is 1) . When you have "59.94" , it's actually an abbreviation of the real number. It's really ChangeFPS(60000,1001), and you do need to specify both


OK, I use the GUI, I "hate" CLI :(


AFAIK, there is no "live" preview in the GUI either

[poisondeathray]

UPDATE:-

I tried a RIFEWrap script, and I got some strange errors:-

vkAllocateMemory failed -2

vkQueueSubmit failed -4

I'd suggest that these have something to do with Vulkan.

I'm using a RTX 3060, with "normal" current drivers...

I changed the gpuid from 0 to -1 in Resizers.avsi, but didn't make any difference.

I tried RIFEWrap another way, and only got a black screen with audio and a VERY low video bitrate.


Those are likely out of memory errors. What were your source video dimensions ? Try a small test on a SD video. If it "works", you have your answer

[Guest]

Those are likely out of memory errors. What were your source video dimensions ? Try a small test on a SD video. If it "works", you have your answer

Will do, but I was using 4K HDR10...

UPDATE:-

Well, you were right :)

So, would it be system memory, or GPU memory ??

I've got 32Gb DDR5, and 8Gb GPU....

Shame that changing the gpuid didn't help :(

[poisondeathray]

Will do, but I was using 4K HDR10...

UPDATE:-

Well, you were right :)

So, would it be system memory, or GPU memory ??

I've got 32Gb DDR5, and 8Gb GPU....

Shame that changing the gpuid didn't help :(



GPU memory, but 8GB should be enough for UHD. Make sure you're not consuming GPU memory in other processes

RIFE also has a UHD mode (uhd=true) which reduces memory usage, but I don't think it's implemented in Dogway's wrapper version

[Guest]

GPU memory, but 8GB should be enough for UHD. Make sure you're not consuming GPU memory in other processes

RIFE also has a UHD mode (uhd=true) which reduces memory usage, but I don't think it's implemented in Dogway's wrapper version

Interesting, hopefully Dogway will read this :)

Thanks for your help :)

UPDATE:-

Was just looking thru the RIFE docs, and there is indeed a UHD model...it's #2.

I added it to the call, but it still has those same memory errors :(

RIFEwrap(model=2,FrameNum=60000,FrameDen=1000)

RIFE Wiki (http://www.avisynth.nl/index.php/RIFE)

### Usage:

```
RIFE(clip input, int "model", int "factor_num", int "factor_den", int "fps_num", int "fps_den", string "model_path", int "gpu_id", int "gpu_thread", bool "tta", bool "uhd", bool "sc", float "sc_threshold", bool "skip", float "skip_threshold", bool "list_gpu")
```

### Parameters:

- input\
A clip to process.\
It must be in RGB 32-bit planar format.

- model\
Model to use.\
`models` must be located in the same folder as RIFE.dll.\
Some of the models have two versions: speed oriented (ensemble=False / fast=True) and quality oriented (ensemble=True / fast=False).\
0: rife\
1: rife-HD\
2: rife-UHD\
3: rife-anime\
4: rife-v2\
5: rife-v2.3\
6: rife-v2.4\
7: rife-v3.0\
8: rife-v3.1\
9: rife-v4 (ensemble=False / fast=True)\
10: rife-v4 (ensemble=True / fast=False)\
11: rife-v4.1 (ensemble=False / fast=True)\
12: rife-v4.1 (ensemble=True / fast=False)\
13: rife-v4.2 (ensemble=False / fast=True)\
14: rife-v4.2 (ensemble=True / fast=False)\
15: rife-v4.3 (ensemble=False / fast=True)\
16: rife-v4.3 (ensemble=True / fast=False)\
17: rife-v4.4 (ensemble=False / fast=True)\
18: rife-v4.4 (ensemble=True / fast=False)\
19: rife-v4.5 (ensemble=False)\
20: rife-v4.5 (ensemble=True)\
21: rife-v4.6 (ensemble=False)\
22: rife-v4.6 (ensemble=True)\
23: sudo_rife4 (ensemble=False / fast=True) (custom model)\
24: sudo_rife4 (ensemble=True / fast=False) (custom model)\
25: sudo_rife4 (ensemble=True / fast=True) (custom model)\
Default: 5.

- factor_num, factor_den\
Factor of target frame rate.\
For example `factor_num=5, factor_den=2` will multiply input clip FPS by 2.5.\
Only rife-v4 model supports custom frame rate.\
Default: 2, 1.

- fps_num, fps_den\
Target frame rate.\
Only rife-v4 model supports custom frame rate.\
Supersedes `factor_num`/`factor_den` parameter if specified.\
Default: Not specified.

- model_path\
RIFE model path.\
Supersedes `model` parameter if specified.\
Default: Not specified.

- gpu_id\
GPU device to use.\
By default the default device is selected.

- gpu_thread\
Thread count for interpolation.\
Using larger values may increase GPU usage and consume more GPU memory. If you find that your GPU is hungry, try increasing thread count to achieve faster processing.\
Default: 2.

- tta\
Enable TTA(Test-Time Augmentation) mode.\
Default: False.

- uhd\
Enable UHD mode.\
Default: False.

- sc\
Avoid interpolating frames over scene changes.\
Default: False.

- sc_threshold\
Threshold to determine whether the current frame and the next one are end/beginning of scene.\
Must be between 0.0..1.0.\
Default: 0.12.

- skip\
Skip interpolating static frames.\
Requires [VMAF](https://github.com/Asd-g/AviSynth-VMAF) plugin.\
Default: False.

- skip_threshold\
PSNR threshold to determine whether the current frame and the next one are static.\
Must be between 0.0..60.0.\
Default: 60.0.

- list_gpu\
Simply print a list of available GPU devices on the frame and does no interpolation.\
Default: False.

[Dogway]

@FTLOY: Added support for UHD in RIFEwrap (link (https://github.com/Dogway/Avisynth-Scripts/blob/master/ResizersPack.avsi)), anyway whatever issues you ever have while working with UHD, blame first the resolution because avisynth tools and hardware (8Gb VRAM mostly) are not ready for this.

[Guest]

@FTLOY: Added support for UHD in RIFEwrap (link (https://github.com/Dogway/Avisynth-Scripts/blob/master/ResizersPack.avsi)), anyway whatever issues you ever have while working with UHD, blame first the resolution because avisynth tools and hardware (8Gb VRAM mostly) are not ready for this.

Thankyou very much, I will see how I go, and maybe I'll have to get a better GPU, but that all depends on the "performance", I guess.

[Guest]

I hope this isn't off thread topic...

Just curious about what these scripts actually do...

z_ConvertFormat(colorspace_op="709:709:709:full=>2020:2020:2020:full")

Does this "just" change the picture characteristics (meaning what it looks like), as they don't seem to change the info shown in MediaInfo.

I have noticed that using the above script, that the clip is still shown to be BT709.

There's also Colormatrix scripts, and some LUT's, but they again, only seem to change what the video "looks like".

Is there a specific script or filter that will actually change the BTxxxx info ?

[Dogway]

Yes, it's a bit offtopic, ask them directly. I made ConvertFormat() because z_ConvertFormat() is intelligible to me, they use strange naming conventions and has some limits.
Sometimes if I urge performance for a project I do some research to find the correct call but for the day to day I use TransformsPack.

[Guest]

Yes, it's a bit offtopic, ask them directly. I made ConvertFormat() because z_ConvertFormat() is intelligible to me, they use strange naming conventions and has some limits.
Sometimes if I urge performance for a project I do some research to find the correct call but for the day to day I use TransformsPack.

I have quickly (using search) read thru all the TransFormsPacks, and can't see a particular reference to a BT709 to BT2020 conversion.

I would doubt that a z_convertformat script would work with yours.

Any suggestions ??

[DTL]

Is there a specific script or filter that will actually change the BTxxxx info ?

MediaInfo only display manually defined metadata in some container (or may be some more RAW stream somehow formatted). The data encoding numbers itself are 'virtual' math objects and not have any application-specific properties itself. So using only RAW image encoding dataset it is not possible to found encoding rules. And also what essence do this dataset encodes too.

User must keep in mind image encoding rules when processing in AVS scripting at each step.

You typically set metadata in the MPEG-encoder input settings to define some specific metadata in standard fields for MPEG-formatted stream.

[Dogway]

I haven't made docs for ConvertFormat but arguments seem self-explanatory enough.
ConvertFormat(cs_in="709",cs_out="2020")

This will rewrite frameprops, not sure about Mediainfo, that has more to do with x264 or the encoder you use.

[DTL]

2020 may use cl and non-cl matrix. non-cl typically larger used in broadcasting ? What matrix expected in ConvertFormat(cs_out="2020") ?

"z_ConvertFormat(colorspace_op="709:709:709:full=>2020:2020:2020:full")"

It converts colour image encoding rules from 709 transfer/matrix/primaries to 2020 transfer/matrix/primaries using non-cl matrix. Because 2020 for matrix is naming alias to 2020ncl. Also 2020-transfer is sort of non-exist item - it is about same as 709/sRGB transfer. So in z_ConvertFormat 2020-transfer is alias to 2010_10 - may be simple convert anything to 10bit 709/sRGB transfer ? So if you need some HDR you need to define some other transfer. BT.2020 is about WCG mostly.

So pure 2020-system is WCG SDR. May be very rarely used.

[poisondeathray]

RIFE with SDR UHD test src works ok for me (Rifewrap works ok too) , and GPU-z shows ~2.5 - 3 GB GPU mem consumption during preview or avsmeter script.avs -gpu . Different models take slightly more or less , but it should be easily "doable" with 8GB GPU mem. Check that other processes are not concurrently consuming GPU memory.

If you use RIFE(list_gpu=true), it will tell you the id numbers. Or you can check with GPU-z while running the test RIFE SD script that works to see if the correct GPU is being used by that id, maybe something is mapped incorrectly in your system


I would doubt that a z_convertformat script would work with yours.


It works . It changes both the avs props and the actual video values. If you use ffmpeg libx265 , it will pass the props directly to the encode instead of you having to manually set them in the encoder

[Dogway]

2020 is a shorthand for 2020NCL which is the most common one used, but you can explicitly define 2020CL or 2020NCL. Anyhow I haven't implemented model conversion yet so I think CL is not currently possible from ConvertFormat. You still have the function in TransformsPack - Models. You can see what's going on with show=true panel.

The concept of "matrix" is ill-formed, it was born when most of the model conversions could be done via a matrix transform, like between YCbCr/YPbPr and RGB, or YUV, or YIQ, etc. Now this is not the case, you can't convert to YcCbcCrc with a single 3x3 matrix, and the same applies to IPT, OkLab, and if I'm not wrong to YCoCg nor YUVr.

Also you don't want 709 transfer if working with delivery formats, for example if you are working with a Bluray source you want 1886 transfer which is the same 2020 uses as standard.

[DTL]

"you can't convert to YcCbcCrc with a single 3x3 matrix,"

Matrix of output is required param for decoder to de-matrix data into RGB for display (typically for non-RGB and chroma-subsampled systems). The way format converter perform conversion between input image encoding rules to required target may be very complex (like converting first to some 'generic colour space' like XYZ ? ).

The real only point of having any metadata with image compressed/encoded dataset is only to instruct display/decoder to show proper physical image. Or may be next format converter. Matrix not required for 4:4:4 RGB or other direct primary encoded datasets and 'transfer' sort of non-required for linear transfer systems. Mostly required is 'primaries' as the only physical conversion from math values to viewer-oriented colours.

[Dogway]

So today I added a few options to FilmGrain+, a skin mask to lower the effect on faces, and emulsion artifact which happens on the U channel as yellow stains.
Here is a comparison, it also shows 'bump' and Path to White:
FilmGrainPlus(str=1.2,size=1.0,sharpness=0.4,mode="log",bump=0.1,skin=0.7)

http://i.imgur.com/kJbde9yl.png (https://i.imgur.com/kJbde9y.png)
http://i.imgur.com/MkkyUXvl.png (https://i.imgur.com/MkkyUXv.png)

[Guest]

@FTLOY: Added support for UHD in RIFEwrap (link (https://github.com/Dogway/Avisynth-Scripts/blob/master/ResizersPack.avsi)), anyway whatever issues you ever have while working with UHD, blame first the resolution because avisynth tools and hardware (8Gb VRAM mostly) are not ready for this.

I tried the "new" RIFEWrap, and it works OK with anything up to, and including 1080p, but I think like you said, maybe it's not ready for UHD HDR10.

I'm still getting these errors that pdr suggested were GPU memory issues..

vkAllocateMemory failed -2

vkQueueSubmit failed -4

However, I'm wondering if its an issue with the Ryzen 7950X having an iGPU, and maybe it's using that instead of the RTX 3060.

Is this call all I need ? :-

RIFEwrap(model=2,FrameNum=60000,FrameDen=1000)

Would adding this be of any benefit ??

- gpu_thread\
Thread count for interpolation.\
Using larger values may increase GPU usage and consume more GPU memory. If you find that your GPU is hungry, try increasing thread count to achieve faster processing.\
Default: 2.

[poisondeathray]

I tried the "new" RIFEWrap, and it works OK with anything up to, and including 1080p, but I think like you said, maybe it's not ready for UHD HDR10.

I'm still getting these errors that pdr suggested were GPU memory issues..

vkAllocateMemory failed -2

vkQueueSubmit failed -4

However, I'm wondering if its an issue with the Ryzen 7950X having an iGPU, and maybe it's using that instead of the RTX 3060.

Is this call all I need ? :-

RIFEwrap(model=2,FrameNum=60000,FrameDen=1000)


Try gpuid=1


RIFEwrap(model=2,FrameNum=60000,FrameDen=1000,gpuid=1)

[Guest]

I haven't made docs for ConvertFormat but arguments seem self-explanatory enough.
ConvertFormat(cs_in="709",cs_out="2020")

This will rewrite frameprops, not sure about Mediainfo, that has more to do with x264 or the encoder you use.

I also tried this, and not sure of the results, and MediaInfo still showed the BT709 of the test clip.

But strangely enough, I ran it thru Handbrake, and chose the Colourspace setting of BT2020, and MediaInfo then showed it to be BT2020...

Some basic info from the log of HB:-

"Settings": {
"desat": "0",
"matrix": "bt2020ncl",
"primaries": "bt2020",
"tonemap": "hable",
"transfer": "bt2020-10"
}

[Guest]

Try gpuid=1


RIFEwrap(model=2,FrameNum=60000,FrameDen=1000,gpuid=1)


Unfortunately, I get this error:-

RIFE:invalid GPU device

and referring to Resizers Pack Line 633 (https://github.com/Dogway/Avisynth-Scripts/blob/master/ResizersPack.avsi#L633)

[LeXXuz]

You should easily be able to spot which GPU is used by watching VRAM usage in task manager. Even if your script won't start because it can't allocate enough mem, should be able to see which GPU mem gets used up. Either your RTX or your iGPU.

And if you want to play it safe and don't need the iGPU you can disable it in the BIOS of any AM5 board. :)

[DTL]

"I'm still getting these errors that pdr suggested were GPU memory issues..
vkAllocateMemory failed -2
vkQueueSubmit failed -4"

You need to start from 1 AVS thread only - set Prefetch(1) as the global script param (end of script) and check if no other scripts (includes ?) uses more threads.

[Dogway]

I also tried this, and not sure of the results, and MediaInfo still showed the BT709 of the test clip.

As I said before, it's an encoder thing. Whether it supports frameprops or not, or if it's overriding what's stated in frameprops.

If you don't have control of the whole pipeline you get things like this where it would be most useful to ask to HandBrake devs.

[anton_foy]

So today I added a few options to FilmGrain+, a skin mask to lower the effect on faces, and emulsion artifact which happens on the U channel as yellow stains.
Here is a comparison, it also shows 'bump' and Path to White:
FilmGrainPlus(str=3.2,size=1.0,sharpness=0.4,mode="log",bump=0.1,skin=0.7)

http://i.imgur.com/kJbde9yl.png (https://i.imgur.com/kJbde9y.png)
http://i.imgur.com/MkkyUXvl.png (https://i.imgur.com/MkkyUXv.png)

Very good I like it alot! But why is the grained image so much softer/blurrier than the original?

[Dogway]

Yes, I knew this would come up :D

Grain is detail, and depending on the amount of grain it defines the detail of the image. I've doing my research and did a reparametrization of the blur depending on several factors like 'sharpness' and 'str' but also resolution. In the last version since I knew many would argue I converted 'preblur' to a float type, so you can type 0.5 for half the blur effect, just mind you, it would look unnatural.

Have a look at this video (https://youtu.be/Vv7lB7n1Fak?t=391).

Also reading some studios apply different grain strength to faces, so I added a quick skin mask and you can lower the effect on faces with the 'skin' arg. Also looks like the red channel has typically the less grain so I added a bit more blur to the V plane.

I will now complete the presets I have samples of. I also want to optimize the LMH code block (lo, mid, hi) but kinda don't want headaches right now.
Also refactored Vignette() in GradePack, so it goes well with this for a vintage look.

[anton_foy]

Yes, I knew this would come up :D

Grain is detail, and depending on the amount of grain it defines the detail of the image. I've doing my research and did a reparametrization of the blur depending on several factors like 'sharpness' and 'str' but also resolution. In the last version since I knew many would argue I converted 'preblur' to a float type, so you can type 0.5 for half the blur effect, just mind you, it would look unnatural.

Have a look at this video (https://youtu.be/Vv7lB7n1Fak?t=391).

Also reading some studios apply different grain strength to faces, so I added a quick skin mask and you can lower the effect on faces with the 'skin' arg. Also looks like the red channel has typically the less grain so I added a bit more blur to the V plane.

I will now complete the presets I have samples of. I also want to optimize the LMH code block (lo, mid, hi) but kinda don't want headaches right now.
Also refactored Vignette() in GradePack, so it goes well with this for a vintage look.

Oh yes I am with you. This video is the Dehancer plugin, I have tried it and it is ok but some things (halation and softening mostly) is not correct IMHO. I made a script for the softening effect here in Avisynth which mimics without actually sacrificing the details. Merely softens instead of blur them away. Can post it for demonstration.
Been scanning 35 and 16mm film for years and there is usually more details than what is shown in the dehancer video but it depends on the scanner alot. Used first Spirit 2k then Scanity (up to 4k+).

Edit: btw. up and running again so tonight I will upload the grain-scans to you.

[Guest]

@ Dogway,

Can you please comment to my earlier question (in the Red text)

post1985770 (https://forum.doom9.org/showthread.php?p=1985770#post1985770)

[Dogway]

Would adding this be of any benefit ??

- gpu_thread\
Thread count for interpolation.\
Using larger values may increase GPU usage and consume more GPU memory. If you find that your GPU is hungry, try increasing thread count to achieve faster processing.\
Default: 2.

You can try several things if you look into the original plugin repo (https://github.com/Asd-g/AviSynthPlus-RIFE).
For example skip=true, but as it says it requires the VMFA plugin, and maybe raising gpu_thread, default for HD is 4, maybe try with 6 or 8 but I don't recall it making a change...

I made a script for the softening effect here in Avisynth which mimics without actually sacrificing the details. Merely softens instead of blur them away. Can post it for demonstration.
Yes please, I have no hands on experience on this, just digital. I could use ex_unsharp to blur other frequencies so it has more like a dreamy look and not a plain blur as you state. Maybe, I'm not sure, I could try to calculate standard deviation of the grain and then pass that to the blur so it's more accurate so to speak instead of a visual setting.

[Guest]

You can try several things if you look into the original plugin repo (https://github.com/Asd-g/AviSynthPlus-RIFE).
For example skip=true, but as it says it requires the VMFA plugin, and maybe raising gpu_thread, default for HD is 4, maybe try with 6 or 8 but I don't recall it making a change...

OK, but is gpu_thread something that might need to be enabled in your wrapper, like the rife-UHD the other day ??

I added it the call, and it said it could find it...

[Dogway]

gpu_thread is not exposed, I'm not sure what it does exactly because I didn't get better performance for HD above 4 threads on my card, so YMMV, that's why.
Try different values and see what works for you.

[Guest]

gpu_thread is not exposed, I'm not sure what it does exactly because I didn't get better performance for HD above 4 threads on my card, so YMMV, that's why.
Try different values and see what works for you.

I'm confused, how do I use it then ??

Were you using 4K video, and your GTX 1070 probably hasn't got much vram (unless you've updated recently)

[Dogway]

The 1070 has 8Gb, it's ngreedia who hasn't updated recently, well yeah, you can get a 4070 for the price of a xx80.

I meant it's not exposed in RIFEwrap, but simply look into the function and edit the argument and change here (https://github.com/Dogway/Avisynth-Scripts/blob/02981ad98eecfc4014932f9be51e0b9d5648a3ff/ResizersPack.avsi#L633) the gpu threads you want.

[Guest]

The 1070 has 8Gb, it's ngreedia who hasn't updated recently, well yeah, you can get a 4070 for the price of a xx80.

I meant it's not exposed in RIFEwrap, but simply look into the function and edit the argument and change here (https://github.com/Dogway/Avisynth-Scripts/blob/02981ad98eecfc4014932f9be51e0b9d5648a3ff/ResizersPack.avsi#L633) the gpu threads you want.

Wouldn't have a clue what to do with this...

gpu_thread=isHD ? 4 : 2

Would it be gpu_thread=2 (or 4) ??

I think I might have mentioned this before, I just don't understand "code", it's just letters & numbers to me :(

[anton_foy]

I must say that you made an amazing effort and the results are GREAT with filmgrain+! Trying to figure out your script as I go home from work here on the subway, how is vstcanny actually meant to be used here? The red channel may be faster reduced by just a simple merge call? Just a thought. It is very realistic looking and a very thougth through script. Await one hour and I will upload the scans:)

[Dogway]

I'm currently dealing with the blue/red channel and trying a few things.
I already ported 5248 which is/was a famous stock and also 5279.

What happens is what's described in the charts but at a higher level, blue channel (U plane roughly in this case) is VERY noisy while the red channel is remnant, barely noisy.

Doing things now by plane complicates matters and I'm not sure the results are quite there since we are working in YUV and more importantly, the grain is now decorrelated so we lose the nice white spots/grains.

I think I will leave chroma grain as it is, unless you are inspecting on a grey plate chroma grain is barely noticeable, less so with path to white.

On the vstcanny line, I use it for gaussian blur, the filter was designed for TCanny edge detection but its mode=-1 (gaussian blur) is actually the more performant gaussian blur you can find in AVS+ if you omit removegrain(12) for a gaussian blur of 0.707 and ex_gaussianblur() for big sigmas. The expression in it is only layered expressions, it's not a multi-regression or anything, I tried to plot it in 3D yesterday without success.

The core concept of the filter is replicating grain behaviour on the visual system, by integrating it, that is the lower the 'size' the higher resolution the original grain plate is, then I downscale. Probably this, along 'log' space and the Path to White is what makes it work, preblurring also though.

I'll have a look at your samples tomorrow and implement them.

[anton_foy]

Here is my soft "hack", it may be tweaked for different resolutions etc. but a base of what I use.

u=last

#Soften
blr = ex_expand(mode="disk",thres=120).removegrain(20).ex_levels(0,0.96,255)
merge(u.sharpen(0.2),blr, 0.52)

interleave(u,last)

Edit: I could not find the script I used before that was much more complex so hacked this together yesterday from memory. Also did you get my PM Dogway? A little bit of a mess of files but maybe first look into "imsc" folder.

[Guest]

Could someone recommend a good filter to remove color banding.?

For removing (or improving at least) the banding you get in foggy, dark or some underwater scenes.

[Dogway]

Edit: I could not find the script I used before that was much more complex so hacked this together yesterday from memory. Also did you get my PM Dogway? A little bit of a mess of files but maybe first look into "imsc" folder.

Yes thank you! Just downloaded and was sorting the names. Only checked a few of thems but I think you got 2 "Eterna Vivid 8543 160T" samples and 2 "Eterna 8563 250D" samples (the one called ET250D_GR), I see they are samples for shooting with an exposure fade, so only a few frames are useful where exposure is balanced, also there's a big cast to green, so not sure I can pull chroma grain detail from there but I think it will come useful anyways. Most are Fuji and among the Kodaks all are already done except 5201 and 5212, 5205 is not in my list maybe cause it was short lived or something.

I liked your soften example, but maybe I don't know it starts to get into the dilation realm, which is not bad at all but it pertains more into compositing rather than restoration, as denoised movies already have all the camera and lens flaws.

It can be approximated without the dilation with:
ex_unsharp(-0.4,Fc=width()/1.5)
And with the dilation, it's the same but in one call, presumibly faster but in reality slower, not sure why:
ex_luts(mode="max",pixels=ex_shape(1,mode="disk"),exprf=" dup x - abs 5 > swap range_max / 1.05 ^ range_max * x ?").removegrain(20)

@FTLOY: Try GradFun3plus/SmoothGradPlus

[anton_foy]

Yes thank you! Just downloaded and was sorting the names. Only checked a few of thems but I think you got 2 "Eterna Vivid 8543 160T" samples and 2 "Eterna 8563 250D" samples (the one called ET250D_GR), I see they are samples for shooting with an exposure fade, so only a few frames are useful where exposure is balanced, also there's a big cast to green, so not sure I can pull chroma grain detail from there but I think it will come useful anyways. Most are Fuji and among the Kodaks all are already done except 5201 and 5212, 5205 is not in my list maybe cause it was short lived or something.

I liked your soften example, but maybe I don't know it starts to get into the dilation realm, which is not bad at all but it pertains more into compositing rather than restoration, as denoised movies already have all the camera and lens flaws.

It can be approximated without the dilation with:
ex_unsharp(-0.4,Fc=width()/1.5)
And with the dilation, it's the same but in one call, presumibly faster but in reality slower, not sure why:
ex_luts(mode="max",pixels=ex_shape(1,mode="disk"),exprf=" dup x - abs 5 > swap range_max / 1.05 ^ range_max * x ?").removegrain(20)

@FTLOY: Try GradFun3plus/SmoothGradPlus

Great! Yes the exposure fade was due to the lack of film I only got short cuts for free :) Or if you mean the dark ones they are shot with a still camera but with the motion picture stocks.

As for the dilation it was originally meant for my digital footage to look like film so your script will be better for denoised film.

[Balling]

2020 is a shorthand for 2020NCL which is the most common one used, but you can explicitly define 2020CL or 2020NCL. Anyhow I haven't implemented model conversion yet so I think CL is not currently possible from ConvertFormat. You still have the function in TransformsPack - Models. You can see what's going on with show=true panel.

The concept of "matrix" is ill-formed, it was born when most of the model conversions could be done via a matrix transform, like between YCbCr/YPbPr and RGB, or YUV, or YIQ, etc. Now this is not the case, you can't convert to YcCbcCrc with a single 3x3 matrix, and the same applies to IPT, OkLab, and if I'm not wrong to YCoCg nor YUVr.

Also you don't want 709 transfer if working with delivery formats, for example if you are working with a Bluray source you want 1886 transfer which is the same 2020 uses as standard.

Correct with 2020CL. Indeed, it tries to make constant luminance which is by definition making Y' as close to Y of XYZ as possible. To do that it applies part of matrix first on linear values and only then applies nonlinearity and finishes the matrix using Y'.

[anton_foy]

Dogway your inbox is full. Did you also want me to send you the grey card grain plates?

[Dogway]

Yes sorry, I forgot to delete the PM, deleted just as I got the warning so try when you can. Will be filling the presets for next updates, I think that's all is left for FilmGrain+.

[kedautinh12]

Hi Dogway, cause filmgrain+ different paramaters from grainfactory3mod. Can you trans this script to filmgrain+ for same result? thanks
gr = 0.3
size = float(width())/2400
GrainFactory3mod(g1str=6*gr,g2str=8*gr,g3str=5*gr,g1size=1.2*size,g2size=1.5*size,g3size=1.4*size,g1cstr=1.5*gr,g2cstr=1.5*gr,g3cstr=1.5*gr,temp_avg=0)

[Dogway]

As I see from the current presets 5218 is the most similar:
FilmGrainPlus(preset="Vision2 5218 500T")
It will auto-scale from input resolution.

[kedautinh12]

Thanks

[Dogway]

Just added SmoothMotion() to ResizersPack.
It's a concept from MPV (https://github.com/mpv-player/mpv/wiki/Interpolation#smoothmotion). To display 24fps content smoothly on 60Hz displays and in real-time.
It works better than ChangeFPS() and ConvertFPS().

[Guest]

Just added SmoothMotion() to ResizersPack.
It's a concept from MPV (https://github.com/mpv-player/mpv/wiki/Interpolation#smoothmotion). To display 24fps content smoothly on 60Hz displays and in real-time.
It works better than ChangeFPS() and ConvertFPS().

This sounds interesting :)

So in a script that has an SMDegrain pre filter call, etc, where would this need to be, before or after ??

[Dogway]

After, at the end of the filter stack.

[LeXXuz]

Any news with Scene Stats?
I tried to mask out fades but it seems there are also error messages on camera pans which makes it not really usable right now. :o

[Guest]

After, at the end of the filter stack.

Thanks for the info, and thanks for the new filter (whatever it should be called)..

I tried it today, and it worked well on a 4K HDR10 clip :)

But I have to ask, even tho it states that it basically increases the original FPS x 2.5, is it possible to specify a custom fps ??

https://github.com/Dogway/Avisynth-Scripts/blob/master/ResizersPack.avsi#L594

[Dogway]

@LeXXuz: Provide me a sample so I can have a look.

@FTLOY: The algo is geared towards a 2.5 framerate upsample. What's your source and target FPS you want to do?

[Boulder]

I tested FilmGrain+ and it looks really nice, thanks a lot :) I often need such a filter to create some fake detail on low-quality or overcleaned sources.
Just noticed that the preblur parameter doesn't seem to work, the strength looks the same with every value other than 0 which effectively does disable it. I was testing on a 8-bit YV12 source.

[Dogway]

It's a multiplier so if internal blur is already 0 it won't do anything, rarely is 0 so you might see an effect for example multiplying by 2, 3 or 4.
Maybe post your call in case I missed something.

[Boulder]

It's a multiplier so if internal blur is already 0 it won't do anything, rarely is 0 so you might see an effect for example multiplying by 2, 3 or 4.
Maybe post your call in case I missed something.
For example this one, I cannot see a visible difference between the preblur values. The image is blurred quite heavily compared to the original one so I was thinking of damping it down.

DGSource("test.dgi")
interleave(FilmGrainPlus(preset="Vision 5274 200T", preblur=0.01, deterministic=true), FilmGrainPlus(preset="Vision 5274 200T", preblur=1, deterministic=true))

[Guest]

@LeXXuz: Provide me a sample so I can have a look.

@FTLOY: The algo is geared towards a 2.5 framerate upsample. What's your source and target FPS you want to do?

I was actually just wondering if it was an option, the 2.5 x is pretty damn close...

As I haven't had too much luck with RIFEwrap :(, mainly GPU memory issues.

I have a sample of a scene from GoT 4K HDR10 that I used SmoothMotion on, and I'd like to get your opinion of which scene is "smoother"..

GoT trees (https://www.mediafire.com/file/f1bcasdzdzfza5d/GoT_trees.7z/file)

At 20 seconds in, there are trees passing across the screen...do I detect a slight "shudder" with the "smooth" clip ??, the other clip is original FPS. It might be my eye's...

[Dogway]

@FTLOY: They serve different purposes though. RIFEwrap will create new frames so the content will have the soap opera effect if target is 60fps. Meanwhile SmoothMotion is only to smoothly display 24fps on a 60Hz display, but honoring the original film framerate cadence. Nowadays most Smart TVs adapt the refresh rate to accomodate to 24fps.

As for the camera pan on the trees I can see the judder but that's what the algo is. For those areas you would RIFEwrap or some kind of interpolation. Maybe ConvertFPS() blending all frames in that area.

@Boulder: I don't get much blur, you can get the gaussian blur sigma with the following expression which is what's parsed to vsTCanny directly. As you can see for 1080p you get like only 0.09 sigma (preblur=1), and for 2160p 0.49 which is still quite low. On that I think I'm going to bypass gaussian blur for sigmas of 0.35 and lower since they only slow down the filter.

w=1920
str=0.4
shrp=1
pbl=1
subtitle(string(max(0,((sqrt(((1-clamp(shrp*(-0.347*w*0.001+1.667),0,1))*3)+1)/2.)*sqrt(2))*(pow(str*(0.409*w*0.001+0.214),0.318)-0.61)*(pow(w/1920.-0.46,0.4)+0.2)*pbl)))


By the way, I'm going to update ResizersPack and TransformsPack since I commited a few typos yesterday.

[Boulder]

@Boulder: I don't get much blur, you can get the gaussian blur sigma with the following expression which is what's parsed to vsTCanny directly. As you can see for 1080p you get like only 0.09 sigma (preblur=1), and for 2160p 0.49 which is still quite low. On that I think I'm going to bypass gaussian blur for sigmas of 0.35 and lower since they only slow down the filter.

w=1920
str=0.4
shrp=1
pbl=1
subtitle(string(max(0,((sqrt(((1-clamp(shrp*(-0.347*w*0.001+1.667),0,1))*3)+1)/2.)*sqrt(2))*(pow(str*(0.409*w*0.001+0.214),0.318)-0.61)*(pow(w/1920.-0.46,0.4)+0.2)*pbl)))


By the way, I'm going to update ResizersPack and TransformsPack since I commited a few typos yesterday.

The source is 1024x576 (originally 1080p, then inverted the upscale and cleaned the video), here are sample screenshots where the blur is rather visible in the clothes and in the earring.

https://i.ibb.co/qmSr0gL/original.png
https://i.ibb.co/51HwFxD/filmgrain-preblur1-0.png

Your code shows 0.014060 if I set w=1024, but maybe any vsTCanny is just blurring noticably. If I set str to 0.2, like I've also tested, the value is 0 but still preblur 0 vs 1 affects the output the same way.

[Dogway]

What I see is vertical blur only. Is vsTCanny updated? This is my first and probably only suspect. Just tested resizing a clip to 1024 width and no issues either.

-----------------------

By the way I wanted to update the rationale for per-shot grain restoration posted here (https://forum.doom9.org/showthread.php?p=1975232), with some fixes and updates.
The main change here aside using FilmGrainPlus now is that the regrain filter is outside ScriptClip runtime environment, this is not only faster but will yield more stable and probably better results.
The main takeaway here is that you can't run SceneStats after heavy filtering, otherwise the look-ahead and lookbacks will take too much time, so we render the stats to an external file.
First for the scene stats, later for the grain diff stats.

# First Pass (fast)
setmemorymax(2048*4)
DGSource("C:\source.dgi",cl=0,ct=0,cr=0,cb=0)

SceneStats(mode="Range",path="C:\Range.log")

Prefetch(1)

# Second Pass (slowish)
setmemorymax(2048*4)
DGSource("C:\source.dgi",cl=0,ct=0,cr=0,cb=0)

ReadStats("C:\Range.log")
ExtractY()
dirt = last
# If this is too slow use a faster spatio-temporal denoiser
SMDegrain(1, 400, prefilter=1, ContraSharp=false, RefineMotion=false, LFR=400)

ex_makediff(dirt,dif=false) # dirt mask
SceneStats(mode="Stats", path="C:\Stats.log") # per-shot dirt mask average

Prefetch(1)

# Third Pass
setmemorymax(2048*4)
DGSource("C:\source.dgi",cl=0,ct=0,cr=0,cb=0)

ConvertBits(16)
SMDegrain(3, 400, RefineMotion=true) # your actual denoiser or whatever filtering here

ReadStats("C:\Range.log")
ReadStats("C:\Stats.log")

bright = FilmGrainPlus(size=0.8,str=0.2,mode="log")
mid = FilmGrainPlus(size=0.9,str=0.4,mode="log")
dark = FilmGrainPlus(size=1.1,str=0.6,mode="log")

# per-shot modulated grain
# Normally motion leads to a greater degrain mask (up to 4 times the values) so you might...
# also want to compute that in First Pass to rule out false positives
ScriptClip(function [bright,mid,dark] () {

avg = propGetAsArray("_SceneStats")[6] # IQM. values are stored as 8-bit

avg > 0.6 ? dark : \
avg > 0.4 ? mid : bright

} )

ConvertBits(8, dither=1)

Prefetch(6)

[Boulder]

What I see is vertical blur only. Is vsTCanny updated? This is my first and probably only suspect. Just tested resizing a clip to 1024 width and no issues either.

That was it - I didn't have the latest version :eek: Thanks again!

[LeXXuz]

Out of all those many presets and settings for Filmgrain+,
what would be a good starting point for a quite subtle grain in SD, HD and 4k, just enough to help poor displays as additional dithering to fight banding?

I encode with x265 @ CRF16 and below with a very slow custom preset, so I'm not concerned it it would be hurt too much by compression.

[kedautinh12]

Out of all those many presets and settings for Filmgrain+,
what would be a good starting point for a quite subtle grain in SD, HD and 4k, just enough to help poor displays as additional dithering to fight banding?

I encode with x265 @ CRF16 and below with a very slow custom preset, so I'm not concerned it it would be hurt too much by compression.

Need more example about only enough to help poor displays as additional dithering to fight banding

[Dogway]

I'm lacking a few presets, specially on the 50 and 200 range which would be more subtle but you can check Vision3 5219, if it's too slow (because of grain small size) try 5218 or play with 'size' and also 'str' if you want it more subtle.

To avoid banding you need to run FGP in HBD as well.

By the way, just refactored FastLineDarkenMOD(), now it's 13% faster in 8-bit and +39% in HBD.

[Lan4]

LSFplus is currently not available in SharpenersPack. It should be?

[LeXXuz]

LSFplus is currently not available in SharpenersPack. It should be?

LSFPlus is separate. As noted in overview of sharpeners package. ;)

[LeXXuz]

I'm lacking a few presets, specially on the 50 and 200 range which would be more subtle but you can check Vision3 5219, if it's too slow (because of grain small size) try 5218 or play with 'size' and also 'str' if you want it more subtle.

To avoid banding you need to run FGP in HBD as well.

By the way, just refactored FastLineDarkenMOD(), now it's 7% faster in 8-bit and +29% in HBD.

Can I select a preset with custom parameters, f.e.
FilmGrainPlus(preset="Vision3 5219 500T", sharpness=0.5)

or would that be ignored?

[madey83]

Hi,

Could you please explain when and which one mfilters i should use in SMDegrain.
Are there any examples to show use cases of each?

What is the value of using them in SMDegrain?

[Dogway]

Can I select a preset with custom parameters, f.e.
FilmGrainPlus(preset="Vision3 5219 500T", sharpness=0.5)
Sure, you can override them, is it not working or something?

Could you please explain when and which one mfilters i should use in SMDegrain.
Are there any examples to show use cases of each?

What is the value of using them in SMDegrain?
'mfilter' argument you mean? That's called motion filter because the filter you pass there is applied typically on motion areas where motion block matching failed. The typical usage is to use spatial filters so you get two perks, a smoother less artifacty output and compressibility.

[LeXXuz]

Sure, you can override them, is it not working or something?

No, all good. Just wanted to make sure as I had a hard time to spot the subtle difference over a remote session. But the filesize was noticeable smaller in the end between the default preset setting and custom setting with only 50% of sharpness. :)

[Guest]

@ Dogway, (or anyone)

I hope this isn't off topic too much, and I apologize if a similar question has been asked.

But are there filters / scripts in your "arsenal" that could do an equivalent "job" as Topaz ??

I have tried Topaz on several old crappy video's, and I'm not convinced :(

If you Google this topic, there are mentions that AVS can do as good a job, with appropriate scripts & plugins, etc.

So I thought I'd ask...:o

[madey83]

'mfilter' argument you mean? That's called motion filter because the filter you pass there is applied typically on motion areas where motion block matching failed. The typical usage is to use spatial filters so you get two perks, a smoother less artifacty output and compressibility.

this is what i got from first page:

ex_FluxSmoothST()- Spatio-Temporal minimum change between weighted blur and median. Uses ex_FluxSmoothT() and its spatial equivalent ex_MinBlur()

is it mean that these two are the only spatial filters?

Have you got few examples how to use them and which is better? Or maybe there are betters - could you please provide names?
:thanks:

[SkilledAbbot]

Hello Forum,

It's been a while since I've used avisynth, and now I am currently reinstalling everything. I'm not very technical but I really enjoyed LSF decades ago and now I am trying to re-implement it to no avail.
Have no idea where I am wrong. Is there are tutorial for newbies like me with step by step setup for these filters? My script and error are pasted below. Thank you.

Import("E:\GameCap\Scripts\functions\ExTools.avs")
Import("E:\GameCap\Scripts\functions\SMDegrain.avs")
Import("E:\GameCap\Scripts\functions\ResizersPack.avs")
Import("E:\GameCap\Scripts\functions\SharpenersPack.avs")
Import("E:\GameCap\Scripts\functions\GradePack.avs")
Import("E:\GameCap\Scripts\functions\FilmGrain+.avs")
Import("E:\GameCap\Scripts\functions\MasksPack.avs")
Import("E:\GameCap\Scripts\functions\NNEDI3CL_rpow2.avs")
Import("E:\GameCap\Scripts\functions\ScenesPack.avs")
Import("E:\GameCap\Scripts\functions\TransformsPack-Main.avs")
Import("E:\GameCap\Scripts\functions\TransformsPack-Models.avs")
Import("E:\GameCap\Scripts\functions\TransformsPack-Transfers.avs")
Import("E:\GameCap\Scripts\functions\LSFplus.avs")



DirectShowSource("E:\GameCap\Videos\test.mp4", audio=false)

LSFplus()


https://imgur.com/a/D6yyOOj

[Dogway]

@madey83: I made tons of spatial filters, for example at least half of ex_median() modes are spatial. Also the SMDegrain prefilters are mostly spatial, so you got ex_minblur() which is pretty nice, ex_KNLMeansCL(), ex_DGDenoise(), ex_BM3D(), DFTTest() but also other ones in ExTools like ex_bilateral(), ex_smartblur() or STTWM(). Then in yugefunc you got ex_guidedblur() and ex_ANguidedblur(). It depends how much you want to denoise and how much you want to protect. For instance is it's blocking and not noise what covers motion areas you'd also could run Deblock_QED(). Depending on what you need I can recommend ex_minblur(), ex_median("IQMV"), ex_median("smart"), ex_KNLMeansCL()/ex_DGDenoise() and ex_BM3D().

@FTLOY: You mean like AI upscaling? I think the best is to actually use upscaling models like the ones here (https://forum.doom9.org/showthread.php?t=184768). I asked him to add a few ones optimized for live action so probably he will add those when he finds some time. Other than that I made deep_resize() as a performant approach for upscaling, it's not bad at all and it's fast. Aside form the default NNEDI3 you can also try other kernels for 'edge' argument like FCBI, SuperResXBR, Waifu2x, RAVU, FSR1 or FSRCNN. I look forward to do some AI based restorations when I install Win10, but probably not in AviSynth.

@SkilledAbbot: Install latest version here (https://forum.doom9.org/showthread.php?t=181351). Search for AviSynth+ 3.7.3 test 9, but before that use an installer (https://github.com/AviSynth/AviSynthPlus/releases/) version even if it's a bit older, and then manually replace files with 'test 9' ones. Also give a look at Asd-g repo (https://github.com/Asd-g) and install some of his plugins, they are very useful and at times needed, also pinterf repo (https://github.com/pinterf) for the most up-to-date common plugins. And use FFMS2 (https://forum.doom9.org/showthread.php?p=1986154#post1986154) loader or GPU based DGDecNV (http://avisynth.nl/index.php/DGDecNV) for frame properties support, might fail otherwise.

[SkilledAbbot]

@SkilledAbbot: Install latest version here (https://forum.doom9.org/showthread.php?t=181351). Search for Avisynth+ 3.7.3 test 9. Also give a look at Asd-g repo (https://github.com/Asd-g) and install some of his plugins, they are very useful and at times needed, also pinterf repo (https://github.com/pinterf) for the most up-to-date common plugins. And use FFMS2 (https://forum.doom9.org/showthread.php?p=1986154#post1986154) loader or GPU based DGDecNV (http://avisynth.nl/index.php/DGDecNV) for frame properties support, might fail otherwise.

Thank you for quick reply. I want to double check, "3.7.3 test9" does not have '+' next to the name. Is that the one?

[Dogway]

He might have forgotten, the current branch since a few years now is all + based. Also if you use AvsPmod the current updated branch is gispos', you can find here (https://forum.doom9.org/showthread.php?t=175823).

[madey83]

[QUOTE=Dogway;1986223]@madey83: I made tons of spatial filters, for example at least half of ex_median() modes are spatial. Also the SMDegrain prefilters are mostly spatial, so you got ex_minblur() which is pretty nice, ex_KNLMeansCL(), ex_DGDenoise(), ex_BM3D(), DFTTest() but also other ones in ExTools like ex_bilateral(), ex_smartblur() or STTWM(). Then in yugefunc you got ex_guidedblur() and ex_ANguidedblur(). It depends how much you want to denoise and how much you want to protect. For instance is it's blocking and not noise what covers motion areas you'd also could run Deblock_QED(). Depending on what you need I can recommend ex_minblur(), ex_median("IQMV"), ex_median("smart"), ex_KNLMeansCL()/ex_DGDenoise() and ex_BM3D().


thank you so much.

[SkilledAbbot]

@Dogway: Works like a charm and looks beautiful. Thank you!




@SkilledAbbot: Install latest version here (https://forum.doom9.org/showthread.php?t=181351). Search for AviSynth+ 3.7.3 test 9, but before that use an installer (https://github.com/AviSynth/AviSynthPlus/releases/) version even if it's a bit older, and then manually replace files with 'test 9' ones. Also give a look at Asd-g repo (https://github.com/Asd-g) and install some of his plugins, they are very useful and at times needed, also pinterf repo (https://github.com/pinterf) for the most up-to-date common plugins. And use FFMS2 (https://forum.doom9.org/showthread.php?p=1986154#post1986154) loader or GPU based DGDecNV (http://avisynth.nl/index.php/DGDecNV) for frame properties support, might fail otherwise.

[Lan4]

Questions about SharpenersPack. I'm interested in non-linear sharpness. In other words, strong for small differences, and not strong for large differences.

1) ex_unsharp has no non-linear sharpening options. But if I increment str and safe=true, will those be non-linear sharpening actions?

2) The threshold in ex_unsharp seems to work in the opposite way. What if we use minus values of threshold?

3) A more complex problem that I've caught a few times. Just to clarify, I'm using the Staxrip app for Avisynth. I use FineSharpPlus and DetailSharpen filters. The same parameter of non-linear sharpness gives exactly the opposite result. First they sharpen, and then something happens and they start blurring the image. Could this theoretically happen?

[Dogway]

I don't know how it is in StaxRip but DetailSharpen doesn't have non-linear modifier, only 'pow' which is analogous to FineSharpPlus' 'pstr'. Both act in the same way as I could check and in the range recommended in the function definitions.

FineSharpPlus in this case is a superior non-linear sharpener as I ported its portion from LSFplus, but it doesn't have all the bell and whistles of the later, so probably you might want to use LSFplus instead.

What you look after (strong on small diffs) is actually the opposite of the implemented non-linear modes. You are looking then into LSFplus' edgemode=2, this will sharpen non-edges only but applied through an edge mask though.

If you want a manual and non-linear sharpening you can also use ex_guidedblur(), which is a non-linear blurring filter.
src = last
rad = 1
bl = ex_guidedblur(rad)

ex_lutxy(bl,"x y - x +")

ex_clamp(src,bl,last) # limiter (might clamp small diffs though)

ex_unsharp() with safe=true is only for ringing, it will still sharpen edges. I found that threshold works bad with safe=true, but in any case they kinda null each other so can you can safely turn safe=false and turn up threshold, no more than 40 or so. Threshold works as a passthough to the unsharpened version, I noticed that after a certain value it starts to blur instead so I might fix that.

Finally you can also use ex_limitdif() as used in deep_resize():

ex_limitdif(flat, edge, thr=thr, elast=ela, UV=1)

[Lan4]

LSFplus is too heavy for my needs. FineSharpPlus, DetailSharpen or ex_unsharp are lighter and faster.

DetailSharpen doesn't have non-linear modifier
I thought so because the script itself says:
sstr (float) - strength of non-linear sharpening.
power (float) - exponent of non-linear sharpening.

Threshold works as a passthough to the unsharpened version, I noticed that after a certain value it starts to blur instead
I see that the threshold of ex_unsharp always blurs. so I asked about the possibility of minus threshold values.

Both act in the same way as I could check and in the range recommended in the function definitions.
purely theoretically, there may be a possibility of such a bug that the parameter values ​​give the opposite effect? to further understand if my computer is not working properly with the filters, or if the Staxrip application is not working properly.

[Dogway]

LSFplus in 'LSF' mode and without supersampling is rather fast I'd say.

What I meant with DetailSharpen is that you can't change the non-linearity, you can change its power but not its shape.

I will have a look at ex_unsharp threshold issue* in the meantime try some of the above suggestions. You can also pass ex_unsharp through an edge mask. I guess your goal is for texture sharpness which that will suffix.

*I didn't find any change on negative values

[Lan4]

I didn't find negative ex_unsharp threshold values. I meant is it possible to make negative values. And would this be a texture sharpening solution (more so than edge sharpening)?

[Dogway]

ex_unsharp() is a plain unsharp mask so I don't want to add non-linear sharpening aside from the bundled anti-ringing 'safe' option.
It is easy to mask out edges as I explained above:

With an edge mask:
msk=ex_edge("frei-chen")
ex_unsharp(2.0, Fc=1920, safe=true)
ex_merge(src,msk)

Using ex_limitdif():
ex_unsharp(2.0, Fc=1920, safe=false)
ex_limitdif(src,thr=1.5,elast=4.0)

[LeXXuz]

What does a neg value for strc mean in FilmGrain+? That no chroma grain is applied? Or do I have to set it to 0 if I don't want chroma processing?

[Dogway]

Negative grain, I don't know what AddGrainC does. The function definition sets the range between 0.0 and 1.0 so that's the recommended values. I would go low in any case.

[anton_foy]

Usually in smdegrain I put "uhdhalf=false" because on my 4k footage uhdhalf=true it gets too soft and seems to loose too much detail to post sharpen it. Any way to compensate this inside smdegrain to keep the speed benifits of mscalevec?

[LeXXuz]

Usually in smdegrain I put "uhdhalf=false" because on my 4k footage uhdhalf=true it gets too soft and seems to loose too much detail to post sharpen it. Any way to compensate this inside smdegrain to keep the speed benifits of mscalevec?

Hm interesting. I wanted to try that out to see difference in denoising. With interesting result. There seems to be a possible bug. As talked about before, I use Expr("81","90","250",scale_inputs="int") as mfilter to determine how well my settings work on a source.

With uhdhalf=false on 4k content, the entire picture is bright red with no details at all. Even with very high thSAD setting. Which would mean mvtools does not find ANY match in that source. Which can't be.
With uhdhalf=true, everything is fine and only a few remaining areas with too high SAD are left shown as red.

I used this simple call:
SMDegrain(mode="MDegrain", tr=6, DCT=5, thSAD=500, refinemotion=true, blksize=32, mfilter=Expr("81","90","250",scale_inputs="int"), chroma=true, plane=4, gpuid=-1, interlaced=false, uhdhalf=false)

Doesn't matter what I set thSAD to, it stays all red. Either there is a bug in mfilter routine or denoising doesn't work at all with uhdhalf=false on 4k content. :confused:

[anton_foy]

@LeXXuz

What happens if you put:
convertbits(16)
Converttoyuv444()
Smdegrain(uhdhalf=false,params)

[Dogway]

What about setting limit=255? Does it improve denoising? I defaulted limit for !UHDHalf to 2 due to some issues.

[LeXXuz]

@LeXXuz

What happens if you put:
convertbits(16)
Converttoyuv444()
Smdegrain(uhdhalf=false,params)

Apart from the fact that I can't use DGHDRtoSDR() in the prefilter chain with 4:4:4, because it expects YUV420P16 as input, the result is still the same. Complete red screen. Something is off.

[anton_foy]

Are the params tuned somewhat to the results of Zopti in the latest smdegrain version?

[Dogway]

Are the params tuned somewhat to the results of Zopti in the latest smdegrain version?

Yes it is optimized, that's why all the search, searchr, searchparam, DCT, DCTR, etc defaults and the output is more detail retaining than the original SMDegrain. The only thing I didn't finish is verification by pair. I was supposed to run Zopti again on another source with artificial grain but didn't have time.

[anton_foy]

Yes it is optimized, that's why all the search, searchr, searchparam, DCT, DCTR, etc defaults and the output is more detail retaining than the original SMDegrain. The only thing I didn't finish is verification by pair. I was supposed to run Zopti again on another source with artificial grain but didn't have time.

Awesome! Sorry for the delay with the grain plates, I have been out of internet at home for a while but coming soon.

[LeXXuz]

I'm thinking about upscaling a few DVD to 720p with deep_resize(). Does it do colour space conversion as well when upsizing from SD to HD? Or do I have to do that manually with ColorMatrix f.e.?

I must say the output looks already quite good with just the default call of deep_resize(width, hight). Is there anything addition to recommend as parameter for this scenario?

And would you recommend denoising before upscaling, or upscaling first and then denoising?

[DTL]

What about setting limit=255? Does it improve denoising? I defaulted limit for !UHDHalf to 2 due to some issues.

Decreasing 'limit' to 2 close of disable degraining at all. It only will process (output denoised) samples of difference about 2 (denoised frame from current frame ?) at 8bit encoding. All other samples of input current frame will be passed to output unchanged (so no denoise for medium and high noise values).

May be decreasing limit to 2 only work somehow good for very low noised 10bit sources. Also setting limit to no-default (255) make performance slower (it is additional post-processing).

[LeXXuz]

Decreasing 'limit' to 2 close of disable degraining at all. It only will process (output denoised) samples of difference about 2 (denoised frame from current frame ?) at 8bit encoding. All other samples of input current frame will be passed to output unchanged (so no denoise for medium and high noise values).

May be decreasing limit to 2 only work somehow good for very low noised 10bit sources. Also setting limit to no-default (255) make performance slower (it is additional post-processing).

So that's why it keeps much better detail with !uhdhalf, and why my entire screen is red with the mfilter expression, because the setting is way too subtle and it denoises "almost" nothing, hence passing the entire frame over to mfilter.

[Dogway]

I think the default in mvtools is 255. What I want you to check is how it behaves for UHD sources (with UHDHalf=false) as I encountered some issues back then. If everything looks fine to you I change it back to 255 as dedault.

[LeXXuz]

I think the default in mvtools is 255. What I want you to check is how it behaves for UHD sources (with UHDHalf=false) as I encountered some issues back then. If everything looks fine to you I change it back to 255 as dedault.

I haven't done much with UHD yet. Just tested this because I was curious about more detail preservation anton_foy talked about. I think anton_foy has more experience to tell if this is troublesome or not.

Since we are talking about this. DTL made a lot of interesting commits to mvtools over the past couple of month in his versions. I admit I don't understand a lot of the technical background, but it looks like some good improvements. And the GPU based stuff is interesting of course. Is it a lot of work to get these versions to run with SMDegrain to benefit from their additions?

[anton_foy]

@Dogway
Wow great params I just replaced smdegrain from 23 feb to the new update. Now experimenting time and I found already alot of nifty tweaks.

@LeXXuz
Regarding DTL's commits they are amazing.
I just would like to get into action with it in HBD and the block overlap that I had problems with causing severe blockiness in higher motion areas. Maybe DTL solved this recently but I must see.

[DTL]

Since we are talking about this. DTL made a lot of interesting commits to mvtools over the past couple of month in his versions. I admit I don't understand a lot of the technical background, but it looks like some good improvements. And the GPU based stuff is interesting of course. Is it a lot of work to get these versions to run with SMDegrain to benefit from their additions?

My version is mostly working (tested) with 8x8 blocksize and 8bit YV12. Most of other block sizes and bitdepth may not work at all or slow (no SIMD versions of processing).

It is again looks as the very beginning of mvtools of 200x years and it may take more one decade to fix possible crash-bugs and cover some generally used block sizes and bitdepths at least (not all possible with mvtools). But it looks the civilization is dying very quickly and expecting no any developers in 202x may make this. So we possibly will no more have as good freeware developers as were for develop original mvtools to version 2.7.45 in 200x..2020 years.

At mid of 2023 it looks we have about 2..3 users of mvtools and 0 to 1 developers of new features. To the total planet Earth of about 8e9 people. The complexity of MAnalyse+MDegrainN is now may be comparable or approaching to some simple MPEG encoder (like MPEG1 or MPEG2) and having about 0 to 1 developer to the total planet looks like not very promising for nice all-features stable versions releases and quick bugfixes. For the residuals of current dying civilization we have examples of ffmpeg and x26x developing communities (>1 active developers and may be >10) so the users of ffmpeg and x26x encoders may still get good enough stable updates from time to time. For mvtools I not see good enough team of developers to make comparable progress.

The only somehow quick solution to work with original 2.7.45 by pinterf (old features but stable and most block size and bitdepth covered) and 2.7.45+ is to rename all filters in 2.7.45+ like _a (alpha-state) and it will possible to load both 2.7.45 and next builds in same AVS environment (also may be new MDegrainN_a can use old and more stable MAnalyse). Some new features in MDegrainN are not depend on block size and bitdepth.

[anton_foy]

My version is mostly working (tested) with 8x8 blocksize and 8bit YV12. Most of other block sizes and bitdepth may not work at all or slow (no SIMD versions of processing).

It is again looks as the very beginning of mvtools of 200x years and it may take more one decade to fix possible crash-bugs and cover some generally used block sizes and bitdepths at least (not all possible with mvtools). But it looks the civilization is dying very quickly and expecting no any developers in 202x may make this. So we possibly will no more have as good freeware developers as were for develop original mvtools to version 2.7.45 in 200x..2020 years.

At mid of 2023 it looks we have about 2..3 users of mvtools and 0 to 1 developers of new features. To the total planet Earth of about 8e9 people. The complexity of MAnalyse+MDegrainN is now may be comparable or approaching to some simple MPEG encoder (like MPEG1 or MPEG2) and having about 0 to 1 developer to the total planet looks like not very promising for nice all-features stable versions releases and quick bugfixes. For the residuals of current dying civilization we have examples of ffmpeg and x26x developing communities (>1 active developers and may be >10) so the users of ffmpeg and x26x encoders may still get good enough stable updates from time to time. For mvtools I not see good enough team of developers to make comparable progress.

The only somehow quick solution to work with original 2.7.45 by pinterf (old features but stable and most block size and bitdepth covered) and 2.7.45+ is to rename all filters in 2.7.45+ like _a (alpha-state) and it will possible to load both 2.7.45 and next builds in same AVS environment (also may be new MDegrainN_a can use old and more stable MAnalyse). Some new features in MDegrainN are not depend on block size and bitdepth.

Nevermind the majority, mind the passion. This is going to have impact regardless. But do you think it will take years to bugfix?

EDIT: by the way there are many people using mvtools especially when you count those who use QTGMC and denoising /degraining is not only bound to doom9 forums audience. Part of the pinnacle of denoising is in mvtools IMHO

[DTL]

" But do you think it will take years to bugfix?"

To find source of crashbug (possibly somewhere in MAnalyse) it may take even minutes if some experienced developer will look into it (also with good debug toolset). But we need >0 developer for it anyway. The pinterf is now busy with AVS core and may not have any time. And as the years going on I not see any more developers interested in mvtools.

But supporting of more blocksizes and bitdepths anyway need to design lots of new SIMD functions and it need time.

So currently we actually have 2 different branches of mvtools - the old all-blocksizes and bitdepths 2.7.45 by pinterf and some post-2.7.45 builds with lots of new features but it work mostly as tech-demo for 8x8 blocksize and 8bit YV12. The list of new features after 2.7.45 somehow implemented and planned is about 45..46 items now. Some are general new ways of processing (MVLPF/MPB/MEL) and may be expanded to many more sub-features. MAnalyse also have some complex planning on SIMD AVX2/AVX512 better performance multi-block processing functions but complex in developing and debugging. But my time for development is limited and my experience in C and C++ programming is poor.

So I understand why Dogway not like to touch such non-stable and no-warranty branch until some 'stable' release.

" there are many people using mvtools especially when you count those who use QTGMC and denoising /degraining is not only bound to doom9 forums audience. "

As I understand they are generally happy with old features of 201x and older and also total home-video creation and processing hype looks like died already at 201x season (today we have close to zero end-users handheld and shoulder-mount video cameras on market) - most end-users are busy with other more important things as the time going on. I also partially busy with development of simple med-ages medicine to be prepared to new 'dark ages' and to keep lives from diseases. Also I got second hit of COVID-19 this spring and need to spend more time on fresh air and money for food to restore health. So it makes even less time for programming at home.

[anton_foy]

As I understand they are generally happy with old features of 201x and older and also total home-video creation and processing hype looks like died already at 201x season (today we have close to zero end-users handheld and shoulder-mount video cameras on market) - most end-users are busy with other more important things as the time going on. I also partially busy with development of simple med-ages medicine to be prepared to new 'dark ages' and to keep lives from diseases. Also I got second hit of COVID-19 this spring and need to spend more time on fresh air and money for food to restore health. So it makes even less time for programming at home.

Two things; new people are coming on to the Avs+ scene and since AI whilst not sufficient mvtools is and does the job greatly although slow.
Secondly dont get any covoid shot it will damage you. Sorry just had to mention it. Hope I dont get banned.

[LeXXuz]

Sorry no it is just crazytown. Risk is ONLY getting the shots IMHO. Lost alot of friends over here because of it. But if your DNA is fit it is ok. Im not blaming anybodys choices here but I will NEVER take any of that.

I will NOT jump on this pro/con waggon. But please stop discussing Covid shots. This absolutely does NOT belong here.

[anton_foy]

I will NOT jump on this pro/con waggon. But please stop discussing Covid shots. This absolutely does NOT belong here.

Very sorry, correctly! I Just found out that the latest update
of smdegrain has indeed improved detail alot but also degraining/denoising is lower. Tweaked some params now to make it more suitable for my fizzy noised footage in UHD :)

Edit: seems like the flat parts are getting less denoised and trying to figure out what params make this.

[madey83]

Very sorry, correctly! I Just found out that the latest update
of smdegrain has indeed improved detail alot but also degraining/denoising is lower. Tweaked some params now to make it more suitable for my fizzy noised footage in UHD :)

Edit: seems like the flat parts are getting less denoised and trying to figure out what params make this.


hi,

Could you please share your smdegrain call with newbie?

I'm very curious your tweaks...

[anton_foy]

hi,

Could you please share your smdegrain call with newbie?

I'm very curious your tweaks...

But It its all in the code, see Dogway's github where smdegrain resides.

[DTL]

Two things; new people are coming on to the Avs+ scene and since AI whilst not sufficient mvtools is and does the job greatly although slow.


I see some still running progress in image processing science in Asian region - so may be some developers from that region may take mvtools and expand support of new features to more blocksizes and bitdepths and fix crashbugs. But may be we need to wait more. I think the European and US part of civilization already left the image processing development (at least as I see with AVS core and plugins development).

[Guest]

Delete Irrelevant

If you want to delete that post, simply go into "Edit", and choose "Delete", then "Delete Message" (bottom left corner, then the bottom right corner).

Done.

I haven't had any Covid shots....https://www.cosgan.de/images/midi/muede/p0045.gif

[Guest]

So I updated quite a few filters the other day, and now most scripts that used to work, now have errors, or should I say, "asking" for more "instructions."

Like "bicubic_coeffs", referencing some lines in both Resizers Pack, & SMDegrain.

And "I don't know what 'Lum' means"....

Clearly something has changed. https://www.cosgan.de/images/smilie/konfus/p020.gif

[Dogway]

Update TransformsPack and ResizersPack.

I finished already my AVS+ updates for the most part unless bugs arise. There's an update for SVM in SimilarityMetrics that I have to revise, and obviously fill more presets in FilmGrain+, aside from that I'm done (and TransformsPack).
We are at a point where AviSynth+ is mature, from the top of my head only the plugins need updates like TIVTC for frameprop support, a TemporalGauss version of TemporalSoften, a performant Hysteresis filter and maybe turn SceneStats into a plugin for a performance increase. Also AvsPmod might see improvements on the sliders side, and the wiki needs a deep update/clean up.

[anton_foy]

If you want to delete that post, simply go into "Edit", and choose "Delete", then "Delete Message" (bottom left corner, then the bottom right corner).

Done.

I haven't had any Covid shots....https://www.cosgan.de/images/midi/muede/p0045.gif

Done, thanks!

TemporalGauss version of TemporalSoften

Isn't the ex_blur3d(0,0,tr,"weighted",uv=3) that?

[DTL]

"We are at a point where AviSynth+ is mature,"

For quality processing (up to broadcast/premium) it still very far from. It only about good (stable) for simple non-demandable home-video (may be nowdays poor smartphones-shot). Many core processing and design still use very beginning of digital computers pixel-based imaging solutions. Not sample-based pro-video solutions.

It may look a shame I need to ask developers in 2023 to implement simplest new created transients shaping/conditioning for typical sinc-based channel and as civilization degrades very quiclky only a few persons already can understand why it is required - https://github.com/AviSynth/AviSynthPlus/issues/339 https://github.com/Asd-g/AviSynth-FillBorders/issues/3 .

About mvtools quality at processing non-4:4:4 sources - the precision for subsampled planes data fetching also still not perfect (even in by builds the error only centered but requied 1/2 more shift still not implemented).

[Guest]

Update TransformsPack and ResizersPack.

I finished already my AVS+ updates for the most part unless bugs arise. There's an update for SVM in SimilarityMetrics that I have to revise, and obviously fill more presets in FilmGrain+, aside from that I'm done (and TransformsPack).
We are at a point where AviSynth+ is mature, from the top of my head only the plugins need updates like TIVTC for frameprop support, a TemporalGauss version of TemporalSoften, a performant Hysteresis filter and maybe turn SceneStats into a plugin for a performance increase. Also AvsPmod might see improvements on the sliders side, and the wiki needs a deep update/clean up.

Was part of this reply for my benefit ??

If it was, I updated EVERYTHING, yesterday https://www.cosgan.de/images/smilie/konfus/k035.gif

[madey83]

But It its all in the code, see Dogway's github where smdegrain resides.

i was wondered yours tweaks, not defaults provided by Dogway.

But of course if you would like to not share, fine. :)

[anton_foy]

i was wondered yours tweaks, not defaults provided by Dogway.

But of course if you would like to not share, fine. :)

Sure I can share it just need some more testing first.

[Boulder]

In my over 20 years of Avisynth, I would never ever have thought that our biggest problem is the degradation of civilization :D

Honestly, we don't even have commercial 4:4:4 sources to work on so I really don't see the point of complaining that nothing is being developed. After all, Avisynth is mostly an amateur's toolkit. I've seen the early ages of normal Avisynth and the almost 100% working MT branch and we are already very, very far from there.

[DTL]

Honestly, we don't even have commercial 4:4:4 sources to work on so I really don't see the point of complaining that nothing is being developed.

It mean when current 2.7.45 mvtools run with typical mass-avaialble 4:2:0 content it creates more distorted result (more details degradation and less MPEG-fiendly output). Because spatial precision on fetching chroma planes blocks have both math design errors (error not centered and side-shifted so can reach about double amplitude of possibe in case of centering) and not enough precision (4:2:0 chroma require pel=2 for chroma at pel=1 for luma and luma of pel=4 require pel=8 for chroma). General users very rare see it - but after several years we finally got one perfectionist user and he open issue at github.

The only current workaround possible is to convert 4:2:0 to 4:4:4 and process with mvtools. But that conversion also not lossless and will add distortions.

Additional spatial errors on fetching chroma planes blocks cause more details blurring and also disturb MPEG encoder with qpel precision analysis with more spatial to temporal noise (false motion) to encode.

It is not very complex issue to fix in mvtools but pel=8 better require runtime subshifting and it require design separate SIMD processing functions for each blocksize+bitdepth combination required.

It is general issue of mvtools design so affect all motion-compensated filters members (MDegrain, MCompensate and so on). So generally used QTGMC script also affected.

"our biggest problem is the degradation of civilization"

When we have left about 2 still alive programmers for AVS core and plugins for 8e9 people at the planet to 2023 it looks somehow not very nice. It was expected with progress of computers the number of good programmers will be increase too. The activity on developing of new plugins or expanding features and quality of existed is sort of died too in compare with 200x years season.

[LeXXuz]

The only current workaround possible is to convert 4:2:0 to 4:4:4 and process with mvtools. But that conversion also not lossless and will add distortions.


Hm. Interesting.
So it would be beneficial to convert to 4:4:4 before filtering with SMDegrain and possibly even encode to 10bit 4:4:4 IF the playback device can handle that format?

And if the playback device can't handle 4:4:4, would a back convert to 4:2:0 before feeding the clip to the encoder 'destroy' all benefits from 4:4:4 processing before?

[DTL]

"it would be beneficial to convert to 4:4:4 before filtering with SMDegrain and possibly even encode to 10bit 4:4:4 IF the playback device can handle that format?"

Yes.

" would a back convert to 4:2:0 before feeding the clip to the encoder 'destroy' all benefits from 4:4:4 processing before?"

No. The only disadvantage is lower performance (fps) and higher RAM usage. Also may be scaleCSAD need different tweaking for RGB or YUV 4:4:4 processing.

It was already at this thread. https://github.com/pinterf/mvtools/issues/59

[anton_foy]

https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/focus.cpp

Here is the TemporalSoften code but someone who knows this maybe can be able to add the TemporalGauss mode to it?

[Dogway]

Isn't the ex_blur3d(0,0,tr,"weighted",uv=3) that?
Yes, but the lack of SC limits its use.

About processing clips in 444, it would also be interesting in also converting to YCoCg (444) and see the possible benefits. I think this is better done outside with the TransformsPack filters instead of black-boxing it inside SMDegrain.

scaleCSAD in SMDegrain adapts to chroma subsampling and source resolution.

On the topic of AviSynth health it is more used than the four we chat here, people simply don't post or use Staxrip or other frontends. Also from my experience AVS helped me view TheFoundry Nuke in AviSynth eyes and while some things can't be done outside it (like tracking, roto, 3D layering) everything concerning filtering AVS is superior.

For ringing I don't know how feasible it is to use a frequency adapted filter for scaling, like say triangular/hermite for hard edges (255 gradient) and going down to sinc with several taps for low frequencies. It looks like the scaling kernels are always static and not content dependent (aside from NN ones)

Another useful update would be to implement avsresize (or zimg) as the backend for the ConvertTo calls, as shown here (https://forum.doom9.org/showthread.php?p=1979592) its speed is average and could be further improved.

[DTL]

For ringing I don't know how feasible it is to use a frequency adapted filter for scaling, like say triangular/hermite for hard edges (255 gradient) and going down to sinc with several taps for low frequencies. It looks like the scaling kernels are always static and not content dependent (aside from NN ones)



Simple Gauss kernel for simplest possible shaping/conditioning work nice enough - https://github.com/DTL2020/AviSynth-FillBorders/releases/tag/v_1.1.2_a01 . Though not as sharp as possible with more 'professional' kernels like SinPow/UserDefined2 .

Yes - the performance of equal to ConvertToRGB32 (in planar form) of avsresize is about 2 times better in compare with AVS internal ConvertToRGB32.

[LeXXuz]

Don't want to get OT, but for anyone interested:

KNLMeansCL runs great on Intel ARC. Got my A770 Limited just today and I'm very happy with its performance so far.

Beyond anything I could achieve with my RTX30x0 boards, thanks to 16GB VRAM and 256bit Membus with ReBAR support. :D

Finally I can run more complex SMDegrain scripts with quite high settings for KNLMeansCL (a=4,d=4,s=8) @ 32 threads, now fully saturating a 5950x CPU.

https://abload.de/thumb/2023-05-06mwe8z.png (https://abload.de/image.php?img=2023-05-06mwe8z.png)

I'm glad I gave it a try and bought one. So, if you use KNLMeansCL very often as prefilter and need a new GPU mostly for video processing and computing, consider an ARC. :)

[DTL]

Intel cards may be more useful if intel will finally implement support for DX12-ME (possibly with better quality on noised sources in compare with NVIDIA) and with better performance (more pairs frames per second search).

Special ASIC typically significantly outperforms 'universal programming language' implementation via universal programming API.

Also as I see AMD buy Xilinx and start to make some video-accelerators for PC-bus (like PCIe) specific for MPEG encoding - if they finally make support in chip+driver for DX12-ME for Windows it may have very nice performance in MAnalyse task. Alveo MA35D board announced - but still no news about DX12-ME support.

https://www.xilinx.com/applications/data-center/video-imaging/alveo-ma35d.html

Card provide at least 32 1080p60 AV1 stream realtime encoding (16 for 264/265) - it is sort of 2000 frames pairs search per second minimum for FullHD size. Also 8K max res allow to process with lower-pel precision if even main engine provide qpel only. Current old NVIDIA only run at 4096x4096 max. And only 35W passive cooling. The GTX1060 card running much lower DX12-ME performance (about 100 pairs frames search per second) takes about 60W.

[Guest]

Originally Posted by Dogway
Update TransformsPack and ResizersPack.

I ended up re-updating, all the Transformers, SMDegrain & Resizers, AGAIN, however, I then had to add NNEDI3CL (which had an update of it's own, recently) https://www.cosgan.de/images/smilie/froehlich/a020.gif

And due to whatever has changed, I now have to change/update ALL the scripts I use. https://www.cosgan.de/images/smilie/traurig/a045.gif

[LeXXuz]

I think the default in mvtools is 255. What I want you to check is how it behaves for UHD sources (with UHDHalf=false) as I encountered some issues back then. If everything looks fine to you I change it back to 255 as dedault.

I'd like to jump back to this for a second.
You mean this limit, right?
limit = Default( limit, md!="MDegrain" ? 255 : isUHD ? 2 : 255 ) # auto-scaled

What exactly does this limit do?
That's a huge gap between 2 and 255. Why so very low and what is meant with automatically scaled?

I'd like to do some more testing with UHDHalf=false one some sources to see how much benefit it may have.

[Dogway]

It does limit changes larger than a difference of 2. Auto-scaled means the difference will be auto-scaled to working bitdepth.
I was probably working around an issue with excessive denoising for UHD, so try with limit=255 with and without UHDHalf, and then compared to 1080p to check if you see something strange.

[DTL]

Limiting is post-processing designed to fight some possible artifacts of 'unlimited' denoising. If these artifacts present and visible. It not designed to control denoise-power. So if user see some artifacts and can not remove by other settings - it can enable limiting post-processing (set limit value to < 255).

[LeXXuz]

It does limit changes larger than a difference of 2. Auto-scaled means the difference will be auto-scaled to working bitdepth.
I was probably working around an issue with excessive denoising for UHD, so try with limit=255 with and without UHDHalf, and then compared to 1080p to check if you see something strange.

Okay. I did some testing with Ridley Scott's Prometheus UHD Blu-ray which is an act of balancing. It has some fine detail but also lots of nasty noise in the blacks. It's not really film grain, but some artificially added noise because of stupidity... eh... pardon me, I meant stylistic reasons of course. :rolleyes:

Anyhow, I uploaded 3 screenshots showing the filtered clip and two with unsuccesfull motion areas enhanced via Expr(). Middle one with UHDHalf=true (SMdegrain default) and the right one with UHDHalf=false, limit=255.
Quite a difference but it shouldn't be overrated, as it just shows that more mv areas have been found in context to the parameters I've used for this test.

https://abload.de/thumb/4k_filtered6ff7h.png (https://abload.de/image.php?img=4k_filtered6ff7h.png) https://abload.de/thumb/4k_mfilter_uhdhalf-tr49ig0.png (https://abload.de/image.php?img=4k_mfilter_uhdhalf-tr49ig0.png) https://abload.de/thumb/4k_mfilter_uhdhalf-fajeflc.png (https://abload.de/image.php?img=4k_mfilter_uhdhalf-fajeflc.png)

Script used:
#
ConvertBits(16)
ConverttoYUV444()
#
Stage=04
#
PRE1 = ConverttoYUV420().DGHDRtoSDR(mode="pq", white=1500, fulldepth=true).ConverttoYUV444().ex_unsharp(-min(0.5,(Stage/30.)))
PRE2 = PRE1.ex_Median(mode="IQMST",Y=3,UV=3).ex_sbr(r=2,UV=3)
PREv = PRE1.Merge(PRE2,(Stage/10.)).ex_unsharp(min(0.5,(Stage/30.)), Fc=width()/1.5).Levels(0,1.2,255*256,(Stage*1.5*256),max(128*256,(278-(Stage*24))*256))
#
SMDegrain(mode="MDegrain", tr=12, DCT=5, thSAD=(Stage*60), thSADc=(Stage*40), thSCD1=(200+(Stage*60)), Str=2.0, contrasharp=true, LFR=(Stage*40), DCTFlicker=true, refinemotion=true, truemotion=false, blksize=16, search=5, pel=2, subpixel=3, mfilter=Expr("81","90","250",scale_inputs="int"), prefilter=PREv, chroma=true, plane=4, gpuid=-1, interlaced=false, UHDHalf=false, limit=255)
#
ex_unsharp(min(0.5,(Stage/30.)), Fc=width()/1.5)
FilmGrainPlus(sharpness=0.5, size=0.05, str=0.05, strc=0)
#
ConverttoYUV420()
Prefetch(32)
Return(Last)


I'm still not sure about that 4:4:4 processing.
I can hardly see any differences and the file sizes are merely the same. Comparing frame by frame you can spot some subtle differences but those differences almost vanish when watching and comparing the clips side by side.
Considering it needs quite more processing power, as expected of course, I'll probably stay with 4:2:0. The tradeoff with encoding speed is not really worth it.

[anton_foy]

@LeXXuz
444 is mainly for the colors as with full RGB (correct me if Im wrong) but probably there will be very little gain in this case. Luma will be fully processed anyway.

[LeXXuz]

@LeXXuz
444 is mainly for the colors as with full RGB (correct me if Im wrong) but probably there will be very little gain in this case. Luma will be fully processed anyway.

I know. It might help on some old sources with more unstable colour planes. For this here it's overkill, but I left it in for the test anyway. :)

[DTL]

" not sure about that 4:4:4 processing.
I can hardly see any differences and the file sizes are merely the same. "

Yes - it is mostly for Die-Hard perfectionists.

[LeXXuz]

I think the default in mvtools is 255. What I want you to check is how it behaves for UHD sources (with UHDHalf=false) as I encountered some issues back then. If everything looks fine to you I change it back to 255 as dedault.

I've encoded the entire film now with limit=255 and UHDHalf=false. At first glance I can already say anton_foy was right. :)
The filtering quality is way better than with UHDhalf=true. Especially darker and/or low SAD areas have a lot more detail retention while even having more overall noise removal since the filze size got smaller than before.
If I have time, I will watch the entire film tonight.


Anything particular to look out for?

[Dogway]

I've encoded the entire film now with limit=255 and UHDHalf=false. At first glance I can already say anton_foy was right. :)
The filtering quality is way better than with UHDhalf=true.

Yes, that's a given, the problem was actually limit=255 while keeping the UHDHalf setting. I will run a few tests today and see how it behaves.


EDIT: Ok, this is what's going on. Specially when using UHDHalf=true, and also specially when paired with mode!=MDegrain (although it also shows with mode="MDegrain"), there's some detail warping.
I guess that to minimize this effect I chose to limit changes to no bigger than 2. It still warps details but it's not as exaggerated.
SMDegrain(tr=2, thSAD=400, mode="IQMT", limit=255, UHDHalf=true, prefilter=1, refinemotion=true) # prefilter=2 for UHDHalf=false

Source (3x zoom)
https://i.imgur.com/gec0fjqm.png (https://i.imgur.com/gec0fjq.png)

UHDHalf=false
https://i.imgur.com/F1FW4F6m.png (https://i.imgur.com/F1FW4F6.png)

UHDHalf=true
https://i.imgur.com/mv2qCGAm.png (https://i.imgur.com/mv2qCGA.png)

UHDHalf=true, Limit=2
https://i.imgur.com/l1rNqhRm.png (https://i.imgur.com/l1rNqhR.png)

[Guest]

SMDegrain(tr=2, thSAD=400, mode="IQMT", limit=255, UHDHalf=true, prefilter=1, refinemotion=true) # prefilter=2 for UHDHalf=false

To my eye's, it's hard to tell them apart...maybe the bottom one...

With the above call, where would be the best line to add them to, in my call, below ?

pre=ex_Median(mode="IQMST",thres=255).DGHDRtoSDR(mode="pq",white=2000)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=5.0,refinemotion=true)


:thanks:

[anton_foy]

@Dogway
Great find but I cannot see any images? I tried in two different browsers yet all I see is text.

@LeXXuz
Glad to be of help! Thanks for testing. :)

[anton_foy]

@FTLOY
Thanks but all I got was this:
https://tinypic.host/i/Screenshot-20230512-091027-Brave.o4eIHh

Btw. Those links are broken for me shows only a "broken image"-symbol. Nevermind.

[LeXXuz]

Yes, that's a given, the problem was actually limit=255 while keeping the UHDHalf setting. I will run a few tests today and see how it behaves.


EDIT: Ok, this is what's going on. Specially when using UHDHalf=true, and also specially when paired with mode!=MDegrain (although it also shows with mode="MDegrain"), there's some detail warping.
I guess that to minimize this effect I chose to limit changes to no bigger than 2. It still warps details but it's not as exaggerated.

The pictures are working for me and the difference is quite clear to see, I think.

Ah now I get it. Just to be clear, 'cause I think I mixed both modes up a little.

The DEFAULT is UHDHalf=true AND limit=2, right?
UHDHalf was added for performance reasons I guess, but there where some problems with details warping, so you chose to reduce limit to 2.

This does NOT apply to UHDhalf=false, which works fine with the limit of 255, but needs significantly more processing time of course.

But why is the limit still set to 2 with UHDHalf=false? Shouldn't it be set back to 255 automatically when user sets UHDHalf to false?

Personally I don't mind the speed penalty, I just set UHDHalf=false & the default limit=255 (unless it's too strong for some scenarios and I have to reduce it manually) from now on, as the result speaks for itself.

[LeXXuz]

To my eye's, it's hard to tell them apart...maybe the bottom one...

With the above call, where would be the best line to add them to, in my call, below ?

pre=ex_Median(mode="IQMST",thres=255).DGHDRtoSDR(mode="pq",white=2000)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=5.0,refinemotion=true)


:thanks:

You don't have to change anything in your script regarding UHDHalf unless you want more quality at the cost of a hefty speed penalty. Then you'll have to add UHDHalf=false, limit=255 to your SMDegrain call.

Btw. I would do the tone mapping first with DGHDRtoSDR before filtering the prefilter clip with ex_Median.
pre=DGHDRtoSDR(mode="pq",white=2000).ex_Median(mode="IQMST",thres=255)

[Guest]

@FTLOY
Thanks but all I got was this:
https://tinypic.host/i/Screenshot-20230512-091027-Brave.o4eIHh

Btw. Those links are broken for me shows only a "broken image"-symbol. Nevermind.

Here ya go, all zipped up, in all their glory..

https://www.mediafire.com/file/m8hgxpscb2w8yz1/UHD.7z/file

[Guest]

You don't have to change anything in your script regarding UHDHalf unless you want more quality at the cost of a hefty speed penalty. Then you'll have to add UHDHalf=false, limit=255 to your SMDegrain call.

Btw. I would do the tone mapping first with DGHDRtoSDR before filtering the prefilter clip with ex_Median.
pre=DGHDRtoSDR(mode="pq",white=2000).ex_Median(mode="IQMST",thres=255)

:thanks: very much for that LeXXuz, I will see how much of a speed hit it is.

[anton_foy]

Here ya go, all zipped up, in all their glory..

https://www.mediafire.com/file/m8hgxpscb2w8yz1/UHD.7z/file

Thank you! :)

[madey83]

Yes, that's a given, the problem was actually limit=255 while keeping the UHDHalf setting. I will run a few tests today and see how it behaves.


EDIT: Ok, this is what's going on. Specially when using UHDHalf=true, and also specially when paired with mode!=MDegrain (although it also shows with mode="MDegrain"), there's some detail warping.
I guess that to minimize this effect I chose to limit changes to no bigger than 2. It still warps details but it's not as exaggerated.
SMDegrain(tr=2, thSAD=400, mode="IQMT", limit=255, UHDHalf=true, prefilter=1, refinemotion=true) # prefilter=2 for UHDHalf=false

Source (3x zoom)
https://i.imgur.com/gec0fjqm.png (https://i.imgur.com/gec0fjq.png)

UHDHalf=false
https://i.imgur.com/F1FW4F6m.png (https://i.imgur.com/F1FW4F6.png)

UHDHalf=true
https://i.imgur.com/mv2qCGAm.png (https://i.imgur.com/mv2qCGA.png)

UHDHalf=true, Limit=2
https://i.imgur.com/l1rNqhRm.png (https://i.imgur.com/l1rNqhR.png)

when i look up on those screens i do not see "warping". To be honest i bearly see difference between them.
Could some one point me where i should look to see difference between pictures?

[anton_foy]

when i look up on those screens i do not see "warping". To be honest i bearly see difference between them.
Could some one point me where i should look to see difference between pictures?

Actually I agree I see just small differences on these examples. I used mode=temporalsoften though not mdegrain. The difference between uhdhalf=true/false on my footage was alot more visible. Can share if you want.

[madey83]

Actually I agree I see just small differences on these examples. I used mode=temporalsoften though not mdegrain. The difference between uhdhalf=true/false on my footage was alot more visible. Can share if you want.

@anton_foy yes please.

Can i use uhdhalf option when i encode 1080p or it is only designed to UHD source.

[madey83]

@Dogway,

is it posible you SMDegrain to remove grain from picture and if you could you please give an example how - how to point SMDegrain to take all pictures from folder and after degrain compress it to jpg again.
for movies i use StaxRip and defined insite it SMDegrain call, but for picture is for me something new.

Thank you in advance :)

[madey83]

To my eye's, it's hard to tell them apart...maybe the bottom one...

With the above call, where would be the best line to add them to, in my call, below ?

pre=ex_Median(mode="IQMST",thres=255).DGHDRtoSDR(mode="pq",white=2000)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=5.0,refinemotion=true)


:thanks:

I'm sorry for stupid question but why for HDR/DV source before degrain i need to use this call: "DGHDRtoSDR(mode="pq",white=2000)"?

i've done several denoising dolby vision source without it and for me looks identical in matter of colors after encode was done...

[Guest]

I'm sorry for stupid question but why for HDR/DV source before degrain i need to use this call: "DGHDRtoSDR(mode="pq",white=2000)"?

i done several denoising dolby vision source without it and for me looks identical in matter of colors after encode was done...

It was something suggested to me several weeks ago, so I just went with it.

And I asked a question here, and the reply I got from LeXXuz :-

https://forum.doom9.org/showthread.php?p=1987078#post1987078

[madey83]

It was something suggested to me several weeks ago, so I just went with it.

And I asked a question here, and the reply I got from LeXXuz :-

https://forum.doom9.org/showthread.php?p=1987078#post1987078

Does it mean the tone mapping is mandatory for SMDegrain to work on the source properly...?

[Guest]

Does it mean the tone mapping is mandatory for SMDegrain to work on the source properly...?

I can't really answer that, but I think it was only on HDR10 content, just to assist a particular filter/script.

It doesn't change HDR to SDR, tho.

[Dogway]

@FTLOY: You have to flip through the images, you won't see much differences as it is, just open them in tabs and flip through them, you will see the warping.

@LeXXuz: Probably a mistake on my part. I'm trying to guess my think process at the time.

I'm sorry for stupid question but why for HDR/DV source before degrain i need to use this call: "DGHDRtoSDR(mode="pq",white=2000)"?

i've done several denoising dolby vision source without it and for me looks identical in matter of colors after encode was done...
Computing motion vectors from a PQ log encoded clip is not a good idea because data is compressed and lacks contrast. That's why converting to SDR is recommended.

I did some extra tests and this is now my recommended call:
DGHDRtoSDR(mode="pq",white=XXX,gamma=1/2.4,tm=1.0)

is it posible you SMDegrain to remove grain from picture and if you could you please give an example how - how to point SMDegrain to take all pictures from folder and after degrain compress it to jpg again.
for movies i use StaxRip and defined insite it SMDegrain call, but for picture is for me something new.

SMDegrain is temporal, if you need to degrain single images use a spatial denoiser like KNLmeansCL, ex_bilateral, ex_minblur, or any kind of spatial median.

[LeXXuz]

@FTLOY: You have to flip through the images, you won't see much differences as it is, just open them in tabs and flip through them, you will see the warping.

That's actually what I did. :D


@LeXXuz: Probably a mistake on my part. I'm trying to guess my think process at the time.

No worries. ;)

[DTL]

"DGHDRtoSDR(mode="pq",white=XXX,gamma=1/2.4,tm=1.0)"

If follow the idea 'linear is better' it may be better to use 16bit linear (or for Die-Hard perfectionists - float32 linear). Or the gamma for 8bit (or 10bit) SDR may be adjusted based on some optimizing runs (like zopti ?) or individual users runs. So may be gamma closer to 1 (full linear) may run somehow better.

Also complete processing in SDR/linear for MDegrainX is not required - only MAnalyse can possibly benefit from running closer to linear. So it can process HDR in its natural transter domain (though it also may be not really good for linear blending). The best math results expected from linear processing (both MAnalyse and MDegrain) but linear HDR can not fit even in 16bit so only float32 (slowest) possible. Linear SDR of 8bit is only about 10bit so can be freely run in 16bit processing.

[Guest]

You don't have to change anything in your script regarding UHDHalf unless you want more quality at the cost of a hefty speed penalty. Then you'll have to add UHDHalf=false, limit=255 to your SMDegrain call.

Btw. I would do the tone mapping first with DGHDRtoSDR before filtering the prefilter clip with ex_Median.
pre=DGHDRtoSDR(mode="pq",white=2000).ex_Median(mode="IQMST",thres=255)

I tried this, and I get a error :(

This works:-

pre=ex_Median(video,mode="IQMST",thres=255).DGHDRtoSDR(mode="pq",white=2000)
video=STTWM(video,sw=50,tw=50,aw=100,sthres=5,tthres=5)
video=SMDegrain(video,tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=5.0,refinemotion=true)


This doesn't, has a DGHDRtoSDR error:- (fixed by adding the "red" video)

pre=DGHDRtoSDR(video,mode="pq",white=2000).ex_Median(mode="IQMST",thres=255)
video=STTWM(video,sw=50,tw=50,aw=100,sthres=5,tthres=5)
video=SMDegrain(video,tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=5.0,refinemotion=true)

[kedautinh12]

Are you got DGHDRtoSDR plugins or your GPU support it??

[kedautinh12]

Can help if you don't give an error alert

[LeXXuz]

I tried this, and I get a error :(


What is the error you're getting?

[Guest]

What is the error you're getting?

Well the first script that works was something I think you suggested a couple of weeks or so ago...

But the other day you suggested to swap the DGHDR end
for end, and that's the one that just throws a simple DGHDRtoSDR error, something about it can't find it or the syntax is wrong or something.

I can't provide the exact error right now.

[LeXXuz]

"DGHDRtoSDR(mode="pq",white=XXX,gamma=1/2.4,tm=1.0)"

If follow the idea 'linear is better' it may be better to use 16bit linear (or for Die-Hard perfectionists - float32 linear). Or the gamma for 8bit (or 10bit) SDR may be adjusted based on some optimizing runs (like zopti ?) or individual users runs. So may be gamma closer to 1 (full linear) may run somehow better.

Also complete processing in SDR/linear for MDegrainX is not required - only MAnalyse can possibly benefit from running closer to linear. So it can process HDR in its natural transter domain (though it also may be not really good for linear blending). The best math results expected from linear processing (both MAnalyse and MDegrain) but linear HDR can not fit even in 16bit so only float32 (slowest) possible. Linear SDR of 8bit is only about 10bit so can be freely run in 16bit processing.

You're right. And on many movies I deliberately deepen the luma ramp to get better results. Quite a lot of movies have strong noise especially in the whites, which means the SAD is particular high in these areas.

With a linear ramp I have to raise thSAD way too much to get these areas denoised while the blacks and even midtone areas (skins f.e. !), already lose way too much detail.

So either you have to live with only partial denoising, which looks even more ugly than the original imho, or risk destroying detail, especially in areas where it's important to keep.

So I use Levels() in the prefilter clip to flatten the luma curve from the upper whites.

I even had a very old movie which looked way better in the end with heavily compressed luma (Levels(0,1.2,255*256,0,128*256)) (!) than with the default curve. And m.e. was still fine, even with that very low contrast.

BUT I also had the opposite where I really needed HDR-SDR conversion to get more contrast in the picture. A very foggy scene f.e. where peoples faces are barely visible, yet you have I nice amount of film grain in there + the compressed range. Have fun denoising that without losing those faces.
Unless you want to go with more fancy stuff like masking and such. Which is where I decided to draw the line of how much effort I'm willing to put into every single film.

So, as we know, there is no holy grail that works best for all contents.

[LeXXuz]

But the other day you suggested to swap the DGHDR end
for end, and that's the one that just throws a simple DGHDRtoSDR error, something about it can't find it or the syntax is wrong or something.

I can't provide the exact error right now.

Provide some when you have the time.
Like kedautinh12 already said, without a proper error message it's hard to tell what's going on. ;)

[kedautinh12]

FTLOY make me remember about old man, comment bug without error message :D

[DTL]

" get these areas denoised while the blacks and even midtone areas (skins f.e. !), already lose way too much detail."

It may be possible to make some level-depending mixer (using Layer/Overlay) and creating simple mask from (blurred) luma channel. So it will mix denoised and original noised clips based on (average/blurred) luma mask and it should allow to separately put to output high/mid/low luma parts of frame with weight from 0 to 100% from either denoised or original noised clip.

If it is frequently useful it may be added to 'limit' post-processing in the MDegrainN. May be auto-masking with some control values (gamma, high/low clipping) or external 0..255 single channel mask clip input.

[anton_foy]

" get these areas denoised while the blacks and even midtone areas (skins f.e. !), already lose way too much detail."

It may be possible to make some level-depending mixer (using Layer/Overlay) and creating simple mask from (blurred) luma channel. So it will mix denoised and original noised clips based on (average/blurred) luma mask and it should allow to separately put to output high/mid/low luma parts of frame with weight from 0 to 100% from either denoised or original noised clip.

If it is frequently useful it may be added to 'limit' post-processing in the MDegrainN. May be auto-masking with some control values (gamma, high/low clipping) or external 0..255 single channel mask clip input.

Very good I think we have the same approach since I use to merge filtered and original to send to prefiltering. Usually it works better than fully procesed.

[Guest]

Provide some when you have the time.


Well, I figured it out, it turned out to be very simple, and I'm almost embarrassed to say, so I won't. :rolleyes:

Fixed (https://forum.doom9.org/showthread.php?p=1987108#post1987108)

:thanks:

[LeXXuz]

Very good I think we have the same approach since I use to merge filtered and original to send to prefiltering. Usually it works better than fully procesed.

That is an interesting idea. Would you mind sharing your script for this before I have to start experimenting with this from scratch? :o

[LeXXuz]

I need some help with NNEDI3/CL.

Even with gpuid=-1 set in SMDegrain, NNEDI3CL is still used instead of NNEDI3.

TransformsPack, ResizersPack and SMDegrain are latest versions.

Oddly enough: if I remove NNEDI3CL from my plugins and select pel=4 but subpixel=3, I still get an error that there is no function NNEDI3CL in Transforms and Resizerspack :confused:

https://abload.de/thumb/2023-05-1517nvfvh.png (https://abload.de/image.php?img=2023-05-1517nvfvh.png)

Plus, I still have a VRAM memory leak with RTX 30 cards. NNEDI3CL uses up all VRAM. This does not happen with GTX 10 models, AMD RX or Intel ARC. Anyone made similar experience with NNEDI3CL?

[Dogway]

Ok I'm going to have a look now.

Meanwhile I wanted to ask for suggestions. Should I default UHDHalf to false? is it not too slow?
And second given my previous post about detail warping with UHDHalf, would you unregardless recommend defaulting 'limit' to 255 (and just add a warning about the artifact on the documentation and the workaround)?

Also I'm working on another Gamut Compression alternative for TransformsPack, looks great.

[LeXXuz]

Ok I'm going to have a look now.

Meanwhile I wanted to ask for suggestions. Should I default UHDHalf to false? is it not too slow?

I'd go with quality over quantity any day. But it may be too much of a speed penalty on an average desktop system.

Maybe leave it as it is but with a more obvious hint to a "Quality" mode for 4k content in the docs or the script header?

Personally I completely overlooked the UHDHalf setting. And without anton_foy's comment I still wouldn't know there is a reduction in pecision for 4k by default.


And second given my previous post about detail warping with UHDHalf, would you unregardless recommend defaulting 'limit' to 255 (and just add a warning about the artifact on the documentation and the workaround)?

I haven't done much testing with the limit yet. Isn't there anything in between 2 - 255 to make that effect a little less obvious/strong?

[Dogway]

I'd go with quality over quantity any day. But it may be too much of a speed penalty on an average desktop system.
What speed are we talking about? for example at a reference CPU on a UHD 16:9 aspect 24fps title. My reference is between 3fps and 5fps using x264 to encode a 2h title in about 8h (overnight) given only SMDegrain is used which is an optimistic take.

I haven't done much testing with the limit yet. Isn't there anything in between 2 - 255 to make that effect a little less obvious/strong?
So it is indeed obvious? Well, maybe I should pass the responsibility to MVTools' vector scaling and not assume strange defaults in SMDegrain.

[LeXXuz]

What speed are we talking about? for example at a reference CPU on a UHD 16:9 aspect 24fps title. My reference is between 3fps and 5fps using x264 to encode a 2h title in about 8h (overnight) given only SMDegrain is used which is an optimistic take.

Well, define reference CPU first. :D

Like I said, quality over quantity for me.
I encode everything with custom 10-bit presets for x265 which are somewhere between the build-in "Slower" and "Very Slow" preset. So those alone demand much more processing power than any x264 preset. Plus, I probably use much more demanding settings in SMDegrain than the average user. The biggest challenge here was to create workflows that nearly saturate my CPUs.

So around 5fps is an accustomed speed area for me, while others probably rather hang themselves than dealing with those speeds :D


So it is indeed obvious? Well, maybe I should pass the responsibility to MVTools' vector scaling and not assume strange defaults in SMDegrain.

It is to me. But others barely noticed the difference looking at the comments regarding your screenshots. Depends if you know what to look for and probably on what screens you watch your content.

[Dogway]

Thanks, so what's your CPU that you get 5fps with UHD denoising with UHDHalf=false and encoding in x265 (provide also 'tr')? That would make a reference ground to compare. For me a CPU from the 8th Gen or so onwards would be reference.
I just tested NNEDI3CL and got no issues with SMDegrain(2,pel=4,subpixel=4,gpuid=-1) with and without NNEDI3CL on the plugins path, what's your call and source?

I made some changes to defaults and documentation fixes, once this NNEDI3CL issue is solved I upload the new update.

[LeXXuz]

Note to myself: Never fiddle with your posts in the middle of the night on a tiny tablet. Somehow I managed to kill my last post. :confused::rolleyes:

So once again in short form:

Thanks, so what's your CPU that you get 5fps with UHD denoising with UHDHalf=false and encoding in x265 (provide also 'tr')? That would make a reference ground to compare. For me a CPU from the 8th Gen or so onwards would be reference.

That is with a Ryzen 7950x and more demanding settings in SMDegrain including custom filter chains for mfilter and prefilter. Plus debanding and FilmGrainPlus afterwards. All in 16 bit. Temporal radius I always use multiples of 6 which I found to be most effective. So most of the time tr=6 in some rare cases 12.
I also have two Ryzen 5950x and a 3950x machine. Which are about 25%, respective 40% slower than the 7950x.

If you like I can run some tests with parameters you usually use for a better comparison.




I just tested NNEDI3CL and got no issues with SMDegrain(2,pel=4,subpixel=4,gpuid=-1) with and without NNEDI3CL on the plugins path, what's your call and source?

I made some changes to defaults and documentation fixes, once this NNEDI3CL issue is solved I upload the new update.

I solved this. It was a fault on my end. I had more than one instance of NNEDI3 and NNEDI3CL in my plugin-folder after running some updates due to slightly different naming. So the new versions did not overwrite the old ones but got copied into the plugin-folder leaving the old ones. That must have caused some confusion in Avisynth. Sorry for the trouble. :o

But the VRAM leak is still present with RTX30. But I guess that is a problem between NNEDI3CL and Nvidia drivers.

[Dogway]

Yes, the 3950x is comparable to i7-8700 (about 10% faster though). The 7950x is about 90% faster than the 8700. So a simple test is ok without all the bells and whistles. This should target 4fps minimum.


# SDR 3840x2160 YUV420 limited source (P16 or P8)
ConvertBits(16)
SMDegrain(tr=3, UHDHalf=false, limit=255, refinemotion=true)
ConvertBits(8,dither=1)

# And encode with x264 or x265, with slow or medium preset.

EDIT: Finally updated SMDegrain to v4.4.0

[anton_foy]

That is an interesting idea. Would you mind sharing your script for this before I have to start experimenting with this from scratch? :o

Sorry for late reply, here is one you can try (with or without ex_unsharp):

w=last.width()
hq=convertbits(8,dither=-1).ConvertToYv12()
hq=hq.hqdn3d(0,0,12,12,13,mt=true).merge(hq,0.37).removegrain(11).ColorYUV(levels="tv->pc",gamma_y = 200).ex_unsharp(300/1800., Fc=w/8., th=0.0, UV=1)

Edit: this is the prefilter only, for smdegrain, mdegrain or mocomped temporal denoiser. Converted to yv12 for speed.

[StainlessS]

Note to myself: Never fiddle with your posts in the middle of the night on a tiny tablet. Somehow I managed to kill my last post. :confused::rolleyes:

TextAreaCache, originally suggested by HolyWu. [FireFox AddOn, also for Chrome]

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

[LeXXuz]

Yes, the 3950x is comparable to i7-8700 (about 10% faster though). The 7950x is about 90% faster than the 8700. So a simple test is ok without all the bells and whistles. This should target 4fps minimum.


You mean single core performance, right? In overall performance a i7-8700 is nowhere near a 3950x.

I'll do a speed test with your code on my machines. And post the results soon. :)

TextAreaCache, originally suggested by HolyWu. [FireFox AddOn, also for Chrome]

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


Thanks StainlessS! :) That could be a lifesaver next time I'm too dumb to use my fingers right. :D

[Dogway]

No, multi-threaded. Play with Prefetch to optimize performance. In any case I uploaded v4.4.0 because I have many pending projects and want to move on.
Probably today I upload v1.9 of TransformsPack with new Gamut Compression function.

[LeXXuz]

No, multi-threaded.

How can a 6C/12T i-8700 be any close to a 16C/32T 3950x :confused:

https://ark.intel.com/content/www/us/en/ark/products/126686/intel-core-i78700-processor-12m-cache-up-to-4-60-ghz.html

Unless we're talking about a different CPU, there is no way on earth this CPU would be as fast as a 3950x in multi-threading ;)

https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i7-8700+%40+3.20GHz&id=3099
https://www.cpubenchmark.net/cpu.php?cpu=AMD+Ryzen+9+3950X&id=3598

[Dogway]

They seem to be on par (https://cpu.userbenchmark.com/Compare/Intel-Core-i7-8700-vs-AMD-Ryzen-9-3950X/3940vs4057) for 4-cores. For 8-cores is about 40% faster but I don't know if AviSynth can really leverage 8-cores.

[LeXXuz]

They seem to be on par (https://cpu.userbenchmark.com/Compare/Intel-Core-i7-8700-vs-AMD-Ryzen-9-3950X/3940vs4057) for 4-cores. For 8-cores is about 40% faster but I don't know if AviSynth can really leverage 8-cores.

Avisynth can perfectly handle high core counts as long as the filters play along.

Here are the results with your SMDegrain settings for 3840x2160 source:
https://abload.de/thumb/speedtest_5950xkzdgg.png (https://abload.de/image.php?img=speedtest_5950xkzdgg.png)

From top left to bottem right:
tl: x264 Medium @ CRF20, tr: x264 Slow @ CRF20
bl: x265 Medium @ CRF20, br: x265 Slow @ CRF20

Taken on a system with 5950x CPU as can be seen in the screenshot.
Should be easy enough to interpolate that onto a 7950x or 3950x or your i7-8700.

As you can see the CPU is fully saturated with Prefetch(32).
The jobs were run in sequence of course and not parallel. I just paused them and left the windows open for better comparison.

Unless you have a rather old CPU I think UHDHalf=false is perfectly feasible considering the quality improvement.

[Dogway]

Thanks for the tests!
I read that for some people, maybe more complex scripts anything higher than Prefetch(4) or 6 didn't bring more performance. Anyway I don't use anything else than my signature rig so I set the 8700 as the cut off since it was a considerable performance step up compared to previous gens.

The 5950x is quite a monster so I expected a bit better numbers than those specially for such a simple script. I will keep the setting as 'false' for a while I think.

Will update TransformsPack as soon as I can, today if I have some time. Really excited for the new feature.

[Guest]

Thanks for the tests!
I read that for some people, maybe more complex scripts anything higher than Prefetch(4) or 6 didn't bring more performance. Anyway I don't use anything else than my signature rig so I set the 8700 as the cut off since it was a considerable performance step up compared to previous gens.

The 5950x is quite a monster so I expected a bit better numbers than those specially for such a simple script. I will keep the setting as 'false' for a while I think.

Will update TransformsPack as soon as I can, today if I have some time. Really excited for the new feature.

It's a shame that you only have access to a fairly old CPU (might have been a powerhouse in its day, but not so much, now).

I think it would make a significant difference to your settings, if you were able to upgrade.

And if you think a 5950X is a "monster", a 7950X shame's it !!!

[Dogway]

Well lately I've been only developing not really encoding/rendering. Even then I switched to Redshift render engine which is GPU based. And for the next 2 years I'll be doing some APPs in Dart.

I will wait until the market relaxes a bit, today prices are inflated and then I'll move to the next Xeon, even if it's the bottom tier. Not really digging this performance/efficiency core system and no AVX512 on top of that, also looking forward to AVX-1024, AMX2, TSX, DDR6 and PCI Gen6, and RTX5000 with path tracing for the GPU with some meaningful RAM+CUDA count.

[DTL]

"DDR6"

After Xeon Max with at least 64 GB of HBM integrated starts shipping in 2023 it looks DDR-SDRAM died in the past for high-performance computing. I hope for poor and dying end-users PCs for homes market intel (or may be AMD) can provide HBM-based CPU compute platform in close years. Still some hope exist.

Also the total compute platform architecture finally redesigned again - from poor host RAM with fast CPU and non-x86/64-compatible compute accelerator(s) mounted via PCIe bus intel finally moves to high-performance CPU+RAM factory assembled module with 20x faster RAM speed and it compatible with all x86/64 software and can use standart periferal and also graphics/DCA PCIe adapters if needed.

It can be designed to poor-people low-LGA CPU socket motherboards with 2ch DDR-SDRAM if expansion required.

[Guest]

Well lately I've been only developing not really encoding/rendering. Even then I switched to Redshift render engine which is GPU based. And for the next 2 years I'll be doing some APPs in Dart.

I will wait until the market relaxes a bit, today prices are inflated and then I'll move to the next Xeon, even if it's the bottom tier. Not really digging this performance/efficiency core system and no AVX512 on top of that, also looking forward to AVX-1024, AMX2, TSX, DDR6 and PCI Gen6, and RTX5000 with path tracing for the GPU with some meaningful RAM+CUDA count.

It's a shame that the 13th Gen Intel's dropped AVX512 support, and the P-cores & E-cores complicate the situation, a little.

However, the 7950X does have AVX512 support, and ALL cores do the job equally (kind of).

In my experience, the 7950X is just a little better than a 13900 (except maybe the 13900KS), when encoding.

But things just keep getting too expensive :(

[DTL]

How can a 6C/12T i-8700 be any close to a 16C/32T 3950x :confused:



The computing may be simply RAM-speed limited because AVS make most of data storage in main host RAM.

The simple 6ch DDR4 6 cores Xeon may run at 1800+ fps and any cores 2ch DDR4/5 based CPU may be limited to about 1000 fps - https://forum.doom9.org/showthread.php?p=1987162#post1987162

[Guest]

"DDR6"

After Xeon Max with at least 64 GB of HBM integrated starts shipping in 2023 it looks DDR-SDRAM died in the past for high-performance computing. I hope for poor and dying end-users PCs for homes market intel (or may be AMD) can provide HBM-based CPU compute platform in close years. Still some hope exist.

Also the total compute platform architecture finally redesigned again - from poor host RAM with fast CPU and non-x86/64-compatible compute accelerator(s) mounted via PCIe bus intel finally moves to high-performance CPU+RAM factory assembled module with 20x faster RAM speed and it compatible with all x86/64 software and can use standart periferal and also graphics/DCA PCIe adapters if needed.

It can be designed to poor-people low-LGA CPU socket motherboards with 2ch DDR-SDRAM if expansion required.

I don't think saying "poor people" is very polite....

[DTL]

"It's a shame that the 13th Gen Intel's dropped AVX512 support"

Intel optimize general-public (really shrinking and dying) market of home PCs to the standard performance tests to be comparable with AMD goods of the same season. So as general public market software close to no benefit from AVX512 and fast RAM - the marketing goods will continue to fight for best fps in Microsoft Word. So no AVX512 and no HBM RAM may reach general public CPUs any more.

For intel it is better to add E-cores with simple AVX2 (and 2 cores of AVX2 can overload simple 2ch DDR4/DDR5 RAM config - no need to put 1 core of AVX512 with about 4x more performance). So it will be comparable in MS Word and 7zip and all other standard marketing tests to make money in each season.

If you will look in the every-year home PCs tests - the intel and AMD is about +-10..30% of performance only. It is simple making money every year - not making high-performance compute platforms for users of smartphones.

Real HPC is Datacenters/Enterprise in 2023 and it is Xeon Max now.

For 8-cores is about 40% faster but I don't know if AviSynth can really leverage 8-cores.

AVS can start whatever required by user threads with Prefetch() and it will be displayed in Task Manager as busy CPU cores. But each thread is also a chain of filters and each filter is surrounded with large software cache located in host RAM. So Busy CPU cores typically spin idle loops and waiting for RAM. It is not thread-logical idle state so Task Manager of OS do not show core idle. It can be found in the hardware performance counters in VTune for example.

[kedautinh12]

It's a shame that you only have access to a fairly old CPU (might have been a powerhouse in its day, but not so much, now).

I think it would make a significant difference to your settings, if you were able to upgrade.

And if you think a 5950X is a "monster", a 7950X shame's it !!!

Old man was said: "7950x don't different with 5950x" :D

[Boulder]

Thanks for the tests!
I read that for some people, maybe more complex scripts anything higher than Prefetch(4) or 6 didn't bring more performance. Anyway I don't use anything else than my signature rig so I set the 8700 as the cut off since it was a considerable performance step up compared to previous gens.

The 5950x is quite a monster so I expected a bit better numbers than those specially for such a simple script. I will keep the setting as 'false' for a while I think.

Will update TransformsPack as soon as I can, today if I have some time. Really excited for the new feature.
The thing with Prefetch is that you have to control the number of frames or the performance will suffer (because the default is threads x 2 I think). Threads can always be set to the maximum number available IMO. For example, I use Prefetch(threads=32, frames=12) on my 5950X. Lowering the amount of prefetched frames will also have a positive effect on memory usage which is often an issue with 4K stuff and Avisynth cache being what it is..

[Guest]

Old man was said: "7950x don't different with 5950x" :D

Who is this "old man" you keep referring to ?

A 7950X with the right settings is WAY better than a 5950X !!!

[kedautinh12]

Who is this "old man" you keep referring to ?

A 7950X with the right settings is WAY better than a 5950X !!!

He is
https://forum.doom9.org/member.php?u=244197

[LeXXuz]

So Busy CPU cores typically spin idle loops and waiting for RAM. It is not thread-logical idle state so Task Manager of OS do not show core idle.

Would you mind linking a source for that?

I have not encountered this under Win11 so far. Quite the contrary where other tools report CPU usage but Task Manager not.
That happens upon starting scripts with heavy GPU load and memory usage. HWI reports quite high CPU usage while Win11 TM doesn't.

. For example, I use Prefetch(threads=32, frames=12) on my 5950X.

Why 12 frames exactly? In any relation to the filters you use?

Well, if you guys think that was way too slow, I'm happy to test with different settings for comparison.

[Boulder]

Why 12 frames exactly? In any relation to the filters you use?
I've tested different combinations and that produced the best performance over multiple kinds of sources with threads=32. I mostly use the same framework script for every source and just tune the parameters so the load on CPU is pretty much the same anyway. It's particularly important to test it by running the encoder with your normal settings since it will affect CPU scheduling greatly.

[DTL]

"Would you mind linking a source for that?"

You can run any software profiler and look at the timestamps around load from memory operations (in disassembly view). From freeware AMD uProf . Loading from memory is not any compute operation - it simply CPU core stall because no data to continue compute. But it is thread taking CPU time so Task Manager will show core load time (it not show real computing load - it only show % of time thread using core time).

Thread waiting for data can not free CPU core resources because thread switching is very costly operation. The only possible is in 'hyperthreading' mode when 2 threads uses 1 core resources the stalling thread waiting for memory may be switched to other thread if it got ready to compute data. So 'hyperthreading' sometime really make some total performance benefit.

The more advanced intel VTune will also show you lots of performance counters around cache misses and so on. Also VTune can create some hints about how much the application is memory-performance bounded (after analysis of memory-performance counters).

The real indirect way to estimate compute load is look into CPU Power usage - any real computing part make switching and in CMOS it takes some power. Stalling in idle parts in CMOS not draw power and not produce heat. So CPU engine put parts to idle zero power state if nothing to compute. So the more power draw to CPU and more heat produced - the more real useful computing is performed. Or at least some about useful shuffling of data in lots of caches (L1,L2,(L3,L4)). The AVX2 and AVX512 compute units running with good load draw lots of power and produce lots of heat (so typically CPU clock trotled to save from overheating).

CPU temp may be used to estimate how compute software is optimized for compute at current chip - with fixed cooling the CPU temp increases as software make more compute switching at given time. It not mean it is useful compute but at least not stall waiting for something.

"I have not encountered this under Win11 so far"

I still not see Win11 - may be Microsoft make some redesign of performance measurement tools in that version. If all supported CPU vendors provide required hardware performance counters. In old times OS can only measure thread time at core (OS knows start and end time of thread at core and can measure 'physical time' using common RDTSC instruction).

[LeXXuz]

The real indirect way to estimate compute load is look into CPU Power usage - any real computing part make switching and in CMOS it takes some power. Stalling in idle parts in CMOS not draw power and not produce heat. So CPU engine put parts to idle zero power state if nothing to compute. So the more power draw to CPU and more heat produced - the more real useful computing is performed. Or at least some about useful shuffling of data in lots of caches (L1,L2,(L3,L4)).

Well, looking at the temps and reported values for TDC, EDC and PPT, I'd say the CPU pretty much has its hands full and isn't really idling very much. :D

And between Prefetch 2,4,8,16, and 18...32 there's a quite good linear scale from 2 to 16, with almost double the prefetch = double the performance. After that the gradient drops with increasing prefetch but performance still increases and tops out with ~32. So I see no reason not to use 32 threads on a 16C/32T CPU.

I'll post a speed test between 'untouched', UHDHalf=true and UHDHalf=false with the 7950x soon for another comparison.

[Dogway]

@LeXXuz: I forgot to say, are you using DGSource() or a CPU bound loader? it makes substantial difference.

I think Xeon Max is enterprise tier, I'm looking forward Diamond Rapids w3 or w5, whatever delivers 8c/16t at least. And the thing with AVX512 is that not all are created equal, Intel now says they are going to bring it to mainstream line but does it include AVX512-VNNI?

[DTL]

I hope the Xeon Max (already renamed in several months after 'Sapphire Rapids HBM') is only one of many new families names in the future. May be end-user chip will be named i7-15xxx or more numbers. Or i9-15xxx, i11-xxxx and so on.

" 8c/16t at least."

Hyperthreading typically good only if it is close to free addition. Only after all other hardware resources are fully filled (max possible channels of RAM and max possible ways in the caches and so on). If the same priced less cores without HT but offer more DDR RAM channels - it may be faster with well optimized software. Also not very great optimized software may somehow benefit from more ways in the caches (Xeons may have 12..24 ways and low quality chips 8..12 ways at L2/L3). If the processing datasets fits in the L2/L3 caches.

"AVX512-VNNI?"

The only known real benefit from NN is may be deinterlacing with fighting special separated fields aliasing. And the interlaced content moves to the past now. I not know any other processing with real benefit from NN on CPU. May be if civilization will not die too quickly we can see 4:2:0 to 4:4:4 decoding of the same high quality as deinterlacing - but it may be visible to Die-Hard perfectionists only. The general benefit of AVX512 is 4x larger register file of AVX2 and 2x wider dispatch ports and lots of new faster instructions for simple integer 8/16 bit operations typically exist in F/BW/DQ/VL/VBMI old series. 202x years expected to be season of AVX512 most members in all CPU chips at the market but something go not as nice as expected. Also the software still very poorly optimized even for AVX2 and number of programmers with understanding in SIMD looks like fast shrinking too. So if we even have AVX512 everywhere - there already close to nobody knows how to program it. The 512 bytes AVX2 register file already not very easy to keep in mind about data placement - and AVX512 is 4x times larger. Only really nice (typically young) great brains can make nice fast handcrafted software for 2048 bytes data array and with complex computing (not simple 2x expanding of old poorly designed AVX2 software). Or with degrading and dying of real humans we need to some NN-robots to design nice AVX512 programs - still not exist may be.

[Dogway]

I think we need general NN support at CPU level as well since as we know the future is AI based and frees us up from those time-consuming/low-reward tasks.
My only real concern with future hardware is if they are going back to the efficiency road path as lately everything consumes and heats way over I consider stable.

By the way I updated TransformsPack with a new gamut compression function ported from Jed Smith:

ConvertFormat(cs_in="ACEScg",cs_out="709",EOTFi="",GC=true)

TM_Hable(mode="Dark",filmic=false)
CCTF("1886",false, tv_out=false)

ConvertBits(8,dither=1)

ACEScg - Linear
http://i.imgur.com/TmY8C8em.png (https://i.imgur.com/TmY8C8e.png)

709 - 1886
http://i.imgur.com/ikZuKucm.png (https://i.imgur.com/ikZuKuc.png)

709 - 1886 (+Gamut Compression)
http://i.imgur.com/TPJHjnkm.png (https://i.imgur.com/TPJHjnk.png)

Since probably all these samples are scene referred (radiance based) they look bland, lacking the filmic punch.
You can try setting 'filmic' to true for either Dark or Bright 'mode'. But I prefer the following.
Here's an example using LMT_DCP() (DCP Tone Curve OOTF)
TM_Hable(mode="Dark",filmic=false)
LMT_DCP()
CCTF("1886",false,tv_out=false)
709 - 1886+DCP OOTF (+Gamut Compression)
http://i.imgur.com/vtMSoXFm.png (https://i.imgur.com/vtMSoXF.png)

And here using LMT_EMoR() instead, a typical Camera Response Function fit. It's an OOTF+EOTFi so we suppress the 1886 inverse EOTF:
TM_Hable(mode="Dark",filmic=false)
LMTi_EMoR(tv_range=false)
709 - EMoR OOTF/EOTFi (+Gamut Compression)
http://i.imgur.com/kXJFFtHm.png (https://i.imgur.com/kXJFFtH.png)


EDIT: Same as above with LMT_EMoR() but with updated GamutCompression with non-linear integration of negative values
709 - EMoR OOTF/EOTFi (+Gamut Compression Updated)
http://i.imgur.com/5G2PTVnm.png (https://i.imgur.com/5G2PTVn.png)

[LeXXuz]

@LeXXuz: I forgot to say, are you using DGSource() or a CPU bound loader? it makes substantial difference.


No. I've used LSMASH. On purpose. The 7950x machine has no Nvidia GPU that can decode HEVC as I have no use for that.
Otherwise it wouldn't be a fair comparison between both systems.

The GT 710 is fine and fast enough for frameserving MPEG-2 and AVC. And the Intel ARC is great for OpenCL filters but doesn't support CUDA of course.
I usually don't do UHD content. For various reasons. This one was just for testing out of curiosity.

Anyhow, here is the same content encoded with a Ryzen 7950x system:

https://abload.de/thumb/speedtest_7950x_28zfph.png (https://abload.de/image.php?img=speedtest_7950x_28zfph.png)

Again, top-left to bottom-right:

tl: x265 medium preset CRF20, UHDHalf=true, Prefetch(16)
tm: x265 medium preset CRF20, UHDHalf=false, Prefetch(16)
tr: x265 medium preset CRF20, no filtering in Avisynth

bl: x265 medium preset CRF20, UHDHalf=true, Prefetch(32)
bm: x265 medium preset CRF20, UHDHalf=false, Prefetch(32)
br: x265 medium preset CRF20 AVX512, no filtering in Avisynth

UHDhalf=false benefits a little from Prefetch 32 over 16, while
UHDhalf=true is about the same. Already noticed this with more demanding scripts for 1080p too.

Lastly a comparison between default AVX2 and allowing AVX512. Difference is negligible, as I expected. But mileage may vary with different content.

Anyhow, I'm fine with these numbers.

[Dogway]

Thanks for the tests, the 7950x is a monster CPU so I think the numbers are fine, UHDHalf=true does almost a 63% perf increase so I think it's fine given people would resort to more convoluted scripts and filtering.
I don't know what filters do make use of AVX512 in AviSynth so I can't tell. My interest in the instruction is more for 3D DCC and games (if I ever happen to find time for that).

[anton_foy]

My footage in uhd is very sharp/finely detailed I guess and when using temporalsoften mode in uhdhalf=true it is considerably blurrier compared to uhdhalf=false. Not nearly as little difference as to LeXXuz comparison examples. Is there a way to regain the detail/sharpness by pel or something and yet gain the speed from mscalevector somewhat?

[Dogway]

My footage in uhd is very sharp/finely detailed I guess and when using temporalsoften mode in uhdhalf=true it is considerably blurrier compared to uhdhalf=false. Not nearly as little difference as to LeXXuz comparison examples. Is there a way to regain the detail/sharpness by pel or something and yet gain the speed from mscalevector somewhat?
Can you post a before-after? TemporalSoften is very aggressive so it will make the shortcomings of vector scaling more apparent. You can try as mentioned earlier with limit=2 or something along those lines, and obviously 'LFR'. I think something is going on on the vector scaling and could be revisited on the mvtools2 side.

By the way I ported (https://github.com/Dogway/emulation-random/blob/master/MPC-HC/Shaders/DolbyVision.hlsl) a few functions like ICtCp_to_RGB(), GamutCompression() or TM_Hable() to an .hlsl shader to decode IPTPQc2 content on real time. It doesn't read the RPU so no dynamic tonemapping, MMR or poly reshaping but the output looks very fine.

[anton_foy]

Can you post a before-after? TemporalSoften is very aggressive so it will make the shortcomings of vector scaling more apparent. You can try as mentioned earlier with limit=2 or something along those lines, and obviously 'LFR'. I think something is going on on the vector scaling and could be revisited on the mvtools2 side.

By the way I ported (https://github.com/Dogway/emulation-random/blob/master/MPC-HC/Shaders/DolbyVision.hlsl) a few functions like ICtCp_to_RGB(), GamutCompression() or TM_Hable() to an .hlsl shader to decode IPTPQc2 content on real time. It doesn't read the RPU so no dynamic tonemapping, MMR or poly reshaping but the output looks very fine.

Yes probably so I want to try with the same footage with mdegrain mode also to see the difference but as for now and a while forward I haven't got access to my computer so I will post when I do. The limit param I need to experiment with too. Thanks!

[Tempter57]

Dogway

Dear master, will pay the attention that QTGMC 4.2 + mod causes appearance of artefacts round objects. It is forced to be rolled away back on QTGMC 4.00 + mod or I apply QTGMC v3.384s by A.SONY. I process in the core results of digitization old VHS interlaced camcoders and source DVC

[Dogway]

Dear master, will pay the attention that QTGMC 4.2 + mod causes appearance of artefacts round objects. It is forced to be rolled away back on QTGMC 4.00 + mod or I apply QTGMC v3.384s by A.SONY. I process in the core results of digitization old VHS interlaced camcoders and source DVC

Can you provide a small sample and the QTGMC+ call? I'm curious to know since v4.1 and v4.2 only implemented sharper base bob deinterlacers.

[Tempter57]

Can you provide a small sample and the QTGMC+ call? I'm curious to know since v4.1 and v4.2 only implemented sharper base bob deinterlacers.

Source https://www.dropbox.com/s/ctokgarx58c0sd0/la_rambla.avi?dl=0
Script
prefix="C:\Program Files (x86)\AviSynth+\"
AddAutoloadDir(prefix+"plugins64")

setmemorymax(8000)

DirectShowSource2("C:\Users\Alex\Downloads\la_rambla.avi", fps=25.000, preroll=15)

LoadVirtualDubPlugin("C:\Program Files (x86)\AviSynth+\plugins64\VirtualDub\ccd_64.vdf", "ccd", 0)

ChangeFPS(last,last,true) # initiate a small forward buffer

# pointresizing for lossless RGb <> YCrCb convertion
pointresize(last.width, last.height*2).ConvertToRGB32(interlaced=true, matrix="Rec709").pointresize(last.width, last.height)
separatefields() ## Remove some chroma noise with CCD in RGB (gives best results)
ccd(12,1)
weave()
pointresize(last.width, last.height*2).converttoYUV422(matrix="Rec709",interlaced=true).pointresize(last.width, last.height)

/*
converttoYUV422(matrix="Rec709",interlaced=true)
src=last
CCD(30)
CombinePlanes(src, last, src, planes="YUV")
*/

#==== Deinterlaced ====
AssumeBFF()
QTGMCp(Preset="placebo", NoiseProcess=0, threads=1)
#QTGMC(Preset="placebo", NoiseProcess=0, edithreads=1)
#QTGMCp(Preset="fast", sharpness=0.3, threads=1)
mergechroma(last)

stabplus(dxmax=16, dymax=16)
Crop(12, 4, -8, -0)

yahr().yahr()
# FineDehalo(rx=2.0, ry=2.0, thmi=80, thma=128, thlimi=50, thlima=100, darkstr=0, brightstr=1.0, showmask=0, contra=0.0, excl=true)
LSFmod(defaults="Fast", strength=40, Smode=3, Smethod=2, kernel=11, secure=false, Lmode=1, soft=0, soothe=true, keep=48, edgemode=1, edgemaskHQ=true)

deep_resize(960, 720, grain=0,qual=2)

SmoothCurve(Ycurve="0-0;16-16; 255-235", Ucurve="0-0;77-72;127-127;172-177;255-255", Vcurve="0-0;77-72;127-127;172-177;255-255", interp=100, limiter=false, TVrange=0, dither=-1)
SmoothLevels(0,0.96,255,0,255, useopt=0, HQ=true, useMT=1) # 0 -automatic choice, 1- SSE2 CPU, 2 - Sandy Bridge CPU

ex_unsharp(0.15).ex_unsharp(0.15,Fc=width()/1.5)

# ==== DEBANDING + ADDGRAIN ====
neo_f3kdb(15,64,42,42,0,0,sample_mode=2,dynamic_grain=true,keep_tv_range=true,dither_algo=3,mt=false)

gr = 0.3
size = 0.8
GrainFactory3mod(g1str=6*gr,g2str=8*gr,g3str=5*gr,g1size=1.4*size,g2size=1.3*size,g3size=1.2*size,g1cstr=1.5*gr,g2cstr=0.8*gr,g3cstr=0.5*gr,temp_avg=1,tv_range=true)

ConvertToYV12(interlaced=false, matrix="Rec709")

AssumeFPS(50.00)
Prefetch(12,24)
Compare result with variants QTGMC(Preset="placebo", NoiseProcess=0, edithreads=1) QTGMC v3.384s mod by A.SONY or QTGMC 4.00 + mod

[Dogway]

Thanks! I could see the issue, just tested the QTGMC+ part of your script. Basically it's a detail vs anti-moiree balance.
For the first half of the video everything looked fine but as soon as it couldn't resolve combing (artifact heavy motion areas) it created those issues.

I reverted the new default EdiModes to v4.0 except when the new arg 'moiree' is enabled.
In either case output now is more detail preserving than in v4.0.

Probably a good improvement would be to mask moiree areas so we could have the best of both worlds.

Check new version here (https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/QTGMC+.avsi).

[Tempter57]

Dogway
Unfortunately the problem with QTGMC 4.3 + mod remained. I have tried even to place QTGMC +. avsi in other folder, thought that the conflict of plug-ins is possible.

[Dogway]

Unfortunately the problem with QTGMC 4.3 + mod remained. I have tried even to place QTGMC +. avsi in other folder, thought that the conflict of plug-ins is possible.

Then I don't know what the issue you refer to. Mind posting a screenshot or something? The plugin versions required are listed on the top of the script.

[Tempter57]

Then I don't know what the issue you refer to. Mind posting a screenshot or something? The plugin versions required are listed on the top of the script.
Here three results of different versions QTGMC https://dropmefiles.com/e2wWu. The password of archive 123

[Dogway]

I tested encoding that portion and got no issues. Ensure the plugin versions and that you are on AVS+ 3.7.3 test9, I can't vouch for later git versions.

The problem however might be in the loader or what you process before the QTGMC+ call (I don't have the CCD plugin so I don't know).
Also it might be that DSS2 messes with frameprops. Try using FFMS2.
Also unrelated but there's no such thing as lossless RGB<->YCbCr, and less with point resize, you are matrixing so point resize will in some form leak into luma.
For lossless you can try YCoCgR but you need to upscale to 444 with an interpolation kernel.

[Tempter57]

I used AVS+ 3.7.3 test9.
The conflict reason really in incompatibility QTGMC + 4.1 mod and above with DSS2, and also filter VirtualDub ccd_64.vdf. At connection FFMS2 and removal in a script of the lines connected with ccd_64.vdf a problem disappears.
But after all truth that QTGMC + 4.0 mod and more low worked with DSS2. I admit, if the conflict has been caused only ccd_64.vdf, but with the advent of problems at application DSS2 I can not reconcile and I do not wish. I will be forced to refuse application QTGMC + 4.3 mod or you try to eliminate in the subsequent versions this defect.

[DTL]

"# pointresizing for lossless RGb <> YCrCb convertion
pointresize(last.width, last.height*2).ConvertToRGB32(interlaced=true, matrix="Rec709")"

With Rec709 matrix it can not be lossless because of clipping superwhites and superblacks. And with PC.709 matrix it was found required additional Levels() preprocessing for input YUV to make more correct RGB decoding - https://forum.doom9.org/showthread.php?p=1987708#post1987708 . It looks AVS still have lots of internal shadows of the past as amateur-designed software. So it hard to believe it can do something lossless enough. Also most of processing in 8bit interfilters data transfers adds quantization noise at each step.

" application DSS2"

DS is completely random source depending on the total system DS environment configured. So if user like to use DSS in any stable way it need to cure all OS DS environment (and keep it from any changes like even Windows update). Also developers can not check if bug happen remotely without getting and somehow running locally complete remote user DS OS configuration snapshot. It is close to impossible for private persons developers.

[Dogway]

I used AVS+ 3.7.3 test9.
The conflict reason really in incompatibility QTGMC + 4.1 mod and above with DSS2, and also filter VirtualDub ccd_64.vdf. At connection FFMS2 and removal in a script of the lines connected with ccd_64.vdf a problem disappears.
But after all truth that QTGMC + 4.0 mod and more low worked with DSS2. I admit, if the conflict has been caused only ccd_64.vdf, but with the advent of problems at application DSS2 I can not reconcile and I do not wish. I will be forced to refuse application QTGMC + 4.3 mod or you try to eliminate in the subsequent versions this defect.

Thanks for testing!
If DSS2 or other loader tags the clip as progressive or a different field order, that's a bug on the loader and not on my side.
AVS+ workflow is frame property based, if you want old school workflow you should switch to AviSynth 2.6 and use old tools otherwise you will run into numerous unexpected issues not only with my filters but also Asd-g plugins and filters.

[Tempter57]

Thanks you for explanations

[salvo00786]

Hi Dogway. I want to report that in your latest version of SMDegrain, the v4.4.0d, the prefilter 4 doesn't work, the program give an error. The other prefilters are ok.

[Guest]

Hi Dogway. I want to report that in your latest version of SMDegrain, the v4.4.0d, the prefilter 4 doesn't work, the program give an error. The other prefilters are ok.Line 322 (https://github.com/Dogway/Avisynth-Scripts/blob/master/SMDegrain/SMDegrain.avsi#L322)

No problems here, with existing script :(

Can you provide error message ?? (I know I forget to do that, from time to time)

[salvo00786]

Yes, this is the error

https://drive.google.com/file/d/1YeCP9ziRoOxjtr50GNkY1y4wImCjaHyi/view?usp=share_link

If I use the old SMDegrain instead of the latest, with the same settings, the error doesn't appear

[kedautinh12]

Yes, this is the error

https://drive.google.com/file/d/1YeCP9ziRoOxjtr50GNkY1y4wImCjaHyi/view?usp=share_link

If I use the old SMDegrain instead of the latest, with the same settings, the error doesn't appear

Are you got latest ver of avs+??
https://gitlab.com/uvz/AviSynthPlus-Builds

[salvo00786]

I am using the latest version of Staxrip. I have to check what version of avs+ is in the program.

[salvo00786]

I don't know if I am wrong, but I downloaded the latest avisynth+ from your link and I overwrited the files in the staxrip directory with the files downloaded. But when I use SMDegrain, the same error appear.

[Guest]

I don't know if I am wrong, but I downloaded the latest avisynth+ from your link and I overwrited the files in the staxrip directory with the files downloaded. But when I use SMDegrain, the same error appear.

You may have to modify the call a little bit..

pre=ex_Median(mode="IQMST")
SMDegrain(tr=6,thSAD=600,thSADC=300,contrasharp=true,prefilter=pre,refinemotion=true)

Might be an idea to also ask the question on the StaxRip thread...

[Dogway]

@salvo00786: Update ExTools and try again. IQMST was a last addition, even so it's already a few months ago.

[Guest]

@salvo00786: Update ExTools and try again. IQMST was a last addition, even so it's already a few months ago.

Does StaxRip use or support Extools ???

Just checked, it's under the "x\Apps\Plugins\AVS\Scripts\ExTools.avsi"

At least v10.0, but latest here, is v10.2

[madey83]

Hello,

is there any way to improve details retantion of this call and also remove more background grain?

pre=ex_Median(mode="IQMST", UV=3,thres=15)
pre=ex_blend(pre,"blend",opacity=0.5).ex_median("IQMV").ex_sbr(1,UV=3)

my_TR = 3 # 4/5 depends on the grain
my_thSAD = 400
my_thSCD1 = my_thSAD + 100
my_thSADC = my_thSAD - 100

SMDegrain(mode="TemporalSoften", tr=my_TR, thSAD=my_thSAD, thSADC=my_thSADC, thSCD1=my_thSCD1, thSCD2=110, Str=2.0, limits=false, refinemotion=true, prefilter=pre, chroma=true, plane=4, search=5, subpixel=3)

[madey83]

Does StaxRip use or support Extools ???

Just checked, it's under the "x\Apps\Plugins\AVS\Scripts\ExTools.avsi"

At least v10.0, but latest here, is v10.2

i use Staxrip 2.18 and i aways import/load below:

import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\GradFun3plus.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\ExTools.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\SMDegrain\SMDegrain.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\ResizersPack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\LSFplus.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\SharpenersPack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\GradePack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\ScenesPack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\MasksPack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\Spresso.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\EX mods\DeblockPack.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\TransformsPack - Main.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\TransformsPack - Models.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\TransformsPack - Transfers.avsi")
loadplugin("E:\4k_encode\BM3DCUDA_AVS-test9\x64\BM3DCPU_AVS.dll")
loadplugin("E:\4k_encode\BM3DCUDA_AVS-test9\x64\BM3DCUDA_AVS.dll")
loadplugin("E:\4k_encode\BM3DCUDA_AVS-test9\x64\BM3D_VAggregate_AVS.dll")
loadplugin("E:\4k_encode\dgdecnv_244\DGDecodeNV.dll")
loadplugin("E:\4k_encode\vsTCanny-1.1.8\x64\Release\vsTCanny.dll")
loadplugin("E:\4k_Encode\neo_FFT3D_r11\x64\neo-fft3d.dll")
loadplugin("E:\4k_Encode\fmtconv-r30\win64\fmtconv.dll")
loadplugin("E:\4k_Encode\avs_libplacebo-1.1.4\x64\Release\avs_libplacebo.dll")
loadplugin("E:\4k_Encode\ClipClop_x86_x64_dll_v1-26_20181222\Avisynth+_x64\ClipClop_x64.dll")
loadplugin("E:\4k_Encode\DGHDRtoSDR_1.15\DGHDRtoSDR.dll")

and i do not have any problem with SMDegrain calls

[Guest]

i use Staxrip 2.18


I don't use StaxRip, but hopefully this help salvo...

[StainlessS]

Madey83,
loadplugin("E:\4k_encode\dgdecnv_244\DGDecodeNV.dll")
DgDecNv currently on v247.
https://www.rationalqm.us/dgdecnv/binaries/

Not sure, I think versions about 244 could produce garbled frame if jumping about within the clip,
but if step back a dozen or so frames and then stepping forward frame by frame, did not produce garbled frame on the original bad one.
Have not noticed similar behaviour recently, so is maybe fixed in v247.

EDIT: Actually, Seems it was updated yesterday, is now v248.

[madey83]

Madey83,

DgDecNv currently on v247.
https://www.rationalqm.us/dgdecnv/binaries/

Not sure, I think versions about 244 could produce garbled frame if jumping about within the clip,
but if step back a dozen or so frames and then stepping forward frame by frame, did not produce garbled frame on the original bad one.
Have not noticed similar behaviour recently, so is maybe fixed in v247.

EDIT: Actually, Seems it was updated yesterday, is now v248.

thx :)

[Dogway]

madey83: You are using very strong filters there, for instance IQMST paired with TemporalSoften. Without seeing your source this could be too much. Maybe use a milder prefilter and increase thSAD. Settings vary a lot from source to source.

Also there are updated versions of your plugins:
avs_libplacebo-1.2.0
BM3DCUDA_AVS-test10-cuda118
ClipClop_x86_x64_dll_v1-27_20210727

[salvo00786]

Hi... Thanks for all your replies. I tried with Staxrip 1.18 and I updated Extools, but the error is the same.

[madey83]

madey83: You are using very strong filters there, for instance IQMST paired with TemporalSoften. Without seeing your source this could be too much. Maybe use a milder prefilter and increase thSAD. Settings vary a lot from source to source.

Also there are updated versions of your plugins:
avs_libplacebo-1.2.0
BM3DCUDA_AVS-test10-cuda118
ClipClop_x86_x64_dll_v1-27_20210727


Hi Dogway,

my main problem is that i have not enough powerfull CPU on my PC, and i always try to get as much as possible clean picture (targeting bitrate between 2-3 Mbps for 1080p) with possible high details remain as possible and of course speed is important for me too. With above settings of SMDegrain + LSFplus + neo_f3kdb i got ~4 fps which is quite low in my opinion.

i have tried also below settings:

pre=STTWM(sw=50,tw=50,aw=100,sthres= 5,tthres=5) # Balanced

my_TR = 3 # 4/5 depends on the grain
my_thSAD = 500
my_thSCD1 = my_thSAD + 100
my_thSADC = my_thSAD - 100

SMDegrain(mode="STWM", limit=255, UHDHalf=true, prefilter=pre, tr=my_TR, thSAD=my_thSAD, thSADC=my_thSADC, thSCD1=my_thSCD1, thSCD2=110, LFR=false, limits=false, DCTFlicker=false, refinemotion=true, search=5, subpixel=3)

but remove grain was not enough. Rising TR and thSAD did not remove grain more... only reduced speed of encode.

this is the picture example where i would like to get clean background but have remain as much as possible details on foreground

https://postimg.cc/tZpLdbf8

[DTL]

Typically to visibly remove more grain and got less MPEG output bitrate at fixed crf-value it is require to make much larger tr-value adjustments (like doubling of tr-value only make photon shot noise about sqrt(2) lower). So playing around tr of 3,4,5 may be not any visible (also doubling of tr typically make processing fps half lower). To make some more visible step in subtle degraining it is more benefitical to move from linear FIR-type filter (like in current 2.7.45 MDegrainX) to IIR-type (also non-linear) filter (like pmode=2 in post 2.7.45 builds and VSTTempSmooth my tech demo). The IIR-type filter can remember best block or sample value over tr-scope and continue output it (equal to frame-duplicate but at block or sample level) and make most MPEG-friendly frame sequence to encode.

FIR-type filter linear because of its math can not reach such samples stability over many frames with not very large tr-values. And residual very small samples non-stability over sequence of frames to encode still create very high 'noise bitrate' to MPEG encoder.

So it may be recommended to wait until new processing modes will be 'officially' released in mvtools/vsttempsmooth (or sample-based vsttempsmooth-like processing will be also integrated as additional mode into MDegrainN as planned depending on some algorithm like for blocks with too bad SAD/dismetrc and so like). Not waste time and CPU/power to use too outdated mvtools manalyse/degrain of about 1..2 decade old. Even with some scripting enchancements over very old and simple FIR-type linear degrain engine. Playing around very simple manalyse/mdegrain engine of 200x years design can not make degraining better and better each year with some 'prefiters' shuffling and simply increasing tr and thSAD. The old 2.7.45-mvtools based denoiser may reach its limits already at 201x years.
I hope if pinterf will have time in 202x years we may still see updated mvtools version 'stable' of post-2.7.45 version number with many new features added. So Dogway will make redesign of SMDegrain for better degrain performance.

I understand users like to make encodings today and not wait years and decades for next better version of software - but things become slower and slower now. After very powerful design of opensource software in 200x years users may be used to have more and more advanced software releases several time per year and now in 202x as most of opensource at current planet and current EU+US civilization is died already it may be only 1 new updated release per decade or even more rare.

[Dogway]

madey83: Update a sample clip so I can have a look. Typically this is a matter of configuring a nice prefilter. What CPU do you have? So I can compare to mine which isn't top notch either.

[madey83]

madey83: Update a sample clip so I can have a look. Typically this is a matter of configuring a nice prefilter. What CPU do you have? So I can compare to mine which isn't top notch either.


@Dogway

Regarding my CPU it is ashamed to admit by it is i7 10750h....

example:
https://mega.nz/file/8QgQSTbQ#Y2XXFl4te93JnrZ1qBClec9e1VpEw3oSclOZDl1LoPs

this is my entire call which gives me bitrate ~3500 Kbps, and yes i know HDR/DV source should have DGHDRtoSDR but i can't properly find white point of my source and i think some colors are shifted/not match to the source. I will update this matter in next time, when i will see this...

edit:
ConvertBits(16)

deep_resize(1920,edge="Zopti1080")
MaxFALL=22 #check for DV/HDR white point

pre=DGHDRtoSDR(mode="pq",white=MaxFALL,gamma=1/2.4,tm=1.0).ex_Median(mode="IQMST", UV=3,thres=15)
pre=ex_blend(pre,"blend",opacity=0.5).ex_median("IQMV").ex_sbr(1,UV=3)

my_TR = 3 # 4/5 depends on the grain
my_thSAD = 400
my_thSCD1 = my_thSAD + 100
my_thSADC = my_thSAD - 100

SMDegrain(mode="MDegrain", tr=my_TR, thSAD=my_thSAD, thSADC=my_thSADC, thSCD1=my_thSCD1, thSCD2=110, Str=2.0, limits=false, refinemotion=true, prefilter=pre, chroma=true, plane=4, search=5, subpixel=3)
LSFplus(strength=50, preset="LSF", secure=true, Lmode=3, soft=-2, soothe=true, Smode=3, Smethod=3, Szrp=16, Spwr=4, SdmpLo=4, SdmpHi=48, overshoot=1, undershoot=1, Overshoot2=1, Undershoot2=1, keep=20, edgemode=0)
neo_f3kdb(preset="veryhigh/nograin", dynamic_grain=false, sample_mode=2,keep_tv_range=false,dither_algo=3,mt=false)
fmtc_bitdepth(bits=10, dmode=7)
Prefetch(10,12)


FYI: i'm newbie in avisynth filtering, so this is my level of understanding how to use it.... :)

[LeXXuz]

this is my entire call which gives me bitrate ~3500 Kbps, and

Well if you care to bound your encodes to a certain bitrate you may tweak your encoder settings instead of trying to denoise your sources too much.
You can't 'denoise' any source down to your desired bitrate without losing too much detail at some point.

Why not do 'some' denoising for better compression and opt for a 2-pass encode at ~3.5Mbit instead of CRF?

[madey83]

Hi LeXXuz,

If I would have enough powerful CPU then I would be possible to do 2 pass encode, but I don't have it and double the time for single episode it is to much for me. That's the reason why I prefer CRF with denoising + plus clean sharp picture is my preference... :)

[LeXXuz]

So it may be recommended to wait until new processing modes will be 'officially' released in mvtools/vsttempsmooth (or sample-based vsttempsmooth-like processing will be also integrated as additional mode into MDegrainN as planned depending on some algorithm like for blocks with too bad SAD/dismetrc and so like). Not waste time and CPU/power to use too outdated mvtools manalyse/degrain of about 1..2 decade old. Even with some scripting enchancements over very old and simple FIR-type linear degrain engine. Playing around very simple manalyse/mdegrain engine of 200x years design can not make degraining better and better each year with some 'prefiters' shuffling and simply increasing tr and thSAD. The old 2.7.45-mvtools based denoiser may reach its limits already at 201x years.
I hope if pinterf will have time in 202x years we may still see updated mvtools version 'stable' of post-2.7.45 version number with many new features added. So Dogway will make redesign of SMDegrain for better degrain performance.

I understand users like to make encodings today and not wait years and decades for next better version of software - but things become slower and slower now. After very powerful design of opensource software in 200x years users may be used to have more and more advanced software releases several time per year and now in 202x as most of opensource at current planet and current EU+US civilization is died already it may be only 1 new updated release per decade or even more rare.

You know, you have a point there I think.
SMDegrain is an excellent script, but after many month and hundreds of tested configurations, it always came down to the very same conclusion that mvtools is the weak spot here and in its current state couldn't cut it to satisfy my needs and expectations of a high-class motion-based denoising workflow on more demanding sources.

I'm almost at the brink of saying I'd better buy more hard drives instead of wasting that money on energy cost for half-satisfying 'remastering' jobs of my collection which I may regret one day.

And here is the big problem I see for any future development. 20 years ago disc space was expensive and hard drive space even more. So lots of people were looking for smarter solutions to back up their content. Hence began a vast development in filters and codecs to reduce file sizes while maintaining or even improving quality. I've been here long enough and witnessed most of that evolution.

Today, storage space is cheap. Talking TB now instead of GB two decades ago. In the same time storage cost went down, energy cost went up constantly. Making video transcoding less and less attractive to many people. In my circle of friends I'm the only one left still caring about encoding efficiency and video filtering. All the other guys do is backing up their discs to their storage networks and be done with it.

And here I am, still wasting lots of money on a somewhat outdated 'profession' with results that don't even fully convince me in the end. Makes you think.

I do hope mvtools will get the updates one day it really needs to greatly improve motion-based denoising methods to a level that can satisfy ambitious quality expectations.
But like you said, we need the people that have the time and knowledge to code and implement those things. And these people get more rare every year.

Don't want to get this OT and like I said, Dogways script is excellent but it can only do as much as its core element. It's like having a Porsche with an old VW engine. Looking awesome at first glance but gets more unsatisfying the deeper you look into it.

[Guest]

Hi... Thanks for all your replies. I tried with Staxrip 1.18 and I updated Extools, but the error is the same.

Have you tried StaxRip 2.19.0 ??

https://forum.doom9.org/showthread.php?p=1987631#post1987631

And did you try the script I suggested ??

https://forum.doom9.org/showthread.php?p=1987812#post1987812

[DTL]

And here I am, still wasting lots of money on a somewhat outdated 'profession' with results that don't even fully convince me in the end. Makes you think.

I do hope mvtools will get the updates one day it really needs to greatly improve motion-based denoising methods to a level that can satisfy ambitious quality expectations.
But like you said, we need the people that have the time and knowledge to code and implement those things. And these people get more rare every year.



If pinterf is currently have low time and busy with AVS core - the only known other good programmer is Asd-g with many AVS plugins supported and some supplementing with required SIMD/bitdepth and other features for today usage. May be open a petition to take mvtools after pinterf and add my partially implemented features to make bugfixed 'stable' build at least with most simple and usefull features added (of total current list about 40+ new features) ? Or may be even open crowdfanding project to collect some money to pay to good programmer to make new better build. After this the Dogway may make additional tests and finally update SMDegrain with new version of mvtools.

I tried to send request to Asd-g for maintaining mvtools versions after 2.7.45 of pinterf build with as most as possible of my additions and will wait for answer.

[kedautinh12]

Asd-g won't touch mvtools if Pinterf still development it

[DTL]

But last release from pinterf was in mid of 2021. Now it is about 2 years passed and still no expected merging of my new features into builds by pinterf or may be new features from pinterf. As I see he simply do not have time because being busy with AVS core and also understanding in 'complex-200x' mvtools is not easy for many-projects programmer.

The processing in my builds up to 2023 in MAnalyse/MDegrainN become even more complex - so it may be even more hard for universal programmer to take it for support. So it was the original idea of pinterf in 2021 - lets keep mvtools of old design unchanged because close to no one understand how it is working so any new features will make project even more harder to support.

So I ask Asd-g not simply take pinterf version but make some combined from my 'branch' and 'stable pinterf' to port as many new features as possible at least for quality of denoising. The really complex to development multi-block search modes based on AVX2 and AVX512 SIMD computing may be skipped for todays very limited developers resources because it is only performance boost and also we have now hardware accelerated DX12-ME modes for MAnalyse and it can be used at least at first generations of multi-generations MVs search.

As mvtools is currently main API for AVS for motion search and some MC-denoise and used by many scripts it is good to have at least a few active developers per year or may be per decade (as things become slower and slower in compare of expected 'singularity of digital civilization from too fast and constantly increasing in speed progress' in the early 200x years).

[salvo00786]

Yes, I started with Staxrtip 2.19.0, and after that I tried go backwards.
Yes I tried with your script, but the error is the same. I don't know why this doesn't work. It's strange.

[Guest]

Yes, I started with Staxrtip 2.19.0, and after that I tried go backwards.
Yes I tried with your script, but the error is the same. I don't know why this doesn't work. It's strange.

Well, that's not good :(

Have you asked on the StaxRip thread ?? (I haven't seen your name there).

Emulgator left an interesting post...

As the suggestions given here, haven't worked either :(

[anton_foy]

So here are the two problem clips im using and the "man" clip is noisier and more problematic than the "sheep" clip.

IMAGES (https://imgsli.com/MTgzNTM4/0/2)
Raw Clips UHD 55mb (https://we.tl/t-0CS13HCzLO)

Speed/Quality:
On my slow computer I get the fastest speed with
smdegrain uhdhalf=true but much less detail/more blurry than set to false.

The DTL-script with DX12ME is a little bit slower than the above but a bit faster than smdegrain uhdhalf=false although the DTL-script denoises the least and too much temporal instabilities are left. I think I am not using DTL's version correctly since I did not understand all the new params so Im sorry if I do it unjustice. Also I should raise the tr but then it gets too slow. Notice that I do not use any prefiltering with DTL's version, only its internal mvlpfGauss.

Mdegrain-script is pretty close to the smdegrain call but a little slower yet denoises more and still keeps alot of detail.

Here is the code for testing 3 different approaches by using SMDegrain (uhdhalf=true / false), DTL's mvtools version and a mdegrain-script:

SetMemoryMax(30200)
LSMASHVideoSource("C:\Users\era\Videos\man.mp4", decoder="h264_cuvid")
propclearall()
convertbits(16)
Levels(0, 1, 255*256, 0, 235*256, coring=false)
converttoYUV444()

cd=convertbits(8,dither=-1).convertToYv12()
hq=cd.hqdn3d(0,0,12,12,13,mt=true).merge(cd,0.33).removegrain(12).coloryuv(levels="tv->pc",gamma_y=190)#.invert("y").levels(0,0.5,255,0,255)#

#smdegrain#
smdegrain(tr=6,prefilter=hq,uhdhalf=true)

#mdegrain-script#
mdgr(tr=6,auxclip=hq,chroma=true)

#DTL#
super=MSuper(last, mt=false, chroma=true, pel=1, levels=1)
sup=MSuper(cd, mt=false, chroma=true, pel=1) # do not create refined subplanes for pel > 1
multi_vec=MAnalyse (sup, multi=true, blksize=8, delta=tr, overlap=0, chroma=true, optSearchOption=5, mt=false, levels=1, UseSubShift=1)
mdegrainn(last,super, multi_vec, tr, thSAD=350, thSAD2=340, IntOvlp=3,mt=false, wpow=4, thSCD1=400, adjSADzeromv=0.5, adjSADcohmv=0.5, thCohMV=16,
\ MVLPFGauss=0.9, thMVLPFCorr=50, MPBthSub=10, MPBthAdd=20, MPBNumIt=2)


deblock(planes="UV")
neo_F3KDB(grainY=0,grainC=0,mt=false,output_depth=16,range=30).mergechroma(last)

Convertbits(10,dither=1)
prefetch(4)
# prefetch(2) #for DTL's version

# MDegrain-function:
function mdgr(clip Input, clip "auxclip", int "thSAD", int "thSADC", int "TR", int "BLKSize", int "Rb", int "Overlap", int "Pel", bool "Chroma", int "Shrp", int "Rad", float "thr", bool "tm", float "Falloff")
{
thSAD = default(thSAD, 150)
thSADC = default(thSADC, 230)
TR = default(TR, 6)
BLKSize = default(BLKSize, 32)
Overlap = default(Overlap, 16)
Rb = default(Rb, 8)
Pel = default(Pel, 1)
Chroma = default(Chroma, false)
Tm = default(Tm, false)
Falloff = default(Falloff, 0.9)
Shrp = default(Shrp, 56)
Rad = default(Rad, 1)
Thr = default(Thr, 1.21)
aux = defined(auxclip)

w = width(input)
h = height(input)
isUHD = (w > 2599 || h > 1499)
nw = round(w/2.0)
nh = round(h/2.0)

inputA = aux ? auxclip : input

super = input.unsharpmask_hbd(shrp,rad,thr,uv=1).MSuper(pel=pel, hpad = 0, vpad = 0, chroma=chroma, mt=false, levels=1, sharp=1)
superfilt = MSuper(inputA,pel=pel, hpad = 0, vpad = 0, mt=false,sharp=1)
Multi_Vector = Superfilt.MAnalyse(Multi=True, Delta=TR, BLKSize=BLKSize, Overlap=Overlap, Chroma=Chroma, truemotion=tm ,global=true)
vmulti2 = Mrecalculate(superfilt,multi_vector,thsad=thsad,truemotion=false,tr=tr,blksize=rb,overlap=rb/2,mt=false,chroma=true)

Input.MDegrainN(Super, vmulti2, TR, thSAD=thSAD, thSAD2=Int(thSAD*Falloff), thSADC=thSADC, thSADC2=Int(thSADC*Falloff))
}


EDIT: To really get the noise removed which I would like then I usually add neo_vd(1.5,1,6,96) or (2.0,1,6,96) but it smears the finer details too much. And if I limit it with ex_limitdif or some edge filtering it is slow.

If you like to see how the chroma is affected with my B/W 3DLUT try this out:
OrtoChromatic-LUT (https://we.tl/t-mZ5AkR7jms)

[DTL]

For really slow processing and possibly better MVs you can try the multi-generations approach of MAnalyse/MDegrain sequence described in https://forum.doom9.org/showthread.php?p=1984152#post1984152 . My tests shows already 2nd generation produces much better MVs. But it require to play with much more params (for MAnalyse and MDegrain at each stage). And it require updated MAnalyse with 2-inputs. MVLPF processing can not do too much with very noisy MVs from single (first) generation MVs search. Also MVLPF currently is FIR-only so to be more effective require not very small tr-setting (>10 is recommented). IIR-type of MVLPF with possible better results at small tr-values is planned but not yet implemented.

Example of using DX12-ME and onCPU MAnalyse in multi-generations MVs refining was in https://forum.doom9.org/showthread.php?p=1984176#post1984176 .

Also as final non-linear cleanup may be used additional MDegrain with pmode=1 from https://forum.doom9.org/showthread.php?p=1984527#post1984527 .

And yes - may be even small progress in denosing require many computing (like 3 Mdegrain in a sequence minimum is recommended in 2023 - first generation of pre-degrain, main (second gen) MDegrain, final non-linear MEL-mode statistical refining, each with tr>10 expected to be better). Each generation of MAnalyse/Mdegrain have its own sets of params. At least thSAD(s) between first and second generation is(are) completely different.

[anton_foy]

Also as final non-linear cleanup may be used additional MDegrain with pmode=1 from https://forum.doom9.org/showthread.p...27#post1984527 .

I tried this but it takes several minutes to even get it to start and I get this (https://www.imagebam.com/view/MELJQA4)
When I try to go forward in the timeline vdub crashes after several more minutes. I tried the FIR-mode in vsttempsmooth which seemed very interesting so I think it may have potential. It is the same mode for MDegrain or am I wrong?

EDIT: Sorry Dogway I realized this does not belong in your thread. Just thought maybe SMDegrain could benifit from DTL's version in the future hopefully when optimized.

[DTL]

Oh - it looks 16bit (and YUV444) really not work in my builds for many processing modes. Sorry. So it is really the task for good programmers to cover many real used bitdepth/blocksize combinations. I still live with only YV12. If that chroma error also happen with YV12 - post in DX12 thread the complete script example and I will try to see what is happen at least in that format.

The general idea for 2023 after some years of testing is about: If user want best possible denoise quality the single MAnalyse/MDegrain call is not enough (even with builds after 2.7.45). It is in theory possible to arrange several MAnalyse/MDegrain into single compiled 'filter' to make same processing as that multi-generation examples, but it may be much more complex to program also the number of params will be completely large for single filter call and it still not benefit for performance. So it will still require some 'complex scripting' like SMDegrain. And yes - to make processing of UHD frames with not very slow speed the powerfull enough machines required to run at least 2 MAnalyse (+MDegrain) in a sequence (better 3), may be with at least 1 DX12-ME hardware accelerator (though its quality is typical somehow lower in compare with onCPU MAnalyse with my GTX1060 experience).

Also to make quality tests with better performance it is not require to process all UHD frame - it is possible to crop only most interested region first like HD-sized or even SD-sized.

" It is the same mode for MDegrain or am I wrong?"

The implementation of statistical analysis is close but vsTTempSmooth is sample-based and MDegrainN is block-based. It require more tests to compare quality on different footages and noise/distortions types. Block-based statistical analysis expected to be better for noised sources, but it still only idea. Also some new ideas found while adding of IIR-mode to vsTTempSmooth (the memory update for better block/sample also, so memory keep not only best block/sample but also the 'statistical metric' of current stored in memory block/sample) still not transferred into MDegrainN. So next builds of MDegrainN may work a bit better.

Here is working example of compare of your posted params single MDegrain and 2-gen processing for YV12 sample clip man.mp4 from https://we.tl/t-0CS13HCzLO: . I think your tr is 6 ?

https://imgsli.com/MTgzNjIx frames 32 and 33 of interleaved clips.


# Input plugins
LoadPlugin("ffms2.dll")
LoadPlugin("mvtools2.dll")

SetFilterMTMode("DEFAULT_MT_MODE", 3)

my_thSAD=450
my_thSAD2=my_thSAD-20

my_thSAD_mg=250
my_thSAD2_mg=my_thSAD_mg-10

my_thSCD=my_thSAD+100

my_pzero=10
my_pnew=10
my_pglobal=10

my_pel=2
my_thCohMV=5 # 5..8 for pel=2, 10..16 for pel=4 ?
my_trymany=true

my_oPT=1
my_overlap=0
my_IntOvlp=3
my_searchparam=2

my_MPBNumIt=2

my_init_tr=12
my_refine_tr=12

Function RefineMV(clip mvclip, clip super_ref, clip src, int _thSAD, int _thSAD2, int in_tr, int refine_tr, int my_thSCD, int my_pel, bool my_trymany, int my_pnew, int my_pzero, int my_pglobal, \
int my_oPT, int my_overlap, int my_searchparam, int my_IntOvlp, int my_thCohMV)
{
g_next=MDegrainN(src, super_ref, mvclip, in_tr, thSAD=_thSAD, thSAD2=_thSAD2, mt=false, wpow=4, thSCD1=my_thSCD, adjSADzeromv=0.5, adjSADcohmv=0.5, thCohMV=my_thCohMV, \
MVLPFGauss=0.9, thMVLPFCorr=50, adjSADLPFedmv=0.9, IntOvlp=my_IntOvlp)
super_g_next=MSuper(g_next,chroma=true, mt=false, pel=my_pel)
return MAnalyse(super_g_next, SuperCurrent=super_ref, multi=true, delta=refine_tr, search=3, searchparam=my_searchparam, trymany=my_trymany, overlap=my_overlap, chroma=true, mt=false,\
optSearchOption=1, truemotion=false, pnew=my_pnew, pzero=my_pzero, pglobal=my_pglobal, global=true, optPredictorType=my_oPT)
}

Function RefineMV_HW(clip mvclip, clip super_ref, clip src, int _thSAD, int _thSAD2, int in_tr, int refine_tr, int my_thSCD, int my_pel, int my_thCohMV)
{
g_next=MDegrainN(src, super_ref, mvclip, in_tr, thSAD=_thSAD, thSAD2=_thSAD2, mt=false, wpow=4, thSCD1=my_thSCD, adjSADzeromv=0.5, adjSADcohmv=0.5, thCohMV=my_thCohMV, \
MVLPFGauss=0.9, thMVLPFCorr=50, adjSADLPFedmv=0.9, IntOvlp=3, UseSubShift=1)
super_g_next=MSuper(g_next,chroma=true, mt=false, pel=my_pel, levels=1, pelrefine=false)
return MAnalyse(super_g_next, SuperCurrent=super_ref, multi=true, delta=refine_tr, chroma=true, mt=false, optSearchOption=5, levels=1)
}

FFmpegSource2("man.mp4")

Crop(700, 540, 1300, 540)

noproc=last

#super_hwa=MSuper(last, mt=false, chroma=true, pel=my_pel, hpad=8, vpad=8, levels=1, pelrefine=false)
super_cpu=MSuper(last, mt=false, chroma=true, pel=my_pel, hpad=8, vpad=8, levels=0, pelrefine=true)

#multi_vec_hwa=MAnalyse(super_hwa, multi=true, blksize=8, delta=my_init_tr, overlap=0, chroma=true, optSearchOption=5, mt=false, levels=1)
multi_vec_cpu=MAnalyse(super_cpu, multi=true, delta=my_init_tr, search=3, searchparam=my_searchparam, trymany=my_trymany, overlap=my_overlap, chroma=true, mt=false, \
optSearchOption=1, truemotion=false, pnew=my_pnew, pzero=my_pzero, pglobal=my_pglobal, global=true, optPredictorType=my_oPT)

multi_vec_cpu2=RefineMV(multi_vec_cpu, super_cpu, last, my_thSAD, my_thSAD2, my_init_tr, my_refine_tr, my_thSCD, my_pel, my_trymany, my_pnew, my_pzero, my_pglobal, my_oPT, \
my_overlap, my_searchparam, my_IntOvlp, my_thCohMV)
#multi_vec_hybr2=RefineMV(multi_vec_hwa, super_cpu, last, my_thSAD, my_thSAD2, my_init_tr, my_refine_tr, my_thSCD, my_pel, my_trymany, my_pnew, my_pzero, my_pglobal, my_oPT, \
#my_overlap, my_searchparam, my_IntOvlp, my_thCohMV)
#multi_vec_hwa2=RefineMV_HW(multi_vec_hwa, super_hwa, last, my_thSAD, my_thSAD2, my_init_tr, my_refine_tr, my_thSCD, my_pel, my_thCohMV)

cpu2=MDegrainN(last,super_cpu, multi_vec_cpu2, my_refine_tr, thSAD=my_thSAD_mg, thSAD2=my_thSAD2_mg, mt=false, wpow=4, UseSubShift=1, thSCD1=my_thSCD, adjSADzeromv=0.7, \
adjSADcohmv=0.7, thCohMV=my_thCohMV, MVLPFGauss=0.9, thMVLPFCorr=50, adjSADLPFedmv=0.9, IntOvlp=my_IntOvlp, MPBthSub=5, MPBthAdd=20, MPBNumIt=my_MPBNumIt, \
MPB_SPCsub=0.5, MPB_SPCadd=1.5, MPBthIVS=2200, showIVSmask=false)
#hwa2=MDegrainN(last,super_hwa, multi_vec_hwa2, my_refine_tr, thSAD=my_thSAD_mg, thSAD2=my_thSAD2_mg, mt=false, wpow=4, UseSubShift=1, thSCD1=my_thSCD, adjSADzeromv=0.7, \
#adjSADcohmv=0.7, thCohMV=my_thCohMV, MVLPFGauss=0.9, thMVLPFCorr=50, adjSADLPFedmv=0.9, IntOvlp=my_IntOvlp, MPBthSub=5, MPBthAdd=20, MPBNumIt=my_MPBNumIt, \
#MPB_SPCsub=0.5, MPB_SPCadd=1.5, MPBthIVS=2200, showIVSmask=false).Weave().Subtitle("hwa2")
#hybr2=MDegrainN(last,super_hwa, multi_vec_hybr2, my_refine_tr, thSAD=my_thSAD_mg, thSAD2=my_thSAD2_mg, mt=false, wpow=4, UseSubShift=1, thSCD1=my_thSCD, adjSADzeromv=0.7, \
#adjSADcohmv=0.7, thCohMV=my_thCohMV, MVLPFGauss=0.9, thMVLPFCorr=50, adjSADLPFedmv=0.9, IntOvlp=my_IntOvlp, MPBthSub=5, MPBthAdd=20, MPBNumIt=my_MPBNumIt, \
#MPB_SPCsub=0.5, MPB_SPCadd=1.5, MPBthIVS=2200, showIVSmask=false).Weave().Subtitle("hybr2")

super_3=MSuper(cpu2, mt=false, chroma=true, pel=2, hpad=8, vpad=8, levels=0, pelrefine=true)
pnew_mel=MDegrainN(cpu2,super_3, multi_vec_cpu2, my_refine_tr, thSAD=250, thSAD2=240, mt=false, thSCD1=350, pmode=1, TTH_thUPD=100, IntOvlp=3)
#pnew=cpu2

tr_s=6
super_s=MSuper(noproc, mt=false, chroma=true, pel=1, levels=0)
multi_vec_s=MAnalyse (super_s, multi=true, blksize=8, delta=tr_s, overlap=0, chroma=true, optSearchOption=1, mt=false, levels=0)
p_s=mdegrainn(last,super_s, multi_vec_s, tr_s, thSAD=350, thSAD2=340, IntOvlp=3,mt=false, wpow=4, thSCD1=400, adjSADzeromv=0.5, adjSADcohmv=0.5, thCohMV=16,
\ MVLPFGauss=0.9, thMVLPFCorr=50, MPBthSub=10, MPBthAdd=20, MPBNumIt=2)

#Interleave(pnew_mel.Sharpen(0.7).Subtitle("pnew_mel"),cpu2.Sharpen(0.7).Subtitle("cpu2"), p_s.Sharpen(0.7).Subtitle("p_s"))
Interleave(cpu2.Sharpen(1.0).Subtitle("cpu2"), p_s.Sharpen(1.0).Subtitle("p_s"))

Prefetch(2) # for intel E7500 2 cores CPU


Using release https://github.com/DTL2020/mvtools/releases/tag/r.2.7.46-a.22 . CPU processing only (the DX12-ME ways are commented out - may be tested for quality/performance too where Win10 and required hardware avaialble). I not use last MDegrainN with pmode=1 because it mostly for better MPEG compression - for denoise and details it still may not show visible difference on static frames compare. Also it looks really cause crash somewhere with VirtualDub at some frames - need to debug later. Added Sharpen(1.0) to show small details better.

Also the example of multi-generation MVs refining is 'very simple' using only MDegrain as self-denoise engine for next gen MAnalyse. For more advanced scripts may be tested diffrerent immediate denoisers (like fft3d/bm3d/vsttempsmooth and others) or even some masked overlay of several different denoise engines using some mask-generation additional algorithm. Also the number of quality-defining params to adjust easily reach 50 or even 100 so it is better to use some Computer-Aided optimizing engines runs (zopti ?). And example params are only some quick adjusted sample based on some old footage to test. Also it is still not best/placebo settings but some more better in performance - for better quality the all predictors may be recommended at all generations (oPT=0) and searchparam >2 for esa search. Also the all penalties (pzero/pglobal/pnew) in onCPU MAnalyse may be also subject to individual adjustment at each generation (at least between 1 and 2). Also full/real_search overlap of blksize/2 may be recommended (not interpolated simulation for just 'deblocking'). That will make processing even more several times slower.

[Dogway]

Sorry I was a bit busy:

Regarding my CPU it is ashamed to admit by it is i7 10750h....

example:
https://mega.nz/file/8QgQSTbQ#Y2XXFl4te93JnrZ1qBClec9e1VpEw3oSclOZDl1LoPs

this is my entire call which gives me bitrate ~3500 Kbps, and yes i know HDR/DV source should have DGHDRtoSDR but i can't properly find white point of my source and i think some colors are shifted/not match to the source. I will update this matter in next time, when i will see this...

No shame there, it's an i7, only timing was a bit off due to lack of AVX2 but CPU development unlike GPU has only got worse (diminishing returns).

You cannot match MaxFALL because DGHDRtoSDR() doesn't understand the source. The colors are not shifted, they are simply encoded differently, namely they are encoded in IPTPQc2's Dolby propietary color model. This is good and bad at the same time, it makes a huge improvement on the over 40 years old YCbCr color model (wrongly known as YUV). It represents the most efficient method of encoding video so you get more (quality) with less (size), and it's been my goal to decode this for the last 2 years. It's based on the IPT color model which is a very good perceptual uniform color model but adapted for HDR -> IPT-PQ crosstalk 2%

This is where the bad news arise, some folks at ffmpeg and other places have been reverse engineering this model and a part of the model depends on something called the RPU which is nothing else than embedded metadata. Not only this metadata will specify the peak (programme or scene) white or colorimetry, but also a few things that make it difficult to decode without hurdles, that is scene based metadata transfer functions (the MMR or polynomial depending on DV profile) and also a trim pass (check the color tint jump from frame 191 to 192).

I managed to decode the static parts, that is the HDR and colors, but not the metadata since I haven't researched enough on how to do that, probably DoVi_Baker or the DoVi_tools can feed the RPU into frame properties but haven't had time to look at it.
ConvertBits(16)

deep_resize(1920)

z_ConvertFormat(pixel_type="YUV444PS",colorspace_op="auto:auto:auto:l=>same:same:same:f",resample_filter_uv="bicubic",filter_param_a_uv=0.262015,filter_param_b_uv=0.368993,use_props=0) # use_props=0 speeds up

# Manually found the 1000 MasterLevel, and scale=1. GC (Gamut Compression) is also enabled here
ICtCp_to_RGB("709",1000,DoVi=true,GC=true,scale=1,tv_out=false)

# Tonemapping (LinWh=11.2 is default, but commonly 30 will make more sense and varies depending on title, better tonemappers will be implemented in the future)
TM_Hable(mode="Default",filmic=false,LinWh=31.2)

# avsresize or below block
z_ConvertFormat(pixel_type="YUV420P8",colorspace_op="rgb:linear:709:f=>709:709:same:l", approximate_gamma=false, use_props=0)

# Alternative to avsresize
CCTF("1886",false,tv_in=false,tv_out=false)
RGB_to_YUV()

DolbyVision IPTPQc2______________________________________________________________________Rec709 - 1886
http://i.imgur.com/FdSzuVal.jpg (https://i.imgur.com/FdSzuVa.jpg)........http://i.imgur.com/pIbHLYIl.png (https://i.imgur.com/pIbHLYI.png)

This looks way better, and for the most IPTPQc2 content enough since not all titles make use of the RPU for the poly shaping or trim pass.
If you don't want to process and reencode the clip I made a GPU pixel shader (https://github.com/Dogway/emulation-random/tree/master/MPC-HC/Shaders) to decode/watch the content on the fly.

For my GPU (GTX 1070) it's barely playable with some frame drops here and there but I suspect there's something wrong on the MPC-HC shader pipeline since I see two shader instances.

So back to your original question, unless you want to keep the IPTPQc2 model, you would apply SMDegrain() normally to the output of the above script as usual. The next call worked well for me:

SMDegrain(4,thSAD=250,mode="temporalsoften",refinemotion=true,prefilter=2)

[Dogway]

So here are the two problem clips im using and the "man" clip is noisier and more problematic than the "sheep" clip.

IMAGES (https://imgsli.com/MTgzNTM4/0/2)
Raw Clips UHD 55mb (https://we.tl/t-0CS13HCzLO)

Speed/Quality:
On my slow computer I get the fastest speed with
smdegrain uhdhalf=true but much less detail/more blurry than set to false.

The DTL-script with DX12ME is a little bit slower than the above but a bit faster than smdegrain uhdhalf=false although the DTL-script denoises the least and too much temporal instabilities are left. I think I am not using DTL's version correctly since I did not understand all the new params so Im sorry if I do it unjustice. Also I should raise the tr but then it gets too slow. Notice that I do not use any prefiltering with DTL's version, only its internal mvlpfGauss.

Mdegrain-script is pretty close to the smdegrain call but a little slower yet denoises more and still keeps alot of detail.

I remember those clips from long ago. I don't remember my solution back then but I came up now with something like this:

ConvertBits(16)
pre=CCD(13).ex_median("IQMV",Y=2,UV=3).ex_sbr(2)
SMDegrain(4,thSAD=270,mode="temporalsoften",UHDHalf=false,chroma=false,mfilter=ex_minblur(1,UV=2),refinemotion=true,prefilter=pre,LFR=true)

# If you want to remove chroma vertical stripes
src1=last
RatioResize(1/3.,"%",kernel="RobiSharp")
src=last
DeStripeV(3,4,2,UV=3)
ex_LFR(src,last,LFR=400,UV=3)
RatioResize(3,"%",kernel="RobiSharp")
MergeLuma(src1)

ConvertBits(8,dither=1)

I wouldn't use hqdn3d() as it's really slow. Your mdgr() looks legit fine, denoise/sharpness balance but for some reason it warps a little bit which is annoying, maybe it's due to the prefiltering and not really the filter.

If my result looks a bit soft you can add ex_unsharp() afterward to bring back some sharpness. And as you can already see I used UHDHalf=false, I also noticed the output to be softer when disabled.

[Dogway]

You know, you have a point there I think.
SMDegrain is an excellent script, but after many month and hundreds of tested configurations, it always came down to the very same conclusion that mvtools is the weak spot here and in its current state couldn't cut it to satisfy my needs and expectations of a high-class motion-based denoising workflow on more demanding sources.

I'm almost at the brink of saying I'd better buy more hard drives instead of wasting that money on energy cost for half-satisfying 'remastering' jobs of my collection which I may regret one day.
Even having developed SMDegrain for years, I'm a purist, I like my grain in films and whenever possible I like to keep things as in the source, with the exception of bad transfer/encodes/releases. It's this case where grain is no more but a mess of blobs and other artifacts when I go, degrain and reapply some grain back ("remastering" basically), and to be honest I think it's miles better than the source, one example being one of your last examples of an outdoor bath with red sky sample. Or the recent 16mm film clip.

I think MVTools2 is in a pretty good state, to be honest I don't want more knobs, and I'm a firm believer that more knobs to adjust is not a better filter but the contrary. A well designed filter should only have a few handful but important parameters to play with which adjust to most if not all clips. Everything else should be reparametrized and best-fitted internally. And I think DTL's work on putting MVTools2 to the next level is superb but it's a long path still and I'm quite burned already for the last 2 years work, currently only on maintenance mode. To be honest everything related MVTools2 feels kinda a placebo or highly subjective improvements so you will only see me paint broad strokes regarding settings.
I do think AI is the way to go for the foreseeable future, a highly specialized AI based MV filter that then you can feed to MVTools or whatever degraining tool. I can see GPU APIs offer some kind of support on this regard (hopefully) and if not there's always good papers and people taking AI where it hasn't been reached yet. You could currently do this on AviSynth, creating some manually crafted mini neural network, it's just not practical or performance worthy.
(as things become slower and slower in compare of expected 'singularity of digital civilization from too fast and constantly increasing in speed progress' in the early 200x years).
Yeah, for some reason young people (mostly) have no interest on getting their hands dirty either literally or figuratively speaking, like understanding how things work and taking things up to the next level, at least from the demographics of Doom9 which mostly are millennials, GenX or Boomers. In Asia things are a bit better but not by much.

[madey83]

Sorry I was a bit busy:



No shame there, it's an i7, only timing was a bit off due to lack of AVX2 but CPU development unlike GPU has only got worse (diminishing returns).

You cannot match MaxFALL because DGHDRtoSDR() doesn't understand the source. The colors are not shifted, they are simply encoded differently, namely they are encoded in IPTPQc2's Dolby propietary color model. This is good and bad at the same time, it makes a huge improvement on the over 40 years old YCbCr color model (wrongly known as YUV). It represents the most efficient method of encoding video so you get more (quality) with less (size), and it's been my goal to decode this for the last 2 years. It's based on the IPT color model which is a very good perceptual uniform color model but adapted for HDR -> IPT-PQ crosstalk 2%

This is where the bad news arise, some folks at ffmpeg and other places have been reverse engineering this model and a part of the model depends on something called the RPU which is nothing else than embedded metadata. Not only this metadata will specify the peak (programme or scene) white or colorimetry, but also a few things that make it difficult to decode without hurdles, that is scene based metadata transfer functions (the MMR or polynomial depending on DV profile) and also a trim pass (check the color tint jump from frame 191 to 192).

I managed to decode the static parts, that is the HDR and colors, but not the metadata since I haven't researched enough on how to do that, probably DoVi_Baker or the DoVi_tools can feed the RPU into frame properties but haven't had time to look at it.
ConvertBits(16)

deep_resize(1920,show=false)

z_ConvertFormat(pixel_type="YUV444PS",colorspace_op="auto:auto:auto:l=>same:same:same:f",resample_filter_uv="bicubic",filter_param_a_uv=0.262015,filter_param_b_uv=0.368993,use_props=0) # use_props=0 speeds up

# Manually found the 1000 MasterLevel, and scale=1. GC (Gamut Compression) is also enabled here
ICtCp_to_RGB("709",1000,DoVi=true,GC=true,scale=1,tv_out=false)

# Tonemapping (LinWh=11.2 is default, but commonly 30 will make more sense and varies depending on title, better tonemappers will be implemented in the future)
TM_Hable(mode="Default",filmic=false,LinWh=31.2)

# avsresize or below block
z_ConvertFormat(pixel_type="YUV420P8",colorspace_op="rgb:linear:709:f=>709:709:same:l", approximate_gamma=false, use_props=0)

# Alternative to avsresize
CCTF("1886",false,tv_in=false,tv_out=true)
RGB_to_YUV()

DolbyVision IPTPQc2______________________________________________________________________Rec709 - 1886
http://i.imgur.com/FdSzuVal.jpg (https://i.imgur.com/FdSzuVa.jpg)........http://i.imgur.com/pIbHLYIl.png (https://i.imgur.com/pIbHLYI.png)

This looks way better, and for the most IPTPQc2 content enough since not all titles make use of the RPU for the poly shaping or trim pass.
If you don't want to process and reencode the clip I made a GPU pixel shader (https://github.com/Dogway/emulation-random/tree/master/MPC-HC/Shaders) to decode/watch the content on the fly.

For my GPU (GTX 1070) it's barely playable with some frame drops here and there but I suspect there's something wrong on the MPC-HC shader pipeline since I see two shader instances.

So back to your original question, unless you want to keep the IPTPQc2 model, you would apply SMDegrain() normally to the output of the above script as usual. The next call worked well for me:

SMDegrain(4,thSAD=250,mode="temporalsoften",refinemotion=true,prefilter=2)

Hi Dogway

Thanks for explaining all this thinks regarding colors, but as i mentioned I'm rookie in avisynth and all this is to hard to understand at this moment for me.

Based on you knowledge and experience I would like to know if it is possible use your awesome scripts to Denise dolby vision profile 5/8.1 without changing colors space like you did ( hope i understud it correctly ).

If it is what should I change in my call.

Could you give me how did you find thSAD value without many encodes.

Thanks :⁠-⁠)

[anton_foy]

I remember those clips from long ago. I don't remember my solution back then but I came up now with something like this:

ConvertBits(16)
pre=CCD(13).ex_median("IQMV",Y=2,UV=3).ex_sbr(2)
SMDegrain(4,thSAD=270,mode="temporalsoften",UHDHalf=false,chroma=false,mfilter=ex_minblur(1,UV=2),refinemotion=true,prefilter=pre,LFR=true)

# If you want to remove chroma vertical stripes
src1=last
RatioResize(1/3.,"%",kernel="RobiSharp")
src=last
DeStripeV(3,4,2,UV=3)
ex_LFR(src,last,LFR=400,UV=3)
RatioResize(3,"%",kernel="RobiSharp")
MergeLuma(src1)

ConvertBits(8,dither=1)

I wouldn't use hqdn3d() as it's really slow. Your mdgr() looks legit fine, denoise/sharpness balance but for some reason it warps a little bit which is annoying, maybe it's due to the prefiltering and not really the filter.

If my result looks a bit soft you can add ex_unsharp() afterward to bring back some sharpness. And as you can already see I used UHDHalf=false, I also noticed the output to be softer when disabled.

Thanks man! Pretty stable temporally even with tr=4. Although the chroma flickers a bit still. Sharp too so no need for any further sharpening I think. Could not have thought of the destripe stuff, neat! I did not see the warping you mentioned on the mdgr-script but I will look closer at that. The prefiltering you put works great too.

[Dogway]

Based on you knowledge and experience I would like to know if it is possible use your awesome scripts to denoise dolby vision profile 5/8.1 without changing colors space like you did ( hope i understud it correctly ).

If it is what should I change in my call.
So you want to undo the IPTPQc2 model, but you still want to keep original color space Rec2020 and original transfer function PQ?

This is the code:
ConvertBits(16)

deep_resize(1920)
z_ConvertFormat(pixel_type="YUV444PS",colorspace_op="auto:auto:auto:l=>same:same:same:f",resample_filter_uv="bicubic",filter_param_a_uv=0.262015,filter_param_b_uv=0.368993,use_props=0)

ICtCp_to_RGB("2020",10000,DoVi=true,GC=false,scale=1,tv_out=false)

z_ConvertFormat(pixel_type="YUV420P16",colorspace_op="rgb:linear:2020:f=>2020:st2084:same:l", approximate_gamma=false, nominal_luminance=203.0, use_props=0)

# 600 was found manually
pre=DGHDRtoSDR(mode="pq",white=600,gamma=1/2.4,tm=1.0).ex_minblur(2,UV=3)
SMDegrain(4,thSAD=250,mode="temporalsoften",refinemotion=true,prefilter=pre)

ConvertBits(10,dither=1)

@anton_foy: Yes, the vertical chroma stripes might or might not be visible, so it depends. If you don't see them on normal playback remove that block so the filter runs faster.

[DTL]

"I think MVTools2 is in a pretty good state, to be honest I don't want more knobs, and I'm a firm believer that more knobs to adjust is not a better filter but the contrary. A well designed filter should only have a few handful but important parameters to play with which adjust to most if not all clips. Everything else should be reparametrized and best-fitted internally."

There are several levels of processing and control:

1. Level of compiled binary (or program source) - typically not reachable by enduser without full program recompile/debug.
2. Level of filter to AVS environment (expose all design control params).
3. Level of script function from script librabry (may have some params internally defaulted or some not very complex math interconnection)
4. Level of endusers script to rare or everyday usage
5. Level of GUI software using some AVS scripts internally

Each level may have less and less user-controllable params with hiding more and more params in the internal defaults (at each level). But to find best defaults and/or params interconnection we require many many test/production runs (or Computer-Aided optimizers runs). At the old decades when there were many users and develpers - the users activity with new features quickly shows best params and some 'advanced/power' users provide Level 3 API (script function from script library - like SMDegrain()) to upper-level content processing users. Now as some new processing modes and features to mvtools added - it exist only at Level 2 and need lots of tests to select best typical use cases params (if there will be found only one best param for all use cases - it can be hardcoded as internal default at Level 1). The design of SMDegrain of Level 3 API at the old mvtools features core (like mvtools-200x) takes about 10..15 years.

So after some (and not few) new features added to mvtools core filters for degrain it may already take many time to design at least more easy to use Level 3 API for script users. And we have greatly reduced number of practical users so the performance of designing Level 3 and higher API of total users pool is significantly reduced. Need long time waiting now *as things become slower and slower*.

At the more active civilization at 200x there was dual-stream process of development:
1. Developers make new features in compiled binary and provide Level 2 API to AVS users.
2. AVS users make tests and provide feedback to developers about best params or even ways to put more developement resources from practically found best processing modes and so on.
This 2-sided interaction make development of plugins faster and more effective.

Most of residual and new users like to have Level 5 or may be some Level 4 API and very hard to understand how lower levels working or even the processing algorithms in compiled binaries. But the path to design nice Level 5 API to endusers in freeware opensource non-commertial software may be very long. As I see typical Level 5 software like xvid4psp is not free at all (at pro-version).

[madey83]

So you want to undo the IPTPQc2 model, but you still want to keep original color space Rec2020 and original transfer function PQ?

This is the code:
ConvertBits(16)

deep_resize(1920)
z_ConvertFormat(pixel_type="YUV444PS",colorspace_op="auto:auto:auto:l=>same:same:same:f",resample_filter_uv="bicubic",filter_param_a_uv=0.262015,filter_param_b_uv=0.368993,use_props=0)

ICtCp_to_RGB("2020",10000,DoVi=true,GC=false,scale=1,tv_out=false)

z_ConvertFormat(pixel_type="YUV420P16",colorspace_op="rgb:linear:2020:f=>2020:st2084:same:l", approximate_gamma=false, nominal_luminance=203.0, use_props=0)

# 600 was found manually
pre=DGHDRtoSDR(mode="pq",white=600,gamma=1/2.4,tm=1.0).ex_minblur(2,UV=3)
SMDegrain(4,thSAD=250,mode="temporalsoften",refinemotion=true,prefilter=pre)

ConvertBits(10,dither=1)

@anton_foy: Yes, the vertical chroma stripes might or might not be visible, so it depends. If you don't see them on normal playback remove that block so the filter runs faster.

@Dogway,

thank you for that.
Is this part is static and no need to change it regarles of the source?
z_ConvertFormat(pixel_type="YUV444PS",colorspace_op="auto:auto:auto:l=>same:same:same:f",resample_filter_uv="bicubic",filter_param_a_uv=0.262015,filter_param_b_uv=0.368993,use_props=0)

ICtCp_to_RGB("2020",10000,DoVi=true,GC=false,scale=1,tv_out=false)

z_ConvertFormat(pixel_type="YUV420P16",colorspace_op="rgb:linear:2020:f=>2020:st2084:same:l", approximate_gamma=false, nominal_luminance=203.0, use_props=0)

# 600 was found manually - Could you please giude how i should do that per source?

Is there any way to check value of thSAD without encoding...?

[Dogway]

Is this part is static and no need to change it regarles of the source?
z_ConvertFormat(pixel_type="YUV444PS",colorspace_op="auto:auto:auto:l=>same:same:same:f",resample_filter_uv="bicubic",filter_param_a_uv=0.262015,filter_param_b_uv=0.368993,use_props=0)

ICtCp_to_RGB("2020",10000,DoVi=true,GC=false,scale=1,tv_out=false)

z_ConvertFormat(pixel_type="YUV420P16",colorspace_op="rgb:linear:2020:f=>2020:st2084:same:l", approximate_gamma=false, nominal_luminance=203.0, use_props=0)

# 600 was found manually - Could you please giude how i should do that per source?

Is there any way to check value of thSAD without encoding...?
Yes, that part is a roundtrip concerning HDR so it only decodes IPTPQc2. 600 was found manually, because I don't know what units DGHDRtoSDR() uses for its 'white' argument. It should be related to MaxFALL I guess but I don't know.

'thSAD' was also found manually, under inspection with AvsPmod.

[madey83]

Yes, that part is a roundtrip concerning HDR so it only decodes IPTPQc2. 600 was found manually, because I don't know what units DGHDRtoSDR() uses for its 'white' argument. It should be related to MaxFALL I guess but I don't know.

'thSAD' was also found manually, under inspection with AvsPmod.

i've never done this, but when i try to open in AvsPmod sample.mkv with your scritp i've got this

https://imgur.com/a/dXfPcrq

[Dogway]

You are not loading RGTools plugin it seems. Also missing MVTools2, MaskTools2, etc...

By the way I realized you can downscale also with z_converformat() so performance can be increased further.
z_ConvertFormat(1920,1080,pixel_type="YUV444PS",colorspace_op="auto:auto:auto:l=>same:same:same:f",use_props=0,\
resample_filter="bicubic",filter_param_a=-0.990000,filter_param_b=0.06000)

[madey83]

You are not loading RGTools plugin it seems. Also missing MVTools2, MaskTools2, etc...

By the way I realized you can downscale also with z_converformat() so performance can be increased further.
z_ConvertFormat(1920,1080,pixel_type="YUV444PS",colorspace_op="auto:auto:auto:l=>same:same:same:f",use_props=0,\
resample_filter="bicubic",filter_param_a=-0.990000,filter_param_b=0.06000)

Hi Dogway,

thank you for your patience to me :) and your help.

i was able to open example.mkv in avsPmod.

Regarding tr and thSAD you manually tried different vaulues or there is an option in avsPmod to calculate avg. value to enitire file?

Sorry, for to meny questions but all this is new to me... :thanks:

[Dogway]

Regarding tr and thSAD you manually tried different vaulues or there is an option in avsPmod to calculate avg. value to enitire file?

No, just inspection and experience/preference. If you use good prefilters you can lower thSAD.

[salvo00786]

Well, that's not good :(

Have you asked on the StaxRip thread ?? (I haven't seen your name there).

Emulgator left an interesting post...

As the suggestions given here, haven't worked either :(

Hi... Finally I have the SMDegrain Working. I have tried so many times on staxrip 2.19 with all my settings and nothing. After that I copied a clean copy of Staxrip 2.19 in a new directory and I updated EXtools and Avisynth. In the new clean copy of Staxrip the SMDegrain work. Probably there are some personal settings in my Staxrip that create a problem with SMDegrain. Anyway now it work. Now I want to know please if someone know a method to use KTGMC with Staxrip, because I have an RTX3070 but QTGMC is so slow. I have seen that exist KTGMC but how to make it work on Staxrip?

[kedautinh12]

KTGMC need avisynthCuda to work but it's old and dom't update very long

[Guest]

Hi... Finally I have the SMDegrain Working. I have tried so many times on staxrip 2.19 with all my settings and nothing. After that I copied a clean copy of Staxrip 2.19 in a new directory and I updated EXtools and Avisynth. In the new clean copy of Staxrip the SMDegrain work. Probably there are some personal settings in my Staxrip that create a problem with SMDegrain. Anyway now it work. Now I want to know please if someone know a method to use KTGMC with Staxrip, because I have an RTX3070 but QTGMC is so slow. I have seen that exist KTGMC but how to make it work on Staxrip?

Well done.

There must be somehow that you can get QTGMC to run faster..

Never heard of KTGMC, but here's some info:-

https://github.com/nekopanda/AviSynthCUDAFilters/wiki/KTGMC

https://github.com/nekopanda/AviSynthCUDAFilters/releases

https://forum.videohelp.com/threads/399958-Avisynth-Neo-and-KTGMC-information

I think you should start asking questions on the StaxRip thread ;)

[DTL]

I have an RTX3070 but QTGMC is so slow. I have seen that exist KTGMC but how to make it work on Staxrip?

Some time ago I tried to make QTGMC work with DX12-ME builds of post-2.7.45 mvtools - https://github.com/DTL2020/QTGMC . But if you need main (?) part of QTGMC using MCompensate - it still do not have interpolated ovelap (from MDegrainN). So may be not good in quality while running with no-overlap MAnalyse with hardware accelerator (also Win10 or better required).

I think your QTGMC is slow because you use large pel and large overlap settings ? Also may be frame size if 1080 interlaced ? I typically do not read complains for too slow QTGMC because it is simple enough and run good at 202x years CPUs. So the project of making QTGMC working with DX12-ME-capable mvtools builds (and interpolated overlap to MCompensate) was almost stopped because close to no one uses QTGMC (for HD and slow settings). And for old SD it may run already good even with high settings.

[fabioseixal]

Hello,

I'm probably doing something wrong, but I don't understand why I get "green frames" when using Spresso "Dogway mod in 2022.03.05 Cosmetics".
If I upscale to HD, the issue is solved. So for now I returned back to the old and trusty Didée original function which works well.

Here are some screenshots: https://slow.pics/c/NLBKXy5L
Video Info

Width : 768 pixels
Height : 576 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits

Thank You

[salvo00786]

Hi DTL. Thanks for the reply. I was using a long script and one parameter, was very slow. I was using chromanoise and chromamotion, but chromamotion slowed down my qtgmc from 40fps to 2/3fps.

When I use QTGMC Slower the speed is about 40fps. I tried this script for a problematic video

chroma = checkmate(thr=12,max=25,tthr2=25)
luma = checkmate(thr=12,max=25,tthr2=0)
fixed = MergeChroma(chroma, luma)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
QTGMC(preset="Slower", InputType=0, sourceMatch=3, Lossless=2, sharpness=0.2, NoisePreset="Slower", Denoiser="dfttest", ChromaMotion=true, ChromaNoise=true, EZDenoise=2.0, DenoiseMC=true, NoiseDeint="Generate", StabilizeNoise=true, ediThreads=8)
Prefetch(8)


With this script the speed dropped from 40 to 2/3 fps. After some experiments, I found that Chromamotion dropped drastically my speed. Without chromamotion the speed go from 2/3 fps to 28/30 fps with all the other parameters, but after some other experiments, this scripts doesn't resolved my problems with the video.

The script that I found that solved my problems is this


chroma = checkmate(thr=12,max=25,tthr2=25)
luma = checkmate(thr=12,max=25,tthr2=0)
fixed = MergeChroma(chroma, luma)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
QTGMC(preset="Slower", sharpness=0.2, ediThreads=8).QTGMC(Preset="Slower", InputType=1, sharpness=0.2, ediThreads=8)
Prefetch(8)


Running two pass of QTGMC, solved my problems. The speed of my last double pass script is about 26.60 fps that is acceptable.

[anton_foy]

@Dogway
If I denoise pretty heavily with smdegrain/mvtools but need to make it affect brighter areas less, could this be done in a clever way in the prefilter?
Ex_merging with masks and two calls of smdegrain is pretty slow so I would think there is a faster solution.

Edit: prefiltering is mostly for the motion vectors and not for denoise strength I know but details can be affected if the prefilter is too soft. Maybe doing it in prefiltering stage is not the way. Any ideas are very welcomed.

[Dogway]

fabioseixal: Thanks for the report! Fixed (https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/Spresso.avsi)
anton_foy: Maybe increase SAD for brighter areas with AddGrainC. A mix of LumaMask, AddGrainC and ex_merge. But maybe better to do afterwards and merge back source clip via LumaMask and ex_merge.

[anton_foy]

anton_foy: Maybe increase SAD for brighter areas with AddGrainC. A mix of LumaMask, AddGrainC and ex_merge. But maybe better to do afterwards and merge back source clip via LumaMask and ex_merge.

Great thanks! But how do you mean afterwards? Not in the prefilter?

[Dogway]

Great thanks! But how do you mean afterwards? Not in the prefilter?

Yes:
src=last
SMDegrain()
ex_merge(src, LumaMask(lo=150, hi=235),luma=true)

[anton_foy]

Yes:
src=last
SMDegrain()
ex_merge(src, LumaMask(lo=150, hi=235),luma=true)

It is faster than doing the addgrainC-merging on the prefilter?

Did you read DTL's suggestion in the MVTools thread?
Maybe something to implement into smdegrain if it is faster and or better quality?

[Dogway]

I read DTL's now, basically my suggestion above(?).
This is basic AviSynth usage, masking, filtering and whatnot.

Post merging is recommended, I don't think it can be merged into an existing expression within SMDegrain, so this should be as fast as it gets. Unless you want to break down the ex_merge call into pieces and turn it into an ex_lutxy() call, but that's advanced.

[anton_foy]

I read DTL's now, basically my suggestion above(?).
This is basic AviSynth usage, masking, filtering and whatnot.

Post merging is recommended, I don't think it can be merged into an existing expression within SMDegrain, so this should be as fast as it gets. Unless you want to break down the ex_merge call into pieces and turn it into an ex_lutxy() call, but that's advanced.

Yeah okay thanks, I just want to find a way with the least processing time to "pull back" degraining in the brighter areas because this is IMHO possibly the simplest road to a "dynamic degrain" without going through slooow runtime filtering.

Another way is to use averageluma and conditionals but I must do benchmarks and it would not be as seamless as the suggested above. (I am aware it is runtime though)

Edit:
so this should be as fast as it gets
You mean below?:
src=last
SMDegrain()
ex_merge(src, LumaMask(lo=150, hi=235),luma=true)

[tormento]

I have tried to reverse the upscaling of an anime, using the values that getnative (python utility) gave me about the source, usually in bicubic parameters.

My intention is to later apply some needi3resize, to have a better 1080p result.

I did tests with DeBicubicResizeMT, Descale and fmtc_resample. I can't get rid of the ghosting close to the edges of the screen that, AFAIK, are a consequence of the bicubic upscaling and minor ones around dark lines.

So, aren't they caused by the upscaling?

Dogway, do you have any hint for me? Is there any function in your plethora of scripts that can help me?

P.S: Something that would *really* work without having to use python and VS to get native resolution would be great too.

[Dogway]

I have tried to reverse the upscaling of an anime, using the values that getnative (python utility) gave me about the source, usually in bicubic parameters.

My intention is to later apply some needi3resize, to have a better 1080p result.

I did tests with DeBicubicResizeMT, Descale and fmtc_resample. I can't get rid of the ghosting close to the edges of the screen that, AFAIK, are a consequence of the bicubic upscaling and minor ones around dark lines.
I would use getNative only to get the source original resolution but then upscale with something else. needi3resize is a nice fast upscaler but if you have the power to spare I would use an onnx model, in one of my tests for a 90s film I use 2X_DigitalFilmV5_Lite with great results. For the borders I usually crop them or use FillBorders plugin.

nnedi3resize can be a bit soft for textures so if you have some in your source you might want to use a better upscaler for 'flat', not to the extent oh high taps sincs but maybe spline16.

[tormento]

if you have the power to spare I would use an onnx model
Unfortunately not and that's why I am downsizing to "native".

As I wrote, I have issues with the artifacts that the original upscale caused and I don't know why they don't disappear when downscaling.

Can I bother you, sending some piece of anime where you can see them?

[Dogway]

As I wrote, I have issues with the artifacts that the original upscale caused and I don't know why they don't disappear when downscaling.

Can I bother you, sending some piece of anime where you can see them?

It's ok. If you can please give me the original resolution that getNative provides. You want to rescale back right?

[tormento]

It's ok. If you can please give me the original resolution that getNative provides. You want to rescale back right?
Here (https://www.upload.ee/files/15323667/AnoHana.7z.html) is the archive.

It contains a short cut of AnoHana 1st episode and the getnative analysis on a couple of significative frames. There is a doubt about 720p and 960p. I have chosen the 720p as it is the most probable, with b=1, c=0, as they are the values that gives the higher error detection.

Look at the upper border of the sky frame. It has some multiple ghostings and, in a minor way, around the game controller too.

My very simple script is:

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
DGSource("N:\In\AnoHana\01.dgi")
ConvertBits(16)
fmtc_resample (1280, 720, kernel="bicubic", a1=1, a2=0, invks=True)
fmtc_bitdepth (bits=10,dmode=8)

[Dogway]

I see, so you only want to downscale.
You have to crop to remove the original ringing in the upper and lower frame borders, as well sides for the black.
crop(2,2,-2,-2)

Or you can use FillBorders plugin instead to fill those areas.

You can also play with crop+dilation:
crop(2,2,-2,-2)
PadBorders(16,16,16,16,mode="Dilate")
fmtc_resample (1280+20, 720+20, kernel="bicubic", a1=1, a2=0, invks=True)
PadResize(1280,720)

[tormento]

You have to crop to remove the original ringing in the upper and lower frame borders, as well sides for the black.
Isn't inverse kernel supposed to get rid of the upscaling artifacts? AFAIK those ones come from bicubic.
You can also play with crop+dilation
Please, explain me the script with crop+dilation.

Anyway, at the end, I would get rid of borders artifacts only but not the ones around the lines.

Am I wrong or once you find native resolution + bicubic parameters, everything should be fixed in the downsized video?

[Dogway]

Please, explain me the script with crop+dilation.
The script posted above.

Isn't inverse kernel supposed to get rid of the upscaling artifacts?
It's a scaling+sharpening convolution so it depends on source artifacts, in this case ringing in borders, and if you sharpen too much ringing around edges as you see. You might want to play with different b and c settings.


EDIT: I tried the FillingBorders() method and still prefer padding. So follow along.

For the ringing you can try two things, apply a milder kernel:
Crop(2,2,-2,-2)
PadBorders(16,16,16,16,mode="dilate")
fmtc_resample (1280+20, 720+20, kernel="bicubic", a1=0.5, a2=0.0, invks=True)
PadResize(1280,720)

or if it's still too soft, I cobbled up this filter chain to remove the ringing and then some post-sharpening.

# Crop garbage
Crop(2,2,-2,-2)
# Pad
PadBorders(16,16,16,16,mode="dilate")
a=fmtc_resample (1280+20, 720+20, kernel="bicubic", a1=-0.5, a2=0.25, invks=false)
fmtc_resample (1280+20, 720+20, kernel="bicubic", a1= 0.5, a2=0.0, invks=True) # 0.5 for less ringing

# Remove ringing
ex_luts(last,a,mode="clamp",pixels=ex_shape(1),UV=3)
# Final Sharpening
ex_unsharp(0.5,Fc=1920,safe=true)

# Crop Padding
PadResize(1280,720)

[tormento]

The script posted above
Thank you.

I have played a bit and what I called ghosting is indeed ringing.

However, even if you added a deringing part, I still can see it along lines.

I thought it could appear upscaling only but as a matter of fact, it's appearing when downscaling too. Why?

Another question: I thought that I should respect the same parameters of bicubic when downscaling. Isn't it true?


P.S: Could you sort out a way to find native resolution beside using getnative?

[tormento]

P.S: I am having strange issues with nnedi3resize(1920,qual=2), as a very simple

LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
DGSource("N:\In\AnoHana\01.dgi")
fmtc_resample (1280, 720, kernel="bicubic", a1=1, a2=0, invks=True)
nnedi3resize(1920,qual=2)

throws me

https://i2.lensdump.com/i/6PUq12.png

but a simple propShow() before nnedi3resize shows

https://i2.lensdump.com/i/6PUnfD.png

So, why is it complaining? Strangely, if I add a propSet("_FieldBased", -1) in the scripts, it works ok.

[Dogway]

However, even if you added a deringing part, I still can see it along lines.

I thought it could appear upscaling only but as a matter of fact, it's appearing when downscaling too. Why?

Another question: I thought that I should respect the same parameters of bicubic when downscaling. Isn't it true?

P.S: Could you sort out a way to find native resolution beside using getnative?
You mean the script I posted above with the deringing and ex_unsharp(). Sure, any kind of "sharpening" is going to create ringing because the real effect it causes is "acutance (https://en.wikipedia.org/wiki/Acutance)". The example was a balanced compromise between sharpness and ringing. If you want absolute zero ringing you should use invks=false, because what that is doing is a deconvolution (reverse convolution), like turning b=1,c=0 into b=0,c=1. At that point you are better off downscaling with no sharpening, but also no blurring, aka "Zopti720" that is b=-1.00,c=0.16.

I started making a sort of getnative function in AviSynth, but dropped it as I'm already in bonus, not up for these kind of mindf* filters like SceneStats and else XD. Just maintenance from now on.
You can make a function though that downscales and also upscales back at the same time with deepresize such as "deepresize(n).deepresize(1/n)" turn "n" into a slider and examine visually.

P.S: I am having strange issues with nnedi3resize(1920,qual=2), as a very simple

LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
DGSource("N:\In\AnoHana\01.dgi")
fmtc_resample (1280, 720, kernel="bicubic", a1=1, a2=0, invks=True)
nnedi3resize(1920,qual=2)

Sorry I didn't know you also wanted to upscale back. Yes that line should work. As you pointed out it's failing because it's somehow labeled as interlaced/telecined ("_FieldBased=1") turn that into 0 and you're fine.

EDIT: New script with nnedi3resize():
Crop(2,2,-2,-2)
PadBorders(16,16,16,16,mode="fill")
fmtc_resample (1280+20, 720+20, kernel="bicubic", a1=-1.0, a2=0.16, invks=false)
nnedi3resize(1920+32,1080+30,qual=2,sharpness=50)
PadResize(1920,1080)

Increase "c" if you want more sharpness/acutance, until ringing bothers you.

[tormento]

A fix for DGDecodeNV.dll about FieldBased is coming. That will fix the issue with needi3resize.

[anton_foy]

@Dogway
Really like the unsharpmask_HBD, the threshold param is very useful to bypass sharpening of flat/non detailed areas. Can it be modified though to get rid of the halos/ringing a bit? Any suggestion of how to reduce it?

Edit: oh I just spotted this you posted above:

# Remove ringing
ex_luts(last,a,mode="clamp",pixels=ex_shape(1),UV=3)
Maybe this works?

Edit2: no it did not reduce much sadly.

[Dogway]

unsharpmask_HBD is a port of real.finder's UnsharpMask_avsi, so it could work on some functions, I haven't used it at all so I don't know, since then I made my new unsharp mask filer ex_unsharp(), it also has 'thres' and a new mode called 'safe' inspired from CTools to prevent ringing. Try using both.

[anton_foy]

unsharpmask_HBD is a port of real.finder's UnsharpMask_avsi, so it could work on some functions, I haven't used it at all so I don't know, since then I made my new unsharp mask filer ex_unsharp(), it also has 'thres' and a new mode called 'safe' inspired from CTools to prevent ringing. Try using both.

Just lovely I will great! Thanks!

Edit: removed my idiotic question.

[tormento]

The DGIndexNV slipstream to correct the _FieldBased issue is out.

[LeXXuz]

Dogway during my tests to find the sweet spots with mfilter=Expr() for denoising,
I've noticed that on many sources the last row of blocks and last line of blocks looks quite different and very often is completely red.

Here's a galery of some examples, I have many more:
https://abload.de/gallery.php?key=eRBeHu1y

I'm wondering if this is just a problem/bug with the mfilter implementation routine or if the last row and line of blocks really gets filtered differently and in some cases much weaker or not at all.

The first I don't care as I just use mfilter for testing my denoising settings but don't actually use it for filtering. The latter I certainly DO care and would worry me.

-It is not any of my filter settings, because, if it occurs, it occurs with the very default settings also. Like:
SMDegrain(mfilter=Expr("81","90","250",Scale_inputs="int"))

what I tried to rule out so far:
-It is not a problem of 8 or 16 bit workflow
-It is not a problem of resolution as it can appear on any mod(4) resolution. Tried mod(8) or mod(16) with not much of a difference.
-It is not a problem of improper cropping where there might be a dark line or row left. It can also be seen on modern CGI which fill out a 1080p res just perfectly

[DTL]

As a workaround it possible to AddBorders before processing and Crop after. I also sometime have completely buggy blocks (arranged in rows, but not complete row) at the last (bottom) rows with 1080 lines frame processing with DX12-ME at GTX1060 and not know where it is come from - simply add 72 samples padding to the bottom and crop after.

Also mvtools Mdegrain not process frame borders not covered with full blocks and simply copy (lines, columns) from source. So to process full active frame area it must be fully covered with blocks. Padding with MSuper not helps.

So may be you use too large block size and frame width/height can not be fully covered. mvtools not add blocks overlapping frame borders (into padded by MSuper area - it is mostly reserved for motion compensation when MV points to the block position outside real frame area and not too out of frame).

[LeXXuz]

As a workaround it possible to AddBorders before processing and Crop after.

It's really an odd issue. Good idea with the extra padding though.

Take this clip for example. This is the uncropped 1080p source (1920x1080):
https://abload.de/thumb/2023-06-191zgcsn.png (https://abload.de/image.php?img=2023-06-191zgcsn.png)

Looks like mvtools doesn't mind the small letterbox borders here.
But it has a problem with the 1920 width here, although it is perfectly divisible by 32,16,8,4,2 of course.
It does not mind that the default 1080p resolution is not divisible by 32 or 16. I process it with the default blocksize of 16 for HD.

Correctly cropping 22 lines of the image at the top and the bottom, resulting in a 1920x1036 resolution, it now DOES mind the source's hight is now additionaly not divisible by 8, showing a red block row at the bottom:
https://abload.de/thumb/2023-06-192dkdci.png (https://abload.de/image.php?img=2023-06-192dkdci.png)

And now it gets really weird. By adding just 2 black lines at the bottom and 2 black rows at the right, creating an unusual resolution of 1922x1038, which now is only divisible by 2, shows only full red (or unprocessed) on the recently added areas while the source picture now seems to be processed correctly:
https://abload.de/thumb/2023-06-1931piga.png (https://abload.de/image.php?img=2023-06-1931piga.png)

And of course after cropping out those extra 2 lines and rows, finally the picture looks as it should have been in the first place:
https://abload.de/thumb/2023-06-1947ke8i.png (https://abload.de/image.php?img=2023-06-1947ke8i.png)

I don't get it. And it's nothing Dogway can do about with SMDegrain if it also happens by using mvtools directly, like you said.
Proofs once more mvtools needs some overhaul. Until then, I have to live with yet another workaround, I guess. Again, thanks for the padding tip DTL.

[DTL]

Also the edge of frame rows and columns of blocks are not completely processed with overlapping (up to blksize/2). For example in versions up to 2.7.45 top row have only horizontal overlap and half vertical (from next row below). In post-2.7.45 in 2x 'diagonal' overlap mode the top blocks row do not have even horizontal overlap at the upper half of block.
To fix it the more padding can be added (so that active frame area will be surrounded with at least 1/2 of blocksize) and all active frame area will be covered with overlapped blocks.

" it's nothing Dogway can do about with SMDegrain"

Required padding can be calculated in scripting from input frame size and block size and added in the library script and cropped after MDegrain. It will make processing somehow slower because of more blocks to process so may be optional function switch.

[LeXXuz]

To fix it the more padding can be added (so that active frame area will be surrounded with at least 1/2 of blocksize) and all active frame area will be covered with overlapped blocks.


Yes, totally forgot about block overlapping. So best way to play it safe would be to first have a resolution divisible by blocksize and then add a padding 'frame' of 1/2 of blocksize around the image?

In which direction does the block overlapping actually occur?
Since I never noticed that problem with the very first line and row of blocks, only the very last ones, I imagined overlapping goes to the right and to the bottom. Which then would mean it'll be enough to pad just 1/2 of blocksize to the right and bottom of the clip.

Or does it go into all four directions (left, top, right, bottom)?

[DTL]

"In which direction does the block overlapping actually occur?"

Second row of blocks is shifted to the right and bottom. Main blocks scan is from left to right and from top to bottom (the MAnalyse have zigzag/meander scan and some new MDegrain in post-2.7.45 too in attempt to reuse near cached data). Though the last (right most) block in shifted row may be skipped (?). Also last row from the bottom may be skipped - need to look in the sources and attempt to understand later.

" best way to play it safe would be to first have a resolution divisible by blocksize and then add a padding 'frame' of 1/2 of blocksize around the image?"

Yes - may be close to this.

"Or does it go into all four directions (left, top, right, bottom)?"

Overlapping _not_ cover (completely) _all_ edges of _covered_by_blocks frame area. So if not all frame area covered by blocks - the 'full' overlap is cover even less.

Overlapping weight function have special cases for 'internal frame blocks' (full overlap processing) and all edges and corners cases (left,top,right,bottom and all 4 corners). So to have all active frame area covered with 'full overlap' it is required to add padding to all 4 frame edges (at least to 1/2 block size if the overlap=blocksize/2 used - max overlap) and to have frame size divisible to block size. Or simply try to add 'big' padding like 2 block size to all edges - it may be also cause covering of active frame area with blocks and with full overlap and all special edge/corners cases will be moved to outside of active frame area zones.

[LeXXuz]

So to have all active frame area covered with 'full overlap' it is required to add padding to all 4 frame edges (at least to 1/2 block size if the overlap=blocksize/2 used - max overlap) and to have frame size divisible to block size.

Okay, sold. I'll just make sure the resolution is divisible by blocksize and add a border of 16 black pixels around the clip to play it extra safe. I don't care about additional processing time. Thx again. :)

[salvo00786]

Hi Guys... A question for you. What is the difference between CAS ans CASm? What is better between these two?

[Dogway]

Hi Guys... A question for you. What is the difference between CAS ans CASm? What is better between these two?

Well the CASm description says it all. An "improvement" over CAS, whether you find an improvement or not you have to test.
CAS as you know is AMD's Contrast Adaptive Sharpening, and Asd-g ported it to a plugin. Then you have CAS+ also inside SharpenersPack, it's my port of CAS to a function, just a tiny bit slower than the plugin.

[salvo00786]

Hi... thanks for you reply, but where I can find the description for CASm? I tried to search for CASm before asking, but I haven't found anything?

[Guest]

Hi... thanks for you reply, but where I can find the description for CASm? I tried to search for CASm before asking, but I haven't found anything?

https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/SharpenersPack.avsi#L3064

[salvo00786]

Ok, thanks

[LeXXuz]

Dogway I'm playing around with some parameters in SMDegrain I haven't paid much attention to before.

First, is it advisable to use recursion mode for MDegrain as an additional refinement if quality is of the highest concern? Or better not as some side effects (which I haven't noticed through quick testing yet) may occur? So far the speed penalty was way less than I expected it to be.

Does recursion increase denoising strength and therefore thSAD should be adjusted/lowered? Or does it merely increase precision through the binominal weighting? Or a mixture of both? Again, side effects?

And second, the rfilter setting. Is the cubical filter mode (4) better for any scenario than the default quadratic filter?

[Dogway]

Recursion is for stronger degrain without raising the temporal radius, so it might be a good alternative, specially for busy scenes.

Also it will become center frame weighted (check tent blur in ExTools) so safer than using a higher 'tr'.

As for higher quality I don't know, it depends on source, if it's very grainy it can help I think. thSAD is something different, it's the "noise threshold", like the mask so to speak for MDegrain and it's independent to recursion.

rfilter=3 is what gave me the best qual/perf ratio in Zopti, that is not to say rfilter=4 can't give better results but in such case the performance hit didn't make it worth it, just speculating, I don't remember if it delivered better quality.

[LeXXuz]

:thanks:

I did a b2b comparison between two encodes of a problematic source and had the impression tr6 with r looked better, even a little bit more stable, than tr12. But I wasn't sure and couldn't pinpoint it exactly. It was just the entire scenery that looked better on pans or scenes with lots of motion.

After so many tests you sometimes just start seeing things... :D

[Dogway]

Just updated TransformsPack (https://github.com/Dogway/Avisynth-Scripts/blob/e4a6f2dddc8f585fcdf5c1ff509bf5d76e3a8723/TransformsPack%20-%20Models.avsi#L560) with the conversion functions of YUV and YIQ, to and from RGB and YCbCr as explained in this post (https://forum.doom9.org/showthread.php?p=1989126). Aside from that and some notes and cosmetics a fix in some indexes for color_coef(), basically XYZ and NTSC-J were wrong.

Next I'm going to fix HLG for its two flavors, and implement an state of the art tonemapper.

[LeXXuz]

I'm still fiddling with some settings to upscale SD content to 720p. And deep_resize is still my favourite choice. Is there any tweak to set to put some more punch into textures while hardly touching sharp edges, which causes even stronger halos on poor sources? Well, I could run LSFplus afterwards, but I'd like to use as few steps as possible.

[Dogway]

SD to 720p is not much of an upscale so I don't know what could be the gains, but I started deep_resize() dev using sinc4 and it was quite good for textures, then I noticed some ringing could leak outside the edge mask and decided to default lanczos8 and leave sinc4 only for HD to UHD.
I noted in the script:
'Sinc' low taps -ie. 4- is worth testing, creates some faints halos specially for SD to HD so see whether it's faint enough for you

I haven't played much with SincLin but it promises similar characteristics as sinc minus the halos, maybe give it a go. Just updated TransformsPack - Main because I didnt update the call args (SincLin is now internal function).
Another crazy idea, is to use static grain to detailed areas, so maybe you can hack FilmGrain+ to be static and pass it through a detail mask. It will work as a cheap way of hallucination.

I want to share a remaster I was doing yesterday which is similar in nature. The source is an horrendous upscale of a dumb deinterlace. So you get aliasing, shimmering and all the stuff.
I didn't know how to proceed, descale, re-deinterlace? didn't seem to work out, so I did a similar job as The Mission (pixelated mess), descale, antialias, QTGMC+ deshimmering, some avisynth-fu and filmgrain to add hallucination.

Source..........................................................................................................................................Remaster
http://i.imgur.com/PRaxJ0Sl.png (https://i.imgur.com/PRaxJ0S.png)............http://i.imgur.com/dLZEN1il.png (https://i.imgur.com/dLZEN1i.png)


DeGaussResizeMT(1024,576,order=1,p=100)
SantiagMod(strh=0,strv=1)

a=last
QTGMCp(TR0=0,TR1=1,TR2=2,Preset="Slower", InputType=1, sharpness=0.0) #deshimmer; some ghosting beware

LR=ex_edge(ex_Luma_Rebuild(5.0, 0.03),"kroon")
MM=MotionMask(LR,lo=10,sharpness=1) # It's better to detect motion from edge masks
ex_merge(ex_LFR(a,LFR=400),MM,luma=true) # Restore LFR only on motion areas (deghost + desmear)

ex_LFR(ex_unsharp(-0.5,Fc=width()/1.5),LFR=700) # Deconv only on LFR areas

a=last
DH=DeHalo_alpha(rx=1.7, ry=1.7, darkstr=1.0, brightstr=1.0, ss=1.5, lowsens=50, highsens=50)

# Flat mask block
FlatMask(1.0,scale=50,invert=true)
ex_boxblur(4)
ex_binarize(200)
ex_expand(3)
ex_inflate()
removegrain(20)

ex_merge(a,DH,last,luma=true) # Dehalo only on edges next to flat areas

deep_resize(1920,grain=0.0)
ex_unsharp(0.3,Fc=width()/1.5,safe=true) # Remove some of the dreamy look
ex_unsharp(1.0,Fc=width()*2.0,safe=true) # Extra fine sharpness
FilmGrainPlus(preset="16mm",sharpness=0.5,skin=0.8,str=1.2,mode="log",hi=0.2)

By the way, I will probably implement the motion mask trick into MotionMask, temporal derivatives are more accurate when computed on edge masks rather than source directly, at least from my tests yesterday.

[LeXXuz]

That is some very nice outcome. :eek: I'll definitely will play around with that. Thanks a lot for sharing the script. :thanks:

[DTL]

I did a b2b comparison between two encodes of a problematic source and had the impression tr6 with r looked better, even a little bit more stable, than tr12.:D

If motion vectors are not correct - increasing tr will cause more blurring. The old idea of MDegrainN was about lowering thSAD for the far frames from current to decrease this effect. So with not very good motion vectors it may be better to set thSAD2 to lower values.

"I started deep_resize() dev using sinc4 and it was quite good for textures"

If sinc (unweighted) is really sharpest - and weighting of sinc cause sharpness loss - may be try to test even more higher amplitude of sin ?
Current sinc is sin(x)/x. With weighted sinc x become higher as x increases. So to make sinc 'more unweighted' we can tweak x-divider in sinc(x). Current sinc(x) is sin(x) x 1/x . The 1/x multiplier can be replaced to higher argument function as x increases. So it will keep sinc(0)=1 to keep current samples values unchanged but will have higher amplitude of near lobes. May be test 1/(0.5x) ? Or 1/(x^0.5) and others.

[Dogway]

If sinc (unweighted) is really sharpest - and weighting of sinc cause sharpness loss - may be try to test even more higher amplitude of sin ?
Current sinc is sin(x)/x. With weighted sinc x become higher as x increases. So to make sinc 'more unweighted' we can tweak x-divider in sinc(x). Current sinc(x) is sin(x) x 1/x . The 1/x multiplier can be replaced to higher argument function as x increases. So it will keep sinc(0)=1 to keep current samples values unchanged but will have higher amplitude of near lobes. May be test 1/(0.5x) ? Or 1/(x^0.5) and others.

Yes, that might work, not sure what filter exposes amplitude though, otherwise I need to model it and feed into fmtc, a bit cumbersome but sinc4 is already bordering the limit, if source is already too sharp it will create pixelation and heavy ringing.

I want to note my above script is a bit rough, but works for me since it's a quick personal remaster I did yesterday, you can go nuts configuring QTGMCp, better dehalo mask, 16-bit pipeline, etc. The trick with SD upscales is to add a bit of de-emphasis, the ex_unsharp deconvolution call in my script.

[LeXXuz]

SD to 720p is not much of an upscale so I don't know what could be the gains,

I think I start to see what you mean. I did an upscale to 1080p for comparison and the overall picture looked a bit better or more balanced if you will.

The resize to 720p was out of a necessity at first. It was for some clips for a 720p display with very poor scaling.

And then I played around and started to realize that the SD content looked a tad better when upscaling. So why not encode my DVD content to 720p or even 1080p now if it benefits the visual impression of the picture.

In this case I don't mind if the final clip gets bigger than the source.

I never considered this because I always thought you can't 'create' new or finer detail through upscaling. What isn't there in the first place, won't be there if you enlarge it. So why even bother?

Yet, it looks a tad better. I even let other people do some blind comparisons and they always chose the upscale with deep_resize. So I guess it can't just be me imagining things.

Which now brings me to an important question. Is it recommended to upscale first and then denoise/clean the picture or clean it first and then do the upscale?

I'm leaning towards the first one, but I'm not quite sure. Obviously there is a speed difference, but that is secondary.

[Dogway]

Rather than 1080p the natural thing to do with upscales is an integer upscale, so 2x, because you don't have to mangle (read blur further) the pixels. So that's the optimal upscale ratio.

You can denoise after upscale but I like before for two reasons, performance, but also because deep_resize upscale will try to sharpen texture and along that noise/grain and that increases SAD. So try both ways, you can always mask out details from the upscaled version.

[DTL]

"Is it recommended to upscale first and then denoise/clean the picture or clean it first and then do the upscale?"

If you can process upscaled (slower) it is better to process upscaled. It will be equal to increasing pel in mvtools over 4. As I see with some synthetic simulation with 'clean' source and AddGrain() and SSIM metric after denoise - going from pel=2 to pel=4 adds SSIM metric significantly. So if you 2x upscale first and process with pel=4 it will be close to processing original with pel=8. Will try to test if 2x upscaling before denoise adds visibly to SSIM metric if process with max currently supported pel=4 of mvtools. But the blocksize may need to be adjusted too (to 2x).

"Yet, it looks a tad better. I even let other people do some blind comparisons and they always chose the upscale with deep_resize. So I guess it can't just be me imagining things."

It may depend on both quality of scaler in display device and MPEG encoder action. If MPEG encoder receive upscaled - it typically uses more bits to output and the resulted bit*(original_pixel)/frame quality measure increases. So the MPEG encoder will keep more textures and other quality things. And display upscaler may be as poor as bilinear or short kernel bicubic so not best for big upscale ratios required for SD sources to FHD and larger screens. With source pre-upscale with some best available scaler you can close to hide any visibility of poor display scaler.

The SD era was really 'long' in current civilization and many good engineers worked in that time to make it close to 'perfect' in 'per_pixel' quality (so for high-end DVD players the DACs of 108 MHz used - not lowest possible 13.5 MHz). In the next move to HD and larger production typically pay much less attention to 'per_pixel' quality so a much poorer display scaler may be used in many consumer display devices. As the visual industry went to digital and HD (HD+) - it really degraded in its engineering potencial already as much as it already forgot to put to standard the restoration display scaler. So any scaler can be used by the manufacturer and give different quality. At the end of analog era with SD the semi-digital design of video systems did not define vertical scaler for line-based frames and the H-scaler expected to be simple sinc of the DAC to display at CRT. So requirements for visual system DAC at first were 'natural' and not put to standard (the standard operates in terms of analog systems like frequency response curve and it must be non-distortive (flat)). And after moving to digital the required standards for scale digital content were completely missed.

[LeXXuz]

Thanks guys for your valued input. :thanks:

[Lan4]

Hello! Help me which kernel to use for deep resize, optimal or with improved textures.
Sources: 1080x1920, about 3500 kb/s, H264
Target: 720x1280, about 800 kb/s, H265

[Dogway]

Default (SSIM2) is fine for downscaling, specially if the display is going to upscale again on TV, tablet, or elsewhere. Downscales don't do edge/flat distinction. If the target display is indeed 720p you might want something softer like spline16 or so.

[Lan4]

If no width or height is specified, is the value applied as the width?

If the kernel is not specified, then the value is taken from the list of default kernels for a specific width?

The point is that phone (portrait) resolutions are reversed, as in my case.

[Dogway]

The kernel is evaluated on horizontal aspect ratios, so if your source is portrait ratio you might want to rotate it 90º, apply a deep_resize() to your target resolution with show=true and check the kernel chosen. Then apply those settings to the original video/image.
TurnLeft()
deep_resize(x,show=true)

If you don't specify a target resolution, for example you say, I wan't half the size: deep_resize(0.5), it will keep the portrait aspect ratio.

[Dogway]

Just released TransformsPack v2.2.0. As promised I ported the state-of-the-art OpenDRT tonescale.

So what's left? Finishing the two HLG flavors and their OOTFs, information/resources are mixed so I will need to do some bit of research.

[LeXXuz]

ex_unsharp(1.0,Fc=width()*2.0,safe=true) # Extra fine sharpness



This line irritates me. Will everything below or above the cutoff frequency heavily sharpened? I always thought everything below, but then I don't quite understand the 'extra fine sharpness' description.

Extra fine sharpness would mean to me to sharpen just the finest details (or highest frequencies), which would imply everything above that high cutoff frequency. It's late and I'm confused :o:D

[Dogway]

Will everything below or above the cutoff frequency heavily sharpened? I always thought everything below, but then I don't quite understand the 'extra fine sharpness' description.

Everything at* the cutoff frequency.

*This is generally how sharpeners work but in my implementation I added a twist by providing 20% of the sharpening from a lower discreet frequency cutoff (for structural support) at no perf cost. Normally you don't want sharpening lower frequencies because they add noticeable thick ringing, but 20% of Fc=width() or even 2*width() is safe and helps details pop up.

In the case of 2*width() you are sharpening at subpixel (and 20% at pixel) level, so kinda "creating" the impression of more details.

[LeXXuz]

Everything at* the cutoff frequency.


Whoops! :o Now it starts to make sense to me. Thanks for the explanation. I guess the name 'cutoff' confused me in that case. Let's blame the language barrier. :D

So just to be sure; if I use ex_unsharp() without any frequency specified, it will sharpen/blur the entire spectrum, right?

[Dogway]

So just to be sure; if I use ex_unsharp() without any frequency specified, it will sharpen/blur the entire spectrum, right?

No, as far as I know you can't do that, you have to sharpen at a certain spectrum. The cutoff term is because you apply a lowpass at that cutoff frequency (everything above will be blurred/ditched), then make a diff + add to the source. You could say, well yes you are sharpening at that cutoff frequency and above, but it's easy to prove that wrong when you sharpen at width()/2.

In the specific case of ex_unsharp() I intentionally included a lower cutoff sharpening with a 20% contribution for structural support. This is, among others, a feature of my unsharp implementation.

[LeXXuz]

In the specific case of ex_unsharp() I intentionally included a lower cutoff sharpening with a 20% contribution for structural support. This is, among others, a feature of my unsharp implementation.

Ah. Now it makes perfect sense and explains the results from my tests which made me really scratch my head before. Shows what I knew about sharpening :rolleyes:
Thanks Dogway. :)

[madey83]

Hi,

So what is the best sharpening method:

Unsharp or LSFplus or maybe contrasharp from SMDegrain?

[Dogway]

So what is the best sharpening method:

Unsharp or LSFplus or maybe contrasharp from SMDegrain?

You also have FineSharp+.

In any case as you can see by my examples I'm lately digging ex_unsharp(), if your source is denoised it can work well, you can also use 'th' to not sharpen subtle changes (left over noise).

LSFplus is also very good as the sharpening is non linear. As explained above what is being sharpened is the roll-off range, in the case of ex_unsharp() a binomial/gaussian roll-off. Either LSFplus or FineSharp+ have settings to model this non-linear roll-off. By default using 'mode="LSF"' is quite good and fast, and won't sharpen noise. The problem is that if you overdo it it can look like oil painting.

I can't tell much more, you have to test depending on source, taste of the moment, etc

[Lan4]

The kernel is evaluated on horizontal aspect ratios, so if your source is portrait ratio you might want to rotate it 90º, apply a deep_resize() to your target resolution with show=true and check the kernel chosen. Then apply those settings to the original video/image.
please clarify how best to proceed.

1. Rotate the video 90 to the left.
2. apply a kernel suitable for the width.
3. Rotate the video back to the right.

Sorry, I did not find a list of automatic selection of kernels by resolution by width. Maybe it's better to always manually choose the kernel that looks best?

[Boulder]

Do you have any recommendations on how to fix the very thin vertical lines in this material? It's not very visible at 100% but when you zoom in, it's easy to see. I'd like to do very light processing so I cannot just blur it all away :)

https://drive.google.com/file/d/1IydxWHsuUf1dnGDnWcAiwzOimSQvB2S4/view?usp=drive_link

[Dogway]

yes, sorry I've been sick. I'm back on Monday

[Dogway]

Do you have any recommendations on how to fix the very thin vertical lines in this material? It's not very visible at 100% but when you zoom in, it's easy to see. I'd like to do very light processing so I cannot just blur it all away

mmm, I'm not seeing it. Do you mean the one frame little dust-like white streaks?
please clarify how best to proceed.

1. Rotate the video 90 to the left.
2. apply a kernel suitable for the width.
3. Rotate the video back to the right.

Sorry, I did not find a list of automatic selection of kernels by resolution by width. Maybe it's better to always manually choose the kernel that looks best?

The defaults are the recommended kernels given the width(), so if your source is height dominant simply turn it 90º to check what deep_resize() suggests, then apply that normally to your source:
Source
TurnLeft()
deep_resize(n,show=true)

Note down the kernel(s) used and taps then:
Source
deep_resize(n,edge="recommended1",flat="recommended2")

[Boulder]

mmm, I'm not seeing it. Do you mean the one frame little dust-like white streaks?

This image shows them quite well, like the area around the character's nose. Not exactly macroblocking but something odd I've not noticed before in sources which are not upscales. It was quite apparent in my ex_makediff comparison, where I compare the downscaled-reupscaled clip with the original.

https://i.ibb.co/C0Y0H6n/hot.png

[poisondeathray]

@Boulder - Did you try destripe ?

[Dogway]

Ah yes, it didn't show well on playback in MPC-HC.

You can use (ex_)vinverse() or some blur and post sharpening:
turnleft()
vinverse()
turnright()
EDIT: ex_vinverse() was blurring more due to a missing HBD var scaling (now fixed)
ex_blur(1,0)
ex_unsharp(1,0)

[Boulder]

@Boulder - Did you try destripe ?

Ah yes, it didn't show well on playback in MPC-HC.

You can use (ex_)vinverse() or some blur and post sharpening:
turnleft()
ex_vinverse() # vinverse() has issues on HBD
turnright()
ex_blur(1,0)
ex_unsharp(1,0)

Thanks, ex_vinverse seems to work well with this one. Destripe blurs quite heavily, though it fixes the issue all right :devil:

[LeXXuz]

Well, still learning, reading and trying to better understand my favourite script. ;)

But may I have a crash course on what is the difference between modes "TemporalGauss", "TemporalSmooth" and "TemporalSoften"?

And maybe a brief explanation on when to prefer one of those over the others or even the default "Mdegrain" mode?

I did some testing and see differences but I can't really conclude what mode may be better for what scenario.

[tormento]

Ah yes, it didn't show well on playback in MPC-HC.
Don't trust players for video quality, sometimes they use shortcuts.

Open them in VDub or AVSPMod.

[tormento]

Now that you called them, please suggest me some filter for macroblocking artefact attenuation from bad AVC compression.

There was grain in the original video and the BD author starved the bitrate, so... shit in shit out.

[Dogway]

Now that you called them, please suggest me some filter for macroblocking artefact attenuation from bad AVC compression.

There was grain in the original video and the BD author starved the bitrate, so... shit in shit out.

Maybe CCD() as prefilter for SMDegrain. Then maybe some structure reinforcement with ex_unsharp(Fc=width()/2.0) or the like. Adding back some grain on top might help to bring out missing high freq details.

[tormento]

With a simple

SMDegrain (tr=3, thSAD=300, refinemotion=false, contrasharp=true, PreFilter=7, plane=4, chroma=true)

I get error

Script error: There is no function named 'color_propGet'.
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-4.5.0d~Dogway.avsi, line 1214)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-4.5.0d~Dogway.avsi, line 329)

[kedautinh12]

It's belong to TransformsPack - Main
https://github.com/Dogway/Avisynth-Scripts/blob/013cd48baac92dfd1c343afdf66b5ece38745924/TransformsPack%20-%20Main.avsi#L1636

[tormento]

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!

[DTL]

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/releases/tag/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.php?p=1990183#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.

[LeXXuz]

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


Oh I want that. :eek: Pretty please with a cherry on top @ Dogway :rolleyes::D:o

[kedautinh12]

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

[DTL]

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/commit/2c30382aaea57f4224553359debe475b1b2e045c ).

[anton_foy]

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/commit/2c30382aaea57f4224553359debe475b1b2e045c ).

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?

[DTL]

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/tree/pinterf_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/releases/tag/r.2.7.46-e.02 . Found while trying to use Auto-thSAD with > 8bit clips.

[LeXXuz]

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?

[Dogway]

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

[LeXXuz]

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.

[Dogway]

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.

source
src=last

SMDegrain()
den=last

ex_ContraSharpening(src) # or LSFplus in contra mode

ex_makeadddiff(last,den,src)

[tormento]

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

[Dogway]

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.

[Boulder]

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.

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?

[Dogway]

Yes, sorry I forgot that ex_makeadddiff() also accepts two inputs so I was thinking on implicit "last".

it should be:
ex_makeadddiff(last,den,src)
Also fixed above

[DTL]

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.

[Dogway]

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.

[DTL]

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.

[poisondeathray]

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"

[Dogway]

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 (https://youtu.be/sGKCrcNsVzo)

RTX VSR is simply DLSS applied to video (super resolution)

[LeXXuz]

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.

source
src=last

SMDegrain()
den=last

ex_ContraSharpening(src) # or LSFplus in contra mode

ex_makeadddiff(last,den,src)

Well this way I get a picture that is almost as noisy as the original but with the grain being static now. I already noticed the missing last argument in the first version of your post and corrected that.

I could post screenshots, but to spare me the hassle with an image provider, I'll just post SAD values from mvtools. Hope you'll take my word for it.

untouched: 26455
denoised: 7720
denoised with internal contrasharp: 8477
denoised with external cs and makediff: 25965

mvtools script:
super = MSuper(mt=false, pel=2)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, search=3, chroma=true, mt=false)
MShow(super,forward_vec1, showsad=true)

(In case someone wonders about those numbers, they are in 16bit´. You have to divide those by 256 if you want a relation to those numbers you use with SMDegrain.)

Idk, maybe it is intended that way. But the denoised areas should still be clean which they are not and those numbers reflect that obviously.

[Dogway]

Maybe the principle was ill-founded, try to do an ex_makediff between src and denoised -with LFR- (grain extract) then add that to the sharpened-denoised clip

ex_makeadddiff(den,src,last)

[kedautinh12]

I have that error when you SMDegrain
SMDegrain(6, 400, prefilter=5, ContraSharp=true, RefineMotion=true, plane=4, limits=false, DCTFlicker=false)
https://i.imgur.com/yuxGTcE.png

[Dogway]

I have that error when you SMDegrain
SMDegrain(6, 400, prefilter=5, ContraSharp=true, RefineMotion=true, plane=4, limits=false, DCTFlicker=false)

Thanks! Just fixed. I forgot to update the new Super global variable that I changed in SMDegrain to align to QTGMC+

[kedautinh12]

Hi Dogway, I tried QTGMCp but can't fix the interlaced video of some scenes, can you help me how to fix that??

Frame 920
https://i.imgur.com/Q4PppXn.png

AssumeTFF()
QTGMCp(Preset="Medium", Sharpness=0).SelectEven()

Sample:
https://drive.google.com/file/d/1oatclOhzlOtYIs527liyP72h7x5hY_mt/view?usp=sharing

[Selur]

resize to 1920x540, then upscale back to 1920x1080

[Dogway]

The moiree effect is present even in the fields so you might need to target the issue locally as postprocessing I think.

[kedautinh12]

The moiree effect is present even in the fields so you might need to target the issue locally as postprocessing I think.

Can you have any suggestions script for that??

[kedautinh12]

resize to 1920x540, then upscale back to 1920x1080

resize after or before Deinterlaced??

I tried and got better results but I still have errors
propSet("_FieldBased",0)
deep_resize(1920,540,grain=0)
deep_resize(1920,1080,grain=0)
AssumeTFF()
QTGMCp(Preset="Medium", Sharpness=0).SelectEven()

[kedautinh12]

After updated QTGMC+ to latest ver with moiree option, I tried but still doesn't work
AssumeTFF()
QTGMCp(Preset="Medium", moiree=true, Sharpness=0).SelectEven()

[Selur]

I did have an additional look the sources:
a. seems like DVD resolution at best, so you could probably downscaling to dvd resolution without loosing detail.
b. Dogway is right, this isn't caused by deinterlacing and won't be fixed by it, this would require some specific local processing like copying parts of a previous frame/field over to the broken ones
=> probably not worth the effort this would require

[kedautinh12]

I did have an additional look the sources:
a. seems like DVD resolution at best, so you could probably downscaling to dvd resolution without loosing detail.
b. Dogway is right, this isn't caused by deinterlacing and won't be fixed by it, this would require some specific local processing like copying parts of a previous frame/field over to the broken ones
=> probably not worth the effort this would require
a, i try downscaling to DVD but errors won't gone

[kedautinh12]

Ok, I tried other Deinterlaced scripts and work very well. Some scenes have ALIASING after Deinterlaced. Therefore, I fixed it with ANTI-ALIASING
AssumeTFF()
AnimeIVTC(mode=1)
daa3mod()

[Boulder]

@Dogway: do you have any recommended method for stabilizing luma changes for a more accurate scene change detection with ffmpeg? I tend to get quite a lot of false detections just because the brightness between frames seems to change a bit (Withnail and I from the early 80s, rather LQ Blu-ray). If I raise the detection threshold, it starts missing too many scene changes to be useful. I'm not looking to catch all of them so I have some wiggling room. I've tried downscaling, severe blurring and using ex_luma_rebuild but no real help there.

[Dogway]

If it's some kind of luma flicker try ex_autolevels() (example (https://forum.doom9.org/showthread.php?p=1982586#post1982586))

Otherwise yes, you have to temporal blend the frames, except those for scene changes, so a catch-22 situation.

It depends if you want surgeon denoising, or a simple temporal blend, in such case replace the denoise with a TemporalSoften().
With SceneStats you can work on a scene basis, also it inherits SC weight from the source frame type.

Here are some examples:
https://forum.doom9.org/showthread.php?p=1982586#post1982586
https://forum.doom9.org/showthread.php?p=1985953#post1985953
https://forum.doom9.org/showthread.php?p=1976405#post1976405
https://forum.doom9.org/showthread.php?p=1969107#post1969107 (I recommend putting SMDegrain/TemporalSoften outside ScriptClip)

[alexx7777]

18482Thank you very much for the work done. I'm getting an nmod error. For what reason and how to solve?

[kedautinh12]

18482Thank you very much for the work done. I'm getting an nmod error. For what reason and how to solve?

Up image to another sever or you will waiting for mod approval forever :D

[alexx7777]

gives an error message (https://disk.yandex.ru/i/HKKUTOkRI7eprQ)

[kedautinh12]

gives an error message (https://disk.yandex.ru/i/HKKUTOkRI7eprQ)

Did you update all scripts of Dogway to latest ver??

[alexx7777]

Did you update all scripts of Dogway to latest ver??
Downloaded from here (https://github.com/Dogway/Avisynth-Scripts/blob/master/ResizersPack.avsi)

[Dogway]

@akexx777 That's an error on line 215, basically a nmod() call in the Defaults definitions. It works for me so ensure everything is updated and no other older ResizersPack is present.
You can also try with this call nmod(8/2,2,4) which is what is failing on line 215

[alexx7777]

@akexx777 That's an error on line 215, basically a nmod() call in the Defaults definitions. It works for me so ensure everything is updated and no other older ResizersPack is present.
You can also try with this call nmod(8/2,2,4) which is what is failing on line 215
Thank you very much, everything worked!

[tormento]

What about using avs_libplacebo in some of your scripts? It's some weeks that I am playing with it and it's really fast and powerful.

The mitchell downsizing filter is something astonishing to get native anime resolution.

[DTL]

I'm still struggling with a bluring effect with SMDegrain in moving areas which really disturbs the overall look of the picture.
To elaborate: I've uploaded four samples of a short scene. Original, 2x denoised with SMDegrain (thSAD 400 and 200)


New tests with 2 stages (non-linear median-like and linear low pass with Gauss kernel) MVs filtering in new MDegrainN release of 26.09.2023 - https://forum.doom9.org/showthread.php?p=1992038#post1992038

Still first generation of MVs (no refining) and no prefiltering. mvtools2 script only.

[LeXXuz]

Looks clearly better, especially the skin tones and areas. :)

[tormento]

I am swearing with the ending of an anime.

The first part (https://pixeldrain.com/u/6o3sShft) of the ending is a resized 1080i 59.94, the second part (https://pixeldrain.com/u/3tedTfUr) is a true (I think) 1080i 59.94.

I want to convert them to 23.976 as the rest of the anime. For the second part, I tried to deinterlace and apply IVTC via DGTools but it becomes a mess, as its not a true telecined video.

For the first part I have no ideas too.

:thanks:

[Selur]

you could try TFM+sRestore

[tormento]

you could try TFM+sRestore
Is proper to deinterlace without downscaling?

Talking about the first video.

[kedautinh12]

I tried this script with the second part and it's a good result but you need to add some dehalo/dering and derainbow to get a better result

QTGMCp(Preset="Very Slow", Sharpness=0).SelectEven()
prefetch(2)

https://drive.google.com/file/d/1f2dMzKeZbTqxOwWrN2KoyPwg-WmZ3L4y/view?usp=drive_link

[tormento]

I tried this script with the second part
Thanks but the problem isn't deinterlacing but get a decent 23.976 ;)

[Sharc]

Weird. For the first part try something like

converttoYV12(interlaced=true)
BWDIF(field=3).selecteven()
RestoreFPS(23.976,1.0)

Edit: still messy,sorry

[anton_foy]

Is there a special scene or frame you have issues with? I tested with the Carrie call (I use tr 1 and 2 and thSAD=400 for the 2nd call) and found it good enough.
Also keep in mind this is a BW film so plane=0 and chroma=false.

The film shows "fizz" grain. It's in between the Carrie example and something stronger like 300. I found that a blksize of 32 is good to avoid catching these kind of big grains, along refinemotion this is a good approach. Filters like SPresso or STTWM are not suited here because they only filter minimal change noise, these are more for DVDs or faint grain.
My general approach with strong grain is a rather strong prefilter (with LFR), and a rather not so strong filter without LFR.

Personally for my encodes I don't like the clean look because they either look psychovisually blurry or sometimes it shows the "screen" effect, like grain stuck over a glass, so I apply some artificial grain after denoising.

@Dogway, how to achieve the "screen" effect you mention here? You mean like applying temporal denoising on a spatial denoised difference kind of? I would like to try this technique just for an experiment.

[Lan4]

Hello. Question about FineSharpPlus.

I use values:
FineSharpPlus(mode=1, sstr=1, cstr=0.1, xstr=0, lstr=1, pstr=4, ldmp=0, hdmp=0)

If you increase "pstr" more than 4, the difference in the result will be almost invisible. If "lstr" is set to 2 (or above), then the difference at pstr=4 or higher becomes more noticeable. This is right?

[Lan4]

Question about using the kernel in DetailSharpen and FineSharpPlus. I'm watching the preview in AvsPmod.

Using gaussian kernel in DetailSharpen(mode=0). Look at the furrows in the image that are most noticeable on the face.
https://i.postimg.cc/fTCNXDpd/1.png

Using box kernel in DetailSharpen(mode=1). Now the furrows have disappeared.
https://i.postimg.cc/Ssc0KhcJ/2.png

Using gaussian kernel in FineSharpPlus(mode=1)
https://i.postimg.cc/SR4B2vGV/3.png

And using box kernel in FineSharpPlus(mode=-1).
https://i.postimg.cc/7hNpgns4/4.png

There is no difference. Furrows are present in both last examples, as if the kernel is not switching. Am I right or wrong?

The question is more of a scientific one, since furrows are not visible after encoding, or almost invisible.

[fabioseixal]

@Dogway, I've been experimenting ex_Vibrance(), to be more precise the Recovery mode to get back the proper saturation after rainbow removal.
The issue is that ex_Vibrance is working okish, i.e., it does recover contrast in areas that where lost, but the problem is that it is also getting back the rainbows in some places.
There also frames where the issue is even worse than before (see below)

Any idea why? I mean, any idea if this can be avoided?
This idea of getting back the contrast after removing the rainbows is a neat idea and it would be awesome to be able to make use of it.


Here is an example.

Source: (Rainbow is visible in the centre near the hole, near the vertical lines etc)

https://i.imgur.com/j268GsV.png]

Source + Scomb: Rainbows are gone

https://i.imgur.com/fBQWd61.png

Source + Scomb + ex_Vibrance: Rainbow is back and vertical lines are now surrounded by a Yellowish "aura", i.e., rainbow effect is accentuated

https://i.imgur.com/QUOwFCz.png

Script used:

DGSource("ep1.dgi")

vibrance=last
scomb()
ex_vibrance(1.0, mode="Recover", Rc=vibrance)

PS: Yes, the video is interlaced, that's where scomb really shines. Probably that's the issue... oh well
PS2: I made the same test but with progressive video and the issue remains exactly the same

[Dogway]

Sorry for the delay, I'm quite busy now with APP development.

@fabioseixal: I think in this case it's better to increase saturation or vibrance. If your filtering is local then the difference of saturation in "recovery" mode is also going to be local. "Recover" works better with mostly global desaturation like denoisers and such.

For DeRainbow I used to use:
edgy=FlatMask(2.0).ex_expand()
ex_merge(last,FFT3DFilter( sigma=2, sigma2=8, sigma3=12, sigma4=4, bt=3, plane=3, ncpu=4),edgy.ex_expand(),Y=2,UV=3,luma=true)

but FFT3DFilter is slow so you can try other denoisers.
I also had this expanded version which kills rainbowing further and preserves saturation a bit better.

o = last
derain = o.ex_median("median",Y=2,UV=3)
Hmed = ex_luts(o,o,mode="median",pixels="-2 0 -1 0 0 0 1 0 2 0",UV=2)
Hedge = ex_lutxy(Hmed,o,"x y - abs 8 *",UV=128)
ex_merge(o,derain,Hedge.ex_expand(2),luma=true,Y=2,UV=3)

edgy=FlatMask(2.0).ex_expand()
ex_merge(o,FFT3DFilter( sigma=2, sigma2=8, sigma3=12, sigma4=4, bt=3, plane=3, ncpu=4),edgy.ex_expand().ex_vibrance(1),Y=2,UV=3,luma=true)


Question about using the kernel in DetailSharpen and FineSharpPlus. I'm watching the preview in AvsPmod.

Using gaussian kernel in DetailSharpen(mode=0). Look at the furrows in the image that are most noticeable on the face.

There is no difference. Furrows are present in both last examples, as if the kernel is not switching. Am I right or wrong?

The question is more of a scientific one, since furrows are not visible after encoding, or almost invisible.

I'm not sure to understand "furrows" in this case, but the implementation in both sharpeners are different, to compare them equally you'd need DetailSharpen() with med=true. As for FineSharpPlus' I might revise the non-linear values as I get a gray clip out of shrpD var. Actually I fixed an issue on _cstr var as spline() was going out of bounds.

[Lan4]

In Finesharp, increasing the LSTR and PSTR parameters softens the sharpness. In FinesharpPlus, on the contrary, it increases sharpness. I'm right? Showing a preview from AvsPmod:

https://imgsli.com/MjE2NDkx

[Lan4]

This is how I understand how Finesharp works. LSTR softens flat areas and textures. PSTR softens edges without affecting flat areas or textures. Screenshots after encoding:

sstr=5, lstr=1, pstr=1 (all other values are at minimum, 0 or 0.1)
https://i.postimg.cc/RVBDhJqp/100-BSG-4-14-new1.png


sstr=5, lstr=5, pstr=1
https://i.postimg.cc/JzT6pTxS/100-BSG-4-14-new2.png


sstr=5, lstr=1, pstr=5
https://i.postimg.cc/N05NS1PF/100-BSG-4-14-new3.png


But I don't understand how FinesharpPlus works. I have to guess with the values to get the result I want.

[Dogway]

@Lan4: Sorry for the delay, FineSharp non-linear sharpening is an old implementation, whereas FineSharpPlus one is based on LSFplus in Smode=5, if any you might want to compare to that. This is not to say everything's right on FineSharpPlus, the contrary, I need to give it a review to see why I'm getting a flat grey shrpD clip, as well as confirm your suspicions. When I get some time I will let you know. Maybe I open an issue ticket on the repo so I don't forget.

[poisondeathray]

ex_vibrance does not seem to work for 10bit or 12bit 420/422/444 input. 8bit, 14bit, 16bit ok

Do you prefer issues reported here or github issues tracker ?

[Lan4]

I think maybe Finesharp is outdated and we need to leave it and modifications in the past? Difficulties arise here and there, and his behavior is often unpredictable.
The values do not increase by one, and sometimes increasing a parameter does not give anything at all, for example, I have ldmp 1=ldmp 2.
Artifacts, blockiness, grids, stripes, halos or ringing appear. Logically this is not related to decreasing and increasing sharpness. This happens randomly, on its own, and just as suddenly disappears.
Sometimes the opposite effect occurs, I increase the softening, but after encoding the sharpness is somehow higher. Sometimes "lstr" and "pstr" do the work for each other, and reducing the edges suddenly reduces the textures, or vice versa, working with textures changes the edges. Moreover, this happens inconsistently.
All this makes the use of Finesharp unpredictable.
In fact, I know three non-linear sharpeners - LSF, Finesharp and DetailSharpen. Moreover, I don’t know how to achieve a strong increase in texture sharpening in LSF, and it cannot be called a small and fast filter. Is it possible to create a modern filter replacement?

[kedautinh12]

You can try ex_unsharp
https://github.com/Dogway/Avisynth-Scripts/blob/24432b3980208582f7175f74107a1415b6175b68/MIX%20mods/SharpenersPack.avsi#L484

[Lan4]

You can try ex_unsharp
https://github.com/Dogway/Avisynth-Scripts/blob/24432b3980208582f7175f74107a1415b6175b68/MIX%20mods/SharpenersPack.avsi#L484
Of course I already tried ex_unsharp. This filter only sharpens edges and can soften textures. But if you expand the threshold down, I think it will increase the sharpness of the textures. What I once wrote to Dogway about. But this requires a new filter.

[poisondeathray]

Sometimes the opposite effect occurs, I increase the softening, but after encoding the sharpness is somehow higher.

And what does it look like before encoding, or using better settings than CQP 28? Your inconsistent results are at least partially result of your encoding settings, not only the filter . When examining the effect of filter, use lossless encoding so you examine the effects of the filter, so it's not distorted by other a dozen other factors

[Emulgator]

Is it possible to create a modern filter replacement?
I would try SSSharp, MedSharp2.
Any more improvement above these will call for AI sharpeners.

[kedautinh12]

I would try SSSharp, MedSharp2.
Any more improvement above these will call for AI sharpeners.

Do you have any suggestions paramete for these???

[Lan4]

I would try SSSharp, MedSharp2.
These are slow and heavy filters. We're talking about a fast and easy filter.

[Emulgator]

Do you have any suggestions paramete for these???
Fully source dependent. Any grain, texture, moirè, halos respond differently.
But these two hit simpler algos out of the water. No size fits all, you got to try and err or succeed.
Fast and easy: Definitely not these. Who wants to gain quality, invests now and yields later.
Many thanks to Dogway for making these huge beasts available in working order again.

[Dogway]

ex_vibrance does not seem to work for 10bit or 12bit 420/422/444 input. 8bit, 14bit, 16bit ok

Do you prefer issues reported here or github issues tracker ?

Hey PDR, by the way thanks for the set_output() trick the other day.

These days I'm quite busy in other projects so I don't visit the forum as often. In Github I get notified by mail so whoever has an account there, an issue ticket is preferred.

I'm checking the issue right now and report back.

EDIT: Yep, can confirm. Having a look now.

EDIT2: Ok the issue is here and I can remove the optimization and it fixes, but I don't understand why it's happening.

rhlf = bi32 ? "2 *" : bi > 12 ? "range_half /" : string(1. / ex_bs(128,8,bi,!tv)) + " *"

Basically when bits are above 12, simply "range_half /", either (bits are 10 or 12) multiply by the reciprocal, so 1. / 2048 in the 12-bit case.

[Lan4]

And what does it look like before encoding, or using better settings than CQP 28? Your inconsistent results are at least partially result of your encoding settings, not only the filter . When examining the effect of filter, use lossless encoding so you examine the effects of the filter, so it's not distorted by other a dozen other factors
lossless made the result even worse. I used:
FineSharp(mode=1, sstr=2.2, cstr=0.2, xstr=0, lstr=1.8, pstr=7, ldmp=0.1)

CQP=0
https://i.postimg.cc/65w4TtGd/1023-MMM-new-a.png

Comparison CQP=0 and CQP=26
https://imgsli.com/MjE5NTI3

DetailSharpen fixes this by changing the kernel.

[tormento]

Is possible to apply different amount of denoising to chroma and luma?

With SMDegrain, of course.

[Dogway]

@tormento: You can specify thSADC for chroma, but regarding temporal radius, nope, you'll need to filter chroma with a second SMDegrain call, then merge Y from one clip and Chroma from the other.

[tormento]

@tormento: You can specify thSADC for chroma, but regarding temporal radius, nope, you'll need to filter chroma with a second SMDegrain call, then merge Y from one clip and Chroma from the other.


How have I to set planes and chroma switches to filter chroma and luma with different thSAD in the same line?

I have read that chroma can be “abused” more than luma in noise reduction and I want to try if true.

[kedautinh12]

Try mergechroma and mergeluma
avisynth.nl/index.php/Merge

Example:
a=last
lum=a.TemporalDegrain2(degrainPlane=0)
chr=a.SMDegrain(thSADC=300, luma=false)
a.mergechroma(chr).mergeluma(lum)

[Dogway]

How have I to set planes and chroma switches to filter chroma and luma with different thSAD in the same line?

I have read that chroma can be “abused” more than luma in noise reduction and I want to try if true.

Where did you read that? Unless chroma is ***ed up it usually uses a lower thSAD since it has a decreased contrast.
If temporal radius is the same, it's quite easy:
SMDegrain(tr=3, thSAD=400, thSADC=200)

Aside from kedautinh12 example, you can also use CombinePlanes()

[tormento]

Where did you read that?


FFT thread. Is it bullshit?

[kedautinh12]

I think with prefilter 6 and 8 will be better for chroma

[Blankmedia]

Hi, I was wondering what would cause these differences between these two versions:

https://i.imgur.com/IPHJdTm.png https://i.imgur.com/ETybvE7.png

The code to deinterlace is the one below, I'm trying to update my scripts and try something new.

I noticed more stuff going on with the new version. It as more shimmering, and blending.



### Deinterlace-Match Fields-Decimate ###
Function FieldMatch(Clip Cee) {
Global PeePee = Cee.DuplicateFrame(0)
Global CeeCee = Cee
Global NeeNee = Cee.DeleteFrame(0)
Pee2 = PeePee.SeparateFields()
Cee2 = CeeCee.SeparateFields()
Nee2 = NeeNee.SeparateFields()
Global PeeCee = Interleave(Pee2.SelectEven(),Cee2.SelectOdd()).Weave()
Global CeePee = Interleave(Cee2.SelectEven(),Pee2.SelectOdd()).Weave()
Global CeeNee = Interleave(Cee2.SelectEven(),Nee2.SelectOdd()).Weave()
Global NeeCee = Interleave(Nee2.SelectEven(),Cee2.SelectOdd()).Weave()
Global Deintee = QTGMCp(CeeCee, Preset="very slow",sourcematch=3, Sharpness=0.0, lossless=2 ).selecteven()
Return ScriptClip(CeeCee, \
"!CeeCee.IsCombedTIVTC(CThresh=12,Chroma=True,BlockX=16,BlockY=32) ? CeeCee : " + \
"!NeeNee.IsCombedTIVTC(CThresh=12,Chroma=True,BlockX=16,BlockY=32) ? NeeNee : " + \
"!CeeNee.IsCombedTIVTC(CThresh=12,Chroma=True,BlockX=16,BlockY=32) ? CeeNee : " + \
"!NeeCee.IsCombedTIVTC(CThresh=12,Chroma=True,BlockX=16,BlockY=32) ? NeeCee : " + \
"!PeePee.IsCombedTIVTC(CThresh=12,Chroma=True,BlockX=16,BlockY=32) ? PeePee : " + \
"!CeePee.IsCombedTIVTC(CThresh=12,Chroma=True,BlockX=16,BlockY=32) ? CeePee : " + \
"!PeeCee.IsCombedTIVTC(CThresh=12,Chroma=True,BlockX=16,BlockY=32) ? PeeCee : Deintee")
}

### Deinterlace-Match Fields-Decimate ###
function SimpsonsDesentrelace( clip IN, string "chemin" )
{
TFM(IN, Order=-1,Mode=5,PP=2,Clip2=FieldMatch(IN),Slow=2,MChroma=False,Ubsco=False,CThresh=12,mthresh=2,Chroma=True, micmatching=0, d2v=chemin)
TDecimate(Mode=1)
}





https://imgur.com/a/S6uD0VP (https://imgur.com/a/S6uD0VP)

Thank you!

[Dogway]

Animation is typically telecined unless this is a TV capture or something, this is not ideal.
QTGMC+ is mainly designed after live recorded video with more temporal coherence.

Try to add back the old bobber with:
UseEdiExt=1 (or 2 for vinverse filtered), EdiExt=ex_bob(src, 0,0.5,props=1)

[kedautinh12]

I got all green frame when use FilmGrainPlus with this video (https://drive.google.com/file/d/1gmnpk4vOf9Lt04RdlQYhqzkIycd2dgvw/view?usp=drivesdk)

script:
LoadPlugin("C:\Encode Tools\MeGUI-2944-64\tools\ffms\ffms2.dll")
FFVideoSource("C:\Users\ADMIN\Downloads\Aitai - SE7VN PV.avi", fpsnum=30000, fpsden=1001, threads=1, colorspace="YUV420P8")
FilmGrainPlus(preset="Vision2 5218 500T")

[Dogway]

Strange, no prob here. Using ffms2_r1387 and AVS+ r4003

[kedautinh12]

I test latest ver from Pinterf and got no error, i think it's from Asd-g's avs + compilie. Sr for disturb :D

[madey83]

hello,

can i ask for help with clearing out this clip:
https://mega.nz/file/sZZh2bpI#zK7jGmvE7xAM7gxR2YyN4oAfLTPVTpqB6eIUaHFhupk

thank you in advance for any help :)

[kedautinh12]

Result with RealESRGAN_x4plus_anime_6B
https://i.imgur.com/HBS8Hvi.png

Script:
z_ConvertFormat(pixel_type="rgbps", colorspace_op="709:709:709:l=>rgb:709:709:f")
mlrt_ncnn(network_path="C:/Program Files (x86)/AviSynth+/plugins64+/models/RealESRGAN/RealESRGAN_x4plus_anime_6B.onnx", builtin=false, fp16=true, tilesize_w=width/4, tilesize_h=height/4)
propSet("_FieldBased",0)
deep_resize(1280,720,edge="SSIM2")
z_ConvertFormat(pixel_type="yuv420p8", colorspace_op="rgb:709:709:f=>709:709:709:l")

[kedautinh12]

I tried with DPIR +UniScale CartoonRestore-lite + AnimeJanai and got this result:
https://i.imgur.com/3ynNODU.png

Script:
z_ConvertFormat(pixel_type="rgbps", colorspace_op="709:709:709:l=>rgb:709:709:f")
mlrt_DPIR(model=1, strength=6, tiles=2) # Denoise
mlrt_ncnn(network_path="C:/Program Files (x86)/AviSynth+/plugins64+/models/UniScale/2x_UniScale_CartoonRestore-lite.onnx", builtin=false, fp16=true, tilesize_w=width/4, tilesize_h=height/4) # Restoration
propSet("_FieldBased",0)
deep_resize(1280,720,edge="SSIM2")
mlrt_ncnn(network_path="C:/Program Files (x86)/AviSynth+/plugins64+/models/Compact/2x_AnimeJaNai_Standard_V1_Compact_net_g_120000.onnx", builtin=false, fp16=true) # Sharpen
deep_resize(1280,720,edge="SSIM2") #target 1280x720
z_ConvertFormat(pixel_type="yuv420p8", colorspace_op="rgb:709:709:f=>709:709:709:l")

[madey83]

hello kedautinh12,

thank you for your feedback...

Could you please tell me where i can find these "onnx" files because i was able to find only e.g. something like that
https://openmodeldb.info/models/4x-realesrgan-x4plus-anime-6b

is there any special opening method to those models in AVSPmod app?
i have got this:
https://imgur.com/txIHjv9

[madey83]

I tried with DPIR +UniScale CartoonRestore-lite + AnimeJanai and got this result:
https://i.imgur.com/3ynNODU.png

Script:
z_ConvertFormat(pixel_type="rgbps", colorspace_op="709:709:709:l=>rgb:709:709:f")
mlrt_DPIR(model=1, strength=6, tiles=2) # Denoise
mlrt_ncnn(network_path="C:/Program Files (x86)/AviSynth+/plugins64+/models/UniScale/2x_UniScale_CartoonRestore-lite.onnx", builtin=false, fp16=true, tilesize_w=width/4, tilesize_h=height/4) # Restore
propSet("_FieldBased",0)
deep_resize(1280,720,edge="SSIM2")
mlrt_ncnn(network_path="C:/Program Files (x86)/AviSynth+/plugins64+/models/Compact/2x_AnimeJaNai_Standard_V1_Compact_net_g_120000.onnx", builtin=false, fp16=true) # Upscales
deep_resize(1280,720,edge="SSIM2") #target 1280x720
z_ConvertFormat(pixel_type="yuv420p8", colorspace_op="rgb:709:709:f=>709:709:709:l")

this RealESRGAN_x4plus_anime_6B looks cleaner to my eyes...

[kedautinh12]

Choose what you like. For personal, i prefer DPIR +UniScale CartoonRestore-lite + AnimeJanai's result

[madey83]

hello kedautinh12,

thank you for your feedback...

Could you please tell me where i can find these "onnx" files because i was able to find only e.g. something like that
https://openmodeldb.info/models/4x-realesrgan-x4plus-anime-6b

is there any special opening method to those models in AVSPmod app?
i have got this:
https://imgur.com/txIHjv9


could you please advice...

[kedautinh12]

You need .dll filters and models from here:
https://github.com/Asd-g/avs-mlrt/releases
Additional scripts:
https://github.com/Asd-g/avs-mlrt/blob/main/mlrt.avsi

More models you can get from here:
https://github.com/styler00dollar/VSGAN-tensorrt-docker/releases/tag/models

[madey83]

You need .dll filters and models from here:
https://github.com/Asd-g/avs-mlrt/releases
Additional scripts:
https://github.com/Asd-g/avs-mlrt/blob/main/mlrt.avsi

More models you can get from here:
https://github.com/styler00dollar/VSGAN-tensorrt-docker/releases/tag/models

thank you :)

[madey83]

You need .dll filters and models from here:
https://github.com/Asd-g/avs-mlrt/releases
Additional scripts:
https://github.com/Asd-g/avs-mlrt/blob/main/mlrt.avsi

More models you can get from here:
https://github.com/styler00dollar/VSGAN-tensorrt-docker/releases/tag/models

Could you please give another help?

this is my avspmod app call and it crush:

tcFile = "E:\timestamps.txt" # timestamps file path
Exist(tcFile) ? FFVideoSource("E:\source.mkv", cachefile="E:\temp.ffindex", timecodes=tcFile) : FFVideoSource("E:\source.mkv", cachefile="e:\temp.ffindex")

Crop(160, 0, -160, -0)
import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\GradFun3plus.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\ExTools.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\SMDegrain\SMDegrain.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\ResizersPack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\LSFplus.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\SharpenersPack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\GradePack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\ScenesPack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\MasksPack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\Spresso.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\EX mods\DeblockPack.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\TransformsPack - Main.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\TransformsPack - Models.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\TransformsPack - Transfers.avsi")
loadplugin("E:\4k_Encode\BM3DCUDA_AVS-test10-cuda118\x64\BM3DCPU_AVS.dll")
loadplugin("E:\4k_Encode\BM3DCUDA_AVS-test10-cuda118\x64\BM3DCUDA_AVS.dll")
loadplugin("E:\4k_Encode\BM3DCUDA_AVS-test10-cuda118\x64\BM3D_VAggregate_AVS.dll")
loadplugin("E:\4k_encode\dgdecnv_248\DGDecodeNV.dll")
loadplugin("E:\4k_encode\vsTCanny-1.1.8\x64\Release\vsTCanny.dll")
loadplugin("E:\4k_Encode\neo_FFT3D_r11\x64\neo-fft3d.dll")
loadplugin("E:\4k_Encode\fmtconv-r30\win64\fmtconv.dll")
loadplugin("E:\4k_Encode\avs_libplacebo-1.2.0\x64\Release\avs_libplacebo.dll")
loadplugin("E:\4k_Encode\ClipClop_x86_x64_dll_v1-27_20210727\Avisynth+_x64\ClipClop_x64.dll")
loadplugin("E:\4k_Encode\DGHDRtoSDR_1.15\DGHDRtoSDR.dll")
loadplugin("E:\4k_Encode\NNEDI3CL-1.0.8\x64\Release\NNEDI3CL.dll")

loadplugin("E:\4k_Encode\____models\mlrt_ncnn-1.0.1\x64\Release\mlrt_ncnn.dll")
import("E:\4k_Encode\____models\mlrt_ncnn-1.0.1\mlrt.avsi")

z_ConvertFormat(pixel_type="rgbps", colorspace_op="709:709:709:l=>rgb:709:709:f")
mlrt_ncnn(network_path="E:\4k_Encode\____models\RealESRGAN_x4plus_anime_6B.onnx", builtin=false, fp16=true, tilesize_w=width/4, tilesize_h=height/4)
propSet("_FieldBased",0)
deep_resize(1280,720,edge="SSIM2")
z_ConvertFormat(pixel_type="yuv420p8", colorspace_op="rgb:709:709:f=>709:709:709:l")

[madey83]

Could you please give another help?

this is my avspmod app call and it crush:

tcFile = "E:\timestamps.txt" # timestamps file path
Exist(tcFile) ? FFVideoSource("E:\source.mkv", cachefile="E:\temp.ffindex", timecodes=tcFile) : FFVideoSource("E:\source.mkv", cachefile="e:\temp.ffindex")

Crop(160, 0, -160, -0)
import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\GradFun3plus.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\ExTools.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\SMDegrain\SMDegrain.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\ResizersPack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\LSFplus.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\SharpenersPack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\GradePack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\ScenesPack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\MasksPack.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\Spresso.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\EX mods\DeblockPack.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\TransformsPack - Main.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\TransformsPack - Models.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\TransformsPack - Transfers.avsi")
loadplugin("E:\4k_Encode\BM3DCUDA_AVS-test10-cuda118\x64\BM3DCPU_AVS.dll")
loadplugin("E:\4k_Encode\BM3DCUDA_AVS-test10-cuda118\x64\BM3DCUDA_AVS.dll")
loadplugin("E:\4k_Encode\BM3DCUDA_AVS-test10-cuda118\x64\BM3D_VAggregate_AVS.dll")
loadplugin("E:\4k_encode\dgdecnv_248\DGDecodeNV.dll")
loadplugin("E:\4k_encode\vsTCanny-1.1.8\x64\Release\vsTCanny.dll")
loadplugin("E:\4k_Encode\neo_FFT3D_r11\x64\neo-fft3d.dll")
loadplugin("E:\4k_Encode\fmtconv-r30\win64\fmtconv.dll")
loadplugin("E:\4k_Encode\avs_libplacebo-1.2.0\x64\Release\avs_libplacebo.dll")
loadplugin("E:\4k_Encode\ClipClop_x86_x64_dll_v1-27_20210727\Avisynth+_x64\ClipClop_x64.dll")
loadplugin("E:\4k_Encode\DGHDRtoSDR_1.15\DGHDRtoSDR.dll")
loadplugin("E:\4k_Encode\NNEDI3CL-1.0.8\x64\Release\NNEDI3CL.dll")

loadplugin("E:\4k_Encode\____models\mlrt_ncnn-1.0.1\x64\Release\mlrt_ncnn.dll")
import("E:\4k_Encode\____models\mlrt_ncnn-1.0.1\mlrt.avsi")

z_ConvertFormat(pixel_type="rgbps", colorspace_op="709:709:709:l=>rgb:709:709:f")
mlrt_ncnn(network_path="E:\4k_Encode\____models\RealESRGAN_x4plus_anime_6B.onnx", builtin=false, fp16=true, tilesize_w=width/4, tilesize_h=height/4)
propSet("_FieldBased",0)
deep_resize(1280,720,edge="SSIM2")
z_ConvertFormat(pixel_type="yuv420p8", colorspace_op="rgb:709:709:f=>709:709:709:l")

i have fixed...

[madey83]

@kedautinh12

have you got any sugestion what is wrong with below that gives me error?

SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("E:\4k_Encode\models\mlrt_ncnn-1.0.1\x64\Release\mlrt_ncnn.dll")
Import("E:\4k_Encode\models\mlrt.avsi")
import("E:\4k_Encode\models\mlrt_ncnn-1.0.1\mlrt.avsi")
Import("E:\4k_Encode\SSIM_downsample.avsi")

z_ConvertFormat(pixel_type="rgbps", colorspace_op="709:709:709:l=>rgb:709:709:f")
mlrt_ncnn(network_path="C:\Program Files (x86)\AviSynth+\plugins64+\models\RealESRGAN\RealESRGAN_x4plus_anime_6B.onnx", builtin=false, fp16=true, tilesize_w=width/4, tilesize_h=height/4)
propSet("_FieldBased",0)
deep_resize(1440,1080,edge="SSIM2")
z_ConvertFormat(pixel_type="yuv420p8", colorspace_op="rgb:709:709:f=>709:709:709:l")
Prefetch(8,12)

avs+ [INFO]: using external Avisynth library from: "E:\4k_Encode\apps\StaxRip-v2.29.0-x64\Apps\FrameServer\AviSynth\AviSynth.dll"
avs+ [INFO]: AviSynth+ 3.7.3 (r4029, 3.7, x86_64)
[0 NVIDIA GeForce RTX 2060] queueC=2[8] queueG=0[16] queueT=1[2]
[0 NVIDIA GeForce RTX 2060] bugsbn1=0 bugbilz=0 bugcopc=0 bugihfa=0
[0 NVIDIA GeForce RTX 2060] fp16-p/s/a=1/1/1 int8-p/s/a=1/1/1
[0 NVIDIA GeForce RTX 2060] subgroup=32 basic=1 vote=1 ballot=1 shuffle=1
[1 Intel(R) UHD Graphics] queueC=0[1] queueG=0[1] queueT=0[1]
[1 Intel(R) UHD Graphics] bugsbn1=0 bugbilz=0 bugcopc=0 bugihfa=0
[1 Intel(R) UHD Graphics] fp16-p/s/a=1/1/1 int8-p/s/a=1/1/1
[1 Intel(R) UHD Graphics] subgroup=32 basic=1 vote=1 ballot=1 shuffle=1
avs+ [INFO]: 1440x1080 fps 24000/1001 i420p8 frames 0 - 32560 of 32561
raw [INFO]: output file: "E:\_new_out.hevc"
x265 [INFO]: HEVC encoder version 3.5+147+17-e8947f740 [Mod by Patman]
x265 [INFO]: build info [Windows][MSVC 1937][64 bit] 10bit
x265 [INFO]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [INFO]: Main 10 profile, Level-4 (Main tier)
x265 [INFO]: Thread pool created using 12 threads
x265 [INFO]: Slices : 1
x265 [INFO]: frame threads / pool features : 3 / wpp(17 rows)
x265 [INFO]: Coding QT: max CU size, min CU size : 64 / 8
x265 [INFO]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [INFO]: ME / range / subpel / merge : star / 57 / 5 / 5
x265 [INFO]: Keyframe min / max / scenecut / bias : 23 / 250 / 40 / 5.00
x265 [INFO]: Lookahead / bframes / badapt : 80 / 16 / 2
x265 [INFO]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [INFO]: References / ref-limit cu / depth : 3 / on / on
x265 [INFO]: AQ: mode / str / qg-size / cu-tree : 3 / 1.0 / 32 / 1
x265 [INFO]: Rate Control / qCompress : CRF-28.0 / 0.60
x265 [INFO]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=2
x265 [INFO]: tools: rskip-edge-threshold=0.02 signhide tmvp b-intra lslices=6
x265 [INFO]: tools: deblock sao
vkAllocateMemory failed -2
vkWaitForFences failed -4
vkAllocateMemory failed -2
vkAllocateMemory failed -2
avs+ [FLAW]: mlrt_ncnn: inference failed occurred while reading frame 0
vkAllocateMemory failed -2
vkQueueSubmit failed -4vkAllocateMemory failed -2
vkQueueSubmit failed -4
vkAllocateMemory failed -2
vkAllocateMemory failed -2
vkQueueSubmit failed -4
vkQueueSubmit failed -4
vkAllocateMemory failed -2
vkAllocateMemory failed -2
vkAllocateMemory failed -2
vkAllocateMemory failed -2
vkQueueSubmit failed -4
encoded 0 frames

[kedautinh12]

Did you update GPU driver to latest ver??

[madey83]

Did you update GPU driver to latest ver??

my current driver for RTX is 545.84


edit:... updated to 546.29 - latest

[madey83]

i have done test with and without "Prefetch(8,12)"

with staxrip crush, without works but super slow.... CPU utilization is around 4% on each core....


results of the script looks fantastic, but encode with 0,0140 fps is....

[kedautinh12]

Prefetch only affect to CPU, for GPU you need waiting Asd-g port from Vapoursynth ver, it has Cuda and MDL support with better speed
https://github.com/AmusementClub/vs-mlrt/releases/tag/v13.2

[kedautinh12]

For Intel CPU or GPU you can try with mlrt_ov
https://github.com/Asd-g/avs-mlrt/blob/main/README_ov.md

Or try with larger num_streams parameters in mlrt_ncnn

[madey83]

Prefetch only affect to CPU, for GPU you need waiting Asd-g port from Vapoursynth ver, it have Cuda and MDL support with better speed
https://github.com/AmusementClub/vs-mlrt/releases/tag/v13.2

ok. thx for that.

is there any avisynth related solution to clean this video up that i could use....

[Blankmedia]

Animation is typically telecined unless this is a TV capture or something, this is not ideal.
QTGMC+ is mainly designed after live recorded video with more temporal coherence.

Try to add back the old bobber with:
UseEdiExt=1 (or 2 for vinverse filtered), EdiExt=ex_bob(src, 0,0.5,props=1)Thanks it seems to do it

[kedautinh12]

ok. thx for that.

is there any avisynth related solution to clean this video up that i could use....

You can try with mlrt_ov (https://github.com/Asd-g/avs-mlrt/releases), and OpenVINO runtimes (https://github.com/Asd-g/avs-mlrt/blob/main/2022.3.7z) (you need put all .dll in same folder), Model from here (https://github.com/styler00dollar/VSGAN-tensorrt-docker/releases/tag/models)
https://i.imgur.com/STiHnzH.png

Script:
z_ConvertFormat(pixel_type="rgbps", colorspace_op="709:709:709:l=>rgb:709:709:f")
mlrt_ov(network_path="C:/Program Files (x86)/AviSynth+/plugins64+/models/RealESRGAN/RealESRGAN_x2plus_op18.onnx", builtin=false, fp16=true, tilesize_w=width/4, tilesize_h=height/4)
propSet("_FieldBased",0)
deep_resize(1280,720,edge="SSIM2")
z_ConvertFormat(pixel_type="yuv420p8", colorspace_op="rgb:709:709:f=>709:709:709:l")

[madey83]

You can try with mlrt_ov (https://github.com/Asd-g/avs-mlrt/releases), and OpenVINO runtimes (https://github.com/Asd-g/avs-mlrt/blob/main/2022.3.7z) (you need put all .dll in same folder), Model from here (https://github.com/styler00dollar/VSGAN-tensorrt-docker/releases/tag/models)
https://i.imgur.com/STiHnzH.png

Script:
z_ConvertFormat(pixel_type="rgbps", colorspace_op="709:709:709:l=>rgb:709:709:f")
mlrt_ov(network_path="C:/Program Files (x86)/AviSynth+/plugins64+/models/RealESRGAN/RealESRGAN_x2plus_op18.onnx", builtin=false, fp16=true, tilesize_w=width/4, tilesize_h=height/4)
propSet("_FieldBased",0)
deep_resize(1280,720,edge="SSIM2")
z_ConvertFormat(pixel_type="yuv420p8", colorspace_op="rgb:709:709:f=>709:709:709:l")

thank you for that, but is is still very slow. I will try other thinks... :)

[kedautinh12]

I think it's faster than yesterday script

[kedautinh12]

Everything will easy if you upgrade your GPU to high end :D

[madey83]

I think it's faster than yesterday script

yes it is ~1 fps.

many thanks for your all advices..

[kedautinh12]

If you find other thing good can share to me? More learing more development:D

[madey83]

this is how my last call looks like, and it is quite fast on my hardware (arround 10 fps)

ConvertBits(16)
dfttest(sigma=64, tbsize=1, dither=1)
pr=ex_Median(mode="IQMST",thres=255)
pre=ex_blend(pr,"blend",opacity=0.2).ex_sbr(1,UV=3)

SMDegrain(tr=3, thSAD=600, thSCD2 = 100, mode="TemporalSoften", truemotion=false, prefilter=pre, contrasharp=false)

deep_resize(1440,1080,edge="nnedi3",flat="nnedi3",grain=0,qual=2,sspace="sigmoid")

ex_unsharp(0.3,Fc=width()/1.5,safe=true) # Remove some of the dreamy look
ex_unsharp(1.0,Fc=width()*2.0,safe=true) # Extra fine sharpness

neo_f3kdb(range=15, y=65, cb=40, cr=40, grainy=0, grainc=0, sample_mode=4, blur_first=True, dynamic_grain=true, mt=False, keep_tv_range=True,output_depth=16)
ConvertBits(10,dither=1)

but i have still problems with removing some dirt/dots....

[kedautinh12]

You can try spotless for dedots

[madey83]

i have tried this call, but do not see any different:

SpotLess(ThSAD2=1000,RadT=1,Chroma=true,BlkSz=8,OLap=4,Tm=false)

edit: i do not have any expirance with it... i found it yesterday... maybe i'm using it wrongly

[kedautinh12]

Increase RadT, delete Tm parameter

[madey83]

Increase RadT, delete Tm parameter

thx.. looks better. i think this is my final call:

dfttest(sigma=64, tbsize=1, dither=1)
pr=ex_Median(mode="IQMST",thres=255) pre=ex_blend(pr,"blend",opacity=0.2).ex_sbr(1,UV=3)
SMDegrain(tr=3, thSAD=600, thSCD2 = 100, mode="TemporalSoften", truemotion=false, prefilter=pre, contrasharp=false)

SpotLess(ThSAD2=1000,RadT=2,Chroma=true,BlkSz=8,OLap=4) # i think it is a good place to call it....

deep_resize(1440,1080,edge="nnedi3",flat="nnedi3",grain=0,qual=2,sspace="sigmoid",gpuid=0)
ex_unsharp(0.3,Fc=width()/1.5,safe=true) # Remove some of the dreamy look
ex_unsharp(0.15).ex_unsharp(0.15, Fc=width()/1.5)

neo_f3kdb(range=15, y=65, cb=40, cr=40, grainy=0, grainc=0, sample_mode=4, blur_first=True, dynamic_grain=true, mt=False, keep_tv_range=True,output_depth=16)
ConvertBits(10,dither=1)

[kedautinh12]

try replace neo_f3kdb with
convertbits(16)
GradFun3plus(thr=0.25, radius=10, mask=2, smode=0,UV=3)

Or
convertbits(16)
GradFun3plus(thr=0.5, radius=20, mask=2, smode=0,UV=3)

[madey83]

try replace neo_f3kdb with
convertbits(16)
GradFun3plus(thr=0.25, radius=10, mask=2, smode=0,UV=3)

Or
convertbits(16)
GradFun3plus(thr=0.5, radius=20, mask=2, smode=0,UV=3)


to my eyes i do not really see any differents between GradFun3plus and neo_f3kdb


Do you see any other improvments for script?

[kedautinh12]

Just short clip, i don't see different very much, maybe good for full clip of your where the part i don't have. For my test with other clip, gradfun3plus is better

[madey83]

Just short clip, i don't see different very much, maybe good for full clip of your where the part i don't have. For my test with other clip, gradfun3plus is better

i have sent you PM with the link

[flossy_cake]

hello,

can i ask for help with clearing out this clip:
https://mega.nz/file/sZZh2bpI#zK7jGmvE7xAM7gxR2YyN4oAfLTPVTpqB6eIUaHFhupk

thank you in advance for any help :)

Can you please reupload the clip as the link is broken

[flossy_cake]

yes it is ~1 fps.

If you want like 70fps this is what I'm using for realtime playback of 480p animation on HTPC


# Assuming 480p input clip #

# temporal antialiasing, denoising & stabilisation (without NNEDI3 interpolation)
QTGMC(InputType=1, TR2=3, preset="slow", EdiThreads=4, Sharpness=0.0, Rep0=13).Prefetch(6)

# line thinning - increase first param by 5.0 at a time for thinner lines
aWarpSharp(15.0, blurlevel=1).Prefetch(1)

# sharpening
CAS(sharpness=0.75, y=3, u=2, v=2, opt=-1).Prefetch(1)

# upscale 480p -> 1080p
Spline36Resize(1440, 1080).Prefetch(1)



Animated png:

https://c.l3n.co/i/shwfrq.png

Individual images: 1 (https://c.l3n.co/i/shwUNM.png), 2 (https://b.l3n.co/i/shwXiQ.png)

[kedautinh12]

Can you please reupload the clip as the link is broken

here:
https://drive.google.com/file/d/1AFDgPTFn9APHyhfcrYTPpCR4KgRPSBgv/view?usp=drive_link

[flossy_cake]

here:
https://drive.google.com/file/d/1AFDgPTFn9APHyhfcrYTPpCR4KgRPSBgv/view?usp=drive_link

Cheers.

Well, I don't know how much smoothing madey83 wants...


# Temporal smoothing + sharpening (increase EZDenoise to eg. 4.0 if you want more denoising)
QTGMC(InputType=1, TR2=3, EZDenoise=0.0, Sharpness=2.0, preset="slow", EdiThreads=4, Rep0=13).Prefetch(6)

# Line thinning
aWarpSharp(15.0, blurlevel=1).Prefetch(1)

# Upscale to 1080p
Spline36Resize(1920, 1080).Prefetch(1)


Getting 30fps @ 3.2Ghz x 4 cores.

Animated PNG's:

https://b.l3n.co/i/38RcJe.png

https://c.l3n.co/i/38Rbxx.png

With EZDenoise=4.0:

https://c.l3n.co/i/38TE8b.png

https://a.l3n.co/i/38TkQ7.png

[Selur]

Using DPIR for denoising might be another option.
https://imgsli.com/MjI2MTk2
https://imgsli.com/MjI2MTk3
(oh, overlooked the speed requirement)

For fast filtering: FFT3DGPU + FastLineDarkening
ClearAutoloadDirs()
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
LoadPlugin("F:\Hybrid\64bit\Avisynth\avisynthPlugins\LoadDll.dll")
LoadDLL("F:\Hybrid\64bit\Avisynth\avisynthPlugins\d3d9.dll")
LoadPlugin("F:\Hybrid\64bit\Avisynth\avisynthPlugins\LSMASHSource.dll")
LoadPlugin("F:\Hybrid\64bit\Avisynth\avisynthPlugins\FFT3dGPU.dll")
LoadPlugin("F:\Hybrid\64bit\Avisynth\avisynthPlugins\masktools2.dll")
LoadPlugin("F:\Hybrid\64bit\Avisynth\avisynthPlugins\RgTools.dll")
Import("F:\Hybrid\64bit\Avisynth\avisynthPlugins\mtmodes.avsi")
Import("F:\Hybrid\64bit\Avisynth\avisynthPlugins\Zs_RF_Shared.avsi")
Import("F:\Hybrid\64bit\Avisynth\avisynthPlugins\FastLineDarkenMod.avs")
# loading source: C:\Users\Selur\Desktop\_new.mkv
# color sampling YV12@8, matrix: bt709, scantyp: progressive, luminance scale: limited
LWLibavVideoSource("C:\Users\Selur\Desktop\_new.mkv",cache=false,format="YUV420P8", prefer_hw=0,repeat=true)
# current resolution: 1280x720
# cropping
Crop(160,0,-160,0)# 960x720
FFT3DGPU(sigma=6.00,ow=16,oh=16,mode=1,precision=0)
FastLineDarkenMOD4(prot=5)
# Converting from 8 to 10bit for encoder
ConvertBits(10)
# setting output fps to 23.976fps
AssumeFPS(24000,1001)
PreFetch(16)
# output: color sampling YV12@10, matrix: bt709, scantyp: progressive, luminance scale: limited
return last


Cu Selur

[kedautinh12]

Using DPIR for denoising might be another option.
https://imgsli.com/MjI2MTk2
https://imgsli.com/MjI2MTk3
(oh, overlooked the speed requirement)

Cu Selur

I used to it
https://forum.doom9.org/showthread.php?p=1994706#post1994706

Cu Kedautinh12 :D

[madey83]

hello,

Thank you all for involvment to guide me.

this is my last call which gives me ~10 fps of speed (Core(TM) i7-10750H)
I will not put any screen due to fact everyone who has source file can see out come of below script.

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetMemoryMax()
ConvertBits(16)
dfttest(sigma=64, tbsize=1, dither=1)
pr=ex_Median(mode="IQMST",thres=255)
pre=ex_blend(pr,"blend",opacity=0.2).ex_sbr(1,UV=3)
SMDegrain(tr=3, thSAD=1000, thSCD2 = 100, mode="TemporalSoften", truemotion=false, prefilter=pre, contrasharp=false)

deep_resize(1440,1080,edge="nnedi3",flat="nnedi3",grain=0,qual=2,sspace="sigmoid",gpuid=-1)
ex_unsharp(0.85).ex_unsharp(0.15, Fc=width()/1.5,safe=true)
GradFun3plus(thr=1.5, radius=10, mask=2, smode=0,UV=3)
ConvertBits(10,dither=1)
Prefetch(10,12)

[madey83]

Using DPIR for denoising might be another option.
https://imgsli.com/MjI2MTk2
https://imgsli.com/MjI2MTk3
(oh, overlooked the speed requirement)

For fast filtering: FFT3DGPU + FastLineDarkening
ClearAutoloadDirs()
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
LoadPlugin("F:\Hybrid\64bit\Avisynth\avisynthPlugins\LoadDll.dll")
LoadDLL("F:\Hybrid\64bit\Avisynth\avisynthPlugins\d3d9.dll")
LoadPlugin("F:\Hybrid\64bit\Avisynth\avisynthPlugins\LSMASHSource.dll")
LoadPlugin("F:\Hybrid\64bit\Avisynth\avisynthPlugins\FFT3dGPU.dll")
LoadPlugin("F:\Hybrid\64bit\Avisynth\avisynthPlugins\masktools2.dll")
LoadPlugin("F:\Hybrid\64bit\Avisynth\avisynthPlugins\RgTools.dll")
Import("F:\Hybrid\64bit\Avisynth\avisynthPlugins\mtmodes.avsi")
Import("F:\Hybrid\64bit\Avisynth\avisynthPlugins\Zs_RF_Shared.avsi")
Import("F:\Hybrid\64bit\Avisynth\avisynthPlugins\FastLineDarkenMod.avs")
# loading source: C:\Users\Selur\Desktop\_new.mkv
# color sampling YV12@8, matrix: bt709, scantyp: progressive, luminance scale: limited
LWLibavVideoSource("C:\Users\Selur\Desktop\_new.mkv",cache=false,format="YUV420P8", prefer_hw=0,repeat=true)
# current resolution: 1280x720
# cropping
Crop(160,0,-160,0)# 960x720
FFT3DGPU(sigma=6.00,ow=16,oh=16,mode=1,precision=0)
FastLineDarkenMOD4(prot=5)
# Converting from 8 to 10bit for encoder
ConvertBits(10)
# setting output fps to 23.976fps
AssumeFPS(24000,1001)
PreFetch(16)
# output: color sampling YV12@10, matrix: bt709, scantyp: progressive, luminance scale: limited
return last


Cu Selur

tomorrow i will test your script :) thank you...

[madey83]

Cheers.

Well, I don't know how much smoothing madey83 wants...


# Temporal smoothing + sharpening (increase EZDenoise to eg. 4.0 if you want more denoising)
QTGMC(InputType=1, TR2=3, EZDenoise=0.0, Sharpness=2.0, preset="slow", EdiThreads=4, Rep0=13).Prefetch(6)

# Line thinning
aWarpSharp(15.0, blurlevel=1).Prefetch(1)

# Upscale to 1080p
Spline36Resize(1920, 1080).Prefetch(1)


Getting 30fps @ 3.2Ghz x 4 cores.

Animated PNG's:

https://b.l3n.co/i/38RcJe.png

https://c.l3n.co/i/38Rbxx.png

With EZDenoise=4.0:

https://c.l3n.co/i/38TE8b.png

https://a.l3n.co/i/38TkQ7.png


hi flossy_cake

to weak clean up to my taste, but thank you for your proposision.... :)

[junah]

QTGMC+ doesnt support EdiThreads anymore? Went from old 3.382s to v4.5p and without EdiThreads encoding speed dropped around 50%

[Sharc]

SMDegrain(interlaced=true) throws an error:
There is no function named 'bicubic_coeffs'

I have the latest ResizersPack.avsi in the plugins64 folder, and updated dependencies etc.

Any idea what's missing?

[Dogway]

QTGMC+ doesnt support EdiThreads anymore? Went from old 3.382s to v4.5p and without EdiThreads encoding speed dropped around 50%

Edithreads was only meant for EEDI filter, now it's called "threads" and I think it's set to 8 by default, play with it and also with Prefetch values depending on your number of cores/threads.


@Sharc: I will have a look. I have prepared a few (small) updates/bugfixes for the weekend.
EDIT: I now checked, interlaced=true defaults to subpixel=4 (nnedi3) which uses ResizersPack's nnedi3wrap() which itself uses bicubic_coeffs from TransformsPack - Main. I think bicubic_coeffs() is better placed in ResizersPack so I will move it there, but I just noticed that you still need TransformsPack for ConvertFormat(), so yes, that's a dependency.

[Sharc]

@Sharc: I will have a look. I have prepared a few (small) updates/bugfixes for the weekend.
EDIT: I now checked, interlaced=true defaults to subpixel=4 (nnedi3) which uses ResizersPack's nnedi3wrap() which itself uses bicubic_coeffs from TransformsPack - Main. I think bicubic_coeffs() is better placed in ResizersPack so I will move it there, but I just noticed that you still need TransformsPack for ConvertFormat(), so yes, that's a dependency.
OK. This helped. Got it working now. Thank you.

[DQWJ]

Hello, Dogway! Thank you for sharing, it's really great!
I am not good at English and used translation software to write it. I hope you can understand and get your help
I switched from the old AviSynth 2.60 to AviSynth+64. The system is WIN10 x64, CPU-i7-9700kf, 8-core 8-thread, graphics card 1660ti, Avisynth+3.7.3post test 10 (20231202- r4035) x64, MeGUI-2944_ X64, installed with VisualCppRedist_ AIO_ X86_ X64.exe, AvsPmod is also the latest version, and your script and related filters are all the latest version. AvsPmod has no problem browsing, but it stops working after about 1 hour of coding or when coding is almost complete (more threads open, faster crashes seem to be like this). I don't know if AVS stops working or MeGUI stops working. After testing for over 2 months, I couldn't find the reason and solution. Is there still something missing that hasn't been installed?

Script:

Import ("C: \ Program Files (x86) \ AviSynth+\ plugins64+\ real. finder tests \ IMPORTALL.avsi")
LoadPlugin ("G: \ SOFTWARE \ DGDecode&DGDecNV \ dgdecnv_250_x64 \ DGDecodeNV. DLL")
DGSource ("VTS-01_1. dgi", fieldop=0)
ConvertBits (Bits=16, dither=-1)
QTGMCp (Preset="Lower", FPSDivisor=2, ShutterBlur=0, Border=false, TR2=1, Sharpness=1.00, moire=false, NoisePreset="Lower", Show=false, Threads=4)
Trim (0, 80000)
Prefetch (1, 16)

PropSet ("FieldBased", 0)
SMDegrain (tr=5, thSAD=500, thSADC=226, RefineMotion=true, contrast=true, mode="MDegrain", pel=2, subpixel=4, prefilter=8, LFR=false, DCTFlicker=false, true motion=true, gpuid=0)
Prefetch (1, 12)

Ex_ Unsharp (str=0.07, Fc=width()/1.5, safe=true)
PropSet ("FieldBased", 0)
Deep_ Resize (1440, 1080, grain=0.0)
ConvertToStacked()
F3kdb (8,40,32,32,0,0, input_mode=1, output_mode=1). f3kdb (16,32,24,24,0,0, input_mode=1, output_mode=1)
ConvertFromStacked()
Ex_ Unsharp (str=0.20, Fc=width()/1.5, safe=true)
Ex_ Unsharp (str=1.0, Fc=width() * 2.0, safe=true)
FilmGrainPlus (preset="FilmGrain", show=0)
ConvertBits (Bits=10, dither=0)
Prefetch (1, 8)


The thread is very low, but it still stops working. The MeGUI log mentions a thread error (it seems like this, I'm not sure), and I can't find the reason. I'm going crazy. I originally wanted to switch back to the old AviSynth2.60 (very stable), but it's your excellent script that keeps me going. I really hope to get your help, thank you!!!

For example, using simple ones won't stop working
LWLibavVideoSource ("000. mkv", threads=4)
Spline36Resize (1280, 720)

[DTL]

QTGMC and SMDegrain uses mvtools and this and other plugins may try to use internal MT via AVSTP (as auto mode if not directly disabled). Do you use fixed version of avstp.dll from pinterf ? Old versions may cause deadlock freeze after some time of running. You need to delete all possible old versions of avstp.dll from any possible PATH at the machine to be sure it can not be loaded by auto-search of some path and use only new fixed file.

[Dogway]

@DQWJ: QTGMCp + SMDegrain seems too much, and I can't recall now if your FilmGrainPlus call is doing something temporal too. I try to separate heavy temporal filters in different scripts. Other than that set SetMemoryMax(2048*4) or so. Finally I think you might need to play with Prefetch(), safe values are 4, 6 and 8, and for cache maybe 4 or 8.

[DQWJ]

QTGMC and SMDegrain uses mvtools and this and other plugins may try to use internal MT via AVSTP (as auto mode if not directly disabled). Do you use fixed version of avstp.dll from pinterf ? Old versions may cause deadlock freeze after some time of running. You need to delete all possible old versions of avstp.dll from any possible PATH at the machine to be sure it can not be loaded by auto-search of some path and use only new fixed file.

Thank you very much for your answer. I feel that this is very likely the reason, but I am not sure what to do specifically. My understanding of English is weak, please forgive me. Can you be a little more detailed
I do have an old avstp.DLL in my plugins64+(version unknown, modified on October 7th, 2020), and now I have downloaded the latest avstp-1.0.4.1 from Pinterf


1. How to disable MT, do I need to disable it?

2. Delete the old version of avstp.DLL, do you still need to install the new version of avstp-1.0.4.1?

3. I only use it on a daily basis
MP_ Pipeline
SetMemoryMax (2048 * 10)
SetFilterMTMode ("DEFAULTMT-MODE", 2)
Prefetch (4,4)
Do you need avstp for these functions? If not, I will delete them directly

[kedautinh12]

Yes, try encode with pinterf's avstp.dll

[DQWJ]

@DQWJ: QTGMCp + SMDegrain seems too much, and I can't recall now if your FilmGrainPlus call is doing something temporal too. I try to separate heavy temporal filters in different scripts. Other than that set SetMemoryMax(2048*4) or so. Finally I think you might need to play with Prefetch(), safe values are 4, 6 and 8, and for cache maybe 4 or 8.

This script mainly involves zooming in 1080P and adding particles after 480P processing is clean. I don't know English and my level is very low, so I only know how to do this. Can you help me write a DVD processing and zooming in 1080P script (live action stage drama, MV type), which requires the screen to be clean and as clear as possible? Thank you

SetMemoryMax (2048 * 4) and Prefetch() have been tested countless times, and the higher the thread setting, the easier it is to stop working. I also suspect that NNEDI3CL.DLL caused the stop working. Let me briefly describe my feeling from multiple tests:
Your script is fantastic. It runs much faster in AvsPmod than the old x32 bit and performs very well, especially in SMDegrain. It's great, but the encoding speed is not as fast as using the old AviSynth 2.60. It's unclear if using GPU has taken up too much CPU resources, resulting in less available CUP for encoding.
The script I used when using the old AviSynth 2.60 actually had more and slower functions (not as effective or streamlined as yours), but the encoding was faster. The old script is as follows:

MP_ Pipeline“
SetMemoryMax (3000)
LoadPlugin ("G: \ SOFTWARE \ dgmpgdec-158&dgindexnv_2051 \ dgindexnv \ DGDecodeNV. DLL")
DGSource ("VTS-01_1. dgi")
QTGMC (Preset="slow", FPSDivisor=2, ShutterBlur=2, Border=true, TR2=1, Sharpness=1.0)
U16()
SMDegrain (tr=3, thSAD=300, RefineMotion=true, contrastharp=true, pel=2, subpixel=3, prefilter=-1, truemotion=true, lsb1in=true, lsb1out=true, mode=6)
Src16=last

###Export clip: srcA
###Prefetch: 48,32
### ###

SetMemoryMax (3200)
F3kdb (8,64,48,48,0,0, input_mode=1, output_mode=1) Dither_ Limit_ Dif16 (src16, Thr=0.35, Elast=3.0). f3kdb (16,48,32,32,0,0, input_mode=1, output_mode=1) Dither_ Limit_ Dif16 (src16, Thr=0.30, Elast=3.0)
CSmod16 (lsd_in=true, lsb=true, edgemode=0, length=30, dither=6)
Nnedi3_ Resize16 (1440, 1080, lsd_in=true, lsb=true, sharp=80, dither=6)

###Export clip: srcB
###Prefetch: 26,18
### ###

SetMemoryMax (3200)

、、、、、、、、、、、、

###Export clip: srcC
###Prefetch: 16,8
### ###

SetMemoryMax (3200)
、、、、、、、、、、、、、

")

This script runs slowly in AvsPmod and has a lower CUP usage, but the memory resource allocation is relatively high (32GB of memory, about 20GB of memory occupied during encoding, and can also play League of Legends games while encoding, which is stable). The encoding speed is also faster. I don't know how to improve the speed of encoding in the new X64 yet

I have also tested your GradFun3plus and it seems to be not working. I don't know where the settings are wrong

[DTL]

1. How to disable MT, do I need to disable it?
2. Delete the old version of avstp.DLL, do you still need to install the new version of avstp-1.0.4.1?
3. I only use it on a daily basis


If you want to test disabling internal intra-frame MT in mvtools you need to set mt=false for each mvtools filter call used in all your scripts (or look in the script functions arguments if the script author make it external param to use as global MT switch). Or delete all avstp.dll files from machine (may archive to some format with different name).

You can test with your scripts and your machine (hardware) what modes of MT are most fast and stable. Some plugins may use internal intra-frame MT like mvtools via AVSTP plugin and AVS environment may use inter-frame MT (AVS+ core feature). So for complex processing there are lots of possible combinations of MT modes (and threads count) to make a different balance of performance and RAM usage and also some combinations may be less stable.

For best protection from the old version of avstp.dll freeze issue you need to delete all old files of avstp.dll from any path of the machine and replace with new fixed version from pinterf.

3. These are internal AVS functions and do not use AVSTP external plugin. So you can completely delete avstp.dll files from all locations to check if it causes some freezing sometime.

"Do you still need to install the new version of avstp-1.0.4.1?"

If your tests shows you get good benefit in performance and lower RAM usage if you enable intra-frame MT via AVSTP in (some of) used plugins - you need to install fixed avstp.dll file (to each plugin or in some global visible PATH or maybe to some auto-load location and so on).

"I do have an old avstp.DLL in my plugins64+(version unknown, modified on October 7th, 2020)"

You need to use version of Jan 23, 2023 ver 1.0.4.1 or later for all filters. You can try to check version of the avstp.dll in the file properties in the windows file explorer. For build by pinterf it displays file version and product version of 1.0.4.1 .

[Dogway]

@DQWJ: Unless you are in a potato CPU which I don't think so given the thread count and RAM, the new SMDegrain should be about same speed. Now you are comparing an MP_Pipeline() workflow which one that isn't. Maybe try to implement MP_Pipeline() with the new scripts? Specially useful when moving SMDegrain to a different MP_Pipeline() thread than QTGMCp

New scripts/functions might be a bit slower than older ones but not by much. They are doing things more correct, dealing with frameprops, or doing more/better prefiltering.

Post the GradFun3plus call you use without other filters.

[Boulder]

Why not try the original script and with just one Prefetch call at the end? There's a ton of filters there and things can get very flaky very fast. I'd also try replacing QTGMCp with real.finder's STGMC, I've never been able to make QTGMCp work properly with multithreading (probably an Avisynth cache issue more or less).

[DQWJ]

@Dogway: Sorry, I tested GradFun3plus again today and it worked fine. Maybe it was during 8-bit testing that it didn't work before? What is the difference between the EX version and the MIX version? I am adjusting the thSAD=700 and thSADC=400 parameters of SMDegrain, but there seems to be no change and I cannot see any difference from the default settings.

I don't think your script is slow, on the contrary, I think it's faster than the one I used before. But the encoding is slow, maybe it's because your script is too fast and occupies too much CUP, which leads to the encoding being slow, or maybe it's because I didn't allocate CUP and RAM properly myself



@Boulder: My situation is a bit similar to yours. I don't think it's due to QTGMCp, because I have also tested the very old QTGMC-3.33 on AVS+X64 and it stopped working. I think it may be an issue with avstp or Avisynth+64. When checking the task manager during coding, you will find that the encoder and AVS occupy about 10GB each, and the memory occupied by AVS will gradually increase. I haven't tested the new version of AVSTP yet, I've been testing other versions. After testing, I will release the test results


笔记

[Blankmedia]

Hi,

When I use

ClearAutoloadDirs()
AddAutoloadDir("D:\A encoder\01 - PARTIE 1\plugins2")
AddAutoloadDir("D:\A encoder\01 - PARTIE 1\plugins2\SMDegrain")
SetMemoryMax(8192*3)
MODIFIE= "PARTIE1_SAUT_DESHAKE.avi"
FFVideoSource(MODIFIE)
fmtc_bitdepth(bits=16, dmode=1, fulls=True, fulld=false)
ConvertToYUV420()
SceneStats("Range+Stats",path="PARTIE1_SAUT_DESHAKE2.avi.log")
Prefetch(1)


In a first pass script with "ffmpeg -i saut_v1.avs -f null -" I get :

Type string
0: Range: 0, 10 Stats: 29297.972656, 55768.945312, 33409.968750, 51142.953125, 48965.523438, 49857.953125, 48965.523438
1: Range: 0, 10 Stats: 29297.972656, 55768.945312, 33409.968750, 51142.953125, 48965.523438, 49857.953125, 48965.523438
2: Range: 0, 10 Stats: 26984.974609, 56282.945312, 31096.970703, 50628.953125, 45876.910156, 48315.953125, 45876.910156
3: Range: 0, 10 Stats: 26984.974609, 56282.945312, 31096.970703, 50628.953125, 45876.910156, 48315.953125, 45876.910156
4: Range: 0, 10 Stats: 26984.974609, 56282.945312, 31096.970703, 50628.953125, 45876.910156, 48315.953125, 45876.910156
5: Range: 0, 10 Stats: 26984.974609, 56282.945312, 31096.970703, 50628.953125, 45876.910156, 48315.953125, 45876.910156
6: Range: 0, 10 Stats: 26984.974609, 56282.945312, 31096.970703, 50628.953125, 45876.910156, 48315.953125, 45876.910156
7: Range: 0, 10 Stats: 26984.974609, 56282.945312, 31096.970703, 50628.953125, 45876.910156, 48315.953125, 45876.910156
8: Range: 0, 10 Stats: 26984.974609, 56282.945312, 31096.970703, 50628.953125, 45876.910156, 48315.953125, 45876.910156
9: Range: 0, 10 Stats: 26984.974609, 56282.945312, 31096.970703, 50628.953125, 45876.910156, 48315.953125, 45876.910156
10: Range: 0, 10 Stats: 26984.974609, 56282.945312, 31096.970703, 50628.953125, 45876.910156, 48315.953125, 45876.910156
11: Range: 11, 20 Stats: 26213.974609, 55511.945312, 29554.972656, 50371.953125, 44670.183594, 47287.953125, 44670.183594
12: Range: 11, 20 Stats: 26213.974609, 55511.945312, 29554.972656, 50371.953125, 44670.183594, 47287.953125, 44670.183594
13: Range: 11, 20 Stats: 26213.974609, 55511.945312, 29554.972656, 50371.953125, 44670.183594, 47287.953125, 44670.183594
14: Range: 11, 20 Stats: 26213.974609, 55511.945312, 29554.972656, 50371.953125, 44670.183594, 47287.953125, 44670.18359

On my second pass with :

ReadStats("PARTIE1_SAUT_DESHAKE2.avi.log")
ex_autolevels()

Overlayed on the video i have this error message:
Expr: Failes to convert '-nan(ind) to float
[...]gradepack.avsi, line 369
[...]gradepack.avsi, line 479

Or if I try second pass with :

ClipStats("PARTIE1_SAUT_DESHAKE2.avi.log")
ex_autolevels()

I get this error message:
ex_autolevels: '_SceneRange' frame properties are required
[...]gradepack.avsi, line 446
[...]saut_v1.avs, line 15

Am I doing something wrong?

[Dogway]

@Blankmedia: I'll have a look at the first issue, I don't see any nand there though
For the second one you should input the results of clipstats in 8-bit into ex_levels manually
Then ex_levels won't try to read scene ranges

[Fjord]

LSFplus v6.0 ex references ex_CAS() on lines 767-770. ex_CAS() existed in SharpenersPack until it was renamed to CASP() in SharpenersPack v4.0 (mix).

LSFplus v6.0 mix references CAS() in the same places (lines 763-766), but CAS() does not appear to be defined anywhere.

Shouldn't these references to ex_CAS() and CAS() in LSFplus be replaced with calls to CASP() from the current SharpenersPack v5.1? Or do ex_CAS() and CAS() exist in some other plugin or script that I need to import?

[rgr]

What else am I missing to try QTGMC+? I updated nnedi3.dll to 0.9.6.43, but I still have this message.


[avisynth @ 000001f3668c01c0] Script error: nnedi3wrap does not have a named argument "dh"
(C:/Program Files (x86)/AviSynth+/plugins64+/QTGMC+.avsi, line 1171)
(C:/Program Files (x86)/AviSynth+/plugins64+/QTGMC+.avsi, line 965)

[Boulder]

What else am I missing to try QTGMC+? I updated nnedi3.dll to 0.9.6.43, but I still have this message.


[avisynth @ 000001f3668c01c0] Script error: nnedi3wrap does not have a named argument "dh"
(C:/Program Files (x86)/AviSynth+/plugins64+/QTGMC+.avsi, line 1171)
(C:/Program Files (x86)/AviSynth+/plugins64+/QTGMC+.avsi, line 965)

There are possible fixes in this GitHub issue: https://github.com/Dogway/Avisynth-Scripts/issues/69

[rgr]

Explained.
Somehow I downloaded QTGMC+ today and an older version was downloaded.

[Dogway]

LSFplus v6.0 ex references ex_CAS() on lines 767-770. ex_CAS() existed in SharpenersPack until it was renamed to CASP() in SharpenersPack v4.0 (mix).

LSFplus v6.0 mix references CAS() in the same places (lines 763-766), but CAS() does not appear to be defined anywhere.

Shouldn't these references to ex_CAS() and CAS() in LSFplus be replaced with calls to CASP() from the current SharpenersPack v5.1? Or do ex_CAS() and CAS() exist in some other plugin or script that I need to import?

Thanks, fixed now, uploading. Indeed I forgot to update the call to CASP(). As for LSFPlus Mix, CAS is a plugin, now I added a version to imply it's an external dependency.

I uploaded also some of the updates for the last few months. Mainly ResizersPack, adding the 'sc' (SceneChange) argument so I can disable it in FillMissing stand alone function, to force RIFE to interpolate even if it's a big change.
TransformPack also saw some more additions, like TM_Daniele() tonemapper which I dig in, S-Log2, and in Main a few more gamuts.

Explained.
Somehow I downloaded QTGMC+ today and an older version was downloaded.

Yes, I was going to suggest to update. I guess it works now.

[Guest]

@Dogway,

FYI,

I was just checking out the updates you've recently done, and in the Ex & Mix mods, LSFplus has some mismatched, erroneous details & dates.

[Dogway]

@Dogway,

FYI,

I was just checking out the updates you've recently done, and in the Ex & Mix mods, LSFplus has some mismatched, erroneous details & dates.

Thanks, fixed now.

[Guest]

Thanks, fixed now.

You're welcome, and thanks for the updates, it's been a "minute".

[kedautinh12]

ExTools and Stabilization Tools Pack still outdate in the info

[madey83]

hello,

i have silly question: Which prefilter from these below is weaker:

2 = strong median/gauss blur
3 = very strong median/gauss blur (IQMV -Variable Inter Quartile Median- filter)
4 = spatio-temporal median/gauss filter (IQMST)

and in what sources type would be better to use one from these?

[simple_simon]

@Dogway, would you consider incorporating a grain function in Gradfun3plus that is similiar to the one in Gradfun2dbmod that only adds grain to areas of that frame that have been debanded?

I'm trying to deband some digital animation footage but the debanding doesn't survive encoding with x264 even at crf=18. I've tried using your Filmgrainplus after Gradfun3plus but that gives the whole image a grainy look that I don't want with digital animation. I just need enough grain in the debanded areas to prevent the encoder from reintroducing the banding.

[rgr]

Yes, I was going to suggest to update. I guess it works now.

But I had just downloaded QTGMC+ for the first time an hour earlier. I don't know why I downloaded the version "QTGMC 3.89 + mod by Dogway 2022, based on 3.382s". It will remain a secret.

At 10 bit depth it looks 20% faster. Great job :)

[rgr]

I uploaded also some of the updates for the last few months. Mainly ResizersPack, adding the 'sc' (SceneChange) argument so I can disable it in FillMissing stand alone function, to force RIFE to interpolate even if it's a big change.

I just downloaded FillMissing (version with " Add 'sc=false' to RIFEwrap to force MI by Dogway on Feb 18, 2024")

and I get:

Avisynth open failure: Script error: RIFEwrap does not have a named argument "sc" (C:/Program Files (x86)/AviSynth+/plugins64+/FillMissing.aysi, line 50)

Edit: ResizersPack I also downloaded the old version. But after updating I get:
Avisynth open failure: Script error RIFEwrap does not have a named argument "gpu_id" (C:/Program Files (x86)/AviSynth+/plugins64+/FillMissing.aysi, line 50)

Edit 2:After correcting the typo on line 50 (gpu_id -> gpuid)
"Avisynth open failure: RIFE: gpu_thread must be between 1 and 2 (inclusive) (C:/Program Files (x86)/AviSynth+/plugins64+/ResizersPack.aysi, line 667) (C:/Program Files (x86)/AviSynth+/plugins64+/FillMissing.aysi, line 50) "

On line 667, gpu_thread can take the values 2 or 4. Do I have a different version of RIFE?

[kedautinh12]

Did you update ResizerPack?
https://github.com/Dogway/Avisynth-Scripts/blob/master/ResizersPack.avsi

You need update all dependencies of fill missing to latest version
https://github.com/Dogway/Avisynth-Scripts/blob/7b5e37d4344e9221e5c8c7a793bfbd14fe32db61/EX%20mods/FillMissing.avsi#L17

[kedautinh12]

I just downloaded FillMissing (version with " Add 'sc=false' to RIFEwrap to force MI by Dogway on Feb 18, 2024")

and I get:

Avisynth open failure: Script error: RIFEwrap does not have a named argument "sc" (C:/Program Files (x86)/AviSynth+/plugins64+/FillMissing.aysi, line 50)

Edit: ResizersPack I also downloaded the old version. But after updating I get:
Avisynth open failure: Script error RIFEwrap does not have a named argument "gpu_id" (C:/Program Files (x86)/AviSynth+/plugins64+/FillMissing.aysi, line 50)

Edit 2:After correcting the typo on line 50 (gpu_id -> gpuid)
"Avisynth open failure: RIFE: gpu_thread must be between 1 and 2 (inclusive) (C:/Program Files (x86)/AviSynth+/plugins64+/ResizersPack.aysi, line 667) (C:/Program Files (x86)/AviSynth+/plugins64+/FillMissing.aysi, line 50) "

On line 667, gpu_thread can take the values 2 or 4. Do I have a different version of RIFE?

I think you need waiting for Dogway to fix it:D

[kedautinh12]

I got this error when tried SMDerain's latest ver:
My script:
LWLibavVideoSource("C:\Users\ADMIN\Downloads\LR_11.avi")
SMDegrain(6, 400, prefilter=6, ContraSharp=true, RefineMotion=true, plane=4, limits=false, DCTFlicker=false, gpuid=1)
https://i.imgur.com/BTRB6aF.png

Sample (https://u.pcloud.link/publink/show?code=XZyY2J0ZboiSEPCdj0B9cry9SdfE04fr2Ovy)

[StainlessS]

@K,
AVI Codec is "LAGS", Lagarith.
LWLibavVideoSource loads as RGBP (Planar RGB 8bit), try convert to YV12. (KNLMeansCL seems to require YUV).
I cant test, my setup KNLMeansCL requires BM3D_CUDA which I dont have. I seem to also have old version SMDegrain.

EDIT: My ver$ Smdegrain call to KnlMeansCL uses,

nlckl = Eval(" nlc.KNLMeansCL(D=d, A=a, h=h, s=s, device_type=device_type, device_id=deviceid, rclip=nlrc, wmode=wmode, wref=wref, channels=UV" + knlm_params + ")")

which I presume produces the KnlMeansCL "Must Use 'RGB' with RGB colorspace", error.

[tormento]

@Dogway

Just remembering you to look at the new DGDenoise :)

The syntax changed so the script is now broken.

[tormento]

I can sort out what do OPP and UV (and its values) in:

ex_BM3D(clip a, float "sigma", int "radius", string "preset", bool "OPP", int "UV", bool "tv_range", int "gpuid")

Any idea? I have tried to look at the avsi but can't understand the conditions.

And why do

ex_BM3D(preset="Light") or ex_BM3D(preset="light")

or

ex_BM3D(preset="Normal") or ex_BM3D(preset="normal")

sometimes spit out "Wrong preset" error?

[kedautinh12]

You need take a look at Dogway's script
https://github.com/Dogway/Avisynth-Scripts/blob/7b5e37d4344e9221e5c8c7a793bfbd14fe32db61/SMDegrain/SMDegrain.avsi#L1151

[tormento]

You need take a look at Dogway's script
https://github.com/Dogway/Avisynth-Scripts/blob/7b5e37d4344e9221e5c8c7a793bfbd14fe32db61/SMDegrain/SMDegrain.avsi#L1151

As I wrote:

I have tried to look at the avsi but can't understand the conditions.

I can't understand that the "obscure" parameters do or the values that can be applied.

[kedautinh12]

I just answer this question from you
And why do

ex_BM3D(preset="Light") or ex_BM3D(preset="light")

or

ex_BM3D(preset="Normal") or ex_BM3D(preset="normal")

[Guest]

I am puzzled about some sort of haloing or ringing that is random during certain scenes.

It's hard to detect on a PC monitor, but rather obvious on a large screen TV.

If someone would be good enough to download my 2 minute sample to "see" what I am on about, and get some suggestions.

https://www.mediafire.com/file/1rbcjtmcgv489c8/2+minute+sample.mkv/file (260Mb)

I'm thinking it might just be the phenomenon of "green screens" in the back ground.

If you pay particular attention to the horse riders as they ride passed the city wall, there's a "blurring" on some sort, surrounding them, but as they pass the gateway columns, into the gateway, the "blurring" disappears.

I've tried DeHalo_alpha, FineDehalo & HQDeringmod, to little affect :(

[tormento]

I just answer this question from you

I hoped it was case insensitive.

[DVB-Freak]

Hello,

I have a problem with this function.
When I load my script in VD2, it show me this error on the picture.

[kedautinh12]

You need use other image websites

[Guest]

You need use other image websites

This is FYI @DVB-Freak, for posting screenshots, etc.

Anything posted / attached here, takes a LONG time to be approved.

[DVB-Freak]

Here is the link to the image:

https://www.directupload.net/file/d/8490/ktjqm4bp_jpg.htm

My script:

FFVideoSource("C:\edit\Film.mkv")
FrameRateConverterMIX(Preset="RIFE", FrameDouble=true)

plugins:

ExTools v10.4 (09-01-2024)
Frame Rate Converter MIX v2.3.3 (10-10-2022)

[rgr]

Recently I have been testing QTGMCp. At 10 bits it is actually much faster than QTGMC, but the image quality is also lower - even worse than QTGMC at 8 bits.
The same settings: preset slower, TR=3.

Edit: I added it to Issues.

Left: QTGMCp (10bit)
Right: QTGMC (10bit)

https://i.imgur.com/KLx6bY0.png

[kedautinh12]

Lol, please upload your image to other image websites. The mod rarely approval your image from here

[takla]

@Dogway
I get the following error with FrameRateConverterMIX (https://raw.githubusercontent.com/Dogway/Avisynth-Scripts/master/MIX%20mods/FrameRateConverterMIX.avsi)


Evaluate: operands of "%" must be integers
ExTools.avsi, line 7509 (https://github.com/Dogway/Avisynth-Scripts/blob/master/ExTools.avsi#L7509)

[DTL]

Recently I have been testing QTGMCp. At 10 bits it is actually much faster than QTGMC, but the image quality is also lower - even worse than QTGMC at 8 bits.
The same settings: preset slower, TR=3.


Maybe you need to manually adjust thSAD values for each version of QTGMC script. For denoising part of this script.

From documentation http://avisynth.nl/index.php/QTGMC

ThSAD2 (0...) SAD threshold for block match on final denoising temporal smooth (TR2). Increase to strengthen final smooth (may smear/blur) Default: 256

If while increasing thSAD you got no-increase in denoise - it may mean sc-detector is active because of too high noise level. So you also need to set higher thSCD.

[Guest]

I just thought I'd bump this, as I was hoping for some sort of a reply :(

I'm sure this has been asked about many times, but...

Can you call SMDegrain (with different parameters) twice in the same script ??

If so, an example would be helpful.

Regards

[takla]

Can you call SMDegrain (with different parameters) twice in the same script ??

Regards

Yes you can. But why would you do that? It takes more CPU resources since the filter has to run twice.

To run it twice, use two lines with it...
Example
SourceFilter("input.mkv")
SMDegrain(blkSize=8)
SMDegrain(blkSize=32)

[Guest]

Yes you can. But why would you do that? It takes more CPU resources since the filter has to run twice.

To run it twice, use two lines with it...
Example
SourceFilter("input.mkv")
SMDegrain(blkSize=8)
SMDegrain(blkSize=32)

I will try this...there might be certain situations where the footage needs a 2nd "hit" with different parameters, that's all.

eg:- instead of a real heavy filter setting, use 2 lighter ones....

[takla]

I will try this...there might be certain situations where the footage needs a 2nd "hit" with different parameters, that's all.

eg:- instead of a real heavy filter setting, use 2 lighter ones....

Uhm no, thats not something you should do. Adjust TR for denoising strength and thSAD for how much noise is picked up.

[Guest]

Uhm no, thats not something you should do. Adjust TR for denoising strength and thSAD for how much noise is picked up.

This is only a curiosity script, I have some very specific & complex SMDegrain scripts I use :)

:thanks:

[Dogway]

Sorry for the delay, very busy these days. I'm updating a few things mentioned. Typos or minor QoL changes.

I just thought I'd bump this, as I was hoping for some sort of a reply :(

I'm sure this has been asked about many times, but...

Can you call SMDegrain (with different parameters) twice in the same script ??

If so, an example would be helpful.

Regards

You can run SMDegrain(mode="rMDegrain") and it will run MDegrain twice but with the same vectors. If you want to refine vectors simply run SMDegrain(RefineMotion=true). Or a suggestion from the docs, run SMDegrain as a prefilter for SMDegrain. Depends on what you want to do and source quality.



@Dogway
I get the following error with FrameRateConverterMIX (https://raw.githubusercontent.com/Dogway/Avisynth-Scripts/master/MIX%20mods/FrameRateConverterMIX.avsi)


The filter is working for me. That's in ex_bs() function, specifically in ibi = ibi-ibi%2 I think. 'ibi' is an int argument same as 'obi'. I'd need more info.



I got this error when tried SMDerain's latest ver:
My script:
LWLibavVideoSource("C:\Users\ADMIN\Downloads\LR_11.avi")
SMDegrain(6, 400, prefilter=6, ContraSharp=true, RefineMotion=true, plane=4, limits=false, DCTFlicker=false, gpuid=1)

SMDegrain doesn't officially support RGB, as stated in the script:
### Supports all Y, YUV and YUY2 clips progressive or interlaced between 8-16 bits.

[tormento]

Sorry for the delay, very busy these days.
Glad to have you back. :)

Please fix prefilter=7 in SMDegrain :devil:

[Dogway]

Updated SMDegrain to v4.6.0. Fixed ex_DGDenoise arguments, I don't quite like the search windows can't go now lower than 9, but at least I had implemented the LFR argument.

I also updated the manual with current versions of filters, etc.

[tormento]

I don't quite like the search windows can't go now lower than 9
AFAIK is because of speed optimizations. It seems that 9 is now a lot faster.

[DVB-Freak]

@Dogway

Can you look at post #2866? It's a simple script.
I updatet all to the newest versions. I add "ConvertBits(16)".
Nothing helps.

[DTL]

That may prove useful for some material I have with lots of troublesome dark areas. :)

New noise-resistant processing mode added to MAnalyse to make motion estimation in low contrast and high noised areas more stable - https://forum.doom9.org/showthread.php?p=1999795#post1999795 .

It is not complex in programming so expected to be added to 'stable' -e.XX builds to use in scripts like SMDegrain faster.

Currently this additional layer of MVs searching and averaging works at all levels (down to finest pel-level) so performance impact is great (though still about 2x faster in compare with number of new search runs added). In next releases I going to add option to limit 'area' mode additional search to only high levels down to pel=1 and it is expected to be several times faster while keeping most of accumulated quality at full-pel level.

[Dogway]

I updated FilmGrain+, I think the bugs in HBD are fixed now.

@Dogway

Can you look at post #2866? It's a simple script.
I updatet all to the newest versions. I add "ConvertBits(16)".
Nothing helps.

Post your script and error message.

[DVB-Freak]

https://www.directupload.net/file/d/...jqm4bp_jpg.htm

My script:

FFVideoSource("C:\edit\Film.mkv")
FrameRateConverterMIX(Preset="RIFE", FrameDouble=true)

plugins:

ExTools v10.4 (19-02-2024)
Frame Rate Converter MIX v2.3.3 (10-10-2022)

Avisynth+ v3.7.3

[DVB-Freak]

Sorry, here is the link to the error-message:


https://www.directupload.net/file/d/8490/ktjqm4bp_jpg.htm

[Dogway]

It's working for me, ensure you are in latest RIFE, GradePack and TransformsPack.

What is your source like, 422 or something out of the norm?

[rgr]

https://www.directupload.net/file/d/...jqm4bp_jpg.htm

My script:

FFVideoSource("C:\edit\Film.mkv")
FrameRateConverterMIX(Preset="RIFE", FrameDouble=true)

plugins:

ExTools v10.4 (19-02-2024)
Frame Rate Converter MIX v2.3.3 (10-10-2022)

Avisynth+ v3.7.3


Why don't you use RIFE directly?

FFVideoSource("C:\edit\Film.mkv")
convertbits(32).converttoplanarrgb(matrix="Rec709") # or other matrix
RIFE(model=5) # or 6
converttoyuv420(matrix="Rec709").convertbits(8,dither=0)

[DVB-Freak]

@Dogway
My source is BT.709 or YUV, it does no matter.
I've cleaned my pluginsfolder and put in the newest plugins.
The error remains.

@rgr
It was only a test. Actually is this my script:

ex_InterpolateDoubles(Preset="RIFE")

I hoped, that is the best quality. But it is the same error.
I give up now.
Thank you all

[tormento]

@Dogway

Do you plan to give the possibility to use SVPTools in your scripts?

[rgr]

@rgr
It was only a test. Actually is this my script:

ex_InterpolateDoubles(Preset="RIFE")

I hoped, that is the best quality. But it is the same error.
I give up now.
Thank you all

I don't know how this is supposed to give you better quality since it's the same as RIFE.

[Guest]

@Dogway
My source is BT.709 or YUV, it does no matter.
I've cleaned my pluginsfolder and put in the newest plugins.
The error remains.

@rgr
It was only a test. Actually is this my script:

ex_InterpolateDoubles(Preset="RIFE")

I hoped, that is the best quality. But it is the same error.
I give up now.
Thank you all

You need to provide the complete script !!

Are you using all the necessary dependancies ??

[DTL]

Some note about thSAD for MRecalculate: As I see it is currently hardcoded as halfthSADR. But it really complex adjustment for performance and performance/quality balance. It may be good to enable at least several control modes of thSAD for MRecalculate in scripting functions without direct control of thSAD for MRecalculate as script function param:

1. Force all new recalculated blocks refining search: set thSAD=0. Slowest mode but depending on source may make best quality (at least it can not make new MVs with more than searchparam offset from input MVs).
2. Sort of 'balanced/auto' - as today in SMDegrain. Average speed (also depends on noise level and thSAD settings).
3. Interpolate MVs only: set thSAD to 'very high' value like 1000 or more. May be average quality but fastest.

Today if user want to increase thSAD as input param to increase denoising in MDegrain - it also cause halfthSAD for MRecalculate to become larger and it passes more blocks with only interpolated MVs from input without real refining search. This may cause decreasing of MVs quality after MRecalculate and cause even more detail loss.

[tormento]

Is there any function in your scripts to convert chroma sampling position to other types, i.e. center to left etc?

[Dogway]

Is there any function in your scripts to convert chroma sampling position to other types, i.e. center to left etc?

Yes, ConvertFormat(). I'm on mobile so I can't post examples but on the explanation of the function I think you can see examples.

[tormento]

Yes, ConvertFormat(). I'm on mobile so I can't post examples but on the explanation of the function I think you can see examples.
It has so many switches that some examples would be helpful.

Can it be used when downsizing to half the original size, preserving chroma 4:2:0 to have 4:4:4 video?

I mean something like (thanks FranceBB)

Y = ConvertToY8(matrix="Rec709").DeBilinearResizeMT(960, 540, src_left=-0.50, src_top=0)
U = UToY8()
V = VToY8()
YToUV(U, V, Y)

[Dogway]

Deriving the offset values is a pain given the sheer number of variables (chroma subsampling, scale factor, etc).
I made the algorithm in line 1965 (https://github.com/Dogway/Avisynth-Scripts/blob/a02ab72341b3597b4aeaacb8d7f3bcb33a68849e/TransformsPack%20-%20Main.avsi#L1965)

ConvertFormat(cplace_in="left",cplace_out="center")

And you can specify the shifting kernel with 'kernel_c'

[tormento]

Do you have something similar or better than hysteria (http://avisynth.nl/index.php/Hysteria)in your scripts? I need to sharpen/line darken The dangers in my heart (https://forum.doom9.org/showthread.php?t=185425) anime, that is so blurry even from BD.

[Dogway]

Wow, the master is back!
If the blurring was too extreme I would recommend the model HurrDeblur, but in this case it's just "soft". Didée's trick with aWarpSharp2 with lowpass might work. As for line darkening/thinning I made a mod called FastLineDarkenPlus. Maybe give it a try, not sure how it compares to Hysteria.

[tormento]

If the blurring was too extreme I would recommend the model HurrDeblur
With what AVS+ plugin?

[poisondeathray]

If the blurring was too extreme I would recommend the model HurrDeblur

With what AVS+ plugin?


There is only 1 plugin that can be used directly in avs+ for HurrDeblur - avs-mlrt

https://github.com/Asd-g/avs-mlrt

[tormento]

There is only 1 plugin that can be used directly in avs+ for HurrDeblur - avs-mlrt
:thanks:

My poor 1660 Super will die on fire. :D

[simple_simon]

I've been using removegrain(mode=5) or vsdegrainmedian(modeY=3) to help with compressability without changing the overall look of the picture too much. What's the best ex_median mode to use as an equivalent?

[Lucky38]

hi,

I'm looking option to denoise with smdegrain enitre frame exept area where is the motion. How could i achive that?

[tormento]

@Dogway

Is there a way to pass parameters to prefilters but to use it as external prefilter? I am interested mostly in 6,7,8.

[DTL]

hi,

I'm looking option to denoise with smdegrain enitre frame exept area where is the motion. How could i achive that?

If SMDegrain exports MVs clip (as some named global ?) - you can feed it to MMask() and use output mask with AVS filters like Overlay() or Layer().
If not - you need to calculate MVs again (MSuper+MAnalyse).


After looking into ex_median - it is a great 64 different median (median-like ?) modes ! Now I am in the process of testing some ways of averaging MVs gathered from 'area' searches (with some offset from block's center position in tessellation grid - it sort of very dense overlap with possible steps on 1 sample dx,dy) to make more stable MV for degraded by noise sources. Which of the 64 different median modes can be tested for this process ?

The gathered MVs from AreaMode search can be treated either as 1D array or as 2D array. Currently, the implemented averaging modes process as 1D array and not use possible 2D information gathered (like distance/radius from block's center of the search position). The offset distance from block's center makes positives and negatives:
1. Positives - the more offset distance from block's center - the more new (not tested with original block's position) samples used and gather more new information about motion. It is sort of an increasing block size.
2. Negatives - the more offset distance from block's center - the more image motion may be changed and the offsetted MVs may be really somehow different from the original block's position.

So with 1 and 2 I am still not sure if we can apply some '2D spatial weighting' to the averaging process. Anyway AreaMode gathers lots of new valuable data to process about motion in some close area about block's center (not only MVs but also SAD (or other supported dissimilarity metric)) it is 2D array of 3 values in each (of size 2x2 + center or 3x3 + center minimum with AreaMode 'radius' of 1 sample and many more with > 1). So lots of different new processing modes may be tested to find the best way of refining MVs using new gathered data.

2D view of the question:
https://i.ibb.co/nQ3wbDg/image-2024-04-17-170508492.png

For gathered MVs set (2D array of scanned to 1D) of MV(0,0) and some of the MV(dx, dy) members (where dx and dy are +-integer offsets in the units of current search level of MAnalyse: +-1 sample at the full-pel level for example) which of the ex_median() averaging algorithms may be recommended to test to get more stable output MV ?

Each MV() is a structure of 3 members (dx, dy, sad). Where dx and dy are relative motion vector X and Y components). So for analysys of 2 completely equal frames MV(0,0) = MV(dx,dy)= (dx=0,dy=0,sad=0).
But if frames have some noise added: MV(0,0) may be not equal to any of others MV(dx, dy). Also MV(0,0) may have non-zero dx, dy also.

[Lucky38]

If SMDegrain exports MVs clip (as some named global ?) - you can feed it to MMask() and use output mask with AVS filters like Overlay() or Layer().
If not - you need to calculate MVs again (MSuper+MAnalyse).


@DTL,

Have you got some example how should look like proper call with SMDegrain?

Many Thanks :)

[DTL]

Documentation https://raw.githack.com/Dogway/Avisynth-Scripts/master/SMDegrain/SMDegrain.html
says
Motion Vectors Globals Input/Output: Reuse motion vectors globals for faster processing, or just use SMDegrain() as a shortcut for creating nice quality motion vectors.

Example

SMDegrain(tr=3,thSAD=400,globals=3) # Outputs vectors

Super = MSuper(levels=1) # Add this line just before if you have some processing between Globals Output and Input.
MDegrain3(Super, bVec1, fVec1, bVec2, fVec2, bVec3, fVec3, thSAD=400)


So you can try

denoised=SMDegrain(tr=3,thSAD=400,globals=3) # Outputs vectors
mask_clip=MMask(fVec1)
Overlay(last, denoised, mask=mask_clip)


I can not check because SMDegrain too complex for me and I can not gather all required dependencies and install as required. You need to check mask polarity (Use Invert() or arguments replacement in reverse order in Overlay() if result is inverted) and set mask 'sensitivity' to motion adjusting ml param at MMask(). Check mask_clip view to see how it masks motion areas,

[Lucky38]

Documentation https://raw.githack.com/Dogway/Avisynth-Scripts/master/SMDegrain/SMDegrain.html
says
Motion Vectors Globals Input/Output: Reuse motion vectors globals for faster processing, or just use SMDegrain() as a shortcut for creating nice quality motion vectors.
:thanks:
Example

SMDegrain(tr=3,thSAD=400,globals=3) # Outputs vectors

Super = MSuper(levels=1) # Add this line just before if you have some processing between Globals Output and Input.
MDegrain3(Super, bVec1, fVec1, bVec2, fVec2, bVec3, fVec3, thSAD=400)


So you can try

denoised=SMDegrain(tr=3,thSAD=400,globals=3) # Outputs vectors
mask_clip=MMask(fVec1)
Overlay(last, denoised, mask=mask_clip)


I can not check because SMDegrain too complex for me and I can not gather all required dependencies and install as required. You need to check mask polarity (Use Invert() or arguments replacement in reverse order in Overlay() if result is inverted) and set mask 'sensitivity' to motion adjusting ml param at MMask(). Check mask_clip view to see how it masks motion areas,

I need to test this..

:thanks:

[Lucky38]

Documentation https://raw.githack.com/Dogway/Avisynth-Scripts/master/SMDegrain/SMDegrain.html
says
Motion Vectors Globals Input/Output: Reuse motion vectors globals for faster processing, or just use SMDegrain() as a shortcut for creating nice quality motion vectors.

Example

SMDegrain(tr=3,thSAD=400,globals=3) # Outputs vectors

Super = MSuper(levels=1) # Add this line just before if you have some processing between Globals Output and Input.
MDegrain3(Super, bVec1, fVec1, bVec2, fVec2, bVec3, fVec3, thSAD=400)


So you can try

denoised=SMDegrain(tr=3,thSAD=400,globals=3) # Outputs vectors
mask_clip=MMask(fVec1)
Overlay(last, denoised, mask=mask_clip)


I can not check because SMDegrain too complex for me and I can not gather all required dependencies and install as required. You need to check mask polarity (Use Invert() or arguments replacement in reverse order in Overlay() if result is inverted) and set mask 'sensitivity' to motion adjusting ml param at MMask(). Check mask_clip view to see how it masks motion areas,

Ihave tried this

SMDegrain(tr=3,thSAD=400,globals=3) # Outputs vectors
mask_clip=MMask(fVec1)
denoised = SMDegrain(last ,tr=4, thSAD=480, thSCD2=100, prefilter=-1)
Overlay(last, denoised, mask=mask_clip)

but this is not work to my eyes. keep more grain on flat area than default SMDegrain call:
SMDegrain(tr=4, thSAD=480, thSCD2=100, prefilter=-1)

[DTL]

To debug the script you may start from checking the mask first - add

return mask_clip

(to the end of script or after mask_clip generation)

And look how it good or not tracks the static and motion areas. Depending on lots of settings (like MVs length and pel and many more) you may need to adjust mask with ml-param of MMask and/or with later any levels adjustment filters (Levels, ColorYUV, Tweak or other) to prepare best mask matching your source motion type and preference. And only next step is apply mask to Overlay() to get best result.

May be better to stack mask and real image in some way to see both mask and real frame at the same time like

return StackVertical(last, mask_clip)

But it may need more conversions to make colour formats equal of mask_clip and 'last' clip so Stack* can combine it in the single frame.

Overlay documentation: clip mask = (full opacity)
Optional transparency mask. Must be the same size as overlay. Where mask is darker, overlay will be more transparent. Must be 0-255 range (in general: 0 - 2^N-1 range for N bits format).

overlay clip is second param of Overlay() so where mask is black (no motion) it will output 'last' (denoised) clip.

MMask kind=0 (default) - Motion
Creates motion mask from the motion vectors length. It builds a better mask than MotionMask function of MaskTools plugin because motion vectors are a lot more reliable than the algorithm of MotionMask. Mask value 0 means no motion at all (the length of the motion vector is null). The longer vector length, the larger mask value (saturated to 255), the scale is defined by ml.

ml float default = 100. So if your motion is at low speed you may try to set higher ml param like

mask_clip=MMask(fVec1, ml=500)

Check if white levels at mask_clip is high enough at the moving areas/objects. Better about 100% white. If because of noise false MVs the MMask starts to output too high 'black level' at the static areas with big ml-value - you can add 'contrast' to mask_clip for better separation of slow motion or noised MVs from moving with Tweak(cont > 1.0) or may be Levels (params to increase conrast).

[simple_simon]

@Dogway

I noticed in the deep_resize script notes that it says linear sspace is best for downscaling. Do I need to convert to linear first or is this all that's needed:

convertbits(16) #(or 32?)
propSet("_FieldBased",0).deep_resize(1728,720,grain=0,qual=2,sspace="linear")
convertbits(8,dither=1)

[Dogway]

Yes, that's fine. You can omit grain and qual args in this case. I think 16bit is enough but check your downscaling kernel! By default it might be DPDIR or SSIM2, in such cases linear is not necessary

[simple_simon]

Yes, that's fine. You can omit grain and qual args in this case. I think 16bit is enough but check your downscaling kernel! By default it might be DPDIR or SSIM2, in such cases linear is not necessary

Looks like all three scalers are using "Didee" by default. I think SSIM2 used to be the default for most small downscaling. Would one of the 2 you mentioned be better?

Also, it probably got lost in the mix but did you happen to see my question here about Gradfun3plus?
https://forum.doom9.org/showpost.php?p=1998135&postcount=2852

[Dogway]

The kernel adapts to the downscaling ratio. In case of Didee the linear space might help , but it also depends on content due to risks on ringing. On live content it can be useful, on clean digital animations sources it might not.

As for adding grain option to Gradfun3plus let me check. I thought it was an option? (Writing from mobile)

[Guest]

Why would this script max out my 32Gb of RAM ?? (which sometimes crashes the PC)

SetCacheMode()
SetMemoryMax(16384)
LoadPlugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\DGHDRtoSDR\DGHDRtoSDR.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\MedianBlur2\MedianBlur2.dll")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\GRADE-PACK\Grade Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\LSF-PLUS\LSFplus.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\RESIZERS-PACK\Resizers Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\SHARPENERS-PACK\Sharpeners Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\SMDEGRAIN\SMDegrain.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\TRANSFORM-PACK\Transforms Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\TRANSFORM-PACK\Transforms Pack-Models.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\TRANSFORM-PACK\Transforms Pack-Transfers.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\Zs_RF_Shared\Zs_RF_Shared.avs")
video=ConvertBits(video,16)
pre=DGHDRtoSDR(video,mode="pq",white=2000,gamma=1/2.4,tm=1.0).ex_Median(mode="IQMST",thres=255)
video=STTWM(video,sw=50,tw=50,aw=100,sthres=5,tthres=5)
video=SMDegrain(video,tr=2,thSAD=200,thSADC=100,UHDHalf=false,limit=255,contrasharp=true,prefilter=pre,str=5.0,refinemotion=true)

[DTL]

If RAM usage grows constantly at processing - it may mean memory leak exist in some plugin. Try to isolate it by making script shorter and if found memory leak - report to developers.

[Guest]

If RAM usage grows constantly at processing - it may mean memory leak exist in some plugin. Try to isolate it by making script shorter and if found memory leak - report to developers.

Hi DTL,

Now that you've suggested this, the ONLY plugin that is different to the majority of my scripts, is DGHDRtoSDR.

It actually doesn't "grow", it's pretty much immediately :(

I've only just started to use this one, and I have been having some very unusual problems.

:thanks:

[Dogway]

Also try to use UHDHalf=true, mvtools2 might not handle 16-bit UHD resolution nicely.

[Guest]

Also try to use UHDHalf=true, mvtools2 might not handle 16-bit UHD resolution nicely.

:thanks:

Will be interested to hear what DTL might have say about statement, as he has been busy working on mvtools2..

[DTL]

Not nicely means performance is not great (also with blocksize of 8x8 even lower).

AVS cache size estimation for 4K 16bit (even in 4:4:4) and largest 'super' frame size with pel=2 (about 4x larger) - 8 Msamples of 6bytes x4 = 192 MB per frame. With 16threads and 10 frames in the cache per each thread - 25 GB in cache. Really big.

So it may be better to reduce the threads number for mvtools (AVS+ threads number of frames-based MT controlled by Prefetch(x,y) ) and if possible - number of frames in the AVS cache. And to keep more performance - enable internal MT via AVSTP.

I think the number of frames in the cache is expected to be controlled by Prefetch(M,N) where N is the number of frames. But I do not see if it really works.

In the sources it really has second param of frames -
https://github.com/pinterf/AviSynthPlus/blob/fa98d04b1386e5477154f6fc83cfef1a8155d5bb/avs_core/core/parser/script.cpp#L264
{ "Prefetch", BUILTIN_FUNC_PREFIX, "c[threads]i[frames]i", Prefetcher::Create },


So you can try to test different Prefetch(threads, frames) settings too. With frames from 1. If it is not working - it is subject to report to AVS core developers too.

You can try to see memory usage with AVSmeter report at testing your total script. If different 'frames' Prefetch() settings the amount of RAM usage does not change - it looks like a bug to be fixed.

[Boulder]

I think the number of frames in the cache is expected to be controlled by Prefetch(M,N) where N is the number of frames. But I do not see if it really works.

It's been working since day one. The problem with current processors is that the default amount of prefetched frames is double the amount of threads, which then easily leads to excessive memory usage with UHD sources. The amount of prefetched frames is much less crucial than the amount of threads what comes to encoding performance, unless you work on near realtime encodes.

[Guest]

@ DTL & Boulder,

Could either of you show me what you would change in script, please.

I'm running with Prefetch(12), but it doesn't need to be in the script, with RipBot.

Running 7950X, 5950X etc.

Or is it pointless ?

[DTL]

"I'm running with Prefetch(12)"

Try to start with Prefetch(12,1) . And with RipBot you need to find where it sends Prefetch(x,(y?)) line to AVS (if it really sends) and also edit its second param to 1 or something low as 1,2,3,etc. If second param not provided it may be up to double of threads number ? So your Prefetch(12) may be internally Prefetch(12,24) and use too much RAM for cache.

Or try to ask RipBot developers how to set prefetch frames number if it sends Prefetch() line to AVS after user's script.

As some hack you can try to add

return video.Prefetch(12,1)

as last line to the script. But it may broke RipBot if it uses special name of clip to return (video ?) or other.

Also as some experiment you can try to add .Prefetch(12,1) to each filter call (except source) so it may force AVS to set these prefetch params at least for these filters. Like
video=ConvertBits(video,16).Prefetch(12,1)
pre=DGHDRtoSDR(video,mode="pq",white=2000,gamma=1/2.4,tm=1.0).ex_Median(mode="IQMST",thres=255).Prefetch(12,1)
video=STTWM(video,sw=50,tw=50,aw=100,sthres=5,tthres=5).Prefetch(12,1)
video=SMDegrain(video,tr=2,thSAD=200,thSADC=100,UHDHalf=false,limit=255,contrasharp=true,prefilter=pre,str=5.0,refinemotion=true).Prefetch(12,1)

[Guest]

"I'm running with Prefetch(12)"

Try to start with Prefetch(12,1) . And with RipBot you need to find where it sends Prefetch(x,(y?)) line to AVS (if it really sends) and also edit its second param to 1 or something low as 1,2,3,etc. If second param not provided it may be up to double of threads number ? So your Prefetch(12) may be internally Prefetch(12,24) and use too much RAM for cache.

Or try to ask RipBot developers how to set prefetch frames number if it sends Prefetch() line to AVS after user's script.

As some hack you can try to add

return video.Prefetch(12,1)



as last line to the script. But it may broke RipBot if it uses special name of clip to return (video ?) or other.

Also as some experiment you can try to add .Prefetch(12,1) to each filter call (except source) so it may force AVS to set these prefetch params at least for these filters. Like
video=ConvertBits(video,16).Prefetch(12,1)
pre=DGHDRtoSDR(video,mode="pq",white=2000,gamma=1/2.4,tm=1.0).ex_Median(mode="IQMST",thres=255).Prefetch(12,1)
video=STTWM(video,sw=50,tw=50,aw=100,sthres=5,tthres=5).Prefetch(12,1)
video=SMDegrain(video,tr=2,thSAD=200,thSADC=100,UHDHalf=false,limit=255,contrasharp=true,prefilter=pre,str=5.0,refinemotion=true).Prefetch(12,1)


Sadly, none of this made any difference to the RAM usage, even the RipBot dev suggested something, but again, that made no difference.

So it's either not using this script, OR buying more RAM.

One thing I should mention is, as RipBot can use Distributed Encoding, you can "load up" the CPU until it basically slows the whole process down, and I generally process 2 chunks at a time, which maxes out the RAM, IF I only process 1 chunk at a time, the RAM usage is more than acceptable.

I can simply run more encoding servers to "pick up the slack"....

So anyone else using this script would not have a RAM usage issue, except maybe with StaxRip, which offers a form of chunk encoding, but only on the same PC.

:thanks:

[DTL]

" none of this made any difference to the RAM usage"

It is really a sad sign of possible more bugs in the prefetcher exists. I will try to test at my use cases and if it also not works as expected - it is a subject to new issue at AVS+ development.

[Boulder]

I would first test the script (and post it here) with different Prefetch parameters in AVSMeter64 before spending too much time faffing about.

[DTL]

It looks like subject of long testing:

With simple internal script

ColorBars()

TurnRight()
#Prefetch(2,1)
Prefetch(2)


RAM usage difference is big between Prefetch[2] and Prefetch[2,1] host CPU is 2 cores E7500. About 20 vs 13 MB. But with my typical test script with lots of mvtools filters calls it close to several % with frame size 800x480 - about 640 and 630 MB. So Prefetct[2,1] is really working to make RAM usage a bit lower - but not as low as expected. Need to test with UHD frame sizes and pel=2 later at host with may RAM and many cores CPU. Also it is better to test with real SMDegrain script running. I typically can not install all required plugins to test it. So if someone have all environment configured to run SMDegrain it is faster to test at that host.

[Boulder]

I tested a UHD source with my denoiser script with some MVTools stuff, outputting 16-bit data in and out. 32 threads in use.
If I put my resizer there, the usage would be much higher I think.

frames 1: 4560 MB
frames 4: 6196 MB
frames 8: 8580 MB
frames 16: 13097 MB
frames 32: 19188 MB
default, frames 64: 22014 MB (hitting some limit? Max is set to 30000 MB)

[LouieChuckyMerry]

Hi Dogway, I hope you're well (and am glad you're back) :) . After transitioning from your original SMDegrain Mod to real.finder's continuation, I finally have your latest SMDegrain Mod (v4.6.0d) working but can't figure out the equivalent of "LSB_In=True" and "LSB_Out=True" ("n16=True" and "n16_Out=True" with real.finder's versions). My typical SMDegrain, well, NotSMDegrain, call is

SMDegrain(TR=1~5,ThSAD=100~900,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)

Thanks for any help.

[DTL]

Some hacks around 16bit were required for old versions of mvtools. With 2.7.45 (46) you can try simply feed 10..16 bit input without any additional params and expect it is processed unchanged and output the same.

[LouieChuckyMerry]

DTL: Thanks for your reply. I'm just a hobbyist, so my understanding of AviSynth is quite limited and my use of it's very simple. Typically, I'll take either an 8-bit or 10-bit source and process it with the script

SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1~5,ThSAD=200~900,RefineMotion=True,Plane=0,Chroma=False)
FastLineDarkenPlus()
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(X,depending on which computer)

outputting to 10bit x264. Sometimes I'll use Spotless() as a prefilter, but that's about as complex as I get. So, to achieve processing the above in 16-bit would I add "ConvertBits(Bits=16)" to the script here

SetFilterMTMode("Default_MT_Mode",2)
ConvertBits(Bits=16)
SMDegrain(TR=1~5,ThSAD=200~900,RefineMotion=True,Plane=0,Chroma=False)
FastLineDarkenPlus()
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(X,depending on which computer)

Thanks for your help.

[Boulder]

So, to achieve processing the above in 16-bit would I add "ConvertBits(Bits=16)" to the script here

SetFilterMTMode("Default_MT_Mode",2)
ConvertBits(Bits=16)
SMDegrain(TR=1~5,ThSAD=200~900,RefineMotion=True,Plane=0,Chroma=False)
FastLineDarkenPlus()
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(X,depending on which computer)

That would most likely be enough. You can doublecheck the output video format by adding Info() after the SMDegrain line and opening the script in VDub for example.

[Lucky38]

Hi Dogway, I hope you're well (and am glad you're back) :) . After transitioning from your original SMDegrain Mod to real.finder's continuation, I finally have your latest SMDegrain Mod (v4.6.0d) working but can't figure out the equivalent of "LSB_In=True" and "LSB_Out=True" ("n16=True" and "n16_Out=True" with real.finder's versions). My typical SMDegrain, well, NotSMDegrain, call is

SMDegrain(TR=1~5,ThSAD=100~900,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)

Thanks for any help.


Hi,

could someone explain how SMDegrain will known when use TR=1 or TR=5 and the same for ThSAD?

i did not see in documentation any information that these parameters can have range value....

[Guest]

Hi,

could someone explain how SMDegrain will known when use TR=1 or TR=5 and the same for ThSAD?

i did not see in documentation any information that these parameters can have range value....

Here's an example...

https://forum.doom9.org/showthread.php?p=2001092#post2001092 post #2917

[StvG]

So, to achieve processing the above in 16-bit would I add "ConvertBits(Bits=16)" to the script here

SetFilterMTMode("Default_MT_Mode",2)
ConvertBits(Bits=16)
SMDegrain(TR=1~5,ThSAD=200~900,RefineMotion=True,Plane=0,Chroma=False)
FastLineDarkenPlus()
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(X,depending on which computer)

That would most likely be enough. You can doublecheck the output video format by adding Info() after the SMDegrain line and opening the script in VDub for example.

F3KDB doesn't support native 16-bit (only stacked, interleaved). Repalce it with neo_f3kdb.

[Lucky38]

Here's an example...

https://forum.doom9.org/showthread.php?p=2001092#post2001092 post #2917


hi FTLOY,

thank you for your replay but this is not the explanation i was hope to get...

I use SMDegrain but i havn't seen that TR=1~5 and ThSAD=200~900 can work with range value...

That is why i was asked how does SMDegrain will known when use TR=1 or TR=2 ... or TR=5 ?

[Boulder]

hi FTLOY,

thank you for your replay but this is not the explanation i was hope to get...

I use SMDegrain but i havn't seen that TR=1~5 and ThSAD=200~900 can work with range value...

That is why i was asked how does SMDegrain will known when use TR=1 or TR=2 ... or TR=5 ?

That was just to mark an example of range. You need to set a fixed TR and ThSAD to your liking.

[Lucky38]

That was just to mark an example of range. You need to set a fixed TR and ThSAD to your liking.

thanks for clarification. :thanks:

[LouieChuckyMerry]

That would most likely be enough. You can doublecheck the output video format by adding Info() after the SMDegrain line and opening the script in VDub for example.

Thanks for your reply. It does seem to be enough; unfortunately, adding Info() after the SMDegrain line doesn't show any info upon opening the script in MeGUI or VirtualDub2 :( .

EDIT: Adding Info() after the SMDegrain line works on my second computer and shows that it's processing in 16bits. Thanks for the new trick.

F3KDB doesn't support native 16-bit (only stacked, interleaved). Repalce it with neo_f3kdb.

Good catch, StvG :thanks: . That explains quite a bit...

Lucky38: Sorry for the confusion.

[DTL]

Some idea about different prefilters usage (including no-prefiter): At testing QTGMC it was found single prefilter mode can not make all areas better in details. With prefilter-ON some areas get better and others not. With prefilter-OFF it is changed. So I make some function to gather most possible details from several filter runs. With deinterlace processing of QTGMC it also collect most of noise from different filter runs also. But it may be tested with SMDegrain too with different prefilters at single processing. The function GetSharpest() included into M_QTGMC listed at https://forum.doom9.org/showthread.php?p=2001388#post2001388 and it uses new plugin MostDiffVal.dll to run. Though I think maybe it can be implemented with all internals of AVS like Layer() instead of Average and Expr() instead of MostDiffVal().

So to run SMDegrain with a set of prefilters (any set may be combined in a chain of GetSharpest(clip1, clip2):


pref1=SMDegrain(prefilter=0)
pref2=SMDegrain(prefilter=1)

GetSharpest(pref1, pref2)

where GetSharpest() is

Function GetSharpest(clip c1, clip c2)
{
avg=Average(c1.GaussResize(c1.width, c1.height, src_left=0.001, src_top=0.001, p=2), 0.5, c2.GaussResize(c2.width, c2.height, src_left=0.001, src_top=0.001, p=2), 0.5)

return MostDiffVal(avg, c1, c2)
}

[gispos]

Some idea about different prefilters usage (including no-prefiter): At testing QTGMC it was found single prefilter mode can not make all areas better in details. With prefilter-ON some areas get better and others not. With prefilter-OFF it is changed. So I make some function to gather most possible details from several filter runs. With deinterlace processing of QTGMC it also collect most of noise from different filter runs also. But it may be tested with SMDegrain too with different prefilters at single processing. The function GetSharpest() included into M_QTGMC listed at https://forum.doom9.org/showthread.php?p=2001388#post2001388 and it uses new plugin MostDiffVal.dll to run. Though I think maybe it can be implemented with all internals of AVS like Layer() instead of Average and Expr() instead of MostDiffVal().

So to run SMDegrain with a set of prefilters (any set may be combined in a chain of GetSharpest(clip1, clip2):


pref1=SMDegrain(prefilter=0)
pref2=SMDegrain(prefilter=1)

GetSharpest(pref1, pref2)

where GetSharpest() is

Function GetSharpest(clip c1, clip c2)
{
avg=Average(c1.GaussResize(c1.width, c1.height, src_left=0.001, src_top=0.001, p=2), 0.5, c2.GaussResize(c2.width, c2.height, src_left=0.001, src_top=0.001, p=2), 0.5)

return MostDiffVal(avg, c1, c2)
}


Why isn't it working as expected? It always shows 'c2'

c1=Sharpen(0.80).subtitle("c1")
c2=Sharpen(0.10).subtitle("c2")
GetSharpest(c1, c2)


Edit: The sharper one is returned, but not the subtitle. This confuses me, please clarify.

Edit2: Oh, a combination of both clips will probably be returned. When I use 'a' and 'f' as a subtitle I see that 'a' and 'f' are overlaid.

[DTL]

It works on sample-level granularity from both input clips. So Subtitle text will be mixed (and typically not very well processed as extreme 0 and max values). Better results on natural narrow/limited range.

For test you need to mask-sharpen c1 clip at one area and mask-sharpen c2 clip at different area and process to see if returned both sharpened areas from c1 and c2.

More sad thing about MAnalyse/MDegrain/MCompensate is with different areas grouped MVs errors it also cause different areas global shift (not only fine sharpness lost) so the GetSharpest() will also somehow mix these areas. And with different pre-filters these grouped MVs areas errors also different.

I typically check it as


c1=Process(params1).Subtitle("params1")
c2=Process(params2).Subtitle("params2", align=..some2, not default and not 4)

sh=GetSharpest(c1, c2).Subtitle("gs", align=4)

Interleave(c1, sh, c2)


And check different areas looking in c1 vs sh and c2 vs sh with frame step in VirtualDub.

[DTL]

Finally made replacement of all functions with AVS internal Expr() and ex_Tools for GetSharpest():


Function GetSharpest(clip c1, clip c2)
{
avg=Layer(c1.ex_GaussianBlur(1.8, UV=3), c2.ex_GaussianBlur(1.8, UV=3), "fast")

return Expr(avg, c1, c2, "x y - abs x z - abs >= y z ?")

#or some faster
#return MostDiffVal(avg, c1, c2)
}


The sigma param for GaussianBlur is subject to check for best results (or best for current user/footage/filters/ etc). Currently 1.8 is about equal to GaussResize(p=2) blur. Also compiled plugin MostDiffVal updated to v0.2 with AVX2 functions and opt SIMD manual control (optional or auto). With 8bit it runs about 2 times faster in comparison with Expr() - looks like because Expr() perform internal calculations with float32 and have penalty of convert from integer to float and back.

ex_GaussianBlur() runs about 1.5 times faster in comparison with GaussResize() for blurring. Also Layer("fast") is somehow faster in comparison with Average(0.5,0.5).

About twice faster with not yet tested quality change is single blur of averaged input clips:

Function GetSharpest(clip c1, clip c2)
{
avg=ex_GaussianBlur(Layer(c1, c2, "fast"),1.8, UV=3)

return Expr(avg, c1, c2, "x y - abs x z - abs >= y z ?")

#or some faster
#return MostDiffVal(avg, c1, c2)
}


Edit: With full chroma planes processing (UV=3 for ex_GaussianBlur) the GaussResize still some faster (looks like integer 2 pass V+H AVS resize kernel is faster, at least for not very large radius blur):


Function GetSharpest(clip c1, clip c2)
{
avg=GaussResize(Layer(c1, c2, "fast"), c1.width, c1.height, src_left=0.001, src_top=0.001, p=2)

return Expr(avg, c1, c2, "x y - abs x z - abs >= y z ?")

#or some faster
#return MostDiffVal(avg, c1, c2)
}

[LouieChuckyMerry]

I very recently transitioned from real.finder's last version of NotSMDegrain (3.1.2.116s) to Dogway's most recent version of SMDegrain (4.6.0d), running on Windows 7 with 64-bit AviSynth+ 3.73. It seems to work fine, but I'm trying to understand why the speed is basically the same (within ~5%) but the resulting video bitrate is radically different (roughly a full CRF). To wit, the scripts

SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=4,ThSAD=700,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
FastLineDarkenMod4()
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
SelectRangeEvery(1000,66)
PreFetch(5)

and

SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(Prefilter=SpotLess(),TR=3,ThSAD=500,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
FastLineDarkenMod4()
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
SelectRangeEvery(1000,66)
PreFetch(5)

with the filters-plugins

F3KDB__64bit
FastLineDarkenMTMod1_48
LinearTransformation
MaskTools2_2_26_0MTDualSignatureMod_pinterf__64bit
MedianBlur2__1_1__64bit
MVTools2_7_41_0MTMod_pinterf__64bit
SharedFunctions1_153
SMDegrainMod_rf_3_1_2_116s
SpotLess1_07

results in bitrates of 3471 kb/s and 4209 kb/s, respectively, while the scripts

SetFilterMTMode("Default_MT_Mode",2)
ConvertBits(Bits=16)
SMDegrain(TR=4,ThSAD=700,RefineMotion=True,Plane=0,Chroma=False)
FastLineDarkenPlus()
Neo_F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
SelectRangeEvery(1000,66)
PreFetch(5)

and

SetFilterMTMode("Default_MT_Mode",2)
ConvertBits(Bits=16)
SMDegrain(Prefilter=SpotLess(),TR=3,ThSAD=500,RefineMotion=True,Plane=0,Chroma=False)
FastLineDarkenPlus()
Neo_F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
SelectRangeEvery(1000,66)
PreFetch(5)

with the filters-plugins

ExTools10_1
FastLineDarkenPlus
LinearTransformation
MaskTools2_2_30_0MTDualSignatureMod_pinterf__64bit
MedianBlur2__1_1__64bit
MVTools2_7_46_0MTMod_pinterf__64bit
Neo_F3KDB9_0__64bit
SMDegrain4_6_0d
SpotLess1_07

results in bitrates of 4165 kb/s and 5173 kb/s, respectively. The sources are the same. Any help understanding why the bitrates are so different would be greatly appreciated.

[Emulgator]

Less entropy, less changing high frequency details, and encoder can save bits.
It may not be visible at first, only pixel-peeping and framestepping will tell what those plugins were able to smoothe.
To go through all plugin's parameter's dependencies would make up a matrix which one should like to solve on his side.
From my side of experience I can tell that Dogway's algos give nice details which got to be honoured by bits...
and of course... many thanks, at least from my side.

[kedautinh12]

You can try with High bit depths to see more clearly about speed

[LouieChuckyMerry]

Less entropy, less changing high frequency details, and encoder can save bits.
It may not be visible at first, only pixel-peeping and framestepping will tell what those plugins were able to smoothe.
To go through all plugin's parameter's dependencies would make up a matrix which one should like to solve on his side.
From my side of experience I can tell that Dogway's algos give nice details which got to be honoured by bits...
and of course... many thanks, at least from my side.


Thank you for a very philosophical answer :) . And I also appreciate Dogway's work very much.


You can try with High bit depths to see more clearly about speed

Please, I don't understand what you mean.

[kedautinh12]

Lol, please search google about High bit depths video and try add converttobit(16) or converttobit(32) and compare both of them again. SMDegrain build by Dogway for speed with High bit depths video not for 8 bit video only

[Guest]

Lol, please search google about High bit depths video and try add converttobit(16) or converttobit(32) and compare both of them again. SMDegrain build by Dogway for speed with High bit depths video not for 8 bit video only

I thought it was ConvertBits(16)....

http://avisynth.nl/index.php/ConvertBits

[Emulgator]

BTW, LouieChuckyMerry,
SMDegrain(Prefilter=SpotLess(),TR=3,ThSAD=500,RefineMotion=True,Plane=0,Chroma=False)
does not work, throws an error.
Prefilter=SpotLess() is not implemented this way within SMDegrain 4.6.0d

[DTL]

You may need to add SpotLess() function body to the script before call it or Import() .avsi file with this script function body.

Function SpotLess() is from https://forum.doom9.org/showthread.php?t=181777 .

[LouieChuckyMerry]

Lol, please search google about High bit depths video and try add converttobit(16) or converttobit(32) and compare both of them again. SMDegrain build by Dogway for speed with High bit depths video not for 8 bit video only


I'm working in 16-bit (see Post #2946 (https://forum.doom9.org/showpost.php?p=2002020&postcount=2946)), but will give 32-bit a try. Thanks.


I thought it was ConvertBits(16)....

http://avisynth.nl/index.php/ConvertBits


ConvertBits(Bits=16)

The above works for me.


BTW, LouieChuckyMerry,

does not work, throws an error.
Prefilter=SpotLess() is not implemented this way within SMDegrain 4.6.0d

It seems to work fine for me...

[Emulgator]

I see now. This argument takes a clip too, (this is possible, I found it in an old script being (last), and I was expecting an integer argument).

[tormento]

I have always used PureVideo deinterlacer for IVTC from 29.97 to 23.974 by using

DGTelecide(mode=1, pthresh=3.5)
DGDecimate()

but I'd like to try something better.

What do you suggest me from your scripts without incurring in miserable performances?

I have a very old i7-2600k and a nVidia 1660 SUPER gpu and remember that I have to encode it too. :o

(I was looking at RIFE but I fear it's too heavy, mostly because of double RGB32 and back conversion and, above all, I have no idea if it's suitable for IVTC too)

[rgr]

it uses new plugin MostDiffVal.dll to run

Where can I download this plugin?

[DTL]

Latest version is https://github.com/DTL2020/MostDiffVal/releases/tag/0.2 .

But it can be replaced with Expr() call

Expr(avg, c1, c2, "x y - abs x z - abs >= y z ?")


It is slower with 8bit and may be 16bit because Expr() process always with float internally. But Expr() always available as AVS core function.

[Guest]

I'm looking for a simple script for adding a small transparent "watermark" image to a video clip. (eg:- like Netflix)

[DTL]

Try to load your image with alpha channel and use Overlay() - http://avisynth.nl/index.php/Overlay . If fixed opacity is enough - you can load RGB image without alpha channel and control with
float opacity = 1.0
Set overlay transparency. The value is from 0.0 to 1.0, where 0.0 is transparent and 1.0 is fully opaque. This value is multiplied by mask luminance to form the final opacity.

Or you can load grey mask as separate image too.

[Guest]

Try to load your image with alpha channel and use Overlay() - http://avisynth.nl/index.php/Overlay . If fixed opacity is enough - you can load RGB image without alpha channel and control with
float opacity = 1.0
Set overlay transparency. The value is from 0.0 to 1.0, where 0.0 is transparent and 1.0 is fully opaque. This value is multiplied by mask luminance to form the final opacity.

Or you can load grey mask as separate image too.

Thanks DTL, but how do I add a .png file as the "watermark" ??

TBH, on the RipBot264 thread, the dev provided a pretty fancy script that I cannot get to work as displayed:-

Script:-
https://forum.doom9.org/showthread.php?p=2002510#post2002510

Result:- (top right corner)
https://forum.doom9.org/showthread.php?p=2002513#post2002513

Completely stumped, and more annoying the op who asked for help, got it work first go :(

[DTL]

Try

logo=ImageReader("mylogo.png", fps=25, use_DevIL=true, pixel_type="RGB32")
Overlay(logo, x=10, y=10, opacity=0.2, mask=logo.ShowAlpha("yv12"))

[Guest]

Try

logo=ImageReader("mylogo.png", fps=25, use_DevIL=true, pixel_type="RGB32")
Overlay(logo, x=10, y=10, opacity=0.2, mask=logo.ShowAlpha("yv12"))


Thanks again, DTL,

I will see if I can get this work, but in the meantime, back on the RipBot264 thread, the op has found an issue that might be why I couldn't get that script to work.

It's an 8 bit vs 10 bit issue....

UPDATE:-

pdr came to the "rescue", it's working perfectly.

[LouieChuckyMerry]

Lol, please search google about High bit depths video and try add converttobit(16) or converttobit(32) and compare both of them again. SMDegrain build by Dogway for speed with High bit depths video not for 8 bit video only

I finally had some spare time to try 32bit input, but the resulting video is very, very, very dark, and when I check the github page (https://htmlpreview.github.io/?https://github.com/Dogway/Avisynth-Scripts/blob/master/SMDegrain/SMDegrain.html), it states "High bitdepth denoising: Supports AviSynth+ native HBD formats, from 8-bit up to 16-bit.". Are you able to input 32bit and return successful video?

[Dogway]

Thanks DTL, but how do I add a .png file as the "watermark" ??

I just updated Logo() which is for a simple Logo addition without any hustle on the mask handling, etc.

It allows for several modes, screen, multiply, watermark, or over, with opacity and fade in, fade out options.

The update was simply to default Chroma=true when "Over" mode (the default) was being used.

[LouieChuckyMerry]

I'm trying to put Deblock_QED to use in the DeblockPack.avsi and seem to actually have it functioning correctly, but wanted to make sure before I spend time testing it. My script is

Deblock_QED()
ConvertBits(Bits=16)
TemporalDegrain2()
CAS()
Neo_F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)

I found that putting the Deblock_QED call after converting to 16bits made for LSD flashback-style output; does this mean that it only accepts 8bit input?

Also, while gathering the needed dependencies for Deblock_QED in the DeblockPack.avsi, I encountered the plugin BlockDetect (https://github.com/Asd-g/AviSynthPlus-BlockDetect) and wondered what it does. Well, I can read what it does, but don't understand why it would be used. Thanks.

[Guest]

I posted on another thread, but got no response, and I come over here, and Louie is here, too :)

I would appreciate some advice on trying to remove the "spots" & artifacts with this video.
https://www.mediafire.com/file/hz00084l90t6p6b/spots.7z/file 142Mb
Regards

[LouieChuckyMerry]

FTLOY: Something's wrong with your link...

Edit: Also with the link on your SpotLess posts...

[Guest]

Thanks Louie , I checked, it's been restricted, I'll post it again as a .7z.

Cheers

DONE :)

[tormento]

I have a very strange issue:

SetMemoryMax()
SetCacheMode(0)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
LoadPlugin("D:\Eseguibili\Media\DGCube\DGCube.dll")
DGSource("M:\In 4k\Dune 4k 4000\dune4k.dgi",ct=280,cb=280,cl=0,cr=0)
libplacebo_Resample(1920,800,filter="ewa_lanczossharp")
libplacebo_Tonemap(src_csp=1, dst_csp=2, LUT="D:\Programmi\Media\AviSynth+\cube\2a_PQ4000_HLG_mode-nar_in-nar_out-nar_nocomp.cube")
SMDegrain (tr=3, thSAD=300, refinemotion=false, contrasharp=false, PreFilter=7, plane=4, chroma=true, mode="MDegrain")
fmtc_resample (css="420")
fmtc_bitdepth (bits=10,dmode=7)
Prefetch(2,6)

works, as well with prefilter=8 but with prefilter=6 I have alternating black and correct frame continuously.

Any idea?

[Emulgator]

Which KNLMeansCL version ? 12.11.2020 seems to work here. 1.1.1e by pinterf

[tormento]

Which KNLMeansCL version ? 12.11.2020 seems to work here. 1.1.1e by pinterf
Same version.

A simple script such as

SetMemoryMax()
SetCacheMode(0)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
DGSource("M:\In\The witch and the beast ~856p BDJP\01.dgi")
SMDegrain (tr=3, thSAD=300, refinemotion=false, contrasharp=false, PreFilter=6, plane=4, chroma=true, mode="MDegrain")
Prefetch(2,6)

works ok.

[Dogway]

@tormento, I tried this only line for an upscale:
libplacebo_Resample(1920,800,filter="ewa_lanczossharp")

And it freezed avspmod. Using ffvideosource.

[Emulgator]

This is my preamble.
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("LWLibavVideoSource", 3)
SetFilterMTMode("LWLibavAudioSource", 3)
SetFilterMTMode("FFVideoSource", 3)
SetFilterMTMode("FFAudioSource", 3)
SetFilterMTMode("DGSource", 3)
SetFilterMTMode("InpaintDelogo", 3)
You want to set Source Filters MTMode to 3.

[StvG]

@tormento, I tried this only line for an upscale:
libplacebo_Resample(1920,800,filter="ewa_lanczossharp")

And it freezed avspmod. Using ffvideosource.

Using the latest ffms2 and the latest avs_libplacebo - no issues, no freezing.

This is my preamble.
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("LWLibavVideoSource", 3)
SetFilterMTMode("LWLibavAudioSource", 3)
SetFilterMTMode("FFVideoSource", 3)
SetFilterMTMode("FFAudioSource", 3)
SetFilterMTMode("DGSource", 3)
SetFilterMTMode("InpaintDelogo", 3)
You want to set Source Filters MTMode to 3.

If relatively recent versions of the filters are used, these calls does nothing. Well, they no harm but they just redundant. The reason - the recent plugins does set own MT mode. If you really want to change this internal plugin MT mode you must use SetFilterMTMode("....", force=true).
Also You cannot set the MT mode on script function calls, only on binary filters. (http://avisynth.nl/index.php/SetFilterMTMode#SetFilterMTMode) (SetFilterMTMode("InpaintDelogo", 3)).

[tormento]

@tormento, I tried this only line for an upscale:
libplacebo_Resample(1920,800,filter="ewa_lanczossharp")

And it freezed avspmod. Using ffvideosource.


Try with v0lt’s VirtualDub2. Avspmod is a bit picky sometimes.

What gpu do you have?

[tormento]

How to apply SMDegrain to 444 video (it comes from a halfsized 1080 to 540)?

I have some issues, trying to use GPU prefilters.

[Dogway]

What kind of issues? I'm testing 960x540 @8bit with prefilters 6, 7 and 8. Seems ok an Avspmod, is it on encode? SMdegrain call.

[tormento]

What kind of issues? I'm testing 960x540 @8bit with prefilters 6, 7 and 8. Seems ok an Avspmod, is it on encode? SMdegrain call.
My bad, can't replicate. Will test further. :o

[gispos]

Try with v0lt’s VirtualDub2. Avspmod is a bit picky sometimes.
When and why ?

[tormento]

Why is a mistery to me.

When, sometimes when high GPU usage is required.

[LouieChuckyMerry]

Try with v0lt’s VirtualDub2. Avspmod is a bit picky sometimes.

Please, where would I find v0lt's VirtualDub2?

[Guest]

Please, where would I find v0lt's VirtualDub2?

Surely you've heard of Google ???

https://forum.videohelp.com/threads/414223-VirtualDub2-Fork-By-v0lt

https://github.com/v0lt/VirtualDub2

[LouieChuckyMerry]

FTLOY: Thanks for that. I did search for it but couldn't find it. Honest. It was late night-early morning and I was rather, er, happy, though, so probably not thinking clearly enough.

[tormento]

@dogway

This bug is true, easily reproducible. ;)

Get a UHD, Dovi or whatever, enough that it has a PQ stream.

Use:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
LoadPlugin("D:\Eseguibili\Media\DGCube\DGCube.dll")
DGSource("M:\In 4k\Mad Max - Furiosa\furiosa_804p.dgi",ct=276,cb=276,cl=0,cr=0)
z_ConvertFormat(width=1920, height=804, pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:full", resample_filter_uv="Spline64", dither_type="error_diffusion", use_props=0)
DGCube("D:\Programmi\Media\AviSynth+\cube\PQ_to_HLG.cube", in="full", lut="full", out="full")
z_ConvertFormat(pixel_type="YUV420P10", colorspace_op="rgb:std-b67:2020:full=>2020:std-b67:2020:limited", resample_filter_uv="Spline64", dither_type="error_diffusion", use_props=0)
SMDegrain (tr=3, thSAD=300, truemotion=false, contrasharp=false, PreFilter=6, plane=4, chroma=true, mode="MDegrain")
Prefetch(2,6)

You can find the appropriate LUT in FranceBB github page.

It will give you alternating corrupted and black frames.

It doesn't work for prefilter=6 but it does for 7 and 8. Perhaps a KNLMeansCL bug, not yours.

[Lucky38]

@Dogway

Will SMDgrain work better with this release of mvtools https://github.com/DTL2020/mvtools/releases? or it can't adavange new feature?

[Emulgator]

Some quickfixes on FillMissing 2.03
# FillMissing
# Based on script created by Did�e
# Based on script created by Did�e
# Modified by John Meyer on June 29, 2011
# Further modification on June 8, 2013
# Tdecimate modifications on October 26, 2021
# v1.10 - Updated and Sanitized by Dogway on Mar 05, 2019
# v1.21 - Updated and Sanitized by Dogway on May 18, 2021
# v1.30 - Further optimized (dcycle from DeJump) by Dogway on Jul 15, 2021
# v1.31 - Optimize for HBD by Dogway on Aug 15, 2021
# v1.32 - Remove GrunT dependency by Dogway on Oct 02, 2021
# v1.40 - BWmask bugfixes by Dogway on Oct 28, 2021
# v1.41 - Rebase with latest FrameRateConverter by Dogway on Jan 10, 2022
# v2.00 - Replace with RIFEwrap and hence an EX mod by Dogway on Feb 18, 2023
# v2.01 - Add 'sc=false' to RIFEwrap to force MI by Dogway on Feb 18, 2024
# v2.02 - Fix gpuid to gpu_id for RIFEwrap uses gpuid internally by Emulgator on Aug 28, 2024
# v2.03 - Fix for bitdepths >8bpc: Downconvert BWMask input to 8 bit and expand mask output afterwards to source bitness for ex_merge by Emulgator on Aug 29, 2024
#
# Dependencies:
# ExTools 10.4
# ResizersPack 12.1
# TransformsPack 2.2.1
# TIVTC
#
#
# - Create interpolated frames at 2x original frame rate using RIFE
# - Detect jumps
# - Create white mask at each jump point; black mask for all other frames
# - Repeat each frame of original video and use mask to "choose" between original video, or motion estimated video
# - Decimate exactly 50% to get back to original frame rate.
# - This decimation removes the dup frames from the original video and also the dups created by repeating each frame of original video
# - However, at each point where motion-estimated frame was inserted, no decimation occurs. Thus, if dups=drops, and the drop happens
# within < "cycle" (TDecimate parameter) of the dup, the dup will be removed and the drop will be filled.
# - If no drops or dups occur within "cycle," then no motion estimation happens, and decimation merely gets back to original,
# unchanged video.


function FillMissing(clip source, float "JumpThresh", bool "Fast", int "dcycle", bool "Show", int "gpu_id", bool "debug") {

source

fs = propNumElements("_ColorRange") > 0 ? \
propGetInt ("_ColorRange") == 0 : isRGB(source)

JumpThresh = Default(JumpThresh,0.8) # Threshold for detecting jumps. Increase to catch more jumps. Should always be less than 1.0
Fast = Default(Fast, true) # true for fast mode
dcycle = Default(dcycle, 20) # Decimation cycle
showdot = Default(Show, false) # true for troubleshooting; otherwise, false
gpu_id = Default(gpu_id, 0) # ID for the GPU to use
Debug = Default(Debug, false) # true for troubleshooting; otherwise, false

double = RIFEwrap(showdot ? Subtitle("***") : last, model=Fast ? 22 : 46, sc=false, gpuid=gpu_id)

# Remove comment from ShowMetrics, and change "return final" to "return test" to look at metrics in order to determine proper JumpThresh
src8 = ConvertBits(8, dither=-1, fulls=fs)
test = ShowMetrics(src8)

# Generate a white or black frame, depending on frame difference
Black = BlankClip( src8, Color_yuv=$000000, channels=0 )
White = BlankClip( src8, Color_yuv=$FFFFFF, channels=0 )

# This function returns a white clip whenever a big jump is detected; otherwise a black clip is returned
# Each YDiff must eliminate Ydiff=0 (duplicate) from moving average
BWMask = ScriptClip(src8, function [src8,JumpThresh,Black,White] () {
YDif1 = YDifferenceToNext(src8,2)
YDif1 = YDif1 < 0.2 ? YDifferenceToNext(src8,3) : YDif1

YDif2 = YDifferenceToNext(src8,1)
YDif2 = YDif2 < 0.2 ? YDifferenceToNext(src8,2) : YDif2

YDif3 = YDifferenceToNext(src8,-1)
YDif3 = YDif3 < 0.2 ? YDifferenceToNext(src8,-2) : YDif3

YDif4 = YDifferenceToNext(src8,-2)
YDif4 = YDif4 < 0.2 ? YDifferenceToNext(src8,-3) : YDif4

((YDif1 + YDif2 + YDif3 + YDif4) * 0.25 ) / (YDifferenceToNext(src8,-1) + 0.01) <= JumpThresh ? White : Black
})

# Generate the 2x framerate mask needed to choose the motion-estimated frames
themask = Interleave(Black,trim(BWMask,1,0)).ConvertBits(BitsPerComponent(source))

# Merge double framerate from original with motion-esimated frames, but only where there are jumps
# (i.e., original frames are used except at jump points)
ex_merge(Interleave(source,source), double, themask, luma=false, UV=3)

# Decimate half of all frames (set to twice the length of "normal" dup/drop cycle)
RequestLinear(clim=100)
dcycle = dcycle+dcycle%2
final = TDecimate(display=false, mode=1, cycleR=dcycle/2, cycle=dcycle, vfrDec=1, sdlim=0 )


return debug ? test : final }

#----------------
# This function displays the YDiff value that will be used for detecting big jumps
# Each YDiff must eliminate Ydiff=0 (duplicate) from moving average

function ShowMetrics (clip c, float "jumpthresh") {

ScriptClip(c, function [c] () {

YDif1 = YDifferenceToNext(2)
YDif1 = YDif1 < 0.2 ? YDifferenceToNext(3) : YDif1

YDif2 = YDifferenceToNext(1)
YDif2 = YDif2 < 0.2 ? YDifferenceToNext(2) : YDif2

YDif3 = YDifferenceToNext(-1)
YDif3 = YDif3 < 0.2 ? YDifferenceToNext(-2) : YDif3

YDif4 = YDifferenceToNext(-2)
YDif4 = YDif4 < 0.2 ? YDifferenceToNext(-3) : YDif4

YDiff = ((YDif1 + YDif2 + YDif3 + YDif4) * 0.25 ) / (YDifferenceToNext(-1) + 0.01)

Subtitle("Probability of frozen Frame= "+String(YDiff),y=26)
} )
Subtitle("JumpThreshold= "+String(jumpthresh),y=12)
}

[rgr]

1. A link would be useful.
2. RIFE has two parameters for detecting and handling scene changes: sc and sc1. The latter is probably even more useful.

[Lucky38]

Hi All,

i'm look help with issue i have got: Source file is HDR with DolbyVision prof 8.1 and when i do resize 2160p -> 1080p i have got strange "halo" on man's head
https://imgur.com/a/AMFxDq7

this is my avisynth call:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetMemoryMax()
SetCacheMode(0)
ConvertBits(16)
deep_resize(1920)
SMDegrain(mode="TemporalSoften", tr=2, thSAD=300, thSCD2 = 100, prefilter=0, contrasharp=false, limits=false, refinemotion=true, LFR=true, DCTFlicker=true, Chroma=true, Truemotion=false, Search=3, pel=1)
ex_unsharp(0.3,Fc=width()/1.5,safe=true) # Remove some of the dreamy look
ex_unsharp(0.8,Fc=width()*1.6,safe=true) # Extra fine sharpness
GradFun3plus(thr=0.35, radius=10, mask=2, thr_det=2, elast=2, smode=0, UV=3)
ConvertBits(10,dither=1)
Prefetch(8,12)

no idea why its happening....

edit:

This call (default falues from StaxRip) give me the same result:


ConvertBits(16)
Spline16Resize(1920, 804)
SMDegrain(tr=2, thSAD=300, prefilter=-1, contrasharp=true, refinemotion=true)
LSFmod(defaults="slow", strength=100, Smode=5, Smethod=3, kernel=11, secure=true, Szrp=16, Spwr=4, SdmpLo=4, SdmpHi=48, Lmode=4, overshoot=1, undershoot=1, Overshoot2=1, Undershoot2=1, soft=-2, soothe=true, keep=20, edgemode=0, edgemaskHQ=true, ss_x=1.50, ss_y=1.50, dest_x=1920, dest_y=804, show=false, screenW=1280, screenH=1024)
ConvertToStacked()
GradFun3(thr=0.5, radius=12, mode=6, smode=1)
ConvertFromStacked()
Prefetch(8)

[Guest]

Hi All,

i'm look help with issue i have got: Source file is HDR with DolbyVision prof 8.1 and when i do resize 2160p -> 1080p i have got strange "halo" on man's head
https://imgur.com/a/AMFxDq7

this is my avisynth call:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetMemoryMax()
SetCacheMode(0)
ConvertBits(16)
deep_resize(1920)
SMDegrain(mode="TemporalSoften", tr=2, thSAD=300, thSCD2 = 100, prefilter=0, contrasharp=false, limits=false, refinemotion=true, LFR=true, DCTFlicker=true, Chroma=true, Truemotion=false, Search=3, pel=1)
ex_unsharp(0.3,Fc=width()/1.5,safe=true) # Remove some of the dreamy look
ex_unsharp(0.8,Fc=width()*1.6,safe=true) # Extra fine sharpness
GradFun3plus(thr=0.35, radius=10, mask=2, thr_det=2, elast=2, smode=0, UV=3)
ConvertBits(10,dither=1)
Prefetch(8,12)

no idea why its happening....

edit:

This call (default falues from StaxRip) give me the same result:


ConvertBits(16)
Spline16Resize(1920, 804)
SMDegrain(tr=2, thSAD=300, prefilter=-1, contrasharp=true, refinemotion=true)
LSFmod(defaults="slow", strength=100, Smode=5, Smethod=3, kernel=11, secure=true, Szrp=16, Spwr=4, SdmpLo=4, SdmpHi=48, Lmode=4, overshoot=1, undershoot=1, Overshoot2=1, Undershoot2=1, soft=-2, soothe=true, keep=20, edgemode=0, edgemaskHQ=true, ss_x=1.50, ss_y=1.50, dest_x=1920, dest_y=804, show=false, screenW=1280, screenH=1024)
ConvertToStacked()
GradFun3(thr=0.5, radius=12, mode=6, smode=1)
ConvertFromStacked()
Prefetch(8)

I certainly wouldn't call that a "halo", looks like some kid has scribbled around his head with a pencil....strange.

It would be interesting if you could post a sample of this video, so it can be tried by others.

[Lucky38]

I certainly wouldn't call that a "halo", looks like some kid has scribbled around his head with a pencil....strange.

It would be interesting if you could post a sample of this video, so it can be tried by others.

this is the sample

https://mega.nz/file/QIgm0JyZ#NJIcrqNcB3TTsnoD7jjRA_lKTdLwgx8ot1k9VxNLoA4

edit/update:

Deep resize use only with this deep_resize(1920) gives the same issue. changing settings to default for x265 and use old version of it x265-3.5+156+14-df2e4c31e-.Mod-by-Patman.-x64-avx2-msvc1937.7z do not solve issue.

[Guest]

this is the sample

https://mega.nz/file/QIgm0JyZ#NJIcrqNcB3TTsnoD7jjRA_lKTdLwgx8ot1k9VxNLoA4

edit/update:

Deep resize use only with this deep_resize(1920) gives the same issue. changing settings to default for x265 and use old version of it x265-3.5+156+14-df2e4c31e-.Mod-by-Patman.-x64-avx2-msvc1937.7z do not solve issue.

I have downloaded the sample, and it certainly hasn't got many issues, and certainly no "scribble" line around the guy's head.

What movie is that ??

To be clear, what is it that you're trying to achieve with this conversion ??

Some degraining & resizing down to 1080p ??

What app(s) do you prefer to use ?? (You mentioned StaxRip)

[Lucky38]

I have downloaded the sample, and it certainly hasn't got many issues, and certainly no "scribble" line around the guy's head.

What movie is that ??

To be clear, what is it that you're trying to achieve with this conversion ??

Some degraining & resizing down to 1080p ??

What app(s) do you prefer to use ?? (You mentioned StaxRip)

hi,

this is andor s01e01

i would like to do some degraining & resizing down to 1080p and sharpening using Staxrip.

when i do degrain, sharpening for 2160p this "scribble" is little visible when you go frame by frame.... When you encode with resize only looks more visible...

I use x265 medium in crf 18-20 (with custom settings) for both 2160/1080 but when i set crf 14 for 1080 it looks better..

have you downscale it during your test?

edit:

with LFR=false, DCTFlicker=false i see it when playing frame by frame but it is less visible compare to LFR=true, DCTFlicker=true

edit 2:

this setting --rskip 2 --rskip-edge-threshold 2 from x265 also highight this problem... without it is less noticable

[Guest]

edit:

with LFR=false, DCTFlicker=false i see it when playing frame by frame but it is less visible compare to LFR=true, DCTFlicker=true

edit 2:

this setting --rskip 2 --rskip-edge-threshold 2 from x265 also highight this problem... without it is less noticable

Having a closer look at your sample, I don't think much needs to be done to it, some of those "calls" are possibly not required, and it's messing up what should be a simple degrain & resize.

I will have a play with it in a few days...

[Boulder]

ConvertToStacked()
GradFun3(thr=0.5, radius=12, mode=6, smode=1)
ConvertFromStacked()
I don't think those Convert.. calls are needed. Use Dogway's GradFun3Plus instead of the old GradFun3.

[Lucky38]

I don't think those Convert.. calls are needed. Use Dogway's GradFun3Plus instead of the old GradFun3.


hi,

yes i know... i used old one to see if this issue could be related to some filters.... normally i use only Dogway's filters....

this is my last call and results:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetMemoryMax()
SetCacheMode(0)
ConvertBits(16)
deep_resize(1920)
SMDegrain(tr=2, thSAD=350, thSCD2 = 100, prefilter=0, contrasharp=false, rfilter=3, LFR=false, DCTFlicker=false)
ex_unsharp(0.3,Fc=width()/1.5,safe=true) # Remove some of the dreamy look
ex_unsharp(1.0,Fc=width()*2.0,safe=true) # Extra fine sharpness
GradFun3plus(thr=0.35, radius=10, mask=2, thr_det=2, elast=2, smode=0, UV=3)
ConvertBits(10,dither=1)
Prefetch(8,12)

https://mega.nz/file/hEYkFYKR#HVMjjn8RtME8fmv9smUbphvvi7Un07B7etJFtoosrxQ

x265:

--crf 18 --output-depth 10 --profile main10 --rd 4 --refine-mv 1 --aq-mode 3 --vbv-bufsize 17500 --vbv-maxrate 18000 --subme 5 --me star --max-merge 5 --weightb --bframes 6 --rc-lookahead 80 --ref 6 --min-keyint 23 --no-open-gop --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1)" --hdr10 --colorprim bt2020 --colormatrix bt2020nc --transfer smpte2084 --range limited --chromaloc 2 --dolby-vision-profile 8.1 --dolby-vision-rpu "E:\_temp\HDRDVmetadata.rpu" --repeat-headers --aud --hrd --limit-sao --selective-sao 4 --no-strong-intra-smoothing

and avs+ [INFO]: AviSynth+ 3.7.3 (r4003, 3.7, x86_64)

[Boulder]

I think you should try removing the filters one by one to see which one triggers what you see.

[Lucky38]

I think you should try removing the filters one by one to see which one triggers what you see.

i have alredy do in this way...

as i stated few post above during resizing to 1080p this issue accures more ( noticable ) than in 2160p...

strange think is that this issue is present only for this actor head...
next actor does not have this issue closly in his head....

this is my observation in his head motion...

[Boulder]

One thing is to change the resizer. Just try a regular Spline36Resize to see if it has the same effect. It's possible that the resampling kernel selected by deep_resize is not good for your source.

[Lucky38]

One thing is to change the resizer. Just try a regular Spline36Resize to see if it has the same effect. It's possible that the resampling kernel selected by deep_resize is not good for your source.

thx for sugestion... :)

x265 settings are the same like i have posted above...
my standard avisynth call with replaced resizer:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetMemoryMax()
SetCacheMode(0)
ConvertBits(16)
Spline36Resize(1920, 804)
SMDegrain(tr=2, thSAD=350, thSCD2 = 100, prefilter=0, contrasharp=false, rfilter=3, LFR=false, DCTFlicker=false)
ex_unsharp(0.3,Fc=width()/1.5,safe=true) # Remove some of the dreamy look
ex_unsharp(1.0,Fc=width()*2.0,safe=true) # Extra fine sharpness
GradFun3plus(thr=0.35, radius=10, mask=2, thr_det=2, elast=2, smode=0, UV=3)
ConvertBits(10,dither=1)
Prefetch(8,12)

results:

https://mega.nz/file/INIWBCSK#ptokbQLZfxkzNX1CWHAv-OPsD8jLHm6SXh3bv1_1Bt4

i still see this issue....