TemporalDegrainV2

[ErazorTT]

Hi all,

I want to share an updated version of the script TemporalDegrain.

The reason for the update was to combine TemporalDegrain with the relevant parts of QTGMC:
Although MDegrain of MVTools with Didees contra-sharpening already performes great, the additional stage of motion compensated fourier denoising can do wonders.
Together with this, the original motion estimation is also much improved using the exceptional approach of QTGMC instead of the very mushy intermediate stream which was losing some vectors in sceenes with low contrast and diverging movement.

With this optional fourier denoising setting the result can be up to completely grainless, much better compressable and together with the optional dithering it is guaranteed to produce no banding, yielding a very natural look in total.

Here a comparison of a scene of s2e1 of Breaking Bad, starting with the original [505KB for the JPEG still]:
https://i.postimg.cc/18PsPjGz/org.jpg (https://postimg.cc/18PsPjGz)

v1.23: TemporalDegrain(degrain=2) [310KB for the JPEG still]
https://i.postimg.cc/6yCtkXGS/v123-tr2.jpg (https://postimg.cc/6yCtkXGS)

v2.0: TemporalDegrain2(degrainTR=2,postFFT=3,postSigma=3) [216KB for the JPEG still]
https://i.postimg.cc/Dm97pZmL/v2-tr2-pf3-ps3-pd-1.jpg (https://postimg.cc/Dm97pZmL)
Compared to V1.23 the out-of-focus regions of V2.0 have almost no remaining grain anymore (can be even better seen on the moving picture) helping compressablity (see the JPEG file sizes as a proxy).
The in-focus regions however have still all details of the original frame.

And now the comparison of why I think it was time for an improved motion estimation over v1 of TemproralDegrain.
original from Breaking Bad s1e1, the camera moves following the car:
https://i.postimg.cc/YhVMBphg/9895-org.jpg (https://postimg.cc/YhVMBphg)

v1.23: TemporalDegrain(degrain=2)
https://i.postimg.cc/ThNXnRjS/9895-v123.jpg (https://postimg.cc/ThNXnRjS)
The motion of the low contrast tarmac is not captured well and thus the details are being washed away.

v2.10: TemporalDegrain2(degrainTR=2)
https://i.postimg.cc/zb6R0QmY/9895-v210.jpg (https://postimg.cc/zb6R0QmY)
More of the details of the tarmac are preserved.

In this thread further down are some movie samples: here (https://forum.doom9.org/showthread.php?p=1855447#post1855447)
I have also made some performance measurements: here (https://forum.doom9.org/showthread.php?p=1856673#post1856673)

Greets,
enjoy!

Changelog:

Dec 20, 2021: v2.3.4 (if you ever had a reason to use something else than postFFT 0, 1 or 2 try again now!)
- dithering is delayed to after contraSharpending which increases quality of dithering, decreasing banding and noise (postDither=2), old behaviour is regained with postDither=1
- postDither argument has been inverted! [new postDither = (-1) * old postDither] <--- if you ever explicitly set the postDither argument, read this line

Dec 21, 2021: v2.4.0 (This and later releases need AviSynth 3.7.1+)
- add BM3D_CPU & BM3D_CUDA (based on BM3D prefilter of Dogway's SMDegrain) and mods by kedautinh12 (Aug 12 - Dec 19)

Dec 21, 2021: v2.4.1
- small speed increase for BM3D (thanks to kedautinh12)

Jan 05, 2022: v2.4.2
- allow enabling or disabling of chroma and luma filtering for BM3D (thanks to kedautinh12)
- allow denoising on different planes at the two stages (degrainPlane vs postPlane)

Feb 15, 2022: v2.4.3
- add limit r to 3 when CUDA=true for BM3D (based on BM3D prefilter of Dogway's SMDegrain) and mods by kedautinh12
- add preset for BM3D (based on BM3D prefilter of Dogway's SMDegrain) and mods by kedautinh12

Apr 05, 2022: v2.5.0
- allow distinct postFFT and postSigma for luma and chroma

May 01, 2022: v2.6.0
- clean chroma more by also using the first degrain step
- tweak scene change detection factors

May 02, 2022: v2.6.1
- fix grainLevelSetup which was broken in previous release

May 10, 2022: v2.6.2
- some fixes and cleanup

Jun 06, 2022: v2.6.3
- increase possible range of grainLevel
- allow for multiple usages of this script

Feb 11, 2023: v2.6.4
- always undot before postFFT stage, increasing FFT efficiency by quite a bit when degrain was disabled
- mention suggested settings inside the script file

Feb 28, 2023: v2.6.6
- cleaning chroma only in one step, to ameliorate the chroma shift bug in mvtools MDegrain

Jan 14, 2024: v2.6.7
- forward device_type and device_id to KNLMeansCL

Link to newest version: >here (https://drive.google.com/file/d/1waGNgIdWx8hq1Ye7ejEJ_pKw6_lXMy2g/view?usp=drive_link)<
All current and old versions can be downloaded: >here (https://drive.google.com/drive/folders/1flOcKBNn_ozvK0D1xgGo0lJ6iTk7EhW9?usp=sharing)<

[tormento]

I want to share an updated version of the script TemporalDegrain.
I will try ASAP and tell you results.

You did a little mistype in the comments:
# KNLMeansCLL: https://github.com/Khanattila/KNLMeansCL/releases #

I am a bit confused too about the role of KNLMeansCL in the script. You state as optional but I can't see any knob or boolean to use it, even if I see trace of it in the code.

I am a bit puzzled why you use FFT3DFilter and FFT3DGPU and not only one of them.

I'd like also to know if the script is high bitdepth aware or internally working in high bit precision or 8 bit only.

I humbly suggest to use thumbnails for the images, not to send to hell thread formatting :)

[johnmeyer]

I've tried a lot of noise reduction and degraining plugins and scripts. You really cannot tell much from static shots because many of these approaches can cause really weird artifacts that can only be seen when you watch the resulting video. This is because you sometimes get correlation between grain in adjacent frames which results in really weird alignment of some of the residual grains, as well as other artifacts, none of which are apparent in a single frame.

So, it would be useful to have a side-by-side before/after video.

[ErazorTT]

Thanks a lot for the quick feedback!! :thanks:


You did a little mistype in the comments:

Oh I will correct that.


I am a bit confused too about the role of KNLMeansCL in the script. You state as optional but I can't see any knob or boolean to use it, even if I see trace of it in the code.

Yeah, right I forgot to mention that in the file. It is being set by postFTT=4.


I am a bit puzzled why you use FFT3DFilter and FFT3DGPU and not only one of them.

I was asuming FFT3DGPU would be a faster version of FFT3DFilter but if I am not mistaken currently only FFT3DFilter is still maintained, thus I though to leave the decission to the user.


I'd like also to know if the script is high bitdepth aware or internally working in high bit precision or 8 bit only.

I have made some of the necessary changes to the inner working as a first step to supporting high bitdepth but I am not there yet. Thats what I plan to do as a next step.


I humbly suggest to use thumbnails for the images, not to send to hell thread formatting :)

Let me see if I can figure out how to do that...

...it would be useful to have a side-by-side before/after video.
Yes very true, I will prepare some samples

[StainlessS]

Let me see if I can figure out how to do that...
PostImage.org allows anonymous upload, but also easy to make account.
Below, HotLink for forum, and then Thumbnail for forum below that.

https://i.postimg.cc/y6nn9NCr/Post-Image.jpg (https://postimages.org/)

https://i.postimg.cc/hhz9Rcj9/Post-Image.jpg (https://postimg.cc/hhz9Rcj9)

[ErazorTT]

PostImage.org allows anonymous upload, but also easy to make account.


Awesome :thanks:

[tormento]

Awesome :thanks:

I use lensdump too.

[Forteen88]

Thanks! Is this script of yours also great against "dancing grain"?
I've noticed that I can barely stand "dancing grain" in videos anymore :P
Oh, I remember that the movie "The Good, the Bad and the Ugly" Blu-ray had really much annoying grain, I could barely concentrate on the movie.
EDIT: But this does not mean that I hate all grain. I can accept a bit of grain if it's not too much!

[hello_hello]

Interesting.....

For a long time QTGMC has been my "go to" noise filter. Not that it's perfect, as being a de-interlacer it can sometimes create unwanted side effects "normal" denoising scripts don't, but where there's movement it's blurring to noise removal ratio tends to be pretty good. Only the other day I found myself wondering how hard it'd be to modify QTGMC to remove the de-interlacing completely for progressive video, and if it was possible, would it adversely effect it's ability to denoise.

Anyhow..... for a quick and very unscientific comparison. The "original video" is the script output with only resizing applied. The filtered screenshots were taken after encoding with x264, CRF18, Preset Slower(ish). I'm not sure why I did it that way, but I guess ultimately it's all about how the encoded version looks.

Thumbnails so as not to upset the scrolling police (and because it is annoying). It looks like you need to click on a thumbnail to open an image on the PostImage site, then right click and select "view image" for the full size version.

Screenshot 1. The camera was panning down a little. The playing card top/left shows the most detail difference.
Screenshot 2 was static.
Screenshot 3 had lots of movement. The stripes on the guy's shirt would be typical noise removal victims.

Edit: Whoops. The first three screenshots were off by a frame relative to the others. They're fixed.


Original 1080p video resized to 720p.
Spline36Resize(1280,536)

https://i.postimg.cc/Mntvvfvs/No-Filtering-A.png (https://postimg.cc/Mntvvfvs)

https://i.postimg.cc/K3nYFR6D/No-Filtering-B.png (https://postimg.cc/K3nYFR6D)

https://i.postimg.cc/WDS6Nywy/No-Filtering-C.png (https://postimg.cc/WDS6Nywy)


Spline36Resize(1280,536)
QTGMC(InputType=1, EzDenoise=1.5)
GradFun3()

https://i.postimg.cc/MMT0vYsp/QTGMC-A.png (https://postimg.cc/MMT0vYsp)

https://i.postimg.cc/hXL1wvzc/QTGMC-B.png (https://postimg.cc/hXL1wvzc)

https://i.postimg.cc/cr8mRXdK/QTGMC-C.png (https://postimg.cc/cr8mRXdK)


Spline36Resize(1280,536)
TemporalDegrainV2()
GradFun3()

https://i.postimg.cc/LhWDgrFK/Temporal-Degrain2-A.png (https://postimg.cc/LhWDgrFK)

https://i.postimg.cc/dkHBBf7C/Temporal-Degrain2-B.png (https://postimg.cc/dkHBBf7C)

https://i.postimg.cc/cgbRY8jM/Temporal-Degrain2-C.png (https://postimg.cc/cgbRY8jM)


Spline36Resize(1280,536)
TemporalDegrain()
GradFun3()

https://i.postimg.cc/qgNXrjhm/Temporal-Degrain-A.png (https://postimg.cc/qgNXrjhm)

https://i.postimg.cc/3y3FHhmp/Temporal-Degrain-B.png (https://postimg.cc/3y3FHhmp)

https://i.postimg.cc/5XLsVpGc/Temporal-Degrain-C.png (https://postimg.cc/5XLsVpGc)

[ErazorTT]

I updated the first post to include a comparison concerning the motion estimation! Since this was one of the main driving points I figured it would be good to show.


Screenshot 1. The camera was panning down a little. The playing card top/left shows the most detail difference.
Screenshot 2 was static.
Screenshot 3 had lots of movement. The stripes on the guy's shirt would be typical noise removal victims.


Hm QTGMC yeilds better results for 1 and 3. I wonder why... What version of QTGMC were you using?
Could you please try to run again with version 2.0.1 and play with options meBlksz=8/16 and/or meTM=true/false for TemporalDegrain2?
(Use the new updated version 2.0.1 from the first post. With the function renamed to TemporalDegrain2 it should also be easier to compare to v1)

[ErazorTT]

So, it would be useful to have a side-by-side before/after video.

Here you have the motion pricture you requested. I used x264 with crf 16 at "Very Slow" for all three:
Original (https://drive.google.com/open?id=1VUYt0i2FvHI-rlpy3tJV2cDSFk3WwbVV)
TD1.23 (https://drive.google.com/open?id=1qloMD42hR8rJIt-TvURx7pv-iGuVWGdb): TemporalDegrain(degrain=2)
TD2.10 (https://drive.google.com/open?id=1YVCv6yltEcWWpfby5ePGI40jq--9OJC5): TemporalDegrain2(degrainTR=2,postFFT=3,postSigma=3,postDither=-1)

Be sure to actually download the files and do not just watch the preview in the browser! The quality of the browser preview is miserable..

... Is this script of yours also great against "dancing grain"?

Yes you should be able to go from "mostly gone" to "OMG WFT, how is that even possible that a movie looks that clean" :D
Look at the files in this post, the grain is gone.

[Taurus]

@ErazorTT:
Please upload your Temporaldegrain2.zip to a filehoster.
It can take days, weeks or months for "Attachments Pending Approval" :D
Or just show the avsi in quotes here in this thread.
Thank you.

[ErazorTT]

@Taurus
Great you made me aware of that! I just updated the first post accordingly. I wonder however why the attachment could be downloaded right after I opened the thread... :confused:

[tebasuna51]

If you modify the first post I can't know when I need approve the attachment, sorry.
Approved now.

I only read new post.

[ErazorTT]

@tebasuna51: I have seen in other threads that this is the way people seem to operate, namely having the first post up to date. What would then be the best way to update the attachments? Do other let you know that they want something approved?

[tebasuna51]

When avsi text is bigger than 16000 chars (like TemporalDegrain2.avsi is) can't be included like text in the post, then you can use:

1) Pastebin (the user can read the source before download it)

2) Other upload free sites: DriveGoogle, Mediafire, Sendspace,... (like you make here)

3) If attach please make a new post with something like:

"New version X.Y attached in first post, please approve it"

[hello_hello]

What version of QTGMC were you using?

QTGMC 3.357s.


Could you please try to run again with version 2.0.1 and play with options meBlksz=8/16 and/or meTM=true/false for TemporalDegrain2?
(Use the new updated version 2.0.1 from the first post. With the function renamed to TemporalDegrain2 it should also be easier to compare to v1)

I didn't bother uploading screenshots with TemporalDegrain2(meTM=true) as the blurring always increased. It appears to have been true for the last version of the script. Were there any other changes aside from making meTM=false the default? It seems to be better now.

Two of the screenshots are the same frames as before, although this time the screenshots are taken directly from the script output and I increased QTGMC's noise removal a bit as I think it had an advantage there.

The new screenshot is of Val Kilmer's face as he was moving a little. Often the blurring of detail on someone's skin increases dramatically when they move, but it seems to be on a par with QTGMC now. There's a halo above the brim of his hat on the left side. It's in the source but largely hidden by noise. If there's an existing halo, QTGMC sometimes enhances it more than I'd like. TemporalDegrain2 enhanced it too, but so far, not quite as much.

QTGMC 3.357s takes functionality from SMDegrain to expand the levels to full range. I think it's only used for the motion search. The idea is to make it more accurate, but I don't know how much difference it makes. Any thoughts there?

Rather than upload 15 screenshots and post thumbnail links, here's a zip file.

Screenshots.zip (https://bayfiles.com/u8733ajcb0/Screenshots_zip) (13.1MB)

[StainlessS]

Another moderator suggested using "Report Post", to report where new attachment requires approval,
Report Post is found below avatar of the offending post as Red triangle with ! symbol inside.

[ErazorTT]

Were there any other changes aside from making meTM=false the default?

Setting truemotion to false was the only functional change.


It seems to be better now.

Thats really awesome! I pretty much forgot that truemotion switch in MVTools. So, huge thanks for you screenshots. Looking at those and comparing back and forth with the ones from QTGMC somehow reminded me of that again.


QTGMC 3.357s takes functionality from SMDegrain to expand the levels to full range. I think it's only used for the motion search. The idea is to make it more accurate, but I don't know how much difference it makes. Any thoughts there?

Hm I will have to analyze that. Right off the top of my head I do not know what exactly you mean. I will look into the code and come back if I see something.

[hello_hello]

Hm I will have to analyze that. Right off the top of my head I do not know what exactly you mean. I will look into the code and come back if I see something.

It expands levels from TV range to PC range for the MSuper clip. I don't know how much difference it makes. Have a look under line #187 here.

https://pastebin.com/u1xsPLwK
# Default Auto-Prefilter - Luma expansion TV->PC (up to 16% more values for motion estimation)

Maybe now I understand why I've always thought SMDegrain and other mvtools2 based denoising scripts blur too much when there's motion. A quick look at the SMDegrain script indicates TrueMotion is disabled by default for resolutions above standard definition (although it still blurs more than QTGMC), and it's enabled by default for mvtools2 itself.
It's disabled by default for MCTemporalDenoise and MCTemporalDenoiseMod (MCTD), so maybe that's why they tend to blur less (from memory, I haven't used them for a while).
I hadn't played with the TrueMotion option myself until now.

Cheers.

[StainlessS]

Blurring (I believe) occurs where vectors are not so good and done to hide problems/errors.
This script function deliberately blurs bad areas and sharpens good areas, I use it one helluva lot, for almost every encode.
McDegrainSharp:- https://forum.doom9.org/showthread.php?p=1737045#post1737045

EDIT: I usually use Frames=1(default, EDIT: well usually all defaulted).

EDIT:

Function MCDegrainSharp(clip c, int "frames", float "bblur", float "csharp", bool "bsrch",bool "Precise") {
# From:- http://forum.doom9.org/showthread.php?p=1737045#post1737045
# Based on MCDegrain By Didee, http://forum.doom9.org/showthread.php?t=161594
# Also based on DiDee observations in this thread: http://forum.doom9.org/showthread.php?t=161580
# "Denoise with MDegrainX, do slight sharpening where motionmatch is good, do slight blurring where motionmatch is bad"
# In areas where MAnalyse cannot find good matches, the blur() will be dominant.
# In areas where good matches are found, the sharpen()'ed pixels will overweight the blur()'ed pixels
# when the pixel averaging is performed.
#

[gispos]

The code uses Undot() but is not specified in the required plugins.
Is there an x64 version of Undot.dll?
I just deleted the line with Undot() :)

thanks

[ErazorTT]

@gispos

yes, right thanks for spotting that!
I know that there is a 64bits undot.dll coming with the 64bit MeGui. Which you can get here (https://sourceforge.net/projects/megui/files/megui-test/). But I do not know where they have that from, I would guess they have compiled it themselves. Or does someone know where to get a 64bit undot.dll from?
Anyways, I have put the call to undot after a check that this function actually exists using FunctionExists. Checkout the newest version 2.0.2.

[ChaosKing]

Undot == RemoveGrain(mode=1), just replace it

[ErazorTT]

@ChaosKing
that was quick and easy, great!

==> checkout new version 2.0.3

[hello_hello]

Blurring (I believe) occurs where vectors are not so good and done to hide problems/errors.
This script function deliberately blurs bad areas and sharpens good areas, I use it one helluva lot, for almost every encode.
McDegrainSharp:- https://forum.doom9.org/showthread.php?p=1737045#post1737045

I added the TrueMotion argument to MCDegrainSharp where appropriate so I could compare the result with Truemotion enabled and disabled. I don't know if other arguments should have different defaults when it's disabled, but it did make a difference. Not so much for the first frame from post #9, probably because the McDegrainSharp defaults don't remove as much noise as TemporalDegrain does by default, however for the third frame disabling TrueMotion seems like an improvement.

Original
https://i.postimg.cc/XpDnbSrw/3-original.png (https://postimg.cc/XpDnbSrw)


MCDegrainSharp(TrueMotion=false)
https://i.postimg.cc/sv23qDgj/3-false.png (https://postimg.cc/sv23qDgj)


MCDegrainSharp(TrueMotion=true)
https://i.postimg.cc/8sNpdb8r/3-true.png (https://postimg.cc/8sNpdb8r)

As a side note, I assume not too many people are using the FastDegrain script. The version here (http://avisynth.nl/images/FastDegrain.avs) (there's a link for it at the bottom of the TemporalDegrain page (http://avisynth.nl/index.php/Temporal_Degrain)), has an incorrect list of required plugins, the "overshoot=oshot" argument for the LimitedSharpenFaster function should be "overshoot=oshoot", and the MDegrain functions don't include the thSAD option.
The only other versions of the script I could find are here (https://forum.doom9.org/showthread.php?p=1368199#post1368199) and they're the same.

[StainlessS]

disabling TrueMotion seems like an improvement.

That is a surprise, TrueMotion = true has been MvTools default since v1.4.10.
As TrueMotion is a group setting for some other args, might be interesting to see what Zorr's Avisynth Optimizer thing makes of it (altering individual args).
TemporalDegrain perhaps has higher frame range than McDegrainSharp which uses only 1 frame range by default[EDIT: Actually 2], I like only
a light touch and so am usually happy with single frame range.

YouTube DarkHorse musvid clip is quite amazing video, but adjusting levels to produce 16->235 (think was maybe ~16->255), and applying
McDegrainSharp(frames=1) and NonlinUSM(z=3, pow=1.1, str=0.25, rad=9) or thereabouts produced a clip that knocked the socks off
the YT effort, but demands about 50% higher bitrate than original. (I think I may also have added a very light FFT3DFilter(sigma=1.5) or thereabouts after
the degrain).

Wonder how TemporalDegrain would fair in comparison.

[ErazorTT]

That is a surprise, TrueMotion = true has been MvTools default since v1.4.10.
In QTGMC it is however disabled by default. so perhaps due to the same reason...

[Groucho2004]

That is a surprise, TrueMotion = true has been MvTools default since v1.4.10.
Didée (https://forum.doom9.org/showthread.php?p=1407409&highlight=truemotion#post1407409) apparently was never a big fan of this parameter in a denoising context.

[StainlessS]

And would HD resolution in this case be as anything with width > 1100 or height > 600 as sort of agreed upon in another thread.
Any argument there.

EDIT: Changed '>' to '>=' above.
EDIT: NOPE, had it right the first time, width > 1100 or height > 600

EDIT: And larger block size be about 24 and above.

[hello_hello]

That is a surprise, TrueMotion = true has been MvTools default since v1.4.10.

Best as I can tell QTGMC uses the default values for options changed by TrueMotion when TrueMotion=true.
When TrueMotion=false two options are set to values other than the MVTools2 defaults. They're lambda and pnew.

I added them to the MCDegrainSharp script but the difference is quite small, and after looking at a bunch of frames I decided the MVTools2 defaults were probably better, at least for MCDegrainSharp. I'll try the same with TemporalDegrain2 later.

Anyhow... here's a version of MCDegrainSharp with TrueMotion disabled. The lambda and pnew defaults when TrueMotion=false are easy to change if you want to try them yourself.

# ========== MCDegrainSharp =====================================================
#
# From: http://forum.doom9.org/showthread.php?p=1737045#post1737045
# Based on MCDegrain By Didee:
# http://forum.doom9.org/showthread.php?t=161594
# Also based on Didee observations in this thread:
# http://forum.doom9.org/showthread.php?t=161580
# Denoise with MDegrainX, do slight sharpening where motionmatch is good,
# do slight blurring where motionmatch is bad.
# In areas where MAnalyse cannot find good matches, the blur() will be dominant.
# In areas where good matches are found, the sharpen()'ed pixels will
# overweight the blur()'ed pixels when the pixel averaging is performed.
#
# 3 Sept 2015 - Mod by StainlessS to add Precise.
# 24 Oct 2018 - Mod by Hello_Hello to disable TrueMotion by default.
# https://forum.doom9.org/showthread.php?p=1855907#post1855907
#
# ===============================================================================

function MCDegrainSharp(clip c, int "frames", float "bblur", float "csharp", bool "bsrch", bool "precise", \
bool "truemotion", int "lambda", int "pnew") {

frames = default(frames, 2)
bblur = default(bblur, 0.6)
csharp = default(csharp, 0.6)
bsrch = default(bsrch, true)
precise = default(precise, false) # Use MRecalculate
truemotion = default(truemotion, false)
bs = (c.width() > 960) ? 16 : 8
c2 = c.blur(bblur)

# Uncommenting the two lines below results in the same truemotion settings as QTGMC when truemotion=false
# lambda = default(lambda, (truemotion ? 1000 : 100 ) * BSize * BSize / 64)
# pnew = default(pnew, truemotion ? 50 : 25)

# Only 1 level required for sharpened Super (not MAnalyse-ing)
super = (frames > 0) ? (bsrch ? c2.MSuper(pel=2, sharp=1) : c.MSuper(pel=2, sharp=1)) : nop()
super_rend = (frames > 0) ? (c.sharpen(csharp).MSuper(pel=2, sharp=1, levels=1)) : nop()

bvec3 = \
(frames > 2) ? MAnalyse(super, isb=true, delta=3, blksize=bs, overlap=bs/2, \
truemotion=truemotion, lambda=lambda, pnew=pnew) : nop()
bvec2 = \
(frames > 1) ? MAnalyse(super, isb=true, delta=2, blksize=bs, overlap=bs/2, \
truemotion=truemotion, lambda=lambda, pnew=pnew) : nop()
bvec1 = \
(frames > 0) ? MAnalyse(super, isb=true, delta=1, blksize=bs, overlap=bs/2, \
truemotion=truemotion, lambda=lambda, pnew=pnew) : nop()
fvec1 = \
(frames > 0) ? MAnalyse(super, isb=false, delta=1, blksize=bs, overlap=bs/2, \
truemotion=truemotion, lambda=lambda, pnew=pnew) : nop()
fvec2 = \
(frames > 1) ? MAnalyse(super, isb=false, delta=2, blksize=bs, overlap=bs/2, \
truemotion=truemotion, lambda=lambda, pnew=pnew) : nop()
fvec3 = \
(frames > 2) ? MAnalyse(super, isb=false, delta=3, blksize=bs, overlap=bs/2, \
truemotion=truemotion, lambda=lambda, pnew=pnew) : nop()

# If Precise, then recalculate on Prefiltered (blurred) Super (NOT the sharpened render super)

bvec3 = \
(frames > 2) ? (!Precise ? bvec3 : \
MRecalculate(super, bvec3, blksize=bs/2, overlap=bs/4, thSAD=100, \
truemotion=truemotion, lambda=lambda, pnew=pnew)) : nop()
bvec2 = \
(frames > 1) ? (!Precise ? bvec2 : \
MRecalculate(super, bvec2, blksize=bs/2, overlap=bs/4, thSAD=100, \
truemotion=truemotion, lambda=lambda, pnew=pnew)) : nop()
bvec1 = \
(frames > 0) ? (!Precise ? bvec1 : \
MRecalculate(super, bvec1, blksize=bs/2, overlap=bs/4, thSAD=100, \
truemotion=truemotion, lambda=lambda, pnew=pnew)) : nop()
fvec1 = \
(frames > 0) ? (!Precise ? fvec1 : \
MRecalculate(super, fvec1, blksize=bs/2, overlap=bs/4, thSAD=100, \
truemotion=truemotion, lambda=lambda, pnew=pnew)) : nop()
fvec2 = \
(frames > 1) ? (!Precise ? fvec2 : \
MRecalculate(super, fvec2, blksize=bs/2, overlap=bs/4, thSAD=100, \
truemotion=truemotion, lambda=lambda, pnew=pnew)) : nop()
fvec3 = \
(frames > 2) ? (!Precise ? fvec3 : \
MRecalculate(super, fvec3, blksize=bs/2, overlap=bs/4, thSAD=100, \
truemotion=truemotion, lambda=lambda, pnew=pnew)) : nop()

return (frames == 0) ? c : \
(frames == 1) ? c2.MDegrain1(super_rend, bvec1, fvec1, thSAD=400) : \
(frames == 2) ? c2.MDegrain2(super_rend, bvec1, fvec1, bvec2, fvec2, thSAD=400) : \
c2.MDegrain3(super_rend, bvec1, fvec1, bvec2, fvec2, bvec3, fvec3, thSAD=400) }

# ===============================================================================

[zorr]

As TrueMotion is a group setting for some other args, might be interesting to see what Zorr's Avisynth Optimizer thing makes of it (altering individual args).
Sure! The challenge is coming up with an objective and reliable way to measure the quality of the grain removal. I gave it some thought and came up with something that may work...

So first we need to be able to calculate the "graininess" of the frame. Some googling and I found this (https://stackoverflow.com/a/25436112), which looks like something that is possible to implement in Avisynth using MaskTools. I'm not sure about how to sum the pixel values after convolution though, perhaps by doing recursive bilinear downscaling in 16bit or 32bit per pixel colorspace in order not to lose too much precision. And hopefully there's a way to read a single pixel's color value into a script variable.

We also need another criteria, if we only measure graininess and consider it bad then the optimizer is going to find the blurriest image possible... :) We could measure the maximum absolute pixel color difference to the original unprocessed frame based on the idea that the degraining should not make a picture that has large deviations from the original.

With these two measurements the optimizer can create a two dimensional pareto front. After the optimizer is done a human would see which of the pareto front members is the best compromise. That would be a fun experiment to try... can anyone help me with the graininess measurement?

[StainlessS]

Unfortunately RT_Stats is only 8 bit and only really for Luma Y or RGB, I have no idea how 16/32 bit works in Avs+, never touched the stuff.
No idea how to force convert to some kind of 16->8 Least Significant Byte, Most significant Byte format so that RT could be used.

EDIT: Here are available COMBINED functions for Y, each func available as individual function as well. [down to single 8 bit pixel]


RT_Ystats(clip c,int "n"=current_frame,int "delta"=0,int "x"=0,int "y"=0,int "w"=0,int "h"=0,bool "interlaced"=false,
float "threshold"=0.0,int "lo"=128,int "hi"=lo,int "flgs"=255,string "prefix"="YS_",
float "mu"=0.0,int "d"=1,int "p"=1,int "u"=1, int "Matrix"=(Width>1100||Height>600?3:2),clip "mask"=NOT_USED,int "MaskMin"=128,"MaskMax"=255)
Returns multiple results as for above single frame Luma sampling functions as Local Variables (prefixed with the prefix string arg).
The args up to "interlaced", are as for all other clip functions, "threshold" used only for "RT_YPlaneMin", "RT_YPlaneMax" and
"RT_YPlaneMinMaxDifference" equivalent routines with same functionality.
"lo" and "hi" are used only with the "RT_YInRange" equivalent routine with same functionality.
"mu" and "d" and "p" and "u" are used only with the "RT_YPNorm" equivalent routine with same functionality.
The new arg "Flgs" selects which results you want returned and the string "Prefix" that is prepended
to the returned Local variable names.
The actual return result is a copy of the flgs arg with any non valid bits reset, ie the Local variables that were set.
Local variables are NOT altered for any function not selected in flgs.
Returns 0 if no pixels found in search area of mask within MaskMin and MaskMax.

Flgs_Bit_Number Add_To_Flgs Equivalent_Function Local_Var_Set_Excluding_Prefix
0 1($01) RT_YPlaneMin() "yMin" (0->255)
1 2($02) RT_YPlaneMax() "yMax" (0->255)
2 4($04) RT_YPlaneMinMaxDifference() "yMinMaxDiff" (0->255)
3 8($08) RT_YPlaneMedian() "yMed" (0->255)
4 16($10) RT_AverageLuma() "yAve" (0.0->255.0)
5 32($20) RT_YPlaneStdev() "yStdev" (0.0->255.0)
6 64($40) RT_YInRange() "yInRng" (0.0->1.0)
7 128($80) RT_YPNorm() "yPNorm" (0.0->??? depends upon d and u)
RT_Ystats() allows you to inquire multiple results simultaneously, with not much more overhead than calling a single individual
routine, however, you should not select sub functions that you dont need as there may be an additional unnecessary overhead.
The Default flgs=255($FF) are all bits set and so sets ALL Local vars at once.
RT_Ystats(flgs=1+2+16) would set Local vars "YS_yMin", "YS_yMax" and "YS_yAve" for full frame current_frame.

In addition to above Local Variables, RT_YStats() sets an int Local variable (where default prefix) of "YS_PixelCount" being
the number of pixels in mask area X,Y,W,H between MaskMin and MaskMax inclusive, or pixels scanned in X,Y,W,H area where mask
not used.
NOTE, If no valid flg bits set (eg $FF00), then returns 0, YS_PixelCount and all other variables remain as before call.
Assuming some valid flg bits, if no valid pixels were found in mask then function returns 0, and only YS_PixelCount would be set
to 0, no other variables are touched (remain as before call, undefined if not previously existing).
Example usage:
ScriptClip("""
got = RT_Ystats(c,mask=Mask,flgs=$10) # AverageLuma
(got != 0) ? RT_debug("AverageLuma = " + String(YS_yAve) + "PixelCount = " + String(YS_PixelCount)) : RT_Debug("NO VALID PIXELS FOUND")
""")


RT_YPNorm, is a weird one as requested by martin53, [below is the individual routine, also available in above combined results routine]

RT_YPNorm(clip c,int "n"=current_frame,int "delta"=0,int "x"=0,int "y"=0,int "w"=0,int "h"=0,bool "interlaced"=false,
float "mu"=0.0,int "d"=1,int "p"=1,int "u"=1,int "Matrix"=(Width>1100||Height>600?3:2),clip "mask"=NOT_USED,int "MaskMin"=128,"MaskMax"=255)
Return int -1 if no valid pixels in Mask clip.
Returns FLOAT value greater or equal to 0.0, being the "Minkowski P-norm" (range depends upon values of 'd' and 'u') for frame(n+delta)
area x,y,w,h.
mu, Float, default 0.0 (0.0 -> 255.0)
d, int, default 1 (1 -> 255) # downscale
p, int, default 1 (1 -> 16) # power
u, int, default 1 (1 -> 255) # final upscale before returning result (experimental)
Formula is: sum_over_pixels[ ((pixel-mu)/d)^p ]^(1/p) * u
or in words: d and u are scaling aids. The differences between the pixel values and mu are scaled, taken to the power of p and added up
over the frame. The sum is taken to the p-th root and finally rescaled.
mu=0, d=1, p=1, u=1 yields the average.
mu=average, d=1, p=2, u=1 yields the standard deviation (uncorrected sample standard deviation).
Implemented as requested by Martin53 (thankyou). *** EXPERIMENTAL ***
http://en.wikipedia.org/wiki/P-norm#The_p-norm_in_finite_dimensions
http://en.wikipedia.org/wiki/Minkowski_distance


EDIT: Fastest will be RT_AverageLuma (even for single pixel, but with int result as float 0.0->255.0, ie no fractional part), as others create count arrays,
whereas RT_AverageLuma sums on-the-fly [same for combined RT_YStats where AverageLuma is sole requested result].

[ErazorTT]

@zorr: I guess the easiest AND most precise way would be to start with a very clean clip, add noise to it and use this as input for the denoiser. The output of the denoiser and the original ground truth are than be subtracted pixel by pixel. Finally all the pixel differences are summed frame by frame. The best denoiser setting will have smallest departure from the original.

For this to work there is thus no need for any measure of noise/grain. Just summing up the difference of all pixels in a frame gives the answer.

[StainlessS]

Good suggestion methinks.
Would Tears Of Steel be a good test source, with both live and CGI content.

Source from Avisynth Usage Forum Sticky, "Consolidated list of test video clip resources",
https://media.xiph.org/


We have a lossless version of the short film Tears of Steel. (17620 frames 2.40:1)

[ y4m 4k (67 GB compressed) ]
[ png 1920x800 (30 GB) ]
[ tiff 4k 16 bit (598 GB) ]

[ flac stereo (80 MB) | 5.1 surround (331 MB) ]

[ exr frames by scene (226 GB) | cleaned footage (330 GB) | raw footage (4 TB) ]

Bit big mind you. Could probably find shorter smaller sequence somewhere on net.

Some Lossy Compressed Versions, various compression / sizes:- https://mango.blender.org/download/
EDIT: Maybe someone already has big download and could spare a 30 second snippit for testing.

[VoodooFX]

And now the comparison of why I think it was time for an improved motion estimation over v1 of TemproralDegrain.
original from Breaking Bad s1e1, the camera moves following the car:
https://i.postimg.cc/YhVMBphg/9895-org.jpg (https://postimg.cc/YhVMBphg)

v1.23: TemporalDegrain(degrain=2)
https://i.postimg.cc/ThNXnRjS/9895-v123.jpg (https://postimg.cc/ThNXnRjS)
The motion of the low contrast tarmac is not captured well and thus the details are being washed away.

v2.03: TemporalDegrain2(degrainTR=2)
https://i.postimg.cc/yW8ywBq7/9895-v201.jpg (https://postimg.cc/yW8ywBq7)
More of the details of the tarmac are preserved.


Very nice overall improvement. Why v2.03 fails on this part?:

original vs v1.23 vs v2.03
https://images2.imgbox.com/be/ce/oImXS8ZF_o.png

[ErazorTT]

@VoodooFX
This one is tricky, since it results from the motion estimation I took from QTGMC. I tried to tweak the motion estimation in a way to improve the detection of moving fine detail as the rim in this example but without putting either the motion detection of big objects or the degraining/denoising at risk.

original, v1.23, v2.03, v2.10
https://i.postimg.cc/3JzS9RtZ/comp.jpg

As you can see v2.10 has gotten a little better when compared to v2.03 however it cannot match the detail of v1.23 in this case.
I would consider this issue a corner case, since there are a couple of factors driving this: the very fast movement of this detail, the total time the detail is visible and its size.

[VoodooFX]

Not the same as v1.23, but still huge improvement. Fast moving details not that important so better not to compromise with slow moving or static details.

[tormento]

Strangely enough I get the following error, both in VirtualDub2 and in Simple x264 launcher:
[2018-10-28][10:56:47] error: Script error: There is no function named 'ConvertToStacked'.
[2018-10-28][10:56:47] (D:/Programmi/Media/AviSynth+/plugins64/TemporalDegrain-2.1.1—ErazorTT.avsi, line 236)
My script:
SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\2_01 sacrificio del cervo sacro, Il\sacrificio.dgi")
CompTest(1)
TemporalDegrain2(degrainTR=4,postFFT=4,postSigma=3,postDither=-1)
Prefetch(6)

EDIT: solved.

[ErazorTT]

You will need Avisynth+ in a recent version.

[hello_hello]

Out of curiosity, which settings require Avisynth+? The defaults run fine on "classic" Avisynth.

[RieGo]

Very nice script. Well documented and easy to tune. nice job.
Thank you very much for this!

[StainlessS]

ErazorTT, report post #1 as having "waiting approval of attachment", or post on some file host eg PasteBin.
(or maybe this post will do it).

[tormento]

You will need Avisynth+ in a recent version.
Problem solved, now I have this:
[2018-10-29][18:16:26] error: ConvertToStacked: Input clip must be native 16 bit: YUV420P16, YUV422P16, YUV444P16, Y16 :p

[Taurus]

Out of curiosity, which settings require Avisynth+? The defaults run fine on "classic" Avisynth.
Here the same.
The only setting I could not get working was postFFT=4.
As far as I understand this will enable KNLMeansCL.
KNLMeansCL itself runs rockstable on this machine.
Groucho2004's AVSMeter silently crashes, preview on MPC-HC hangs and closes.
Virtualdub shows this:
https://i.postimg.cc/3R4NZTds/Crash.png (https://postimages.org/)

FFT3DGPU (aka postFFT=2) runs fine without any multithreading
in the script.
I think it's because I'm on avisynth 2.6.06 32bit and the script is calling for a stacked format.
But nevermind the only denoisers/degrainers I'm using are dfttest (aka postFFT=3) or FFT3DFilter (aka postFFT=1)
and they both are doing fine.
This was just for information and feedback.
Right now I'm struggeling with the settings compared to good ol TemporalDegrain.
I have used it quite a bit some years ago and made some templates of my favorit settings. But my memory is leaking about each knob and bells and whistles.
So I have to refresh my thinking and start a new.

Thanks for maintaining this wonderful script.
It saved my life a few times in the past ;):D

[ErazorTT]

@tormento, what are the exact parameters you are trying to use? This would help to figure out whats going on.

[ErazorTT]

@Taurus
Well I would actually suggest to not try to copy over the old setting used for TemporalDegrain v1.23, since the settings have changed considerably.
As a starting point I would use the recommended 5 step procedure together with the 5 parameters, which both are mentioned in the comments inside the script.
Only if one is willing to spend hours in testing should one start reviewing other settings. In which case however it would be great if people shared their findings!

[Taurus]

@Taurus
Well I would actually suggest to not try to copy over the old setting used for TemporalDegrain v1.23, since the settings have changed considerably.
As a starting point I would use the recommended 5 step procedure together with the 5 parameters, which both are mentioned in the comments inside the script.
Only if one is willing to spend hours in testing should one start reviewing other settings. In which case however it would be great if people shared their findings!

No,no,
I'm not copying the settings from old temporalgrain to v2!
I'm just comparing the final outcome of my old tweaked and approved temporalgrain settings with your suggested settings in new v2.
But because I forgot almost everything about good old temporalgrain, I have to rebuild a testing environment from scratch and start all over again :mad: .
But your attempt looks real promising.
Really appreciated.

[tormento]

@tormento, what are the exact parameters you are trying to use? This would help to figure out whats going on.
Here (https://forum.doom9.org/showthread.php?p=1856262#post1856262).

P.S: There is no reference to dfttest neither in the required plugins nor in the optional ones.

[Taurus]

Here (https://forum.doom9.org/showthread.php?p=1856262#post1856262).

P.S: There is no reference to dfttest neither in the required plugins nor in the optional ones.

You are right, dfttest is not mentioned in the top lines of the temporaldegrain2 script.
But a few lines down ErazorTT explains exactly what and why you should use for postFFT=3 (dfttest).
Just verified with process exlorer: dfttestdll and dither.dll are correctly loaded when postFFT=3 is enabled.
Maybe ErazorTT should update the dependency list a little.....

[ErazorTT]

@tormento
Oh I see. Yeah, that was a pretty stupid f*ck up on my side.. :rolleyes:
Please checkout new version 2.1.2 from first post!

Oh and btw using degrainTR=4 AND postSigma=3 is a very severe overkill.

[tormento]

Please checkout new version 2.1.2 from first post!
[2018-10-31][09:26:01] error: Script error: There is no function named 'Dither_convert_8_to_16'.
[2018-10-31][09:26:01] (D:/Programmi/Media/AviSynth+/plugins64/TemporalDegrain-2.1.2—ErazorTT.avsi, line 241)
[2018-10-31][09:26:01] (E:\in\2_01 sacrificio del cervo sacro, Il\sacrificio_4td.avs, line 17)
Please get rid of old dither tools as was done by SMDegrain :)
Oh and btw using degrainTR=4 AND postSigma=3 is a very severe overkill.
Just trying to do a comparison with
SMDegrain (tr=4, thSAD=400, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=false, plane=4, chroma=true)

Edit: tried to run under Simple x264 Launcher and results in a deadlock with Prefetch. Working (slow as hell) under VirtualDub. Tried again without prefetch under Simple x264 and I get something like 0.15 fps.

[ErazorTT]

[2018-10-31][09:26:01] error: Script error: There is no function named 'Dither_convert_8_to_16'.

The function Dither_convert_8_to_16 is not part of dither.dll but of dither.avsi, which can also be found in the same archive (http://ldesoras.free.fr/src/avs/dither-1.27.2.zip), you will need both files in you path.


Please get rid of old dither tools as was done by SMDegrain :)


Yes I am also no fan of this but as far as I see SMDegrain does still has this function call even in the newest version, so I do not know what you mean by "as was done by SMDegrain":

from SMDegrain v3.1.2.100s:

NL_in = lsb && !lsb_in ? input.Dither_convert_8_to_16() : input

[tormento]

need both files in you path.
Did it.
as far as I see SMDegrain does still has this function call even in the newest version
With the command line I use, it doesn't use dither at all (I did not have in my Plugins64 directory), so I suppose it's only a optional condition trigger.

Any hint about speed?

[ErazorTT]

Well concerning speed I can for sure say that using dfttest as postFFT is slow.
For full HD and using TemporalDegrain2(degrainTR=2,postFFT=3,postSigma=3,postDither=-1) on one core and with the x264 instance on the other core, I am getting something around 1 fps.

I do have almost no experience with KNLMeans or using MtMode or Prefetch.

Do I assume correctly that you are testing with high bit input?

[tormento]

Well concerning speed I can for sure say that using dfttest as postFFT is slow.
I am using KNLMeansCL as postFFT(=4).
I do have almost no experience with KNLMeans or using MtMode or Prefetch.
Picture that with SMDegrain (the syntax I posted) I get 12-13 fps with Prefetch(6) getting similar results. As I saw you already looked at other script to get inspiration, I humbly suggest you to get a look to SMDegrain also and get the good things from it too. :o And please, play a bit with Prefetch too. 1 fps on nowadays processors is really slow. We have GPU sitting there too, let's use them :) I have been successful to make your script to work with Prefetch and the maximum I get is still 0.98fps.
Do I assume correctly that you are testing with high bit input?
No, I use 8 bit input, as you can see from DGDecNV syntax.

[ErazorTT]

Does it change something to set postDither to 0? What speed do you reach then?

is this (https://forum.doom9.org/showthread.php?p=1856262#post1856262) still the actual script you managed to make prefetch running?

[tormento]

Does it change something to set postDither to 0? What speed do you reach then?
Running and I am at 0.86 with Prefetch(6)
is this (https://forum.doom9.org/showthread.php?p=1856262#post1856262) still the actual script you managed to make prefetch running?
Yep. It hangs a bit in the begninning, so much that the x264 launcher complains:
[2018-10-31][17:59:54] Warning: encoder did not respond for 60 seconds, potential deadlock...
then it starts.

Please, if you want, give latest SMDegrain a run with my same parameters, i.e.
SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
<your preferred decoder>
CompTest(1)
SMDegrain (tr=4, thSAD=400, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=false, plane=4, chroma=true)
Prefetch(6)

[ErazorTT]

So I made a perfomance test on my dual core 3Ghz Haswell with the following code with the colored expressions either being enabled or not:


SetFilterMTMode("DEFAULT_MT_MODE", 2)
LWLibavVideoSource("Z:\1080p.mkv")
TemporalDegrain2(...)
BilinearResize(480,270)
Trim(100,666)+Trim(9835,10000)
Prefetch(2)


These are the results:
https://i.postimg.cc/2SgYMF53/perf.png

Just using the BilinearResize without any other filter and the throughput is at 122 fps.
On one core TemporalDegrain2 is almost as fast as TemporalDegrain v1.23.
Using postFFT=3 decreases the speed dramatically and postFFT=4 is only any better if you have some usefull graphics card, not as my crappy internal Intel.
Increasing the number of threads using the parameter fftTreads helps somehow, it helps however more to use Prefetch.

@tormento: Could you please also test using postFFT=3 with your Prefetch of 6?
And, could it be that you also have an internal intel graphics card apart from your actual GPU? Because in this case I would guess that perhaps the KNLMeans runs on the wrong GPU. Could you give it another using KNLMeans with this (https://drive.google.com/open?id=1SUkbwe7e56QKokOU43C_izrz3VYOhFae) version?

[ChaosKing]

Nice script. It's a good smdegrain alternative.
I tested TemporalDegrain2(degrainTR=4, postFFT=3, fftthreads=4) with Prefetch(2), 4 and 6 - DVD 720x480
Went from 3.2 fps to 5.8fps. The biggest jump was with Prefetch(2) to 5.4fps. The cpu is at 50% max. Ryzen @ 3.7ghz 8core.
With degrainTR=2 I get 15.4 fps :D


Any chance this gets ported to Vapoursynth one day?

[ErazorTT]

Were you using both fftthreads=4 and Prefetch(2) at the same time? I though those to be mutually exclusive. Thus I would have guessed that it would be more performant to have only Prefetch, which then could be set higher. :confused: What is your experience with that?

Additionally I really would not set degrainTR higher than FPS/8, thus for the usual cinema film not higher than 3. There can be some very rare, hard to find but ugly effects! I could show an example when I have time to prepare the pictures later today. Thus I would decrease degrainTR to 3 or even 2 and instead increase postSigma to 2 or 3.

Well I have never used Vapoursynth, so this is not something which will happen immediately..

[ChaosKing]

Were you using both fftthreads=4 and Prefetch(2) at the same time? I though those to be mutually exclusive.
.

Yeah, it seems mixing both is not a good idea. You can see the negative effects even more with higher values. Prefetch(8) alone runs now with 7.2fps. If I add fftthreads (tried 2 and 8) it slows down to 3.5fps regardles of that fftthread value I set.

If you want give VapourSynth a try you can use my portable pack (all filters, scripts and editors included). https://forum.doom9.org/showthread.php?t=175529

EDIT
For some reason I set degrainTR=6 while testing with fftthreads...
Prefetch(8) + fftthreads=8 => 9.2 fps, so yes mixem them is ok :cool:

TemporalDegrain2(degrainTR=4, postFFT=3, fftthreads=8) # 9.2fps
Prefetch(8)

TemporalDegrain2(degrainTR=3, postFFT=3, fftthreads=8) # 12.5fps
TemporalDegrain2(degrainTR=2, postFFT=3, fftthreads=8) # 17.3fps

TemporalDegrain2(degrainTR=3, postFFT=3) # 10.1fps
TemporalDegrain2(degrainTR=2, postFFT=3) # 14.0fps

[tormento]

@tormento: Could you please also test using postFFT=3 with your Prefetch of 6?
Results on 1920x1032 input:

TemporalDegrain2(degrainTR=4,postFFT=0,postSigma=3,postDither=0) 0.69 (1.56*) fps, 3791.50 kb/s
TemporalDegrain2(degrainTR=4,postFFT=3,postSigma=3,postDither=0) 0.45 (0.85*) fps, 3060.34 kb/s
TemporalDegrain2(degrainTR=4,postFFT=4,postSigma=3,postDither=0) 0.64 (0.98*) fps, 3331.73 kb/s

(* Prefeth=6)

And, as comparison:

SMDegrain (tr=4, thSAD=400, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=false, plane=4, chroma=true) 9.34 fps, 4083.54 kb/s

I think the problem does not reside on postFFT side. As you can see the delta is negligible with postFFT=0. Please notice that every output is then processed to x264 slow preset.
And, could it be that you also have an internal intel graphics card apart from your actual GPU? Because in this case I would guess that perhaps the KNLMeans runs on the wrong GPU.
My CPU is a Sandy Bridge and does not support OpenCL. Plus the slowness would appear on SMDegrain too.
Could you give it another using KNLMeans with this (https://drive.google.com/open?id=1SUkbwe7e56QKokOU43C_izrz3VYOhFae) version?
All the new trials were made with your newer script.

[ChaosKing]

I noticed that your scripts produces some halos:

200% zoom
https://i.imgur.com/IK83WEL.png

I used TemporalDegrain2(degrainTR=3, postFFT=3, fftthreads=8). It's still visible with postFFT=0 but slightly less.

[ErazorTT]

TemporalDegrain2(degrainTR=4,postFFT=0,postSigma=3,postDither=0) 0.86 fps 3060 kb/s
TemporalDegrain2(degrainTR=4,postFFT=3,postSigma=3,postDither=0) 0.95 fps 3371 kb/s
TemporalDegrain2(degrainTR=4,postFFT=4,postSigma=3,postDither=0) 1.58 fps 3791 kb/s


This is ultra wierd! How can it be faster to have the postFFT enabled compared to not having it enabled :confused:
Were you running with Prefetch(x)? What do you get when you increase your Prefetch(x) setting from 1 to whatever you usually use?

[ErazorTT]

I noticed that your scripts produces some halos:
200% zoom
https://i.imgur.com/IK83WEL.png


Is it the original to the right? Because I for sure see there the same structure. It seems it is just visually hidden behind the noise. Once the noise is removed, the structure is revealed.

[tormento]

This is ultra wierd!
I will rerun again to have confirmation.

[tormento]

This is ultra wierd!
Post fixed.

[zorr]

AvisynthOptimizer could be used to test the speed of different Prefetch and SetFilterMTMode settings.

Additionally I really would not set degrainTR higher than FPS/8, thus for the usual cinema film not higher than 3. There can be some very rare, hard to find but ugly effects!

Also by comparing the degrained clip to the original with SSIM it should be easy to spot any anomalies in the rendering. The script could return the worst SSIM of any frame. It will probably need a long clip to find those rare errors though, but it should be possible. If anyone is interested I can help make the script ready for the optimizer.

[ErazorTT]

AvisynthOptimizer could be used to test the speed of different Prefetch and SetFilterMTMode settings.

That would be great, however as much as would love to do this test myself, I guess my crappy dual core laptop is not performant enough to do this analysts.


Also by comparing the degrained clip to the original with SSIM...

Yes , something along the lines of this here: http://forum.doom9.org/showthread.php?p=861726#post861726


It will probably need a long clip to find those rare errors though...

The suggestion by StainlessS is probably a good starting point:
http://forum.doom9.org/showthread.php?p=1856048#post1856048


If anyone is interested I can help make the script ready for the optimizer.

Yeah that would be interesting to see! (Who knows perhaps this would trigger my urge to get a decent standalone pc again :D )

[tormento]

That would be great, however as much as would love to do this test myself, I guess my crappy dual core laptop is not performant enough to do this analysts.
My two cents: I don't want to weigh you down but I simply think that the script, even as so much good as it is, is simply too slow to have any improvements with tweaks on the Prefetch side. I have looked at the CPU usage, both on single thread and MT, and there are so much time it plains does nothing. With Prefetch(6), over 8 logical cores, I get a media of 30% with peaks of 50%.
You (we) should analyze every single routine inside and find where the cycles run void.

And, since x264 Simple Launcher was created, it's the first time I see it telling me the script is not responding, to give you an idea.

Please, if you have time, try to create a simpler one, using only OpenCL filtering (KNLMeansCL in my mind) + MVTools. Probably the results will be crappier but we could have an idea of theoretical speed.

[ChaosKing]

I offer to run the Optimizer tests on my 8 core Ryzen.

[ErazorTT]

Well considering that the result from ChaosKing are more than an order of magnitude faster than yours, and yours are exactly as fast as both TempralDegrain v1 and v2 on my crappy laptop I would guess that there is something wrong for you. I don’t know what simple launcher is supposed to do but apparently there goes something wrong.
Considering that you have a Sandy Bridge this means that you have 4 cores. Perhaps it would be an idea to not set Prefetch higher that 3 and have x264 on the 4th core. And also try to run once with postFFT=1.

[ChaosKing]

My CPU util was still @ 50-60% max with Prefetch 8. But the big diffenrence could be this: I have a RX480 gpu, that means KNLMeansCL is not that slow on my system.
tormento, what fps do you get with KNLMeansCL alone?

[ChaosKing]

Here is a quick test for:
optimize degrainTR = _n_ | 1..4 | degrainTR
optimize postFFT = _n_ | 0,1,3 | postFFT

I used AddGrain(80, 0, 0, seed=2) on a clean anime 720p source
But after iter 16 I got into an endless DUPLICATE PARAMS loop.

225.84503 33630 degrainTR=1 postFFT=0
241.66373 76180 degrainTR=4 postFFT=0
239.99747 60510 degrainTR=3 postFFT=0
239.99747 61410 degrainTR=3 postFFT=0
239.99747 62140 degrainTR=3 postFFT=0
244.31024 16655 degrainTR=3 postFFT=3
244.09448 95600 degrainTR=4 postFFT=1
244.91441 18072 degrainTR=4 postFFT=3
244.09448 95270 degrainTR=4 postFFT=1
236.55763 48110 degrainTR=2 postFFT=0
225.84503 34390 degrainTR=1 postFFT=0
243.23091 80750 degrainTR=3 postFFT=1
244.91440 18117 degrainTR=4 postFFT=3
242.97444 15382 degrainTR=2 postFFT=3
241.66373 75960 degrainTR=4 postFFT=0
232.85495 53540 degrainTR=1 postFFT=1


https://i.imgur.com/bFROtKh.png

[ErazorTT]

Ok that is interesting! Perhaps you could also include a sweep over the postSigma = _n_ | 1,2,3,4 | . Since postFFT=0 is apparently always worse you could exclude it to save some time.

[ErazorTT]

@tormento: Could you please try again with this version here (https://drive.google.com/open?id=14uAFDJm1bHG64Xldvi1mzf2zB0y4ndw8). I included knlDevId so perhaps playing with it changing it from 0 to 1 will help..

[zorr]

Here is a quick test for:
optimize degrainTR = _n_ | 1..4 | degrainTR
optimize postFFT = _n_ | 0,1,3 | postFFT

I used AddGrain(80, 0, 0, seed=2) on a clean anime 720p source
But after iter 16 I got into an endless DUPLICATE PARAMS loop.

Hmm, seems *almost* normal behavior. The DUPLICATE PARAMS happens when the optimizer is unable to find a parameter combination it hasn't already tried. I should probably add an ending condition there as well or make it smart enough to realize it has tried all combinations.

However what I don't quite understand is why it did that after 16 iterations, there are 4*3 possible combinations which is 12. And it already has some duplicates in your log... :confused:

[ChaosKing]

degrainTR = 4 # optimize degrainTR = _n_ | 1..4 | degrainTR
postFFT = 1 # optimize postFFT = _n_ | 0,1,3 | postFFT
postSigma = 1 # optimize postSigma = _n_ | 1..4 | postSigma

Now with Prefetch(8), lower res (640x360) and trim to 150 frames.
Is it normal that the graph doesn't show lower values like 135?

145.50601 9670 degrainTR=1 postFFT=1 postSigma=3
145.67668 25930 degrainTR=2 postFFT=3 postSigma=1
142.8922 17800 degrainTR=3 postFFT=0 postSigma=1
147.25772 20230 degrainTR=3 postFFT=1 postSigma=3
142.8922 17830 degrainTR=3 postFFT=0 postSigma=2
142.8922 17730 degrainTR=3 postFFT=0 postSigma=1
135.96149 7380 degrainTR=1 postFFT=0 postSigma=1
145.5126 20260 degrainTR=3 postFFT=1 postSigma=1
142.8922 17950 degrainTR=3 postFFT=0 postSigma=2
135.96149 7350 degrainTR=1 postFFT=0 postSigma=1
142.8922 17950 degrainTR=3 postFFT=0 postSigma=1
144.04181 14660 degrainTR=2 postFFT=1 postSigma=1
143.90645 22950 degrainTR=4 postFFT=0 postSigma=2
143.90645 23380 degrainTR=4 postFFT=0 postSigma=1
140.8963 12090 degrainTR=2 postFFT=0 postSigma=2
147.57607 31830 degrainTR=3 postFFT=3 postSigma=3
145.67668 25760 degrainTR=2 postFFT=3 postSigma=1
147.12352 36800 degrainTR=4 postFFT=3 postSigma=1
140.8963 12100 degrainTR=2 postFFT=0 postSigma=3
140.8963 12100 degrainTR=2 postFFT=0 postSigma=1
145.50601 9660 degrainTR=1 postFFT=1 postSigma=3
139.70255 9660 degrainTR=1 postFFT=1 postSigma=1
147.17488 25320 degrainTR=4 postFFT=1 postSigma=2
143.70836 9700 degrainTR=1 postFFT=1 postSigma=2
146.21446 20850 degrainTR=1 postFFT=3 postSigma=4
146.8522 14590 degrainTR=2 postFFT=1 postSigma=3
135.96149 7390 degrainTR=1 postFFT=0 postSigma=2
135.96149 7380 degrainTR=1 postFFT=0 postSigma=3
147.3242 31640 degrainTR=3 postFFT=3 postSigma=2
142.22742 21040 degrainTR=1 postFFT=3 postSigma=1
147.40378 20430 degrainTR=3 postFFT=1 postSigma=4
142.8922 17960 degrainTR=3 postFFT=0 postSigma=4
147.4705 25270 degrainTR=4 postFFT=1 postSigma=3
147.70525 32060 degrainTR=3 postFFT=3 postSigma=4
146.24329 9590 degrainTR=1 postFFT=1 postSigma=4
147.18077 25890 degrainTR=2 postFFT=3 postSigma=3
147.1184 14480 degrainTR=2 postFFT=1 postSigma=4
144.46893 21110 degrainTR=1 postFFT=3 postSigma=2
145.5126 20240 degrainTR=3 postFFT=1 postSigma=1
142.8922 17930 degrainTR=3 postFFT=0 postSigma=3
146.74043 26020 degrainTR=2 postFFT=3 postSigma=2
140.8963 12540 degrainTR=2 postFFT=0 postSigma=4
147.25772 20260 degrainTR=3 postFFT=1 postSigma=3
147.41321 26070 degrainTR=2 postFFT=3 postSigma=4
143.90645 22770 degrainTR=4 postFFT=0 postSigma=4
147.84923 36290 degrainTR=4 postFFT=3 postSigma=4
135.96149 7400 degrainTR=1 postFFT=0 postSigma=4
146.84929 20350 degrainTR=3 postFFT=1 postSigma=2
146.16771 14490 degrainTR=2 postFFT=1 postSigma=2
147.7625 36640 degrainTR=4 postFFT=3 postSigma=3
147.56343 25300 degrainTR=4 postFFT=1 postSigma=4
145.57582 20730 degrainTR=1 postFFT=3 postSigma=3
146.18916 25550 degrainTR=4 postFFT=1 postSigma=1
143.90645 23240 degrainTR=4 postFFT=0 postSigma=3
147.58546 36390 degrainTR=4 postFFT=3 postSigma=2
146.68575 31290 degrainTR=3 postFFT=3 postSigma=1

https://i.imgur.com/3rnrBNA.png


The output by evaluate mode is also a bit strange, worst result = best?
Single run results: 56
Series results: 0

Run 1 best: 147.84923 36290 degrainTR=4 postFFT=3 postSigma=4

Best result: 147.84923
Worst result: 147.84923

Pareto front:
147.84923 36290 degrainTR=4 postFFT=3 postSigma=4
147.70525 32060 degrainTR=3 postFFT=3 postSigma=4
147.57607 31830 degrainTR=3 postFFT=3 postSigma=3
147.56343 25300 degrainTR=4 postFFT=1 postSigma=4
147.4705 25270 degrainTR=4 postFFT=1 postSigma=3
147.40378 20430 degrainTR=3 postFFT=1 postSigma=4
147.25772 20230 degrainTR=3 postFFT=1 postSigma=3
147.1184 14480 degrainTR=2 postFFT=1 postSigma=4
146.24329 9590 degrainTR=1 postFFT=1 postSigma=4
135.96149 7350 degrainTR=1 postFFT=0 postSigma=1

[ErazorTT]

Judging by this measurement the optimum is also the maximal settings which were allowed:

147.84923 36290 degrainTR=4 postFFT=3 postSigma=4

It would appear that the maxima fit degrainTR and postSigma were still too low in this run. However, the result should be wildly different in different circumstances: like for clips with much quick movements I would guess that increasing degrainTR above some threshold will be counterproductive.

[ChaosKing]

Bonus: degrainTR 5-6
148.04684 47280ms degrainTR=6 postFFT=3 postSigma=4
148.01166 42710ms degrainTR=5 postFFT=3 postSigma=4
147.94945 41310ms degrainTR=5 postFFT=3 postSigma=3
147.78264 37160ms degrainTR=6 postFFT=1 postSigma=4
147.7377 36780ms degrainTR=6 postFFT=1 postSigma=3
147.73164 30890ms degrainTR=5 postFFT=1 postSigma=4
147.67194 30840ms degrainTR=5 postFFT=1 postSigma=3
147.44595 30810ms degrainTR=5 postFFT=1 postSigma=2
144.64229 27510ms degrainTR=5 postFFT=0 postSigma=1

@zorr I had set it to -iters 30 by mistake but it ran 32 times nonetheless
LOG (x64, 0.9.8 beta)
Output 1:
name ssim
type FLOAT
goal MAX
unit
round 0
Output 2:
name time
type TIME
goal MIN
unit ms
round 10

Found following optimizable parameters:
# optimize degrainTR = _n_ | 5..6 | degrainTR
# optimize postFFT = _n_ | 0,1,3 | postFFT
# optimize postSigma = _n_ | 1..4 | postSigma
found 3 parameters to optimize

Running SPEA2
* 1 / 30 : 145.00519 56410ms degrainTR=6 postFFT=0 postSigma=1
+ 2 / 30 : 145.00519 55430ms degrainTR=6 postFFT=0 postSigma=3
+ 3 / 30 : 144.64229 28650ms degrainTR=5 postFFT=0 postSigma=2
4 / 30 : 144.64229 28710ms degrainTR=5 postFFT=0 postSigma=1
* 5 / 30 : 147.81573 42460ms degrainTR=5 postFFT=3 postSigma=2
+ 6 / 30 : 146.67145 31380ms degrainTR=5 postFFT=1 postSigma=1
7 / 30 : 145.00519 56330ms degrainTR=6 postFFT=0 postSigma=4
+ 8 / 30 : 144.64229 28330ms degrainTR=5 postFFT=0 postSigma=2
Parameter sensitivity estimation with 64 result combinations
-> degrainTR 0,542 postFFT 1,546 postSigma 0,990
Mutating 2 params by 22,0 %
+ 9 / 30 : 147.78264 37160ms degrainTR=6 postFFT=1 postSigma=4
+ 10 / 30 : 147.44595 30810ms degrainTR=5 postFFT=1 postSigma=2
11 / 30 : 144.64229 28410ms degrainTR=5 postFFT=0 postSigma=4
12 / 30 : 145.00519 53030ms degrainTR=6 postFFT=0 postSigma=1
13 / 30 : 147.45505 42150ms degrainTR=5 postFFT=3 postSigma=1
14 / 30 : 146.67145 30820ms degrainTR=5 postFFT=1 postSigma=1
15 / 30 : 146.8749 36550ms degrainTR=6 postFFT=1 postSigma=1
+ 16 / 30 : 144.64229 27580ms degrainTR=5 postFFT=0 postSigma=2
Parameter sensitivity estimation with 256 result combinations
-> degrainTR 0,556 postFFT 1,403 postSigma 0,968
Mutating 1 params by 14,0 %
mutation failed 1000 times, increasing mutation count to 2
+ 17 / 30 : 144.64229 27510ms degrainTR=5 postFFT=0 postSigma=1
18 / 30 : 145.00519 52870ms degrainTR=6 postFFT=0 postSigma=2
19 / 30 : 147.81573 42490ms degrainTR=5 postFFT=3 postSigma=2
20 / 30 : 144.64229 27880ms degrainTR=5 postFFT=0 postSigma=3
+ 21 / 30 : 147.7377 36780ms degrainTR=6 postFFT=1 postSigma=3
22 / 30 : 147.54588 36850ms degrainTR=6 postFFT=1 postSigma=2
+ 23 / 30 : 147.67194 30840ms degrainTR=5 postFFT=1 postSigma=3
24 / 30 : 147.57674 48110ms degrainTR=6 postFFT=3 postSigma=1
Parameter sensitivity estimation with 256 result combinations
-> degrainTR 0,559 postFFT 1,282 postSigma 1,054
Mutating 1 params by 6,0 %
mutation failed 1000 times, increasing mutation count to 2
mutation failed 1000 times, increasing mutation count to 2
mutation failed 1000 times, increasing mutation count to 2
mutation failed 2000 times, increasing mutation count to 3
25 / 30 : 145.00519 53010ms degrainTR=6 postFFT=0 postSigma=3
+ 26 / 30 : 147.73164 30890ms degrainTR=5 postFFT=1 postSigma=4
* 27 / 30 : 147.94945 41310ms degrainTR=5 postFFT=3 postSigma=3
28 / 30 : 147.88573 46830ms degrainTR=6 postFFT=3 postSigma=2
* 29 / 30 : 148.01166 42710ms degrainTR=5 postFFT=3 postSigma=4
30 / 30 : 147.99655 47120ms degrainTR=6 postFFT=3 postSigma=3
* 31 / 30 : 148.04684 47280ms degrainTR=6 postFFT=3 postSigma=4
32 / 30 : 145.00519 53230ms degrainTR=6 postFFT=0 postSigma=4
Parameter sensitivity estimation with 256 result combinations
-> degrainTR 0,566 postFFT 1,161 postSigma 1,152
Total execution time: 1339735ms
Pareto front:
148.04684 47280ms degrainTR=6 postFFT=3 postSigma=4
148.01166 42710ms degrainTR=5 postFFT=3 postSigma=4
147.94945 41310ms degrainTR=5 postFFT=3 postSigma=3
147.78264 37160ms degrainTR=6 postFFT=1 postSigma=4
147.7377 36780ms degrainTR=6 postFFT=1 postSigma=3
147.73164 30890ms degrainTR=5 postFFT=1 postSigma=4
147.67194 30840ms degrainTR=5 postFFT=1 postSigma=3
147.44595 30810ms degrainTR=5 postFFT=1 postSigma=2
144.64229 27510ms degrainTR=5 postFFT=0 postSigma=1
Running SPEA2
...

[ErazorTT]

What is actually the script you are using?

[ChaosKing]

https://forum.doom9.org/showpost.php?p=1856803&postcount=98

[ChaosKing]

Now I tested 100 frames from tears of steel, this scene https://www.youtube.com/watch?v=R6MlUcmOul8&feature=youtu.be&t=271

And here I noticed also some halos. You can see it very good on his hair in #2 http://screenshotcomparison.com/comparison/123735/

My script
ffms2("TearsOfSteelFull12min_1080p_24fps_27qp_1474kbps_GPSNR_42.29_HM11.mkv").ConvertBits(8).bicubicresize(880,500).trim(6460,6560)
source = last
last=source.AddGrain(40, 0, 0, seed=2)
degrainTR = 5 # optimize degrainTR = _n_ | 1..5 | degrainTR
postFFT = 3 # optimize postFFT = _n_ | 0,1,3 | postFFT
postSigma = 1 # optimize postSigma = _n_ | 1..4 | postSigma
denoised = TemporalDegrain2(degrainTR=degrainTR, postFFT=postFFT, postSigma=postSigma)
# no Prefetch, i forgot to add it :)

@zorr
- Evaluate mode still shows version 0.9.8 instead of 0.9.9
- Worst result is still wrong in 0.9.9 and the visualisation also I guess (96.75 value is cut off)
AvisynthOptimizer v0.9.8-beta

Arguments
mode = evaluate
autorefresh = true

Running evaluation for log(s) .\avs_version (2018-11-04 10-10-30) optimize spea2 pop-8 mutcount-60%-1 mutamount-0.3-0.01 cross-0.1-20 iters-70 run-01.log
Using these settings:
ARGUMENT DESCRIPTION VALUE
-vismode visualization mode single
-scripts write scripts none
-globalpareto show series pareto true
-autorefresh autorefresh true
-highlight highlight latest 10
-multipareto show multiple pareto fronts 0 (OFF)
-top zoom into top x% results 20
-groupby group by parameter (OFF)
-maxgroups group by max groups N/A
-groupmin group by min value N/A
-groupmax group by max value N/A
-animation animation iterations per frame 0 (OFF)

Reading log file .\avs_version (2018-11-04 10-10-30) optimize spea2 pop-8 mutcount-60%-1 mutamount-0.3-0.01 cross-0.1-20 iters-70 run-01.log
Single run results: 64
Series results: 0

Run 1 best: 99.42768 51190 degrainTR=5 postFFT=3 postSigma=1

Best result: 99.42768
Worst result: 99.42768 <----- NOPE!

Pareto front:
99.42768 51190 degrainTR=5 postFFT=3 postSigma=1
99.42644 44710 degrainTR=4 postFFT=3 postSigma=1
99.3991 38630 degrainTR=3 postFFT=3 postSigma=1
99.39909 38140 degrainTR=3 postFFT=3 postSigma=1
99.37821 37100 degrainTR=5 postFFT=1 postSigma=1
99.35609 30730 degrainTR=4 postFFT=1 postSigma=2
99.3523 30310 degrainTR=4 postFFT=1 postSigma=1
99.34066 24040 degrainTR=3 postFFT=1 postSigma=2
99.26441 17570 degrainTR=2 postFFT=1 postSigma=2
99.15682 17560 degrainTR=2 postFFT=1 postSigma=4
99.067345 17490 degrainTR=2 postFFT=1 postSigma=1
99.05565 11640 degrainTR=1 postFFT=1 postSigma=4
96.75158 8700 degrainTR=1 postFFT=0 postSigma=2
https://i.imgur.com/zkLRXnc.png


98.24987 14380 degrainTR=2 postFFT=0 postSigma=3
99.31801 31720 degrainTR=2 postFFT=3 postSigma=4
99.34313 32060 degrainTR=2 postFFT=3 postSigma=2
99.3523 30310 degrainTR=4 postFFT=1 postSigma=1
96.75158 8700 degrainTR=1 postFFT=0 postSigma=2
99.39007 44140 degrainTR=4 postFFT=3 postSigma=2
96.75158 8720 degrainTR=1 postFFT=0 postSigma=3
98.24987 14580 degrainTR=2 postFFT=0 postSigma=4
98.72428 21350 degrainTR=3 postFFT=0 postSigma=3
99.052536 11670 degrainTR=1 postFFT=1 postSigma=3
99.02302 25530 degrainTR=1 postFFT=3 postSigma=2
99.05565 11640 degrainTR=1 postFFT=1 postSigma=4
98.72428 21600 degrainTR=3 postFFT=0 postSigma=4
98.12291 11930 degrainTR=1 postFFT=1 postSigma=1
99.05177 34090 degrainTR=5 postFFT=0 postSigma=1
99.15682 17560 degrainTR=2 postFFT=1 postSigma=4
96.75158 8820 degrainTR=1 postFFT=0 postSigma=1
98.878456 12010 degrainTR=1 postFFT=1 postSigma=2
99.28696 32500 degrainTR=2 postFFT=3 postSigma=1
99.24217 17770 degrainTR=2 postFFT=1 postSigma=3
99.37821 37100 degrainTR=5 postFFT=1 postSigma=1
96.75158 8750 degrainTR=1 postFFT=0 postSigma=4
98.94025 27930 degrainTR=4 postFFT=0 postSigma=1
98.24987 14310 degrainTR=2 postFFT=0 postSigma=2
99.27137 24320 degrainTR=3 postFFT=1 postSigma=3
99.352585 36270 degrainTR=5 postFFT=1 postSigma=2
98.72428 21830 degrainTR=3 postFFT=0 postSigma=2
99.42768 51190 degrainTR=5 postFFT=3 postSigma=1
99.188416 26020 degrainTR=1 postFFT=3 postSigma=4
99.35609 30730 degrainTR=4 postFFT=1 postSigma=2
99.37805 51230 degrainTR=5 postFFT=3 postSigma=2
99.14046 25910 degrainTR=1 postFFT=3 postSigma=3
99.2798 24180 degrainTR=3 postFFT=1 postSigma=1
99.15887 24290 degrainTR=3 postFFT=1 postSigma=4
99.34593 44000 degrainTR=4 postFFT=3 postSigma=3
99.42644 44710 degrainTR=4 postFFT=3 postSigma=1
99.05177 33440 degrainTR=5 postFFT=0 postSigma=2
98.72428 21520 degrainTR=3 postFFT=0 postSigma=1
99.38929 38540 degrainTR=3 postFFT=3 postSigma=2
99.34066 24040 degrainTR=3 postFFT=1 postSigma=2
99.39909 38140 degrainTR=3 postFFT=3 postSigma=1
98.94025 28150 degrainTR=4 postFFT=0 postSigma=2
99.35622 38870 degrainTR=3 postFFT=3 postSigma=3
98.24987 14870 degrainTR=2 postFFT=0 postSigma=1
99.32733 51160 degrainTR=5 postFFT=3 postSigma=3
98.688225 25490 degrainTR=1 postFFT=3 postSigma=1
99.30322 44120 degrainTR=4 postFFT=3 postSigma=4
99.26441 17570 degrainTR=2 postFFT=1 postSigma=2
98.94025 27280 degrainTR=4 postFFT=0 postSigma=4
99.32066 38310 degrainTR=3 postFFT=3 postSigma=4
99.067345 17490 degrainTR=2 postFFT=1 postSigma=1
99.26495 30370 degrainTR=4 postFFT=1 postSigma=3
99.280716 51640 degrainTR=5 postFFT=3 postSigma=4
99.24911 36540 degrainTR=5 postFFT=1 postSigma=3
99.1392 30790 degrainTR=4 postFFT=1 postSigma=4
99.33777 31310 degrainTR=2 postFFT=3 postSigma=3
99.05177 33620 degrainTR=5 postFFT=0 postSigma=3
99.115715 36940 degrainTR=5 postFFT=1 postSigma=4
99.05177 33770 degrainTR=5 postFFT=0 postSigma=4
98.94025 27360 degrainTR=4 postFFT=0 postSigma=3
98.12291 11790 degrainTR=1 postFFT=1 postSigma=1
99.15887 24470 degrainTR=3 postFFT=1 postSigma=4
98.94025 28210 degrainTR=4 postFFT=0 postSigma=2
99.3991 38630 degrainTR=3 postFFT=3 postSigma=1

[tormento]

Well considering that the result from ChaosKing are more than an order of magnitude faster than yours, and yours are exactly as fast as both TempralDegrain v1 and v2 on my crappy laptop I would guess that there is something wrong for you. I don’t know what simple launcher is supposed to do but apparently there goes something wrong.
Or probably you missed the fact I am running the script on a 1080p source and you both on 720p or DVD resolution? :D Which encoder you feed at the end? I am using x264 --preset slow.

To clear things up, I am now using AVSMeter64 to get script results with no encoder around.

@ChaosKing to answer you about KNLMeansCL performance, I run a simple KNLMeansCL() on 1080p source:
AVSMeter64.exe sacrificio_KNLMeansCL.avs

AVSMeter 2.8.6 (x64) - Copyright (c) 2012-2018, Groucho2004
AviSynth+ 0.1 (r2728, MT, x86_64) (0.1.0.0)

Number of frames: 1750
Length (hh:mm:ss.ms): 00:01:12.990
Frame width: 1920
Frame height: 1032
Framerate: 23.976 (24000/1001)
Colorspace: YV12

Frames processed: 1750 (0 - 1749)
FPS (min | max | average): 2.001 | 17.93 | 12.41
Process memory usage (max): 198 MiB
Thread count: 24
CPU usage (average): 9.6%

Time (elapsed): 00:02:21.065

Anyway... as I told twice... SMDegrain with KNLMeansCL prefilter works with 10x performance.

[ChaosKing]

tears of steel 1080p x64 test:

#0.82fps
TemporalDegrain2(degrainTR=3, postFFT=3, postSigma=1)

#4fps
TemporalDegrain2(degrainTR=3, postFFT=3, postSigma=1, fftthreads=8)
Prefetch(8)

KNLMeansCL alone runs at 27fps on a 1080p source


I'm testing the script performance, so I don't feed to any encoder.

[tormento]

tears of steel 1080p x64 test:
Please try these (https://forum.doom9.org/showthread.php?p=1856708#post1856708) settings to mantain some uniformity.

EDIT:
#4fps
TemporalDegrain2(degrainTR=3, postFFT=3, postSigma=1, fftthreads=8)
Prefetch(8)

@ErazorTT

1.86 fps here on i7-2600k + GTX 760. I can't really see one order of magnitude.

[ChaosKing]

All with Prefetch(8). Now tested with avsmeter64, 300 frames, 1080p source - ffms2("TearsOfSteelFull12min_1080p_24fps_27qp_1474kbps_GPSNR_42.29_HM11.mkv").trim(500,500+300)
AviSynth+ r2728, all plugins updated
Ryzen 1700 @ 3.7ghz, Rx480, 16gb ram 3000mhz
TemporalDegrain2(degrainTR=4,postFFT=0,postSigma=3,postDither=0) #5.15
TemporalDegrain2(degrainTR=4,postFFT=0,postSigma=3,postDither=0, fftthreads=8) #5.5
TemporalDegrain2(degrainTR=4,postFFT=3,postSigma=3,postDither=0) # 2.42
TemporalDegrain2(degrainTR=4,postFFT=3,postSigma=3,postDither=0, fftthreads=8) # 3.52
TemporalDegrain2(degrainTR=4,postFFT=4,postSigma=3,postDither=0) #4.23
TemporalDegrain2(degrainTR=4,postFFT=4,postSigma=3,postDither=0, fftthreads=8) #4.62

Have you the newest fftw lib installed?

[ErazorTT]

Or probably you missed the fact I am running the script on a 1080p source and you both on 720p or DVD resolution?


My performance measurement (here (https://forum.doom9.org/showthread.php?p=1856673#post1856673)) was using a 1080p source. Yielding around 1.7fps without postFFT on a dual core haswell laptop, i5-4288U.


Which encoder you feed at the end? I am using x264 --preset slow.


For measuring the speed of the script I use x264 with preset super fast, since I want to measure the differences between scripts not the impact of the encoder. However I very much see the point of measuring both, since in the end one has to do both at a time.


Anyway... as I told twice... SMDegrain with KNLMeansCL prefilter works with 10x performance.


Yes.. Apparently there is somewhere something wrong but I just dont know where... Without being able to test it myself, there nothing more I can do than guessing.. :(

[tormento]

For measuring the speed of the script I use x264 with preset super fast
Much better to feed directly to avsmeter
Yes.. Apparently there is somewhere something wrong but I just dont know where... Without being able to test it myself, there nothing more I can do than guessing.. :(
We are here to help ;)

[tormento]

Have you the newest fftw lib installed?
I am using 3.3.8 (https://forum.doom9.org/showthread.php?p=1855955#post1855955) AVX

[ErazorTT]

Much better to feed directly to avsmeter


Thats a good suggestion!

I am using 3.3.8 (https://forum.doom9.org/showthread.php?p=1855955#post1855955) AVX

Oh wow I test all the version from your link and the fastest version was "simd128+256" which made dfttest alsmot 10% faster!

EDIT:
Hm however fft3dfilter does not work with this version of fftw lib, it produces access violations...

[zorr]

@zorr
- Evaluate mode still shows version 0.9.8 instead of 0.9.9


Yes, I forgot to update the version number. It has happened a couple of times before. :o

- Worst result is still wrong in 0.9.9 and the visualisation also I guess (96.75 value is cut off)

The visualization by default "zooms in" into the best 20% of results. You can change that with argument -top, for example -top 50 would show the top 50% of results. If you want the zooming completely disabled use -top 100 but that doesn't usually look very good. Perhaps -top 99 will do what you want.

I wasn't able to reproduce the problem with the worst result, I also noticed that in your log the Series has zero results, probably has something to do with that.


Single run results: 64
Series results: 0


Can you give me the exact command line you use to call the optimizer? Are you calling it from the <optimizer>/bin directory or somewhere else? Where are your log files located at?

You also might try the latest version (https://drive.google.com/open?id=1pD9qguKcAkvVNTjpfJeixcukf4yXKtAI) which has one path related problem fixed.

@zorr I had set it to -iters 30 by mistake but it ran 32 times nonetheless

That's a limitation of the algorithms, they evaluate a whole population until they can stop. So the iteration count is always divisible by the population count.

[tormento]

Hm however fft3dfilter does not work with this version of fftw lib, it produces access violations...
Try to report in that thread.

[zorr]

Run 1 best: 99.42768 51190 degrainTR=5 postFFT=3 postSigma=1

Best result: 99.42768
Worst result: 99.42768 <----- NOPE!


Ah, I forgot what the worst result means. It's actually the best result of the worst run. When there is only one run then best == worst. The idea is that you can see how different results the runs give. I will change the labels to "Best run" and "Worst run" to make it easier to understand.

I have tracked down the Series results being 0, will be fixed in the next version.

And more on topic: it might be a good idea to test if there is any difference in quality when running in multithreaded mode versus single threaded. There shouldn't be, but it doesn't hurt to make sure...

[Zetti]

Thats a good suggestion!



Oh wow I test all the version from your link and the fastest version was "simd128+256" which made dfttest alsmot 10% faster!

EDIT:
Hm however fft3dfilter does not work with this version of fftw lib, it produces access violations...
The problem is fftw lib and not fft3dfilter.

See here: https://forum.doom9.org/showthread.php?p=1857182#post1857182

[tormento]

I want to share an updated version of the script TemporalDegrain.
What about a switch to use FFT3DGPU instead of FFT3DFilter? I'd like to see speed/quality differences. Problem is AFAIK we don't have a x64 version of it.

It could be nice to have a new compiled version from Pinterf, who already dealt with FFT3DFilter or (my dream) a FFT3DCL from Khanattila

[ErazorTT]

What about a switch to use FFT3DGPU instead of FFT3DFilter?


FFT is used in two instances in the script. You can already change both to using FFT3DGPU via function arguments. One by changing limitFFT to 2 and the other by changing postFFT to 2. PostFFT also has the options 3 (dfttest) and 4 (meansCL) which do not make sense for limitFFT.

I'd like to see speed/quality differences.


Yeah me too but I just have an integrated Intel GPU. Quality wise I would expect FFT3DGPU to behave very close to FFT3Dfilter. And especially for limitFFT there is will be no difference in quality, though perhaps very significantly in speed.

That said, FFT3DGPU has not seen any new version in ages while there have been updates to FFT3Dfilter.

[tormento]

One by changing limitFFT to 2
Ok... I did not notice that. Now that you point it, I can see it in the script code. Now I only need to find a FFT3DGPU x64...

EDIT: Here (https://forum.doom9.org/showthread.php?t=164513).
That said, FFT3DGPU has not seen any new version in ages while there have been updates to FFT3Dfilter.
A real pity. Just imagine to have a FFT3DCL...

[tormento]

TemporalDegrain2(degrainTR=4,postFFT=0,postSigma=3,postDither=-1,limitFFT=1) 1.70 fps
TemporalDegrain2(degrainTR=4,postFFT=0,postSigma=3,postDither=-1,limitFFT=2) 1.66 fps
TemporalDegrain2(degrainTR=4,postFFT=4,postSigma=3,postDither=-1,limitFFT=1) 1.12 fps
TemporalDegrain2(degrainTR=4,postFFT=4,postSigma=3,postDither=-1,limitFFT=2) 1.03 fps

So there should be a bottleneck somewhere...

[Groucho2004]

So there should be a bottleneck somewhere...
What do you mean by "should"? The main bottleneck you have in your statements is this:
degrainTR=4

[tormento]

What do you mean by "should"? The main bottleneck you have in your statements is this:
degrainTR=4

I have no knowledge of programming and I can only read a bit of scripting. Can you explain me why SMDegrain is way faster even with TR=9?

[Groucho2004]

Can you explain me why SMDegrain is way faster even with TR=9?
It's a completely different script that uses different parameters passed to the various plugins would be my guess.

[ErazorTT]

Can you explain me why SMDegrain is way faster even with TR=9?

I would suggest to also have a look at the resulting output. What kind of source do you have that you need a temporal radius that big? Even in very heavy scenes like in 300 there is basically no grain or noise left when using degrainTR=3 with postSigma=3.

And in the case of SMDegrain, does it actually change something to go with TR above 6? Isn’t 6 the maximum it computes?

Very generally speaking, if a script does not remove almost all noise you want removed with a temporal radius of 3, I very much doubt it will help much to increase further. With ever increasing number of frames in radius the marginal gain decreases very quickly while the marginal costs* at best remain constant.

Thus also for performance measurements I would really suggest to use the scripts on a realistic source with sensible settings. Setting you would actually use for the final encoding.

EDIT: (*) costs, plural! That is because as costs there is not only the performance impact, with increasing radius there are also the chances of artifacts and the ugliness of artefacts increasing.

This is actually the very reason why I tried to develop an successor script for TemporalDegrain in the first place: Increasing TR above 3 starts to be detrimental, thus I included the post FFT step to combat the remaining noise with another tool. The combination of two different attacks yields better results with less costs than just increasing the numbers of one attack. This is usually generally true, in wars, hacks, medicine or in this instance of combating noise. :D

[tormento]

What kind of source do you have that you need a temporal radius that big?
Pure benchmark example. I use 9 really rarely on old movies.
And in the case of SMDegrain, does it actually change something to go with TR above 6? Isn’t 6 the maximum it computes?
Usually nothing changes a lot above 4. On some material it changes a lot.

Generally speaking: why FFT3DGPU had no effect on performance?

[ErazorTT]

I have no idea!

[Groucho2004]

why FFT3DGPU had no effect on performance?
fft3dgpu is faster for me:

CPU: i5 2500K @ 4GHz, GPU: GTX750

Full script (1080p clip, 100 frames):
LoadCPlugin("E:\Apps\VideoTools\AVSPlugins\CPlugs\ffms2_64.dll")
FFVideoSource("TestDenoise.mkv")
TemporalDegrain2(degrainTR = 1, postFFT = x)


postFFT = 0
FPS (min | max | average): 1.057 | 39.67 | 3.381
Process memory usage (max): 755 MiB
Thread count: 20
CPU usage (average): 44.7%


postFFT = 1
FPS (min | max | average): 0.645 | 6.377 | 2.194
Process memory usage (max): 1134 MiB
Thread count: 20
CPU usage (average): 38.7%

postFFT = 2
FPS (min | max | average): 0.668 | 12.75 | 2.626
Process memory usage (max): 1263 MiB
Thread count: 24
CPU usage (average): 38.4%

[tormento]

fft3dgpu is faster for me
We were talking about limitFFT switch, not postFFT.

Anyway... 0.5fps... ;)

You know better than me the different order of magnitude betweet FFT3DFilter and FFT3DGPU:


FFT3DFilter() no MT

AVSMeter 2.8.7 (x64) - Copyright (c) 2012-2018, Groucho2004
AviSynth+ 0.1 (r2728, MT, x86_64) (0.1.0.0)

Number of frames: 1568
Length (hh:mm:ss.ms): 00:01:05.399
Frame width: 1920
Frame height: 800
Framerate: 23.976 (24000/1001)
Colorspace: YV12

Frames processed: 1568 (0 - 1567)
FPS (min | max | average): 2.409 | 30.74 | 17.92
Process memory usage (max): 269 MiB
Thread count: 20
CPU usage (average): 9.6%

Time (elapsed): 00:01:27.509
FFT3DGPU() no MT

AVSMeter 2.8.7 (x64) - Copyright (c) 2012-2018, Groucho2004
AviSynth+ 0.1 (r2728, MT, x86_64) (0.1.0.0)

Number of frames: 1568
Length (hh:mm:ss.ms): 00:01:05.399
Frame width: 1920
Frame height: 800
Framerate: 23.976 (24000/1001)
Colorspace: YV12

Frames processed: 1568 (0 - 1567)
FPS (min | max | average): 2.796 | 124.9 | 36.15
Process memory usage (max): 242 MiB
Thread count: 35
CPU usage (average): 5.4%

Time (elapsed): 00:00:43.377

[Groucho2004]

We were talking about limitFFT switch, not postFFT.
Same thing, fft3dfilter vs. fft3dgpu.

By the way, the limitfft parameter comment in the avsi makes no sense:

limitFFT= default( limitFFT, 1 ) # wether to use the limit clip. Do never ever disable this, thats part of the very core of the functionality


This is the code:
filter = (limitFFT==1) ? \
o.FFT3DFilter(plane=degrainPlane, sigma=limitSigma, sigma2=s2, sigma3=s3, sigma4=s4, bt=3, bw=limitBlksz, bh=limitBlksz, ncpu=fftThreads) : \
o.FFT3DGPU(plane=degrainPlane, sigma=limitSigma, sigma2=s2 , sigma3=s3, sigma4=s4, bt=3, bw=limitBlksz, bh=limitBlksz)


This means that "limitfft = 1" uses fft3dfilter and any other value uses fft3dgpu. There is no disable option.

[ErazorTT]

This means that "limitfft = 1" uses fft3dfilter and any other value uses fft3dgpu. There is no disable option.

Yeah right.. updated it together with putting pinterf's new hosting addres for FFT3dGPU.

[tormento]

FFT3DGPU() no MT

AVSMeter 2.8.7 (x64) - Copyright (c) 2012-2018, Groucho2004
AviSynth+ 0.1 (r2728, MT, x86_64) (0.1.0.0)

Number of frames: 1568
Length (hh:mm:ss.ms): 00:01:05.399
Frame width: 1920
Frame height: 800
Framerate: 23.976 (24000/1001)
Colorspace: YV12

Frames processed: 1568 (0 - 1567)
FPS (min | max | average): 2.787 | 120.3 | 36.53
Process memory usage (max): 242 MiB
Thread count: 35
CPU usage (average): 4.4%

Time (elapsed): 00:00:42.929

[ChaosKing]

TemporalDegrain2(degrainTR=4, postFFT=3, fftthreads=8) # 9.2fps
Prefetch(8)

TemporalDegrain2(degrainTR=3, postFFT=3, fftthreads=8) # 12.5fps
TemporalDegrain2(degrainTR=2, postFFT=3, fftthreads=8) # 17.3fps

TemporalDegrain2(degrainTR=3, postFFT=3) # 10.1fps
TemporalDegrain2(degrainTR=2, postFFT=3) # 14.0fps



Wolfberry has ported TemporalDegrain2 to VapourSynth (https://forum.doom9.org/showthread.php?p=1858274#post1858274). Here are now some numbers with the VS version:

TemporalDegrain2(degrainTR=3, postFFT=3) # 22.3 fps
TemporalDegrain2(degrainTR=2, postFFT=3) # 27.4 fps

A solid +10fps :eek:


Edit: can't test tr=4 for now + it would be only with float sample type
Edit2:
clip=mvf.Depth(clip,32)
clip=hnw.TemporalDegrain2(clip, degrainTR=4, postFFT=3) # 6.6fps and 7gb ram :D
clip=hnw.TemporalDegrain2(clip, degrainTR=4, postFFT=03) # 9fps

[tormento]

A solid +10fps :eek:
Too much for a simple conversion. Perhaps there's a issue somewhere like what happen for z.lib (or was it color conversion? can't remember).

[ChaosKing]

Too much for a simple conversion. Perhaps there's a issue somewhere like what happen for z.lib (or was it color conversion? can't remember).

Same source, same format YV12. But my CPU is at max util, whats the difference. VS just scales better with more cores.

[pinterf]

Same source, same format YV12. But my CPU is at max util, whats the difference. VS just scales better with more cores.
The search method and parameters were not the same in VS and AVS versions, I reported it.

After having the same parameters, I still don't like how it works under Avisynth+ MT at degrainTR2 or 3 settings. Reorganized the AVS code to use similar methods like the VS port, such as creating standalone bv1,2,3 and fv1,2,3 vector clips and use them in MDegrain1,2,3 instead of creating one mvmulti clip, and use different MCompensate structures and Interleaving them. Probably it became better but still laggy, seems that if there were short deadlocks or ineffective cache usage, but I really don't know what happens.

[tormento]

Is there any optimization but degrainPlane=0 to denoise a b/w movie?

[ErazorTT]

well I havn't put much work into bw movies, so no there is no optimization for that.

[ErazorTT]

Reorganized the AVS code to use similar methods like the VS port, such as creating standalone bv1,2,3 and fv1,2,3 vector clips and use them in MDegrain1,2,3 instead of creating one mvmulti clip, and use different MCompensate structures and Interleaving them.

I tested that and for me it makes just no difference. But look for yourself: TemporalDegrain-v2.1.4a.7z (https://drive.google.com/open?id=1SdzDnwhw-7hIHo_4FaaJCYhhwCQCokpV)
This script is to be used just for TR up to 4. I was too lazy to write the MCompensate part for up to 6...

[pinterf]

Since then I experimented a bit. The clip dependencies are very special in this script. During my tests I made a parameter for MDegrain to tell it whether the forward or the backward vectors should requested first and in what order (e.g Backward3 B2 B1 Forward1 F2 F3 sequence vs. F3 F2 F1 B1 B2 B3), thus changing which frame is waiting for which other earlier frame. I was able to double the fps but it was not consistent and clearly, this hack is not a solution. Avisynth kind of multithreading and GetFrame logic makes a huge difference for this specific script and makes it inferior compared to Vapoursynth which is able to start requesting the necessary frames parallel instead of requesting them in a serialized, blocking way.

[tormento]

Since then I experimented a bit.
Did you try with Neo fork?

[pinterf]

Yes, the theory is the same.

[ErazorTT]

The title says it all! :D The links on the first post where updated.

Not much speed degredation using high bits due to the possibility to use have the MAnalyze part on 8 bits and the MDegrain in high bits.

[ErazorTT]

Could someone please take care of the pending approval of the downloads on the first post? Greets!

[alexx7777]

I do not understand how to apply TemporalDegrain2 with Qtgmc?

[Zarxrax]

I'm having some trouble getting this script to run.
It says "Script Error: There is no function named 'BitsPerComponent'."
I am using Avisynth+ 32bit, and have installed all of the required and optional plugins that the script lists.
Sorry for the basic question, its been 5+ years since I've touched avisynth, and I've spent all day trying to get everything set up and try out new scripts :)

[StainlessS]

You running latest (r2772) ?

try

Return Version

Current (r2772) :- https://github.com/pinterf/AviSynthPlus/releases

but suggest this one instead (Latest test):- https://drive.google.com/file/d/14DJyF9NFPtwU9almef3LX9jCssDt3VeF/view
[I always get a message from Pinterf GDrive files "Whoops, there was a problem with Preview", but download still works]

Pinterf said he will up a new build next week.

[Zarxrax]

You running latest (r2772) ?

try

Return Version

Current (r2772) :- https://github.com/pinterf/AviSynthPlus/releases

but suggest this one instead (Latest test):- https://drive.google.com/file/d/14DJyF9NFPtwU9almef3LX9jCssDt3VeF/view
[I always get a message from Pinterf GDrive files "Whoops, there was a problem with Preview", but download still works]

Pinterf said he will up a new build next week.

Ah, I was on r1576 that I got from http://avs-plus.net/, it seemed like an official site, but I guess not? Working now, thanks!

[StainlessS]

Yep, Pinterf dont have control over avs-plus.net. (and you get latest from devs forum Avs+ thread [but not the one in 1st post linking to avs-plus.net], from Pinter sig [below any of his posts]).

[Zarxrax]

If I use postFFT=4, this produces a green line along the bottom of my video. Is it possible to fix this? I thought this might be because my vertical resolution of 1080 is not mod 16, but it turns out that the green line is there even if I crop some pixels before applying the filter.

[ChaosKing]

If I use postFFT=4, this produces a green line along the bottom of my video. Is it possible to fix this? I thought this might be because my vertical resolution of 1080 is not mod 16, but it turns out that the green line is there even if I crop some pixels before applying the filter.

sounds like an old masktools plugin. Make sure you have the lastest version. https://github.com/pinterf/masktools/releases and https://github.com/pinterf/fft3dfilter


EDIT:
(postFFT == 4) ? DT_KNLMeansCL( lsbd ? noiseWindow.Dither_convert_8_to_16() : noiseWindow, a=2, d=postTR, h=postSigma*0.5, Luma = LumaNoise, Chroma = ChromaNoise, stacked=lsbd, device_type="GPU", device_id=knlDevId) : \
noiseWindow.HQDn3D(0,0,4,1)

It uses KNLMeansCL and HQDn3D

[Zarxrax]

I downloaded all the plugins from the links right in the script. I just double checked everything to make sure. I made double sure that the KNLMeansCL and HQDn3D files were the latest versions.

[Groucho2004]

I downloaded all the plugins from the links right in the script. I just double checked everything to make sure. I made double sure that the KNLMeansCL and HQDn3D files were the latest versions.Run the Avisynth Info Tool (https://forum.doom9.org/showthread.php?t=176079), save the log file and post it.

[Zarxrax]

Run the Avisynth Info Tool (https://forum.doom9.org/showthread.php?t=176079), save the log file and post it.
Log file attached

[Groucho2004]

Log file attachedIt might take a while for a mod to approve the attachment. I suggest you post it on pastebin.

[tebasuna51]

Log file approved.

[Groucho2004]

Log file attached

Nothing obvious but remove these and try again:
C:\Program Files (x86)\AviSynth+\plugins\RemoveGrainS.dll [2005-08-01]
C:\Program Files (x86)\AviSynth+\plugins\RepairS.dll [2005-08-01]

[real.finder]

Nothing obvious but remove these and try again:
C:\Program Files (x86)\AviSynth+\plugins\RemoveGrainS.dll [2005-08-01]
C:\Program Files (x86)\AviSynth+\plugins\RepairS.dll [2005-08-01]


if that the case, that because avs+ not really load the plugins folders as this order

PluginDir+ in Software/Avisynth in HKEY_CURRENT_USER
PluginDir+ in Software/Avisynth in HKEY_LOCAL_MACHINE
PluginDir2_5 in Software/Avisynth in HKEY_CURRENT_USER
PluginDir2_5 in Software/Avisynth in HKEY_LOCAL_MACHINE

but it did load from PluginDir2_5 first as you said here (https://github.com/pinterf/AviSynthPlus/issues/11#issuecomment-334964527)

[Zarxrax]

Removing those didn't help, but I did find a way around the problem by doing colorspace conversion to YV12 after TemporalDegrain2 rather than before.

[Tima]

Is there a way to use TemporalDegrain2 in conjunction with QTGMC for interlaced sources?

What QTGMC Denoising settings would you recommend for this scenario?

[hello_hello]

For myself, I added an Avisynth+ check to TemporalDegrain2 so it'll play with Avisynth 2.6 again (I still use it occasionally). For anyone who cares, lines 114 to 121 in the script look like this:

postTR = (postFFT > 0) ? postTR : 0
postTD = postTR * 2 + 1
maxTR = (degrainTR > postTR) ? degrainTR : postTR
LumaNoise = (degrainPlane == 0) || (degrainPlane == 4)
ChromaNoise = (degrainPlane > 0) ? true : false
inHighBits = input.BitsPerComponent()>8
postDither = inHighBits ? 0 : postDither

Replacing the above with the following text bypasses the "no function named 'BitsPerComponent" error the script would otherwise produce for Avisynth 2.6

IsAvisynthPlus = (FindStr(LCase(VersionString()), "avisynth+") > 0) || (FindStr(LCase(VersionString()), "avisynth neo") > 0)
postTR = (postFFT > 0) ? postTR : 0
postTD = postTR * 2 + 1
maxTR = (degrainTR > postTR) ? degrainTR : postTR
LumaNoise = (degrainPlane == 0) || (degrainPlane == 4)
ChromaNoise = (degrainPlane > 0) ? true : false
inHighBits = IsAvisynthPlus && input.BitsPerComponent()>8
postDither = inHighBits ? 0 : postDither

There's only a line added to the top and one line changed, but replacing a block of text doesn't require much explaining.

[Forteen88]

I wonder, what's the recommended setting for less degraining than using the setting: TemporalDegrain2(grainLevel=false) ?
I thought that TemporalDegrain2 degrained too much on a movie (the old first Star Wars, not the crappy new SJW-SW), even with that setting.

Here are some comparisons for SW-Episode 5 Blu-ray.

Screenshot frame20000, Source, cropped:
http://www.imagebam.com/image/cb40bf1333459603

Screenshot frame20000, Source, cropped, TemporalDegrain2(grainLevel=false):
http://www.imagebam.com/image/c467bf1333459870

Screenshot frame20000, Source, cropped, TemporalDegrain2():
http://www.imagebam.com/image/d2baa61333459983

[kedautinh12]

Here have neo-Dfttest and neo-fft3dfilter with more developer, can you add this in script??
https://forum.doom9.org/showthread.php?t=181294

[magnetite]

Looks like the OP hasn't been seen since early 2019 according to his profile.

[crystalfunky]

How can I include this in Staxrip? Sry I'm a beginner.

[Groucho2004]

How can I include this in Staxrip?Your best bet is most likely posting this in the staxrip thread.

[stax76]

It's included in the next build.

The customization needs basic understanding of the INI format and about avisynth in general, here is guide regarding another plugin:

https://forum.doom9.org/showpost.php?p=1913616&postcount=1893

All the dependencies are included in the last version and staxrip uses smart/automatic dependency detection/loading, it will parse the avsi file to figure out which dependencies it has and then add the required LoadPlugin and Import calls.


[Noise]

TemporalDegrain2 =
Import("D:\Projekte\VB\staxrip\bin\Apps\Plugins\AVS\TemporalDegrain2\TemporalDegrain2.avsi")
TemporalDegrain2(degrainTR=2, postFFT=3, postSigma=3)

[crystalfunky]

Thanks for your effort.
Unfortunately it doesn't work.
I get the following error: 1 (0x1)
Unzulässige Funktion (improper function)
when I start the encoding process.

[stax76]

It's something specific to your system, it works here with portable avisynth 3.6.1-test-8 and x265 (using avs2pipemod).

staxrip supports this also in vapoursynth btw., there is no profile for it included but the dependencies are included and it's easy to create a profile, this vapoursynth code works:

clip = G41Fun.TemporalDegrain2(clip)

[Tima]

Does VapoursSynth G41Fun.TemporalDegrain2() port support interlaced video?

From the code, I see no reasons to not support it (and trying it on real footage shows good results for me), but I don't fully understand the algorithm details (incl. why AVS version doesn't support it), so I'm not sure about this.

[Cary Knoop]

Does VapoursSynth G41Fun.TemporalDegrain2() port support interlaced video?

From the code, I see no reasons to not support it (and trying it on real footage shows good results for me), but I don't fully understand the algorithm details (incl. why AVS version doesn't support it), so I'm not sure about this.
As long as you separate the fields first.

[poisondeathray]

The problem with only separating fields, then applying a filter is the even/odd field offset (Even/odd scanlines). Temporal filtering is not ideal when each subsequent field goes up/down

The problem with separating fields then grouping even/odd to be filtered separately is you don't get temporal filtering across fields. This can introduce temporal inconsistency

The other approach is to double rate deinterlace then filter, and possibly reinterlace - but then you have to deinterlace

Each approach has pros/cons

[Cary Knoop]

The other approach is to double rate deinterlace then filter, and possibly reinterlace - but then you have to deinterlace

You are right that is the better, way.

Personally I would use the following in case of "interlaced" processing of a filter:

c = core.yadifmod.Yadifmod(c, order=1 if tff else 0, mode=1, edeint=core.nnedi3.nnedi3(c, field=3 if tff else 2, nns=0))
c = Filter(c)
c = core.std.DoubleWeave(c, tff=tff)[::2]

[Tima]

Thanks!
Looking at the QTGMC code, the best way would be to incorporate TemporalDegrain2 denoising as one of the methods into QTGMC pipeline.
I wonder, how hard would it be.

[Cary Knoop]

Thanks!
Looking at the QTGMC code, the best way would be to incorporate TemporalDegrain2 denoising as one of the methods into QTGMC pipeline.
I wonder, how hard would it be.
It's a bit of a catch-22, because in order to do a good temporal denoising you would want to deinterlace first. :)

I usually denoise first, and then call QTGMC with a very low sigma as I do not like a deinterlace filter deliver a denoised clip.

[Tima]

QTGMC does a very good job on extracting MV from the interlaced clip.
It's much better than you can achieve with TD2, because it uses QTGMC MV extraction simplified for the progressive input case (and pre-deinterlacing with stuff like Yadif seems suboptimal).

As for denoising, QTGMC seem to use just the last (postFFT) part from the TD2 pipeline, without 2-stage MDegrain part.

My point is that TD2 borrows MV part from QTGMC -- maybe it's time to contribute the denoising from TD2 to QTGMC :)

[VoodooFX]

There is few deal breaking visual bugs with TD2. Some kind of ugly artifacts before scene change, and some "special effects" introduced around "flicker" frame. Every time I tried it I noticed one or another, that's why I never used it for actual encode.

[kedautinh12]

I moded temporaldegrain2 replaced fft3dfilter, dfttest, to neo-fft3d, neo-dfttest. Let's waiting for him comback
https://github.com/kedaitinh12/AVSPlus-Plugins/blob/master/TemporalDegrain-v2.2.1MOD.avsi

[kedautinh12]

Forgot, use mod ver with neo-fft3d and neo-dfttest here:
https://forum.doom9.org/showpost.php?p=1923091&postcount=153

[magnetite]

Something I noticed while using this plugin was there was no staggered denoising. You can denoise all planes, but I don't think there's a way to denoise luma a little bit, and chroma a lot, and vice versa.

[ErazorTT]

QTGMC does a very good job on extracting MV from the interlaced clip.
It's much better than you can achieve with TD2, because it uses QTGMC MV extraction simplified for the progressive input case (and pre-deinterlacing with stuff like Yadif seems suboptimal).

As for denoising, QTGMC seem to use just the last (postFFT) part from the TD2 pipeline, without 2-stage MDegrain part.

My point is that TD2 borrows MV part from QTGMC -- maybe it's time to contribute the denoising from TD2 to QTGMC :)

Yeah, TD2 was only thought for progressive clips. And yes, probably all this should actually be integrated into QTGMC. Will probably need to contact QTGMCs author for that. BTW: just push a new update. Cheers.

[ErazorTT]

Forgot, use mod ver with neo-fft3d and neo-dfttest here:
https://forum.doom9.org/showpost.php?p=1923091&postcount=153

Ok will look at it. Have too yet see what neo improved over the originals.

[kedautinh12]

Ok will look at it. Have too yet see what neo improved over the originals.

It's old. New ver neo here:
https://github.com/HomeOfAviSynthPlusEvolution

And here:
https://forum.doom9.org/showthread.php?t=181294

[kedautinh12]

FFT3dGPU now support > 8 bit
https://github.com/pinterf/FFT3dGPU

[ErazorTT]

FFT3dGPU now support > 8 bit
https://github.com/pinterf/FFT3dGPU

ok, done

[ErazorTT]

It's ole. New ver neo here:
https://github.com/HomeOfAviSynthPlusEvolution

And here:
https://forum.doom9.org/showthread.php?t=181294

yeah ok, so the advantage is the support of AVX2? I am asking because I see that the "old" versions are also still maintained.

Anyhow, I just added them in v2.2.5.

[ErazorTT]

There is few deal breaking visual bugs with TD2. Some kind of ugly artifacts before scene change, and some "special effects" introduced around "flicker" frame. Every time I tried it I noticed one or another, that's why I never used it for actual encode.

Perhaps you will find time to be more specific?

[kedautinh12]

Thanks for your update

[VoodooFX]

Perhaps you will find time to be more specific?

First bug: Glitch on frames before some scene changes. I think parts of a scene change frame appears in the previous frames (bigger tr - more previous frames affected). This one I noticed many times.

Second bug: Around a "flicker" frame. I think like when one(few?) frame has sudden change in brightness then result is kinda slowmo "flicker" effect. This one I noticed only the few times.

[ErazorTT]

Well I just checked again with degrainTR up to 5 (which is way too much for any 24fps clip, you never should need more than 3) and neither at flicker frames nor at scene chnages have I experianced that. :confused:

[joearmstrong]

Maybe the same issue I noticed:

It's a general problem using any temporal filter: There are inaccuracies in fast scene changes - they are a bit noisier than the other frames. With radius 1 there is 1 frame before/after noisier, with radius 3 there are 3 frames before/after noisier, etc. Using a spatial filter instead of a temporal one solves the issue, but that's not a solution for me.
I know it's a natural effect specific to the end and beginning of a scene. Probably many people don't notice it - but I notice it when watching the encoded video on my screen - is there any possibility to fix or reduce this temporal related issue?

The described "flicker" effect I cannot confirm.

[tormento]

Maybe the same issue I noticed
With temporal denoise, on scene change, you can't define a "before" frame span. Thus the denoising is strongly affected. I don't even know if there could be a possile fix.

[joearmstrong]

I thought so. Then I shoud probably deal with spatial denoising because of the disturbing noisier scene changes. Or is there a better alternative?

[VoodooFX]

Well I just checked again with degrainTR up to 5 (which is way too much for any 24fps clip, you never should need more than 3) and neither at flicker frames nor at scene chnages have I experianced that. :confused:
My bad that I didn't made screens and samples, I thought that you are not active on it anymore, I'll try to do some tests.
When I tested the issue it appeared with any TR, it was not like joearmstrong described.
Now that I think about it, maybe it's coincidence, both issues appeared on the "black-and-white" clips.

[real.finder]

Maybe the same issue I noticed:

It's a general problem using any temporal filter: There are inaccuracies in fast scene changes - they are a bit noisier than the other frames. With radius 1 there is 1 frame before/after noisier, with radius 3 there are 3 frames before/after noisier, etc. Using a spatial filter instead of a temporal one solves the issue, but that's not a solution for me.
I know it's a natural effect specific to the end and beginning of a scene. Probably many people don't notice it - but I notice it when watching the encoded video on my screen - is there any possibility to fix or reduce this temporal related issue?

The described "flicker" effect I cannot confirm.

SMDegrain has mfilter parameter for these cases

[joearmstrong]

SMDegrain has mfilter parameter for these cases

I tested SMDegrain with mfilter parameter but I didn't notice an improvement - during some fast scene changes I tested the problem remains the same.
Maybe I am doing something wrong? What would be a recommended setting for the mfilter parameter to improve scene changes?

[tormento]

SMDegrain has mfilter parameter for these cases
One though just blinked in my mind... and if on scene change we could apply temporal filter on reverse stream? Such as a Tenet movie, if you watched it... Lot of decoders are capable of frame accurate rendering, could you think about the feasibility of it?

[real.finder]

What would be a recommended setting for the mfilter parameter to improve scene changes?

don't know how you use it but just feed it with spatial filter clip you talk about
Using a spatial filter instead of a temporal one solves the issue, but that's not a solution for me.
I know it's a natural effect specific to the end and beginning of a scene.

so it will be like Spatio-Temporal Denoiser, it will give you the best of the 2

[joearmstrong]

don't know how you use it but just feed it with spatial filter clip you talk about


so it will be like Spatio-Temporal Denoiser, it will give you the best of the 2


Not working for me. I'm using this script:
pre=neo_vd ()
SMDegrain(RefineMotion=true, lsb=true, Contrasharp=false, prefilter=2, mfilter=pre, blksize=16,truemotion=false, plane=0, chroma=false)

Using spatial filter neo_vd (Neo Vague Denoiser) only results in correct scene changes. Using it in SMDegrain with mfilter introduces the noisier scene changes issue.

[real.finder]

Not working for me. I'm using this script:
pre=neo_vd ()
SMDegrain(RefineMotion=true, lsb=true, Contrasharp=false, prefilter=2, mfilter=pre, blksize=16,truemotion=false, plane=0, chroma=false)

Using spatial filter neo_vd (Neo Vague Denoiser) only results in correct scene changes. Using it in SMDegrain with mfilter introduces the noisier scene changes issue.

then try use http://avisynth.nl/index.php/RemoveDirt#SCSelect with it

org=last
pre=neo_vd ()
SMDegrain(RefineMotion=true, lsb=true, Contrasharp=false, prefilter=2, mfilter=pre, blksize=16,truemotion=false, plane=0, chroma=false)
org.SCSelect(pre, pre, last)

[joearmstrong]

then try use http://avisynth.nl/index.php/RemoveDirt#SCSelect with it

org=last
pre=neo_vd ()
SMDegrain(RefineMotion=true, lsb=true, Contrasharp=false, prefilter=2, mfilter=pre, blksize=16,truemotion=false, plane=0, chroma=false)
org.SCSelect(pre, pre, last)

Unfortunately that didn't work either. The frames concerned are now even noisier than before.
My Knowledge so far: Using just a spatial denoiser doesn't worsen the quality of scene changes. Using a temporal denoiser results in some noisier frames during scene changes.

[ErazorTT]

If I may enter the discussion here. I have checked the worst of all grainy film (300) and there at scene changes I must say that, yeah perhaps there is a very slight increase of remaining grain but I doubt this will be seen when not at 400% zoom.
So please also just try this:
TemporalDegrain2(degrainTR=2)
or even
TemporalDegrain2(degrainTR=3)

With increasing TR the degraining capability increases but the impact of scene changes decreases. So 3 cleans more than 2 which cleans more than 1 but the impact of a scene change is pretty strong for 1 less so for 2 and only minor for 3.

So to be very much independent of scene changes you could use 3. Then perhaps there might be too much cleaning for your taste, but in this case you could then mix some of the original back into the resulting clip, like that:
TemporalDegrain2(degrainTR=3, postMix=25) [postMix was broken before release 2.3.0 so you'd need to grab this newest one]

Meaning that 25% of the original will be mixed with 75% of the filtered result.

I am just looking at scene changes here and not at what VoodooFX discribed as "flicker" frames. These singular flicker frames basically represent 2 scene changes, one just before and one just after that fliker frame. These will be always very hard to deal with. There is simply not enough information to figure out if the things shown are grain, noise, or actually part of the image. Only way there would be a neuronal network which was trained on the noise during the movie and which is then applied to these singular frames. I have no idea but this sounds a lot like what I just described: http://www.avisynth.nl/users/vcmohan/NeuralNet/NeuralNet.html

[StainlessS]

I saw people using ScSelect in this thread, and it prompted me to make and post this mod.
(I was never a big fan of ScSelect, it makes too many false detect mistakes)

EDIT: Script removed.
Moved to thread here:- https://forum.doom9.org/showthread.php?t=182392

[Tenkei]

I wanted to point that FFT3DGPU requires mode to be 1 to utilize ow and oh. Also precision should be set to 2 to match the CPU version. According to the author, ow must be even but that won't be the case when grainLevel is set to 1.

One more thing, I don't think multiplying ppSAD1 and ppSAD2 when DCT=5 is a good idea. With default setting I noticed a huge banding and artifacts on scene change. The colors are also inaccurate. Using different grainLevels didn't help.

It got better when I removed the multiplication code. See:

https://i.postimg.cc/F7fLrXT8/Source.pngSource (https://postimg.cc/F7fLrXT8)
https://i.postimg.cc/XrdB5cSg/Default.pngDefault settings (https://postimg.cc/XrdB5cSg)
https://i.postimg.cc/3dPDWf6R/No-Multiplier.pngDefault settings with no multiplier (https://postimg.cc/3dPDWf6R)

[VoodooFX]

With default setting I noticed a huge banding and artifacts on scene change.
Does those artifacts propagate into frames before scene change?

[Roemer]

First of all: Many thanks for your script!
I am although running in an issue:
I need to use TemporalDegrain2 multiple times and it throws an exception about "Multiple QTGMC Calls". I found out that QTGMC provides an option to pass the name of the variables it should us or that it should reuse the existing variables. Is there anyway to pass that to your script as your script internally uses TemporalDegrain2?
Thanks for help.

[lollo2]

I did the following in TemporalDegrain-v2.2.1.avsi:

# changed
# from ReplaceGlobals = false
# to ReplaceGlobals = true
# to solve QTGMC error "Multiple calls to QTGMC, set PrevGlobals="Replace" or read documentation on 'Multiple QTGMC Calls'"

[kedautinh12]

new ver of hqdn3d support HBD: https://github.com/Asd-g/hqdn3d

[kedautinh12]

ExTools now can replace MaskTools2 for improve speed in HBD
https://github.com/Dogway/Avisynth-Scripts/blob/master/ExTools.avsi

[kedautinh12]

New port filter from Vapoursynth BM3D CPU and GPU ver
https://github.com/WolframRhodium/VapourSynth-BM3DCUDA/issues/7#issuecomment-886173346

[StainlessS]

kedautinh12,
You seem to have missed hqdn3d update [v1.0.1] 3 days after [15 April 21] your post #187,
link in kedautinh12 post #187.

[kedautinh12]

kedautinh12,
You seem to have missed hqdn3d update [v1.0.1] 3 days after [15 April 21] your post #187,
link in kedautinh12 post #187.

I only share link for ErazorTT when he online he will catch it. I got last ver when Asd-g released it

[kedautinh12]

As I could observe BM3D is better at motion estimation and probably also at denoising.

[kedautinh12]

fmtconv available avs+ now, maybe replace dither
https://forum.doom9.org/showthread.php?t=183139

[kedautinh12]

I moded TemporalDegrain2 use BM3D, details in description
https://github.com/kedaitinh12/AVSPlus-Plugins/blob/master/TemporalDegrain-v2.3.1MOD.avsi

Still waiting for ErazorTT :D

[coolgit]

TemporalDegrain2(degrainTR=1, postFFT=4, postSigma=2, fftThreads=8) produce a slight shift in colour and weird frame blending during 1st and last frame of scene changes.

The orange/brown colour not suppose to be there.

[VoodooFX]

Upload those images to imgur or you'll wait forever for approval. :)

[Sangen]

I wonder why it takes so long for approval here

[Boulder]

Sometimes the best way to get them approved is to report the post and ask for the approval :)

[coolgit]

Changed the links as post 195 is still pending approval.

https://i.ibb.co/NFc0VbY/001029.jpg

https://i.ibb.co/ZhBmqwP/001030.jpg

[baka1]

Impressed with the denoiser!
https://slow.pics/c/Q4culaDS
Raw BD vs TR1 vs TR2

[Kurosu]

The thSCD2 (at least) seems to produce very unstable results. I get heavy ghosting because of scene changes with the default value, as observed by many here. I observed sequences where much lower values are needed. In any case, it seems heavily dependent on grainLevel and degrainTR, and likely other parameters (postFFT):
* grainLevel=0,degrainTR=3 => thSCD2=80
* grainLevel=0,degrainTR=2 => thSCD2=90

I haven't checked ppSCD1/thSCD1 yet.

[VoodooFX]

The thSCD2 (at least) seems to produce very unstable results. I get heavy ghosting because of scene changes with the default value, as observed by many here.
Any samples? So far I didn't see samples similar to what I've observed - huge parts of a next scene are propagated into a previous scene (if I remember it correctly).

[Kurosu]

None that can be shared and that I kept, unfortunately. The sequence was blurry, but I suspect this just means the scene change metric is just far from perfect.

[Kurosu]

Here's something:
https://mega.nz/file/i40AhIzD#RUn7UcuwIhHRAVkss5nRS1lI9B_tg3Vff6PAkD4uCsA

Playing with ppSCD1 and thSCD2, as in the associated script, is required otherwise heavy ghosting occurs.

[Kurosu]

And for people wanting to know what the big deal is, see this (lossless images are not needed to see the point):
https://imgur.com/a/LIjWU2O

[VoodooFX]

And for people wanting to know what the big deal is, see this (lossless images are not needed to see the point):
https://imgur.com/a/LIjWU2O
That's exactly what I was talking about. Noticed this on every encode I tried, with TR1, TR2.

[ErazorTT]

And for people wanting to know what the big deal is, see this (lossless images are not needed to see the point):
https://imgur.com/a/LIjWU2O

And that issue is then improved by lowering thSCD2?

[ErazorTT]

I wanted to point that FFT3DGPU requires mode to be 1 to utilize ow and oh.
I actually thought that mode 1 was the default! Are there versions where it's not the default?


Also precision should be set to 2 to match the CPU version.

I wasn't aware of that, but sure, now that I read it, absolutely! Will change it.


According to the author, ow must be even but that won't be the case when grainLevel is set to 1.

Again, I wasn't aware, will change.


One more thing, I don't think multiplying ppSAD1 and ppSAD2 when DCT=5 is a good idea. With default setting I noticed a huge banding and artifacts on scene change. The colors are also inaccurate. Using different grainLevels didn't help.

That difference in the returned values of SAD and SATD in areas where their answer should actually be the same (i.e. in areas of constant luminosity) and trying to make them somehow comparable has made me some sleepless nights actually.. :mad:
Was there a threshold where the output changed from one to the other, or was the change continuous with the change of the factor?

[ErazorTT]

I moded TemporalDegrain2 use BM3D, details in description
https://github.com/kedaitinh12/AVSPlus-Plugins/blob/master/TemporalDegrain-v2.3.1MOD.avsi


I'm getting the following errors when I try your code.

"propNumElements: This filter can only be used within run-time filters."
"Script Error: There is no function named 'MatchClip'."

What am I missing?

[ErazorTT]

Changed the links as post 195 is still pending approval.

https://i.ibb.co/NFc0VbY/001029.jpg

https://i.ibb.co/ZhBmqwP/001030.jpg

And that was only when using postFFT=4?

[ErazorTT]

Here's something:
https://mega.nz/file/i40AhIzD#RUn7UcuwIhHRAVkss5nRS1lI9B_tg3Vff6PAkD4uCsA

Playing with ppSCD1 and thSCD2, as in the associated script, is required otherwise heavy ghosting occurs.

Great that you posted that, so that I can try myself!

[kedautinh12]

You need update your latest ver of avs+ 3.7.1 test 34
https://forum.doom9.org/showthread.php?p=1909698#post1909698

And i forgot add TransformsPack.avsi to optional plugins
https://github.com/Dogway/Avisynth-Scripts/blob/852790754e
4ef7ae2cf0a5d520e8ce7b77da71d2/TransformsPack.avsi#L81

https://github.com/kedaitinh12/AVSPlus-Scripts/blob/master/TemporalDegrain-v2.3.1MOD.avsi

[ErazorTT]

ExTools now can replace MaskTools2 for improve speed in HBD
https://github.com/Dogway/Avisynth-Scripts/blob/master/ExTools.avsi

I'm using mt_lutxy, mt_makediff and mt_adddiff.
What is the performance assessment of these functions for 8bits? Are these also expected to run faster, or might it even be slower?

[ErazorTT]

You need update your latest ver of avs+ 3.7.1 test 34
https://forum.doom9.org/showthread.php?p=1909698#post1909698

And i forgot add TransformsPack.avsi to optional plugins
https://github.com/Dogway/Avisynth-Scripts/blob/852790754e
4ef7ae2cf0a5d520e8ce7b77da71d2/TransformsPack.avsi#L81

https://github.com/kedaitinh12/AVSPlus-Scripts/blob/master/TemporalDegrain-v2.3.1MOD.avsi

Ok, then I will release two versions: A v2.3.2 without BM3D being compatible to AviSynth 3.7.0, and a v2.4.0a with BM3D. I would like to also have the currently official version of AviSynth covered.

[kedautinh12]

I'm using mt_lutxy, mt_makediff and mt_adddiff.
What is the performance assessment of these functions for 8bits? Are these also expected to run faster, or might it even be slower?

You can check speed between them with avsmeter but you need use with latest ver avs+ cause it's added some perfomane improve in expr()

[ErazorTT]

I just pushed a new version (v2.3.2), this should especially address the scene change bug which was troubling quite some of you.
I needed to move back to SAD from SATD for that, since I apparently still do not have found a way to stably work with SATD. :(

Thanks to everybody here for trying things out, and coming forward when there is something fishy. I will also try to look more often here into the forum to see what's going on!

I am currently working on the 2.4.0 release for adding BM3D support and the usage of ExTools.

What I am currently finding quite troblesome is the finding from coolgit when using knlmeans, did anybody else experience this?

Changed the links as post 195 is still pending approval.

https://i.ibb.co/NFc0VbY/001029.jpg

https://i.ibb.co/ZhBmqwP/001030.jpg

[kedautinh12]

Just ask pinterf :D
https://forum.doom9.org/showthread.php?t=171379&page=75&highlight=KNLMEANSCL

[ErazorTT]

I just pushed the test releases 2.4.0alpha and 2.4.0beta.
alpha adds BM3D and beta adds ExTools on top.

In my tests ExTools is slightly slower then MaskTools (3.15fps vs 3.25fps) on my Zen2.

These can be grabbed from the download link at the first post of this thread.

[Dogway]

I don't think Expr() LUT calculations are still on par with masktools2 LUT, but I need to do more benchmarks, on 16-bit it should make a difference though.

[ErazorTT]

Just ask pinterf :D
https://forum.doom9.org/showthread.php?t=171379&page=75&highlight=KNLMEANSCL

I wasn’t implying that it might be on knlmeans, I thought perhaps there was something wrong with the way I was interacting with it. So that the error would be in my script calling knlmeans.

[coolgit]

And that was only when using postFFT=4?

I have gone back and tried all postFFT version and other setting such as sigma, tr etc and the error was the same as before.

Edit. Tried all the latest version and no changes. However 2.4.0 not tested as getting

Script Error

Script error: Expr does not have a named argument "lut"
(C:/Program Files (x86)/AviSynth/plugins64+/Extools.avsi, line 100)
\StaxRip\Apps\Plugins\AVS\TemporalDegrain2\TemporalDegrain2.avsi, line 268)

Edit.

2.40 doesn't work.

[kedautinh12]

I think you need update avs+ latest ver (3.7.1 test 34)
https://forum.doom9.org/showthread.php?t=181351

[coolgit]

I think you need update avs+ latest ver (3.7.1 test 34)
https://forum.doom9.org/showthread.php?t=181351

Thanks for that, working now.

[ErazorTT]

Edit. Tried all the latest version and no changes. However 2.4.0 not tested as getting

2.40 doesn't work.

Is there any way you could tell me what you are trying to encode? Could you provide me a snipet of that, like 100 frames or so?

[kedautinh12]

TemporalDegrain2(degrainTR=1, postFFT=4, postSigma=2, fftThreads=8) produce a slight shift in colour and weird frame blending during 1st and last frame of scene changes.

The orange/brown colour not suppose to be there.

Can you share video sample??

[coolgit]

Here the link. There should be two scene changes defects.

https://mega.nz/file/qqQTSCZJ#tDyQR8l-BqJAAUY-LB_4kn115R7KgtqNUo8Dm9KNA8I

[kedautinh12]

Here the link. There should be two scene changes defects.

https://mega.nz/file/qqQTSCZJ#tDyQR8l-BqJAAUY-LB_4kn115R7KgtqNUo8Dm9KNA8I

i used your script and your example video but don't meet your problem from frame 7->10 (tested with 2.4.0alpha ver)

[kedautinh12]

Maybe you don't update all plugins to latest ver

[coolgit]

Staxrip

FFVideoSource("F:\TemporalDegrain2.avi", cachefile="F:\TemporalDegrain2_temp\temp.ffindex")
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
SetMemoryMax(1024)
threads=8
TemporalDegrain2(degrainTR=1, postFFT=4, postSigma=2, fftThreads=8)
Prefetch(8)

VDub2

FFVideoSource("F:\TemporalDegrain2.avi")
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
SetMemoryMax(1024)
threads=8
TemporalDegrain2(degrainTR=1, postFFT=4, postSigma=2, fftThreads=8)
Prefetch(8)

Frame 10 and 88, same errors.

[ErazorTT]

Frame 10 and 88, same errors.

Yes, its there in 10 and 88, I'm getting the same brown colors. This is due to the scene change detection (SCD). Either the per block SCD threshold is too high, or the per frame SCD threshold.
Changing ppSCD1 from 5 to 4 solves this or setting thSCD2 from 130 to 90. So it would appear that the default settings for ppSCD1 or thSCD2 are too high.

The per block scene detection is set by ppSCD1, which means that if each pixel in a block is more different than the value of ppSCD1 compared to the previous frame than this block calles for a scene change.
A scene change is triggered if more than thSCD/255*100 percent of all blocks in a frame call for a scene change.

Its not immediately clear to me if either ppSCD1 is too high of thSCD2 or both. But I would guess that thSCD2 is too high, so I would change that one.

PS: I found a better more general way, which takes the chroma changes better into account. Will push an update shortly.

[coolgit]

Yes, its there in 10 and 88, I'm getting the same brown colors. This is due to the scene change detection (SCD). Either the per block SCD threshold is too high, or the per frame SCD threshold.
Changing ppSCD1 from 5 to 4 solves this or setting thSCD2 from 130 to 90. So it would appear that the default settings for ppSCD1 or thSCD2 are too high.

The per block scene detection is set by ppSCD1, which means that if each pixel in a block is more different than the value of ppSCD1 compared to the previous frame than this block calles for a scene change.
A scene change is triggered if more than thSCD/255*100 percent of all blocks in a frame call for a scene change.

Its not immediately clear to me if either ppSCD1 is too high of thSCD2 or both. But I would guess that thSCD2 is too high, so I would change that one.

PS: I found a better more general way, which takes the chroma changes better into account. Will push an update shortly.


Tried:

ppSCD1=4 thSCD2=130 = failed
ppSCD1=5 thSCD2=90 = failed
ppSCD1=4 thSCD2=90 = pass

It is both that's too high.

From your file

thSCD2 = default(thSCD2, 130) #MVTools default of 130 is apparently too high

and yet you kept it at 130:confused::confused:

Well it is great that this is finally working, thanks for your efforts.

[ErazorTT]

From your file

thSCD2 = default(thSCD2, 130) #MVTools default of 130 is apparently too high

and yet you kept it at 130:confused::confused:

Well it is great that this is finally working, thanks for your efforts.

Yes, that was always some back and forth.. And eventually I forgot to remove that line.

I just pushed the v2.3.3, please try. For me it solves that issue, while the SCD settings all remains where they were (ppSCD1=5, thSCD2=130).

[coolgit]

2.3.3 worked.

I will be doing some episodes this week and will test using 2.3.3 and ppSCD1=4 thSCD2=90 and see which is more reliable.

[ErazorTT]

I will be doing some episodes this week and will test using 2.3.3 and ppSCD1=4 thSCD2=90 ...

I am trying to have them as far up as possible because if not, they may start losing useful frames. This might especially be the case in grainy source clips. So if you source clips are not very grainy, you should be able to reduce both somewhat. But for a general default I would think that having them higher up is better.

... and see which is more reliable.
I would guess (and hope) that 2.3.3 is more reliable than decreasing the SCD values.

[ErazorTT]

This release cuts down on banding and noise with the new default of postDither=2, which is especially significant for postFFT 1 and 2, but also measurable for the others.
If you every needed something else than postFFT 0, 1 or 2 you might try again. You should be able to get away with a somewhat decreased postSigma value. (In one instance I could decrease the value from 3 to 2.5 for the same output.)
(Attention, the values for postDither are now inverted, negative and positive values are swaped compared to all previous releases!)

BM3D is introduced as postFFT 5 in version 2.4.0. This is significantly helped by the above change, since it would have produced some quite unpleasant noise with the old dither behaviour (which can now be replicated with postDither=1).
This version does however need the current test releases of AviSynth.

[GB452]

Nice! v2.4.2 is working great. I wish it could be ported to VapourSynth as the much older TemporalDegrain in havsfunc isn't nearly as good.

[coolgit]

2.3.3 worked.

I will be doing some episodes this week and will test using 2.3.3 and ppSCD1=4 thSCD2=90 and see which is more reliable.

2.3.3 worked without any problems after doing 14 episodes since my last post.

[real.finder]

I wish it could be ported to VapourSynth as the much older TemporalDegrain in havsfunc isn't nearly as good.

keep in mind that most of times the vs (plugins or scripts) ports are not 100% same output as avs one (https://forum.doom9.org/showthread.php?p=1953277#post1953277)

[ErazorTT]

2.3.3 worked without any problems after doing 14 episodes since my last post.

Great to hear that! I would suggest to move to 2.3.4 however. Since the only change between 2.3.3 and that is the improvement due to the moved dithering mentioned in the change log. So while a regression is really very improbable, there is a measureable gain.

Nice! v2.4.2 is working great. I wish it could be ported to VapourSynth as the much older TemporalDegrain in havsfunc isn't nearly as good.

I’m sorry but I will not be able to be the one to port this over to VS, because I simply have exactly no experience with VS. The time to read into it simply does not appear worth it for me, since I’m very proficient in AS and currently don’t see a reason to move to VS.

[joearmstrong]

If I understand meAlg settings correctly, then hexagonal search is used by default. Using meAlg=7 should select umh (Uneven Multi Hexagonal search) and give a little quality boost. In my tests it was just a bit slower than the default meAlg=4.

1- Exhaustive search
2- Diamond search
3- Square search
4- Hexagonal search
5- Star-shaped search
6- Successive Elimination Algorithm (SEA)
7- Uneven Multi Hexagonal search (UMH)

Is this correct? I read that from https://forum.doom9.org/showthread.php?p=693742

[tebasuna51]

If I understand meAlg settings correctly, then hexagonal search is used by default. Using meAlg=7 should select umh (Uneven Multi Hexagonal search) and give a little quality boost. In my tests it was just a bit slower than the default meAlg=4.

1- Exhaustive search
2- Diamond search
3- Square search
4- Hexagonal search
5- Star-shaped search
6- Successive Elimination Algorithm (SEA)
7- Uneven Multi Hexagonal search (UMH)

Is this correct? I read that from https://forum.doom9.org/showthread.php?p=693742

Don't mistake meAlg with me x264 parameter showed in the post https://forum.doom9.org/showthread.php?p=693742

meAlg in TemporalDegrain-v2.3.4 is used like:

...
Search = meAlg
...
MAnalyse( isb=true, multi=true, delta=maxTR, blksize=BlockSize, overlap=Overlap, search=Search, ...

And search in MAnalyse is not exactly like me parameter:

search = 0 : 'OneTimeSearch'. searchparam is the step between each vectors tried ( if searchparam is superior to 1, step will be progressively refined ).
search = 1 : 'NStepSearch'. N is set by searchparam. It's the most well known of the MV search algorithm.
search = 2 : Logarithmic search, also named Diamond Search. searchparam is the initial step search, there again, it is refined progressively.
search = 3 : Exhaustive search, searchparam is the radius (square side is 2*radius+1). It is slow, but it gives the best results, SAD-wise.
search = 4 : Hexagon search, searchparam is the range. (similar to x264).
search = 5 : Uneven Multi Hexagon (UMH) search, searchparam is the range. (similar to x264).
search = 6 : pure Horizontal exhaustive search, searchparam is the radius (width is 2*radius+1).
search = 7 : pure Vertical exhaustive search, searchparam is the radius (height is 2*radius+1).

Then UMH is obtained with meAlg = 5

[joearmstrong]

Thank you for your help, tebasuna51! TemporalDegrain2's avsi-file linked to that page at meAlg parameters - I misunderstood.

I also tested again the scene change issue with noisier frames - ErazorTT's tip (post 181) to use degrainTR=3 and postMix helped a lot. For me this solved the issue.

So, I finally found my perfect settings for better compressibility:
SetFilterMTMode("TemporalDegrain2", MT_MULTI_INSTANCE)
ConvertBits(16)
crop(...)
TemporalDegrain2 (degrainTR=3, meAlg=5, postmix=50)
ConvertBits(8, dither=0)
Prefetch()

[Sharc]

TemporalDegrain2 throws an error when filtering interlaced footage like
separatefields()
e=selecteven().TemporalDegrain2()
o=selectodd().Temporaldegrain2()
interleave(e,o).weave()

The problem seems to be with multiple calls to QTGMC.

Any suggestion (other than deinterlacing)?

[Selur]

How can one call multiple TemporalDegrain2 instances in one script? (used in example to filter top and then bottom fields while not deinterlacing beforehand)
Since ReuseGlobals and ReplaceGlobals are statically set to false 'DT_SetUserGlobal' atm. TemporalDegrain2 crashes with:
"Multiple calls to QTGMC, set PrevGlobals="Replace" or read documentation on 'Multiple QTGMC Calls'"
(side note: the error message should be adjusted to not refer to QTGMC)

Is there a way to clean a global variable in Avisynth?

Cu Selur

[lollo2]

With AviSynth 2.60 and TD2 version 2.2.1 I did the following (second change seems appropriate):


# reference: http://forum.doom9.net/showthread.php?p=1890163#post1890163
#
# added IsAvisynthPlus = (FindStr(LCase(VersionString()), "avisynth+") > 0) || (FindStr(LCase(VersionString()), "avisynth neo") > 0)
# and changed
# from inHighBits = input.BitsPerComponent()>8
# to inHighBits = IsAvisynthPlus && input.BitsPerComponent()>8
# to run with AviSynth 2.6 instead of AviSynth+ bypassing the "no function named 'BitsPerComponent" error
#
# changed
# from ReplaceGlobals = false
# to ReplaceGlobals = true
# to solve QTGMC error "Multiple calls to QTGMC, set PrevGlobals="Replace" or read documentation on 'Multiple QTGMC Calls'"

[Selur]

Would be nice if the latest version would also be adjusted accordingly.

[Sharc]

# change
# from ReplaceGlobals = false
# to ReplaceGlobals = true
# to solve QTGMC error "Multiple calls to QTGMC, set PrevGlobals="Replace" or read documentation on 'Multiple QTGMC Calls'"

Thanks! This did the trick.

[Selur]

Sure, but it would probably be better to make it configurable since Reuse might make sense too (when applying TemporalDegrain2 two times in a row,...)

[ErazorTT]

New update which lets process luma and chorma differently. I found this to be helpfull when the chroma planes are much noisier (or have a drifferent type of grain) than the luma plane. Here is such an example.

That is the original:
https://i.postimg.cc/1nSjQJ3h/org.jpg (https://postimg.cc/1nSjQJ3h)

This is after adjusting the settings for a clean luma (grainLevel=2,degrainTR=2,postFFT=1,postSigma=2):
https://i.postimg.cc/Bj8ycjVy/gl2tr2ps2.jpg (https://postimg.cc/Bj8ycjVy)
It is very clear how much chroma noise is left. And if you compare with the original, you see that the chroma noise is also of completly different nature, noise "blobs" are much bigger than on the luma plane.

After setting the new parameter divSADc=1 and adjusting the new parameter postSigmaC to 8 (grainLevel=2,degrainTR=2,postFFT=1,postSigma=2,divSADc=1,postSigmaC=8):
https://i.postimg.cc/sB7Nqty4/gl2tr2ps2d1psc8.jpg (https://postimg.cc/sB7Nqty4)
The parameter postSigmaC allows to set the strength of the fft post processing to a separate value for the chroma planes. This will however invoke two calls which will slow down the processing significantly.

A viable solution without the performance impact would be to only set divSADc=1, which will yield the following result (grainLevel=2,degrainTR=2,postFFT=1,postSigma=2,divSADc=1):
https://i.postimg.cc/jDG18sVj/gl2tr2ps2d1.jpg (https://postimg.cc/jDG18sVj)

[Dogway]

I know those yellow stain artifacts, I used to clean them with NeatVideo before which worked very good, but I just ported CCD(), gave it a try and found it to perform very good.
src=last
CCD(30,HD=true)
CombinePlanes(src, last, src, planes="YUV")

[kedautinh12]

I seen different between 2.4.3 and 2.5.1 in list download about changelogs and DT_BM3D function

[ErazorTT]

I removed again the paramter divSADc to make things easier for the user. Improved cleanup of the chroma planes generally. No performance impact (<1% speed difference).
The right selection of grainLevel has now however somewhat gained in importance.

With the same parameters as in the second picture of my previous post this leads to the following result (grainLevel=2,degrainTR=2,postFFT=1,postSigma=2):
https://i.postimg.cc/H8XHH5j8/2-6-0-gl2tr2ps2.jpg (https://postimg.cc/H8XHH5j8)
This result is right inbetween the last two pictures of my previous post!

[kedautinh12]

After got latest ver i got errors when use with postFFT=4 i got what 'devID' means, with postFFT=5 i got what 'devID' means and what 'cuda' means

[ErazorTT]

Yeah, right. I fixed it now in v2.6.2.

[StvG]

v2.6.2 - line #483:
ch ? output.MatchClip(a) : output.mergechroma(a)

What is the filter MatchClip?

[kedautinh12]

v2.6.2 - line #483:
ch ? output.MatchClip(a) : output.mergechroma(a)

What is the filter MatchClip?

It's is script from Dogway
https://github.com/Dogway/Avisynth-Scripts/blob/c113ff30e37f47d8117c1b3db8f00599cc62e267/TransformsPack%20-%20Main.avsi#L110

And other scripts from Dogway to work MatchClip functions

[StvG]

Thanks. I did see the optional plugins.

[ErazorTT]

main change is that by default its now possible to use multiple instances. For example for using different settings on different parts of the clip. Depending on the settings, this will need a lot of memory!

[mastrboy]

Is there a github or similar page for this? This forum is very slow at approving attachements: Attachments Pending Approval: File Type: zip TemporalDegrain-v2.6.3.zip

[Zetti]

You can grab it from his Google Drive in post 1

[PatchWorKs]

@ErazorTT Out of curiosity: do you think is possible to speedup your great software by using QuickSync instructions ?

[Selur]

in Temporal Degrain v2.6.3 line 202:
outputStage= default( outputStage, 2 ) # [0, 2] you can decide to skip the processing of later stages and directly output the clip as process of the stage given: 0= output after first degraining, 1= output after second degraining, 2= output after FFT post processing, 3= output after contra sharpening (that's the last stage and the default)
-> text says 3 is default, but code says range is 0-2 and default is 2.

[cork_OS]

UPD: wrong info

[Selur]

works fine here with google drive,.. (might be blocked due to you location)

[StainlessS]

I quite often have small probs downloading from Google Drive, but usually starts eventually if you give it a minute or so,
works better if you're signed in to your Google account. (I usually stay signed out unless required)

Maybe some kind of punishment for not being signed in,
Hotmail, on signing in using non MS Edge browser, just hangs for about 30 seconds (or is it 60), punishment for not using Edge [EDIT: Zero network activity until punishment ends].
(I usually start it up before I want to use it, and switch back to what I was doing for a couple of minutes so that it will have dished out sufficient punishment.)

EDIT: Above Hotmail Edge punishement thing, is where (my) MS telemetry is disabled/crippled, perhaps Edge also passes telemetry and where not using edge, then
attempts standard MS telemetry spyware stuff until it figures out that it is also blocked.

[anton_foy]

Trying to understand the TemporalDegrain2-script as it works really well with my footage but I would like to add an option to dynamically adjust postSigma with my noise detection and ScriptClip. Is it possible to mod it using ScriptClip only for postFFT? Have tried a while to get it to work but it seems to ignore the FFT3dFilter I use for ScriptClip. Putting the whole TemporalDegrain2 inside of ScriptClip is impossibly slow.


function FD(clip c)
{
# Noise extraction - normalizing the image to even out motion leaving "only" moving noise.

in = c.levels(6*256,1,122*256,0,255*256).tdif.ApplyGradationCurves(lumaPoints="0,128, 40,0, 128,255, 213,0, 255,128")
nc = SI_physicalcores()
ScriptClip(function[in,nc] () {

# Noise detection
nTH = in.YDifferenceToNext()
s = nmod(nTH*0.00009, dec=1)
fft3dfilter(sigma=s, bt=3, ncpu=nc, plane=4)
} )
}
# TemporalDifference - noise enhancing
function tdif(clip C)
{
mt_lutxy(C, C.Trim(1, 0), mt_polish("16*abs(x-y)"), U=-128, V=-128)
return Last
}

function DT_postFFT(clip in, int postFFT, int postPlane, float postSigma, int postDither, int postTR, int postTD, int fftThreads, int postBlkSz, int devId, bool cuda, string dftsfile)
{
LumaNoiseP = (postPlane == 0) || (postPlane == 4)
ChromaNoiseP = (postPlane > 0) ? true : false
dftDither = (postDither < 0) ? postDither*(-1) : 0

out = (postFFT == 0) ? FD( postDither > 0 ? in.ConvertBits(16) : in) : \
(postFFT == 1) ? neo_fft3d ( postDither > 0 ? in.ConvertBits(16) : in, y=LumaNoiseP?3:2, u=ChromaNoiseP?3:2, v=ChromaNoiseP?3:2, sigma=postSigma, bt=postTD, ncpu=fftThreads, bw=postBlkSz, bh=postBlkSz ) : \
(postFFT == 11)? FFT3DFilter( postDither > 0 ? in.ConvertBits(16) : in, plane=postPlane, sigma=postSigma, bt=postTD, ncpu=fftThreads, bw=postBlkSz, bh=postBlkSz ) : \
(postFFT == 2) ? FFT3DGPU( postDither > 0 ? in.ConvertBits(16) : in, plane=postPlane, sigma=postSigma*2/3, bt=postTD, precision=2, mode=1, bw=postBlkSz, bh=postBlkSz ) : \
(postFFT == 3) ? neo_dfttest( postDither > 0 ? in.ConvertBits(16) : in, y=LumaNoiseP?3:2, u=ChromaNoiseP?3:2, v=ChromaNoiseP?3:2, sigma=postSigma*4, tbsize=postTD, dither=dftDither, threads=fftThreads, sbsize=postBlkSz, sosize=postBlkSz*9/12, slocation=dftsfile) : \
(postFFT == 13)? dfttest( postDither > 0 ? in.ConvertBits(16) : in, Y=LumaNoiseP, U=ChromaNoiseP, V=ChromaNoiseP, sigma=postSigma*4, tbsize=postTD, threads=fftThreads, dither=dftDither, sbsize=postBlkSz, sosize=postBlkSz*9/12, sfile=dftsfile ) : \
(postFFT == 4) ? DT_KNLMeansCL( postDither > 0 ? in.ConvertBits(16) : in, a=2, d=postTR, h=postSigma, Luma = LumaNoiseP, Chroma = ChromaNoiseP, device_type="GPU", device_id=devId) : \
(postFFT == 5) ? DT_BM3D( postDither > 0 ? in.ConvertBits(16) : in, radius=postTR, sigma=postSigma, chroma=ChromaNoiseP, CUDA=cuda, device_id=devId ) : \
(postFFT == -1)? HQDn3D( postDither > 0 ? in.ConvertBits(16) : in, 0,0,4,1, u=ChromaNoiseP?3:2, v=ChromaNoiseP?3:2) : NOP()

return out
}


Replaced postFFT=0 just to test. I guess FFT3DFilter needs to work together with the degraining bit for it to work as intended?

EDIT: the above is just the code-snippet of the parts I changed in TemporalDegrain-v2.6.3.avsi

[kedautinh12]

Trying to understand the TemporalDegrain2-script as it works really well with my footage but I would like to add an option to dynamically adjust postSigma with my noise detection and ScriptClip. Is it possible to mod it using ScriptClip only for postFFT? Have tried a while to get it to work but it seems to ignore the FFT3dFilter I use for ScriptClip. Putting the whole TemporalDegrain2 inside of ScriptClip is impossibly slow.


function FD(clip c)
{
# Noise extraction - normalizing the image to even out motion leaving "only" moving noise.

in = c.levels(6*256,1,122*256,0,255*256).tdif.ApplyGradationCurves(lumaPoints="0,128, 40,0, 128,255, 213,0, 255,128")
nc = SI_physicalcores()
ScriptClip(function[in,nc] () {

# Noise detection
nTH = in.YDifferenceToNext()
s = nmod(nTH*0.00009, dec=1)
fft3dfilter(sigma=s, bt=3, ncpu=nc, plane=4)
} )
}
# TemporalDifference - noise enhancing
function tdif(clip C)
{
mt_lutxy(C, C.Trim(1, 0), mt_polish("16*abs(x-y)"), U=-128, V=-128)
return Last
}

function DT_postFFT(clip in, int postFFT, int postPlane, float postSigma, int postDither, int postTR, int postTD, int fftThreads, int postBlkSz, int devId, bool cuda, string dftsfile)
{
LumaNoiseP = (postPlane == 0) || (postPlane == 4)
ChromaNoiseP = (postPlane > 0) ? true : false
dftDither = (postDither < 0) ? postDither*(-1) : 0

out = (postFFT == 0) ? FD( postDither > 0 ? in.ConvertBits(16) : in) : \
(postFFT == 1) ? neo_fft3d ( postDither > 0 ? in.ConvertBits(16) : in, y=LumaNoiseP?3:2, u=ChromaNoiseP?3:2, v=ChromaNoiseP?3:2, sigma=postSigma, bt=postTD, ncpu=fftThreads, bw=postBlkSz, bh=postBlkSz ) : \
(postFFT == 11)? FFT3DFilter( postDither > 0 ? in.ConvertBits(16) : in, plane=postPlane, sigma=postSigma, bt=postTD, ncpu=fftThreads, bw=postBlkSz, bh=postBlkSz ) : \
(postFFT == 2) ? FFT3DGPU( postDither > 0 ? in.ConvertBits(16) : in, plane=postPlane, sigma=postSigma*2/3, bt=postTD, precision=2, mode=1, bw=postBlkSz, bh=postBlkSz ) : \
(postFFT == 3) ? neo_dfttest( postDither > 0 ? in.ConvertBits(16) : in, y=LumaNoiseP?3:2, u=ChromaNoiseP?3:2, v=ChromaNoiseP?3:2, sigma=postSigma*4, tbsize=postTD, dither=dftDither, threads=fftThreads, sbsize=postBlkSz, sosize=postBlkSz*9/12, slocation=dftsfile) : \
(postFFT == 13)? dfttest( postDither > 0 ? in.ConvertBits(16) : in, Y=LumaNoiseP, U=ChromaNoiseP, V=ChromaNoiseP, sigma=postSigma*4, tbsize=postTD, threads=fftThreads, dither=dftDither, sbsize=postBlkSz, sosize=postBlkSz*9/12, sfile=dftsfile ) : \
(postFFT == 4) ? DT_KNLMeansCL( postDither > 0 ? in.ConvertBits(16) : in, a=2, d=postTR, h=postSigma, Luma = LumaNoiseP, Chroma = ChromaNoiseP, device_type="GPU", device_id=devId) : \
(postFFT == 5) ? DT_BM3D( postDither > 0 ? in.ConvertBits(16) : in, radius=postTR, sigma=postSigma, chroma=ChromaNoiseP, CUDA=cuda, device_id=devId ) : \
(postFFT == -1)? HQDn3D( postDither > 0 ? in.ConvertBits(16) : in, 0,0,4,1, u=ChromaNoiseP?3:2, v=ChromaNoiseP?3:2) : NOP()

return out
}


Replaced postFFT=0 just to test. I guess FFT3DFilter needs to work together with the degraining bit for it to work as intended?

I remember you run very slow with neo-fft3t. Try limitFFT=11, TemporalDegrain2 will use fft3d filter

[anton_foy]

I remember you run very slow with neo-fft3t. Try limitFFT=11, TemporalDegrain2 will use fft3d filter

Thanks, now I have upgraded my computer a bit and neo-fft works fine.
Although I talking about modding the TemporalDegrain-script to make neo/fft3dfilter work in scriptclip in the way I suggested above.

EDIT: Now I think I found out a bit more about what is doing what. As I understand it there are two instances where FFT3D is used.
First as a kind of prefilter(?) in DGlimit and second instance as postFFT. Will try to experiment with DGlimit-FFT3D + ScriptClip.

[simple_simon]

What would be the best settings in TemporalDegrainV2 to best replicate the FastDegrain.avsi from the original TemporalDegrain package but utilizing the added QTGMC analysis benefits?

[ErazorTT]

I at least have no idea. I never tried to replicate any other plugin. Just read the step-by-step readme at the top of the TD2.avsi script and it will guide you through the setup of TD2 for the clip at hand.

[some dude]

I'm running into a weird issue, I don't think I'm missing any of the dependent plugins.

Avisynth open failure:
unexpected character "["
(TemporalDegrain-v2.6.2.avsi, line 478, column 41)


The line it appears to be referring to is

output = cd ? output.BM3D_CUDA(sigma=[s,cs,cs], radius=r, chroma=chr, fast=true, extractor_exp=6, device_id=devId)

I'm not sure why it can't read the "[" character.

[StainlessS]

I'm not sure why it can't read the "[" character.
You running latest avs+ ?

(Looks like some kind of Array stuff)

EDIT:
output = cd ? output.BM3D_CUDA(sigma=[s,cs,cs], radius=r, chroma=chr, fast=true, extractor_exp=6, device_id=devId)
Does that require the Cuda version AVS+ ???

[Reel.Deel]

Does that require the Cuda version AVS+ ???

No it does not require the CUDA version. The only filters known that require AviSynth+ built with the CUDA option are Nekopanda's CUDA filters (https://github.com/pinterf/AviSynthCUDAFilters#readme). But there is no current compile of those filters that work with the latest AVS+: https://github.com/AviSynth/AviSynthPlus/issues/296

[subterrestrial]

I came across this topic when I was searching for reference to help me mod a denoising script using Nekopanda's CUDA functions as I really like the efficiency of these cuda filters. TemporalDegrain2 seems to be a nice start point since it is partly based on QTGMC degrain algorithm of which the cuda version realization already exists.

It might be off this topic but I want to share some information about compiling the printerf version AviSynthCUDAFilters because I read the reply referred that there was problems in compling these filters with AVS+3.7.2.
When I compiled printerf's AviSynthCUDAFilters with AVS+3.7.0 by CUDA11 compiler and run the program using a pascal architecture card(GTX10xx series, just like the one which printerf got when he moded the soure file), it worked very well. But when I changed the card to a turing architecture card(GTX16xx and RTX20xx) and comiled the file again with AVS+3.7.2, the filter failed to work. It seemed the graphic gard memory and cpu memory failed to synchronise. The same problem was also reported in a Japanese forum where there is special column discussing Avisynth topics(https://toro.2ch.sc/test/read.cgi/avi/1653113801/l50).

Anyway, I finally figured out a way to make it work: using CUDA 8 compiler to compile printerf's AviSynthCUDAFilters, in this way I could make the program run on a turing architecture card but I can't guarantee it can run ampere architecture card(RTX30xx) because I don't have a card for testing. However, it seems that the program may run on ampere architecture cards sinse Nekopanda's programs was compiled by CUDA8 compiler and the programs were reported to work on those cards(https://mevius.5ch.net/test/read.cgi/avi/1666875696/).

Sorry but there are more off topic things I want to add. Actually the source code that Nekopanda compiled his last version cuda filters which is in his repository of Amtsukaze project was not updated to his repository of AviSynthCUDAFilters project. The date in which the program file was comiled was about half year later than the date of the final change in his AviSynthCUDAFilters project. Another decisive evidence is that a funtion in printerf's AviSynthCUDAFilters is lacking a parameter which resulted in KFMDeint.avsi in Amtsukaze failing directly applied in(bool "is120" in function KFMDeint). Additionally, although I know it's not a sufficient evidence, I compiled Nekopanda version using the not updated code by CUDA 8 compiler and compare the efficiency with Nekopanda's compiled files running same program but just replacing the dll file in the Amtsukaze folder, then I founed mine was not efficient as Nekopanda's . Since Nekopanda's AvsCUDA.dll and KFM.dll was both comiled half year later than the last updated code, I'm pretty sure there are code changes in the soure file. After all, in my guess Nekopanda's main and final purpose was not to create these filters, which were just tools he created to build his final program Amtsukaze of which I just find out the maintainance has been taken over by rigaya(https://github.com/rigaya/Amatsukaze) though he/she didn't touch the AviSynthCUDAFilters codes.

[kedautinh12]

I'm running into a weird issue, I don't think I'm missing any of the dependent plugins.

Avisynth open failure:
unexpected character "["
(TemporalDegrain-v2.6.2.avsi, line 478, column 41)


The line it appears to be referring to is

output = cd ? output.BM3D_CUDA(sigma=[s,cs,cs], radius=r, chroma=chr, fast=true, extractor_exp=6, device_id=devId)

I'm not sure why it can't read the "[" character.

You need use latest avs+ ver
https://gitlab.com/uvz/AviSynthPlus-Builds

You need use update TemporalDegrain2 to latest ver (check first post)

You don't need Cuda if you use this script:
TemporalDegrain2 (postFFT=5, cuda=false)

[Arx1meD]

I like everything in Temporaldegrainv2 and the quality of the cleaning of the noise is brilliant! But the speed of work is slow, and on my old computer it works very slowly. I decided to change the script so that it works faster and cleaned well from noise.
This is my lightweight version - Temporaldegrain2_fast.
# Temporal Degrain 2 fast
#
# Based on TemporalDegrainV2
# https://forum.doom9.org/showthread.php?t=175798
#
# Needed plugins:
# neo_FFT3D https://github.com/HomeOfAviSynthPlusEvolution/neo_FFT3D
# MaskTools2 https://github.com/pinterf/masktools
# MVTools2 https://github.com/pinterf/mvtools or https://github.com/DTL2020/mvtools
# RgTools https://github.com/pinterf/RgTools
# vsDeGrainMedian https://github.com/Asd-g/AviSynth-vsDeGrainMedian
#
# Usage Default:
# TemporalDegrain2_fast(Strength=3, Y=3, U=3, V=3, RadT=1, BlkSz=16, Sharp=0.4, PostDeHalo=false, PostMix=0)
#
# Post in Doom9's forum: https://forum.doom9.org/showthread.php?p=1982594#post1982594


function TemporalDegrain2_fast (clip input, int "Strength", int "Y", int "U", int "V", int "RadT", int "BlkSz", int "Olap", \
float "Sharp", bool "PostDeHalo", float "PostMix")
{
Str = Default(Strength, 3) # Noise/grain suppression strength.
# Strength for depth noise (< 2), low (3 ... 5), medium (6 ... 9), high (10 ... 14), veryhigh (> 15)
Y = Default(Y, 3) # Luma plane to process. Value: 2 - copy from input, 3 - process
U = Default(U, Y) # Chroma plane to process. Value: 2 - copy from input, 3 - process
V = Default(V, U) # Chroma plane to process. Value: 2 - copy from input, 3 - process
RadT = Default(RadT, 1) # Temporal Radius of frame analysis. Value 1 or 2
BlkSz = Default(BlkSz, 16) # Block size for motion analysis. Bigger BlkSz quicker. Recommended values: 8, 16, 32
OLap = Default(OLap, BlkSz/2) # The value of overlapping blocks on each other
Sharp = Default(Sharp, 0.4) # Sharpening strength. Range: 0 ... 1
DeHalo = Default(PostDeHalo, false) # Remove halo after sharpening. Value: true or false
PostMix = Default(PostMix, 0) # How much noise/grain will be returned. Range: 0 ... 1

func_name = "TemporalDegrain2_fast: "
Assert(Y == 2 || Y == 3, func_name+"Luma Y plane must be 2 or 3")
Assert(U == 2 || U == 3, func_name+"Chroma U plane must be 2 or 3")
Assert(V == 2 || V == 3, func_name+"Chroma V plane must be 2 or 3")
Assert(Y == 3 || U == 3 || V == 3, func_name+"One of the planes Y, U, V must be 3")
Assert(RadT == 1 || RadT == 2, func_name+"Temporal Radius of frame analysis must be 1 or 2")
Assert(Sharp >= 0 && Sharp <= 1, func_name+"Sharpening strength must be between 0 and 1.0")
Assert(PostMix >= 0 && PostMix <= 1, func_name+"The noise return value must be between 0 and 1.0")

dPlane = Y==3 && (U==3 || V==3) ? 4
\ : Y==3 && U==2 && V==2 ? 0
\ : Y==2 && U==3 && V==2 ? 1
\ : Y==2 && U==2 && V==3 ? 2
\ : Y==2 && U==3 && V==3 ? 3 : 4
pad = Max(Blksz, 8)
pel = 1
chr = U==3 || V==3 ? true : false

# denoising 1st way
dgLimit = input.neo_fft3d(sigma=Str, sigma2=Floor(Str*0.625), sigma3=Floor(Str*0.375), sigma4=Floor(Str*0.250), \
bt=RadT==1?3:5, Y=Y, U=U, V=V, bw=BlkSz*2, bh=BlkSz*2, ow=OLap, oh=OLap) #, ncpu=4, mt=true)
dgSpatD = mt_makediff(input, dgLimit, Y=Y, U=U, V=V)

# denoising 2nd way
dgNR1 = dgLimit.vsDeGrainMedian(modeY=0, limitY=Str, limitU=U==3?Str+2:0, limitV=V==3?Str+2:0)
dgNR1D = mt_makediff(input, dgNR1, Y=Y, U=U, V=V)

# combine 1st and 2nd ways
dgDD = mt_lutxy(dgSpatD, dgNR1D, "x range_half - abs y range_half - abs < x y ?", Y=Y, U=U, V=V, use_expr=2)
dgNR1x = mt_makediff(input, dgDD, Y=Y, U=U, V=V)

# sharpen the edges only
dgNR1x = Sharp > 0 ? mt_merge(dgNR1x, \
dgNR1x.RemoveGrain(17).Sharpen(Sharp), \
dgNR1x.RemoveGrain(12).mt_edge("prewitt", Y=3, U=2, V=2).mt_inpand(chroma="-128").Blur(1.58), \
Y=3, U=2, V=2)
\ : dgNR1x

# denoising 3rd way
sup = dgNR1x.Blur(1.58).Blur(1.58).MSuper(hpad=pad, vpad=pad, pel=pel, chroma=chr)
MultiVec = MAnalyse(sup, multi=true, delta=RadT, blksize=BlkSz, overlap=OLap, search=5, dct=7, chroma=chr, truemotion=false, global=true)
dgNR1xS = MSuper(dgNR1x, hpad=pad, vpad=pad, pel=pel, levels=1, chroma=chr)
dgNR2 = MDegrainN(dgNR1x, dgNR1xS, MultiVec, RadT, plane=dPlane)

# combine 1st, 2nd and 3rd ways
dgDD2 = mt_lutxy(dgNR1x, dgNR2, "x range_half - abs y range_half - abs < x y ?", Y=Y, U=U, V=V, use_expr=2)

# post denoising
# dgNR3 = dgDD2.RemoveGrain(17)
# dgDD2 = mt_lutxy(dgNR3, dgDD2, "x range_half - abs y range_half - abs < x y ?", Y=Y, U=U, V=V, use_expr=2)

# sharpening
allD = Sharp > 0 ? mt_makediff(input.Sharpen(1), dgDD2.Blur(1.58).Blur(1.58)) : NOP()
ssD = Sharp > 0 ? mt_makediff(dgDD2, dgDD2.RemoveGrain(20)) : NOP()
ssDD = Sharp > 0 ? mt_lutxy(ssD.Repair(allD, 12), ssD, "x range_half - abs y range_half - abs < x y ?", Y=Y, U=U, V=V, use_expr=2) : NOP()
out = Sharp > 0 ? mt_lutxy(dgDD2, ssDD, "x range_half y - "+String(Sharp)+" * -", Y=3, U=2, V=2, use_expr=2) : dgDD2

# dehaloing
m0 = Sharp > 0 && DeHalo ? dgNR1x.mt_edge("prewitt", Y=3, U=2, V=2).mt_inpand(chroma="-128") : NOP()
m1 = Sharp > 0 && DeHalo ? mt_lutxy(out, m0, "y range_half > x y ?", Y=3, chroma="-128", use_expr=2).mt_binarize(threshold=128).Blur(0.5) : NOP()
out = Sharp > 0 && DeHalo ? mt_merge(out, dgNR1x.Blur(0.1), m1, Y=3, U=2, V=2) : out

PostMix > 0 ? mt_lutxy(out, input, "x x y - "+String(PostMix)+" * -", Y=Y, U=U, V=V, use_expr=2) : out
}

[kedautinh12]

Can you share your slow ver??

[Arx1meD]

Can you share your slow ver??
This is the script from the first post of this thread.

[anton_foy]

I like everything in Temporaldegrainv2 and the quality of the cleaning of the noise is brilliant! But the speed of work is slow, and on my old computer it works very slowly. I decided to change the script so that it works faster and cleaned well from noise.
This is my lightweight version - Temporaldegrain2_fast.


@Arx1meD Actually it looks great! Faster and degrains smoothly while keeping a good amount of detail.

I will try to add mocomped temporalsoften instead of mdegrain just to see if it eats a bit more noise.

[avinewbie]

@Arx1meD
Thank you.I tried it and its amazingly fast and easy to tune even on my old PC.

[rgr]

Why am I getting this error?

Both clips should have the same colorspace!
(C:/Program Files (x86)lAviSynth+/plugins64+/TemporalDegrain-v2.6.4.avsi, line 441)
(C:/Program Files (x86)lAviSynth+/plugins64+/TemporalDegrain-v2.6.4.avsi, line 395)

Source: MPEG2, 720x576, YUV420

Full script:
video_org=FFmpegSource2("../00000.m2ts", atrack=-1)
crop_left=12 # | rimozione esatta delle bande nere sinistra, sopra, destra e del disturbo sotto
crop_top=2 # | 720-(12+16)x576-(2+14)=692x560
crop_right=16
crop_bottom=14
video_org_crop=video_org.crop(crop_left,crop_top,-crop_right,-crop_bottom)

video_org_crop_adj=video_org_crop.ColorYUV(off_u=+12, off_v=-6)

### de-interlacing
deinterlaced=video_org_crop_adj.AssumeTFF().QTGMC(preset="slow", matchpreset="slow", matchpreset2="slow", sourcematch=3, tr1=2, tr2=1, NoiseTR=2, sharpness=0.1)

### convert to YV16
deinterlaced_yv16=deinterlaced.convertToYV16()

### denoising
denoised_yv16=deinterlaced_yv16.TemporalDegrain2(degrainTR=3)

### convert to YUY2
denoised=denoised_yv16.convertToYUY2()

### convert to YV12
denoised_yv12=denoised.convertToYV12()

### sharpening
sharpened_yv12=denoised_yv12.LSFmod(defaults="slow")

### convert to YUY2 with chroma from YUY2 color space
sharpened=sharpened_yv12.convertToYUY2().MergeChroma(denoised)

### add borders
video_restored=sharpened.addborders((crop_left+crop_right)/2,(crop_top+crop_bottom)/2,(crop_left+crop_right)/2,(crop_top+crop_bottom)/2)

return(video_restored)

[rgr]

Feb 11, 2023: v2.6.4
- always undot before postFFT stage, increasing FFT efficiency by quite a bit when degrain was disabled
- mention suggested settings inside the script file

In the new version I get this error:

Both clips should have the same colorspace!
(C:/Program Files (x86)lAviSynth+/plugins64+/TemporalDegrain-v2.6.4.avsi, line 441)
(C:/Program Files (x86)lAviSynth+/plugins64+/TemporalDegrain-v2.6.4.avsi, line 395)

Rolling back to 2.6.3 solves the problem.

[ErazorTT]

Yes, I just updated the file. Should be fixed now.

[ErazorTT]

I found that there is a wierd inconsistent chroma shift for 420 sources. It can be upto half a pixel. Which means that when resized onto the luma, it will be twice of that.
From my investigation I found that it comes from mvtools MDegrain. I reported it here (https://github.com/pinterf/mvtools/issues/59), you can take a look of the magnitue of the deviation there.

I thus decided to go back to a single degrain step for the chroma. I think this is the best compromise in total.
This halfs the shift introduced by mvtools, which I think is good enough. And it gives quite some speed increase, at the expense of a slightly less clean chroma.
For the paranoid among us, a complete the circumvention of the chroma shift bug can be enabled by the flag "degrainAvoidChromaShift", but that is relatively expense at 10% performance cost.

Also, if it is really necessary to clean the chroma more, which should be rather rarely, both degrains steps can be enabled for the chroma by the flag "degrainChromaTwoStep". This will however also enable the relatively expensive circumvention of the bug.

[karthauzi]

thanks for v2.6.6! Can it ported in G41fun.py Vapoursynth? Its actually v2.6.3

I have abolutely no Idea how to do this, even with googling, maybe i only need to adjust some lines? they are very different AVS and VS codelines.

Can you have a look into my G41Fun.rar to show us how to adjust it, so i can use v2.6.6?

Im using Staxrip and i already just Copy & Pasted the entire TemporalDegrain2 code from another G41fun.py into this one and replaced it from an old v2.4.3?. Improvising :D


https://drive.google.com/file/d/1uPauV40jfUKT8Xsq4bjkCJcUuBWpw3Jr/view?usp=sharing


Greetings

[Mounir]

I'm Trying the filter for the first time, i get an error (for a change) (tried v2.6.2 and v2.6.3 aswell)

avisource
convertoyv12()
TemporalDegrain2("CUDA"=false)

script error expected a , or )

[poisondeathray]

I'm Trying the filter for the first time, i get an error (for a change) (tried v2.6.2 and v2.6.3 aswell)


avisource
convertoyv12()
TemporalDegrain2("CUDA"=false)


script error expected a , or )


CUDA=false , no ""


TemporalDegrain2(CUDA=false)

[kedautinh12]

I'm Trying the filter for the first time, i get an error (for a change) (tried v2.6.2 and v2.6.3 aswell)



script error expected a , or )

Cuda parameter only use with postFFT=5. You can use without postFFT=5 but that parameter no meaning when don't set postFFT=5

[Drommer]

Hi. Is there any solution to the problem of color loss and artifacts when switching scenes? I saw in the manual about DCT, but it doesn't help and sometimes makes it worse.
I really like this filter. I have already found the optimal settings and transcode a few videos. Very reluctant to try anything else.

[kedautinh12]

Hi. Is there any solution to the problem of color loss and artifacts when switching scenes? I saw it in the manual about DCT, but it doesn't help and sometimes makes it worse.
I really like this filter. I have already found the optimal settings and transcribed a few videos. Very reluctant to try anything else.

I think it's related to banding colors after denoising, I think you can try parameter postFFT=3 or 4 or 5 to avoid banding. If banding continues after use 3, 4, and 5, you can try debanding with neo_f3kdb or gradfun3plus with 16bit

Example:

* Denoiser scripts
ConvertBits(16)
GradFun3plus(thr=0.25, radius=10, mask=2, smode=0,UV=1)

[Drommer]

I think it's related to banding colors after denoising
No, it's not about banding. This problem was discussed two pages ago. The last frame of the previous scene and the first frame of the next scene have distorted colors and spots. In this case (screenshots below) both processed frames go to cold tones, the second frame also has a small pink spot right of the door that gets bigger as the grainLevel increases.

https://imgsli.com/MjA5MTQx
https://imgsli.com/MjA5MTQy

P.S. My line: grainLevel=0, meBlksz=4, postFFT=4. I have also tried postFFT=0 and other options, but it has no effect.

[Drommer]

Just in case, I checked the script version - everything is fine, 2.6.6. I also update all other components the script might depend on.

I went back to the discussion on the previous pages and noticed a post where the problem was solved by changing the values of ppSCD1 and thSCD2. This works, but I had to reduce the values to ppSCD1=2 and thSCD2=80. I think such an extremely low value would lead to false positives within the same scene. Am I the first to experience this problem after the fixes in version 2.3.3?

UPD 27/09. I did some more tests. I tried using the SceneCutSelectClip (https://forum.doom9.org/showthread.php?p=1990796#post1990796) function, which (as I understand it) uses the same mechanism of searching and comparing frames. With default settings (thSCD1=400, thSCD2=130) scene change detection works correctly.

[Drommer]

I found a bug when using postFFT=4 (KNLMeansCL). The devId variable is ignored because it is not specified in the function call. It is necessary to fix line 513 as follows:
output = KNLMeansCL(temp, a=a, d=d, h=strength, device_id=device_id, channels=channels)

[ErazorTT]

So this is mainly visible on skin colors, right? This is at least what I get from your screenshots. I will try to find examples myself.

Concerning the SCD values. By driving them down you basically disabled the scene change detection for MVTools. This also suggests that it is an issue related to MDegrain. If thats the case, I fear there is not much that can be done, apart from informing the creators of MVTools.

Oh, and I pushed a new version which fixes the forwarding of the device_id for KNLMeans.

[rgr]

Are there any plans to fix issues like the one at the top of this screenshot?

https://i.imgur.com/CqqyqYu.png

[takla]

Are there any plans to fix issues like the one at the top of this screenshot?

https://i.imgur.com/CqqyqYu.png

Uhm, you want to crop black bars before denoising...

[poisondeathray]

That probably has more to do with QTGMC. Use border=true

[ErazorTT]

Are there any plans to fix issues like the one at the top of this screenshot?

Well, I‘ve never seen this before, and I myself am using this plugin on an almost daily basis. So, no until now it was not planned to fix this, since I was not aware of this issue.
Might that be the cause:
That probably has more to do with QTGMC. Use border=true

And if not, what kind of source is it? Is it interlaced and what other plugins are you using?

[rgr]

Uhm, you want to crop black bars before denoising...

Sometimes this is impossible (e.g. image with borders)

That probably has more to do with QTGMC. Use border=true

QTGMC is resistant to this (the problem appeared after adding TD2). I think I even saw a workaround for this in the QTGMC code, but I'm not sure.

Well, I‘ve never seen this before, and I myself am using this plugin on an almost daily basis. So, no until now it was not planned to fix this, since I was not aware of this issue.
Might that be the cause: (QTGMC)

And if not, what kind of source is it? Is it interlaced and what other plugins are you using?

Source: progressive(*), after QTGMC (InputType=1)

[Boulder]

Source: interlaced, after QTGMC (InputType=1)

InputType=x expects progressive input, it is not for deinterlacing.

[rgr]

InputType=x expects progressive input, it is not for deinterlacing.

Sorry, progressive input -- my mistake. Corrected.

[Kurosu]

There are cases where I cascaded this filter, or use 10 bits to reduce a palettization-like effect in bright/dark parts.
I'm wondering if it would be possible to
1) Obtain (MSuper/MAnalyse?) the motion field on the 8bits sequence, but only apply the 10bits just before the temporally-compensated denoising itself (MDegrainN?)
2) Reuse any info (vmulti?) when cascading in some scenarios

[DTL]

1. Yes
2. Yes. But when processing denoised data with MAnalyse you will got somehow different MVs. So reused MVs from first MAnalyse may or may not be better (even in different areas of frame).

[Kurosu]

For 1., I tend to use "barebone" (just changing grainlevel<=2, degrainTR<=2, meSubpel) settings without too much pre or postprocessing. I imagine a global solution would be cumbersome. But for my limited use case, do you think changing bitdepth just before MSuper and/or MDegrainN would be useful.

For 2., yes, I can imagine ME on a denoised clip will not yield the same result. It would make only somewhat more sense if there were more than 2 temporaldegrain2 chained, so a very very limited use case.

[tormento]

I really can't sort out how to use grainLevelSetup.

Tried to search in AVSI and here but no useful informations found.

Any help is welcome.

[tormento]

TemporalDegrain2(degrainTR=1,grainLevel=1,degrainChromaTwoStep=false,meAlg=5,limitFFT=2,postFFT=4,postSigma=1.0)

works ok but

TemporalDegrain2(degrainTR=1,grainLevel=1,degrainChromaTwoStep=false,meAlg=5,limitFFT=2,postFFT=4,postSigma=0)

gives me error

KNLMeansCL: 'h' must be greater than 0!
(D:/Programmi/Media/AviSynth+/plugins64/TemporalDegrain-2.6.7~ErazorTT.avsi, line 519)
(D:/Programmi/Media/AviSynth+/plugins64/TemporalDegrain-2.6.7~ErazorTT.avsi, line 456)
(D:/Programmi/Media/AviSynth+/plugins64/TemporalDegrain-2.6.7~ErazorTT.avsi, line 424)

Why?

[kedautinh12]

TemporalDegrain2(degrainTR=1,grainLevel=1,degrainChromaTwoStep=false,meAlg=5,limitFFT=2,postFFT=4,postSigma=1.0)

works ok but

TemporalDegrain2(degrainTR=1,grainLevel=1,degrainChromaTwoStep=false,meAlg=5,limitFFT=2,postFFT=4,postSigma=0)

gives me error

KNLMeansCL: 'h' must be greater than 0!
(D:/Programmi/Media/AviSynth+/plugins64/TemporalDegrain-2.6.7~ErazorTT.avsi, line 519)
(D:/Programmi/Media/AviSynth+/plugins64/TemporalDegrain-2.6.7~ErazorTT.avsi, line 456)
(D:/Programmi/Media/AviSynth+/plugins64/TemporalDegrain-2.6.7~ErazorTT.avsi, line 424)

Why?

Lol, just look that script you will know why the postSigma must greater than 0
(postFFT == 4) ? DT_KNLMeansCL( postDither > 0 ? in.ConvertBits(16) : in, a=2, d=postTR, h=postSigma, Luma = LumaP, Chroma = ChromaP, device_type="GPU", device_id=devId) : \

float h = 1.2
Controls the strength of the filtering. Larger values will remove more noise.

[Peter Sagan]

I found a version of this script bundled somewhere and it contained one additional line inside function DT_postFFT:

postTD = (postFFT == 11 || postFFT == 1) ? postTR : (postFFT == 2 && postTR > 4) ? 4 : (postFFT == 2) ? postTR : postTR * 2 + 1


Anyone know why that might be? The rest of the script is exactly identical to the version 2.6.7 posted here.

[tormento]

Lol, just look that script you will know why the postSigma must greater than 0
Look at the wiki (http://avisynth.nl/index.php/TemporalDegrain2).

It tells that postSigma can be between 0 and 4 and it doesn't tell that it has to be strictly bigger than 0.

Either is wrong the script or the wiki page.

[isidroco]

Hi, I have 4c/8threads cpu and can't get temporaldegrain2 use more than 13% of the cpu. Using AviSynth+ v3.7.3 and also added to the script with no perceivable difference:
SetFilterMTMode( "DEFAULT_MT_MODE", MT_MULTI_INSTANCE )
prefetch(4)

Edit, managed to get 18% with:
TemporalDegrain2( degrainTR=2, grainLevel=2, postFFT=3, postSigma=1.0, fftThreads=4)
prefetch( 2)


Is there any other setting to improve CPU usage and speed up process?

[kedautinh12]

Look at the wiki (http://avisynth.nl/index.php/TemporalDegrain2).

It tells that postSigma can be between 0 and 4 and it doesn't tell that it has to be strictly bigger than 0.

Either is wrong the script or the wiki page.

Between 0 and 4 with other plugins but KnlmeansCL, did you know "float" mean?

[hello_hello]

I was doing my usual TemporalDegrain2 vs QTGMC comparison before encoding a video today (as depending on the type of noise one of them usually works better than the other), and I found TemporalDegrain2 was doing something odd to a particular frame at the end of a scene. Anyone know why? Enabling post processing seems to help a lot, but it also slows encoding down a fair bit. I guess I'm just hoping to understand what it is about this one frame. The script I used for the screenshots below only contained either TemporalDegrain2 or QTGMC.

Source
https://i.ibb.co/8DMHVhBg/Original.png

TemporalDeGrain2(degrainTR=1, grainLevel=2)
https://i.ibb.co/cKHbS1cQ/Temporal-De-Grain2.png

TemporalDeGrain2(degrainTR=1, grainLevel=1, postFFT=3, postSigma=1, postDither=1)
https://i.ibb.co/Zp1yJL3b/Temporal-De-Grain3.png

QTGMCp(InputType=1, EzDenoise=2.0, Preset="very slow", gpuid=-1) - Dogway's version
https://i.ibb.co/tTgDhDck/QTGMC.png

It's frame #81 in this sample (5.7 MiB).
Test Sample.mkv (https://files.videohelp.com/u/210984/Test%20Sample.mkv)

[rgr]

I don't think you'll get an answer. Probably a random combination of factors that led to this. I, on the other hand, observed something like this at the beginning of the scenes (first frame or frames). Only the author could analyze it, I guess.

[rgr]

The original file, after dfttest and after TD2 (degrainTR=3, grainLevel=1).
Hair doesn't look the best after this filter. Even changing it to grainLevel=0 doesn't help much. On the plus side -- it sharpens nicely.

https://imgsli.com/Mzk5MDA0/1/2

[Kurosu]

I was doing my usual TemporalDegrain2 vs QTGMC comparison before encoding a video today (as depending on the type of noise one of them usually works better than the other), and I found TemporalDegrain2 was doing something odd to a particular frame at the end of a scene. Anyone know why?

[...]

It's frame #81 in this sample (5.7 MiB).
Test Sample.mkv (https://files.videohelp.com/u/210984/Test%20Sample.mkv)


What you are seeing is unfortunately something hard to set automatically. When there is a scene change, TDv2 may still try to use frames from the other side of the scene change. Your frame 81 is just before one, and I suspect if you look at your processed frame 82, it'll also have similar artifacts.

The internal MCompensate (including MDegrain which calls it) calls rely on thSCD2 primarily (and thSCD1, which TDv2 multiplies by 64 before passing to MCompensate and friends) in relation to scene change detection. Go look at MVTools documentation to understand these and maybe try to tweak it. Try maybe thSCD2=100 (40% of blocks) or 77 (30%), but it will depend on your noise level.

[Selur]

There has been a port of TemporalDegrain2 for a while now https://github.com/Selur/VapoursynthScriptsInHybrid/blob/master/degrain.py#L407 maybe better build on that, add BM3D as optionel postFFT and add the chroma shift idea (which I like)

[sdml]

Tinkering with it a little I kinda wonder - Is all kind "degrain" kinda equal to just MV's Degrain()?

[Selur]

All temporal/motion based degrain script variants like:

TemporalDegrain
TemporalDegrain2
MCDegrainSharp
MDegrain
SMDegrain

use the same general base idea. :)
Estimate motion between frames => compensate for that motion => perform temporal averaging only on corresponding objects rather than fixed pixel positions.