SMPTE colorbar generation formula

[colibri]

I wish to generate a colorbar! I use below formula:

// rgb to yuv
int y = (( 66 * r + 129 * g + 25 * b + 128) >> 8) + 16;
int u = (( -38 * r - 74 * g + 112 * b + 128) >> 8) + 128;
int v = (( 112 * r - 94 * g - 18 * b + 128) >> 8) + 128;

But from this link, my result is not correct!

The 8-bit values of 100% SMPTE color bars are:

| COLOR | R-G-B | BT.709 Y-Cb-Cr | MyResult |
|---------+-------------+----------------+-------------|
| Gray | 104-104-104 | 104-128-128 | 105-128-128 |
| Yellow | 235-235-16 | 168-44-136 | 197-32-143 |
| Cyan | 16-235-235 | 145-147-44 | 161-161-32 |
| Green | 16-235-16 | 134-63-52 | 140-65-48 |
| Magenta | 235-16-235 | 63-193-204 | 108-191-208 |
| Red | 235-16-16 | 51-109-212 | 86-95-224 |
| Blue | 16-16-235 | 28-212-120 | 51-224-113 |
| White | 235-235-235 | 235-128-128 | 218-128-128 |
| Black | 16-16-16 | 16-128-128 | 30-128-128 |

Which formula should be used to generate 8-bit 100% SMPTE color bars?

[jagabo]

Your RGB to YUV conversion is creating standard limited range YUV (Y 16 to 236, U and V 16 to 240) from full range RGB (0 to 255). I't looks like rec.601 -- I'll have to check the math later. Computer RGB is normally full range (RGB 0 to 255) and all commercial distribution formats are limited range YUV. Your input colors are limited range RGB, not the normal full range RGB (what you see on the screen).

[betwixt]

Did you know 'ffmpeg' can generate the bars for you?
Look for the 'smptebars AVOptions:' in the FULL help screen.

Brian.

[jagabo]

I've verified that the equations you are using are for converting full range RGB (0 - 255) to limited range rec.601 YCbCr (Y 16-235, CbCr 16-240).

Your input RGB colors are limited range RGB, not full range RGB. For example, full range full brightness red should be 255,0,0. Full range 75% red should be 191,0,0 (this is what the standard rec.709 color bars use). Limited range RGB is almost never used for anything.

Your expected rec.709 colors are for full range 75 percent RGB colors, not 100 percent RGB colors. Ie, your input colors should be 191 or 0 for each RGB component. That will give you the expected YCbCr values if you perform a correct rec.709 conversion.

I don't have the 8 bit integer RGB to rec709 YUV conversion equations handy.

[jagabo]

Official rec.709 doc:
https://forum.videohelp.com/threads/390628-Inaccurate-YUV-RGB-Conversion?highlight=rec...on#post2532179

AviSynth code:
http://avisynth.nl/index.php/Color_conversions

Beware, code like (Kr*219/255) may be optimized by a compiler to (Kr*1) or (Kr*0). Use ((Kr*219)/255) instead.

[LMotlow]

@jagabo, previous 2 posts:
Good catch and useful info.

[chris319]

Do you want SMPTE standard color bars or goofy amateur video color bars?

The standard used in professional facilities and used by manufacturers is SMPTE RP 219, viz.:

http://car.france3.mars.free.fr/HD/INA- 26 jan 06/SMPTE normes et confs/rp219 mirehd.pdf

Here is the equation for the primaries and secondaries. Per the RP 219 spec the bars are 75%.

0.75 * (235 - 16) + 16 =180

Thus,
Red = R=180, G=16, B=16
Cyan = R=16, G=180, B=180
etc.

Why this matters: SMPTE color bars are a standardized test signal. Professional vectorscopes from Tektronix, etc. (which none of us mortals can afford) are calibrated to this standard. If you send your video with color bars to a professional facility such as a TV station, network, post-production house or even to Netflix and your bars are out of kilter, it could fail QC and be rejected, or, they are left to guess at how to set up on your non-standard bars.

Professional facilities use 75% bars.

I've been around the block on the topic of SMPTE bars. If you need proof, check the spec.

[poisondeathray]

Yes, that wikipedia link looks incorrect

eg. "Red" should be 191,0,0 in 8 bit RGB for SMPTE bars . In 8bit YCbCr it's given exactly as 51,109,212 according to RP219-1 and 2. That matches the SMPTE HD bars in NLE's too

[chris319]

Yes, that wikipedia link looks incorrect

eg. "Red" should be 191,0,0 in 8 bit RGB for SMPTE bars . In 8bit YCbCr it's given exactly as 51,109,212 according to RP219-1 and 2. That matches the SMPTE HD bars in NLE's too

No, if we're talking about SMPTE RP 219, the industry standard, red is 180-16-16. Read the spec. The NLE mfrs. have it wrong, and that includes Davinci Resolve. Look at your Belle Nuit bars. https://www.belle-nuit.com/test-chart

0.75 * (235 - 16) + 16 =180

Wikipedia wrong? Unheard of!

[poisondeathray]

Yes, that wikipedia link looks incorrect

eg. "Red" should be 191,0,0 in 8 bit RGB for SMPTE bars . In 8bit YCbCr it's given exactly as 51,109,212 according to RP219-1 and 2. That matches the SMPTE HD bars in NLE's too

No, if we're talking about SMPTE RP 219, the industry standard, red is 180-16-16. Read the spec.

SMPTE RP 219 says 8bit "red" is YCbCr 51,109,212 . Can you point out the part where it says red is 180-16-16?

[chris319]

SMPTE RP 219 says 8bit "red" is YCbCr 51,109,212 .

BT.709 coefficients: #Kr = 0.2126: #Kg = 0.7152: #Kb = 0.0722

Y of red bar = 180 * 0.2126 + 16 * 0.7152 + 16 * .0722 ~ 51, the value given in Fig. 3-2

Now let's figure it your way:

191 * 0.2126 + 0 * 0.7152 + 0 * 0.0722 ~ 41

or using BT.601 coefficients:

EY
0.299 ER
0.587 EG
0.114 EB

191 * 0.299 + 0 * 0.587 + 0 * 0.114 ~ 57

Only 180-16-16 using BT.709 coefficients gives us the correct Y value of 51.

[pandy]

75% in RGB doesn't mean 75% in YCbCr... Equations are quite simple and obvious.
btw all signals like this need to have bandwidth limit i.e. proper lowpass shape filter is quite mandatory.
For real signal values https://www.itu.int/rec/R-REC-BT.801/en can be used as reference.

[jagabo]

Now let's figure it your way:

191 * 0.2126 + 0 * 0.7152 + 0 * 0.0722 ~ 41

That equation is for full range YUV. For limited range YUV (used almost everywhere) you must adjust for the range (Y =16 to 235 rather than 0 to 255) and offset (black at Y=16).

(191 * 0.2126 + 0 * 0.7152 + 0 * 0.0722) * ((235-16)/(255-0)) + 16 ~ 51

The AviSynth equations (for full range RGB to limited range YUV) I linked to gave:

   R       G       B           Y       U      V
---------------------------------------------------
  0.000   0.000   0.000 -->  16.000 128.000 128.000
  0.000   0.000 191.000 -->  27.843 211.890 120.308
  0.000 191.000   0.000 --> 133.318  63.333  51.802
  0.000 191.000 191.000 --> 145.161 147.223  44.110
191.000   0.000   0.000 -->  50.874 108.777 211.890
191.000   0.000 191.000 -->  62.717 192.667 204.198
191.000 191.000   0.000 --> 168.192  44.110 135.692
191.000 191.000 191.000 --> 180.035 128.000 128.000

All of which round to the expected YUV values.

[colibri]

Thanks, all, it's more clear now!

so BT.601 is full range but BT.709 is limited range, Does full range (BT.601) can display more colors than limited range (BT.709)? I am curious why HDTV use BT.709 with limited range.

[poisondeathray]

so BT.601 is full range but BT.709 is limited range, Does full range (BT.601) can display more colors than limited range (BT.709)? I am curious why HDTV use BT.709 with limited range.

No, both are limited range in common use such as TV, DVD, BD etc... But both have full range variants as well.

Limited range is used because some space is allocated for head and footroom (you can't get perfect signals for a variety of reasons)

[chris319]

Did you check the Belle Nuit signal as I suggested? Red is 180-16-16. For 100% bars it is 235-16-16.

https://www.belle-nuit.com/test-chart

191.000 0.000 0.000 --> 50.874

Let's see the full equation with BT.709 luminance coefficients.

[colibri]

Very nice catchup.

Mostly testcards is used for monitor, but for LCD such as phone screen, is it the same. for monitor, maybe we need to use limited range signal, but for LCD screen do we still need to use limted range signal? I guess LCD can always show everything between (0,255).

[chris319]

Proper SMPTE color bars have something called a pluge. In the RP219 spec there are explicit instructions on how to set up monitor brightness using the pluge.

[jagabo]

Let's see the full equation with BT.709 luminance coefficients.

The RGB to limited range YCbCr equation is on the AviSynth page I linked to.

The problem with your calculations is that you are using the full range YCbCr equations get generate the expected values of limited range YCbCr colors. For example, full range YCbCr defines black at Y=0, limited range defines black at Y=16. You're creating limited range YCbCr from limited range RGB. But aside from the need to create pluge patterns like this there is limited range RGB isn't used much.

[chris319]

You're creating limited range YCbCr from limited range RGB.

BT.709 specifically defines black at 16 and white at 235. That's what you call "limited range". I prefer to go by specs. If you look further on another avisynth web page you'll find a whole table with 180-16-16.

Did you examine the Belle Nuit bars? I suspect not.

[jagabo]

You're creating limited range YCbCr from limited range RGB.

BT.709 specifically defines black at 16 and white at 235. That's what you call "limited range". I prefer to go by specs. If you look further on another avisynth web page you'll find a whole table with 180-16-16.

Both are standard. One which doesn't change levels (for when you need to access superblacks and superwhites), one for normal viewing (import/export of images, etc.).

Did you examine the Belle Nuit bars? I suspect not.

I'm fully aware of the Bell Nuit bars. They are limited range RGB images for conversion to limited range YCbCr video. But limited range is not the norm for images outside that context. JPG, PNG, BMP, etc. are all full range RGB when output and displayed.

[chris319]

Both are standard.

I'm talking about SMPTE bars which is the topic of this thread and which are industry standard in the U.S. per RP 219. One standard.

There are other standardized test signals for Europe, etc.

Now if you want to talk about the bars found in Davinci Resolve or Premiere Pro or what have you, if they don't conform to spec then don't call them SMPTE bars because they're not, and don't expect interoperability with professional video facilities.

What you call "limited range" I prefer to refer to as BT.709 which is definitely a standard.

[poisondeathray]

Now if you want to talk about the bars found in Davinci Resolve or Premiere Pro or what have you, if they don't conform to spec then don't call them SMPTE bars because they're not, and don't expect interoperability with professional video facilities.

What you call "limited range" I prefer to refer to as BT.709 which is definitely a standard.

They are SMPTE bars, the conform to specs

They are YCbCr bars. The actual YCbCr values are the same as in the SMPTE document (maybe some minor rounding differences).

The "RGB" preview is just a preview. How that gets converted to RGB does not affect the actual underlying YCbCr data. It just depends on how you are setup to view it (how the program(s) are converting to RGB for display underneath the hood)

Different equations are used to convert YCbCr to "computer RGB" (RGB 0-255) , or "studio range RGB" (RGB 16-235) , and vice versa

When you are viewing on an 8bit 0-255 RGB setup , you will get 191,0,0 for R 75% 8bit RGB . Because it uses the appropriate equation for that system.

But that exact same video, those exact same bars, when viewing on an 8bit 16-235 RGB setup will display as 180,16,16 because it uses the appropriate equation.

Both are 75% Red for that RGB setup


But if you are using a computer monitor , or phone, or tablet, 99.99999% will be using "computer RGB" , or RGB 0-255. Very few programs or setups use "studio RGB" (sony vegas is one notable exception that can use both) . To use RGB 16-235 properly you have setup your programs, settings, drivers, monitor, and calibrate properly .

99.99999% of 8bit RGB sources are 0-255. Think of camera images, jpg's, png's, gifs, web, etc... Almost nothing uses 16-235 RGB on computers. If you 're using RGB 16-235 display for browser, viewing images - it's not going to look correct . So most people use a separate broadcast monitor for this. The main monitor is usually set to computer RGB levels

eg. Here are SMPTE SD NTSC 100 bars from SMPTE .
https://www.smpte.org/lifewithoutsmpte/SMPTEColorBars

Notice the 100% values in RGB are 255, not 235. 0% is 0, not 16. But Bt601 , like Bt709 also indicates R,G,B, and Y should be between 16-235 (studio range RGB). Then why the 255 numbers on SMPTE's own webpage? Because you're likely viewing that webpage computer monitor, or tablet, or device like a phone. All those use RGB 0-255. That's why they used the appropriate equation to convert to RGB. And that why most people should be using RGB 0-255 for computer work, that's why NLE's display as 191,0,0 for R 75% 8bit.

[chris319]

I'm not talking about 0 - 255 "full-range" video that's not going to be broadcast or used in a professional facility and which may or may not conform to BT.709. How many times do I have to make this point?

You're wasting your keystrokes bringing 0 - 255 video into the discussion. If a video is headed for YouTube then who cares about color bars anyway, much less whether they are standard or not? You're belaboring the point by bringing 0 - 255 into the discussion.

See Fig. 3-4 and Fig. 3-9. What are the figures given for 100%W?

[poisondeathray]

I'm not talking about 0 - 255 "full-range" video that's not going to be broadcast or used in a professional facility and which may or may not conform to BT.709. How many times do I have to make this point?

You're wasting your keystrokes bringing 0 - 255 video into the discussion. If a video is headed for YouTube then who cares about color bars anyway, much less whether they are standard or not? You're belaboring the point by bringing 0 - 255 into the discussion.

You probably didn't read or didn't understand.

I'm not talking about 0-255 YCbCr full range video either.

I'm explaining why 75% "red" is RGB 191,0,0 on most computers (and that's legal for SMPTE , passes QC video). And that's correct.

I'm explaining what you're categorizing as a discrepancy - when really it's the same thing. Just 2 different RGB systems. The underlying YCbCr values and video is the same, just converted differently to different systems

Because you're not submitting RGB, you're submitting YCbCr. Bars are attached as YCbCr. Your final submission is YCbCr

[poisondeathray]

See Fig. 3-4 and Fig. 3-9. What are the figures given for 100%W?

YPbPr 235,128,128 for 8bit values

On a RGB 16-235 setup, such as a studio RGB setup, you would expect it to be converted and display as RGB 235,235,235

On a RGB 0-255 setup, such as a normal computer monitor, you would expect it to be converted and display as RGB 255,255,255

[chris319]

On a RGB 0-255 setup

Did you not read my previous post?

[poisondeathray]

On a RGB 0-255 setup

Did you not read my previous post?

Does it make sense to you know ?

That same Y 16-235, CbCr 16-240 legal range video that displays as RGB 0-255 on a computer monitor is going to be used in broadcast . It's the same underlying video !


Are you reading this on a computer monitor ? How is it calibrated or setup ?