Are rec601 levels possible??

[jmac698]

colorbars(width=720,height=480,pixel_type="YV12")
coloryuv(analyze=true)

gives y=[7,235] u=[44,210] v=[44,211]
This seems totally wrong. Aren't color bars supposed to give
y=[16,235] and u,v=[16,240] ?
In any case, why are u,v ranges different? And when I copy source from vdub, I see more weird results, the grey is 191 and the blue bar is b=186. The brightness seems to decrease as you move right.
IF these "perfect" color bars aren't right, how can I ever calibrate my card?
What ranges should I expect in a perfect cap?

[jmac698]

Well,
I wrote a program based on http://www.avisynth.org/ColorConversions.
And while I wasn't too careful about rounding, this is approximately what you should get:
75% color bars
color yuv rgb
grey 180,128,128 191,191,191
yellow 161,44,142 191,190,0
cyan 131,156,44 0,191,190
green 112,72,58 0,191,0
magenta 84,184,198 191,0,192
red 65,100,212 191,0,1
blue 35,212,114 0,1,192

Where the original 75% color bars were combinations of 0,191 (when reconverted back to rgb, there is a small error).
I find that the avisynth colorbars->virtualdub conversion is off by up to 5 while my program varies only +-1. I suspect one of those programs are inaccurate.
Anyhow, 75% color bars plus black and white should give
y=[16,235], u,v=[44,212].
The programs are still off by 2 here as well.

[Wilbert]

I didn't check the numbers of jmac698, but i guess they are correct and the same as the upper bars in ColorBars.
gives y=[7,235] u=[44,210] v=[44,211]
This seems totally wrong. Aren't color bars supposed to give
y=[16,235] and u,v=[16,240] ?
This is caused by the pluge signals:
The pluge signals, -4, 0, and +4, are used to set brightness on video monitors. When adjusted properly, only the +4 bar should be visible while the -4 and 0 both appear black.
http://www.mivs.com/technical/colorbars.html

The pluge signal of "-4" is the one that falls outside [16,235].

[jmac698]

Ahh.. thanks, that helps a lot.
I get rgb 9,9,9 for the +4 pluge... analyze reports 7. They are also not close to +4 which would be y=20, rgb=4,4,4.
I'm interested to know about the innacuracies, because, I've never been able to get perfect color bars in Dscaler (settings, calibration). I think digital devices are all using the same integer formulas and these errors add up. So realistically, there should be a modified "digital" set of color values to match. Then you can truly match digital levels, I mean compensating for the roundoff errors of the hardware. If there are still differences, they should be fairly even I think... as color is a phase not affected by frequency response.

[Wilbert]

I get rgb 9,9,9 for the +4 pluge... analyze reports 7. They are also not close to +4 which would be y=20, rgb=4,4,4.
I see what you mean. We got the values from http://www.greatdv.com/video/smptebars3.htm.

The difference between your 191 and our 180: 191 is 75% of 255, and 180 is 75% of 240 (=255-16+1). I think the latter should be correct?

According to that site:
-4 pluge: r=g=b=7
0 pluge: r=g=b=16
+4 pluge: r=g=b=24

Are you sure "-4 pluge" corresponds with Y=12, and "+4 pluge" with Y=20?

[jmac698]

First off, some references.
EIA 189-A-1976, Encoded Color Bar Signal (formerly known as EIA RS-189-A)
SMPTE EG 1-1990, Alignment Color Bar Test Signal for Television Picture Monitors
The +-4 refers to IRE levels (an NTSC unit). IRE stands for Institute of Radio Engineers (now called IEEE). PLUGE stands for Picture line-up generator. 100 IRE is defined as white, and blanking (blacker than black) is 0IRE. There is 7.5IRE setup to reach black, so there is 92.5IRE from black to white. So 1 IRE=219/92.5=2.37 of Y units.

IRE Y R=G=B
-4 7 -11
0 16 0
4 25 11

There is also a shortcut formula from Y to r=g=b, r=g=b=255*(y-16)/219. So the most precise possible value for 4IRE would be, 255*4/92.5=11 (in rgb). -4IRE would be -11

So reference http://www.greatdv.com/video/smptebars3.htm I don't agree with, it has Y=24 but I say Y=25 for the +4 PLUGE.

The 75% white bar should be 191=r=g=b, 180=y, so I agree with that part.

I would have to check if PAL colorbars would be the same.. and I do suggest special routines in creating direct RGB colorbars, as there would be double roundoff (+4 IRE is not an exact Y, and Y->RGB is not exact either).

I think this is pretty important as being a reference signal.
I agree with http://www.mivs.com/technical/colorbars.html as far as it goes, it remains to be calculated the small color bars and the -I and Q.

Are you a coder of one of these tools?
Should we figure this out and make a nice FAQ?

Btw, do you realize that analyze reports colors you could never see? I would really like to have a mode where yuv is mapped to gbr, so one could directly read the original colors. Say, a function to convert clips between this format and back. Then paint programs could be used to read it, and you can see the picture by viewing only green, and in photoshop you could also split to layers and convert back to rgb maybe with L*A*B or something?

[Wilbert]

Thanks for your post, it's very informative!

So for +4 IRE we have Y=16+4*2.37=25.48=25 (similar for -4 IRE). Ok, i got it. We will change that.

I would have to check if PAL colorbars would be the same..
Ok, please do.

and I do suggest special routines in creating direct RGB colorbars, as there would be double roundoff (+4 IRE is not an exact Y, and Y->RGB is not exact either).
The rgb and yuv modes are implented directly, so there's no conversion internally. You can check this with

ColorBars(pixel_type="RGB32")
Crop(...)
RGBAdjust(analyze=true)

The rgb modes are exact, and the yuv modes are calculated from those (using the formulas you linked).

it remains to be calculated the small color bars and the -I and Q.
I can't check EIA right now cause i'm at work (I think that the SMPTE document is not free right?), but how much should these I,Q values be?

Btw, do you realize that analyze reports colors you could never see? I would really like to have a mode where yuv is mapped to gbr, so one could directly read the original colors. Say, a function to convert clips between this format and back.

ConvertToXXX(matrix="PC.601") # and "PC.709"

maps it back to RGB [16,235] ....

[hanfrunz]

I think there should be a YUY2 version of ColorBars(). And maybe it would be nice to have the choice of different bars/testpattern. (SMPTE-bars, EBU-bars, sweep, multiburst, ...)
I can grab some "official" testpattern from a professional testpatterngenerator and post the exact values here. Another problem is, that these generators always produce 10bit signals. So we might get rounding errors.

hanfrunz

[Wilbert]

I think there should be a YUY2 version of ColorBars().
funny guy :) Perhaps you can update your avs version?

And maybe it would be nice to have the choice of different bars/testpattern. (SMPTE-bars, EBU-bars, sweep, multiburst, ...)
I can grab some "official" testpattern from a professional testpatterngenerator and post the exact values here.
That would be very nice!

[hanfrunz]

funny guy :) Perhaps you can update your avs version?
oops, i should read the docs more often :)

my first measurement:
Source: Sony DVW-A500P (internal pattern-generator)
Digitized with: Avid Adrenaline Nitris (OMF 1:1)
readings made with avisynth: (OMF-import filter, cropped area of pure color, coloryuv)

75% color bars = Y, U, V
White= 235, 128, 128
yellow= 162, 44, 142
cyan= 131, 156, 44
green= 112, 72, 58
magenta= 84, 184, 198
red= 65, 100, 212
blue= 35, 212, 114
black= 16, 128, 128

100% color bars = Y, U, V
White= 235, 128, 128
yellow= 210, 16, 16
cyan= 170, 166, 16
green= 145, 54, 34
magenta= 106, 202, 222
red= 81, 90, 240
blue= 41, 240, 110
black= 16, 128, 128

[jmac698]

My program agrees with all the measured values, except for two points. You have a white bar instead of 75% grey, my reference says it should be white, and our yellow values disagree. I know why.
Here is the direct formula for yellow (y):

.75*(.299+.587)*219+16=161.5255=162, my value

191/255*(.299+.587)*219+16=161.34=161, your value
or actually, in 10bits:
767/1023*(.299+.587)*219+16=161.47 ... still not accurate enough in 10bits!

Do we use rgb color bars as the reference, or true 75% as the reference? This and some other points need careful thought. For example I've assumed 1.000=255(rgb)=235(y) exactly. There could also be cases where rounding style matters. We could also go by the intent of the colorbars. 75% is recommended to create a signal which doesn't exceed -100/3 to 400/3IRE in composite. I have to find a formula for composite to make sure 162,44,142 doesn't exceed limits. Ok, looks good, only red and cyan would be close. So Alex, my final answer is 162 :)

-I should be greenish-yellow, Q should be purplish. I could use a matrix calculator to calculate this, anyone know a free one?

[jmac698]

What test patterns does avisynth need? My argument is that there are only 3 things the HTPC has to calibrate, the capture window and cropping to perfect the aspect ratio, the sound level which does not distort, and the colors. What we be a really cool feature is running a script on a realtime capture source, shouldn't there be some special string you can put in directshow source to connect to a capture device? VLC does this with dshow:// device= or something like that, I don't know if that's a ds standard or a vlc convention.

Anyhow, then we could write a script to use averageluma etc. of the color bar areas, and determine not only the settings, but the rec. coefficients used (imagine an auto colorfix flag!!). The cropping could be calculated as well, by searching for the brightest vertical line much like the capture faq. I can suggest a better cropping pattern though, a moving white line and you pick the frame where it comes into view, the frame# is then the #of pixels cropped. Sound good?

Another general idea, there's a lot of need for meta information on video files, filters trying to pass stuff back and forth and having compatibility problems. We should define a container for this, it could fix a lot of problems. We need a standard way to refer to frames, and then info for those frames, such as caption characters, color standard, interlaced, etc. Just defining a frame skeleton could make a big difference, everyone can put their own info in it.

[Wilbert]

-I should be greenish-yellow, Q should be purplish. I could use a matrix calculator to calculate this, anyone know a free one?
I know how to calculate them given some (U,V) value. I just don't know what values i should take for I and Q.

[jmac698]

hanfrunz:

Can you tell me the actual levels of Pb, Pr? Are they +-350mV, and is Y 0-700mV?

Wil:
I'll add the calculations to my program in a bit...

[jmac698]

I'm stuck with a small problem. I can find -I and Q, but they are illegal values and I don't know how to map them.

(rgb scaled to 1=white)
-I
R=-.956295
G=-.272558
B=-1.104744
YCbCr 16 268 -25

+Q
R=.621027
G=-.646709
B=1.701157
YCbCr 16 343 227

If I scale it to keep the same Hue,
YCbCr 16 169 171, or R=69,B=83.
I measured R=40, B=89 from colorbars.

[jmac698]

In NTSC regions, it has been common practice to use a 75% amplitude color bar signal as a test stimulus and reference. In non-NTSC regions, the 100% amplitude color bar is preferred. But in both cases, the saturation of the color bars is kept at 100%.

http://www.tektronix.com/Measurement/App_Notes/Component_Puzzle/standards.html

[hanfrunz]

hanfrunz:

Can you tell me the actual levels of Pb, Pr? Are they +-350mV, and is Y 0-700mV?

Wil:
I'll add the calculations to my program in a bit...

no i can't because i did all measurements in the digital domain. There are no volts here :) But i i would measure with an analog waveformmonitor on the digibeta vcr the levels would be +-350mV and 0-700mV

[Wilbert]

@jmac698,
EIA 189-A-1976, Encoded Color Bar Signal (formerly known as EIA RS-189-A)
I guess also this one is not free?
I can find -I and Q, but they are illegal values and I don't know how to map them.

(rgb scaled to 1=white)
-I
R=-.956295
G=-.272558
B=-1.104744
YCbCr 16 268 -25

+Q
R=.621027
G=-.646709
B=1.701157
YCbCr 16 343 227

Could you elaborate? How did you get these numbers?

[guada 2]

:) Excuse me, but i have a little question:

Then, a real difference would exist between these colors space conversion on SD and HD mode:

RGB ITU-R has BT .601 range and ;
Convert RGB range (0,255) as IRE (0,100)

It would be true?

[jmac698]

Well, YIQ is not used anymore, but it was actually better in some ways, in that it more closely resembled the response of the human eye to color. As such, it allowed more filtering of the color, even as low as 600KHz. The difference with YUV, is that it's rotated 33 degrees (which way, not sure right now). I see that Red is at 90+33 degrees for example.

Anyhow, here's the formula:

Y = 0.299R + 0.587G + 0.114B
I = 0.877(R - Y) cos 33 - 0.492(B - Y) sin 33
Q = 0.877(R - Y) sin 33 + 0.492(B - Y) cos 33

Namely,

I = 0.735514(R − Y) − 0.267962(B − Y)
= 0.595716R − 0.274453G − 0.321263B
Q = 0.477648(R − Y) + 0.412626(B − Y)
= 0.211456R − 0.522591G + 0.311135B

I don't have the reverse formulas handy at the moment. But look at
http://www.nacs.uci.edu/~wiedeman/cspace/me/rgbyiq.html

You can play with sliders in realtime, you will find that -I is a greenish blue and +Q is a reddish blue. The full -I and +Q cause invalid RGB colors there as well.

Guada: I'm not sure I understand you. There is a precision loss in converting rgb<->YUV for sure, even with floating point. Imagine a diamond on graph paper. There's no way equal spaced dots on the lines could fit onto intersections of the graph paper. In the same way, there's a type of rotation between rgb and yuv.
HDTV, from a .ts file, uses Rec.709 colors, these have a brighter green, you can easily see the difference. To store them in an SD mpeg2 file (convert to dvd) you have to convert to Rec.601. Just write colorbars(720,480,rgb).coloryuv(matrix="Rec709") and you'll see.

Anyhow, the only thing I can do is draw a line between -I and white and see where it enters the valid rgb zone.

[IanB]

Yes, not all YUV (or YIQ) values have corresponding RGB values. This is not news.

For example :- At the maximum (235) and minimum (16) values of Y, UV (and IQ) must be zero (128).

The boundary of valid mappings looks like a skewed and distorted pair of pyramids base to base.

[Wilbert]

@jmac698

For some reason i can't make myself understandable to you. I know how to convert between YUV, YIQ and RGB. I just want to know where these numbers are coming from:

-I
R=-.956295
G=-.272558
B=-1.104744

What value for "I" did you use here to get the values for the RGB channels?

[IanB]

Please note The original RGB image, the one from Adobe, http://www.greatdv.com/video/smptebars3.htm, is [16..235]RGB, not the usual [0..255] RGB. The few YUV values I checked are correct for a RGB[16..235] -> Rec.601 -> YUV[16..235] translation. Note the PC.601 translation is very close but not exactly the same as this.

I agree, on the surface the +4 signal probably should be 25 not 24 but I suspect that some gamma correction may be involved (Adobe have strong ideas about gamma) which could account for this discrepancy. Many people have attested to the correctness of the Abobe values, so I would be reluctant to change this pattern. As we are implementing the pattern from NTSCBARS.BMP, changing values would mean we are no longer implementing this.

I have wanted to add an appropriate PAL versions of the pattern for sometime. If somebody wants to document and justify appropriate patterns, strong consideration will be given.

[jmac698]

@wilbert:
I used I=-1, Q=+1, assuming that is what was meant by -I, Q. The exact formula I used was the opposite of the one I already posted, but I haven't found it again.

Maybe I should find the -I,Q that is on the edge of valid rgb. As for changing to 25, I'm sure it's accurate as far as my understanding goes. As for the gamma theory, all these numbers are supposed to be on gamma corrected values at all times. If gamma were involved, I feel that it is quite likely the other values would be noticably different as well. My own suspicion as to why Adobe is different, is that they didn't derive it directly as I did. It's similar to the yellow error I found, in that a 10bit translation of 191,191,0 leads to Y=161, while a direct translation of .75,.75,0 (white=1.0) leads to Y=162. It's that close, within .03 error.

However, there is another argument. Even if we prove we have the best colorbars, it's not as useful in reality if 90% of studio equipment uses the slightly wrong, but defacto color bars. I would take hanfrunz measurements exactly, because that's what you will be comparing your capture card to on a TV testpattern.

Another point, -I,Q have no practical use anymore :)

hunfranz: can you do a digital measurement of the -I,Q and -+4 LUGE?

[Wilbert]

I think the formula is (the inversion of your system of equations in post 'Today 03:11'):

r = y + 0.9562948322*Q + 0.6210251253*I
g = y - 0.2721214741*Q - 0.6473809535*I
b = y - 1.106989908*Q + 1.704614975*I

so I=-1,Q=0 gives

# note that YUV is not the same as YCbCr
u = -0.8386705680
v = -0.5446390350

and thus

r = y - 0.6210251253
g = y + 0.6473809535
b = y - 1.704614975

I think rgb are scaled here right? So I need to multiply them with 255? Btw, what did you choose for y, just 0?

They are not exactly the same as your numbers ...

[jmac698]

Yes, in that format all numbers are supposed to be relative to 1. That's because, the recxxx coeficients add to 1. You know why I can't find my formula? Because the YIQ->YUV formula is also the YUV->YIQ formula, so I used that :) I need a matrix calculator, how did you invert that? Octave? Don't have time to do calculations now, later..

[Wilbert]

Btw, so when setting I=-1, you actually set I=-255 (non-scaled version). Are such values valid?

I use Maple for that. Here:

A = matrix([[a,b,c],[d,e,f],[g,h,i]]);

det(A) = a*e*i-a*f*h-d*b*i+d*c*h+g*b*f-g*c*e

inverse(A) = matrix([[e*i-f*h, -b*i+c*h, b*f-c*e], [-d*i+f*g, a*i-c*g, -a*f+c*d], [d*h-e*g, -a*h+b*g, a*e-b*d]])

[jmac698]

Does I=-1 mean I=255? No, I believe the Rec601 type of scaling would apply, so I=-1 means 16.

It's just like YUV:
Y=0 is 16
Y=1 is 235
Y'=Y*219+16

I=-1 is 16
I=0 is 128
I=1 is 240
I'=I*112+128

same for Q.

Btw, I means Inphase, Q means quadrature. This is a term from math/electronics; I means in the same phase as a reference (colorburst), and Q means 90deg out of phase. Fortunately, at the start of every rasterline there is a
calibration color signal known as the color burst, and from this sinewave,
the phase of the color signal is measured.

The sinewave then continues, at the same time as the luminence portion of
rasterline is sent, both signals varying to specify a color and luminance.

***
* * *
* * *
* * *
*-------*-------*----> Time
* *
* *
* *
***
ColorBurst Reference Signal

***
* *
* *
* *
--*-------*-------*--> Time
* * *
* * *
* * *
***
An Orange color 30 degrees
out of phase with ColorBurst

[jmac698]

Rec. ITU-R BT.801-1
100/0/75/0 colour bars (this refers to a 100% white bar with 0 setup followed by the other colorbars at 75% and 0 setup)
The table in the standard lists directly the YCbCr digital values, however with 300ns rise time included, this means 3 or 4 pixels of transition where it ramps to the next value. I extracted only the "stable" values in the middle of each colorbar.
Also, there was 15pixels of black border on each side and the bars were 87 pixels wide, in 720x480. Don't take these pixel sizes as accurate, it depends on context which I have to think carefully through.

Rec. ITU-R BT.801-1
Description of encoded colour-bar signals according to the 4:2:2 level
of Recommendation ITU-R BT.601
100/0/75/0 colour bars
color Y Cb Cr
white 235 128 128
yellow 162 44 142
cyan 131 156 44
green 112 72 58
magenta 84 184 198
red 65 100 212
blue 35 212 114
black 16 128 128


Description of encoded colour-bar signals according to the 4:2:2 level
of Recommendation ITU-R BT.601
100/0/100/0 colour bars
AND
Rec. ITU-R BT.1729
Appendix 2
100% colorbars
color Y Cb Cr
white 235 128 128
yellow 210 16 146
cyan 170 166 16
green 145 54 34
magenta 106 202 222
red 81 90 240
blue 41 240 110
black 16 128 128


-All these values are the same as http://forum.doom9.org/showthread.php?p=789629#post789629 by hanfrunz, A Sony DVW-A500P (internal pattern-generator) measured digitally. They are also the same as a program I wrote. I'm 99% sure of these, and they should supersede Premiere or any other indirect sources.
Note: the value for Yellow proves that the standards are based on exactly 75% colorbars, as opposed to RGB=(191,191,0), which converted to YCbCr in either 8bits or 10bits gives Y=161 instead of the true Y=162.

[jmac698]

measured avisynth colorbars
from script
Y=colorbars(width=720,height=480,pixel_type="YUY2")
#also tested same on type="YV12"
U=Y.UToY().pointresize(720,480)#yv12 is scaled 2x, 2y
V=Y.VtoY().pointresize(720,480)#yuy2 is scaled 2x
Return (MergeRGB(V,Y,U))

color Y Cb Cr
white 180 128 128
yellow 161 44 142
cyan 130 156 44
green 111 72 59
magenta 84 183 196
red 64 100 211
blue 34 210 114
black 16 128 128

from script
Y=colorbars(width=720,height=480,pixel_type="RGB32")
color R G B
white 180 180 180
yellow 180 180 12
cyan 13 180 180
green 13 180 12
magenta 180 16 180
red 180 15 14
blue 15 15 180
black 16 16 16

Compared to correct values, avisynth is wrong in all colors and all modes, by some small amount. I measured these through virtualdub,then in GIMP, to double check, I used coloryuv(analyze=true) and verifed directly in avisynth that blue and red are wrong.
The bar widths are 103 (@720x480) except green=102. Looks good.
Coming soon: correct
bmp workaround

[jmac698]

Following are 100/0/75/0 colour bars in separated y,cb,cr pictures. The values are checked and exact to the appropriate standards, however I'm only showing the 7 top colors like avisynth does.

To use, this script:
y=ImageSource("C:\MyVideos\y.bmp", pixel_type="rgb24")
cb=ImageSource("C:\MyVideos\cb.bmp", pixel_type="rgb24")
cr=ImageSource("C:\MyVideos\cr.bmp", pixel_type="rgb24")
cr=ConvertBackToYUY2(cr,matrix="PC.601").pointresize(360,
480)
cb=ConvertBackToYUY2(cb,matrix="PC.601").pointresize(360,
480)
y=ConvertBackToYUY2(y,matrix="PC.601")
colorbarsyuv=YToUV(cb,cr,y)

The output of this script is also exact, except for some interpolation at the color boundaries, however please do not try to convert this again to RGB. Instead use this:

colorbarsrgb=ImageSource("C:\MyVideos\rgb bars.bmp", pixel_type="rgb24")

[jmac698]

Having read standards all day, I say Y=25 for the +4 PLUGE.

SMPTE 170M-1999 has all the info you need. White is defined as 100IRE and setup as 7.5IRE, so there is no doubt. This should supersede any indirect references, I derived this directly from "first source" materials.

[jmac698]

Generate reference standard colorbars at home:
-get tvtool from tvtool.info/index_e.htm.
-Set the tv standard, but don't turn on tvmode.
There are colorbars displayed by default, which stay even if tvtool exits.
If you have a Philips SAA7104, I have a strong suspicion that the colorbars are exactly the standard values, as I checked the datasheet.
For this chip only, I strongly suspect the chip is outputting exact colorbars, and only variances in the components of the card could screw it up.
No driver or user settings have any affect on the colorbar testmode, that's how you can be sure of it. The same is usually true for other chips too. So this is a great way to make perfect colorbars.

[jmac698]

RS-189-A->EIA-189-A->EIA-189-A-1976->IA Standard EIA-189-A, July 1976, Encoded Color Bar Signal

This one has 7 color bars (75%, no white), -I,White,+Q, but no PLUGE or small color bars.

An improvement was made in SMPTE EG 1-1990 Color Bar Pattern which has the PLUGE and other bars. This is the standard avisynth is trying to duplicate.

These standards have the first colorbar is grey.

Another standard is fullfield 100% and 75%, as outlined above. The width of the bars is 1/7 of the active area. This would be 103/720 pixels, if 720 pixels represented the active area however the analog active area is about 703 pixels so there should be extra black borders.

[IanB]

Given all is derived from adobe's NTSCBARS.BMP the small errors in Wilberts, Sh0dans and My translation from RGB[16..235] back to YUV is as expected (This is why you should minimise RGB to YUV conversions, error accumulates!). The true value for the Yellow bar should have been r=g=180.25,b=16; 180.25=219*0.75+16; rounding to the nearest integer value gives r=g=180. Feeding this, 180, thru the appropriate formula results in Y=161.304 which is rounded down to 161. Feeding 180.25 thru give 161.5255 which rounds up to 162.

Apon closer examination the values actually in the code are slightly strange.static const int top_two_thirds[] =
{ 0xb4b4b4, 0xb4b40c, 0x0db4b4, 0x0db40c, 0xb410b4, 0xb40f0e, 0x0f0fb4 };Note the black levels are not exactly 0x10 as would be expected and as documented on the referred to site. Now these values actually agree with my copy of NTSCBARS.BMP, so the original colorbars author has obviously just ripped these values. All this leads me to believe this image was NOT digitally generated but has most likely been captured and converted.

Given this slight black level error, it could explain the +4 pluge value being only 24 instead of 25. I can find nowhere that any propper integer truncation will cause a value of 24.

Given for NTSC White Y=1.0 -> y=235, IRE=100 and Setup Y=0.0 -> y=16, IRE=7.5, this implies 1 IRE=(235-16)/(100-7.5)= 2.3676 which gives +/-4 pluge as 16+/-4*2.3676= 25.470, 6.530 and rounding gives 25, 7

As a point of interest 0 IRE seems to want to be -1.757 and y=0 is +0.742 IRE

[jmac698]

First, I apologize for the cross post. In my mind, this was originally a question, now that it has turned to a certainty, I feel valid now in posting it as a confirmed bug. Also I didn't think you still followed this thread.

I'm glad you now agree the Adobe must be in error. The IRE is still a derived calculation but simple and certain. The other values are directly listed in a table with no room for misinterpretation.

Now that we agree, it is only a difference in philosophy that you use a defacto standard (among those who believe Premiere in current version is accurate), and the real standard (which is proven true for studio test equipment (Sony DVW-A500P)). Right?

So I will complain to Adobe, then we shall all agree ;)

0IRE: no need to encode it. 16 is chosen arbitrarily for headroom. Sync pulses have a special code in bt.656 (in reality they are negative). IRE itself is only american and arbitrary somewhat.

[IanB]

So I will complain to Adobe, then we shall all agree ;)Good luck!

[jmac698]

This is still a problem that needs to be solved, and I don't think any opensource author has done it. I quote from mjpegtools,
y4mcolorbars
y4mcolorbars creates a YUV4MPEG2 stream consisting entirely of frames
containing a colorbar test pattern. The pattern attempts to reproduce the
standard SMPTE EG-1-1990 colorbar test signal as faithfully as possible,
given the constraints of the Y'CbCr colorspace.

...
Data to place in the "-I/+Q" patches in the bottom row of the pattern:
0 - -I and +Q at 20% (20IRE) [default]
1 - -I and +Q at 50% (50IRE)
2 - +Cb and +Cr at 100%
...
"BUGS"
First, it's not clear to the author (who hasn't actually ever seen the SMPTE
EG-1-1990 document itself) what the absolute excursion of the -I and +Q regions
is supposed to be; however, the phase is correct, and that should be the
critical feature. Second, the PLUGE bars, of -4 and +4 IRE, can never be
precisely synthesized --- the Y' digital space maps [16,235] over the
full luma excursion, but the full luma excursion in analog space depends
on whether or not 7.5 IRE NTSC setup is being used by whatever device
eventually produces the analog output. However, the difference
is within 1-bit of Y' accuracy anyway.

I agree it should be 20%, so now we have a level. I still need to do a calculation, however.

Now the most important part, the author did what I was going to do, just reduce until it fits as legal colors:
* Classic colorbars have -I and +Q in the PLUGE section.
*
* Following Poynton, "Digital Video and HDTV", p367:
*
* -I = (-0.955987, +0.272013, +1.106740) R'G'B'
* +Q = (+0.620825, -0.647204, +1.704231) R'G'B'
*
* Converting to Y'PbPr and Y'CbCr:
*
* -I = (0, 0.624571 -0.681873) -> (16, 268, -25)
* +Q = (0, 0.961755 0.442815) -> (16, 343, 227)
*
* Uh, oh: these are outside of the Y'CbCr gamut.
* We can get around this, kind of, by reducing the magnitude until they
* fit, keeping the phase the same. Q is the worst offender, and a factor
* of 0.5 does the trick:
*
* (0.5)*(-I) = (0 0.312286 -0.340937) -> (16, 198, 52)
* (0.5)*(+Q) = (0 0.480878 0.221407) -> (16, 236, 178)
*
* (0.2)*(-I) = (0 0.124914 -0.136375) -> (16 156 97)
* (0.2)*(+Q) = (0 0.192351 0.088563) -> (16 171 148)

I also note the author made the colorbars from RGB equivalents, probably not realizing this introduces a small error.

Therefore, I think at the moment, :
-I -> (16 156 97) (Y U V)
+Q -> (16 171 148)

He got the +-4IRE right, with 7 and 25.

[jmac698]

Colorbars of the Web

Ref Color Y Cb Cr R G B
1 White 235 128 128 255 255 255
2 235 128 128 235 235 235
3 235 235 235 255 255 255
4 255 255 255
5 255 255 255

Grey 180 128 128 191 191 191
2 180 128 128 180 180 180
3 180 180 180 204 204 204
4 206 206 206
5 191 191 191

1 Yellow 162 44 142 191 191 0
2 161 44 142 180 180 12
3 180 180 16 255 255 0
4 206 206 0
5 191 191 0

1 Cyan 131 156 44 0 191 191
2 130 156 44 13 180 180
3 16 180 180 0 255 255
4 0 206 206
5 0 191 191

1 Green 112 72 58 0 191 0
2 111 72 59 13 180 12
3 16 180 16 0 255 0
4 0 206 0
5 0 191 0

1 Magenta 84 184 198 191 0 191
2 84 183 196 180 16 180
3 180 16 180 255 0 255
4 206 0 206
5 191 0 191

1 Red 65 100 212 191 0 0
2 64 100 211 180 15 14
3 180 16 16 255 0 0
4 206 0 0
5 191 0 0

1 Blue 35 212 114 0 0 191
2 34 210 114 15 15 180
3 16 16 180 0 0 255
4 0 0 206
5 0 0 191

1 Black 16 128 128 0 0 0
2 16 128 128 16 16 16
3 16 16 16 19 19 19
4 20 20 20
5 16 16 16

0 +4 IRE 25 128 128 11 11 11
2 24 128 128 24 24 24
3 24 24 24 38 38 38
4 40 40 40
5 24 24 24

0 -4 IRE 7 128 128 -11 -11 -11
2 7 128 128 7 7 7
3 7 7 7 0 0 0
4 0 0 0
5 7 7 7

0 -I 16 156 97
2 24 152 111 0 29 66
3 0 29 66 8 62 89
4 34 79 138
5 0 29 66

0 +Q 16 171 148
2 23 167 143 44 0 92
3 44 0 92 58 0 126
4 88 46 122
5 44 0 92

References:
0 My calculations
1 Rec. ITU-R BT.801-1
2 www.avisynth.org, Version 2.56, ColorBars(), based
on NTSCBARS.BMP from Adobe Premiere
3 http://www.greatdv.com/video/smptebars3.htm, written yuv
and rgb from picture
4 http://www.mivs.com/technical/colorbars.html
5 http://en.wikipedia.org/wiki/SMPTE_color_bars


Conclusion: everyone is different! Never trust some random reference on the web, you have to figure it out very carefully yourself.

[IanB]

@jmac698,

Thanks. And to confirm I got this by approaching it from the TV signals angle.

NTSC Chrominance signal uses scaled axis of 0.877(R-Y) and 0.493(B-Y). The I subcarrier phase is advanced 33 degrees to (R-Y). And the Q subcarrier phase is -90 degrees from the I.

The +Q test signals in this realm is defined as 0% luminance (black) with 20% amplitude Q only chrominance. The -I test signals is likewise defined as 0% luminance (black) with 20% amplitude inverted phase I only chrominance.

Thus assigning a reference phase of 0 degrees for the (B-Y) signal the +Q phase will be 33 degrees and the -I will be 303 degrees. And of course Y=0 gives y=16.

Solving for +Q :-
0.493*(B-Y)=0.2*cos(33deg)
(B-Y)=0.2*cos(33)/0.493=0.3402
u=128+(B-Y)*256/2.018=171.16 => 171
0.877*(R-Y)=0.2*sin(33deg)
(R-Y)=0.2*sin(33)/0.877=0.1242
v=128+(R-Y)*256/1.596=147.92 => 148

Thus +Q = yuv{16, 171, 148}

And likewise for -I
(B-Y)=0.2*cos(303)/0.493=0.2209
u=128+(B-Y)*256/2.018)=156.02 => 156
(R-Y)=0.2*sin(303)/0.877=-0.1913
v=128+(R-Y)*256/1.596=97.32 => 97

Thus -I = yuv{16, 156, 97}Both agreeing with your result.

Converting to RGB[16..235] gives
+Q = rgb{43.2, -12.3, 90.5}
-I = rgb{-25.9, 27.9, 64.4}
which if you clip negative values to zero are fairly close to the NTSCBARS.BMP values of
+Q = rgb{44, 0, 92}
-I = rgb{0, 29, 66}

(Again more evidence the image was captured not generated)

Also in your calcs above you should note the range for each of the references. Most are RGB[0..255] and YUV[16..235]. NTSCBARS is RGB[16..235] which is very significant.

[jmac698]

@IanB:

Awesome job!! Those are the ideal calculations and I agree with them. It's good to have the precision if we ever have to deal with 10bit video.

I noticed that about my table, but I didn't feel like finishing it at the time. I'm curious to see how they would all look if normalized to one standard, probably 16,235 to eliminate comparing quantization errors.

Today we've changed one small part of the world :) I've already contacted the y4colorbars author.

If I can just finish calculating saturation, and PixelInfo() gets finished, I'll be able to write a calibration script and now everyone will have ideal analog caps!

THIS WAS GREAT TEAMWORK!!

[IanB]

One last issue before I hack into the code. As currently speced the RGB[16.235] image the +Q and -I panels will not result in the correct hue if negative values are truncated to zero.

As the important attribute of these test signals is the phase, 33 and 303 degrees, I think we should aim to maintain this. I can see two solutions :-

1. Reduce the saturation from 20% such that G=0 for the +Q panel, and R=0 for the -I panel.

+Q = rgb[16..235]{31.4, 0, 58.1} sat=11.3%
-I = rgb[16..235]{0, 20.6, 34.5 sat=7.6%

2. Keep the saturation at 20% and add a small amount of luminance such that G=0 for the +Q panel, and R=0 for the -I panel.

+Q = rgb[16..235]{55.5, 0, 102.8} lum=5.6%
-I = rgb[16..235]{0, 53.8, 90.3 lum=11.8%

Thoughts????

[jmac698]

First, I have a reference that -I, Q should be at +-20IRE or 40IRE peak to peak. white is 100IRE and 75% saturated colorbars, in yellow and cyan, should reach 100IRE. Therefore -I,Q should be at 15% saturation. Does that work and make sense?
How about, .2*.75*224=128+-33.6 in digital codes. What does that give? It would mean 78% again of saturation, or .15 instead of .2 in the original equation.
So I get
+Q (16,160,143)->24 0* 65
-I (16,149,105)->0* 10 42
Hmm, try your scale.

Need to think more, not now. Ps, it certainly seems possible that RGB could never store colorbars, and to use a .bmp as a reference is really bad! (let's shoot Adobe...)

[IanB]

Okay I can easily believe 20IRE instead of 20%. But surely this translates to 20/92.5*100=21.62% not 15%. We are talking about the peak amplitude of the resultant composite NTSC signal.

+Q=yuv{16, 175, 150}=rgb[16..235]{45.4, -14.6, 96.6}
-I=yuv{16, 158, 95}=rgb[16..235]{-29.3, 28.9, 68.3}it certainly seems possible that RGB could never store colorbars,And that is the point of my previous post, even using rgb[16.235] the require signal is simply a lot out of range, hence my 2 suggestions. The 20IRE bit doesn't effect 1. the constraints are the reduce the saturation to suit the limits of G=0 and R=0. For 2. the increased chroma amplitude requires a bit more Y to offset it.

Also a friend has suggested that the +Q and -I amplitudes should be the same, thus the -I constraint should dominate.

[jmac698]

I agree, I'd like to see them the same. Well, if I had a choice I'd raise the luminence, this shouldn't affect a vectorscope at all, but keeps hue and saturation the same.
Raising it to just fit is as good as anything.

[IanB]

Thus I should proceed with these numbers

+Q=yuv{16, 174.7, 149.5}
-I=yuv{16, 158.3, 94.8}

+Q=rgb[16..235]{74.7, 14.6, 125.8} Y=13.4%
-I=rgb[16..235]{0, 58.2, 97.6} Y=13.4%

[jmac698]

I'll call it done. If I can find proper I,Q levels in YUV I'll let you know.. it's only a line of code. Just warn me before you release 2.57. You also have to be careful of the boundaries of 4:2:0 mpeg2 style subsampling. Not sure how you're handling that. It's too bad we can't write perfect DV colorbars.
No time today to check translation between digital and IRE for color...

[IanB]

For YUV we rig the width/height of the bar elements to align with the chroma subsampling.

An alpha 2.5.7 will be out soon.

[jmac698]

Ok, with Y/C as [0,1], Composite=3/40+37/40Y+37/40C
Or, composite=7.5IRE+.925Y+.925C
With Y=0 (and ignoring setup), 20IRE=.925C, C=1/.925*20=21.62IRE or .2162 out of 1.

My own calculations give:
+Q {16,175,150}
-I {16,158,95}
which agrees with you.

The final +Q is further from Adobe than the 20% values, while the -I is actually closer. I have to wonder if the original colorbars were accurate? I am still certain of these values however.

Real TV's must use some offset in RGB, because the point of PLUGE is to adjust brightness until black is just 0. So black level must be applied before conversion to RGB.

I'll test your alpha. ps could you help hanfrunz with his filter?
http://forum.doom9.org/showthread.php?t=108602

[Wilbert]

Talking about the PLUGE. Shall we include the PLUGE when showing the bars for Rec.709? Most of it stays the same, except the -I/+Q stuff. I guess it doesn't really make sense to include it?