Any resizers with anti-ringing?

[Stereodude]

Are there any plugins / filters for AVIsynth that have anti-ringing capability for resizing like madVR has? I know ResampleHQ has linear light capability, but no mention of anti-ringing. I searched around some but didn't find any mention of any.

[feisty2]

dither_resize16nr or nnedi3/eedi3

[feisty2]

or you can use any other resizer you want like this "xxxresize ().repair (gaussresize (p=100),mode=1)" which is basically the same as dither_resize16nr script

[Stereodude]

dither_resize16nr or nnedi3/eedi3Okay, thanks I'll check out dither_resize16nr since I want to downscale and AFAIK nnedi3/eedi3 can't.

[feisty2]

Okay, thanks I'll check out dither_resize16nr since I want to downscale and AFAIK nnedi3/eedi3 can't.

no, downscaling ringing is almost invisible, so using dither_resize16nr instead of dither_resize16 will only cause blur and other problems but gives you no good, it's only recommended to use non ringing resizer for upscaling

[Stereodude]

no, downscaling ringing is almost invisible, so using dither_resize16nr instead of dither_resize16 will only cause blur and other problems but gives you no good, it's only recommended to use non ringing resizer for upscalingOh... Good to know.

I was using this:
ResampleHQ(1280,720, "YV12", "TV.709", "TV.709", false, 0, 0, -0, -0 ,"CatmullRom")
flash3kyuu_deband(range=15, grainY=32, grainC=32, sample_mode=2, dither_algo=3, mt=false)

I think this is more or less the same thing using the dither package though I don't think Dither_resize16 scales in linear light...
Dither_convert_8_to_16()
Dither_resize16(1280, 720, 0, 0, -0, -0, kernel="bicubic", a1=0, a2=.5)
GradFun3(smode=1,lsb_in=true,lsb=true,debug=0)
DitherPost()
Or should I deband the source prior to scaling it since the final dither is the last step either way?

[Sharc]

Perhaps this (http://svn.int64.org/viewvc/int64/resamplehq/doc/kernels.html) can also help with filter selection.

[Stereodude]

Perhaps this (http://svn.int64.org/viewvc/int64/resamplehq/doc/kernels.html) can also help with filter selection.That was interesting. I hadn't seen it before.

[feisty2]

yeah, you can achieve gamma aware resizing by using "Dither_y_gamma_to_linear" and "Dither_y_linear_to_gamma", dither_resize16 is not gamma aware

[Stereodude]

yeah, you can achieve gamma aware resizing by using "Dither_y_gamma_to_linear" and "Dither_y_linear_to_gamma", dither_resize16 is not gamma awareIf I'm resizing in 16 bits do I need a linear light resizer?

[feisty2]

If I'm resizing in 16 bits do I need a linear light resizer?

you can use gamma aware resizing but it may give you ringing and aliasing for some unknown reasons

# 1920x1080 stacked 16bit input here #
dither_convert_yuv_to_rgb (lsb_in=true,output="rgb48y")
Dither_y_gamma_to_linear (curve="709")
dither_resize16 (1280,720)
Dither_y_linear_to_gamma (curve="709")
Dither_convert_rgb_to_yuv (SelectEvery (3, 0),SelectEvery (3, 1),SelectEvery (3, 2),lsb=true)

now your video is downscaled to 720p with gamma aware process

[Stereodude]

you can use gamma aware resizing but it may give you ringing and aliasing for some unknown reasonsInteresting... I have noticed the aliasing with ResampleHQ. Especially when going from FHD to DVD. I didn't attribute it to gamma aware resizing though.

[cretindesalpes]

With gamma-aware resizing, ringing occurs on the dark part of a contrasted dark/light edge. The ringing exists without gamma awareness too, but it becomes more visible when resizing in a linear colorspace. The reason is exactly the same as for the preservation of stars in a night sky. Averaging pixels of different intensities in a gamma-compensated colorspace tends to darken the result.

On the other hand, the ringing is attenuated in the light part.

Anyway, the correct way to resize a Y’Cb’Cr’ picture in linear light is to convert it first in R’G’B’, then to RGB by linearizing each component. Then resize and do the inverse transform. Check this (http://forum.doom9.org/showthread.php?p=1545110#post1545110).

[Stereodude]

Anyway, the correct way to resize a Y’Cb’Cr’ picture in linear light is to convert it first in R’G’B’, then to RGB by linearizing each component. Then resize and do the inverse transform. Check this (http://forum.doom9.org/showthread.php?p=1545110#post1545110).So it this correct then?Dither_convert_8_to_16()
GradFun3(radius=15, smode=1, lsb_in=true, lsb=true, debug=0)
dither_convert_yuv_to_rgb (lsb_in=true, output="rgb48y")
Dither_y_gamma_to_linear (curve="709", tv_range_in=false, tv_range_out=false, u=1, v=1)
Dither_resize16(1280, 720, 2, 2, -6, -2, kernel="bicubic", a1=0, a2=.5, u=1, v=1)
Dither_y_linear_to_gamma (curve="709", tv_range_in=false, tv_range_out=false, u=1, v=1)
Dither_convert_rgb_to_yuv (SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2), lsb=true)
DitherPost(mode=0)
Why do I want tv_range_in = false?

[feisty2]

oh, my omission, sure u should set "tv_range_in=false, tv_range_out=false"
coz it works on RGB mode which means full range :)

[TheSkiller]

This raises a question...
Which curve is the correct one to use in linear <-> gamma conversions if we're working with stacked RGB originating from standard 8 bit YCbCr (like YV12)?
I noticed you guys use curve="709" while in cretindesalpes' example there is no curve specified which means it defaults to "sRGB".

[feisty2]

the transfer characteristics (curves) for dvd and hdtv are both bt709, and bt2020 for uhdtv

[TheSkiller]

Well, yes, I know. But after we convert YV12 to RGB... doesn't that change the transfer curve to sRGB?
I thought 601 and 709 (and BT.2020) exist only in YCbCr land, not RGB.

By the way, the transfer characteristics for DVD are definitely not 709 but 601 like pretty much all SD sources.

[feisty2]

Well, yes, I know. But after we convert YV12 to RGB... doesn't that change the transfer curve to sRGB?
I thought 601 and 709 (and BT.2020) exist only in YCbCr land, not RGB.

By the way, the transfer characteristics for DVD are definitely not 709 but 601 like pretty much all SD sources.

bt601 and bt709 are exactly the same curve, transfer characteristic and matrix are 2 different things!

[TheSkiller]

OK, true, it also says it in the dither documentation. However this doesn't answer my question whether the transfer characteristics change to sRGB or not if we convert a source with 709 transfer characteristics to RGB.

[Stereodude]

Are you suggesting the latter conversion back to YUV should be something other than 709?

[feisty2]

OK, true, it also says it in the dither documentation. However this doesn't answer my question whether the transfer characteristics change to sRGB or not if we convert a source with 709 transfer characteristics to RGB.

no, when applied Dither_y_gamma_to_linear (), you get linear rgb, no gamma stuff, I guess the curve won't change during the conversion

[TheSkiller]

Are you suggesting the latter conversion back to YUV should be something other than 709?No, I'm not talking about the actual color space conversion. I'm talking about the "linear <-> gamma" conversions:
Dither_y_gamma_to_linear (curve="709", tv_range_in=false, tv_range_out=false, u=1, v=1)
and
Dither_y_linear_to_gamma (curve="709", tv_range_in=false, tv_range_out=false, u=1, v=1)


Like I've said, cretindesalpes didn't specify curve at all in his example he links to (link (http://forum.doom9.org/showthread.php?p=1545110#post1545110)) which means it defaults to "sRGB", not "709". So which is the correct one to use for the given case?

[feisty2]

in studios, they use 16bit linear rgb to store the original digital mastertape, and when they encode the master to a dvd/bd/hdtv project, they convert it to yv12 using bt709 curve which means you have to use the same curve (bt709) to convert it back to linear rgb
and single image is different from a video because jpg images are usually converted from 8bit rgb sources (8bit rgb needs gamma not like 16bit rgb dosen't) (SRGB in most cases) so you have to use SRGB curve for these single images