Post subject: Can I keep pixel perfect quality on Y′UV, YUV, YCbCr, etc?
Sonia
She/Her
Joined: 12/6/2013
Posts: 435
Location: Brazil
Unless if I'm missing something, I noticed that pixel perfect lossless quality is only kept on the RGB color space format. Below is a side by side comparison (all recorded with Lagarith, then I took pics of the videos): Is it possible to make it so the pixels will look lossless perfect on Y′UV, YUV, YCbCr, YPbPr, etc as well?
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Try doubling the resolution:
Language: Avisynth

AVISource("video.avi") PointResize(Width * 2, Height * 2)
Afaik only YV24 and RGB have pixel-perfect colors at native resolution.
Pokota
He/Him
Joined: 2/5/2014
Posts: 778
YUV444 (YV24) and RGB have pixel-perfect colors at native resolution because they're not discarding any of the color information in favor of compression. You need to upscale at least 2x (and to an even number, preferably to a power of 2) to keep color information from bleeding around with yuv420, because of how it compresses the color information. For best result, please use point resize (nearest neighbor). I can't remember how to cheat with the other yuv schemes, but presumably integer upscaling would work for them as well.
Adventures in Lua When did I get a vest?
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Pokota wrote:
integer upscaling would work for them as well
Width * 3 would still result in chroma subsampling.
Pokota
He/Him
Joined: 2/5/2014
Posts: 778
ah, right, odd numbers would recreate the subsampling issue. I've amended my post accordingly.
Adventures in Lua When did I get a vest?
Publisher
Joined: 4/23/2009
Posts: 1283
This is why our download encodes on the site are in YV24 colorspace.
Publisher
Joined: 4/23/2009
Posts: 1283
creaothceann wrote:
Try doubling the resolution:
Language: Avisynth

AVISource("video.avi") PointResize(Width * 2, Height * 2)
Afaik only YV24 and RGB have pixel-perfect colors at native resolution.
Just doubling wouldn't work as most colospace conversion when discarding the color info is using a scaler other than point resize. The correct way is to convert is to make sure the chroma scaler is using point resize. Like so:
Language: Avisynth

ConvertToYV12(chromaresample="point")
To add onto this, unless the later AviSynth version fixed this, the param "chromaresample" would be ignored if the source isn't already in YUV, so the real way is doing like this:
Language: Avisynth

ConvertToYV24(chromaresample="point") ConvertToYV12(chromaresample="point")
Last minor point is there are color conversion matrix for different resolutions. For native console resolutions, it is mostly BT.601.
Sonia
She/Her
Joined: 12/6/2013
Posts: 435
Location: Brazil
@Pokota Does it need to be only to the power of 2 or can I simply use any even number? I'm asking this because I work with 6x and 10x sometimes too.
Publisher
Joined: 4/23/2009
Posts: 1283
Sonia wrote:
@Pokota Does it need to be only to the power of 2 or can I simply use any even number? I'm asking this because I work with 6x and 10x sometimes too.
Any even number for YV12 and YUY2.
Pokota
He/Him
Joined: 2/5/2014
Posts: 778
While it can be any even number for YV12 and YUV2, powers of 2 compress better. Saves bandwidth.
Adventures in Lua When did I get a vest?
Sonia
She/Her
Joined: 12/6/2013
Posts: 435
Location: Brazil
Okay, thanks. One more thing: is there a way to do "ConvertToYV12(chromaresample="point")" through virtualdub's filters? I have avisynth installed, but I prefer to use virtualdub alone if possible. I know how to point resize the video's resolution on "filters = resize (nearest neighbor)" but how can I resize the chroma?
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
BTW, 8x results in the second smallest file size after 2x. http://tasvideos.org/forum/viewtopic.php?p=340280#340280
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 10/14/2013
Posts: 335
Location: Australia
Sonia wrote:
...is there a way to do "ConvertToYV12(chromaresample="point")" through virtualdub's filters? I have avisynth installed, but I prefer to use virtualdub alone if possible. I know how to point resize the video's resolution on "filters = resize (nearest neighbor)" but how can I resize the chroma?
If you're working exclusively in Virtualdub, nearest neighbor resize is all you need to do, followed by convert format to your desired colorspace. It should give the same result as doing a point resize followed by ConvertToYV12 (or whatever colorspace you're after). Resizing the resolution also resizes the luma (brightness) and chroma (color) components. The problem with YV12 and YUY2 is that they're chroma subsampled. YV12 is set at 4:2:0 and YUY2 is set at 4:2:2 if I'm not mistaken. These exist for a variety of purposes, but do not really cater to pixel-oriented game videos. The issue is that in the case of 4:2:0, this means that there is only one chroma (or color) pixel for every 2x2 block of luma resolution, as shown in the picture above. This is why the black pixels in your examples remain unblurred, whilst color starts to spill into other pixels and is also why a resize with a factor of 2 solves this problem. So assuming you have a video in RGB to begin with, you resize with a factor of 2 using point size or nearest neighbor. The point of this is to double (or quadrouple, etc) each pixel both horizontally and vertically, making each 2x2 block contain four identical pixels. This means that when the chroma is compressed down to represent the 2x2 block, no data is discarded and then no blurring/blending occurs. Hopefully that helps you understand the situation more thoroughly. I darted around your question a bit, but the problem itself doesn't require you to resize the resolution and then the luma separately - they're linked. The luma is the brightness and the chroma is the color data and in a 4:4:4 colorspace (or in RGB) each pixel has it's own unique values.
I'm not as active as I once was, but I can be reached here if I should be needed.
Publisher
Joined: 4/23/2009
Posts: 1283
thecoreyburton wrote:
So assuming you have a video in RGB to begin with, you resize with a factor of 2 using point size or nearest neighbor. The point of this is to double (or quadrouple, etc) each pixel both horizontally and vertically, making each 2x2 block contain four identical pixels. This means that when the chroma is compressed down to represent the 2x2 block, no data is discarded and then no blurring/blending occurs.
This doesn't work because when you convert to YV12, the downsampling of the chroma is not done by point usually. Bilinear (I think?) and Bicubical looks more than the 2x2 block. That means the color sample might have a hint of the surrounding color with it.
Joined: 10/14/2013
Posts: 335
Location: Australia
Aktan wrote:
This doesn't work because when you convert to YV12, the downsampling of the chroma is not done by point usually. Bilinear (I think?) and Bicubical looks more than the 2x2 block. That means the color sample might have a hint of the sounding color with it.
Ah, I didn't know that. That actually explains a lot. Disregard any misinformation in my post above, Sonia. :)
I'm not as active as I once was, but I can be reached here if I should be needed.
Publisher
Joined: 4/23/2009
Posts: 1283
To make matters worse, when you convert back to RGB as most displays are or YUV4:4:4, the upscaling of the chroma is probably not using point resize either, adding some color bleeding also...
Sonia
She/Her
Joined: 12/6/2013
Posts: 435
Location: Brazil
Thank you, guys. I will keep all of this in mind. ^^
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Aktan wrote:
To make matters worse, when you convert back to RGB as most displays are or YUV4:4:4, the upscaling of the chroma is probably not using point resize either, adding some color bleeding also...
This is the real killer for 4:2:0. It doesn't matter how smart you are when encoding; the playback software is going to stomp over that and make film-based assumptions about how to filter the chroma.
Pokota
He/Him
Joined: 2/5/2014
Posts: 778
While on the subject; Link to video My typical editing/encoding process has me using point resize in avisynth, passing it as RGB32 to ffmpeg, and having ffmpeg encode it x264 yuv420. How much color fidelity am I losing by pushing that onto ffmpeg instead of doing this directly in avisynth?
Adventures in Lua When did I get a vest?
Publisher
Joined: 4/23/2009
Posts: 1283
Honestly, since you already point resized upscale, not much. There will be slight color bleeding, but not enough for anyone to really notice at 1080p since the original resolution was so small. Edit: I just like to really do the best I can to reduce that amount, hence the lines I posted earlier.
Pokota
He/Him
Joined: 2/5/2014
Posts: 778
So the larger the original footage, the more color bleeding there will be. Well, that's fair I guess. (I normally do 720p instead of 1080p, but GBx footage doesn't 2x scale to 720p)
Adventures in Lua When did I get a vest?
Publisher
Joined: 4/23/2009
Posts: 1283
Pokota wrote:
So the larger the original footage, the more color bleeding there will be. Well, that's fair I guess. (I normally do 720p instead of 1080p, but GBx footage doesn't 2x scale to 720p)
You must also remember, the larger the source, the less pixelated it is in general also, so less likely to also have color lines.