Dogway's Filters Packs

[tormento]

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]

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]

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]

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
http://i.imgur.com/EdfPh2zm.png (https://i.imgur.com/EdfPh2z.png)
AA+DR
http://i.imgur.com/jwXUyw1m.png (https://i.imgur.com/jwXUyw1.png)
AA+DR+Blur
http://i.imgur.com/QTDKMFkm.png (https://i.imgur.com/QTDKMFk.png)
AA+DR+Localized Blur
http://i.imgur.com/3pjn57gm.png (https://i.imgur.com/3pjn57g.png)

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

@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 (https://forum.doom9.org/showthread.php?p=1957551#post1957551). This is important for MIX mods but I need to synchronize all the scripts to upload at once.

[tormento]

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]

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 (https://send.cm/d/6WES).

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?

[Dogway]

Is there a special scene or frame you have issues with? I tested with the Carrie call (I use tr 1 and 2 and thSAD=400 for the 2nd call) and found it good enough.
Also keep in mind this is a BW film so plane=0 and chroma=false.

The film shows "fizz" grain. It's in between the Carrie example and something stronger like 300. I found that a blksize of 32 is good to avoid catching these kind of big grains, along refinemotion this is a good approach. Filters like SPresso or STTWM are not suited here because they only filter minimal change noise, these are more for DVDs or faint grain.
My general approach with strong grain is a rather strong prefilter (with LFR), and a rather not so strong filter without LFR.

Personally for my encodes I don't like the clean look because they either look psychovisually blurry or sometimes it shows the "screen" effect, like grain stuck over a glass, so I apply some artificial grain after denoising.

[tormento]

Is there a special scene or frame you have issues with? I tested with the Carrie call (I use tr 1 and 2 and thSAD=400 for the 2nd call) and found it good enough.
Also keep in mind this is a BW film so plane=0 and chroma=false.
The issue is the resulting bitrate, too high for a BW movie.

The best results are from SPresso+STPresso+SMDegrain but the speed is in the order of 0.5 fpsL too slow. I am eager to see your porting of STPresso if it could achieve better speeds and the same quality.

Plus, I have found that, strangely, if you apply plane=0 and chroma=false, you obtain a lower noise cleanup.

[Boulder]

The issue is the resulting bitrate, too high for a BW movie.

BW movies are often very grainy. Also, chroma information is a much smaller portion of data than luma.

[tormento]

BW movies are often very grainy.
Results vary by the "type" of grain, i.e. silver particle size, distribution, etc. Some BW movies are really easy to compress and you can achieve really high compression ratio.
Also, chroma information is a much smaller portion of data than luma.
The strange thing is that using plane=0 and chroma=false, lowers the noise reduction, even using Greyscale() to cleanup chroma completely. That's a thing I will never understand.

[Dogway]

The chroma plane which is plain grey will be considered for the SAD calculation so it lowers the overall SAD value, moreover when I use a scaleCSAD of 1 for HD sources. Chroma planes are always greyish so the difference is not much but it might be noticeable. You have to counteract this with a higher thSAD.

[tormento]

@dogway

Do you see anything wrong with

SMDegrain (tr=6,PreFilter=4,thSAD=900,contrasharp=false,refinemotion=true, plane=0, chroma=false, Globals=2)
SMDegrain (tr=6, thSAD=900,contrasharp=false,refinemotion=true, plane=0, chroma=false, Globals=1)

instead of using higher tr and thSAD?

Which choice is, quality wise, better?

[Dogway]

Ah, I noticed some issues, well Globals is something I haven't touched in a long time.
I recommend you for the time being to not use Globals. Other than that I see the output is very clean, I'm not accustomed to using such high values, maybe you can add some LFR recovery. Maybe the first pass can use blksize of 32 to speed up processing, but this depends on what details are being wiped or not, it depend on grain amount.

Using two passes is fine, it indirectly multiplies the effect for a fraction of the performance. (-6) -6 0 6 (6) = 24 frames for the current frame output.

[tormento]

Ah, I noticed some issues, well Globals is something I haven't touched in a long time.
Please :) I think that the possibility to calculate vectors only once is useful.
I recommend you for the time being to not use Globals.
So should I use 2 lines of SMDegrain without passing vectors?
Other than that I see the output is very clean
I just can see some issues right before scene change, where details get somehow lost.
I'm not accustomed to using such high values, maybe you can add some LFR recovery.
Perhaps you are not fond of old movies, where grain is not details but simply useless noise. I keep on battling with that.

Do you suggest me to put LFR in the first line, in the second or both?

12 angry men, which I sent you a clip of, is really a bloody mess. With x264 crf 20, I am sweating to keep bitrate unter 4000kb/s and for a BW movie it is really a lot.

[Dogway]

I already fixed the issue with Globals. There are already many changes for new SMDegrain, I was waiting to add RGB support and cumulative YPlaneMin/YPlaneMax to ex_retinex but I lost part of that work plus I was having issues with runtime variables readback.

I only need to finish an issue with UHDhalf prefiltering (switched position so prefiltering happens on dowscaled version) and I do the release. Next v3.4.0 is a good candidate for long stable release.

Running 2 passes is a good idea for several reasons, as you might know 2 mean averages approximates a binomial weight:

ex_boxblur(3,mode="weighted") <-> ex_boxblur(1,mode="mean").ex_boxblur(1,mode="mean")

This is called tent blur and in the context of motion vectors this is more performant. Besides you calculate new vectors from a cleaner source so its a finer refinement of MV.

For MDegrain this is like running a median twice, so it approximates a weighted median.
Together you perform a stronger denoising but with stronger center weighting, in other words better protection and speed than a single call with higher 'tr'.

With Globals this is not possible because you are reusing the "dirty" Globals of the first pass (the output Globals of the first prefiltering) and the only benefit is the weighted median. (In contrast using the first pass as a prefiltering only you do refine the MV but don't perform the weighted median)
Globals was designed when combining filters that use MV in rather clean sources, for example for temporal limiting, frame interpolation, etc.

I do like old films, actually I hate new digital recorded movies but lately I have been only developing rather than encoding. If you use such high thSAD or tr, LFR and DCTFlicker by extensions are a must. By Didée words grain is a high frequency only property but DCT encoding propagates this to low frequency. 'DCTFlicker' is not perfect so I recommend running both at first pass and lower thSAD and tr for the second pass to don't destroy what was recovered.

You can optimize x264 bitrate by using preset 'slower' or 'very slow'. Using 'zones' for the opening and credits. Also using a range limiter in avisynth. And a light blur where motion vectors fail (the 'mfilter' arg)

[tormento]

You can optimize x264 bitrate by using preset 'slower' or 'very slow'. Using 'zones' for the opening and credits. Also using a range limiter in avisynth. And a light blur where motion vectors fail (the 'mfilter' arg)
Thanks for your precious advices.

I am using slow preset as my CPU is the real bottleneck of my computer.

What about introducing a "pass" or "recursion" parameter, to internally apply the consecutive denoising? Perhaps it could lead to more speed and less roundings.

[Dogway]

Ok, I just uploaded a new version. It needs latest avisynth, test32 I think. By the way I included a new prefilter, ex_FluxSmoothST(), this is MinBlur + FluxSmoothT, which share the same concept but one is spatial and the other temporal. So now DFTTest is 4, KNLMeanCL 5 and BM3D 6.

I'm reworking the whole packs to be numerically stable and fast by using the latest updates by pinterf (we should build him a monument or at least a xmas present :D )

You might notice some speed improvements when I update ExTools, currently I'm finishing QC but it might take more days to be sure I don't screw it. I mainly have to assure that the new f32 scale_inputs works fine across the board along the new range_max constant (as full scale).

ex_retinex() needs more work to include cumulative stats, they will be in next version.

Do you mean recursion for MDegrain only (not MV)? That's possible. I will run tests to see how it improves things. It fits in the scope of current recursion solution by prepending an "r", so it would work as mode="rMDegrain".


EDIT: sneakingly added recursion to MDegrain, test it out to find if it fills your needs. I might give it a revision for the next version, as Didée was doing something similar back then.

[tormento]

So now DFTTest is 4, KNLMeanCL 5 and BM3D 6.
I'd prefer to have an added number than to change years of habits. :)
Do you mean recursion for MDegrain only (not MV)?
I meant a way to replicate 2 calls of SMDegrain consecutively but internally and optimized, as we were talking about the opportunity to have 2 calls with minor THSAD instead of 1 only with bigger one.

[tormento]

I will run tests to see how it improves things. It fits in the scope of current recursion solution by prepending an "r", so it would work as mode="rMDegrain".
I have looked at SMDegrain AVSI but I can't get how to make recursion work.

I can't see any parameter to add but only a check about the "r" letter on MDegrain and I can't understand how to make it work.

[Dogway]

Yes, declare mode="rMDegrain" in the call and it will use recursion, but only for the MDegrain part not the vectors. As for to replicate 2 consecutive calls, I think it's best to do it explicitly as currently is done, I prefer simple things that can be seen and there wouldn't be speed gain at all (you only save a single TV->PC range).

Bu the way I'm reworking ex_gaussianblur() (used in LFR and ex_retinex()) as it was designed with a single resolution size, but it changes depending on resolution so I had to make a multi-regression fit. The good part is that it will fit even better than before. I will release ExTools in 2 days.

[tormento]

As for to replicate 2 consecutive calls, I think it's best to do it explicitly as currently is done
I hoped to save some video memory, as the dual line recursion eats it like peanuts and I have to increase the number of threads: AVS doesn't like 2xSMDegrain so much and sits idle for the most of machine time.

[Dogway]

Well yes, that's an issue on mvtools, running manalyze several times has a great impact on performance, that's why among other things I don't like creating more MV in scripts like STPresso. DCFlicker uses it too, so it's a bit on the heavy size.

Back in the time I used to split the first pass of SMDegrain into a lossless file and then run the second call on this, this usually was faster than in a single script. MPPipeline also helped on this regard. Now for HD I don't see lossless being an option, maybe pseudo-lossless can cut it, a x264 profile at 12-bit with pseudo-lossless settings.

[tormento]

Now for HD I don't see lossless being an option, maybe pseudo-lossless can cut it, a x264 profile at 12-bit with pseudo-lossless settings.
x264 CRF 0 is of great use but unfortunately Nvidia can read 8 bit AVC 4:2:0 only, leaving me with the option to index it with some software only. HEVC is out of question, as it is too much CPU intensive.

[Dogway]

I have been making a SAD sampler for the last 2 days without success, so I will leave this here in case someone sees an issue.

# ex_Luma_Rebuild(s0=6)
# SAD_sampler(show=2)


## Dependencies:
## ExTools
## FredAverage
## ResizersPack
## Grade (for show)
## MasksPack (for show)
## TransformsPack (for show)

# show: 0: no debug, 1: show sampled area 2: show sampled area in diff mode
function SAD_sampler(clip src, int "show") {

show = Default(show, 0)

mmod(src,128,mode="crop")
b=ConvertBits(8, dither=-1).ExtractY()

w = width()
h = height()
davg=0 grey=0
id = 0 fr = 0
# x = 1 y = 1
OK = false

while (!OK) {

for (x = 1, w/128, 1) {

stridex = 128*x

for (y = 1, h/128, 1) {

stridey = 128*y

c = b.Crop(stridex-128,stridey-128,-w+stridex,-h+stridey)
a = c.FredAverage()
d = c.TemporalSoften(10,255,0,30,2)
# e = c.ex_edge("frei-chen",0,255)
diff = ex_makediff(a, d, aug=5, metric="none", UV=128)
# diff = ex_logic(diff, e, "max", UV=128)

ScriptClip(diff, function[a,d,x,y,c,show] () {

davg = (AverageLuma(last,-5)+AverageLuma(last)+AverageLuma(last,+5))/3.
grey = (AverageLuma(a, -5)+AverageLuma(a) +AverageLuma(a, +5))/3.
OK = (davg < 40.) && (90. < grey < 126.)
d = show > 1 ? last : show > 0 ? c : c
OK ? propSet(d,"_x_id",-1,0).propSet( "_y_id",-1,0).propSet("_diff",davg,0).propSet("_grey",grey,0) : \
propSet(d,"_x_id", x,0).propSet( "_y_id", y,0).propSet("_diff",davg,0).propSet("_grey",grey,0)
} )

yy = propGetInt("_y_id")
xx = propGetInt("_x_id")
EOL = (w+h)/128.
t1 = id/EOL == 1.0
t2 = id/EOL == 2.0
t3 = id/EOL == 3.0
t4 = id/EOL == 4.0
fr = t4 ? fr+24*3 : fr
b = t1 ? b.PadResize(w,h,biasw=64,biash=0) : \
t2 ? b.PadResize(w,h,biasw=0, biash=64) : \
t3 ? b.PadResize(w,h,biasw=-64,biash=0) : \
t4 ? b.PadResize(w,h,biasw=0,biash=-64).selectevery(1,fr) : b

if (show > 0 && yy<0) {
grey = round(propGetFloat("_grey"))
davg = round(propGetFloat("_diff"))
src = b.subtitle(Format("id:{id} fr:{fr}\nx:{x} y:{y}\ng:{grey} d:{davg}"),lsp=1)
bg = BoxMask(src,x*128-128,x*128,y*128-128,y*128,invert=false,matchformat=true)
ex_blend(src,bg,"multiply",opacity=0.3)
}
x = yy<0 ? w/128 : t1 || t2 || t3 || t4 ? 1 : xx
y = yy<0 ? h/128 : t1 || t2 || t3 || t4 ? 1 : yy
id = yy == h/128 ? id : id + 1
id = t4 ? 0 : id
OK = yy<0

}
}
OK ? last : Undefined()
}

I also tested adding the variables into an array to save on propSet/Get calls, but array items can't be dynamic it seems.
I will continue with last fixes for ExTools, SharpenersPack and SMDegrain.

[anton_foy]

Strange, what version of avs+ are you on? propNumElements() works for me outside runtime environments.

Same error here with LSFmod Im on Avs+ version r3577 (testbulid 34), error at line 541 in LSFmod-script.
EDIT: also smdegrain at line 61.

[tormento]

Trying ResizersPack-7.1~Dogway.avsi

Script error: Invalid arguments to function 'width'.
(D:/Programmi/Media/AviSynth+/plugins64/ResizersPack-7.1~Dogway.avsi, line 171)
(D:/Programmi/Media/AviSynth+/plugins64/ResizersPack-7.1~Dogway.avsi, line 150)
(D:/Programmi/Media/AviSynth+/plugins64/TransformsPack-1.0rc29~Dogway.avsi, line 136)
(D:/Programmi/Media/AviSynth+/plugins64/TransformsPack-1.0rc29~Dogway.avsi, line 145)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.3.9d~Dogway.avsi, line 914)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.3.9d~Dogway.avsi, line 917)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.3.9d~Dogway.avsi, line 228)

[kedautinh12]

Trying ResizersPack-7.1~Dogway.avsi

Script error: Invalid arguments to function 'width'.
(D:/Programmi/Media/AviSynth+/plugins64/ResizersPack-7.1~Dogway.avsi, line 171)
(D:/Programmi/Media/AviSynth+/plugins64/ResizersPack-7.1~Dogway.avsi, line 150)
(D:/Programmi/Media/AviSynth+/plugins64/TransformsPack-1.0rc29~Dogway.avsi, line 136)
(D:/Programmi/Media/AviSynth+/plugins64/TransformsPack-1.0rc29~Dogway.avsi, line 145)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.3.9d~Dogway.avsi, line 914)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.3.9d~Dogway.avsi, line 917)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.3.9d~Dogway.avsi, line 228)

Cause ResizersPack latest ver update for extools v6.9 but extools just updated v6.8

[tormento]

Cause ResizersPack latest ver update for extools v6.9 but extools just updated v6.8
Version 7.0 works perfectly fine and I think it was the first one prepared for newer extools. Only Dogway will tell us what happened :)

[Dogway]

Ok, I just updated ExTools so hope things go back to normal slowly. Still need to update SMDegrain. TransformsPack I don't know what the issue is?
I was holding back for the ex_bs() refactor but it was delayed on conversations with pinterf so decided to do it for next version, so sad v6.9 will be so short-lived :o

[anton_foy]

Ok, I just updated ExTools so hope things go back to normal slowly. Still need to update SMDegrain. TransformsPack I don't know what the issue is?
I was holding back for the ex_bs() refactor but it was delayed on conversations with pinterf so decided to do it for next version, so sad v6.9 will be so short-lived :o

Nice work! I replaced with new Extools but LSFmod get another error:
ex_lutspa does not have a named argument "fulls"

EDIT: sorry my bad, it was deblockpack but when I updated from 1.5 to 1.6 I get that runtime error again at line 98.

[Dogway]

LSFmod and TransformsPack still need to be updated. DeblockPack is updated so it should work, line 98? Do you mean this line?:
propGetInt (clp,"_ColorRange") == 0 : rgb

[Forteen88]

The issue is the resulting bitrate, too high for a BW movie.

The best results are from SPresso+STPresso+SMDegrain but the speed is in the order of 0.5 fpsL too slow. I am eager to see your porting of STPresso if it could achieve better speeds and the same quality.

Plus, I have found that, strangely, if you apply plane=0 and chroma=false, you obtain a lower noise cleanup.If I have to pick either SPresso or STPresso, would it be better to pick STPresso to encode DVD-videos, because it's temporal? To my understanding, SPresso is probably better to encode a video with a bunch of still-images.

[Boulder]

Video is a bunch of still images you know..

[Forteen88]

Video is a bunch of still images you know..:) I think that you understand what I mean.
STPresso for sequential video.

[Dogway]

I always favour some temporal filtering, so you can try STPresso. It has bias options between spatial and temporal, it's a tad slower than SPresso so for a faster alternative I made STTWM(). You can try them and use what suits your needs.

[anton_foy]

LSFmod and TransformsPack still need to be updated. DeblockPack is updated so it should work, line 98? Do you mean this line?:
propGetInt (clp,"_ColorRange") == 0 : rgb

It says "propnumelements: this filter can only be used within run-time filters. DeblockPack.avsi, line 98"

[Forteen88]

I always favour some temporal filtering, so you can try STPresso....Thanks.

[Dogway]

It says "propnumelements: this filter can only be used within run-time filters. DeblockPack.avsi, line 98"

I think you don't have latest AVS+ installed because it's working fine here. frameprops can be read from frame index 0 since a few versions back.


By the way, I just uploaded a refactor of FlatMask() inspired by the recent thread here (https://forum.doom9.org/showthread.php?t=183533)on edge masks for cartoons.
I remade it entirely with ExTools and while it isn't exactly the same it probably works faster than doing full segmentation like described in the paper.
It serves two purposes, edge masks without double edges, and if fine tuned also as a flat mask. It uses an internal limiter so it also can be used to mix filtered clips to pass only on flat areas.

http://i.imgur.com/qLkLLbem.png (https://i.imgur.com/qLkLLbe.png)

http://i.imgur.com/45OtuXlm.png (https://i.imgur.com/45OtuXl.png)

[Shinkiro]

LSFmod broken
https://i.imgur.com/pho0VTB.png

[Dogway]

Yes, updating soon.

[anton_foy]

I think you don't have latest AVS+ installed because it's working fine here. frameprops can be read from frame index 0 since a few versions back.


Don't know what Im doing wrong I replaced all avisynth.dll's with the newest "Avisynth+ 3.7.1 test build 34 (20211208)"
In Avisynth_repository>x86-folder and in System32-folder.

EDIT: BTW. Thanks Dogway for the applygradientcurves substitution!!!

[Dogway]

Are you using avisynth x86? If not files should go into the x64 folder and system32. In other words in the test34 zip go to the x64 folder and copy Avisynth.dll and DeVil.dll into System32, then the files from plugins folder into "plugins64+" folder of your avisynth+ installation. If this doesn't work you might need to check your paths with avsmeter "avsmeter64 avsinfo -lf >AVSinfo.log"

This is how it looks here:
VersionString: AviSynth+ 3.7.1 (r3577, master, x86_64)
VersionNumber: 2.60
File / Product version: 3.7.1.0 / 3.7.1.0
Interface Version: 8
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\system32\avisynth.dll
Avisynth.dll time stamp: 2021-12-08, 19:27:35 (UTC)
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+

[anton_foy]

Are you using avisynth x86? If not files should go into the x64 folder and system32. In other words in the test34 zip go to the x64 folder and copy Avisynth.dll and DeVil.dll into System32, then the files from plugins folder into "plugins64+" folder of your avisynth+ installation. If this doesn't work you might need to check your paths with avsmeter "avsmeter64 avsinfo -lf >AVSinfo.log"

This is how it looks here:
VersionString: AviSynth+ 3.7.1 (r3577, master, x86_64)
VersionNumber: 2.60
File / Product version: 3.7.1.0 / 3.7.1.0
Interface Version: 8
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\system32\avisynth.dll
Avisynth.dll time stamp: 2021-12-08, 19:27:35 (UTC)
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+

Yes I use 32-bit AVS+

[DTL]

I see default overlap param in SMDegrain = half block size. Do it really makes great visible quality benefit over the smaller size (like 2) ? I see enabling overlap (overlap > 0) in MDegrain significantly affect speed. With block size 8x8 overlap =4 may be 4 times slower of no-overlap. Overlap=2 runs about 60% of no-overlap speed. The overlap=0 really produces visible blocks edges (and make best speed but lowest quality).

Wiki lists:
overlap int = blksize/2
Must be *even* and *less* than block size. Common values: blksize/4 or blksize/2. Larger overlap looks slightly better and runs slower.

May be it exist some statistics what is most commonly used overlap value ?

Assuming with hardware motion search the MAnalyse will be *infinitely* fast - the overlapping processing of MDegrain on CPU will be the main speed limiter.

[Dogway]

Guess I didn't notice the change of defaults, typically settings are as in MVTools defaults so a SMDegrain dumb call is practically the same.

The documentation says:
"The greater overlap, the more blocks number, and the lesser the processing speed. However the default value 0 may cause blocking-like artefacts"

But I can test with blksize/4, I will have a look at zorr statistics but I also have pending my own statistics. For SMDegrain is that and automatic thSAD detection, but it will be in form of a helper function to be called explicitly. I think a wise strategy is to default to blksize/4 if refinemotion is used.

[zorr]

But I can test with blksize/4, I will have a look at zorr statistics but I also have pending my own statistics.

In my tests so far larger overlap most of the time means better quality. Some of my results can be found in this post (https://forum.doom9.org/showpost.php?p=1945684&postcount=31).

The test was using MFlowFPS while MCompensate would most likely be closer to what MDegrain is doing. Nevertheless I think the results also apply to MDegrain to certain degree at least.

Optimal overlap and overlapv were different in that test, I think because motion was almost perfectly horizontal. In the general case that doesn't apply so using blksize/2 is the best option. I have even suggested that MVTools allowed larger than blksize/2 overlaps since there's a clear trend of better quality the larger the overlap.

It would be interesting to test if the quality drop of having smaller overlap like blksize/4 can be compensated with other parameters which don't slow down the processing that much.