Dogway's Filters Packs

[DTL]

"Maybe Dogway will add that one day to SMDegrain"

refinemotion may be changed from single true/false bool to 0 if no refine or number of refine steps. Typical everyday scripts may be designed to have acceptable speed/quality. Not best possible results with low speed.

Also for possibly a bit better quality you may check pel=4. It looks like typical precision of MPEG encoders search now. If found and applied correctly it should save from blurring a bit better. Though it is much slower and need about 4x more RAM in compare with pel=2. So with too much of threads and large frame size it is easy to run out of memory.

[LeXXuz]

Just running a test. Performance is lower but still okay with blksize=8, pel=4, subpel=3. Around 14FPS now which was ~19FPS before. Machine has 128GB. So memory should not become a bottleneck.

[DTL]

About 'blocksize' in processing: Smallest possible for refining with 'full-samples' size and 4:2:0 is 2x2 luma and 1 chroma samples pair. Though if going down to subsample processing it may be smaller. So it is in theory possible to make refining down to 'per-sample' processing - not per-block. It possibly may reduce some limitations of method based on very limited number of possible to process transforms in current MVtools.

Do not know why current limitation of SMDegrain is: SMDegrain: For RefineMotion you need a blksize of at least 8. If set 4x4 and refine to 2x2 it should be still supported by MVtools ? May be because overlap of 1 is not valid for 2x2 4:2:0 blocks ? So it is needed to convert to 4:4:4 to use refining to lower blocksizes.

Current limitation of min blocksize processing may be easily workarounded by upsizing clip before process and downsizing back after process. But it will be slower and require more RAM.
The script for test about:
N=2 (or 3,4,5...)
MyLovelyResize(width*N, height*N)
SMDegrain(...)
MyLovelyResize(width/N, height/N)

(may be a bit better to use Upsample/Desample functions pairs from jpsdr ResampleMT)

With N=2 and blocksize in degrain 8 and refinemotion=true it will be equal to processing blocksize 4x4 and refining to 2x2 (and doubling of pel precision). Unfortunately it may degrade quality with 'large starting blocksize' so it is better to add more refining steps in degrain script.

Also for better resistance to noise-errors with small blocksizes it may be better to use multi-stage processing starting from large blocksize and lower thSAD values to keep from error-blurring at stages with large blocksize. Also for processing with small blocksize to get less noise-based positions errors it may be good to test with new MVLPF processing versions.

Like
my_thSAD=...(typical thSAD/1.2)
next_step=1.2
SMDegrain(blocksize=16, thSAD=my_thSAD, refinemotion=true)
SMDegrain(blocksize=8, thSAD=my_thSAD*next_step, refinemotion=true)

[LeXXuz]

Originally Posted by DTL

Like
my_thSAD=...(typical thSAD/1.2)
next_step=1.2
SMDegrain(blocksize=16, thSAD=my_thSAD, refinemotion=true)
SMDegrain(blocksize=8, thSAD=my_thSAD*next_step, refinemotion=true)

Thanks DTL. I'll give that a try, too.
The last time I actively used 2-stage denoising I wasn't really happy with the results. Because smearing and ghosting in fine textures was kinda awful. However, that was with a rather old version way before Dogway implemented all those updates and without modifying the blocksize because I simply didn't know better at that time.

[LeXXuz]

I have a DVD film here with some poor black levels and lots of noise in those black areas.



I've used this so far:

ConvertBits(16)
PRE1=(sneo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:3 0.5:12 0.9:24 1.0:48", chrslocation="0.0:1.5 0.5:6 0.9:12 1.0:24"))
PRE2=(sneo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:2 0.5:8 0.9:16 1.0:32", chrslocation="0.0:1 0.5:4 0.9:8 1.0:16"))
SMDegrain(tr=6, thSAD=400, blksize=8, contrasharp=false, limitS=true, LFR=150, DCTFlicker=true, refinemotion=true, truemotion=true, Str=5.0, pel=4, subpixel=3, prefilter=PRE2, chroma=true, plane=4)
SMDegrain(tr=3, thSAD=600, blksize=8, contrasharp=50, limitS=true, LFR=false, DCTFlicker=false, refinemotion=true, truemotion=true, Str=5.0, pel=4, subpixel=3, prefilter=PRE1, chroma=true, plane=4)
neo_f3kdb(range=15, Y=64, Cb=32, Cr=32, grainY=32, grainC=16, sample_mode=4)
Prefetch(16,16)
Return(Last)

Daylight sceenes and even indoors look fine. But dark areas still have either noise or somethin that looks like a static noise curtain now.

Would appreciate any advice where/how to tweak.

[DTL]

It may be better to provide sample video for download.

[LeXXuz]

Originally Posted by DTL

It may be better to provide sample video for download.

You are probably right. Here is a sample file:
https://send.cm/d/BLrs

[DTL]

I check it. It looks the script somewhere create great 'shadow detail gain up' and it greatly increase residual dark noise.

I run simple mvtools-based script using my latest build from https://forum.doom9.org/showthread.p...88#post1968988

LoadPlugin("mvtools2.dll")
LoadPlugin("ffms2.dll")

FFMpegSource2("testsample-001.mkv")

tr = 12 # Temporal radius
super = MSuper (mt=false, chroma=true,pel=2, hpad=8, vpad=8, levels=0)
multi_vec = MAnalyse (super, multi=true, blksize=8, delta=tr, chroma=true, overlap=4, mt=false, optSearchOption=1, levels=0, scaleCSAD=0)
MDegrainN(super, multi_vec, tr, thSAD=300, thSAD2=290, mt=false, wpow=4, thSCD1=350, adjSADzeromv=0.5, adjSADcohmv=0.5, thCohMV=16, MVLPFGauss=0.9, thMVLPFCorr=50)

And it make much less noise at the dark areas of this frame - https://i1.imageban.ru/out/2022/05/2...d49b49deb3.png . I do not tweak parameters - it is some defaults from some testing of different versions with not very noisy content.

[LeXXuz]

Originally Posted by DTL

I check it. It looks the script somewhere create great 'shadow detail gain up' and it greatly increase residual dark noise.

Dogway where are you?

Originally Posted by DTL

And it make much less noise at the dark areas of this frame - https://i1.imageban.ru/out/2022/05/2...d49b49deb3.png . I do not tweak parameters - it is some defaults from some testing of different versions with not very noisy content.

Thank you DTL. That looks much better indeed.
I'll give that a try on the entire film and see how it plays out.

[DTL]

May be it is something about attempt to keep more details in shadows ? Also can it be levels 0<->16 different conversions to RGB ? I make preview of script in VirtualDub and framegrab via Ctrl+1 command.

May be you can start from disabling most of additional processing like neo_f3kdb(range=15, Y=64, Cb=32, Cr=32, grainY=32, grainC=16, sample_mode=4) to see what cause dark noise increasing.

[LeXXuz]

Originally Posted by LeXXuz

I have a DVD film here with some poor black levels and lots of noise in those black areas.

Just to clarify: this is NOT the encoded output. It's a frame from the untouched source.

[DTL]

So you can show the processed source with a script of a dark scene to show the result.

[LeXXuz]

Sorry for any misunderstanding. I wanted to show the source pic to show you guys what I'm up against. And maybe to give some hints on how to tackle such noise the best way.

The output with SMdegrain() has much less noise but still visible in these scenes. Likewise I'm unsure about the black level as dark scenes clearly look too bright in the source. However, if I play around with PC/TV conversions the ouput got too dark. And it looks too bright when playing the DVD on my TV, too.

I'll show some comparisons with SMDegrain() when I'm back home later this weekend.

Hi,

Can you please have a look at this...

https://forum.doom9.org/showthread.p...86#post1969586

DTL has been posting builds of Mvtools2, and I get an SMDegrain Line 645 error when checking with AVSMeter.

[LeXXuz]

Originally Posted by DTL

So you can show the processed source with a script of a dark scene to show the result.

Okay I've encoded the film with the script provided by DTL and my script with SMDegrain. In addition I added sharpening by calling LSFPlus after denoising and finally debanding with f3kdb.

Scripts as follows:

tr = 12 # Temporal radius
super = MSuper (mt=false, chroma=true,pel=2, hpad=8, vpad=8, levels=0)
multi_vec = MAnalyse (super, multi=true, blksize=8, delta=tr, chroma=true, overlap=4, mt=false, optSearchOption=1, levels=0, scaleCSAD=0)
MDegrainN(super, multi_vec, tr, thSAD=300, thSAD2=290, mt=false, wpow=4, thSCD1=350, adjSADzeromv=0.5, adjSADcohmv=0.5, thCohMV=16, MVLPFGauss=0.9, thMVLPFCorr=50)
ConvertBits(16)
LSFPlus(preset="slow", strength=100)
neo_f3kdb(range=15, Y=64, Cb=32, Cr=32, grainY=32, grainC=16, sample_mode=4)
Prefetch(16,16)
Return(Last)

I could not run DTL's script with 16 bit. I always got an Access Violation error, so I had to convert to 16 bit afterwards.

This is the script I used with SMDegrain:

ConvertBits(16)
PRE=(sneo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:2 0.5:8 0.9:16 1.0:32", chrslocation="0.0:1 0.5:4 0.9:8 1.0:16"))
SMDegrain(tr=12, thSAD=400, blksize=8, contrasharp=false, refinemotion=true, truemotion=true, Str=5.0, pel=2, subpixel=2, prefilter=PRE, chroma=true, plane=4)
LSFPlus(preset="slow", strength=100)
neo_f3kdb(range=15, Y=64, Cb=32, Cr=32, grainY=32, grainC=16, sample_mode=4)
Prefetch(20,20)
Return(Last)

First of, DTL's script filters the content fairly stronger, resulting in an about 20% smaller output file.

(Also the encoding speed was twice as fast, 23FPS <> 11FPS. BUT that comparison is not fair, as it filters only in 8 bit and is leaving less noise in the output for x265 to handle. So I just put this as a side note in parentheses.)

However, both versions produce a blurring effect I really dislike and keeps me questioning if I should use noise reduction after all to convert my collection.
(I also did encodes without LSFPlus and f3kdb which hat little to no effect to the problem.)

To elaborate:
I've uploaded three files onto send.cm. Please download them to watch as that site doesn't support Matroska containers for direct playback.
File1
File2
File3

File 1 is the original MPEG2 source. File 2 is a conversion with DTL's script to HEVC. File 3 the conversion with SMDegrain.
(Note: I slightly changed the black levels in the conversions, so pay no mind on that pls.)

If you compare both conversions with the original, take a very close look at the texture of John Nettles' (the actor on the left) suit. As he moves away the texture will be washed out making the suit look like an uni-coloured blanket. So to speak.

On a frame-by-frame close-up I saw that some frames are even washed out in the orginal frames, however overall the suit has much more detail in the original than in both conversions.

Right now I'm so focused on this effect that I may be exaggerating. So I'd like some honest opinions on this.

No matter what I tweaked, I could NOT get a solution that got rid of this blurring while still doing a decent denoising job overall. Maybe this is just wishful thinking anyway without scene based denoising?

Someone once told me: you can't denoise a video without sacrificing at least some detail. And as much as noise filters have improved, I'm still entitled to say he's probably right.

[Dogway]

The blurring, which I call smearing is a known side-effect, it smears low frequency details.

For that I made the LFR arg to recover some, it brings back some dirt blobs so it's better used with DCT=true (I might improve this area).

ConvertBits(16)
SMDegrain(tr=12, thSAD=400, blksize=8, contrasharp=100, refinemotion=true, LFR=150, DCTflicker=true, Str=3.0, pel=2, subpixel=2, prefilter=6, chroma=true, plane=4)
ConvertBits(8,dither=1)

This is low frequency detail that is recovered, low contrast high frequency detail is going to be lost since it will read as noise because getting that fine motion vectors is unpractical. For that reason I usually add grain afterwards for some "hallucination". But I think you are going for the high compressibility/clean look.

If you just want to denoise low luma areas pass the denoiser through a lumamask()


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

By the way, on another note. I'm making a BATCH file to process images in an easy way, so one can leverage the powerful AVS tools with cjxl, the state-of-the-art JPEG XL image compression encoder.
As I observed all the programs I found either don't support JXL or they support it but scarce on filtering options. As an example, ImageMagick doesn't support jxl --quality argument, besides its bicubic scaler coefficients don't match avisynth's (avisynth adds a preblurring of some sorts) so it's hard to relate.
Will upload soon with some TransformsPack updates.

[DTL]

"I could not run DTL's script with 16 bit. I always got an Access Violation error, so I had to convert to 16 bit afterwards."

It looks some bug with 16bit input to MAnalyse now. Current workaround is to feed MAnalyse with 8bit input:

ConvertBits(16)
tr = 12 # Temporal radius
super = MSuper (mt=false, chroma=true,pel=2)
super8 = ConvertBits(8).MSuper (mt=false, chroma=true,pel=2)
multi_vec = MAnalyse (super8, multi=true, blksize=8, delta=tr, chroma=true, overlap=4, mt=false, optSearchOption=1)
MDegrainN(super, multi_vec, tr, thSAD=300, thSAD2=290, mt=false, wpow=4, thSCD1=350, adjSADzeromv=0.5, adjSADcohmv=0.5, thCohMV=16, MVLPFGauss=0.9, thMVLPFCorr=50)

" take a very close look at the texture of John Nettles' (the actor on the left) suit. As he moves away the texture will be washed out making the suit look like an uni-coloured blanket. "

To possibly keep more low contrast details you can try more extreme settings like

tr = 15 
super = MSuper (mt=false, chroma=true,pel=2)
super8 = ConvertBits(8).MSuper (mt=false, chroma=true,pel=2)
multi_vec = MAnalyse (super8, multi=true, blksize=8, delta=tr, search=3, searchparam=4, truemotion=true, chroma=true, overlap=4, mt=false, optSearchOption=1)
MDegrainN(super, multi_vec, tr, thSAD=100, thSAD2=100, mt=false, wpow=4, thSCD1=350, adjSADzeromv=0.3, adjSADcohmv=0.3, thCohMV=4, MVLPFGauss=0.9, thMVLPFCorr=20)

It will reduce global degrain level visibly. Though Dogway's script work also good. To keep more details - also try to use as low thSAD values as possible.

[Blankmedia]

I'm only here to talk about our lord and savior :

Flatmask

ex_retinex as no argument tv_in error on line 161.

Thanks again for your splendid work.

[Dogway]

Originally Posted by Blankmedia

I'm only here to talk about our lord and savior :

Flatmask

ex_retinex as no argument tv_in error on line 161.

Thanks again for your splendid work.

Did you update? tv_in was added in last commit.

Anyway just updated SMDegrain now with the most recent changes.

[Blankmedia]

Originally Posted by Dogway

Did you update? tv_in was added in last commit.

Anyway just updated SMDegrain now with the most recent changes.

-_-

Only thing I didn't update and I didn't check in what script ex_retinex was before posting.

thank you