Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 2nd July 2014, 15:38   #1  |  Link
awvnx
Registered User
 
Join Date: Jun 2014
Posts: 4
Debilinear444

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

Code:
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
}
awvnx is offline   Reply With Quote
Old 2nd July 2014, 16:14   #2  |  Link
colours
Registered User
 
colours's Avatar
 
Join Date: Mar 2014
Posts: 308
The chroma channels end up being resized twice in your comparison; first with a spline36 kernel from 960540 to 1280720, then again with a bilinear kernel from 1280720 to 19201080. 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.
colours is offline   Reply With Quote
Old 2nd July 2014, 17:13   #3  |  Link
bxyhxyh
Registered User
 
Join Date: Dec 2011
Posts: 354
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.

Last edited by bxyhxyh; 6th July 2014 at 12:52.
bxyhxyh is offline   Reply With Quote
Old 2nd July 2014, 21:16   #4  |  Link
awvnx
Registered User
 
Join Date: Jun 2014
Posts: 4
The original image: http://a.pomf.se/yhsrmh.png
awvnx is offline   Reply With Quote
Old 3rd July 2014, 07:09   #5  |  Link
bxyhxyh
Registered User
 
Join Date: Dec 2011
Posts: 354
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.

Last edited by bxyhxyh; 6th July 2014 at 12:52.
bxyhxyh is offline   Reply With Quote
Old 3rd July 2014, 07:27   #6  |  Link
colours
Registered User
 
colours's Avatar
 
Join Date: Mar 2014
Posts: 308
Quote:
Originally Posted by bxyhxyh View Post
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.
colours is offline   Reply With Quote
Old 3rd July 2014, 07:59   #7  |  Link
turbojet
Registered User
 
Join Date: May 2008
Posts: 1,840
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.
__________________
PC: FX-8320 GTS250 HTPC: G1610 GTX650
PotPlayer/MPC-BE LAVFilters MadVR-Bicubic75AR/Lanczos4AR/Lanczos4AR LumaSharpen -Strength0.9-Pattern3-Clamp0.1-OffsetBias2.0
turbojet is offline   Reply With Quote
Old 3rd July 2014, 08:29   #8  |  Link
awvnx
Registered User
 
Join Date: Jun 2014
Posts: 4
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?

Last edited by awvnx; 3rd July 2014 at 09:13.
awvnx is offline   Reply With Quote
Old 3rd July 2014, 11:51   #9  |  Link
bxyhxyh
Registered User
 
Join Date: Dec 2011
Posts: 354
Just to be sure. Are their color same when you open with Media Player Classic?
Code:
#Source
spline36resize(1280,720)
Code:
#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

Last edited by bxyhxyh; 3rd July 2014 at 15:52.
bxyhxyh is offline   Reply With Quote
Old 3rd July 2014, 16:34   #10  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 709
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?

Quote:
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.

Code:
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()
}
__________________
powered by Google Translator

Last edited by Motenai Yoda; 3rd July 2014 at 16:38.
Motenai Yoda is offline   Reply With Quote
Old 3rd July 2014, 17:30   #11  |  Link
bxyhxyh
Registered User
 
Join Date: Dec 2011
Posts: 354
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?

Last edited by bxyhxyh; 3rd July 2014 at 17:39.
bxyhxyh is offline   Reply With Quote
Old 3rd July 2014, 18:40   #12  |  Link
colours
Registered User
 
colours's Avatar
 
Join Date: Mar 2014
Posts: 308
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.

Quote:
Originally Posted by Motenai Yoda View Post
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.

Quote:
Originally Posted by Motenai Yoda View Post
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 1280720 4:4:4 (or 4:2:2), where the luma is upscaled to 19201080 and the chroma is downscaled to 960540.
colours is offline   Reply With Quote
Old 3rd July 2014, 23:22   #13  |  Link
foxyshadis
Angel of Night
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
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.
foxyshadis is offline   Reply With Quote
Old 4th July 2014, 01:37   #14  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 709
Quote:
Originally Posted by colours View Post
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

Quote:
Originally Posted by colours View Post
The assumption is that the "original master" was 1280720 4:4:4 (or 4:2:2), where the luma is upscaled to 19201080 and the chroma is downscaled to 960540.
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.
__________________
powered by Google Translator
Motenai Yoda is offline   Reply With Quote
Old 4th July 2014, 07:06   #15  |  Link
bxyhxyh
Registered User
 
Join Date: Dec 2011
Posts: 354
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.
bxyhxyh is offline   Reply With Quote
Old 4th July 2014, 13:58   #16  |  Link
Sapo84
Registered User
 
Join Date: May 2008
Posts: 40
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).
Sapo84 is offline   Reply With Quote
Old 4th July 2014, 17:05   #17  |  Link
osgZach
Registered User
 
Join Date: Feb 2009
Location: USA
Posts: 676
Quote:
Originally Posted by Sapo84 View Post
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
osgZach is offline   Reply With Quote
Old 4th July 2014, 18:03   #18  |  Link
Bloax
The speed of stupid
 
Bloax's Avatar
 
Join Date: Sep 2011
Posts: 317
The text has a black (and white) halo around it in the unmasked example.
Bloax is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:51.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.