Color banding and noise removal

[cybersharky]

DGSource("D:\magnum\title00.dgi",fieldop=0)
crop(0, 4, 0, -4)
LanczosResize(640,480)
tr = 6 # Temporal radius
super = MSuper (pel=2)
multi_vec = MAnalyse (super, multi=true, delta=tr)
MDegrainN (super, multi_vec, tr, thSAD=400, thSAD2=150)

Does temporal radius have anything to do with overlap?
Because I see in the examples overlap is used in MAnalyse, when using MDegrain2/3

[06_taro]

Originally Posted by Lenchik

http://www.nmm-hd.org/newbbs/viewtopic.php?f=7&t=179 and http://www.mediafire.com/file/8b6dhd...size_v1.4.2.7z
As ideas for Dither_resize16 from links above:
- setting separate algorithms for luma and chroma planes;
- some algorithms from madVR;
- some non-ringing algorithms maybe (i don't know if we can use Repair in 16bit without bugs of any kind).

An example for Spline64 luma kernel with SoftCubic75 chroma kernel(but no non-ringing algorithm, RemoveGrain16 and Repair16 is necessary for many scripts to be ported from 8-bit to 16-bit, and adding YV16/YV24 support is also interesting):

Dither_resize16(dest_width, dest_height, kernel="Spline64")
\ .MergeChroma(Dither_resize16(dest_width, dest_height, kernel="Bicubic", a1=0.75, a2=0.25))

[cretindesalpes]

cybersharky:

No, the temporal radius has nothing to do with the overlap. However, omitting the overlap (default is 0) may cause blocking-like artifacts.[/QUOTE]

Lenchik / 06_taro:

Thank you for the suggestions. Actually I prefer keeping the resizer function "simple", and use scripting for the non-linear parts and plane recombination. Anyway I will add a built-in function for colorspace conversions (including simple chroma subsampling conversions) probably in combination with resizing, because scripting these things is quite complicated and not very efficient.

In your example you could use the plane filters to avoid unnecessary computations that will be thrown out:

               Dither_resize16(dest_width, dest_height, kernel="Spline64", u=1, v=1)
\ .MergeChroma(Dither_resize16(dest_width, dest_height, kernel="Bicubic", y=1, a1=0.75, a2=0.25))

Even without 16-bit RemoveGrain, it's possible to work in 8 bits for ringing cancellation and merge the modified pixels with the 16-bit results. This would be a good approximation for visible ringing. Pixel-sized artifacts (aliasing, ringing, halos…) generally don't need 16-bit processing to be fixed as they often result in large value changes.

[06_taro]

Agree with keeping the resizer "simple". And applying such a filter on 8-bit clip and adding the diff is usually enough in terms of visual effect. But if the aimed output clip is 16-bit, would it result in some artefacts in LSB, such as mosquito around edges for deringing? And although such artefacts in LSB shouldn't be noticeable after dithered to 8-bit, I'm worried if they may reduce the efficiency of compression.

[Lenchik]

Same questions as 06_taro's but for aiming output in 10 bit to 10 bit x264 build.

[cretindesalpes]

Originally Posted by 06_taro

Agree with keeping the resizer "simple". And applying such a filter on 8-bit clip and adding the diff is usually enough in terms of visual effect. But if the aimed output clip is 16-bit, would it result in some artefacts in LSB, such as mosquito around edges for deringing? And although such artefacts in LSB shouldn't be noticeable after dithered to 8-bit, I'm worried if they may reduce the efficiency of compression.

These artifacts are small relative to the edges that generate ringing and will be most likely crushed by the compression. And artifacts caused by the low-bitdepth processing are much smaller than the visual artifacts caused by the method itself which is far from perfect, or than the noise level that comes with most lossy or real-life video source.

Below is a quick attempt. I adopted a slightly different approach than just adding the 8-bit difference.

# Gradient
amt_l = 0.25
amt_c = 0.125
BlankClip (length=1, width=640, height=480, pixel_type="YV12", color_yuv=$000000)
KillAudio ()
base = last
x  = "x 0.5 - 32768 * "+String(amt_c)+" * 32768 + 0 65535 clip "
y  = "y 0.5 - 32768 * "+String(amt_c)+" * 32768 + 0 65535 clip "
z = "x y + 1 - 32768 * "+String(amt_l)+" * 32768 + 0 65535 clip "
msb = base.mt_lutspa (mode="relative", yexpr=z+"8 >>u 255 &u", uexpr=x+"8 >>u 255 &u", vexpr=y+"8 >>u 255 &u", y=3, u=3, v=3)
lsb = base.mt_lutspa (mode="relative", yexpr=z+"      255 &u", uexpr=x+"      255 &u", vexpr=y+"      255 &u", y=3, u=3, v=3)

# Text
txt = msb
txt = txt.Subtitle ("This is a test.\n\n--\\||//@=#§", align=5, lsp=1, text_color=$E0E020, halo_color=$202020)
txt = txt.Subtitle ("\nTest with light ringing.",      align=5, lsp=1, text_color=$848484, halo_color=$808080)
msk = mt_lutxy (msb, txt, "x y != 255 0 ?", y=3, u=3, v=3)
lsb = mt_merge (lsb, base, msk, y=3, u=3, v=3)
msb = txt

StackVertical (msb, lsb)

# Rings. Source: http://www.imagemagick.org/Usage/img_photos/rings_lg_orig.png
rings = ImageSource ("rings_lg_orig.png").Trim (0, -1)
rings = rings.ConvertToYV12 ().Crop (0, 0, 0, base.Height ()).Dither_convert_8_to_16 ()
StackHorizontal (last, rings)


# Resize
dw = Width()    * 2
dh = Height()/2 * 2

main = Dither_resize16 (dw, dh, kernel="Spline64"     )
nrng = Dither_resize16 (dw, dh, kernel="Gauss", a1=100)

m8 = main.DitherPost (mode=-1)
n8 = nrng.DitherPost (mode=-1)
f8 = m8.Repair (n8, 1)
k8 = mt_lutxy (m8, f8, "x y != 255 0 ?", y=3, u=3, v=3)
f16 = f8.Dither_convert_8_to_16 ()
f16 = nrng.Dither_limit_dif16 (f16, thr=0.5)
Dither_merge16_8 (main, f16, k8, y=3, u=3, v=3)


# Display
main.Subtitle ("Spline64") + last.Subtitle ("nrSpline64")
DitherPost (mode=6)
    last
\ + mt_lut (expr="x 16 &u   17 x 15 &u -   1 x 15 &u +   ? 14 *", u=-128, v=-128)
\ + k8.GreyScale ().Subtitle ("Ringmask")

[SilaSurfer]

Hey cretindesalpes. Since I'm using a lot of your functions from Dither package, I decided to incorporate Dither_resize16 in my general workflow. Now I want to produce the same output as ResampleHQ, meaning gamma aware resizing, and I wanted to check if I got it correctly:

Dither_convert_8_to_16 ()
Dither_y_gamma_to_linear()
Dither_resize16(w, h, kernel="blackman", taps=5) - I'm using Blackman as my resizer for Bluray sources where I resize down to 720p.
Dither_y_linear_to_gamma()
Ditherpost(mode=-1,ampo=0,ampn=0)

As you can see my sources are YV12. Is this ok?

[cretindesalpes]

Dither_convert_yuv_to_rgb (matrix="709", output="rgb48y")
Dither_y_gamma_to_linear (curve="709", u=1, v=1)
Dither_resize16 (w, h, kernel="blackman", taps=5, u=1, v=1)
Dither_y_linear_to_gamma (curve="709", u=1, v=1)
Dither_convert_rgb_to_yuv (
\  SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2),
\  matrix="709", mode=-1)

But unless you really have a reason, prefer mode=6 (or 0) to mode=-1.

[SilaSurfer]

Originally Posted by cretindesalpes

Dither_convert_yuv_to_rgb (matrix="709", output="rgb48y")
Dither_y_gamma_to_linear (curve="709", u=1, v=1)
Dither_resize16 (w, h, kernel="blackman", taps=5, u=1, v=1)
Dither_y_linear_to_gamma (curve="709", u=1, v=1) 
Dither_convert_rgb_to_yuv (
\  SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2),
\  matrix="709", mode=-1)

But unless you really have a reason, prefer mode=6 (or 0) to mode=-1.

Thanks cretindesalpes. About mode parameter I was just posting an example. I will incorporate this into my denoising and dithering workflow from your Dither tools. What about if I would want to downsize to SD, I would need to change Matrix parameter to 601?

Dither_convert_yuv_to_rgb (matrix="709", output="rgb48y")
Dither_y_gamma_to_linear (curve="709", u=1, v=1)
Dither_resize16 (w, h, kernel="blackman", taps=5, u=1, v=1)
Dither_y_linear_to_gamma (curve="601", u=1, v=1) 
Dither_convert_rgb_to_yuv (
\  SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2),
\  matrix="601", mode=-1)

Like so?

[cretindesalpes]

Yes for Dither_convert_rgb_to_yuv(), but keep "709" in Dither_y_linear_to_gamma(). This is the same transfer characteristic anyway. I just should add an alias for convenient use.

[SilaSurfer]

Thanks, cretindesalpes

Do you have any convolutions examples for your resizer?

[cretindesalpes]

Dither 1.16.0:

• Added generic spline kernel to Dither_resize16.
• Added the SMPTE 240M gamma curve and aliases for BT.601 and SMPTE 170M.
• Fixed a bug related to chroma subsampling and multi-threading in Dither_merge16.
• Bug fixed in MVTools.

——— Edit ———

SilaSurfer:

# Equivalent to mt_convolution (horizontal="1 5 -1 7 -1 5 1", vertical="1", u=3, v=3) for stack16 clips
w = Width ()
h = Height () / 2
Dither_resize16 (w, h, kernelh="impulse 1 5 -1 7 -1 5 1", fh=-1, center=false)

[Reel.Deel]

Thanks cretindesalpes!!

[SilaSurfer]

Originally Posted by cretindesalpes

Dither 1.16.0:

• Added generic spline kernel to Dither_resize16.
• Added the SMPTE 240M gamma curve and aliases for BT.601 and SMPTE 170M.
• Fixed a bug related to chroma subsampling and multi-threading in Dither_merge16.
• Bug fixed in MVTools.

——— Edit ———

SilaSurfer:

# Equivalent to mt_convolution (horizontal="1 5 -1 7 -1 5 1", vertical="1", u=3, v=3) for stack16 clips
w = Width ()
h = Height ()
Dither_resize16 (w, h, kernelh="impulse 1 5 -1 7 -1 5 1", fh=-1, center=false)

Thanks cretindesalpes for updated version and the example.

[SilaSurfer]

Dither_convert_8_to_16 ()
Dither_resize16 (1280, 720, kernel="impulse -1 6 -1",
\                fh=-1, fv=-1, cnorm=true, center=false)
DitherPost (mode=-1)

I also tried your example from the docs and the result is just beautiful. But I had to change it from this:

Dither_convert_8_to_16 ()
Dither_resize16 (Width (), Height () / 2, kernel="impulse -1 6 -1",
\                fh=-1, fv=-1, cnorm=true, center=false, y=3, u=2, v=2)
DitherPost ()

If I specify my own resolution, that is without /2, I get some color distortion, I had to remove y=3,u=2,v=2 parameters to normalize it. Is it save to use the way I posted it in the first example? Thanks for your patience.

[Boulder]

Out of interest: have you had any chance to look at the improvements made to MVTools v2 by the SVP team?

[cretindesalpes]

Not yet. But I'll have a look when possible.

[ajp_anton]

Originally Posted by cretindesalpes

Dither_convert_yuv_to_rgb (matrix="709", output="rgb48y")
Dither_y_gamma_to_linear (curve="709", u=1, v=1)
Dither_resize16 (w, h, kernel="blackman", taps=5, u=1, v=1)
Dither_y_linear_to_gamma (curve="709", u=1, v=1)
Dither_convert_rgb_to_yuv (
\  SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2),
\  matrix="709", mode=-1)

But unless you really have a reason, prefer mode=6 (or 0) to mode=-1.

Why go to RGB for resizing?

[cretindesalpes]

It’s not for resizing, it’s for gamma correction (to do things correctly).

[ajp_anton]

Isn't gamma_to_linear doing the gamma "correction"? Or is linear scale not well defined for the UV planes or something?