Debilinear444

[awvnx]

I've established that a BD source I'm working with was bilinear resized from 720p to 1080p. This was confirmed by checking the output of Debilinear(1280, 720).BilinearResize(1920, 1080) and noticing that the luma was identical to the source.

I'd like to encode it in 720p by using Debilinear on the Y and upscaling the chroma to 720p. However, the chroma doesn't seem to be the same. The red outline desaturated a bit. How can I fix this? I've tried both spline36 and lanczos3 for resizing the U and V, but it's still the same.

http://screenshotcomparison.com/comparison/81827

FFVideoSource("in.mkv")
Debilinear444(1280, 720)
DitherPost()

function Debilinear444( clip c, int "w", int "h", bool "lsb" )
{
    w = default( w, 1280 )
    h = default( h, 720 )
    lsb = default( lsb, true )
 
    deep = c.dither_convert_8_to_16()
 
    Y = deep.DebilinearY( w, h, lsb_inout = true )
 
    U = deep.UToY8()
    U = U.Dither_resize16( w, h, src_left = 0.25 )
 
    V = deep.VToY8()
    V = V.Dither_resize16( w, h, src_left = 0.25 )
 
    result = YToUV( U, V, Y )
    result = lsb ? result : result.DitherPost()
 
    return result
}

[colours]

The chroma channels end up being resized twice in your comparison; first with a spline36 kernel from 960×540 to 1280×720, then again with a bilinear kernel from 1280×720 to 1920×1080. The first step is fine, but the second one uses a blurry kernel, which is what causes the apparent desaturation.

… Probably. It's hard to tell if you don't provide a sample.

[bxyhxyh]

IT IS MISLEADING INFORMATION, DON'T DO IT

--colormatrix smpte170m would help. Or change colormatrix in your avisynth script.

Edit: Also I recommend you to using ConvertToY8().Dither_resize16(1280,720,kernel="bilinear",invks=true) instead of Debilinear for luma. It is faster and more compression friendly.

[awvnx]

The original image: http://a.pomf.se/yhsrmh.png

[bxyhxyh]

IT IS MISLEADING INFORMATION, DON'T DO IT

Every fansbubbers make same mistake as you. They don't correct colormatrix when they do YV24 rips (upscale chroma).

As I previously said add --colormatrix smpte170m in your x264 settings OR call Colormatrix("Rec.601->Rec.709",clamp=0) after source filter in your Avisynth script.
I don't know which one is better choice though.

[colours]

Originally Posted by bxyhxyh

Every fansbubbers make same mistake as you. They don't correct colormatrix when they do YV24 rips (upscale chroma).

Maybe the reason they don't "correct" the colour matrix is because it was never wrong to begin with?

Chroma sampling and colour matrices are entirely orthogonal concepts and there is no need to convert from 601 coefficients to 709 when upscaling the chroma because the source was 709 all along.

[turbojet]

Everything should see 1280x720 and 1920x1080 as 709 in his case --colormatrix bt709 might be worth it just to identify the colormatrix.

If awvnx was downscaling to lower resolutions colormatrix("Rec.709->Rec.601") would be the most compatible option but feel free to set --colormatrix smpte170m so it's known in the file. --colormatrix has very low compatibility so always best to convert the colormatrix if going between SD<>HD<>4K.

[awvnx]

So here's comparison of original to Debilinear444(1280,720).BilinearResize(1920,1080), where chroma upsampling in Debilinear was done spline36. It's pretty much identical.

http://screenshotcomparison.com/comparison/81936

Now, here's Debilinear444(1280,720).Spline36Resize(1920,1080). The chroma seems to sharpened and outlines are less red now. Makes sense, since we're basically comparing bilinear resizing to spline36 resizing.

http://screenshotcomparison.com/comparison/81937

So... it seems like there's no point in making a release with 720p 4:4:4 by using debilinear444? Because any player software will upsize with something sharper than bilinear, and cause this.

___
bxyhxyh, the BD reports BT.709 and this encode was done with --colormatrix bt709 --colorprim bt709 --transfer bt709
I assume when I use FFVideoSource to open it, it should be set correctly. But I can try to explicitly set it and see if it changes.
Should something be set in the script itself?

[bxyhxyh]

Just to be sure. Are their color same when you open with Media Player Classic?

#Source
spline36resize(1280,720)

#Source
debilinear444(1280,720)

If they are different, my second post can help you.
If they are same, I got your question wrong.

Edit: Please don't use MadVR

[Motenai Yoda]

as colours wrote 601->709 should be done only when upsampling from an sd source to an hd one and vice versa, chroma sampling has nothing to do with.

also I don't think Debilinear(1280, 720).BilinearResize(1920, 1080) is a good way to check if bilinear or that res were used. You should instead look at whether debilinear cause halos, alias or ringing.

btw 444 was wrong at the beginning, you assume it was upscaled by bilinear, so you rescale down luma only with debiliner, why not chroma too?

So... it seems like there's no point in making a release with 720p 4:4:4 by using debilinear444? Because any player software will upsize with something sharper than bilinear, and cause this.

actually most sw player use bilinear as default resize, but most tv's use a sharp one.

function Debilinear444( clip c, int "w", int "h", bool "lsb_in" , bool "lsb_out" )
{
    w = default( w, 1280 )
    h = default( h, 720 )
    lsb_in = default( lsb_in, true )
    lsb_out = default( lsb_out, lsb_in )
 
    deep = (lsb_in || !lsb_out) ? c : c.dither_convert_8_to_16()
 
    Y = deep.DebilinearY( w, h, lsb_inout = (lsb_in || lsb_out) ).
 
    U = deep.UToY8()
    U = (lsb_in || lsb_out) ? U.Dither_resize16( w, h, src_left = 0.25, kernel = "Spline64" ) : U.Spline64Resize( w, h, src_left = 0.25 )
    #maybe replace them with nnedi3_resize16 and nnedi3_rpow2 will be better.
 
    V = deep.VToY8()
    V = (lsb_in || lsb_out) ? V.Dither_resize16( w, h, src_left = 0.25, kernel = "Spline64" ) : V.Spline64Resize( w, h, src_left = 0.25 )
 
    result = YToUV( U, V, Y)

    return lsb_out ? result : result.DitherPost()
}

[bxyhxyh]

Have you guys noticed that upscaling chroma and downscaling luma leads to wrong color? (Wrong means it is little off compared to the source)
You can check it with any bluray you have. (Check your scripts by opening it with MPC or encode then watch it.)

It has nothing to do with what resizer you used for chroma.

So if calling colormatrix() is wrong, how should we correct it?

[colours]

Okay, so I went and made a 4:2:0 and a 4:4:4 encode for comparing, and you're right in that somehow the colours are different between the two encodes in MPC-HC with EVR.

That said, the colours do turn up identical on mpv, so it's just a playback issue. madVR probably also gets it right.

Originally Posted by Motenai Yoda

also I don't think Debilinear(1280, 720).BilinearResize(1920, 1080) is a good way to check if bilinear or that res were used. You should instead look at whether debilinear cause halos, alias or ringing.

I just want to say I totally agree with this.

Originally Posted by Motenai Yoda

btw 444 was wrong at the beginning, you assume it was upscaled by bilinear, so you rescale down luma only with debiliner, why not chroma too?

The assumption is that the "original master" was 1280×720 4:4:4 (or 4:2:2), where the luma is upscaled to 1920×1080 and the chroma is downscaled to 960×540.

[foxyshadis]

I wonder if it's because in the 444 case, the decoder is converting to RGB, whereas for 420 it passes NV12 to the renderer/driver. Try deselecting all YUV output from your decoder and see if that changes anything; if so, it's just another typical EVR/driver problem.

[Motenai Yoda]

Originally Posted by colours

Okay, so I went and made a 4:2:0 and a 4:4:4 encode for comparing, and you're right in that somehow the colours are different between the two encodes in MPC-HC with EVR.

for me no difference with mpc-hc+evr

Originally Posted by colours

The assumption is that the "original master" was 1280×720 4:4:4 (or 4:2:2), where the luma is upscaled to 1920×1080 and the chroma is downscaled to 960×540.

well the prodution guys have done everything, but I can also assume that they could have used bicubic or any lanczos/spline resizer, maybe into another csp like rgb xyY or wrgb too,then converted to YUV 444 and scaled chroma to 420.

also imo debilinear ignores high freqs and adds halo & grain (mainly coz 8bit source and bd bitrate aren't enough) too much.

[bxyhxyh]

FYI
Haali, and VMR7/9 have this color issue. 420 and 444 looks different
EVR, Sync, and madVR display all like Haali's 444.
VLC player's default renderer display all like Haali's 420.

[Sapo84]

If you're gonna encode the whole episode with debilinear make sure there's no parts with higher resolution.
Credits, episode titles, logos are usually drawn at full hd and looks fugly if resized with debilinear.
You should try to mask them, the difference is usually pretty visible (not masked masked).

[osgZach]

Originally Posted by Sapo84

If you're gonna encode the whole episode with debilinear make sure there's no parts with higher resolution.
Credits, episode titles, logos are usually drawn at full hd and looks fugly if resized with debilinear.
You should try to mask them, the difference is usually pretty visible (not masked masked).

..looks the same to me

[Bloax]

The text has a black (and white) halo around it in the unmasked example.