digitalFAQ.com Forum

digitalFAQ.com Forum (https://www.digitalfaq.com/forum/)
-   General Discussion (https://www.digitalfaq.com/forum/news/)
-   -   Is description of 4:1:1 subsampling in guides correct? (https://www.digitalfaq.com/forum/news/10670-description-411-subsampling.html)

mjb2019 05-26-2020 09:12 PM

Is description of 4:1:1 subsampling in guides correct?
 
From this site's Guide to Understanding Video Sources, Part 2 – Capturing Videotapes

Quote:

The compression rate of YUV is represented as Y:U:V in numbers. Some common ones:
4:4:4 = Uncompressed. Equal number of samples of Y, U and V.
4:2:2 = U and V are horizontally half of Y. Used for VHS/cable/broadcast, etc.
4:2:0 = U and V are both vertically and horizontally half of Y. Used for DVD MPEG and DVB.
4:1:1 = U and V are both vertically and horizontally one-quarter of Y. Used in NTSC consumer DV.
Based on another site's quite illustrative Chroma Subsampling Techniques explanations, I believe the description of 4:1:1 in our guide is incorrect. U and V are horizontally one-quarter of Y, but there is no loss in the vertical direction.

latreche34 05-26-2020 10:42 PM

No. they are not correct, Here is a better description:
https://en.wikipedia.org/wiki/Chroma_subsampling

Believe it or not 4:1:1 has twice the vertical chroma resolution of the 4:2:0 but half the horizontal chroma resolution of 4:2:0, But since more chroma resolution is needed horizontally than verticall 4:2:0 tend to look better than 4:1:1.

lordsmurf 05-26-2020 10:51 PM

What page was that on? It does need updates.

But the main point remains: 4:1:1 is one-fourth of color data, and half of the color data present on consumer analog formats like VHS. It throws away data when used for conversion.

The Wikipedia definitions are wonky and confusing, and ultimately misleading. RED is better.

mjb2019 05-27-2020 12:02 AM

Quote:

Originally Posted by lordsmurf (Post 69004)
What page was that on? It does need updates.

I linked to it in the first line of the original post.

latreche34 05-27-2020 01:46 AM

1 Attachment(s)
Think of it like this: 4:H:V where H is the number of chroma samples in a 4 horizontal luma pixels on a given scan line, and V is the total number of vertical changes of chroma in the 8 total pixels (from line one to line 2 in all 4 pixels).
4:2:2 has the same vertical chroma resolution of 4:1:1 and the same horizontal chroma resolution of 4:2:0, it has the best of both worlds. 4:4:4 simply means for each luma pixel there is a corresponding chroma pixel assigned to it.

Here is a better visualization of what I said:

http://www.digitalfaq.com/forum/atta...1&d=1590565056

mjb2019 05-27-2020 12:55 PM

Latreche34, your explanation conflicts with the one I linked to at red.com. You are showing the output chroma as having the same hue as the first of the sampled input pixels. Unless I'm mistaken, the RED site is saying the output is an average hue across the sampled range.

In other words, for 4:1:1, on each row, a set of 4 input chroma pixels (say, two red followed by two blue) is sampled to produce one output pixel (a four-wide purple); the output gets the average hue of the four input pixels, not the hue of just the first input pixel.

Which is correct?

latreche34 05-27-2020 02:59 PM

It's a convention there is nothing magic about it, They decided to gauge chroma that way as I explained it above, just like any other unit of measurement, for instance the foot, or the Mac for airplane speed. I haven't read your link but they must have gotten something wrong. The colors in the wiki picture are for presentations purposes, They have nothing to do with the chroma primary colors. That's where your confusion lies.

To answer your question about the sampled range, When the signal gets digitized I believe it takes the 4 pixels's average chroma value, It wouldn't be possible to measure a single pixel or 2 pixels otherwise it is considered 4:4:4 capable capture card which is not. But the sampling is time driven not pixel driven because the analog signal has no pixel structure it is just an infinite analog values up to the carrier frequency limit.

For the digital signal and imaging sensors it is a different story, we are only concerned about video capturing.

lordsmurf 05-27-2020 03:27 PM

Quote:

Originally Posted by latreche34 (Post 69009)
Here is a better visualization of what I said:

It's a misleading graph, because 4:2:0 is alternating. It is essentially 4:2:2, but across 2 frames. There is slight color reduction, but it's mild, not stark like 4:1:1.

scharfis_brain 05-27-2020 05:11 PM

In progressive domain 4:2:0 chroma subsampling might be okay.

But IMHO, 4:2:0 in interlaced domain is equally bad as 4:1:1.

This page explains 4:2:0 and interlacing quite well: http://www.mir.com/DMG/chroma.html

That's why I long ago argued for motion-adaptive 4:2:0 to 4:2:2 conversion, when interlacing is present:

http://rationalqm.us/autoyuy2/autoyuy2.html
https://forum.doom9.org/showthread.php?t=97987&page=1

Simply speaking: interlaced 4:2:0 messes up your chroma more than 4:1:1.

4:1:1 - especially for VHS - is more than sufficient.

VHS has 80 lines of chroma. 4:1:1 can offer 180 lines of chroma.
So the Nyquist-Shannon limit is overly satisified.

Upsampling 4:1:1 to 4:2:2 can easily done with some clever turnleft().nnedi3(dh=true).turnright() trickery.

Anyways I only work in 4:2:2 with interlaced video.
I convert to 4:2:0 *after* deinterlacing/upscaling.

latreche34 05-27-2020 08:27 PM

Indeed 4:2:0 is almost as bad as 4:1:1. I myself started to move away from 4:2:0. Usually after I encode and de-interlace I always downconvert to 4:2:0 but after doing few experiments on playback compatibility with files encoded at 4:2:2 I found out most devices play them back with no problems, and here is the kicker, the files are only about 15% bigger, So I don't see any reason for downconverting to 4:2:0 from now on.

I started a thread about this two weeks or so ago but no one seem to care I guess:
http://www.digitalfaq.com/forum/vide...ing-422-a.html

lordsmurf 05-28-2020 05:59 AM

Quote:

Originally Posted by scharfis_brain (Post 69036)
4:1:1 - especially for VHS - is more than sufficient.
VHS has 80 lines of chroma. 4:1:1 can offer 180 lines of chroma.
So the Nyquist-Shannon limit is overly satisified.

No. This is a "theory vs. practice" argument. The math is proven wrong, over and over again. The loss of color and detail is so drastic that even non-video laymen can see a difference. The colors are not just lost, but cooked (shade/tint changes, saturation/intensity change, etc).

Quote:

Originally Posted by latreche34 (Post 69038)
Indeed 4:2:0 is almost as bad as 4:1:1.

If by "almost" you mean "halfway between 4:2:2 and 4:1:1", then I agree.

However, due note that is strictly for NTSC. PAL is less obvious. (PAL users always liked to poke fun at NTSC, with "never the same colour" jokes, but PAL is no better. I'd even go one further, and suggest anybody that took the saying seriously never worked extensively with both formats. Each has equal numbers of warts.)

Quote:

I started a thread about this two weeks or so ago but no one seem to care I guess: http://www.digitalfaq.com/forum/vide...ing-422-a.html
I care. And replied. :)

scharfis_brain 05-28-2020 03:47 PM

2 Attachment(s)
Quote:

Originally Posted by lordsmurf (Post 69051)
No. This is a "theory vs. practice" argument. The math is proven wrong, over and over again. The loss of color and detail is so drastic that even non-video laymen can see a difference. The colors are not just lost, but cooked (shade/tint changes, saturation/intensity change, etc).

This simply is not true. The math is correct.

What you mean is: Lot's of implementations are incorrect!
Most chroma-upsamplers are doing it wrong by just
- doing a nearest neighbor chroma-upsampling, or
- doing wrong chroma placements and the like.

But from a practical perspective even YUV8:1:1 is sufficient for VHS, if using the correct upsamplers.

Have alook at my example image attached to this post.

- The left column shows wrong chroma upscaling: nearest neighbor scaling. It shows horrible staristepping
- The mid column shows linear upscaling: the stairstepping is highly reduced.
- The right colums shows nnedi3 upscaling: the stairstepping is almost gone. just some blurring in the horizontal domain remains.

Even 8:1:1 chroma using a decent upscaler (I used nnedi3) looks quite acceptable.

Thus - again - the math is not wrong here. It is the implementations.

In the past I recovered many NTSC DV-footage YUV411 to YUV422 using this approach.
Noone was able to tell that it was not YUV422 in the first place!

EDIT: I added a real-life example.

lordsmurf 05-28-2020 07:35 PM

I'm sure the math is correct. But the math isn't visual. What we see is most definitely a worse picture when capture as 4:1:1/DV. Again, cooked colors, lost color. So math be damned. Theory vs. practical application. What "should be" simply is not.

mjb2019 05-28-2020 08:20 PM

Quote:

Originally Posted by scharfis_brain (Post 69036)
This page explains 4:2:0 and interlacing quite well: http://www.mir.com/DMG/chroma.html

Getting back to my question, if anyone cares...

A reference on that page is http://www.adamwilt.com/pix-sampling.html which says The color sample is co-sited (located at the same place) as the first brightness sample in each 4-pixel group, and the color at that location is simply replicated over the following three pixels. Likewise, it is not hard to just Google and find more references that say each chroma sample is based on just the first pixel's color, e.g. http://www.jayandwanda.com/DigitalSampling.html which shows that a particular software DV codec seems to implement 4:1:1 in exactly that way!

But then, like the RED site, there are others that say that no, subsampling has the effect of averaging the color across the pixels, e.g. http://www.dvxuser.com/articles/colorspace/ which also used a software codec to prove this point, and the notation reference https://poynton.ca/PDFs/Chroma_subsampling_notation.pdf agrees with this as well.

So it seems to me that the mechanism of subsampling varies by implementation. I do not know what happens in my Sony DV camera, but I am guessing it is more likely to be averaging.

Regardless, how would be best to address this in the guide I asked about?

scharfis_brain 05-29-2020 02:15 AM

1 Attachment(s)
I agree, that the kind of sampling (nearest neighbor / average) is dependant on the implementation.
I think the best would be, to mention both kinds of sampling in the guide.

http://www.adamwilt.com/pix-sampling.html
shows correctly how sampling is done.
But it also shows, how chroma is being upsampled incorrectly.

http://www.jayandwanda.com/DigitalSampling.html
Somehow these explanations simply feel wrong, because 4:1:1 and 4:2:2 simply do not have a vertical component.

Anyways the whole concept, that a single chroma sample value in 4:1:1 / 4:2:0 strictly is copied over four luma samples is wrong.
Sampling theory tells that you need filtering to upsample subsampled chroma. (Generally speaking this counts for ANY kind of continuous signal)

If done correctly the losses aren't apperant as the linked guides might suggest:

http://www.digitalfaq.com/forum/atta...1&d=1590736410

lordsmurf 05-29-2020 02:38 AM

Quote:

Originally Posted by mjb2019 (Post 69064)
subsampling varies by implementation.

Astute observation. All DV codecs suck.

Quote:

Originally Posted by scharfis_brain (Post 69078)
http://www.adamwilt.com/pix-sampling.html
shows correctly how sampling is done.
But it also shows, how chroma is being upsampled incorrectly.

Adam Wilt was about shooting DV, back in the 90s, not using it as a conversion format. And converting VHS is not shooting DV. Conversion takes already-degraded 4:2:2(ish) color, and degrades it more. Cameras take 4:4:4 real life, and compress it down.

And your above images are mostly about resizing, not the data loss from DV conversions.

Quote:

Sampling theory tells that you need filtering to upsample subsampled chroma.
... but it's still upsampling, aka creating data by algorithm guessing. The source data is gone. Sure, some guess better. But the data is gone. I can't say that enough. DV takes data, throws it out. It's gone. No amount of upsampling, no method of upsampling, can undo that.

DV throws out data from that 4:2:2(ish) consumer analog source, which now has noticeable damage, and is therefore bad. The end.

DV has not just color compression, but blocks, and other noises.

Technically 4:2:0 throws data out, but the loss is less perceived, therefore not terrible. Thus why it was chosen for DVD, BD, broadcast, and streaming specs.

scharfis_brain 05-29-2020 03:03 AM

Quote:

Originally Posted by lordsmurf (Post 69079)
Thus why it was chosen for DVD, BD, broadcast, and streaming specs.

interlaced YUV4:2:0 is really horrible unless we upsample it with "algorithm guessing" (like you name it) to YUV4:2:2 / YUV4:4:4.

YUV4:2:0 has been chosen in the past, because analogue distribution over formats like PAL and SECAM had conceiled the vertical chroma issues due to their delay lines.

Even most new-ish TVs do NOT properly upsample interlaced YUV4:2:0. I can see lot's of chroma interlacing or vertical chroma smearing artifacts, that could have been avoided using proper "algorithm guessing".

lordsmurf 05-29-2020 03:55 AM

Quote:

Originally Posted by scharfis_brain (Post 69080)
interlaced YUV4:2:0 is really horrible unless we upsample it with "algorithm guessing" (like you name it) to YUV4:2:2 / YUV4:4:4.

YUV4:2:0 has been chosen in the past, because analogue distribution over formats like PAL and SECAM had conceiled the vertical chroma issues due to their delay lines.

Even most new-ish TVs do NOT properly upsample interlaced YUV4:2:0. I can see lot's of chroma interlacing or vertical chroma smearing artifacts, that could have been avoided using proper "algorithm guessing".

And I don't really disagree with any of that. :)

Scaling is important.
And quality of the scaler matters.
And noting the limitations of scaling.


All times are GMT -5. The time now is 10:05 AM

Site design, images and content © 2002-2026 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2026 Jelsoft Enterprises Ltd.