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

[MysteryX]

Something I've noticed around here is that whenever I'm working on something, there are always some members not just disagreeing but aggressively trying to destroy it.

I worked on SuperRes to improve the upscaling quality and many were saying it was impossible and that it was impossible to get better results than NNEDI3. Turns out it's now the best upscaling method available in Avisynth.

I worked on FrameRateConverter and people were saying it was impossible to accurately detect artifacts to give an output that works most of the time, and that I shouldn't waste any time even trying. I did it and it's working pretty well.

Now I'm hearing the same thing all over again with this. I'm getting used to the pattern. Yes, I know it's impossible. Yes, I know it doesn't make sense based on old concepts. We're doing it anyway. Because we don't operate from the same mental container. I think me and Burdafel have this in common. We don't think outside the box. We just didn't know of the box to begin with. That's more the space we should be thinking from.

[MysteryX]

Getting back on topic, what I'm seeing is that with MvTools, the vector motion data is a lot more important than I thought. Tiny changes to motion vectors data can result in very different results. To the point where RemoveGrain(18) and RemoveGrain(21) produce a considerably different output -- which I know, doesn't make logical sense.

[lansing]

Watch your language. If you don't like what we're doing, just get the heck out.


Yes that's what I meant by original, perhaps I should have called it "no prefilter", but I think anyone with a brain understood that. I can't compare with original because generated frames don't match source frames.

Please, if you got nothing constructive to say, shut up.

Edit: I renamed it to "no prefilter" to avoid confusing anyone else

If someone else views any screenshot other than mClean(rn=10) to give better results, I'm listening, but please have something to back up what you say. This test is pretty simple: comparing 6 versions of a script to see which gives better results. I don't care about how "things should be done", I only care about concrete results.
What in the blue hell does that have to do with this thread?

Since when does this thread gone from comparing OP's script to other denoisers, to comparing how every denoiser perform inside YOUR filter?

I'm pretty certain that I said more constructive things than someone who have hijacked the thread for the last 5 pages talking about his own stuffs. I didn't see you saying a single word about the obvious problem that is underlying in OP's core smdegrain. To evaluate the quality of filter, you have to look it in both the pros and cons, if the cons exceeded a certain point, then the filter is a no go.

Here's a short scene emphasizing the problem I'm talking about.
snow (http://www.mediafire.com/file/p9jgodk3mwf9loo/snow.avi)

[MysteryX]

The conversation of mClean began within the conversation of FrameRateConverter. Budafel stated that he wanted to improve the source to feed into the interpolation. That's definitely not its only use.

Here's a short scene emphasizing the problem I'm talking about.
snow (http://www.mediafire.com/file/p9jgodk3mwf9loo/snow.avi)
Finally something constructive. You never mentioned this before unless I missed a few posts.

I found previously that KNLMeansCL worked well with artifacts but SMDegrain worked better with grainy videos, kind of like the one you have.

I was wondering whether mClean would replace SMDegrain, and I think that your post answers the question. I suppose SMDegrain is what gives the best result on that clip?

Burdafel, I'm testing your latest version with my 288p VCDs. enh=13, rn=10 is working good. enh=20, rn=12 is too much, in similar proportion to the HD videos. There's little difference between rn=0 and rn=10 but for heavy artifacts rn=0 works better. It seems this filter performs equally well on heavy artifacts or on no-artifacts clips. Which is a good thing when both are in the same frame.

Can you post a sample frame where you say it benefits from high enh?

[MysteryX]

288p clip with denoise, upscale and frame interpolation.

- Deblock_QED
- Deblock_QED + mClean(rn=0)
- KnlMeansCL(D=2, A=2, h=1.8, channels="YUV")

https://s26.postimg.org/6982h80p1/5483_no.png (http://postimg.org/image/6982h80p1/) https://s26.postimg.org/6ai0an2it/5483_mclean.png (http://postimg.org/image/6ai0an2it/) https://s26.postimg.org/4swjz2xs5/5483_knl.png (http://postimg.org/image/4swjz2xs5/)

KnlMeans removes a lot more artifacts but kills a lot of details, especially in the curtains.

mClean is again my favorite version, BUT artifact removal is a bit weak. Raising thSAD removes real details instead of removing more artifacts. Is there a way to make it just a little bit stronger? Perhaps lansing's clip has the same issue: mClean is a bit too weak for the job. I'm sure you'll come up with a new feature idea that will fix this.

[lansing]

The conversation of mClean began within the conversation of FrameRateConverter. Budafel stated that he wanted to improve the source to feed into the interpolation. That's definitely not its only use.

If that was his original intention then he should change the title to something like "a denoiser for better motion vector search for mvtools".

Finally something constructive. You never mentioned this before unless I missed a few posts.
Because I wasn't expecting someone who're writing a filter around smdegrain to not know the fault of smdegrain.


I was wondering whether mClean would replace SMDegrain, and I think that your post answers the question. I suppose SMDegrain is what gives the best result on that clip?
No! It's the complete opposite! That's the reason I don't use smdegrain, don't you see that mclean(smdegrain) is wiping out half of the snow which are details? Where is your logical sense?

For the OP, he'll eventually need to make a decision between quality and performance, just like what he had been adviced (https://forum.doom9.org/showthread.php?p=1815184#post1815184). If he is not to fix the core problem of his denoiser (like right now), then his script is going to be just another variation of smdegrain no matter how many fancy post processing he add. If he IS to fix it, he must also realize that someone had already done that 9 years ago. Why even bother reinventing the same thing...
MCTD (https://forum.doom9.org/showthread.php?t=139766)

[burfadel]

Yes, most often it is a tradeoff of performance and speed. You are limited by the speed of the filters used, so the best idea would be to find new ways of dealing with that. Most filter scripts use the same process for Chroma and Luma. I use the most ideal solution for these. MVtools does not do a good job on Chroma, but does on Luma. FFT3DFilter is similar on Luma as KNLMeansCL, but is great on Chroma. KNLMeansCL on chroma isn't the most efficient option.

In terms of the post processing, remoise is quite differet to the other options out there, it's perceptual based intended for motion, so still shots may not represent the trueness of it. In terms of sharpening, it is detail orientated and works on the inverse of the areas that renoise works on. The actual sharpen method itself is a unsharp filter. I haven't seen the solution I used elsewhere, it's ultra simple and super fast though :). Most other filters use external scripts. mClean doesn't deblock, unless I find a differing solution to what is out there it probably won't! Any other solutions can run separately afterwards. That said, there would be some benefit from internalising something like deblock_QED and simplifying it, because applying renoise and the sharpening after it would be beneficial. There's also another filter I would consider simplifying and incorporating it for the same reason, but ultimately any filters such as these will have simplified parameters. Most of the extra parameters or changing settings serves little or no benefit, and any change they do provide is usually in relation to another setting... so you can apply it as one setting that scales the individual settings. There are some useful things in MCTemporalDenoise, I saw those earlier :). At the moment I haven't borrowed from that script, but I probably will in the future and simplify where necessary. It's why I originally referred to it as an all-in-one script that I wanted to keep as simple as possible. Make the best script that I can do, and only then apply the best features from the other scripts and simplify their parameters. This is also inclusive of leveraging any advancements in Avisynth or respective filters, as well as accepting different solutions that people offer. I'll of course mention the respective other scripts when utilsing portions of their code.

As an all-in-one I also intended it to be a prefilter for FrameRateConverter or anything else, MysteryX knows this :).

[feisty2]

Since u guys been bitching about NLMeans a lot, y'all should know "h" is not the only hyperparameter? "s" is another major parameter that has to be carefully tweaked, default "s=4" is def a no go for ur shitty vcd garbage, make it 1 and gradually increase it till it feels rite

[lansing]

Yes, most often it is a tradeoff of performance and speed. You are limited by the speed of the filters used, so the best idea would be to find new ways of dealing with that.

Yes, that would require ideas for a new algorithm, not by using 10+ years old filters like what you're doing right now. Even then, the law between quality vs performance is not going to change, better quality is going to take longer processing time.

All the talk you said about your post processings are not reflecting on your result because your core denoising method (smdegrain) is giving you crappy input. All I'm seeing right now are the artifacts created by your smdegrain and artifacts created your mask.

[MysteryX]

If that was his original intention then he should change the title to something like "a denoiser for better motion vector search for mvtools".
It's not only for that, as Burdafel already explained clearly enough.

mclean(smdegrain) is wiping out half of the snow which are details
I can't even know that from the clip you sent, as I don't have the original. Next time I would suggest posting individual frames before and after so we can see the difference.

To evaluate the quality of filter, you have to look it in both the pros and cons, if the cons exceeded a certain point, then the filter is a no go.
That's where you and I fundamentally disagree. You're here to destroy. We're here to create.

If someone works on something that gives bad results, I'll point the flaws so that at the very least he will learn and improve himself from it. You'll just go in with a knife in his back to destroy him and his ideas. If you succeed, it's unlikely that member will bring anything else in the future. Luckily, there are many resilient members on this forum. I guess many are used to this dynamic (which isn't only you), as I see several people wait late in their development cycle until their script is solid before exposing it to public -- where it often gets torn apart.

So far I haven't seen any case where mClean degraded an image in any significant way. Perhaps your snow clip but I haven't seen the effect yet, nor what settings you used. If there is image deterioration, renoise should alleviate it.

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

Putting that aside,

Burdafel, from what I've tested so far, it does a good job with subtle noise removal. Perfect as a prefilter, but a bit weak as a full-blown denoiser. Whether it works as a degrainer remains to be tested (perhaps on HD camera footage).

I'm not concerned about performance. There is however a trade-off between denoising and preserving details, and here the main focus was on preserving details, but perhaps there could be an effective "strength" setting.


Since u guys been bitching about NLMeans a lot, y'all should know "h" is not the only hyperparameter? "s" is another major parameter that has to be carefully tweaked, default "s=4" is def a no go for ur shitty vcd garbage, make it 1 and gradually increase it till it feels rite
Thanks, I'll definitely test it out!

P.S. I never bitch. Maybe if someone really crosses the line, and even then it's not bitching.

[burfadel]

Grain, both good and bad, is the main target. Artifacts are much harder as they're also effectively detail. I'll look for the happy balance. :)

[lansing]

So far I haven't seen any case where mClean degraded an image in any significant way. Perhaps your snow clip but I haven't seen the effect yet, nor what settings you used. If there is image deterioration, renoise should alleviate it.

You don't see it because you have eye problem as it was proven here (https://forum.doom9.org/showthread.php?p=1816662#post1816662), and you have a history of seeing invisible stuff (https://forum.doom9.org/showthread.php?p=1745470#post1745470). All your feedbacks are bullshit that were based on who knows what you saw.

The snow clip is a very good example exposing the problem of smdegrain.

original
http://i.imgur.com/KpvRPwp.png

mclean()
http://i.imgur.com/dDaRXar.png

The difference is so obvious, the filter is altering any moving object trying to smooth out the motion, in this case, it's wiping out the snow.


Here the filter is wiping out the detail on anything that moves:

original
http://i.imgur.com/dj0EGzX.png

mclean()
http://i.imgur.com/dIkJ94X.png

You're here to destroy. We're here to create.

If someone works on something that gives bad results, I'll point the flaws so that at the very least he will learn and improve himself from it.

This is so funny, I AM the one that's pointing out the flaws, not you! You can't even see the flaws because of your eye problem! You can't even see the artifacts that were created by the mask who know existed for how long.

[MysteryX]

Also post the script settings you use.

Posting on PostImage.io has the advantage of taking little space here and allowing to easily open in full-screen to compare images.

I agree that this particular clip reacts badly. Then it would be useful to see how it behaves with other denoisers. If you want to contribute, I would suggest posting sufficient relevant data:
- plugins/settings used
- screenshot
- comparison with other relevant denoisers
- your observation or conclusion in regards to the test ("this is BS" isn't a technical conclusion)

Sending the source of a difficult clip like that one could also be useful for Burdafel to work with. I developed FrameRateConverter using the worst videos I had for interpolation.

Every personal attacks might come back to you as big headaches -- better stick to a technical conversation.

[MysteryX]

Also Burdafel, if you need some custom algorithm written in C++, I can help with that (at least CPU version without assembly opt)

[Groucho2004]

BurdafelThat makes 7 times you got his moniker wrong. :D

[StainlessS]

That makes 7 times you got his moniker wrong. :D

I think I've been guilty of same thing a number of times, Burfadel just dont sound as good Burdafel, maybe an name change is in order :)

EDIT: To below, perhaps I have not posted wrong name, but I have definitely been using that name mentally.

[Groucho2004]

I think I've been guilty of same thing a number of times, Burfadel just dont sound as good Burdafel, maybe an name change is in order :)Couldn't find a single instance. Maybe someone else who's name you butchered? Like Grouchy? :rolleyes:

Actually, Grouchy is fine with me, has a nice ring to it.

[MysteryX]

Burfadel just dont sound as good Burdafel, maybe an name change is in order :)
Agree

Groucho, every time I see your name I'm thinking of Schtroumpf Grognon
https://vignette1.wikia.nocookie.net/schtroumpfs/images/b/ba/Schtroumpf-grognon_original_backup.jpg/revision/latest?cb=20150222140755&path-prefix=fr

[burfadel]

You don't see it because you have eye problem as it was proven here (https://forum.doom9.org/showthread.php?p=1816662#post1816662), and you have a history of seeing invisible stuff (https://forum.doom9.org/showthread.php?p=1745470#post1745470). All your feedbacks are bullshit that were based on who knows what you saw.

The snow clip is a very good example exposing the problem of smdegrain.

original
http://i.imgur.com/KpvRPwp.png

mclean()
http://i.imgur.com/dDaRXar.png

The difference is so obvious, the filter is altering any moving object trying to smooth out the motion, in this case, it's wiping out the snow.


Here the filter is wiping out the detail on anything that moves:
...

This is so funny, I AM the one that's pointing out the flaws, not you! You can't even see the flaws because of your eye problem! You can't even see the artifacts that were created by the mask who know existed for how long.

Dont get mixed up between SMDegrain and MDegrain, SMDegrain is a script using MDegrain as it's base :).

When removing grain you inevitably will remove what perceptually is detail. It's why adding the right type and amount of grain can make the image appear clearer and less flat. In this case, what appears to be detail that is removed due to the grain structure appearing as texture is actually most likely noise.

I've put together a test script with options for Mdegrain 3 through 6. This is adjusted by changing value of 'm'. If none is specific, the default 2 is used (MDegrain2), if you select 6 it will use MDegrain6, which is slower and should be overkill!

Additionally to that, there's an option 'recalc'. Default is false. If true, Mrecalculate will be used. This is a viable option speed wise if it has better quality :).

There's also an option for search method, applied to recalculation. Reason for this is exhaustive search may be too slow for Analysis stage, but fine for recalculation due to the recalculation only being done for bad vectors. This will only have affect if recalc=true.

Finally, there's an option for DCT. Again, this is for recalc only as this is where it would most likely be beneficial and has less of an impact on speed. If false (default) it uses the default DCT value which is 0. If true, it uses DCT value 4. Value 4 is preferable over 1 due to speed, and it maintains most of the benefits of 1.

So, play around with these test functions and let me know what you like best. The renoise function will work differently for each setting, so you may also want to use rn=0 to see just the Mdegrain process, or rn=12 (for instance) to see how it responds in relation to noise removed.

This is just a test for differences, which one performs the best for you. As an added test, I changed the rfilter value for 4, if using just mCleanT() this will be the only difference between this script and mClean.

Function is mCleanT(), T for Test.
m: 2 through 6. MDegrain function. Default is 2, which uses MDegrain2 function. Options 3-6 will use MDegrain3, MDegrain4, MDegrain5, or MDegrain6
recalc: True/false. Default is false. Recalculate vectors when set to true. Setting to true will also activate search and dct options if specified
search: True/false. Fefault is false, which uses the mClean setting of 5 (UMH search). If set to true, will enable exhaustive search (3) for the recalculation (with recalc=true)
dct: True/false. Default is false where dct 0 is used. If true dct 4 is used for recalculation (with recalc=true)

If you like feel free to adjust the searchparam values.

Those black spots when using mClean obviously shouldn't be there. Is it possible to upload a 10 second clip to Onedrive, Google drive, Mediafire etc? That way I can investigate and resolve that.

# mClean Test spatio/temporal denoiser
# Version: 1.3c_2 (29 August 2017)
# By burfadel

### TEST ONLY ###
### NOTE: Function name is mCleanT ###

# +++ Required plugins +++
# Latest RGTools, MVTools2, Masktools2, FFT3DFilter by Pinterf
# Latest Modplus, only required if using sharpening overboost (enh settings 101 and 102)
# Requires latest fftw.dll to be installed as instructed on the website - http://www.fftw.org


function mCleanT(clip c, int "thSAD", int "blksize", int "blksizeV", int "overlap", int "overlapV", int "enh", int "rn", int "outbits", int "m", bool "recalc", bool "dct", bool "search", int "cpu")
{
defH = Max (C.Height, C.Width/4*3) # Resolution calculation for auto blksize settings
thSAD = Default (thSAD, 450) # Denoising threshold
blksize = Default (blksize, defH<360 ? 8 : defH<750 ? 12 : defH<1200 ? 16 : defH<1600 ? 24 : 32) # Horizontal block size for MDegrain2
blksizeV = Default (blksizeV, blksize) # Vertical block size for MDegrain2, default same as horizontal
overlap = Default (overlap, blksize>4?(blksize/4+1)/2*2:0) # Horizontal block overlap
overlapV = Default (overlapV, blksize>4?(blksizeV/4+1)/2*2:0) # Vertical block overlap
enh = Default (enh, 13) # Detail enhancement (detail orientated sharpen) strength
rn = Default (rn, 10) # ReNoise strength from 0 (disabled) to 20
outbits = Default (outbits, c.BitsPerComponent) # Output bits, default input depth
calcbits = c.BitsPerComponent == 8 ? 12 : c.BitsPerComponent
calcbits = outbits > calcbits ? calcbits : outbits
m = Default (m, 2) # MDegrain steps
recalc = Default (recalc, false) # Process recalc
dct = Default (dct, false) # To use DCT=4 or not on recalc
search = Default (search, false) # If true uses exhaustive search on recalc
cpu = Default (cpu, 4) # Threads for fft3dfilter


Assert(isYUV(c)==true, """mClean: Supports only YUV formats (YV12, YV16, YV24)""")
Assert(isYUY2(c)==false, """mClean: Supports only YUV formats (YV12, YV16, YV24)""")
Assert(isYV411(c)==false, """mClean: Supports only YUV formats (YV12, YV16, YV24)""")
Assert(enh>=0 && enh<=102, """mClean: "enh" ranges from 0 to 102""")
Assert(rn>=0 && rn<=20, """mClean: "rn" ranges from 0 to 20""")
Assert(outbits>=8 && outbits<=16, """mClean: "outbits" ranges from 8 to 16""")
Assert(m>=2 && m<=6, """mClean Test: "m" ranges from 2 (default) to 6""")
dct = (dct==true) ? 4 : 0
search = (search==true) ? 3 : 5

# Spatio/temporal chroma noise filter
filt_chroma = fft3dfilter (c, bw=blksize*2, bh=blksizeV*2, ow=overlap*2, oh=overlapV*2, sharpen=0.12, bt=3, ncpu=cpu, dehalo=0.3, sigma=2.35, plane=3)

# Temporal luma noise filter
super = c.MSuper (chroma=false,hpad=16, vpad=16, rfilter=4)
super2 = c.MSuper (chroma=false, hpad=16, vpad=16, levels=1, rfilter=4)
bvec6 = (m==6) ? MAnalyse (super, chroma=false, delta = 6, isb = true, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=13) :nop
bvec5 = (m>=5<=6) ? MAnalyse (super, chroma=false, delta = 5, isb = true, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=11) :nop
bvec4 = (m>=4<=6) ? MAnalyse (super, chroma=false, delta = 4, isb = true, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=9) :nop
bvec3 = (m>=3<=6) ? MAnalyse (super, chroma=false, delta = 3, isb = true, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=7) :nop
bvec2 = MAnalyse (super, chroma=false, isb = true, delta = 2, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=5)
bvec1 = MAnalyse (super, chroma=false, isb = true, delta = 1, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=3)
fvec1 = MAnalyse (super, chroma=false, isb = false, delta = 1, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=3)
fvec2 = MAnalyse (super, chroma=false, isb = false, delta = 2, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=5)
fvec3 = (m>=3<=6) ? MAnalyse (super, chroma=false, isb = false, delta = 3, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=7) :nop
fvec4 = (m>=4<=6) ? MAnalyse (super, chroma=false, isb = false, delta = 4, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=9) :nop
fvec5 = (m>=5<=6) ? MAnalyse (super, chroma=false, isb = false, delta = 5, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=11) :nop
fvec6 = (m==6) ? MAnalyse (super, chroma=false, isb = false, delta = 6, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV, search=5, searchparam=13) :nop

bvec6 = (recalc==false) ? bvec6 : (m==6) ? MRecalculate (super2, bvec6, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=13, dct) :nop
bvec5 = (recalc==false) ? bvec5 : (m>=5<=6) ? MRecalculate (super2, bvec5, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=11, dct) :nop
bvec4 = (recalc==false) ? bvec4 : (m>=4<=6) ? MRecalculate (super2, bvec4, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=9, dct) :nop
bvec3 = (recalc==false) ? bvec3 : (m>=3<=6) ? MRecalculate (super2, bvec3, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=7, dct) :nop
bvec2 = (recalc==false) ? bvec2 : MRecalculate (super2, bvec2, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=5, dct)
bvec1 = (recalc==false) ? bvec1 : MRecalculate (super2, bvec1, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=3, dct)
fvec1 = (recalc==false) ? fvec1 : MRecalculate (super2, fvec1, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=3, dct)
fvec2 = (recalc==false) ? fvec2 : MRecalculate (super2, fvec2, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=5, dct)
fvec3 = (recalc==false) ? fvec3 : (m>=3<=6) ? MRecalculate (super2, fvec3, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=7, dct) :nop
fvec4 = (recalc==false) ? fvec4 : (m>=4<=6) ? MRecalculate (super2, fvec4, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=9, dct) :nop
fvec5 = (recalc==false) ? fvec5 : (m>=5<=6) ? MRecalculate (super2, fvec5, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=11, dct) :nop
fvec6 = (recalc==false) ? fvec6 : (m==6) ? MRecalculate (super2, fvec6, chroma=false, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2, search=search, searchparam=13, dct) :nop

clean = (m==2) ? c.MDegrain2 (super, bvec1, fvec1, bvec2, fvec2, thSAD=thSAD, plane = 0) :nop
clean = (m==3) ? c.MDegrain3 (super, bvec1, fvec1, bvec2, fvec2, bvec3, fvec3, thSAD=thSAD, plane = 0) :clean
clean = (m==4) ? c.MDegrain4 (super, bvec1, fvec1, bvec2, fvec2, bvec3, fvec3, bvec4, fvec4, thSAD=thSAD, plane = 0) :clean
clean = (m==5) ? c.MDegrain5 (super, bvec1, fvec1, bvec2, fvec2, bvec3, fvec3, bvec4, fvec4, bvec5, fvec5, thSAD=thSAD, plane = 0) :clean
clean = (m==6) ? c.MDegrain6 (super, bvec1, fvec1, bvec2, fvec2, bvec3, fvec3, bvec4, fvec4, bvec5, fvec5, bvec6, fvec6, thSAD=thSAD, plane = 0) :clean

clean = calcbits != clean.BitsPerComponent ? clean.ConvertBits(calcbits) : clean
c = calcbits != c.BitsPerComponent ? c.ConvertBits(calcbits) : c

# Masks for spatial noise reduction and noise independent detail enhancement
noised = mt_makediff (clean, c, u=1, v=1)
noise = mt_binarize (clense(mt_makediff(mt_binarize(noised, u=1, v=1), mt_edge(sharpen(clean, 0.85), "prewitt", u=1, v=1), u=1, v=1), grey=true), u=1, v=1)

# Spatial luma denoising
clean2 = mt_merge (clean, removegrain(clean, 18, modeU=-1, modeV=-1), noise, u=1, v=1)

# Unsharp filter for spatial detail enhancement
clsharp = (enh>0<=100) ? mt_adddiff (mt_makediff(clean, blur(clean, 0.80*(enh/100), 0.50*(enh/100)), u=1, v=1), clean2, u=1, v=1) : clean
clsharp = (enh>=101<=102) ? mt_adddiff (mt_makediff(clean, gblur(clean, enh-100), u=1, v=1), clean2, u=1, v=1) : clsharp

# If selected, combining ReNoise
renoise = (rn==0) ? nop : tweak(temporalsoften (noised, 4, 255, 0, scenechange=0, mode=2), cont=1.010+(0.020*(rn/20)), bright=1.01+(0.04*(rn/20)))
clean2 = (rn>0<=20) ? mergeluma (clean2, mt_adddiff(clean2, renoise, u=1, v=1), 0.3+(rn*0.035)) : clean2

# Combining spatial detail enhancement with spatial noise reduction using prepared mask
filt_luma = mt_merge (clean2, clsharp, mt_invert(mt_convolution(noise, u=1, v=1), u=1, v=1), u=1, v=1)

# Converting bits per channel
filt_luma = outbits < filt_luma.BitsPerComponent ? ConvertBits(filt_luma, outbits, 1) : filt_luma
filt_chroma = filt_chroma.BitsPerComponent <> filt_luma.BitsPerComponent ? ConvertBits(filt_chroma, BitsPerComponent(filt_luma)) : filt_chroma

# Combining result of luma and chroma cleaning
return mergechroma (filt_luma, filt_chroma)
}

Let me know how it goes :).

[lansing]

Also post the script settings you use.

Posting on PostImage.io has the advantage of taking little space here and allowing to easily open in full-screen to compare images.

I agree that this particular clip reacts badly. Then it would be useful to see how it behaves with other denoisers. If you want to contribute, I would suggest posting sufficient relevant data:
- plugins/settings used
- screenshot
- comparison with other relevant denoisers
- your observation or conclusion in regards to the test ("this is BS" isn't a technical conclusion)

Sending the source of a difficult clip like that one could also be useful for Burdafel to work with. I developed FrameRateConverter using the worst videos I had for interpolation.

Every personal attacks might come back to you as big headaches -- better stick to a technical conversation.

There is nothing "difficult" about the snow clip, it's just an example demonstrating the typical behavior(con) of smdegrain. This is what was expected to get from the filter, apply it on any clip and you will get the same problem.

If the OP was to build the script around smdegrain, the very first thing he should had done was to write some logic to protect against its problem, that is how you build stuff. You build a solid core first, then you add the fancy stuffs, not the other way around.

As for comparison, this is a smdegrain only problem, so any other temporal denoisers is not going to have it, just as expected. The closest one that can relate to is MCTD, since it also built around smdegrain.

original
http://i.imgur.com/KpvRPwp.png (http://imgur.com/KpvRPwp)

mctd()
http://i.imgur.com/v31a6Lc.png (http://imgur.com/v31a6Lc)

And it has done the protection.

[lansing]

Dont get mixed up between SMDegrain and MDegrain, SMDegrain is a script using MDegrain as it's base :).
smdegrain is a wrapper function for mvtools+mdegrain, which is what you're using.


I've put together a test script with options for Mdegrain 3 through 6. This is adjusted by changing value of 'm'. If none is specific, the default 2 is used (MDegrain2), if you select 6 it will use MDegrain6, which is slower and should be overkill!

Additionally to that, there's an option 'recalc'. Default is false. If true, Mrecalculate will be used. This is a viable option speed wise if it has better quality :).

There's also an option for search method, applied to recalculation. Reason for this is exhaustive search may be too slow for Analysis stage, but fine for recalculation due to the recalculation only being done for bad vectors. This will only have affect if recalc=true.

Finally, there's an option for DCT. Again, this is for recalc only as this is where it would most likely be beneficial and has less of an impact on speed. If false (default) it uses the default DCT value which is 0. If true, it uses DCT value 4. Value 4 is preferable over 1 due to speed, and it maintains most of the benefits of 1.

So, play around with these test functions and let me know what you like best. The renoise function will work differently for each setting, so you may also want to use rn=0 to see just the Mdegrain process, or rn=12 (for instance) to see how it responds in relation to noise removed.

This is just a test for differences, which one performs the best for you. As an added test, I changed the rfilter value for 4, if using just mCleanT() this will be the only difference between this script and mClean.

Function is mCleanT(), T for Test.
m: 2 through 6. MDegrain function. Default is 2, which uses MDegrain2 function. Options 3-6 will use MDegrain3, MDegrain4, MDegrain5, or MDegrain6
recalc: True/false. Default is false. Recalculate vectors when set to true. Setting to true will also activate search and dct options if specified
search: True/false. Fefault is false, which uses the mClean setting of 5 (UMH search). If set to true, will enable exhaustive search (3) for the recalculation (with recalc=true)
dct: True/false. Default is false where dct 0 is used. If true dct 4 is used for recalculation (with recalc=true)

If you like feel free to adjust the searchparam values.

Those black spots when using mClean obviously shouldn't be there. Is it possible to upload a 10 second clip to Onedrive, Google drive, Mediafire etc? That way I can investigate and resolve that.

Let me know how it goes :).
Man, you'll need to start doing the testing yourself, you have my sample clip, I have told you the problem and you saw the problem. You can't rely solely on the observation of others, or you'll have another MysteryX coming by trolling you for 2 weeks going nowhere.

I don't know if the problem the nature of the filter or just some lazy logic, and I don't know whether the problem existed within mvtools as a whole or just the function "mdegrain", that's going to be your job to test. If the problem only exist in "mdegrain", then there's going to be decision to make on what to replace it with. If the problem existed within mvtools as a whole, then you'll need to look for ways to protect it (MCTD), or invent your own logic.

[burfadel]

I have done testing myself :). What I think is great may not be the most ideal solution. The m settings are for comparison and interest. If you must know, I think recalc helps, not sure about dct, or whether there are any cases where exhaustive search is beneficial. I really don't think anyone has done that kind of testing, they're using basically what was done as an example 10 years ago, or slight variations thereof. Pinterf only recently added MDegrain 4, 5, 6. If say, 4 is useful there may be a way to limit the speed impact :). I missed your actual clip link, I'll check it up when I'm home and not using my phone :).

Home now but can't look at it right away (9.30 pm here anyway). I will do a quick look up and explaining though :)

Here is an example for Mdegrain2 when it was added... 12 years ago! In the old MVTools changelog I notice the multithreading that is causing issues was added in 2008.
backward_vec2 = source.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=4, sharp=1, idx = 1)
backward_vec1 = source.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=4, sharp=1, idx = 1)
forward_vec1 = source.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=4, sharp=1, idx = 1)
forward_vec2 = source.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=4, sharp=1, idx = 1)
source.MVDegrain2(backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400,idx=1)
https://avisynth.org.ru/mvtools/mvtools.html

That will NOT work in MVTools2, it's just showing where the origins of where other scripts, including SMDegrain, came from. Note that Super was not a separate thing back then.

Here is a more 'modern' version of the above in the MVTools2 description page, the old one by Fizick:
super = MSuper(pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)
http://avisynth.org.ru/mvtools/mvtools2.html

Sharp no longer needs to be specified as sharp=1 is now default, so if you take that out you have what basically every denoiser that uses MDegrain utilises. Only difference is they may specify blksize values etc. Sure, adding an extra line for MDegrain3 is different, but hardly so :). I thought by putting together a test script like I did, it gives people the opportunity to mess around with some of the really new stuff added (MDegrain4 through 6), as well as see if there are any benefits from the other settings. Sure, SMDegrain does expose some of these, but it's just extra options that people typically don't use. The real fact is, pretty much a single variation will be ideal for practically all situations. This is good, because it means I can keep the main script as simple as possible and provide the best results for everyone, not just when the person decides to test out all the other options.

If a high MDegrain works best, there are things to do limit the impact on speed without hopefully affecting the benefits too much.

Opinions of what looks better varies from person to person, but if there is a consensus that a certain feature provides benefits, then it makes sense to use that. I guess in many ways I'm going out of my way to try and see if the 12 year old example script can be improved upon, not just assuming it's the best because every other script that uses MDegrain basically has that same script used (differences mainly block size).

The testing is as your said, making a strong base :). MCTD is great, as I said I will incorporate the beneficial stuff from other scripts and reference them when I do. Haven't needed to do that so far because I haven't done that (the MDegrain2 use doesn't count, and especially so if improved upon the base script). The main focus was a fast as the functions allows, up to date script, utilising the most ideal filters as required. Example, FFT3Dfilter for chroma.

[lansing]

I have done testing myself :). What I think is great may not be the most ideal solution. The m settings are for comparison and interest. If you must know, I think recalc helps, not sure about dct, or whether there are any cases where exhaustive search is beneficial. I really don't think anyone has done that kind of testing, they're using basically what was done as an example 10 years ago, or slight variations thereof. Pinterf only recently added MDegrain 4, 5, 6. If say, 4 is useful there may be a way to limit the speed impact :). I missed your actual clip link, I'll check it up when I'm home and not using my phone :).

Home now but can't look at it right away (9.30 pm here anyway). I will do a quick look up and explaining though :)

Here is an example for Mdegrain2 when it was added... 12 years ago! In the old MVTools changelog I notice the multithreading that is causing issues was added in 2008.

https://avisynth.org.ru/mvtools/mvtools.html

That will NOT work in MVTools2, it's just showing where the origins of where other scripts, including SMDegrain, came from. Note that Super was not a separate thing back then.

Here is a more 'modern' version of the above in the MVTools2 description page, the old one by Fizick:

http://avisynth.org.ru/mvtools/mvtools2.html

Sharp no longer needs to be specified as sharp=1 is now default, so if you take that out you have what basically every denoiser that uses MDegrain utilises. Only difference is they may specify blksize values etc. Sure, adding an extra line for MDegrain3 is different, but hardly so :). I thought by putting together a test script like I did, it gives people the opportunity to mess around with some of the really new stuff added (MDegrain4 through 6), as well as see if there are any benefits from the other settings. Sure, SMDegrain does expose some of these, but it's just extra options that people typically don't use. The real fact is, pretty much a single variation will be ideal for practically all situations. This is good, because it means I can keep the main script as simple as possible and provide the best results for everyone, not just when the person decides to test out all the other options.

If a high MDegrain works best, there are things to do limit the impact on speed without hopefully affecting the benefits too much.

Opinions of what looks better varies from person to person, but if there is a consensus that a certain feature provides benefits, then it makes sense to use that. I guess in many ways I'm going out of my way to try and see if the 12 year old example script can be improved upon, not just assuming it's the best because every other script that uses MDegrain basically has that same script used (differences mainly block size).

The testing is as your said, making a strong base :). MCTD is great, as I said I will incorporate the beneficial stuff from other scripts and reference them when I do. Haven't needed to do that so far because I haven't done that (the MDegrain2 use doesn't count, and especially so if improved upon the base script). The main focus was a fast as the functions allows, up to date script, utilising the most ideal filters as required. Example, FFT3Dfilter for chroma.

I'm kind of lost at what exactly are you trying to do here. The objective of your test should be very clear: you turn off the spatial denoising and all the post processing of your test clip and plug it to the snow clip, if your temporal denoiser doesn't wipe out any snow, bingo. If not, that means it doesn't work and try another method.

And if you actually did the test yourself, you should of know that your current test script did not work.

[StainlessS]

Question:- Why does that Smurf thing, have his naughty tackle glued to his bum ?
https://forum.doom9.org/showthread.php?p=1816915#post1816915

[Groucho2004]

Groucho, every time I see your name I'm thinking of Schtroumpf Grognon[/IMG]Every time I see your name I think of dancing Asian girls in provocative outfits. Definitely better than your smurf fantasy of me.

[burfadel]

I'm kind of lost at what exactly are you trying to do here. The objective of your test should be very clear: you turn off the spatial denoising and all the post processing of your test clip and plug it to the snow clip, if your temporal denoiser doesn't wipe out any snow, bingo. If not, that means it doesn't work and try another method.

And if you actually did the test yourself, you should of know that your current test script did not work.

I did test the test script and it works perfectly here. Not only that, I went back, copied it from the post and tried that just to be sure :). All the options work for me, so what about it isn't working for you? Keep in mind the latest plugins are required, and like the main script requires Avisynth+. Pinterf resolved a bug I reported and released an updated MVTools earlier this week. MVTools base is quite old, PinterF has done a great job of updating it.

Now, you may be wondering why I left the post processing stuff enabled. Simple, it's easy to turn off with enh=0 and rn=0 :). More precisely though, Renoise is 100 percent dependent on what is actually removed. In terms of the most effective and most accurate (without motion issues or removing wanted detail) removal method, m=6, recalc=true, search=true, dct=true should be highest quality. That said, it is too slow and overkill anyway. The idea way would be to find the maximum settings that show a visible difference, then find a second or third 'ideal' setting, and work it from there.

An important aspect of this is that it is subjective to the individual. You will however discover with a larger dataset that there will be things that people agree on, so that's the purpose of the test. As I said earlier, it doesn't seem any real quality analysis like this has been done. You might have a clip where something stands out that is obviously better for that situation, but doesn't make a perceptible difference in the particular clips that others use. This would just mean the most ideal settings aren't found if it's only me passing each individual options and combinations thereof over different clips.

If you want to trim down the test options, m 4 through 6 are just out of interest. They are new to MVTools by PinterF, you probably haven't come across them. It's out of interest because each m higher is slower. That said, if m 4 is beneficial over 3 there are possibly ways to overcome that performance issue.

So values of m to try are 2, 3, and also 4 out of interest to see if it improves. The most ideal one out of those, proceed on to recalc=true, followed by keeping recalc and adding search=true, replacing search=true with dct=true, then using search=true and dct=true. Lets just say if you found m3, recalc=true, dct=true to be the one you like, then you can drop it to m2 and see if the quality holds. If not, then it's good.

I simply don't have every clip out there. Different clips have different noise characteristics, all of these can impact noise (grain, impulse etc) removal effectiveness of any filter. Also, I already have a general idea of which settings of these to choose. I will not say them though, as I want people to form their own opinion and corroborate my findings. By doing so it gives people the option to share their ideas and findings to find the most beneficial outcome. The added advantage with the online community is that others can also benefit for other scripts, if so desired, if there is indeed a good set of options.

[burfadel]

Every time I see your name I think of dancing Asian girls in provocative outfits. Definitely better than your smurf fantasy of me.

"What are you up to Groucho?"
"Just smurfing the internet"

[MysteryX]

"What are you up to Groucho?"
"Just smurfing the internet"
LOL!
https://www.youtube.com/watch?v=mcAW9YJ1-S8


MvTools2 is an old relic that everybody uses, yet nobody understands fully the use, nobody understand how it works and nobody wants to touch the code -- except Pinterf who works on the code without understanding how it even works. The conversation here supports that further.

The way MvTools2 works, small variations of settings can cause huge differences to the output. SMDegrain is one set of settings. MvTools2 has many functions and many settings. It's kind of an ignorant comment to say that everything that can be done with MvTools2 is one and the same, when each small variation can cascade into considerable changes.

The tests I've done with FrameRateConverter and RemoveGrain(18) vs RemoveGrain(21) support that: that tiny variation resulted into very notable changes.

MvTools2 is a complex library with tons of settings.

[lansing]

I did test the test script and it works perfectly here. Not only that, I went back, copied it from the post and tried that just to be sure :). All the options work for me, so what about it isn't working for you? Keep in mind the latest plugins are required, and like the main script requires Avisynth+. Pinterf resolved a bug I reported and released an updated MVTools earlier this week. MVTools base is quite old, PinterF has done a great job of updating it.

I simply don't have every clip out there. Different clips have different noise characteristics, all of these can impact noise (grain, impulse etc) removal effectiveness of any filter. Also, I already have a general idea of which settings of these to choose. I will not say them though, as I want people to form their own opinion and corroborate my findings. By doing so it gives people the option to share their ideas and findings to find the most beneficial outcome. The added advantage with the online community is that others can also benefit for other scripts, if so desired, if there is indeed a good set of options.

By "not working" I mean it's not fixing the issue. Turn on all the highest setting you want and you'll be getting the same thing. A temporal denoiser should not be touching anything that's not temporal.

[burfadel]

That's right :). Exposing all those options makes things too complex though for the end user. The good thing is that in terms of the analysis I suspect there is an ideal set of settings for benefit and performance that are generalistic. It's finding those settings over a wide variety of clips that is the difficult part.

[burfadel]

By "not working" I mean it's not fixing the issue. Turn on all the highest setting you want and you'll be getting the same thing. A temporal denoiser should not be touching anything that's not temporal.

That's true, but if it's the case it's a bug in MVTools. Without a motion clip of it I can't see myself. That said though, with a clip that has the issue and notified exactly where it is, I should be able to overcome it and importantly, maybe identify why it is happening. There's still a lot to add, I just want to 'perfect' the base.

[MysteryX]

So lansing, you want to help or you're just here to complain? make up your mind


BurFaDel, if you haven't figured it out yet, I wasn't sure whether he had posted the source or processed video. This is the source
Here's a short scene emphasizing the problem I'm talking about.
snow (http://www.mediafire.com/file/p9jgodk3mwf9loo/snow.avi)

[burfadel]

Thanks, I missed that :). MDegrain does motion compensation to find noise, that said stationary objects shouldn't be affected since there is nothing to compensate. I have some ideas of MDegrain function part improvements, whether it works it not as intended... The above test is still invaluable, the changes will be inclusive of those.

[burfadel]

The artifact masks from framerateconverter could overcome any remaining artifact issues, but reducing the problem is much better than trying to fix it later :).

[burfadel]

Updated first post with version 1.4.
Changed to MDegrain4 as the results were nicer and the output is more efficient, the settings used should reduce the impact on speed. I also modified the sharpen function, it should produce nicer results but at the same time is also stronger. I would have done more on the script but had other things come up that needed attending to over the weekend :).

EDIT: Updated first post to version 1.5
Changed sharpen setting enh, and adjusted range from 0-24 (0-20 normal range and 21-24 overboost sharpening). Updated renoise and will now only be applied to areas with luma greater than 32(/255). Added DCTFilter, improves compressibility fractionally, main reason for its addition is for additionally cleaning of the picture in a particular way. Adding padding to mod4 (re-updated version 1.5 post to reflect this).

Please use the latest chikuzen's updated DCTFilter, which has a x64 version, from here - https://github.com/chikuzen/DCTFilter/releases

[lansing]

Good to see you also noticed that the renoise function was adding blown white noises around moving object in darker areas. Any update on your smdegrain issue fix/workaround?

[MysteryX]

Dark scenes were getting noise and getting gray-er, now it's good. If it's due to the 2.2 gamma curve, the same problem may happen with whites. Perhaps you could apply a curve that softens both edges of the gamma curve instead of applying a flat threshold?

The new version's enh doesn't work for me. This version's sharpening with enh=0 is about the same as 1.3c with enh=13, and with enh=0 it actually looks pretty good. You can see some details are better defined than in v1.3c. With enh=1, however, it goes south. enh=5 is just worse.

Note: this is my full script that denoises, upscales and interpolates.

v1.3c / v1.4 enh=0 / v1.4 enh=1 (all rn=10)
https://s26.postimg.org/pxd7el891/5017_m_Clean3.png (http://postimg.org/image/pxd7el891/) https://s26.postimg.org/chq6p4zr9/5017_m_Clean4.png (http://postimg.org/image/chq6p4zr9/) https://s26.postimg.org/4di2kedc5/5017_m_Clean4enh.png (http://postimg.org/image/4di2kedc5/)

[burfadel]

Remember it's MDegrain, SMDegrain is another script that uses it. It would be like calling Deblock_QED as plain Deblock, as although Deblock_QED is a wrapper function the script itself is quite different than calling Deblock directly. Basically every script does this, rely on other filters, so if another script happens to use a similar base function or function set, the base function set should be referenced, not the wrapper :)

I do know why MDegrain does that, technically it's actually doing what it's meant to do! I did think of a possible solution, I'll see if it works (or probably not!) sometime in the next couple of days.

[burfadel]

Dark scenes were getting noise and getting gray-er, now it's good. If it's due to the 2.2 gamma curve, the same problem may happen with whites. Perhaps you could apply a curve that softens both edges of the gamma curve instead of applying a flat threshold?

The new version's enh doesn't work for me. This version's sharpening with enh=0 is about the same as 1.3c with enh=13, and with enh=0 it actually looks pretty good. You can see some details are better defined than in v1.3c. With enh=1, however, it goes south. enh=5 is just worse.

Note: this is my full script that denoises, upscales and interpolates.


I've readjusted the defaults, now 0-54 so should give you more scale. A 0-100 scale was too high. The enh settings is fine if you are doing only a small amount of image enlargement afterwards, and definitely fine for reducing image size. If you are upsizing to a much larger resolution a slightly different approach is needed but should be relatively easy to implement. I'll have to look at that either later today or tomorrow. The added benefit of this would be that you can run (for now before implementation) other forms of artifact reduction and do an enhance after everything is done. Artifacts like ringing can be difficult to remove since it is technically detail, and the typical method of removing it is smoothing. This works great but it can also smooth wanted details or ring-esque like details. Haloing is 'easier' to reduce or remove, but again faces the same problem with detail removal. I do have some thoughts on how to do this. If I did add it, it probably won't be on or it will have a weak default setting.

In terms of scaling the application of renoise base on luma contrainsts, not sure on how to do that! Or at least, such that it can be done simply. I can though simply limit its application to a range of for instance, 32-220 if adding to high luminance areas is problematic. I might add it anyway, there's probably little point on adding it to high luminance areas.

[MysteryX]

Perhaps you can alter the renoise algorithm to work in linear-light instead of on a gamma curve?

[MysteryX]

Here's a comparison with a HD video. This clip mostly has noise in the dark leather and a little bit in the hair.

Original / mClean 1.3c / mClean 1.5c enh=0 / mClean 1.5c enh=5
https://s26.postimg.org/ncha1xekl/2204_original.png (http://postimg.org/image/ncha1xekl/) https://s26.postimg.org/z0bbwh3ph/2204_mclean3.png (http://postimg.org/image/z0bbwh3ph/) https://s26.postimg.org/8x8juigat/2204_mclean5.png (http://postimg.org/image/8x8juigat/) https://s26.postimg.org/n4y8j5szp/2204_mclean5enh.png (http://postimg.org/image/n4y8j5szp/)

Here, the leather doesn't benefit as much from renoise and looks more flat. Which is why I think working in Linear Light would be a better idea. You can't do MDegrain in Linear Light because it requires HBD to not loose a lot of data, and MDegrain in HBD is a lot slower. However, you can probably convert into Linear Light right after to do the rest of the processing.

Is this script with MDegrain4 sharper than the previous? With enh=0 it looks almost just as sharp. With enh=5, however, it's way too sharp. It might look fine now, and after encoding it will still be decent, but if you re-encode a second time it will get ugly.

The enh settings is fine if you are doing only a small amount of image enlargement afterwards, and definitely fine for reducing image size.
If it's too sharp for upscaling, then it's definitely out-of-balance, and will get ugly after encoding it twice.

[MysteryX]

I'm looking at your script. Instead of excluding U and V planes of a Y12 clip on all commands, why don't you just work with a Y8 clip? This would simplify the syntax quite a bit.

To convert to linear light, something like mt_lut(x, "x 2.2 ^") should do it. Not sure where it would have to go though, or whether it would work with your logic. I'm a bit confused as to what mt_binarize is doing in your script.

[burfadel]

I plan to change it to Y8, I just want to make sure everything is working like it should, then use Y8. The results should be identical, if not then the error can be directed at the proper filter. The mt_binarize is in there so renoise isn't applied back to areas with less than 32 luma. If there is a better way of doing it... The leather is black so it isn't being applied there. As for enh, it really depends on the basal quality of the clip. If any sharpen filter looks bad on the clip enh won't work, since it is a detail orientated unsharp mask. It's why it can be disabled with 0, it can only enhance what is there! There is something I can do to for it that can improve it though, it may make it usable at a lowered setting in those cases. It's something I always intended to do but wanted to get the base done right first :). There is also something else I can try for situations such as in those screenshots.

EDIT: Not sure if there is any benefit converting to Y8, apart from making the script look a bit neater. If in Y8 and none of the 'do not process chroma' flags are specified, do the filters work just on the Y plane, or do they 'process' blank chroma channels? I guess the only other reason would be if it were faster, but then again you have to consider the conversion to and from Y8 format to the original YV12/YV16/YV24 format.

[burfadel]

Updated first post with soothe function.

[StainlessS]

Not sure if there is any benefit converting to Y8, apart from making the script look a bit neater. If in Y8 and none of the 'do not process chroma' flags are specified, do the filters work just on the Y plane, or do they 'process' blank chroma channels? I guess the only other reason would be if it were faster, but then again you have to consider the conversion to and from Y8 format to the original YV12/YV16/YV24 format.

I think that for ConvertToY8,
Avs standard uses subframe, ie sort of forgets that it has chroma. Results of further filter ops comes only from the luma plane, chroma no longer considered part of frame by following filters [EDIT: which produce Y8 luma only].
Avs+, copies luma plane into new frame buffer (I think this may happen only if not already aligned to some optimal memory boundary, for eg SSE2/SIMD or whatever, if already aligned, then may do same as avs, not sure).
Both above methods have their advantages, and both sets of devs prefer their method.

For Convert back to YV12 (using eg MergeChroma), new frame will be created and planes copied/blitted into it.
Copying will be quite fast and not really worth considering as a bottle neck.

For non Y8 Planar, some ops in your script may not have a 'do not process chroma' type flag, and so those would process chroma even if nothing useful
exists there, conversely, some ops may not support Y8. Choose your poison.

[burfadel]

I guess ultimately it will come down to which method is faster. If they perform the same, then I'll probably still use Y8 for script neatness. It will be interesting to see the results of this!

[MysteryX]

It will be faster and use less memory to use Y8. Otherwise you're allocating and moving useless space around.

The only "downside" is a memcpy (or however they implement it) of a single plane for conversion, which is totally irrelevant performance-wise.

[StainlessS]

It will be faster and use less memory to use Y8. Otherwise you're allocating and moving useless space around.


I dont see nottin wrong there, I could be mistaken. (EDIT: bit pissed).

[MysteryX]

Frame data need to allocated and passed for every filter. Y12 clip requires twice as much memory as Y8 clips. Since allocation is no more of a performance issue than memcpy, it probably won't have any performance effect other than taking twice as much memory (3x with Y24), unless some filter in the chain doesn't exclude the chroma planes.

There's just no downside to using Y8 (unless you want to support AVS 2.5.8)

If you're wondering how it works behind the scene, Y12 stores its data in 3 separate memory areas (planes). The simplest filter would take each plane a memcpy into the destination frames. ConvertToY8 simply memcpy the first plane. Not really any conversion there; it just drops unnecessary planes.

[burfadel]

That makes sense, I'll change it just to Y8 on the weekend as well as the next feature:). Memory efficiency is also important.