Dogway's Filters Packs

Originally Posted by LeXXuz

Yeah I know they have to match. First stage was also set to subpixel=3, of course.

It only works if both are set to 2.
It does not work when both are set to 3.
(And of course it doesn't work when they don't match.)

HI LeXXuz

what is the benefit to use globals in denoising?
Could it improve denoise, could it replace prefilters....

have you got some script to share to do some comparison test with my current setup?

Thank you in advance.

[LeXXuz]

Originally Posted by madey83

HI LeXXuz

what is the benefit to use globals in denoising?
Could it improve denoise, could it replace prefilters....

have you got some script to share to do some comparison test with my current setup?

Thank you in advance.

You may want to take a look into the docs with the link Dogway provided.

The globals parameter can be helpful if you want to run more than one instance of SMDegrain for denoising. The benefit is you dont't have to recalculate motion vectors again for your second instance of SMDegrain which can improve performance.

Some forms of noise can better be reduced by two instances of SMDegrain (each with weaker settings) than just one instance with stronger settings.

This doesn't replace prefiltering in any way. Appropriate prefiltering is always important to get best results with SMDegrain.

[kedautinh12]

Hi Dogway, your scripts requirements need only transforms pack. I wonder it's need 3 parts of them or only main version?? Of cause i load all and I ask for my friend (old man)

[TDS]

@ Dogway ,

"Old Man" here, just to give a little more info on kedautinh12's post above.

I asked him for some help a little earlier today, and he mentioned about the 3 Transforms Packs:-

Transforms Pack-Main

Transforms Pack-Models

Transforms Pack-Transfers

I have ONLY been using the "Main" one, with my scripts that need Transforms Pack, and it works....adding the other 2 didn't make any difference to the script I was working on.

Respect.

[Reel.Deel]

Transforms Pack-Main has lots of functions and some of those are dependent on the functions included in the Models/Transfers pack. If you're using the Main pack and it's not complaining about a missing function, then it does not anything from the other two packs. It does not hurt one bit to have all of the scripts.

[kedautinh12]

Hi, i report new issue: when i use this scripts, i got that error (test with some video but i still got same issue. I think issue not from my video)

src=last
RatioResize(0.25,"%",kernel="bicubic")
DeStripeV(3,1,255)
ex_boxblur(1,0,mode="weighted")
bicubicresize(1338,974)
ex_LFR(src,last, LFR=150)
src=last

ex_edge("kroon")
ex_boxblur(0,5)
ex_binarize(80,true,hi=-1)
ex_lut("x[-1,0] x[1,0] - abs 5 *").ex_inpand().ex_expand()
ex_boxblur(0,10)
ex_lut("x 40 - 0 max 20 *") # Assumes 8-bit
# ex_deflate().ex_deflate()

InpaintDelogo(src, mask=last, Loc="0,0,0,0")
ex_lutxy(src,"y 5 + x > y x ?") # Assumes 8-bit


smdegrain(tr=2,mode="temporalsoften",blksize=32,thSAD=900,LFR=false,DCTFlicker=true,contrasharp=false,refinemotion=true)
smdegrain(tr=1,mode="MDegrain",blksize=32,thSAD=300,LFR=false,contrasharp=false,refinemotion=false)

ex_bilateral(5,0, ithres=10.0, sthres=10.0, dejaggie=false)

[Dogway]

Sure, you are comparing the original with a scaled clip in ex_LFR().

By the way, among other things I finished the CAT refactor so I'm uploading TransformsPack v1.0 final in a few moments. Will write a full fledged post later in the day with examples and benchmarks.

[kedautinh12]

Ah, ok thanks

[Dogway]

I had time to run some speed benchs and some examples for ConvertFormat()
Mind you, I still need to work on the Preset system and Model conversion within ConvertFormat()

In my tests all filters run better at Prefetch(4). P8 indicates the speed at 8-bit for comparison.

The template script is as follows:

setmemorymax(2048*4)
DGSource("src.dgi")

ConvertBits(16)

[...] # Filters

Prefetch(4)

YUV to RGB

100 329 P8 520 z_ConvertFormat(pixel_type="RGBP16",colorspace_op ="709:709:709:l=>rgb:709:709:l",resample_filter="spline36")
               fmtc_resample(kernel="spline36", css="444")
 65 213 P8 251 fmtc_matrix(mat="709", col_fam="RGB",fulld=false)
 64 209 P8 372 ConvertFormat(1,1,"YUV","RGB",kernel="spline36",tv_out=true)
 59 194 P8 368 ConverttoPlanarRGB(matrix="709:f",chromaresample="spline36")

RGB to YUV

100 216 z_ConvertFormat(pixel_type="YUV420P16",colorspace_op ="rgb:709:709:f=>709:709:709:l",resample_filter="spline36")
 76 163 ConverttoYUV420(matrix="709:l",chromaresample="spline36")
        fmtc_matrix(mat="709", col_fam="YUV")
 75 161 fmtc_resample(kernel="spline36", css="420")
 64 138 ConvertFormat(1,1,"RGB","YUV",kernel="spline36")

1080p to UHD

100 253 P8 351 z_ConvertFormat(3840,2072,resample_filter="spline36")
 83 210 P8 243 fmtc_resample(3840,2072,kernel="spline36")
 63 158 P8 246 ConvertFormat(3840,cs_out="",kernel="spline36")

Rec.601 to Rec.709 (no P8 since speeds are similar except avsresize with a 25% speed increase)

100 294 z_ConvertFormat(pixel_type="YUV420P16",colorspace_op ="601:709:170m:l=>709:709:170m:l",resample_filter="spline36")
        fmtc_resample (css="444",kernel="spline36")
        fmtc_matrix   (mats="601", matd="rgb")
        fmtc_transfer (transs="1886", transd="linear")
        fmtc_primaries(prims="170m", primd="709")
        fmtc_transfer (transs="linear", transd="1886")
        fmtc_matrix   (mats="rgb", matd="709")
 26  77 fmtc_resample (css="420",kernel="spline36")
 13  38 ConvertFormat(cs_in="601",cs_out="709",kernel="spline36")

Some useful examples for ConvertFormat()


No Moirée

ConvertFormat(0.5,nomoiree=true,kernel="RobiSharp")

Ringing
Plain lanczos4 x4 upscale

With sigmoid scaling, a bit better.

ConvertFormat(4,cs_out="",kernel="lanczos4",scale_space="sigmoid")

But noring=true makes the difference

ConvertFormat(4,cs_out="",kernel="lanczos4",noring=true)

yes, you can mix them to get less 'bloating'

ConvertFormat(4,cs_out="",kernel="lanczos4",noring=true,scale_space="sigmoid")

Now nnedi3, nice

ConvertFormat(4,cs_out="",kernel="nnedi3")

But it can also be further improved

ConvertFormat(4,cs_out="",kernel="nnedi3",noring=true)

UHD upscale
Talking about nnedi3, you can upscale to UHD with decent speed at 72fps (nnedi3 GPU):

ConvertFormat(3840,cs_out="",kernel="nnedi3")

Or if you want some more sharpness

deep_resize(3840,grain=0) # 12 fps

Downscaling

Now for the opposite. With typical downscale kernels you can't go too far.
See in this example with 'Zopti1080', which is a bicubic with -0.99 and 0.06 coefs.

Source
Spline64

ConvertFormat(0.25,cs_out="",kernel="spline64")

Zopti1080

ConvertFormat(0.25,cs_out="",kernel="Zopti1080")

Of course, you can try using linear scaling but result doesn't look nice at all (even worse with Zopti1080)

ConvertFormat(0.25,cs_out="",kernel="spline64",scale_space="linear")

Now check using 'SSIM2' downscaler

ConvertFormat(0.25,cs_out="",kernel="SSIM2")

This is streamlined in deep_resize() by default:

deep_resize(0.25)

[kedautinh12]

Wow, amazing result

[tormento]

Originally Posted by Dogway

I had time to run some speed benchs and some examples for ConvertFormat()

[…]

ConvertBits(16)

On older machines (like mine) ConvertBits seems to be slower than other HBD conversion such as avsresize and fmt_, beside giving problems when converting to RGB and back (there are some posts about the need of fulld=true).

Moreover, if I am not wrong, avsresize allows to compact the conversion process in a single line instead of two calls. I can't remember about fmt_ .

Perhaps you could gift us with some more tests.

[Dogway]

Well, I can't compete with compiled programs and yet ConvertFormat() manages to equal fmtconv and internal Convert_ in some modes. avsresize is another thing, I don't know if they handcrafted the code in assembly or what but it's insanely fast.

In any case it was never my purpose, the beauty of it is to for example, scale up with nnedi3, using noring, in linear scale, with correct chroma placement, and change transfer or color space with gamut compression all in "one step" and with a self explanatory one-liner. Moreover, all the coefficients are derived so you might probably get more accurate* results (though not standard). It also serves me and others as a notebook for color management, as I write notes here and there, and the code isn't populated with CPU/SIMD specific intrinsics.
*Yeah, I realize CIE 1931 is far from being accurate, that's why I keep working on the CMFs.

Running these tests gave me some ideas for further optimizations, namely while fixing several bugs deep_resize() saw a near 50% speed decrease, so I might give it a look for a refactor.

[DTL]

"With typical downscale kernels you can't go too far."

Scaling for moving pictures systems is very complex task if trying to get sharpest result. Static scalers may give nice results but may cause significant artifacts in motion. So may be next generation scalers can be scene-adaptive so can apply best static scaler for static areas of the scene (it is really very common for many motion pictures footages like static camera for the total scenecut) and use motion-friendly not as sharp scaler for moving parts of the scene.
So 'classic' non-content adaptive scalers for motion pictures may be not as sharp as best static but fast and produce average result for the total movie in both static and moving parts of frames.

If possible it is nice to see 'motion' test of scalers using some synthetic or external slow motion speed content with typical motion speed about 0.1..0.3 samples per frame to see different content positions relative to sampling grid. 'As sharp as single (pixel)sample' static scalers may significantly fail this test. Because moving of single sample keeping its amplitude and 'width' in any real number position relative to sampling grid is not possible. May be animated .GIF file may be natural for text forum to see 'motion test' result.

Typical issue for motion of too-sharp and/or non-linear scalers is 'temporal aliasing' that looks like flickering of small details and sharp edges.

So selecting same for all moving pictures scaler is some balance between temporal artifacts and spatial artifacts and sharpness. Skipping temporal tests for moving pictures scaler may cause selecting too sharp scaler but producing too much temporal artifacts at natural moving pictures.

The 'classic' AVS convolution based linear scalers are result of some balance between temporal artifacts and spatial artifacts and sharpness.

[Boulder]

Can you do a test with that astronomical image and linear scale downscaling with avsresize (using HBD for all steps)? I'd be interested in seeing the result as I've always understood that linear light is better for such source material.

[kedautinh12]

Originally Posted by Boulder

Can you do a test with that astronomical image and linear scale downscaling with avsresize (using HBD for all steps)? I'd be interested in seeing the result as I've always understood that linear light is better for such source material.

I think Transforms Pack of Dogway just finished in 8 bit. HBD will support in future

[Dogway]

Originally Posted by Boulder

Can you do a test with that astronomical image and linear scale downscaling with avsresize (using HBD for all steps)? I'd be interested in seeing the result as I've always understood that linear light is better for such source material.

I did the test but with fmtconv and result was same.

I think Transforms Pack of Dogway just finished in 8 bit. HBD will support in future

It works at any bitdepth (color space is even hard-coded to 32-bit, that's why is so slow AVS wise), what is not supported currently in ConvertFormat() is HDR, but I want to post a few examples of what you can do using ancillary model functions.

@Dogway,

What is your recommendation to downscale dolby vision 2160p source to 1080p Dolby vision?

[Dogway]

Originally Posted by madey83

What is your recommendation to downscale dolby vision 2160p source to 1080p Dolby vision?

By default deep_resize() uses 'Zopti1080' for going down to 1080p. This is correct in the sense you get a good speed and good quality.
Since you are keeping Dolby Vision (you need to attach metadata to the reencode), the metrics might be changed, but not so much than if you downscaled further.

I did a test and scaling in Dolby Vision 'log' with SSIM2 has a similar effect than scaling with Zopti1080 in 'gamma' (because you lose some sharpness in log)

Originally Posted by DTL

Scaling for moving pictures systems is very complex task if trying to get sharpest result. Static scalers may give nice results but may cause significant artifacts in motion.

That is true, it really depends whether your downscale is display referred or scene referred. For display referred you want something softer and motion aware, maybe a PP filter like Soothe() or ex_reduceflicker() can help, it is also content dependent. On the other side, with scene referred downscales, you are better relying on smart guest device upscalers/PP, similar to basicvsr and such.

[tormento]

Originally Posted by Dogway

Well, I can't compete with compiled programs

I was talking about internal ConvertBits function, that you used in your benchmarks.

[tormento]

Originally Posted by Dogway

By default deep_resize() uses 'Zopti1080'

What about DPID?