Talk:SMPTE color bars

This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Film: Filmmaking This article is supported by the Filmmaking task force. Television: Test cards High‑importance This article is within the scope of WikiProject Television, a collaborative effort to develop and improve Wikipedia articles about television programs. If you would like to participate, please visit the project page where you can join the discussion. To improve this article, please refer to the style guidelines for the type of work.TelevisionWikipedia:WikiProject TelevisionTemplate:WikiProject Televisiontelevision articles High This article has been rated as High-importance on the project's importance scale. This article is supported by the Test cards task force (assessed as Top-importance).

It is requested that an image or photograph of a stairstep signal on a waveform monitor be included in this article to improve its quality. Please replace this template with a more specific media request template where possible. The Free Image Search Tool or Openverse Creative Commons Search may be able to locate suitable images on Flickr and other web sites.

Upload

When was introduced the SMPTE color-bar test pattern?

The original color test pattern generator was developed by RCA circa 1951.

https://patentimages.storage.googleapis.com/2f/b4/90/ed6fcccbba109f/US2742525.pdf — Preceding unsigned comment added by 172.91.176.10 (talk) 00:05, 21 December 2021 (UTC)[reply]

Developed by Al Goldberg of CBS Laboratories. Adopted by SMPTE in 1978.

• Well, the article says the color bars started in the 1980's. But, I had never seen a TV station sign-off with color bars where I lived, but this happens on occassion from some Indianapolis TV stations in the overnight hours for no reason.

Why are the color bars apparently so restrictively licensed? Even if I made a piece of art using it, released under GNU licensing, it'd be illegal from what I can tell. Thats messed up. Bars of color on a site that uses the word free alot, near-totally unusable. Where is this world going to? —The preceding

• Where did you get that idea? While the SMPTE document itself is copyrighted (you can buy it from the SMPTE website), and SMPTE might impose restrictions on the use of their name; I'm not aware of any patents one must license--from SMPTE or anyone else--to implement SMPTE bars. Certainly, color bars are not copyrightable subject matter (as the colors used are determined entirely by technical considerations, and are not the expression of an author, they fall under the
  scenes a faire exception to copyright law). I work in the video industry, and I've never heard of any restrictive licensinc on SMPTE colorbars. And my employer produces several products which generate them. --EngineerScotty 03:10, 5 March 2006 (UTC)[reply
  ]

While the SMPTE bars are interesting and useful; especially in NTSC land; there are other color bars signals that are useful:

• Plain old 100% and 75% bars
• The newer colorbar standard from SMPTE (can't remember the number) intended for high definition television systems

Perhaps the article should be renamed

I will come back later to see if someone has commented on this. If not, I will try to edit the article by removing the NTSC references. —Preceding unsigned comment added by Milivoj (talk • contribs) 15:36, 25 March 2006

This is about SMPTE color bars, which includes tests that are NTSC-specific. The NTSC references should remain in this article.  Denelson83  22:17, 25 March 2006 (UTC)[reply]

• Elliott Smith wrote a song titled "Color Bars". There is no indication that there is a connection between the song and SMPTE color bars —Preceding unsigned comment added by 69.230.161.1 (talk • contribs) 04:59, 7 June 2006

• In the music video Video Killed the Radio Star by The Buggles, the female singers' costumes include a 100% color bar pattern on their belt buckles.

The sound clip's format should be changed into a more user feiendly version like mp3 or something. —Preceding unsigned comment added by 141.149.149.200 (talk • contribs) 19:54, 18 November 2006

The sound clips on Wikipedia are in

That 1000MHz sound is also used to "bleep" offensive stuff, right? Curvebill 23:03, 7 July 2007 (UTC)[reply]

1000 Hz. --  Denelson83  05:15, 8 July 2007 (UTC)[reply]

to better illustrate "this sequence of bars thus appears on a waveform monitor in luminance mode as a downward staircase from left to right." in the Useage section. --Thomprod (talk) 01:31, 21 January 2009 (UTC)[reply]

Is this (figure 2) the sort of thing that you had in mind?--♦IanMacM♦ ^{(talk to me)} 11:01, 21 January 2009 (UTC)[reply]

Yes, that would do nicely. Can you please upload it and add it to the article? --Thomprod (talk) 01:25, 22 January 2009 (UTC)[reply]

He can't, because it would be a copyvio. --  Denelson83  03:21, 22 January 2009 (UTC)[reply]

Since an image here would need to comply with

WP:NFCC, as the saying goes, here is one I made earlier. This shows color bars in a software oscilloscope.--♦IanMacM♦ ^{(talk to me)} 20:37, 22 January 2009 (UTC)[reply

]

It would be nice to have the luminance value of each of the bars (gray is 77 IRE -- I have to get out Ennes to look up the rest). — Preceding unsigned comment added by 69.12.176.20 (talk) 17:56, 13 August 2012 (UTC)[reply]

I have added the luminance values obtained directly from Ennes, as well as a link to the Tektronix pdf on NTSC video measurements where there are plenty of scope shots. Some web sites give erroneous luminance values for color bars. Ennes and Textronix are in agreement (yellow = 69 IRE, etc.) and I consider them authoritative. Chris319 (talk) 20:55, 24 June 2016 (UTC)[reply]

Confining the color-bar values to the studio swing range of 16 to 235, we get (0.75 x (235-16)) + 16, or 180. The magenta bar, for example, consists of R = 180, G = 16, B = 180. 100% white is thus equal to 235.

The pluge values would then be:

+2 * ((235-16)/100)+16 = 20 (R = 20, G = 20, B = 20) for +2%.

+4 * ((235-16)/100)+16 = 25 (R = 25, G = 25, B = 25) for +4%. (SD)

-2 * ((235-16)/100)+16 = 12 (R = 12, G = 12, B = 12) for -2%. (HD)

See SMPTE RP 219 Fig. 3-9 and paragraphs 4.3, 4.31 and 4.32.

Chris319 (talk) 06:01, 16 October 2016 (UTC)[reply]

This is called superblack or toeroom or blacker than black. 2A00:1370:812D:F205:C0A5:95D7:D09C:EE8C (talk) 14:34, 18 April 2021 (UTC)[reply]

The illustration of HD bars does not conform to SMPTE RP 219.

As stated above, the primary and secondary RGB values should be either 16 or 180. — Preceding unsigned comment added by 50.1.203.20 (talk) 11:58, 21 November 2017 (UTC)[reply]

Again, Denelson has posted an image of SMPTE color bars which he wrongly claims are RP 219 conformant but which are grossly out of RP 219 spec. — Preceding unsigned comment added by 173.228.2.244 (talk) 10:40, 24 October 2019 (UTC)[reply]

No, Denelson posted a pattern, in that "colours calculated to make RGB(0,0,0) correspond to -2% black, or "blacker-than-black." That is of course wrong, since no superblack values are possible in full range. See https://en.wikipedia.org/wiki/File:SMPTE_Color_Bars_16x9.svg also, obviously 180 and 16 values are for limited range RGB. And his ones are full range. 2A00:1370:812D:F205:C0A5:95D7:D09C:EE8C (talk) 13:48, 18 April 2021 (UTC)[reply]

This guy also confirms that those bars are recalculated, so I am going to add that info. https://forum.doom9.org/showthread.php?p=1361635#post1361635 2A00:1370:812D:F205:483:61BE:52C6:8DA0 (talk) 10:43, 19 April 2021 (UTC)[reply]

doom9 is not a standards-setting body.

This article is about SMPTE color bars which are codified in SMPTE RP 219, where no distinction is made between "full" and "limited" range. Per BT.601 and BT.709, 8-bit luma levels are confined to the range 16 - 235. There is no provision for a 0 - 255 luma range in BT.601, BT.709 or RP 219. In digital video the values of 0 and 255 are reserved for sync. Having picture data at 0 or 255 would wreak havoc with the video signal.

If you're talking about sRGB, that is a separate standard and belongs in a separate article.

The SMPTE and EBU standards are authoritative, not what some guy on a web site says. — Preceding unsigned comment added by 172.91.176.10 (talk) 2021-07-24T19:00:14 (UTC)

PNG does not use sRGB. It has a gAMA chunk. As for your point about full range... Here full range RGB is used in PNG file and original SVG. Valery Zapolodov (talk) 11:14, 24 August 2021 (UTC)[reply]

This article is about the television test signal, not computer graphics formats such as png. Read the first sentence of the article:

SMPTE color bars are a television test pattern used where the NTSC video standard is utilized, including countries in North America.

"In digital video the values of 0 and 255 are reserved for sync" Actually only for limited range, neither full range YCbCr, nor full range RGB have that problem. Valery Zapolodov (talk) 14:44, 5 January 2022 (UTC)[reply]

To reiterate: This article is about SMPTE color bars which are codified in SMPTE RP 219 where no provision is made for "full" range. Per BT.601 and BT.709, 8-bit luma levels are confined to the range 16 - 235. There is no provision for a 0 - 255 luma range in BT.601, BT.709 or RP 219. Your exception for a non-existent "full-range" video standard is invalid. — Preceding unsigned comment added by 172.91.176.10 (talk) 22:13, 6 January 2022 (UTC)[reply]

Yes, there is none. Full range YCbCr does exist though. Still, I was talking about full range RGB. Valery Zapolodov (talk) 12:30, 15 January 2022 (UTC)[reply]

BTW, I was wrong. The bars are not recalculated. I also updated them fixing wrong -I, +Q signals and fixing ramp. Ramp must have 100% white region. Valery Zapolodov (talk) 21:05, 17 February 2022 (UTC)[reply]

If we agree that full-range (0 - 255) signals are not part of the SMPTE RP 219 spec then why are we including them in an article about SMPTE color bars? In SMPTE RP 219 and subsequent ARIB specs all signals are confined to the 16 - 235 range. This article is not about sRGB, PNG or doom9.

We should only show the signals indicated on the standard. But providing approximate sRGB values for the sake of illustration is not problematic I think. Limited vs full-range discussion should be moved to a specific article.4throck (talk) 23:50, 21 February 2022 (UTC)[reply]

Agreed that we should stick to the SMPTE standard. sRGB is not a video standard so why are we dealing with this non-standard approximation in this article? sRGB bars should be in the sRGB article, but is there even a standard for sRGB color bars? I think it IS problematic to have sRGB bars in this article because you are documenting a true standard and a pseudo non-standard side by side which is potentially confusing and ambiguous. — Preceding unsigned comment added by 172.91.176.10 (talk) 22:48, 22 February 2022 (UTC)[reply]

Mention to sRGB makes sense on the images, if we wish to illustrate the bars on a properly calibrated screen. Other than that it's "original research" and really unsupported by references.

Took the liberty of removing that column from the table, but kept the colors (now on the first column background) for illustrative purposes. Also added a better caption to images (I hope) mentioning the diferent color spaces. 4throck (talk) 23:45, 22 February 2022 (UTC)[reply]

Check the background colors in the first column with a color picker program. Viewed with Chromium, Firefox or Edge the colors range from 0 - 191 per the codes you have entered, but the numbers in the 2nd column range between 16 - 180 which is correct. The background colors in the 1st column do not agree with the RGB values in the 2nd column. There is no explanation of this and you've created a confusing mess. I think it is best to leave these "sRGB approximations" out of it. — Preceding unsigned comment added by 172.91.176.10 (talk) 23:01, 23 February 2022 (UTC)[reply]

The first column has limited range R'G'B' (Studio) using BT.1886 EOTF. The sRGB is always full range in PNG and that is what you see in Chrome, obviously. Wow. "The background colors in the 1st column do not agree with the RGB values in the 2nd column" they were not supposed to, morover they also are from YCbCr 8 bit, so additional off-by-ones were done by me. "sRGB approximations" they are not approximations. They are precise. Just you may want to switch your BT.709 primaries display to EOTF of BT.1886 and it will be perfect. But BT.1886 is complex, it may be 2.2 gamma on LCD display and here you get sRGB, except for linear part. As for sRGB when you color pick you are supposed to color pick the R'G'B', not caring for its transfer or primaries. It does not happen that way, except on android on recent galaxy S21, for example. I will also point out that this is reference: https://www.youtube.com/watch?v=k5tcHp1kBmQ (on 0:21). It has correct 100% white part and both +Q and -I are correct. My galaxy devices apply BT.1886 transfer to the picture on display. This is also correct and has a lonk to githib script. https://www.youtube.com/watch?v=dAWGwhC1VVw Valery Zapolodov (talk) 04:36, 27 February 2022 (UTC)[reply]

Valery: No offense intended, but it is clear from your remarks that you do not understand some basic concepts: 1. SMPTE color bars are a standard for video, not for computer graphics. As such, concepts of sRGB and PNG do not enter the discussion. 2. As a test signal, color bars are display independent. Therefore, EOTF is not a consideration for the signal itself. The signal is agnostic with regard to transfer characteristic. This is where it becomes clear that you do not understand the role of color bars in the video signal chain. 3. Not being device- or display-dependent, how your galaxy device displays them is irrelevant. 4. There is no standardized test signal for sRGB and if there were, it wouldn't be relevant to this article. You can ignore these points and continue to argue to the contrary, but by so doing you continue to reveal that you are in over your head in this discussion. Again, no offense intended. — Preceding unsigned comment added by 172.91.176.10 (talk) 19:24, 28 February 2022 (UTC)[reply]

"SMPTE color bars are a standard for video, not for computer graphics." Yes, but Apple for example does everything correctly by color managing the transfer and primaries as everyone is supposed to. My main display supports BT.1886 too in HW. "signal is agnostic with regard to transfer characteristic." No, it is not. The signal is supposed to use BT.1886. "There is no standardized test signal for sRGB" There is none, but we are forced to use sRGB in CSS. Were it PNG image we could have tagged it as gAMA chunk 2.4 but we cannot. Valery Zapolodov (talk) 10:16, 5 March 2022 (UTC)[reply]

"The signal is supposed to use BT.1886."

This is another unwarranted assumption on your part, Valery. Nowhere in the RP-219 specification is BT.1886 mentioned. 172.91.176.10 (talk) 15:21, 27 March 2022 (UTC)[reply]

BT.1886 only came in 2006, 4 years after RP 219:2002. 2A00:1370:8184:164:B0F7:6BD5:B11E:E81D (talk) 05:04, 12 April 2022 (UTC)[reply]

"Yes, but Apple for example does everything correctly by color managing the transfer and primaries as everyone is supposed to." Apple does not set standards for the video industry. Again you are conflating video and computer graphics, revealing your ignorance of video. There is no "yes but Apple" about it, no PNG and no sRGB. — Preceding unsigned comment added by 107.184.247.128 (talk) 18:37, 30 May 2022 (UTC)[reply]

"Apple does not set standards for the video industry" In fact it did at least create the Display P3: P3-D65 +sRGB transfer (all photos and all screenshots) which is now also used by my Galaxy S21 FE, S22 (screenshots only). All HDR Blu-rays target P3-D65 + PQ transfer but that is Dolby + SMPTE tech. As for Dolby Vision Apple also more or less created their own HLG Dolby Vision. Please note that I am not saying that Apple did create a lot of standards, I am only saing it follows them, that cannot be said about most of the world. 2A00:1370:8184:54CA:71A0:7D29:2D84:BA9F (talk) 23:12, 1 June 2022 (UTC)[reply]

What are you talking about ? Do you use a signal analyzer to test your phone's TV output ? What's the relation between your phone and video ?

If you wish to analyze color profile display conformance, you don't use SMPTE color bars. You use other patterns with a Tristimulus colorimeter... 4throck (talk) 08:17, 2 June 2022 (UTC)[reply]

You do not need signal analyser on your phone, which BTW are more color accurate than most displays in the world, even older reference ones, galaxy s series and iPhones. You did not know that? Shame. Both support TrueTone, which is mandatery for SDR, be it sRGB or BT.709 (PQ is really absolute). You can just use ffplay -vf extractplanes=y and color picker like Pixolor, that you can take a mod apk from 4pda or buy here: https://play.google.com/store/apps/details?id=com.embermitre.pixolor.app 212.248.24.235 (talk) 07:17, 11 July 2022 (UTC)[reply]

After some searching, I was able to find references for digital values, for both SD and HD 100% and 75% bars.

• https://www.leaderamerica.com/pdf/vol03_no04.pdf
• https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.1729-0-200504-I!!PDF-E.pdf

The first document shows the usage of signal analyzers (LV5100 for SD - http://www.valtechvideo.com/partneri/leader/LV5100D.pdf and LV5152 DA for HD - https://assets.tequipment.net/assets/1/26/Documents/Leader/lv-5152da_manual.pdf) with SD and HD patterns. Both SD and HD values for 75% and 100% bars are explicitly listed. Here's the explanation provided for the values shown:

For digital video sources, the 10-bit YCbCr values for color bars are diferent depending if we have a SD or HD signal^[1]. SD values are based on the SMPTE formula for Y from the NTSC system ( Y = 0.299R + 0.587G + 0.114B)^[2]. HD values are according to SMPTE RP-177 and 274M ( based on the formula Y= 0.2126R + 0.7152G + 0.722B)^[3]

Note: Values sourced from "Leader Teleproduction Test Volume 3 Number 4 - Digital Video Levels"^[4]; also matching Recommendation ITU-R BT.1729 (2005) for 100% SD and HD bars^[5]

I'll eventually update the article with this information (currently sourced from a blog...), but for now I'm adding it here for easy reference. 4throck (talk) 07:49, 31 May 2022 (UTC)[reply]

>currently sourced from a blog...

As I already said it is not sourced from the blog (which is actually a good article, I would argue). The blog is only secondary source that is required to represent the standard by Wikipedia policy. In fact you can get the standard from sci-hub. The problem with your table is that the standard only specifies HD (so BT.709 limited matrix). Which is the only thing described here. Also #page=18 and other such are not allowed in the URL, that is Chrome extension. 2A00:1370:8184:54CA:71A0:7D29:2D84:BA9F (talk) 23:18, 1 June 2022 (UTC)[reply]

Contrary to what you say, the first source explains the usage of signal analyzers (LV5100 for SD - http://www.valtechvideo.com/partneri/leader/LV5100D.pdf and LV5152 DA for HD - https://assets.tequipment.net/assets/1/26/Documents/Leader/lv-5152da_manual.pdf) with SD and HD patterns. Both SD and HD values for 75% and 100% bars are explicitly listed.

The second source is a ITU standard. It only considers 100% bars but shows both SD and HD values, that match the first source.

These references are solid, and the values are original 10-bit YCbCr - not calculated or transformed in any way. This is what's needed for Wikipedia.

The problem with the blog is that the original values are never cited and it only shows personal calculations (using MathCAD ?), so it's not a good reference. 4throck (talk) 08:06, 2 June 2022 (UTC)[reply]

>Contrary to what you say, the first source explains the usage of signal analyzers

There is is nothing contrary to what I said. Again, SMPTE (not ITU) standard only discusses HD values while it says SD is just autoconverted. I do not think that ITU standard should be put here. One mention of it is enough. It is publicly available after all. Are you going to add BT.2020nc matrix too? What about BT.2111 PQ and HLG values (suddenly they remembered HDR has too different of a transfer, wow)? What about the correction for BT.2020 primaries they also did a mistake about? We cannot put it all here, can we? All the links to all of those public though and in the article!

>The problem with the blog is that the original values are never cited and it only shows personal calculations (using MathCAD ?), so it's not a good reference

Were it an actual blog, it would not even be considered as

WP:RS. But it is not really a blog or even a blog of a company. Those are actual good articles THAT show how the standard derived 10 bit values using BT.709 spec's .xx notation, they also have some research into what SDR white in HDR should be, so I consider them notable. http://blog.videoq.com/2019/08/20/unified-hdr-reference-white/ Also what about MathCAD? You want it to be done in LaTeX and calculated in Wolfram Mathematica? The fact is I checked those values are the same as in SMPTE standard (when you convert .xx notation in the way 709 specifies), so what is the problem? You think this is original research from me? Well, the article does mention this is 100/0/75/0 (yes!) “EBU Bars” (sic!) so I would think that this is obviously SMPTE standard? 2A00:1370:8184:1B49:5070:FC27:5212:D052 (talk) 23:02, 3 June 2022 (UTC)[reply

]

You can insert your table, but please do not delete my tables. Please, thank you. 212.248.24.235 (talk) 07:18, 11 July 2022 (UTC)[reply]

All you have to do is read SMPTE RP 219. The values are spelled out explicitly and unambiguously in Fig. 3-2 for both 10-bit and 8-bit systems. The test signal is agnostic with respect to display hardware, BT.709, BT.601, BT.1886, BT.2020, sRGB, PNG, EOTF, OETF, "full range", some blog on the Internet and all the other gymnastics you people are going through. For 8 bits, white is 235 and black is 16; for 10 bits white is 940 and black is 64. The SMPTE standard does not conflate video and computer graphics.

The SMPTE spec is authoritative. A blog on the Internet is not. — Preceding unsigned comment added by 107.184.247.128 (talk) 11:57, 26 February 2023 (UTC)[reply]

The article says that SMPTE owns copyright on at least some of the color bar images, but that seems to be quite a stretch:

• Images must meet the threshold of originality to become subject to US copyright law. See the Commons guidance on this for examples. It is pretty certain that the color bars aren't creative enough to qualify.
• In fact by definition, images that are created by exactly following a technical standard demonstrate no creativity at all, and are not considered "works of authorship"
• US copyright law does not apply at all to "business operations or procedures; mathematical principles; formulas or algorithms; or any other concept, process, or method of operation.". The color bar images are the result of following such a procedure, algorithm, process etc.
• The original standards documents defining these images (not created by SMPTE) are explicitly in the public domain (as noted in our own article).
• You can't take something out of the public domain once it's out there.
• Regardless of the copyright status of the standards documents, the images that result from following the standard aren't owned by whoever owns the standard.
• Our own use of the older version images is from Commons where the license statements is "This simple sign is ineligible for copyright and therefore in the public domain, because it contains no original authorship." Anyone familiar with Commons knows they are VERY strict about these things, and yet this has never been considered remotely controversial.
• The newer versions (that the article claims SMPTE own copyright on) are visually just small tweaks to the previous ones... certainly not enough to create a new copyright.

Of course I'm just some guy on the Internet, and this is definitely original research... but the only source we have is someone alleging to represent the SMPTE claiming that the SMPTE owns the copyright (not independent), posted as a reply to a discussion on a public message board (not reliable). Given that the copyright claim is prima facie blatantly false, I don't believe it should be in the article. Accordingly I'm about to remove it.

If anyone disagrees and wants to put it back, that's fine, but perhaps at least it should say "The SMPTE claims that..." rather than just baldly state the copyright claim as if it was a plain fact.

Thparkth (talk) 14:27, 2 September 2022 (UTC)[reply]

I contacted SMPTE when I originally reverted this. We can leave it out for now because you've made good points and I was not able to find a reliable source. I'll post here again if/when I hear back from them. ~Kvng (talk) 15:15, 5 September 2022 (UTC)[reply]

I don't think SMPTE are themselves a reliable source for whether they own copyright on these images; at most they are reliable for saying they *claim* copyright ownership. But many organizations claim copyright on things they don't own because there are no consequences and so no downside for them. Thparkth (talk) 18:22, 4 November 2022 (UTC)[reply]

A cursory search at copyright.gov does not turn up any copyright claim by SMPTE for color bars. As I understand it, they were originally patented by RCA and modified by CBS Labs circa 1978. I don't see how SMPTE can legitimately claim a copyright. — Preceding unsigned comment added by 107.184.247.128 (talk) 11:21, 20 April 2023 (UTC)[reply]

Please give Pluge color bars its own Paragraph. I had a video editing studio for 10 years and without Pluge I would have been flying blind on the optimal brightness and contrast my monitors were set to. 2605:E000:2FC0:21:282B:78CA:1FFA:71BB (talk) 01:05, 15 November 2023 (UTC)[reply]