Color banding and noise removal

[real.finder]

official mvtools v2.5.11.20 has been released and pinterf did some fix too https://github.com/pinterf/mvtools/tree/mvtools-pfmod

can we have new mvtools mod16 ?

[Reel.Deel]

Originally Posted by real.finder

official mvtools v2.5.11.20 has been released and pinterf did some fix too https://github.com/pinterf/mvtools/tree/mvtools-pfmod

can we have new mvtools mod16 ?

pinterf's mod is based on mvtools v2.6.0.5 so it already includes mod16.

[real.finder]

Originally Posted by Reel.Deel

pinterf's mod is based on mvtools v2.6.0.5 so it already includes mod16.

but it don't have official mvtools v2.5.11.20 changes

and not work with avs 2.5 (some people still use it)

[asarian]

Originally Posted by real.finder

but it don't have official mvtools v2.5.11.20 changes

and not work with avs 2.5 (some people still use it)

Hmm, so I just upgraded the wrong AviSynth mvtools?! LOL. Guys, please, don't confuse me. It's hard enough to keep everything apart as it is.

[pinterf]

I came up with the my mod mainly because of the 2.6 Api and to fix some memory exceptions of the x64 version. Really not big modifications. At about the same time Physic came back to business after many years and fixed some other things with the 2.5.11.20 version. But this is for 32 bit only. Note that the 2.6.0.5 version (and thus my mod also) is still 8 bit except the output of mdegrain. Looking at the complexity of the code I think it would be easier to backport the plugin from VapourSynth when we need a true (stacked )16 bit or even float! (Avisynth+ 2017 ) version.

[asarian]

Well, looks like your modded version works great! Thanks for all your hard work!

[James Freeman]

With this line:

Dither_convert_rgb_to_yuv(matrix="2020")

What can be the cause??

[Groucho2004]

Originally Posted by James Freeman

With this line:



What can be the cause??

Either Avisynth cannot find dither.dll or you're missing some MS runtime libraries (or both).
You can troubleshoot your Avisynth install with this tool.

Also, post your full script.

[James Freeman]

Originally Posted by Groucho2004

Either Avisynth cannot find dither.dll or you're missing some MS runtime libraries (or both).
You can troubleshoot your Avisynth install with this tool.

Also, post your full script.

My Script:

AVISource("D:\renderin\signpost.avi",audio=false).AssumeFPS(25,1)
Dither_convert_rgb_to_yuv(matrix="2020")

That's it.

Am I supposed to copy the files from the Win32 directory to the same with the .avsi file?

[Groucho2004]

Originally Posted by James Freeman

Am I supposed to copy the files from the Win32 directory to the same with the .avsi file?

Correct.

[James Freeman]

It works.

[bilditup1]

So, I was told in another thread that this is the proper way to use dither tools to change the color matrix whilst downscaling:

Dither_convert_8_to_16 ()
Dither_resize16 (640, 480, csp="YV24") # change to the desired dimensions
Dither_convert_yuv_to_rgb (matrix="709", output="rgb48y", lsb_in=true)
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="601", lsb=false, mode=0, output="YV12")

Two questions about this:
First, why is the downscale being done here as opposed to just using AviSynth's resizers at the very end of the script? What benefit comes from doing this? Having less to process for the color matrix conversion?
Second, why process in rgb48y?
I'm not asking because I'm skeptical. I just would like to know how this works, as I'm new to Dither.

[Motenai Yoda]

maybe the resize can be done this way if you don't want Dither_convert_yuv_to_rgb to upscale chroma planes, you can use chromak="spline36" to reduce the chroma blurring too, but differences will be negible.
You can use Dither_resize16 at the end too, it will be better than internal avs resizers coz works with better input precision (I don't know for avs+).

internally conversion between colorimetries is done using rgb coz those define how to convert yuv to/from rgb

I don't know how well colormatrix will do, sure it can't get/output at 16bit precision, but I hope all calculation are done internally in float/double, not integer as MisterX said.

[bilditup1]

Originally Posted by Motenai Yoda

...

Thanks for taking the time to explain.

[colours]

Originally Posted by bilditup1

First, why is the downscale being done here as opposed to just using AviSynth's resizers at the very end of the script? What benefit comes from doing this? Having less to process for the color matrix conversion?

Originally Posted by Motenai Yoda

maybe the resize can be done this way if you don't want Dither_convert_yuv_to_rgb to upscale chroma planes, you can use chromak="spline36" to reduce the chroma blurring too, but differences will be negible.
You can use Dither_resize16 at the end too, it will be better than internal avs resizers coz works with better input precision (I don't know for avs+).

AVS and AVS+ both use 16-bit fixed point precision internally (iirc), but they accept and produce only 8-bit output. By using Dither_resize16, you get less rounding error, and if you want an 8-bit output, you now also have the option to apply error diffusion to make it all pretty and dithered. (The posted script does have error diffusion disabled for some reason, though. Bizarre.)

And yes, the downscaling is done right after padding the input to 16-bit as this reduces the number of samples needed to process, thus increasing the speed. Leaving downscaling to the end wouldn't affect accuracy much (might even be very slightly better?), but would be considerably slower depending on the downscaling factor.

The YCbCr→RGB conversion requires the chroma subsampling to be undone at some point, so by converting to 4:4:4 directly in Dither_resize16, we avoid unnecessary resampling, which is both faster and more accurate.

[Motenai Yoda]

Originally Posted by colours

The YCbCr→RGB conversion requires the chroma subsampling to be undone at some point, so by converting to 4:4:4 directly in Dither_resize16, we avoid unnecessary resampling, which is both faster and more accurate.

for me doing this way is definitively better, but I agree slower

Dither_convert_8_to_16 ()
Dither_convert_yuv_to_rgb (matrix="709", output="rgb48y", lsb_in=true, chromak="spline36")
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="601", output="YV24")
Dither_resize16 (640, 480, csp="YV12") # change to the desired dimensions
ditherpost()

PS for cretindesalpes
I was trying this and that with paris clip from Derf's, and I notice some values in the V channel (the yellow papers on the table, the orange of the ball) change, even without resize and the same matrix, just doing yuv->rgb->yuv

ps2 it also happen with avs internal converttorgb, but less

[Reel.Deel]

Originally Posted by colours

(The posted script does have error diffusion disabled for some reason, though. Bizarre.)

The script started out as just a sample from the documentation, forgot to change it.

Originally Posted by Motenai Yoda

for me doing this way is definitively better, but I agree slower

Regarding the script in post #1055, if you add chromak="spline36" to Dither_convert_rgb_to_yuv then you get visually the same result as your script above but much faster (around 70% in my tests).
Here's a comparison between the two methods: 1x | 3x
Here's the original picture I used in the script below, I also change the dithering mode to satisfy colours.

FFImageSource("IMG_4850.png")
Dither_convert_rgb_to_yuv (matrix="709", output="YV12", lsb=true)
o = last

o.Dither_resize16 (640, 360, csp="YV24") # change to the desired dimensions
Dither_convert_yuv_to_rgb (matrix="709", output="rgb48y", lsb_in=true)
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="601", lsb=true, output="YV12", chromak="spline36")
a = last

o.Dither_convert_yuv_to_rgb (matrix="709", output="rgb48y", lsb_in=true, chromak="spline36")
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="601", output="YV24")
Dither_resize16 (640, 360, csp="YV12") # change to the desired dimensions
b = last

a = a.Dither_convert_yuv_to_rgb (matrix="601", output="rgb24", lsb_in=true, chromak="spline36", mode=6).Subtitle("A")
b = b.Dither_convert_yuv_to_rgb (matrix="601", output="rgb24", lsb_in=true, chromak="spline36", mode=6).Subtitle("B")
Interleave(a,b)

[Motenai Yoda]

Regarding the script in post #1055, if you add chromak="spline36" to Dither_convert_rgb_to_yuv then you get visually the same result as your script above but much faster (around 70% in my tests).

yep is still faster and difference is negible, but I think B is still a little bit better

I suspected resize was optional as if you would to downsize or not.
if not you can add chromak="spline36" to Dither_convert_yuv_to_rgb too and remove Dither_resize16 call.

[real.finder]

Originally Posted by Motenai Yoda

yep is still faster and difference is negible, but I think B is still a little bit better

I suspected resize was optional as if you would to downsize or not.
if not you can add chromak="spline36" to Dither_convert_yuv_to_rgb too and remove Dither_resize16 call.

did you try HDRMatrix? http://forum.doom9.org/showthread.ph...67#post1753267

[tormento]

@cretindesalpes

AVS+ is getting more features in these days, such as high bit colors spaces.

Do you think it could be useful to create a specific build of your suite?