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

[lansing]

I found knlmeamscl to cause detail or edge sharpness loss. Denoising is ineffective if it also limits visual fidelity.
Here's the general order of sophistication of algorithm we have for spatial denoiser in avisynth now:
knlmeanscl>dfttest>fft3dfilter>removegrain

There's really no debate on its effectiveness, it's better than removegrain because it just has a better algorithm, end of debate.

As for chroma, it's just the sigma settings. There's a couple of things I haven't added for that yet also.
There's no point to tweak for chroma denoising because we cannot see them like 99% of the time. And I doubt that you tweak them by ExtractU/V+blown up brightness, so why even bother.

In addition to that, fft3dfilter's chroma denoise will desaturate color, people even use it as a derainbow alternative, so the best way to "fix" the problem is not use it.

The texture like noise isn't removed so much in that anime image, also remember you can set renoise to 0. Noise removal doesn't have to be absolute, some noise can be visually pleasing watching at a normal distance, without those overly flat surfaces. This of course depends on the type and quality of noise. mClean is temporally stabilised which is why it is relatively bandwidth friendly with renoise.
It's more like the removegrain inside mclean reached its limit than it chooses not to remove the grain.

[Groucho2004]

I'm also quite puzzled by the "loss of details" comments regarding KNLMeansCL. My experience with it (or any NLMeans algorithm) is the exact opposite. Maybe increasing the search window ("a") will yield better results.

[MysteryX]

Maybe increasing the search window ("a") will yield better results.
I've always been using KNLMeans with D=2, A=2

[MysteryX]

I did another test on a very grainy video take with my camera. In this case, KNLMeans wasn't doing a good job and I instead opted for SMDegrain.

Original / SMDegrain / mClean v1.3c / mClean v1.7c
https://s26.postimg.org/l3jjdk16t/Grain_original.png (http://postimg.org/image/l3jjdk16t/) https://s26.postimg.org/pdy79569x/Grain_smdegrain.png (http://postimg.org/image/pdy79569x/) https://s26.postimg.org/7k2p7un7p/Grain_mclean13.png (http://postimg.org/image/7k2p7un7p/) https://s26.postimg.org/ggdhbsdtx/Grain_mclean17.png (http://postimg.org/image/ggdhbsdtx/)

I lowered enh from 27 to 22. v1.3c does lose considerable details with such grains, and v1.7c does a lot better here. Much better output than SMDegrain.

I don't mind tweaking enh to what suits me best, but what is more of a problem is having to calculate its dynamic value before altering its value. You divine height by 40 for its default value. Perhaps it could set the division factor or something like that.

It's not giving the plastic effect, but it's not falling far. Without renoise, it would look like a plastic doll.

I can definitely use this instead of SMDegrain. v1.7c isn't giving as consistent results with low-quality VCDs though.

Note: the clip above is rather static. Animated scenes may give different results.

https://s26.postimg.org/ye7e72rr9/Grain2_original.png (http://postimg.org/image/ye7e72rr9/) https://s26.postimg.org/bzl4d3zlx/Grain2_mclean13.png (http://postimg.org/image/bzl4d3zlx/) https://s26.postimg.org/ycsuzx0jp/Grain2_mclean17.png (http://postimg.org/image/ycsuzx0jp/) https://s26.postimg.org/g16swihad/Grain2_mclean17.png (https://postimg.org/image/g16swihad/)

Here, unfortunately, it's blurring out my shirt.

[SaurusX]

I've always been using KNLMeans with D=2, A=2

I've found that changing the S value to S=1 also preserves more fine details. Star fields and the like. The higher the A value in combination with S=1, the better it seems to do.

That being said, I use D=1,A=3,S=1. Bumping up D to 2 can introduce encoding errors when you combine it with a lot of other temporal filters. The end effect seems to be minimal, especially for animated content.

EDIT FROM THE FAR FUTURE: Now I use D=3, A=1, S=1. S for the same reasons as before. A higher D does a better job of eliminating Gaussian random noise and keep details. A lower A provides less smoothing of large flat areas. I only increase A if I find that after removing the white noise with a high D that what's left behind is an uneven orange-peel or mottled look.

[burfadel]

If you can think if a better way to scale enh, since the greater the resolution the higher it needs to be. I've made some performance improvements to the script, and it also uses less memory. I've still got some tweaking to do on it. I've discovered search 0, 1, and 2 don't seem to be optimised, which makes sense, default 4 is practically faster. I wonder if optimisations from x265 could be incorporated, I think it will help with speed. Ideally STAR search should be ported and made default, it's as fast as UMH search in x265, sometimes faster, and provided results like exhaustive. The default search range in MVTools is quite small, a ported optimised STAR search would not only likely be faster but produce more accurate and nicer results. Remember the search algorithms in MVTools2 have been there for 10+ years, are unlikely fully optimised, and are the principle thing that is required by most functions. Other functions like MDegrain rely on it indirectly, but would still benefit hugely.

[burfadel]

Updated first post to v1.8. Speed improvements, memory use reduction, and better quality.

[Atak_Snajpera]

I did another test on a very grainy video take with my camera. In this case, KNLMeans wasn't doing a good job and I instead opted for SMDegrain.

https://s26.postimg.org/l3jjdk16t/Grain_original.png
This does not look like very grainy video to me! This is example of very grainy video
http://i.cubeupload.com/bhTQsW.png

[burfadel]

Is that grain changing every frame or is it consistent? If consistent the noise is basically a texture, so removal of that noise you are potentially removing detail. Spatial denoisers work on pixels or area of pixels as either a blank implementation, effectively acting as a blur, or difference between pixels to determine whether it should be removed. Temporal denoisers work by difference between frames, ideally in this case you track the movement over the temporal radius. Spatial denoisers were traditionally preferenced because they are generally fast and can be good at damping and softening static noise at the risk of losing detail. No denoiser can be perfect, because you are fundamentally changing the picture.

What did you think of v1.8? The results are 'quite different'. I might have to chase up a couple of things in MVTools2 with PinterF, the issues don't effect the output of v1.8, they're just bugs I found along the way that should be simple fixes.

[burfadel]

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

Sorry I didn't answer this question earlier, I forgot about it :D. I have no idea about Vapoursynth, the syntax is different and the workings of some of the commands is also different. mClean is still in development, it would be time consuming to maintain the changes between the two.

[lansing]

What did you think of v1.8? The results are 'quite different'. I might have to chase up a couple of things in MVTools2 with PinterF, the issues don't effect the output of v1.8, they're just bugs I found along the way that should be simple fixes.

Like I said before, you should have test it yourself before posting, or you would have known that the black dot artifacts was brought back again a couple of version ago.

And I don't really notice any speed improvement, same old 14fps on my 4770k with a 1080 blankclip script
BlankClip(length=10000, width=1920, height=1080, pixel_type="yv12")
killaudio()
mclean()
prefetch(8)

AVSMeter 2.6.2 (x64) - Copyright (c) 2012-2017, Groucho2004
AviSynth+ 0.1 (r2508, MT, x86_64) (0.1.0.0)

Number of frames: 10000
Length (hh:mm:ss.ms): 00:06:56.667
Frame width: 1920
Frame height: 1080
Framerate: 24.000 (24/1)
Colorspace: YV12

Frames processed: 656 (0 - 655)
FPS (min | max | average): 1.115 | 85451 | 14.22
Memory usage (phys | virt): 1935 | 2145 MiB
Thread count: 33
CPU usage (average): 72%

Time (elapsed): 00:00:46.121

Press any key to exit...

[burfadel]

I did do testing before posting, doesn't meant I can come across all issues. The speed thing you noticed is peculiar, in all testing that I did it was noticeably faster for me consistently, as well as using less memory.

Same test as you, except length is 1000. CPU usage is lower becuase I set prefetch(8) on a 16 thread machine.

mClean 1.7c:
AVSMeter 2.6.5 (x64) - Copyright (c) 2012-2017, Groucho2004
AviSynth+ 0.1 (r2508, MT, x86_64) (0.1.0.0)

Number of frames: 1000
Length (hh:mm:ss.ms): 00:00:41.667
Frame width: 1920
Frame height: 1080
Framerate: 24.000 (24/1)
Colorspace: YV12

Frames processed: 1000 (0 - 999)
FPS (min | max | average): 1.885 | 21560 | 21.32
Memory usage (phys | virt): 1792 | 2136 MiB
Thread count: 53
CPU usage (average): 41%

Time (elapsed): 00:00:46.9

mClean 1.8:
AVSMeter 2.6.5 (x64) - Copyright (c) 2012-2017, Groucho2004
AviSynth+ 0.1 (r2508, MT, x86_64) (0.1.0.0)

Number of frames: 1000
Length (hh:mm:ss.ms): 00:00:41.667
Frame width: 1920
Frame height: 1080
Framerate: 24.000 (24/1)
Colorspace: YV12

Frames processed: 1000 (0 - 999)
FPS (min | max | average): 1.783 | 26352 | 25.53
Memory usage (phys | virt): 1515 | 1536 MiB
Thread count: 37
CPU usage (average): 36%

Time (elapsed): 00:00:39.170

It's faster for me and uses less memory than mClean 1.7c. Also the CPU usage is less.

Of course it's a bit counter-intuitive to test a temporal filter, particularly one that uses MVTools2, on a blank clip :).

[tebasuna51]

In previous versions (at least until 1.4) there are the line:

blkSize = Default (blkSize, DefH<360 ? 8 : DefH<750 ? 12 : DefH<1200 ? 16 : DefH<1600 ? 24 : 32) # Horizontal block size for MDegrain4

In mClean 1.8 the line is:

blkSize = Default (blkSize, defH>480 ? 12 : defH>1200 ? 16 : defH >=2600 ? 32 : 8) # Horizontal block size for MDegrain4

Are you sure about that sintax?

I think than defH>1200 ? 16 : defH >=2600 ? 32 never work, is always 12 for defH>480.

[Groucho2004]

Of course it's a bit counter-intuitive to test a temporal filter, particularly one that uses MVTools2, on a blank clip :).You can always use synthetic, random grain like this:
colorbars(width = 1920, height = 1080, pixel_type = "yv12").killaudio().assumefps(24000, 1001).trim(0, 999)
addgrain(var = 100.0)

[Sharc]

mClean Version 1.8, AVS+ 32 bit:
I'm getting from avisynth a "System exception - Illegal Instruction .... line 117" which is
clean = clean.dctfilter (1,1,1,1,1,1,0.50,0)
My dctfilter version is 0.5.0.0.

Any suggestion what could be wrong?

[burfadel]

If you run dctfilter by itself does it do the same thing? What CPU do you have?

[manolito]

What about this post by tebasuna51?
https://forum.doom9.org/showthread.php?p=1819328#post1819328

IMO he is absolutely right, the logic in the 1.8 version of the script is faulty.


Cheers
manolito

[burfadel]

What about this post by tebasuna51?
https://forum.doom9.org/showthread.php?p=1819328#post1819328

IMO he is absolutely right, the logic in the 1.8 version of the script is faulty.


Cheers
manolito

Possibly? I see what you mean though, I'll fix that for the next version.

Currently I'm trying to work out the most ideal way to work a new quality feature. It's ideal in almost all situations and frames, it's trying to work the remaining situations that is the tricky part. It resolves the issue on the snow clip that was posted :). I've tried basically everything simple, so I might have to look at another approach which will still be faster than v1.7c but take some of the gains of v1.8, in addition to taking some of the gains as a result of the feature itself. Hopefully it will be worth it though :).

[Sharc]

If you run dctfilter by itself does it do the same thing? What CPU do you have?
Problem solved, thanks.
By mistake I copied both the DCTFilter.dll and the DCTFilter_avx2.dll into the avisynth plugins folder.

[MysteryX]

v1.8 seems to give a little bit more of a plastic effect, and it shifts the image slightly to the left, which may be the cause of the 1st problem if luma/chroma aren't aligned

[burfadel]

There does appear to be a slight shift. After lots of testing it appears there is a minor bug in the MScaleVect function that's causing it. It's not related to block size or anything else. I'll report it in the MVTools2 thread.
http://forum.doom9.net/showpost.php?p=1819536&postcount=399

This same bug is probably why it doesn't work very well with MFlowFPS either.

[burfadel]

The other day Pinterf sent me a test version of MVTools2 which basically fixed the image shift issue. It was an error in one of the algorithms that was there since day one. There was still a very slight shift or difference in some motion between fully using Mscalevect and using base code, I'm not sure whether that could be resolved though. In terms of how mClean is set up though, basically the new version fixes the issue as I don't use it on radius 1. I guess if that additional error was improved upon I could add a fast option that runs it for radius 1 as well and maybe use Mdegrain3 instead of Mdegrain4 for that mode.

[cap5lock]

Using v1.8 got this error
Please help
https://s1.postimg.org/3u0v7j5mq7/image.png

[Groucho2004]

Using v1.8 got this error
Please help
Run "AVSMeter (https://forum.doom9.org/showthread.php?t=174797) -avsinfo -log". Post the created log file (avsinfo_x86.log).

[Sharc]

Using v1.8 got this error
Please help
https://s1.postimg.org/5ujddatcsv/image.png
Removing DCTFilter_avx2.dll from the plugins folder has solved exactly this problem for me (https://forum.doom9.org/showpost.php?p=1819409&postcount=219).

[cap5lock]

Removing DCTFilter_avx2.dll from the plugins folder has solved exactly this problem for me (https://forum.doom9.org/showpost.php?p=1819409&postcount=219).
Thanks
Unfortunately after removing avx2.dll, I got this error showed up
https://s1.postimg.org/1fkh3gaesv/image.png

Run "AVSMeter (https://forum.doom9.org/showthread.php?t=174797) -avsinfo -log". Post the created log file (avsinfo_x86.log).
Here it is the log file

Edit :
SOLVED
I used old DCTFilter dll by mistake...
Thanks for helping me

[MysteryX]

Original / mClean 1.7 / mClean 1.8

Here the result is excellent with v1.8
https://s1.postimg.org/1iwezdlhhn/1318_original.png (https://postimg.org/image/1iwezdlhhn/) https://s1.postimg.org/6xuxhsxukb/1318_mclean17.png (https://postimg.org/image/6xuxhsxukb/) https://s1.postimg.org/7c1d8o7nfv/1318_mclean18.png (https://postimg.org/image/7c1d8o7nfv/)

Here, there is still too much color shifts.
https://s1.postimg.org/1iwezdkewr/2749_original.png (https://postimg.org/image/1iwezdkewr/) https://s1.postimg.org/1pzmut6s23/2749_mclean17.png (https://postimg.org/image/1pzmut6s23/) https://s1.postimg.org/6cl9vi5jff/2749_mclean18.png (https://postimg.org/image/6cl9vi5jff/)

On 288p content, however, I still get best results with v1.3c; v1.7 and v1.8 add distortion and amplify artifacts. Is there a specific reason for this? Perhaps SD and HD content require different settings.

[burfadel]

Possibly. There is a bug in MVtools2 that affects 1.8. PinterF has fixed this and it will be in the next MVtools2 release. I was waiting on this before a new mClean. I did spend quite a while working on another 'feature' that works great in some specific scenarios in making it better (ideal even), but in other scenarios it was worse. For the remainder of situation it made no difference. Since it was scene dependent it's usefulness isn't really there. There is completely different way I could potentially do it that could have most of the benefits without the downsides, I'll have to do testing.

[MysteryX]

Yes I have Pinterf's fixed version, that's fine.

MDegrain4 gives good quality on HD grain (small pixels). However, on SD content with gross pixels and artifacts, it's distorting stuff. Perhaps you'll find a method that works for both HD and SD. If not, perhaps you can have a version for HD and a version for SD.

Then color distortion is the other concern -- entirely separate issue.

[burfadel]

I think I can work something out there!

[burfadel]

Updated first post with v1.9. I had to shuffle around the description etc as the first post exceeded the allowed post size limit. MysteryX, If the very low resolution handling (such as the 288P example you gave) is still a little iffy I can add handling for this, but I didn't want to add it with v1.9 if it appears unnecessary.

[tebasuna51]

I think than your line:

blkSize = Default (blkSize, defH>480 ? 12 : defH>1200 ? 16 : defH >=2600 ? 32 : 8) # Horizontal block size for MDegrain4

is still wrong in v1.9, blkSize 16 or 32 are never used, only 12 for defH>480 or 8 for defH<=480
Must be:

blkSize = Default (blkSize, defH >=2600 ? 32 : defH>1200 ? 16 : defH>480 ? 12 : 8) # Horizontal block size for MDegrain4

EDIT:
Also the sc parameter:

sc = defH>480 ? 2 : defH>1200 ? 4 : defH >=2600 ? 8 : 1

must be:

sc = defH >=2600 ? 8 : defH>1200 ? 4 : defH>480 ? 2 : 1

[burfadel]

Oops, I've made that correction now :). On a separate note, something that I was going to include requires the use of scriptclip, but I can not get it working within the script. If I run it outside the script it works fine.

Are you familiar with using scriptclip? I asked MysteryX, I can forward you the message I sent him on here if you are.

[StainlessS]

Just post your Scriptclip requirement here, let everyone see it.

Perhaps you keep getting mixed up with masktools RPN [EDIT: multi-ganged] '?:' ternary conditional, I think it works a bit back-to-front and weird
compared with everyone else's [EDIT: multi-ganged] version ternary conditional.

[burfadel]

For scriptclip, it would be something like:
combined = deband ? CombinePlanes(clean, chroma?filt_chroma:c, planes="YUV", source_planes="YUV", pixel_type=pixeltype(filt_chroma)) : nop()
combined = deband ? ScriptClip(" coloryuv(combined, gain_y=LumaDifference(c, clean), chroma?gain_u=ChromaUDifference(c, filt_chroma):0, chroma?gain_v=ChromaVDifference(c, filt_chroma):0) ") : nop ()
filt_chroma = deband ? mt_adddiff (combined, TemporalSoften(mt_makediff(combined, f3kdb (combined, preset=chroma?"high":"luma", range=17,
\ grainY=33, grainC=chroma?35:0)), 1, 255, chroma?255:0, scenechange=255, mode=2)) : filt_chroma
clean = deband ? ExtractY (filt_chroma) : clean

The second line is what's added to the passage. The above can be copied over the equivalent lines in v1.9 and scriptclip line adjusted according. It works outside the script as:
c=last
mClean()
filt_chroma=last
ScriptClip("coloryuv(filt_chroma, gain_y=LumaDifference(c, filt_chroma), gain_u=ChromaUDifference(c, filt_chroma), gain_v=ChromaVDifference(c, filt_chroma))")

When I added it to the script it didn't work. When it did appear to work with some faffing around it wasn't functional. You can see the difference by adding *150 (multiplying and overblowing the change to show the base number difference at least works) at the end of one of the gains, such as gain_v=ChromaVDifference(orig, filt_chroma)*120.

[StainlessS]

# How it is
S= "
\ coloryuv(combined,
\ gain_y = LumaDifference(c,clean),
\ chroma ? gain_u=ChromaUDifference(c,filt_chroma) : 0, # EDIT: kind of surprised these 2 lines work at all
\ chroma ? gain_v=ChromaVDifference(c,filt_chroma) : 0 # EDIT: Assuming that they do
\ )"

# more like how it should be,
# but, when not @ main script level, combined, c, clean. chroma, filt_chroma, are not in scope (unless globals).

# Maybe below more as intended (but args still not in scope)
S= "
\ coloryuv(combined,
\ gain_y = LumaDifference(c,clean),
\ gain_u = (chroma) ? ChromaUDifference(c,filt_chroma) : 0,
\ gain_v = (chroma) ? ChromaVDifference(c,filt_chroma) : 0
\ )"

combined = deband ? ScriptClip(S) : nop # This is horrible, [EDIT: perhaps nop should be combined]

# TEST
Colorbars.killaudio # Assign to Last
a=invert # inverted Last
a=false ? blankclip : NOP
return a # If true then returns blankclip else Error, "The script return value was not a clip (is an int, 0)"


EDIT: Grunt would let you import args using eg args="combined, c, clean. chroma, filt_chroma" as args to scriptclip.

EDIT: Also, take care with ScriptClip, requires a source arg, if not supplied then is implied to be Last (should it be c or combined or what, inside Scriptclip that source arg will become Last).

[MysteryX]

Note that if you use ScriptClip, you can't use MT anymore -- which renders it useless for practical use in many cases.

Perhaps you'd need a custom filter for this one? Plus you might do a better job if you decide how it's being done in the details.

Also perhaps other complex command chains would be better achieved as custom filters.

[burfadel]

I've worked out it, I just have to build on it now :). I also found that using 'pixel_type for combineplanes instead of sample_clip was 'wrong' :).

[tormento]

I tried a very silly mClean() in my script, just to give it a try, and the result is:
[2017-10-31][11:15:02] Simple x264 Launcher (Build #1118), built 2017-10-04
[2017-10-31][11:15:02]
[2017-10-31][11:15:02] Job started at 2017-10-31, 11:15:02.
[2017-10-31][11:15:02]
[2017-10-31][11:15:02] Source file : E:\in\1_30 Eden Lake\eden_mclean.avs
[2017-10-31][11:15:02] Output file : E:\in\1_30 Eden Lake\eden_mclean.mkv
[2017-10-31][11:15:02]
[2017-10-31][11:15:02] --- SYSTEMINFO ---
[2017-10-31][11:15:02]
[2017-10-31][11:15:02] Binary Path : D:\eseguibili\media\x264 launcher
[2017-10-31][11:15:02] Avisynth : Yes
[2017-10-31][11:15:02] VapourSynth : No
[2017-10-31][11:15:02]
[2017-10-31][11:15:02] --- SETTINGS ---
[2017-10-31][11:15:02]
[2017-10-31][11:15:02] Encoder : x264 (AVC/H.264), 64-Bit (x64), 8-Bit
[2017-10-31][11:15:02] Source : Avisynth (avs)
[2017-10-31][11:15:02] RC Mode : CRF
[2017-10-31][11:15:02] Preset : slow
[2017-10-31][11:15:02] Tuning : <None>
[2017-10-31][11:15:02] Profile : High
[2017-10-31][11:15:02] Custom : --level 4.1 --keyint 240 --vbv-bufsize 78125 --vbv-maxrate 62500 --aq-mode 2 --sar 1:1
[2017-10-31][11:15:02]
[2017-10-31][11:15:02] --- CHECK VERSION ---
[2017-10-31][11:15:02]
[2017-10-31][11:15:02] Detect video encoder version:
[2017-10-31][11:15:02]
[2017-10-31][11:15:02] Creating process:
[2017-10-31][11:15:02] "D:\eseguibili\media\x264 launcher\toolset\x64\x264_8bit_x64.exe" --version
[2017-10-31][11:15:02]
[2017-10-31][11:15:02] x264 0.152.2851kMod ba24899
[2017-10-31][11:15:02] (libswscale 4.7.101)
[2017-10-31][11:15:02] (libavformat 57.75.100)
[2017-10-31][11:15:02] (ffmpegsource 2.23.0.0)
[2017-10-31][11:15:02] built by Komisar on Jul 2 2017, gcc: 4.9.2 (multilib.generic.Komisar)
[2017-10-31][11:15:02] x264 configuration: --bit-depth=8 --chroma-format=all
[2017-10-31][11:15:02] libx264 configuration: --bit-depth=8 --chroma-format=all
[2017-10-31][11:15:02] x264 license: GPL version 2 or later
[2017-10-31][11:15:02] libswscale/libavformat/ffmpegsource license: GPL version 2 or later
[2017-10-31][11:15:02]
[2017-10-31][11:15:02] Detect video source version:
[2017-10-31][11:15:02]
[2017-10-31][11:15:02] Creating process:
[2017-10-31][11:15:02] "D:\eseguibili\media\x264 launcher\toolset\x64\avs2yuv_x64.exe"
[2017-10-31][11:15:02]
[2017-10-31][11:15:02] Avs2YUV 0.24bm5
[2017-10-31][11:15:02]
[2017-10-31][11:15:02] > x264 revision: 2851 (core #152) - with custom patches!
[2017-10-31][11:15:02] > Avs2YUV version: 0.24.5
[2017-10-31][11:15:02]
[2017-10-31][11:15:02] --- GET SOURCE INFO ---
[2017-10-31][11:15:02]
[2017-10-31][11:15:02] Creating process:
[2017-10-31][11:15:02] "D:\eseguibili\media\x264 launcher\toolset\x64\avs2yuv_x64.exe" -frames 1 "E:\in\1_30 Eden Lake\eden_mclean.avs" NUL
[2017-10-31][11:15:02]
[2017-10-31][11:15:03] error: MAnalyse: Block sizes must be 8 or more for divide mode
[2017-10-31][11:15:03] (D:/Programmi/Media/AviSynth+/plugins64/mClean-1.9�burfadel.avsi, line 109)
[2017-10-31][11:15:03] (E:\in\1_30 Eden Lake\eden_mclean.avs, line 13)
[2017-10-31][11:15:03]
[2017-10-31][11:15:03] PROCESS EXITED WITH ERROR CODE: 1

[burfadel]

Are you using the latest versions of all the plugins, for example MVTools2 (pfmod)? https://github.com/pinterf/mvtools/releases/

[tormento]

Are you using the latest versions of all the plugins, for example MVTools2 (pfmod)? https://github.com/pinterf/mvtools/releases/
Yes and the video is Mod 16.

[Groucho2004]

Yes and the video is Mod 16.
You could try running the script with AVSMeter. If that works, something else in the chain is not working as it should (avs2yuv?).

[burfadel]

The smallest blocksize that the script uses is 8. I tried it on a clip resolution of 524,288, and no hassles.

[tormento]

You could try running the script with AVSMeter. If that works, something else in the chain is not working as it should (avs2yuv?).
AVSMeter 2.6.0 (x64) - Copyright (c) 2012-2017, Groucho2004
AviSynth+ 0.1 (r2508, MT, x86_64) (0.1.0.0)

MAnalyse: Block sizes must be 8 or more for divide mode
(D:/Programmi/Media/AviSynth+/plugins64/mClean-1.9ùburfadel.avsi, line 109)
(E:\in\1_30 Eden Lake\eden_mclean.avs, line 13)

Same video works with SMDegrain, KNLMeansCL, FFT3D, etc etc etc

Isn't simply that a () without parameters triggers some strange bug?

My environment:
Log created with: AVSMeter 2.6.0 (x64)

[OS/Hardware info]
Operating system: Windows 10 (x64) (Build 17025)
CPU brand string: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz
CPU features: MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, POPCNT, AES


[Avisynth info]
VersionString: AviSynth+ 0.1 (r2508, MT, x86_64)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: C:\WINDOWS\SYSTEM32\avisynth.dll
Avisynth.dll time stamp: 2017-06-29, 09:09:33 (UTC)
PluginDir2_5 (HKLM, x64): D:\AviSynth+\plugins64
PluginDir+ (HKLM, x64): D:\AviSynth+\plugins64+


[CPP 2.5 / 64 Bit Plugins]
D:\AviSynth+\plugins64\Dither-1.27.2.dll
D:\AviSynth+\plugins64\f3kdb-2.0•20140721—SAPikachu.dll

[CPP 2.6 / 64 Bit Plugins]
D:\AviSynth+\plugins64+\ConvertStacked.dll
D:\AviSynth+\plugins64+\DCTFilter-0.5.0—chikuzen.dll [0.5.0.0]
D:\AviSynth+\plugins64+\DirectShowSource.dll
D:\AviSynth+\plugins64+\FFT3dFilter-2.4—pinterf.dll [2.4.0.0]
D:\AviSynth+\plugins64+\ImageSeq.dll
D:\AviSynth+\plugins64+\KNLMeansCL-1.1.0.dll
D:\AviSynth+\plugins64+\MaskTools-2.2.10—pinterf.dll [2.2.10.0]
D:\AviSynth+\plugins64+\MedianBlur2-0.94—tp7.dll
D:\AviSynth+\plugins64+\MVTools-2.7.2.23—pinterf.dll [2.7.23.0]
D:\AviSynth+\plugins64+\RgTools-0.96—pinterf.dll [0.96.0.0]
D:\AviSynth+\plugins64+\Shibatch.dll
D:\AviSynth+\plugins64+\TimeStretch.dll
D:\AviSynth+\plugins64+\VDubFilter.dll

[Scripts / AVSI]
D:\AviSynth+\plugins64+\colors_rgb.avsi
D:\AviSynth+\plugins64\CompTest.avsi
D:\AviSynth+\plugins64\DeHalo_alpha—realfinder.avsi
D:\AviSynth+\plugins64\Dither-1.27.2.avsi
D:\AviSynth+\plugins64\mClean-1.9—burfadel.avsi
D:\AviSynth+\plugins64\MT_xxpand_multi.avsi
D:\AviSynth+\plugins64\SMDegrain-3.1.2·93—realfinder.avsi
D:\AviSynth+\plugins64\VHSHaloremover.avsi

[Uncategorized / Other]
D:\AviSynth+\plugins64+\AviSynth-new.css
D:\AviSynth+\plugins64+\AviSynth.css
D:\AviSynth+\plugins64+\colors_rgb.txt
D:\AviSynth+\plugins64+\DCTFilter-0.5.0—chikuzen.md
D:\AviSynth+\plugins64+\FFT3dFilter-2.4—pinterf.gif
D:\AviSynth+\plugins64+\FFT3dFilter-2.4—pinterf.htm
D:\AviSynth+\plugins64+\FFT3dFilter-2.4—pinterf.txt
D:\AviSynth+\plugins64+\MaskTools-2.0a48.htm
D:\AviSynth+\plugins64+\MaskTools-2.2.10—pinterf.md
D:\AviSynth+\plugins64+\MedianBlur-0.84.txt
D:\AviSynth+\plugins64+\MVTools-2.7.2.22—pinterf.htm
D:\AviSynth+\plugins64+\MVTools-2.7.2.23—pinterf.md
D:\AviSynth+\plugins64+\RgTools-0.96—pinterf.md
D:\AviSynth+\plugins64\AviSynth-new.css
D:\AviSynth+\plugins64\AviSynth.css
D:\AviSynth+\plugins64\Dither-1.27.2.htm
D:\AviSynth+\plugins64\f3kdb-2.0•20140721—SAPikachu.html
D:\AviSynth+\plugins64\SMDegrain-3.1.2d.htm



[DLL dependencies (x64)]
C:\WINDOWS\SYSTEM32\avisynth.dll:
AVIFIL32.dll
MSVFW32.dll
MSACM32.dll
GDI32.dll
USER32.dll
ADVAPI32.dll
ole32.dll
imagehlp.dll
MSVCP140.dll
KERNEL32.dll
VCRUNTIME140.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll

D:\AviSynth+\plugins64\Dither-1.27.2.dll:
KERNEL32.dll

D:\AviSynth+\plugins64\f3kdb-2.0•20140721—SAPikachu.dll:
KERNEL32.dll

D:\AviSynth+\plugins64+\ConvertStacked.dll:
KERNEL32.dll
VCRUNTIME140.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll

D:\AviSynth+\plugins64+\DCTFilter-0.5.0—chikuzen.dll:
VCRUNTIME140.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
KERNEL32.dll

D:\AviSynth+\plugins64+\DirectShowSource.dll:
WINMM.dll
QUARTZ.dll
ole32.dll
USER32.dll
OLEAUT32.dll
KERNEL32.dll
VCRUNTIME140.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll

D:\AviSynth+\plugins64+\FFT3dFilter-2.4—pinterf.dll:
KERNEL32.dll
USER32.dll
VCRUNTIME140.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll

D:\AviSynth+\plugins64+\ImageSeq.dll:
DevIL.dll
MSVCP140.dll
KERNEL32.dll
VCRUNTIME140.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll

D:\AviSynth+\plugins64+\KNLMeansCL-1.1.0.dll:
OpenCL.dll
MSVCP140.dll
KERNEL32.dll
VCRUNTIME140.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll

D:\AviSynth+\plugins64+\MaskTools-2.2.10—pinterf.dll:
KERNEL32.dll
MSVCP140.dll
VCRUNTIME140.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll

D:\AviSynth+\plugins64+\MedianBlur2-0.94—tp7.dll:
MSVCR110.dll
KERNEL32.dll

D:\AviSynth+\plugins64+\MVTools-2.7.2.23—pinterf.dll:
KERNEL32.dll
MSVCP140.dll
VCRUNTIME140.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll

D:\AviSynth+\plugins64+\RgTools-0.96—pinterf.dll:
VCRUNTIME140.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
KERNEL32.dll

D:\AviSynth+\plugins64+\Shibatch.dll:
MSVCP140.dll
KERNEL32.dll
VCRUNTIME140.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll

D:\AviSynth+\plugins64+\TimeStretch.dll:
KERNEL32.dll
VCRUNTIME140.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll

D:\AviSynth+\plugins64+\VDubFilter.dll:
USER32.dll
KERNEL32.dll
VCRUNTIME140.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll

[External (plugin) functions]
D:\AviSynth+\plugins64\Dither-1.27.2.dll:
DitherPost
Dither_add16
Dither_bilateral16
Dither_box_filter16
Dither_limit_dif16
Dither_max_dif16
Dither_median16
Dither_merge16
Dither_min_dif16
Dither_out
Dither_removegrain16
Dither_repair16
Dither_resize16
Dither_sub16
SmoothGrad

D:\AviSynth+\plugins64\f3kdb-2.0•20140721—SAPikachu.dll:
f3kdb
flash3kyuu_deband

D:\AviSynth+\plugins64+\ConvertStacked.dll:
ConvertFromDoubleWidth
ConvertFromStacked
ConvertToDoubleWidth
ConvertToStacked

D:\AviSynth+\plugins64+\DCTFilter-0.5.0—chikuzen.dll:
DCTFilter
DCTFilter4
DCTFilter4D
DCTFilter8
DCTFilter8D
DCTFilterD

D:\AviSynth+\plugins64+\DirectShowSource.dll:
DirectShowSource

D:\AviSynth+\plugins64+\FFT3dFilter-2.4—pinterf.dll:
FFT3DFilter
FFT3DFilter_VersionNumber

D:\AviSynth+\plugins64+\ImageSeq.dll:
ImageReader
ImageSource
ImageSourceAnim
ImageWriter

D:\AviSynth+\plugins64+\KNLMeansCL-1.1.0.dll:
KNLMeansCL

D:\AviSynth+\plugins64+\MaskTools-2.2.10—pinterf.dll:
mt_adddiff
mt_average
mt_binarize
mt_circle
mt_clamp
mt_convolution
mt_deflate
mt_diamond
mt_edge
mt_ellipse
mt_expand
mt_freeellipse
mt_freelosange
mt_freerectangle
mt_gradient
mt_hysteresis
mt_infix
mt_inflate
mt_inpand
mt_invert
mt_logic
mt_losange
mt_lut
mt_lutf
mt_luts
mt_lutspa
mt_lutsx
mt_lutxy
mt_lutxyz
mt_lutxyza
mt_makediff
mt_mappedblur
mt_merge
mt_motion
mt_polish
mt_rectangle
mt_square

D:\AviSynth+\plugins64+\MedianBlur2-0.94—tp7.dll:
MedianBlur
MedianBlurTemporal

D:\AviSynth+\plugins64+\MVTools-2.7.2.23—pinterf.dll:
MAnalyse
MBlockFps
MCompensate
MDegrain1
MDegrain2
MDegrain3
MDegrain4
MDegrain5
MDegrain6
MDegrainN
MDepan
MFlow
MFlowBlur
MFlowFps
MFlowInter
MMask
MRecalculate
MRestoreVect
MSCDetection
MScaleVect
MShow
MStoreVect
MSuper

D:\AviSynth+\plugins64+\RgTools-0.96—pinterf.dll:
BackwardClense
Clense
ForwardClense
RemoveGrain
Repair
VerticalCleaner

D:\AviSynth+\plugins64+\Shibatch.dll:
SSRC
SuperEQ

D:\AviSynth+\plugins64+\TimeStretch.dll:
TimeStretch

D:\AviSynth+\plugins64+\VDubFilter.dll:
LoadVirtualdubPlugin

[Groucho2004]

I get the same error.
Script:
colorbars(width = 1024, height = 1024, pixel_type = "yv12").killaudio().assumefps(50, 1).trim(0, 499)
mclean()


Also, with a resolution of 1024 x 1024, I get this error:
Script error: f3kdb does not have a named argument "preset"
(E:/Apps/VideoTools/AVSPlugins/AutoLoad/mclean.avsi, line 140)
Edit: It seems that the experimental f3kdb 2.0pre2 is required.

[tormento]

Edit: It seems that the experimental f3kdb 2.0pre2 is required.
I think your comment refers only to second error, as I already had the experimental version and the first error occurred.

[burfadel]

2.0.0.1 for f3kdb is basically the 'final'. Work stopped on it, source code is available on github. https://github.com/SAPikachu/flash3kyuu_deband/releases

The other error is a result of a fixing a syntax error. I'll fix it for version 2.0, which will be released shortly. That one will require the autoadjust plugin for one of the settings change, allowing for basically harmonising colour balance, deflicker etc (more appropriate custom settings). Yes, another plugin, but it's super fast and applied at the appropriate location. It's also much more effective than my attempt that I got working with scriptclip but was a little finnicky stability wise. Basically there are four deband settings, 0=disabled, 1=deband only, 2=auto balance only, 3=deband and auto balance. Deband 1 is the default (so the extra filter won't be required), unless non 8 bit where 0 is default (f3kdb limitation), with auto balance option 2 will be still available.

[Groucho2004]

I think your comment refers only to second errorThat's correct.

[Groucho2004]

2.0.0.1 for f3kdb is basically the 'final'. Work stopped on it, source code is available on github. https://github.com/SAPikachu/flash3kyuu_deband/releasesI have been using f3kdb 1.5.1 for years and it has served me well. I'm a bit reluctant to use the 2.0 version because of SAPikachu's "experimental" and "use with caution" notes in the first post of the f3kdb thread. Maybe I should give it a try...

[MysteryX]

2.0.0.1 for f3kdb is basically the 'final'. Work stopped on it, source code is available on github. https://github.com/SAPikachu/flash3kyuu_deband/releases
There's no pre-compiled version of it?

and it requires Python AND GCC to build!? I won't spent half an hour just to try to build something that should be ready to use.