Talk:Chroma subsampling

Old stuff not previously in a section

Glad for the info. Yes, Chroma formats should be merged with Chroma subsampling. The formats by themselves don't mean much without some explanation of how subsampling occurs.

Great article - seems to be the only resource on the web that handles this topic. But I have a problem. Look at the picture on the left, wouldn't you say that the 4:2:0 picture is wrong? We're talking about horizontal lines. 4:2:0 switches the U and V component every uneven line. so i would say (from logic), there should be a long blue line. and then (in the next line) a long red line. --Abdull 14:19, 23 Mar 2005 (UTC)

Nope, i take back the previous statement. As i thik i figured out correctly, one of the reddish or blueish block represents something like "needed area that is covered with full information". Right? Maybe the blueish and reddish rectangles can be explained? --Abdull 14:25, 23 Mar 2005 (UTC)

I'm actually very curious about your diagram as well. I read it as follows: blue squares represent pixels with luma samples, while red squares represent pixels with both luma and chroma samples associated. This makes sense to me of the 4:1:1 diagram, which looks like every other chroma/luma sampling diagram for 4:1:1 subsampling I have ever seen. Things start to get tricky for me, though, when I get to, for example, the 4:4:4 diagram, which, if I am reading this correctly, I know to be false. Video sampled in a 4:4:4 Y:Cb:Cr ratio should have an equal signal bandwidth for each channel, and thus should have a chroma sample in both Cb and Cr channels for every pixel, right? (Typically, I have seen chroma samples treated as though there is complete overlap between pixels defined in Cb and Cr channels, although I am aware that in DVCPROHD and perhaps other examples this is not true). At any rate, I have always seen 4:4:4 video implied to be one chroma sample for every luma sample per channel, and thus would expect your diagram for this sampling pattern to be entirely red or blue. Looking further at the diagram, my reading of it would also seem to suggest that all these different chroma sampling patterns contain the same relative amount of information in luma and chroma channels. This contradicts both everything I have ever read on the subject and also the statement you make about 4:2:2 requiring less bandwidth than 4:4:4. It is possible that A) my knowledge of codec construction is deeply flawed, and/or that B) I have no idea how to read the diagram. In either case, I would greatly appreciate a caption on the diagram explaining how it should be read as I appear to not be the only one confused by it. -Evan (06/04/07)

Also I had a tough time wading through this page to get a sense for the talk; a lot of it centers around, well, what the first heading says, so I moved everything that was originally its own separate heading that really was about that to this category, and bolded the old category separators. I hope no one is offended; I simply wanted to make this easier to read. I have seen 22:11:11 (about HD sampling) and 8:8:8 (in regards to a DaVinci setup, too) mentioned before, just to throw my two cents in on that topic. Probably the right answer is in there somewhere. -Evan (06/04/07)

Discussion about the numbers > 4 in sampling ratios and thus meaning of the a:b:c notation

contradictory information in the same page? In "Sampling systems and ratios" it says that "This notation is not valid for all combinations and has exceptions, e.g. 4:1:0 (where the height of the region is not 2 pixels, but 4 pixels, so if 8 bits per component are used, the media would be 9 bits per pixel)," but later in the page it says that 4:1:0 is possible and has a whole section explaining it. From the first statement, I don't understand what is said about the region being 4 pixels tall. Why is that? — Preceding unsigned comment added by Julovi (talk • contribs) 00:09, 10 February 2023 (UTC)

what do the numbers actually mean?

You seem to treat the groups of numbers as simply identifiers with no intrinsic meaning. I find it unlikely that this would be the case. does anyone know what the individual numbers actually mean? Plugwash 17:37, 8 Apr 2005 (UTC)

Here is your answer: http://www.quantel.com/domisphere/infopool.nsf/HTML/6CE9156EC8F04A5280256C7D00529E43?Open --Dulldull 17:48, 10 May 2005 (UTC)

I can't see any information on the individual numbers there. Plugwash 12:48, 23 May 2005 (UTC)

I just noticed someone had filled it in here since i last checked.

Reply/Note:

The above link is is gone. Best way to think of what the numbers means is that the 4 is the standard luminance resolution for the system you are talking about. The 4 is different for SDTV-(NTSC/PAL) than HTDV. In NTSC/PAL CCIR 601 digital video there are 720 luminance samples per line, this equals the 4 in 4:2:2. There are 360 chrominance samples per line, this is the 2, in 4:2:2.Telecine Guy 3/8/07

a:b:c notation - gone?

• This article appears to contradict itself about the third field in a:b:c notation. Please see the discussion on the talk page.

• It looks like this has been deleted from Chroma subsampling and the contradict should be moved. My guess this was a topic about MPEG encoding. Anyone agree?

—The preceding unsigned comment was added by Telecineguy (talk • contribs) 23:15, 20 February 2007 (UTC).

8:8:8

• Where should 8:8:8 go?

• Reply:

The only 8:8:8 systems I have seen is when 8:4:4 or 4:4:4 or 4:2:2 is sub pixel up sampled to 8:8:8. This is done for finer resolution in color correcting a video signal. I have only seen this done inside a DaVinci 8:8:8 SDTV Color Corrector that would still output 4:4:4 or 4:2:2. A common problem is video is when a video operator has the wrong settings, that is you cannot mix Chroma subsampling formats. 4:4:4 must feed 4:4:4, 4:2:2 must feed 4:2:2. A up (or down) converter must be used to go from one format to the other, other wise sampling errors will occur (usually lines in the video). As such I am not sure 8:8:8 needs to be added to the main page as a heading. Do you have another example of 8:8:8?

4:2:0 and 4:1:0 sampling The provided information is not correct. The numbers in x:y:z don't indicate which horizontal lines contain which chroma samples.

4:2:0 does not mean that there is no V or Cr information stored at all, it means that in each line, only one color difference channel is stored with half the horizontal resolution. The channel which is stored flips each line, so the ratio is 4:2:0 for one line, 4:0:2 in the next, then 4:2:0 again, and so on. This leads to half the horizontal as well as half the vertical resolution, giving a quarter of the color resolution overall.

So, this is not totally true. There are three types of 4:2:0 sampling: MPEG-1 (U and V have same placement between two vertical luma pixels) MPEG-2 (U and V have same placement between 2x2 luma pixels) and PAL DV (U and V alternating, just as you described above):

4:1:0 sampling means that chroma is shared between 4x4 luma pixels (and not 2:4). So it's 18 bytes for 16 pixels, or 9 bits per pixel. Indeo uses such sampling.

http://www.avisynth.org/Sampling (plus references in this article) (Section References in that page has a link "4:2:0" taking you to a page that states the sampling in 4:2:0 effectively happens between every other line: http://www.quantel.com/domisphere/infopool.nsf/HTML/dfb420?OpenDocument)

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/YUVFormats.asp http://www.fourcc.org/fccyuv.htm#Planar%20YUV%20Formats (YUV9 is 4:1:0 sampling)

Btw, i don't understand the exact naming convention x:y:z either :) But, here are some random thoughts about it: http://forum.doom9.org/showthread.php?t=87991 131.155.54.18 15:02, 17 October 2005 (UTC)

I'd always heard that the numbers were: first the (relative) number of luminance samples, then chrominance (both U and V) on even scan lines, then chrominance on odd scan lines. But I was dealing with planar image file formats and therefore didn't need to pay attention to the question of whether all the chrominance was really on half the scan lines, or if U and V were alternately represented, etc.

I suspect that the numbers started out as something like this, then got applied traditionally with some vagueness to anything with essentially the same spatial resolutions in the channels. There's some regularity to the format designations but I wouldn't be surprised to hear that it's a little loose. -66.31.108.41 02:02, 23 March 2006 (UTC)

Origins of J:a:b notation Originally, the first number meant that luma was sampled 4 times the frequency of the color subcarrier (4fsc). The two numbers following referred to the sampling frequency of the Cb and Cr components. (may be wrong) However, when SD was standardized, they changed the sampling rates for better NTSC and PAL interchange. So while 4fsc is 14.3 MHz for NTSC and 17.7 MHz for PAL, for SD the luma sampling is 13.5 Mhz.

With subsequent high definition formats, engineers didn't want to go with higher numbers and liked the 4:x:x scheme (and 4fsc became meaningless anyways). So 4:x:x now refers to chroma subsampling scheme used.

(may be wrong) In my opinion, the whole notation is not a good idea since some of the numberings are ambiguous... notably 4:2:0 and 4:4:4.

Re. HD formats - 22:11:11 is sometimes used instead of 4:2:2. 82.127.93.74 11:22, 19 January 2007 (UTC)

4:4:4 Y'CbCr This is the best color sampling ratio (it yields a nearly perfect representation of each pixel's color), and is used as an intermediate format in high-end film scanners and cinematic postproduction. We could explain why the representation is imperfect... when converting from R'G'B' to Y'CbCr, you tend to incur quantization error.

The subjective comment about it being the best isn't necessarily true.

This is not true! If you keep R'G'B' then you have to use worse quantization level on each R', G', B' component to make them fit in the limited bandwidth. When you use Y'CbCr, you can use better quantization for Y', which is what your eye will firt detect, including for movement (where your eye is very accurate at detecting very small differences in luminance!).

Remember that quantization happens always in the compression of images in MPEG, and every channel is affected by quantization. With Y'CbCr, the impact is of quantization can be made much less severe on luma than on chroma, and finally you get a better perceived quality once the image is decompressed!

If you are not convinced, look at static high quality JPEG images (Q=100, i.e. 9 bits per color pixel) : those compressed within the Y'CbCr or YUV color models are definitely more crispy than with the sRGB with the same bitrate (or filesize). This is very visible when you look at textured areas of images, or at the borders of contrasted diagonals. Using Y'CbCr really enhanced the final resolution of the image with no extra cost in terms of final

The cost of the color space transformation is only in chroma, but the eye is not perceiving chromatic differences as well as in luminance (especially in textured areas like fields of herbs, stones, walls, characters hair and dressing), or when looking at very smoothed areas (like clouds in a natural sky, or at waves on the sea).

If you have a (8,8,8)-bit sRGB image, converting it to a (14,5,5)-bit Y'CbCr color space is almost lossless for the eye (and if you take a mathematical measure of the error when performing the conversion back to sRGB, the SNR is extremely high (much more than what your eye can perceive), but it compresses much better ; almost all of the loss in image compression does not come from this conversion. 90.5.134.25 17:19, 18 February 2007 (UTC)

8:4:4

This is really just 4:2:2 subsampling right? I was under the impression that the first number lost its meaning a long time ago, and now all that matters is the ratios. --Ray andrew 01:54, 9 March 2007 (UTC)

Reply: In NTSC/PAL digital video there are normally 720 luminance samples per line, this equals the 4 in 4:2:2. There are 360 chrominance samples per line, this is the 2, in 4:2:2. So in 8:4:4 there are 1440 luminance samples per line and 720 chrominance samples per line. This gives twice the resolution for luminance. The ratios 8 is twice 4, makes 8:4:4 a high end system, this is not subsampling, but true high res. Calling 8:4:4 the same ratio as 4:2:2 will not work as few devices can handle 1440 luminance samples per line. 8:8:8 noted above is subsampling depending on the input. 8:4:4 upped to 8:8:8 is subsampled only in chrominance. See CCIR 601 for more info on 4:2:2 video. When connecting devices together it is important to have the same samples per line on the output to input. Other wise sampling errors will occur, this can show up as faint lines top to bottom in the video. Telecine Guy

I've never heard of 8:4:4 before (i.e. it doesn't appear in manufacturer literature, it doesn't appear in Charles Poynton's book or other video engineering books, etc.). Is there a source to back this up? 74.102.238.157 08:40, 21 April 2007 (UTC)

It is mostly used by The Spirit DataCine and Da Vinci Systems' 888 and 2k color correctors. Telecine Guy 09:56, 22 April 2007 (UTC)

YUV Notation should really be avoided!

YUV refers to an analog encoding scheme, whereas this article really talks about Y'CbCr (digital). One difference is that the scale factors on the U and V are different than those on Cb and Cr.

Similarly, Y' does not directly represent the luminance from color science.

See http://poynton.com/papers/YUV_and_luminance_harmful.html

While I'm not aware of the difference between YUV and Y'CBCr myself (though I've certainly heard both used) it should be noted that the term YUV is very widely used in digital video texts/papers etc. Even if they do do so incorrectly. So even if the article is changed that miusage should be noted. AlyM 15:51, 6 July 2006 (UTC)

The Chroma Bug

The chroma bug is a problem related to the misinterpretation of chroma subsampling (since it interacts with interlacing).

see http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html

Terminology

Note that the luma (Y') of video engineering deviates from the luminance (Y) of color science (as defined by CIE). Luma is formed as the weighted sum of gamma-corrected (tristimulus) RGB components. Luminance is formed as a weighed sum of linear (tristimulus) RGB components.

In practice, the CIE symbol Y is often incorrectly used to denote luma. In 1993, SMPTE adopted Engineering Guideline EG 28, clarifying the two terms. The luma of video engineering is to be denoted by the symbol Y', whereas the luminance of color science is to be denoted by the symbol Y. Note that the prime symbol ' is used to indicate gamma correction. In current practice, the symbol Y is ofter used to refer to the luma of video engineering and not the luminance of color science. The exact intention has to be discerned from the context of the term's usage.

Similarly, the chroma/chrominance of video engineering differs from the chrominance of color science.

• This is mostly derived from Charles Poynton's writings

[[1]] Glennchan 22:44, 13 July 2006 (UTC)

Major Changes

I went ahead and made some fairly major changes to correct technical inaccuracies. My intention was not to step on anyone's toes.

To do:

• I propose getting rid of the bitstream stuff - to me, it's too obvious
• Good diagrams showing the schemes and where the chroma samples are taken from
• Add article on chroma bug, link to it
• Correct inaccuracies in the luminance (video), YIQ, YUV articles; then link to them
• Perhaps add information on chroma interpolation and reconstruction
• Perhaps add information on chroma filtering

Glennchan 06:48, 14 July 2006 (UTC)

Confusing

I felt the presentation is a bit confusing as it tries to make a correspondance between the bitstream and the sampling format. The bitstream structure can be discussed separately. The book Video Demystified by Keith Jack, provides a good explanation of chroma subsampling and the corresponding chapters of the book are freely available at http://books.elsevier.com/bookscat/samples/1878707566/1878707566.pdf

Yeah I think it should be changed... although I really gutted the article already. :D I have no idea how the bitstream stuff is relevant to most people reading wikipedia... and as you point out its confusing / not organized. Perhaps push it into its own section, or remove it entirely.Glennchan 02:55, 20 July 2006 (UTC)

Digital component video

Hey, I think we should try to be more specific when we talk about what formats using what. What exactly does "digital component video" refer? To me, it is an umbrella term for the various digital video formats that use chroma subsampling- which could be any one of the many schemes available. (Skimming through Charles Poyntons book, digital component video interface seems to typically refer to SDI) Perhaps we should include HDMI on there, although I don't know too much about it. HDMI seems to support 4:2:2, 4:4:4, and the colorspaces Y'CbCr R'G'B' and xvYCC, and different bit depths. Glennchan 19:59, 7 December 2006 (UTC)

Adding contradiction tag

The "Sampling systems and ratios" section claims that the third component of the ratio is always either equal to the second, or zero. Nonetheless, the article also contains a (brief) section discussing 4:2:1. If 4:2:1 really exists, then the "Sampling systems and ratios" section can't be right.216.59.230.140 01:35, 2 February 2007 (UTC)

This is not really a contradiction. It forgets to describe the 4:2:1 case, which is extremely rare (not used in standard video, because the target viewing device will not be able to reproduce such detail in interlaced mode; this can only be viewed on a progressive-scan computer screen). Such notation means that one of the two chroma channels has a doubled bandwidth. It means that the chroma channels are not symetric.

It can't be one of the standard CIE colorspaces, but it could be used for example in HSV or HSL colorspaces:

• V, the value, or L, the light, encodes the luma information on every pixel of a 2x2 macro-block
• H and S encode the chroma, but the eye is more sensitive to H, the hue, and to S, the saturation so:
• you can give twice more bandwidth to H than to S.
• This is a minor improvement that helps giving more color
• Such transform is very computational-intensive, notably because it involves gamma-correction which requires a much higher precision for the intermediate results; for HDTV (which requires very high pixel frequency) the cost would be too high (and it would not work on mobile devices due to excessive power dissipation, too many transistors or gates, and too much capacitance per bit, also because such transform requires ROM-lookup that are extremely energy-expensive, or require adding DRAM or registers for caching such data; it also requires generic ALU, instead of simpler static multipliers that aer hardware efficient).

For all these reasons, the 4:2:1 subsampling type is reserved to software-only implementation, and its performance is poor (it can't cope now with HDTV signals); there are some cameras that use it, but they all suffer from the cost and heavy weight of their batteries, and their autonomy is poor...

Really, forget 4:2:1, and use 4:2:0 with which you can much more easily increase the resolution to compensate for the fact that chroma information is subsampled in alternating frames. 90.5.134.25 17:39, 18 February 2007 (UTC)

Macropixel

The word "macropixel" is not defined, but used. Though I can imagine what it means, it's still unclear for me if "each macropixel of two neighbouring pixels uses 4 bytes of memory" means that for the whole frame the average memory per pixel is 2 or 4 bytes. I guess 4. Macfreek 15:29, 17 December 2005 (UTC)

a:b:c notation

I don't understand, even after reading the article, what 4:2:1 exactly does. How would 4:2:1 look in the image on the left?

I don't understand the reason for this notation. Why don't they give the factors of horizontal and vertical direction separatly, e.g. "2:2" could mean 2 times horizontally and 2 times vertically (like 4:2:0). Why has 0 got a meaning?

At the main entry I added a link to an image that I think better illustrates what the different chroma subsampling notations refer to. That black and white image is more explanatory compared to what the current pink & blue tiled image on the entry does. I would actually suggest to remove that pink and blue image, just keep linking to other one. —Preceding unsigned comment added by Raulsaavedraf (talk • contribs) 19:12, 22 May 2008 (UTC)

I've never heard of 4:2:1, and doubt that it exists. If anybody knows of a meaning for it, please share....

To understand what's going on with 4:2:2 and 4:2:0, we have to look at the history. The 4:2:2 notation originated in the days of analog TV, when we could only scan horizontal lines, so we could only subsample horizontally. It represented luma and two color differences. Then along came memory, and we could work on a whole field or frame all at once. That made it possible to subsample both vertically and horizontally.

At that point, we had a sort of notation mutation.

In the old understanding, 4:2:0 would mean that one of the color differences was completely discarded, which, of course, wouldn't work. But because the two color differences are always given the same weight, we could write that number only once, and replace the last digit with a zero to indicate that we're subsampling in both directions.

Because human vision works the same horizontally and vertically (were that not true, we'd be rotating our heads 90 degrees all the time to get a better look at stuff), 4:2:0 works just as well as 4:2:2. Therefore, 4:2:2 is obsolete. Now that we have memory, we should forget about it.

-- J.S.

170.20.96.116 (talk) 19:26, 6 April 2009 (UTC) John Sprung

8:4:4

I propose including 8:4:4 under 4:2:2 instead of its own section. 8:4:4 is marketing speak (by telecine vendors). For example, if I subsampled a 4096 x 3076 image's chroma components to 2048 x 1536, it would still be called 4:2:0 instead of something like 32:16:0, even though the analog bandwidth (an obsolete measure when talking about digital video) is ~30 times that of standard definition. The numbers in the notation correspond to absolute sample values (4 = 720 samples per line, etc.) only when talking about digitizing analog standard definition video. For everything except standard definition, the numbers just mean ratios. So if the chroma components have half the number of luma samples in the horizontal direction, the subsampling is 4:2:2, no matter if it's full-HD, 4K, or whatever pixel count you can imagine. If you disagree, then I propose adding 16:16:16, 16:8:0, 16:8:8 (and any other meaningless terms) to correspond to different sampling resolutions (I guess 12:6:6 would then be for 2048 x 1536 video with horizontal chroma subsampling :^) ). —Preceding unsigned comment added by 130.233.243.229 (talk) 22:44, 17 December 2007 (UTC)

I agree with you. -- J7n

I removed the section. It was uncited anyway. Totsugeki (talk) 00:13, 23 February 2010 (UTC)

Video codecs doing 4:4:4

As correctly pointed out in the Controversy section, rudimentary color subsampling is a method of the past – much like interlacing. I never use it when creating JPEG files. Yet all video formats known to me require it. What are the video codecs capable of handling 4:4:4? -- J7n —Preceding unsigned comment added by 83.99.184.75 (talk) 22:01, 6 May 2008 (UTC)

High (quality) profiles for standards like MPEG2, MPEG4 I believe will support 4:4:4. JPEG2000 is always 4:4:4 I believe, as wavelets are naturally scalable and the subsampling would hurt it more than help. DCT-based compression at low bitrates benefits from subsampling... at higher bitrates it does not, this is why JPEG does 4:4:4 at high bitrates. Unfortunately, studio video infrastructure is typically 4:2:2 SDI so there is a upper limit to quality. Dual link 4:4:4 SDI is possible (and used for mastering) but impractical over large facilities. Glennchan (talk) —Preceding comment was added at 17:50, 23 June 2008 (UTC)

I don't believe MPEG4 part 2 has any support for 4:4:4, and I know that MPEG4 part 10 only supports 4:4:4 in the "High 4:4:4 Predictive" profile which isn't widely used. Both Dirac and Theora support unsubsampled chroma. --Gmaxwell (talk) 16:41, 28 April 2009 (UTC)

X:Y:Z: Cr and Cb, not even/odd scanlines

In X:Y:Z notation Y and Z correspond to Cr and Cb bandwidth rate, not to even and odd scanlines.

4:2:1 codecs halve Cr and quarter Cb bandwidth rather than sampling odd lines two times less often than even ones.

Bandwidth may be unrelated to sampling rate. Some codecs do really downsample the video, others sample color difference at luma rate then average them and transmit the average. —Preceding unsigned comment added by Abolen (talk • contribs) 15:41, 22 May 2008 (UTC)

Yes, this when you're doing the computation as waveforms, and in particular is how it originated from the analog days. However, nowadays I believe there is nothing that prevents the Chroma subsampling from operating discretely (by literally pulling chroma values out positionally entirely in the digital domain).Tgm1024 (talk) 16:29, 18 January 2014 (UTC)

Diagrams don't obey chroma siting standards

Ack... I made the diagrams but they were from codecs that don't obey the chroma siting standards. I believe that DV has Cr and Cb offset from each other by 2 pixels (it's a DSP hack to avoid having to stick a delay into the DSP; cheap consumer bastards)... which is incredibly weird but true. And MPEG-2 would be as described in chroma subsampling notation on poynton's website. Unfortunately I'm too lazy to fix it, and I don't know of ANY DV codec on a PC that handles the DV to the spec.

I also haven't read the original DV and MPEG-2 spec, so I could definitely be wrong about what these standards are. e.g. even if you look in the print version of Poynton's book, the DV chroma diagram in it is wrong; inconsistent with http://www.poynton.com/PDFs/Chroma_subsampling_notation.pdf. Glennchan (talk) 18:07, 3 September 2008 (UTC)

Disputed

I have for years struggled with hand-waving "experts" completely mangling the origin and definition of the a:b:c notation. The current article is no differrent, and includes a rather obtuse way of handling the 4:2:0 case. I have finally found a consistent and coherent explanation. Please refer to an excellent discussion on p.6 of Chrominance Subsampling in Digital Images, by Douglas A. Kerr. I propose that the Wiki section be completely scrubbed to include this excellent explanation.--algocu (talk) 20:42, 9 September 2008 (UTC)

I agree agree; Doug writes good clear and correct stuff. Go for it. It would be good to back up with some book refs, too. Dicklyon (talk) 01:44, 10 September 2008 (UTC)

Check Charles Poynton's chroma subsampling notation document. In the video world at least, there are multiple configurations for 4:2:0. Whatever the proper terminology is, it is abused in practice. We might as well mention what 4:2:0 might refer to. JPEG, DV, MPEG-2, also handle it differently. Interlaced and progressive configurations also differ.99.226.215.161 (talk) 05:09, 30 September 2008 (UTC)

I too agree. Douglas Kerr's piece is clear and correct. The Wiki page is plain wrong. Why isn't it enough to tell the author of the Wiki page that 4:2:0, which is in wide use, would have completely wrong colors if the Cb channel were missing? Grossly wrong pages like this are harmful to the Wiki project. —Preceding unsigned comment added by Dcouzin (talk • contribs) 15:17, 16 February 2009 (UTC)

I (tried to) apply these changes in the article. If an expert can check, this section of the talk page can probably be removed. --129.88.43.5 (talk) 10:49, 30 March 2009 (UTC)

Conflicting terminology

I reverted a mal-styled declaration of incorrectness, based on inconsistency of terminology with the YCbCr article. If someone wants to work on making them more consistent, that would be welcome, but sources need to be cited, especially if someone is to claim that some usage is incorrect. Better to just say what's correct, and cited sources for that. Dicklyon (talk) 21:13, 22 November 2008 (UTC)

What does h.264 use?

Just curious what sampling h.264 uses for HD video? --70.167.58.6 (talk) 22:27, 22 April 2009 (UTC)

4:2:0. (there is a h264 profile for other pixel formats, but it doesn't appear to be widely supported as far as I can tell) --Gmaxwell (talk) 16:35, 28 April 2009 (UTC)

It uses left chroma location. JPEG uses center and HEVC for BT.2100 (HDR) uses Top-left. Valery Zapolodov (talk) 02:51, 13 May 2021 (UTC)

NTSC resolution of 720 x 480?

The caption on the illustration refers to the NTSC standard having a resolution of 720 x480. Surely this is incorrect, as the aspect ratio of NTSC is 4:3, hence 640 x 480 (same as VGA computer monitors). Ross Fraser (talk) 10:09, 8 January 2011 (UTC)

• The NTSC pixel aspect ratio is not 1.00, hence 720 is correct. Pixels are higher than they are wide. It's the other way around in PAL, 720 x 576, also 4:3 due to pixels being wider than they are high. --Janke | Talk 15:23, 8 January 2011 (UTC)
  • Thanks for the clarification. I looked at other Wikipedia articles to try to get info on this and there was nothing. If you can, please edit the NTSC and PAL articles, among others, to provide this info on the digitization of NTSC and PAL data streams. Thanks! Ross Fraser (talk) 23:48, 12 January 2011 (UTC)
    • Strictly, both PAL and NTSC are analog video formats, and have no actual pixels, so it would be wrong to put a pixel number into the articles. Most (but not all) digital implementation of PAL- and NTSC-compatible video both have 720 pixels (704 used) per line. See DV. --Janke | Talk 19:48, 13 January 2011 (UTC)
      • The pixel count is based on digital sampling at 4x the NTSC color subcarrier frequency (3.579545 MHz). The period of one horizontal line inclusive of horizontal blanking is 63.56 uS. Subtract 11.03 uS for horizontal blanking, divide by the 4x subcarrier period of 69.84 nS and 752 pixels fill the visible part of one scan line and conform with the RS-170A spec. 720 and 704 pixels do not fill the visible part of the scan line, leaving the H blanking period too wide and out of spec. 752 is a convenient number because it is 47 16-bit words. In addition, there are 483 active scan lines in NTSC, with 21 lines of blanking per field, for a total of 525 lines (483 + 21 + 21). In NTSC days broadcasters used line 21 of each field for closed captioning. There was a plan to use line 22 for Teletext which never panned out. — Preceding unsigned comment added by 69.12.176.20 (talk) 03:06, 18 September 2012 (UTC)

The pattern examples seem wrong

The chroma blocks should be 2x smaller and consequently the resulting blocks should contain smaller color component blocks. Or separate block patterns could be made for the color components. reasoning: in the 4:4:4 format both Yr and Yb should appear exactly as often as Y. Now the diagram shows alternatively an Yr and Yb for every consecutive Y. —Preceding unsigned comment added by 83.87.234.209 (talk) 22:17, 29 January 2011 (UTC)

Which figures are you talking about? Dicklyon (talk) 00:44, 30 January 2011 (UTC)

missing image

i do not see any image to illustrate the appearance of "4:2:0 progressive sampling applied to moving interlaced material. " All image captions are UNDER their corresponding images, right? If so, this one is missing.

FleetingJoy (talk) 19:15, 7 July 2011 (UTC)

Chrominance (term)

I was reading near the beginning of the article, and noted that the author, for some reason, did use the term "luminance", but not "chrominance". I was reluctant to do a wholesale replacement, however. "Chrominance" seems to be a correct and accepted term, but I don't keep up with this field any more.

Fwiw, I was greatly inspired by the Color TV special issue of Proceedings of the IRE, iirc 1949. Defining the I and Q axes and bandwidths in terms of human vision seemed especially inspiring. Even when the cost of true I and Q decoding in a receiver had been reduced somewhat, receivers using true I and Q seemed to be all but nonexistent. One would think that better quality would encourage some high-end products to be made, but "high-fidelity video" never seemed to take hold.

Regards, Nikevich 18:40, 23 April 2012 (UTC)

Chroma and luma are gamma corrected (OETF) and the other two are not. See ITU-T Rec. H.273. Nowadays only chroma and luma are there, though HDR did bring back linear light. Valery Zapolodov (talk) 02:49, 13 May 2021 (UTC)

4:2:0 clarification

I think I finally figured out what 4:2:0 is supposed to mean: That it really means 4:2:0.5. But that one doesn't bother with decimals in the expression. And that one also could write 8:4:1 which would mean the same thing.

Or another way to put it: The numbers give the relative sampling frequency, right? Then my explanation holds water. If I'm right then why not put this on the main page? Would save a lot of folks headache I think. — Preceding unsigned comment added by DavidGGG (talk • contribs) 11:50, 14 June 2012 (UTC)

I agree that the 'mathematically correct' names should be provided along with the 'traditional' names.

I'm not sure whether 4:2:0 is 'mathematically correct', but the article itself states that "4:1:0" and "4:2:1" are not — and it is neither clear why, nor what the 'expected' names would be.

—DIV (120.17.225.128 (talk) 15:06, 4 October 2018 (UTC))

Effectiveness

This section talks about the fact that chroma subsampling isn't necessarily the best approach when it comes to compression effectiveness. However, there is no talk about the positive aspects: Saving bandwidth and memory footprint in digital systems. In particular, mobile processors who are power-constrained greatly benefit from this since uncompressed pixel traffic to and from external memory is a large part of power consumption. — Preceding unsigned comment added by 24.5.125.133 (talk) 05:47, 22 March 2015 (UTC)

How much is this difference though? I would say people would prefer higher image clarity on a mobile device, because it is much closer to your eyes. The largest battery hit to a mobile device is the backlight itself. If anything, a better approach would be to reduce the resolution of the phones instead of using the extreme ones like 2550x1440 on a 5 inch display when it isn't humanely possible to see all of that detail without it being like 1 foot from your face.----

Purpose of 4:4:4

Since the reason for using YCbCr is to dedicate most of the data on luminance, what purpose does 4:4:4 hold? You could use the same amount of bytes per pixel to encode RGB instead. 2.104.130.203 (talk) 22:46, 2 October 2015 (UTC)

4:4:4 YCbCr is easier to compress with lossy compression techniques than 4:4:4 RGB in two different ways. The conversion from RGB to YCbCr has a decorrelation effect, so the energy of the signal tends to become more compacted into the Y component instead of being spread across all three components, and that saves bits in the same way a spatial transform like a DCT (e.g., as used in JPEG) or a spatial KLT does (see also Principal component analysis). Also, since people are more sensitive to errors in Y than in Cb and Cr, the chroma signals can be compressed with more distortion without being as visually annoying. People are also more sensitive to errors in G than in R and B, but the effect is more pronounced for YCbCr. Mulligatawny (talk) 01:15, 25 May 2018 (UTC)

You must be kidding. Y'CbCr is much bigger colorspace than R'G'B'. For limited range it has superwhite and superblack (the first even visable) and also even for full range a lot of values are outside of R'G'B. Valery Zapolodov (talk) 02:46, 13 May 2021 (UTC)

Y'CbCr is much bigger colorspace than R'G'B' not for a given amount of bits. You reach out for more space, you chop out the precision at lower bits. Same for superwhite: you limit the output range, you again lose precision. JPEG has the good sense of not using superwhite. Video codecs use it, because TV people are used to it being a thing.

Y'CbCr gives higher Coding gain by decorrelation -- ideally, you don't need to encode the same information thrice. Artoria2e5 🌉 00:08, 17 July 2023 (UTC)

Explanation of J:a:b

The explanation of J:a:b in Sampling systems and ratios

J: horizontal sampling reference (width of the conceptual region). Usually, 4.
a: number of chrominance samples (Cr, Cb) in the first row of J pixels.
b: number of changes of chrominance samples (Cr, Cb) between first and second row of J pixels.

is currently confusing, and inconsistent with some information elsewhere.

A lot of the problems relate to luma (Y) sampling.

Firstly, there is no indication in this explanation of the sampling of Y. But the subsequent explanations presuppose a meaning. For example, in 4:4:4:

Each of the three Y'CbCr components have the same sample rate

Yet actually the above definitions only say that the two chroma channels are sampled at each pixel, but say nothing about the luma (Y).

Secondly, I find at Wikimedia this example of the structure for "3:1.5:1.5":

3:1.5:1.5 structure

I don't know whether this is ever used in practice, but nevertheless — if correct — it is helpful to have a quite different example to illustrate the logic of the naming. Notice that this figure shows luma sampled every 4/3 pixels, rather than every (4/4) pixel.

Lastly, for b, why say "between first and second row of J pixels", rather than just "between first and second row" or "between adjacent rows"? Surely the mention of "J" here adds no information, and is rather distracting.

—DIV (120.17.225.128 (talk) 15:17, 4 October 2018 (UTC))

Is there a 4:0:0 sampling scheme?

Is there a 4:0:0 sampling scheme? I think I've read it somewhere, but that doesn't make it true. But if there is, I think it should be mentioned. Algotr (talk) 01:42, 4 March 2022 (UTC)

That is just Y only, grayscale. 2A00:1370:8184:164:CDD4:5A3C:A775:5C0C (talk) 20:33, 25 March 2022 (UTC)

R'G'B'

Where should R'G'B' be explained? This "chroma subsampling" article (and this corresponding talk page) mention R'G'B' several times. Another article -- "RGB color spaces" -- mentions R'G'B' in the title of one of its references. The first use of R'G'B' in this article links to the "RGB" article, so I clicked on it, hoping to find an explanation there, but that article never even mentions R'G'B', much less explains it. None of these 3 articles ever explains what R'G'B' means, and what (if anything) makes it different from RGB.

Is there some other article that explains what R'G'B' means? --DavidCary (talk) 22:32, 29 November 2022 (UTC)

The prime means gamma-corrected (or any non-linear), so R'G'B' means any non-linear RGB signal. That would be nearly every display standard you've heard of: sRGB, P3, whatever. Artoria2e5 🌉 00:10, 17 July 2023 (UTC)