mClean spatio/temporal denoiser v3.2 (01 March 2018)

[MysteryX]

Use IsYUV420(), IsYUV422() and ISYUV444()

[raffriff42]

Originally Posted by burfadel

Updated the first post with version 1.6.

If you extract the luminance channel such it is just the Y channel, obviously it is a different format to the YUV clip such as output from the chroma filtering. You first have to convert back to the same format before combining. This is fine, however when you are in more than 8 bits, the commands such as isYV12() etc do not work since it is expecting a YUV420Y8 clip for it to be true. Since it is a YUV420P10 clip (for example) the command isYV12() seems to give back false. If you run convertToYV12(), it keeps the higher bitdepth of 10 etc, so isYV12() still doesn't work. This, and possibly other little issues, are problematic when you want to have the output clip the same format as the input clip and it isn't 8-bit etc. This is why I put back the 'do not process' flags to the luma commands, it was either that or dropping support for YV16 and YV24, which obviously isn't desirable.

It works fine as is because the bit depths can be matched easily and the pixel type hasn't changed. I could do a convertbits() just so isYV12() etc works, but then it's an extra unnecessary bit of processing that will probably affect speed more than what was gained by converting it to Y8 and going back to the desired pixel type.

Don't use IsYV12, use Is420 -- works at any bit depth.
Don't use ConvertToYV12, use ConvertToYUV420.
To combine the planes again, use CombinePlanes(Y-clip, U-clip, V-clip, "YUV") (for one example)

[MysteryX]

This issue has several issues. On 1080p content, it throws a validation error on enh. Then it crashes on gBlur value being out of range. And then, output doesn't have the right dimensions!

I used Spline36Resize(Width/2, Height/2) to test and work around the bug, so I'm testing on 960x540

Performance-wise -- Prefetch(8)

v1.3c

FPS (min | max | average):      0.239 | 9584 | 14.75
Memory usage (phys | virt):     582 | 695 MiB
Thread count:                   36
CPU usage (average):            55%

v1.6

FPS (min | max | average):      0.915 | 15800 | 13.10
Memory usage (phys | virt):     1031 | 1162 MiB
Thread count:                   38
CPU usage (average):            61%

It felt a lot slower, but it mostly just takes longer to initialize but then performance isn't far off v1.3c. However... memory usage is twice higher!!! And that's at HALF the resolution. In a x86 processing chain, this leaves me no room for much other processing.

As for versioning, it's bad practice to use major/minor version numbers for development versions. Agree, Microsoft did it with Windows Millenium and Vista, but it's bad practice. You'd get to v1.35 before having a script ready for production. Generally, most people use version numbers below 1 for alpha/beta/dev versions, and for FrameRateConverter, I just put the date instead of a version number until it was finalized.

Semantic Versioning Guidelines

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.


How should I deal with revisions in the 0.y.z initial development phase?

The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.

Also keeping a development history is good practice.

So far v1.3c is what works best. I can't easily test this version side-by-side because frame dimensions don't match.


Btw could you explain this line?

noise =  mt_binarize (clense(mt_makediff(mt_binarize(noised), mt_edge(sharpen(clean, 0.82), "prewitt")), grey=true))

I see you're using this to exclude blacks from renoise, but I don't think that's a good way to do it. Have you tried applying a gamma curve to the noise you want to insert back using mt_lut?
motion_mask = mmask(noised, fvec3, kind=1, ml=120).mt_binarize(32, u=1, v=1)

[burfadel]

A big difference between 1.3C and higher is changing from MDegrain2 to MDegrain4, which gives better output. Working in Y plane only should reduce this memory usage, I should also be able to recover some speed etc in places. The motionmask has a mt_binarize to create a hard mask, the soft mask is simply too weak for it. As for the dimensions, it's the padding and cropping afterwards, I guess that's why pointresize and not crop is used at the end in the padding script. Pointresize is used so you can add non-mod based padding, addborders requires mod based depending on the pixel type.

As for the renoise, not sure how to apply mt_lut to it such that it is only applied on non-dark areas. I'll give it another try.

[DarkNite]

Cranked up a test run of mClean 1.6 last night, and have been faced with two errors. First error was upon initial loading of the script: Enh reported only accepting ranges of 0-54 when using mClean(), so I defined enh as 15, and was off to the races. Come back this morning to a job that is 5 frames from completion, and an Out of memory (Unable to allocate 2992224 bytes) error from Virtualdub FilterMod. Both are firsts for me, at least as far as mClean is concerned.

[burfadel]

That out of memory issue is weird, a tad shy of 3 MB. Maybe I'm triggering a small memory leak somewhere since once the memory is initially allocated it shouldn't increase with time. I have to admit 1.6 does have bugs, but when it works it's good... makes testing interesting! Later today my time I'll post 1.6b with the necessary fixes. I have two different 'concepts' that may help further with speed without quality loss, unfortunately if they work it will make the code look a bit dodgy with people scratching their heads as to why i did it in such a way. The goal of course is efficacy of the concept, not how it looks in script!

[MysteryX]

Originally Posted by burfadel

As for the renoise, not sure how to apply mt_lut to it such that it is only applied on non-dark areas. I'll give it another try.

First of all, what is causing the extra artifacts in dark scenes? Is it a "bug" with MDegrain that causes that?

Generally, when there are issues only on dark (or bright) scenes, it's an indication that it's an issue with the gamma curve, where if you apply a value linearly, it will have a large impact on dark/bright scenes and low impact on middle values. This might be the case here.

Just try applying a 2.2 gamma curve on the noise and see what it does. Syntax is mt_lut("x 2.2 ^")

[burfadel]

Updated first post to version 1.7

Changes:

• fixed errors introduced with 1.6
• changed analysis, should be faster without motion quality loss; in testing it was either the same or fractionally better depending on the motion
• luma now processed as a single plane (Y12 default)
• changed application of renoise, application processes only above luma value 20, application scaled from 0 at value 20 to 100 at values 40 and above

It wasn't a linear light issue. If applied the given linear light formula it basically looks like it boosts gamma by 2.2?

Let me know how the new analysis works. Should be faster with same or better perceived quality.

[MysteryX]

Doing some tests. First thing I'm noticing is that it's applying a strong sharpening to scenes without noise, which is a no-no (unless I really want to run a sharpener which I don't). It uses enh=35 for 1080p. Just lowering it a bit works. 25 is too soft, 30 is too sharp, 28 is good.

Original / mClean v1.3c / mClean(enh=28) / mClean(enh=35)




This latest version is causing color shifts (SBS logo)
Original / mClean


Mostly all it does with the KARA - Dazzling Red clip is over-sharpen and distort colors. Can't really compare because of color shifts.

On my 288p VCD upscaled to 768p (full script and replacing the denoiser line). enh=15 is too much but enh=7 works. Interestingly enough, renoise makes very little difference at all ... if anything, it just add a little bit of sharpening? This version is doing a good job here, keeping the right details and discarding the right things.

No denoise / mClean v1.3c / mClean(enh=7) / mClean(enh=15)


Other types of noise, however, it's not doing anything expect sharpening the noise and distorting colors again
No denoise / mClean(enh=7)


Here, it's adding several distortions compared to v1.3c, such as loosing the teeth
No denoise / mClean v1.3c / mClean(enh=7)


In terms of versioning, changing the major number from 1 to 0 would respect the conventions; then each dev build could keep incrementing the way you're doing (0.7, 0.8, etc)

[burfadel]

I can change enh setting, just thought of a better - and obvious in many ways, way applying the strength. I didn't think to test with VCD resolution. The colour shift is easily fixed, again it's possibly a function of resolution. I'd have to find some clips where it doesn't work as well as previous versions as it's some simple fine tuning. 1.7 should be faster?

[MysteryX]

download KARA - Dazzling Red (link above) and try on it

[ChaosKing]

@burfadel will you port this script to vapoursynth too? I find it quite effective against heavy noise, with better "color stabilising" than smdegrain. (at least for my anime source)

[MysteryX]

In terms of performance (with prefetch 8)

v1.6 - 540p

FPS (min | max | average):      0.915 | 15800 | 13.10
Memory usage (phys | virt):     1031 | 1162 MiB
Thread count:                   38
CPU usage (average):            61%

v1.7 - 540p

FPS (min | max | average):      1.557 | 21067 | 21.87
Memory usage (phys | virt):     859 | 932 MiB
Thread count:                   35
CPU usage (average):            68%

v1.7 - 1080p

FPS (min | max | average):      0.768 | 64957 | 5.620
Memory usage (phys | virt):     1702 | 2026 MiB
Thread count:                   41
CPU usage (average):            69%

I think you've just designed the most expensive plugin in Avisynth in terms of memory usage. Makes it difficult to insert it into a script -- almost have to run it separately with an intermediary AVI file.

[Groucho2004]

Originally Posted by MysteryX

In terms of performance

Can you post the script with which which you obtained these results?

[burfadel]

Originally Posted by MysteryX

In terms of performance (with prefetch 8)

v1.6 - 540p

FPS (min | max | average):      0.915 | 15800 | 13.10
Memory usage (phys | virt):     1031 | 1162 MiB
Thread count:                   38
CPU usage (average):            61%

v1.7 - 540p

FPS (min | max | average):      1.557 | 21067 | 21.87
Memory usage (phys | virt):     859 | 932 MiB
Thread count:                   35
CPU usage (average):            68%

v1.7 - 1080p

FPS (min | max | average):      0.768 | 64957 | 5.620
Memory usage (phys | virt):     1702 | 2026 MiB
Thread count:                   41
CPU usage (average):            69%

I think you've just designed the most expensive plugin in Avisynth in terms of memory usage. Makes it difficult to insert it into a script -- almost have to run it separately with an intermediary AVI file.

I'm guessing you're running 32-bit Avisynth? I suspect it's the recalc, great for performance but obviously not for memory when combined with multithreading! I can think of two alternatives, I'll have to figure which one is more appropriate.

[Groucho2004]

Ran a few tests (i5 2500K @ 4GHz / 4 cores, AVS+ 64 bit):

[Script]

#SetMemoryMax(3000)
colorbars(width = 1920, height = 1080, pixel_type = "yv12").killaudio().assumefps(25, 1).trim(0, 99)
#ConvertTo16Bit()
mclean()
#Prefetch(4)

8 bit video (YV12):

FPS (min | max | average):      0.979 | 18.07 | 4.996
Memory usage (phys | virt):     582 | 587 MiB
Thread count:                   15
CPU usage (average):            27%

16 bit video (YUV420P16):

FPS (min | max | average):      0.377 | 2.532 | 1.503
Memory usage (phys | virt):     741 | 745 MiB
Thread count:                   15
CPU usage (average):            26%

16 bit video with Prefetch(4):

FPS (min | max | average):      0.699 | 85227 | 3.964
Memory usage (phys | virt):     1269 | 1471 MiB
Thread count:                   19
CPU usage (average):            77%

16 bit video with Prefetch(8) without using SetMemoryMax():

FPS (min | max | average):      0.029 | 325413 | 1.090
Memory usage (phys | virt):     1636 | 1954 MiB
Thread count:                   35
CPU usage (average):            81%

16 bit video with Prefetch(8) and SetMemoryMax(3000):

FPS (min | max | average):      0.508 | 325413 | 5.097
Memory usage (phys | virt):     2194 | 2535 MiB
Thread count:                   44
CPU usage (average):            99%

- 16 bit processing is a lot slower than 8 bit
- Using Prefetch(8) needs SetMemoryMax() to be set to ~3000 or performance drops massively

[MysteryX]

Originally Posted by Groucho2004

Can you post the script with which which you obtained these results?

sure

LWLibavVideoSource("source.mp4")
mclean()
Prefetch(8)

Originally Posted by Groucho2004

Using Prefetch(8) needs SetMemoryMax() to be set to ~3000 or performance drops massively

That's not even an option with x86

[Groucho2004]

Originally Posted by MysteryX

That's not even an option with x86

Why not? I just tried it, works just fine, although a bit slower than AVS+ 64 bit. Obviously that only works on a 64 bit OS.

[MysteryX]

Isn't x86 limited to 2GB? There's the 3GB patch but even with that I've had crashes when approaching the 2GB limit. (maybe related to AvisynthShader, haven't tested in a while)

[Groucho2004]

Originally Posted by MysteryX

Isn't x86 limited to 2GB?

Yes, on 32 bit Windows (there are OS hacks but I wouldn't recommend them)

Originally Posted by MysteryX

There's the 3GB patch but even with that I've had crashes when approaching the 2GB limit.

The 3 GB patch only applies to 32 Bit Windows. So, you're on 32 bit Windows?

If the application that uses 32 Bit Avisynth is built with the LARGEADDRESSAWARE linker switch it can address up to 4 GB on a 64 Bit OS.