Dogway's Filters Packs

[Dogway]

I ported new nvidia's sharpener, read its blog, here the repo. It's open source to compete against AMD's FSR. Someone else can port their scaler as that isn't possible with avisynth syntax.

I didn't like it much though, it's a bit naive, simple minmax edge mask that is later discretized, minmax limiting and a simple unsharp mask fixed at 3x3 window.
Bitrate increase is understandable, you are increasing acutance which raises SAD, but when I encode I only care about output quality. I guess if you want to maximize quality for bitrate using LSFmod's options is best suited because you can tell it to localize sharpening only where it cares most.

I didn't read much of the new MVTools developments by DTL, I read about some concessions on using only 8x8 blocks, that's not optimal for HD, furthermore I would really like to see adaptive block sizes like H.265, a clear sky wouldn't need less than 32 block sizes whereas a city landscape would do better with 8. I will wait for stable.

I will have a look now to the pending issues.

[tormento]

Originally Posted by Dogway

I ported new nvidia's sharpener

I wrote _un_sharpeners

Can't find any suitable to some excessively sharpened movies.

[Dogway]

ah, that's easy, use blur with clamping. ex_luts("clamp") as alternative to dehaloers or custom convolutions.

Originally Posted by Boulder

You can use this script to see how it looks, if you change the value of limit between 0.29 and 0.3, the difference is quite big compared to 0.3 and 0.31. It doesn't seem to matter if the source is 8 or 16 bits.

I'm testing in frame 46 with:

limit = 0.30
convertbits(16)
a=SPresso(bias=20, biasc=40, rgmodec=4, limit=limit, limitc=limit*2)
ex_makediff(a, aug=100, UV=128)

And there's a barely noticeable change between 0.29 and 0.30, compared to 0.30 to 0.31. But I mean this is augmented x100.
When using your call, yes some blocks seem to change more with 0.29 to 0.30 but this also happens with with older SPresso scripts, this is the nature of hard thresholding/limiting. I implemented soft thresholding on a few of my filters (not all). Anyway, I'm going to use old=true to my ex_MinBlur() call so it's an exact match to older SPresso. I will edit the script again when pinterf adds the sign operator.

[Boulder]

Originally Posted by Dogway

I'm testing in frame 46 with:

limit = 0.30
convertbits(16)
a=SPresso(bias=20, biasc=40, rgmodec=4, limit=limit, limitc=limit*2)
ex_makediff(a, aug=100, UV=128)

And there's a barely noticeable change between 0.29 and 0.30, compared to 0.30 to 0.31. But I mean this is augmented x100.
When using your call, yes some blocks seem to change more with 0.29 to 0.30 but this also happens with with older SPresso scripts, this is the nature of hard thresholding/limiting. I implemented soft thresholding on a few of my filters (not all). Anyway, I'm going to use old=true to my ex_MinBlur() call so it's an exact match to older SPresso. I will edit the script again when pinterf adds the sign operator.

Thank you for the explanation. In fact, it's fine to keep it as it is now that I know how it is. I often use quite small values for limit in my denoiser to just push the hardest grain edges back a bit.

[tormento]

Originally Posted by Dogway

use blur with clamping. ex_luts("clamp")

Is that the exact command to use? ex_luts("clamp")?

[Boulder]

I found a rather peculiar problem with SoftLimiter and apparently multithreading.

This script causes strange seeking which quite often crashes RequestLinear with "RequestLinear: internal error (frame not cached)!". I'm currently on test 27 of Avisynth+'s latest builds.
DGSource("source.dgi")
RequestLinear(clim=100, debug=true)
SoftLimiter(dyn=2)
Prefetch(threads=24, frames=12) # good for 12-core 3900X

https://pastebin.com/TgjREc0f, see for example line 588.

[videoh]

Since DGSource() supports random access, why is RequestLinear() needed? What is it doing?

[Boulder]

This strange glitch, https://github.com/pinterf/mvtools/issues/37, does not occur if I use RequestLinear there.

[videoh]

DGIndex and DGIndexNV both use the same random access logic, so if you can find a way to produce this error with DGIndex then perhaps pinterf will be able to look at it. We should chip in to get him an nVidia GPU, if anyone can find one.

[Dogway]

Originally Posted by tormento

Is that the exact command to use? ex_luts("clamp")?

It's the same that I posted a while ago, antialiasing, dehaloers, masked blurs are all good for that.

[tormento]

Originally Posted by Dogway

It's the same that I posted a while ago.

Unfortunately none of them gave good results on movies such as Transformers, Pacific rim, etc... where the CGI sharpness was exasperated to increase "realism".

When you have time, please, get a look on my message about Brazil, before file shares expire.

[DTL]

Originally Posted by Dogway

I read about some concessions on using only 8x8 blocks, that's not optimal for HD, furthermore I would really like to see adaptive block sizes like H.265, a clear sky wouldn't need less than 32 block sizes whereas a city landscape would do better with 8. I will wait for stable.

The 8x8 blocks with AVX2 register file simply fastest for processing (full exa search with radius up to 3..3.5 (that is -4+3 for example). Because it can use H-stepping during search inside register file. Though as I see from practice - the search radiuses > 2 is still mostly experimental feature because default=2 and at finest level it even decreases to 1 for better speed. So it generally required to have only sp1 and sp2 search functions. sp3 and sp4 looks like rarely used by anyone. Though I have an idea that level 0 sp4 search will be faster in compare with 2levels 0,1 search with sp2 at level 1 and sp1 at level 0 - but it still an idea. The tests still not confirm it (though it were very few tests and with 8x8 only blocksize).

Though with latest speed test i try 4x 8x8 block search (in 4x1 arrangement that is faster to load from memory) with both H and V steps reload from memory (cache) and it still a bit faster (about 1.5x). Also the 4x 8x8 blocks may be arranged in 'macroblock' in different ways - like 4x1 in H direction or 2x2 in H and V and it makes 16x16 block. But this multi-8x8 block processing still have 8x8-precision refining because each 8x8 block is refined. In classic 16x16 block search there is no refining down to 8x8 granularity.

But because 16x16 block really fits in 1/2 of AVX2 register file so I will add 16x16 block search in 'standard' mode (with 16x16 granularity). It will not be as fast as 8x8 (inside search algoriphm) but should be still faster in compare with old 16x16 each pos SSE search (Expanding search). Because of 4times less vector data processing overhead in compare with 8x8 block size. Though it is still only for AVX2 capable chips. Sadly the war between intel and amd cause the amd to go to massive-multicore chips without avx512. So it looks the CPU chips manufacturers lost war with HW accelerators of large vectors processing and the future expansion of large vectors co-processors at standard CPU cores may be stopped. May be AVX2 is the last most commonly used large vector co-procession capability at general client CPU chips in current dying civilization. All other large vectors processing must be offloaded to separate HW accelerators (like GPU or other).
There some ideas of 'distributed' MAnalyse processing with sending 'workunits' to 'workers' that can be IP interconnected to any host in the net and also localhost can have any based 'worker' (also GPU-accelerated) to receive working task from main processing MAnalyse and return small data about vector data refined (12 bytes chunk per each block). But all workers must have access to the processing files (source). So users/programmers can make separated by IP layer 'vector task search/refine workers' with any processing capabilities (CPU/GPU/ASIC etc) and it will be easier to debug and scale. The size of 'workunit' may be as small as one block or as large as the tr-step (total tr-stepped frame for MDegrainN, though currently MDegrainN asks for separated each tr frame with GetFrame - not for all 2*tr MAnalyse data at once).

The AVX512 can fit 32x32 block for faster search but it looks the nowdays and close future of AVX512 in clients chips become not as nice as expected. Though some pro with highperformance workstations (some HP workstations have Xeons Gold with AVX512) and servers can use it.

I also move to the idea of dymanic block size processing because 8x8 still have lots of vector processing overhead. And if vectors of the local region are coherent enough - we can use multi-8x8 block processing at SAD search/refining with increasing of speed.

But typically clear sky and clear low-detailed (and low contrast ?) areas do not create enough coherent vectors fields. And as the most critical for speed level 0 search uses internally r=1 so we need really totally coherent prediction vectors x1=x2=x3=x3 and y1=y2=y3=y4) to use multi-block processing (or even arrange area to 4x macroblock) because any possible refining at finest level can be only to +-1 in x,y coordinates. May be maximum non-coherency may be +-1 because if predicted block coords are best - the search phase will simply confirm prediction and re-generate SAD value (as currently done with optPredictorType=3).

Or algoriphm of switching to 'macroblocks' need addition like not only check vectors coherency but also may be its spectum or total contrast, or something else.

[Boulder]

Originally Posted by videoh

DGIndex and DGIndexNV both use the same random access logic, so if you can find a way to produce this error with DGIndex then perhaps pinterf will be able to look at it. We should chip in to get him an nVidia GPU, if anyone can find one.

Hmm, I could try and see if it occurs on MPEG2 sources. Somehow I've always thought this as a possible issue with NVidia drivers.

Then again, the strange seeking in SoftLimiter is also something worth investigating.

[Dogway]

Originally Posted by tormento

Unfortunately none of them gave good results on movies such as Transformers, Pacific rim, etc... where the CGI sharpness was exasperated to increase "realism".

When you have time, please, get a look on my message about Brazil, before file shares expire.

I relaxed a bit for the last 2 or 3 days after the intense last week, but I haven't forgotten about your questions, thanks to it I improved ex_BM3D() which happens to have frame access issues with ffvideosource().
I already downloaded the clips and at first glance it seems to be a problem of high 'thSADC', but I need to give a deeper look at it.

As for softening I can't recommend anything outside deringing (which ex_luts("clamp") does) and/or blurring. I run tests on it and it worked fairly well for transformers with the antialiasing + deringing combo. Not sure what your goal is, this is as good as it gets without butchering the source.

Antialising for cutting out the sharpness
Deringing to eliminate acutance
Blurring (Optional) for extra softening

As a side effect mosquito noise also seems to be eliminated, so no bitrate hungry artifacts remain, specially if you pair it with a faint temporal denoiser like FluxSmooth or STpresso.

SantiagMod(strh=2,strv=2)
a=last
ex_luts(last,removegrain(12,0),mode="clamp",UV=1)

th = ex_bs(7, 8, bi, false)
ex_lutxy(last,a,Format("x y - abs {th} > y x y min ?")) # hard threshold

# The next very optional
msk=ex_makediff(ex_guidedblur(12,use_gauss=false,regulation_mode=2), aug=10, UV=128)
ex_merge(last,ex_boxblur(0.15,mode="weighted"),msk,luma=true)

Raw

AA+DR

AA+DR+Blur

AA+DR+Localized Blur


@Boulder: Can you try with Dyn=0? I think the issues may come from ShowChannels() or something, maybe ScriptClip() since I'm using "After_Frame=True". Until pinterf has a look on what is preventing ScriptClip to catch ShowChannels() globals I can't switch to the newer ScriptClip() syntax (more MT friendly)

[Boulder]

Originally Posted by Dogway

@Boulder: Can you try with Dyn=0? I think the issues may come from ShowChannels() or something, maybe ScriptClip() since I'm using "After_Frame=True". Until pinterf has a look on what is preventing ScriptClip to catch ShowChannels() globals I can't switch to the newer ScriptClip() syntax (more MT friendly)

Yes, dyn=0 works.

[tormento]

I saw you kept Spresso updated. Any news about STpresso?

[Dogway]

Just updated SPresso again with more HD modes. STpresso I haven't made it, but you can use STTWM() which is now included in ExTools.

I'm also in the middle of a big update for all my filters, big in the sense of importance not number of changes, since I'm going to rework the whole HBD scale thingy to reach parity with AVS+ core and masktools2, after the changes in test26. This is important for MIX mods but I need to synchronize all the scripts to upload at once.

[tormento]

Originally Posted by Dogway

STpresso I haven't made it, but you can use STTWM() which is now included in ExTools.

Thanks, I've noticed your post some weeks ago.

Unfortunately I have absolutely no idea about how to translate the parameters from STpressto to STTWM.

[Dogway]

sthres -> limit
tthres -> tlimit
tw     -> tbias
sw     -> bias
aw     -> back

Anyway, it's not a strict port but the rationale is the same, defaults are to resemble STPresso defaults. The difference is that I use weighted median for both spatial and temporal, and that the temporal part is that, a simple weighted temporal median while fluxsmoothT is a mix of temporal average and temporal median.
Also the temporal part is not motion compensated because a weighted temporal median is already self motion protected.

The benefit of all these changes is greater speed and simplicity. The only thing that can be improved is to use Didée style thresholding/limiting or my own soft threshold solution.

[tormento]

Originally Posted by Dogway

Anyway, it's not a strict port but the rationale is the same, defaults are to resemble STPresso defaults.

I have tried to apply your hints to my scripts, trying a really angry noise beast clip from 12 angry men movie.

Despite being a BW movie, it has some really difficult trade between noise reduction and details (marble, clothes, wood, smoke), plus I am having really a hard time to obtain a decent bitrate when encoding.

I have tried the some of your previous hints, plus other I knew already, such as:

ConvertBits(16)
SMDegrain (tr=9, thSAD=900, refinemotion=true, contrasharp=false, PreFilter=5, plane=4, chroma=true)
fmtc_bitdepth (bits=8,dmode=8)

ConvertBits(16)
pre=smdegrain(tr=6,mode="temporalsoften",blksize=32,thSAD=900,prefilter=5,contrasharp=false,refinemotion=true)
smdegrain(tr=6,mode="MDegrain",blksize=32,prefilter=pre,thSAD=900,LFR=false,contrasharp=false,refinemotion=true)
fmtc_bitdepth (bits=8,dmode=8)

ConvertBits(16)
Spresso(limit=10,bias=30).STTWM(sw=30, tw=49, aw=1, sthres=10, tthres=8)
fmtc_bitdepth (bits=8,dmode=8)

ConvertBits(16)
Spresso(10,30).STpresso(limit=10,bias=30,RGmode=4,tthr=22,tlimit=8,tbias=49,back=1,mc=true)
SMDegrain (tr=6, thSAD=600, refinemotion=true, contrasharp=false, PreFilter=4, plane=4, chroma=true)
fmtc_bitdepth (bits=8,dmode=8)

ConvertBits(16)
Spresso(limit=10,bias=30).STTWM(sw=30, tw=49, aw=1, sthres=10, tthres=8)
SMDegrain (tr=6, thSAD=600, refinemotion=true, contrasharp=false, PreFilter=4, plane=4, chroma=true)
fmtc_bitdepth (bits=8,dmode=8)

Useless to say, I am not having good results, both in quality and in size terms.

Can you pull a rabbit out of the hat?