ColorBars test pattern references

[jmac698]

Hello,
after extensive research, directly of the standards, I have found wrong colors in colorbars(). I have provided references and bmp's with correct values. More available at http://forum.doom9.org/showthread.php?t=107682&page=2 in case you hadn't looked.

[Wilbert]

For clarity, only the +4 IRE values is wrong, no?

[jmac698]

Sorry but all the colors are wrong, in every mode.
http://forum.doom9.org/showthread.ph...961#post794961 correct values, directly from table in standard
http://forum.doom9.org/showthread.ph...006#post795006 measurements of colorbars()

[Wilbert]

Ok, i didn't read the whole thread carefully As you notice, it's all due rounding errors. It will be corrected in the next version ...

[jmac698]

I know it's a lot to read, I have a feeling no one is reading it anymore, but after talking to myself a long time I reached a conclusion

[IanB]

As I noted it the Using thread, the core problem is the Adobe NTSCBARS.BMP which all is based on is slightly out of whack. We have compounded the problem by converting back to YUV and doubling the error due to rounding and truncation.

I do not have a problem tweaking the YUV values towards the provided values such that a single YUV[16..235] -> RGB[16..235] conversion return the original NTSCBARS.BMP results.

I am however reluctant to just correct the values used in the original RGB source without understanding where they came from. The errors are more than simple rounding errors! The Adobe BMP's for better or worse are a defacto standard in there own right.

As I also said in the using thread I have wanted to add PAL versions of the patterns. So I propose to leave the NTSCBARS.BMP as the default (with intelligent YUV rounding) and add mathematically correct NTSC and PAL versions of the appropriate patterns as options.

[jmac698]

First, I think you need to be updated. I've downloaded all the actual standards and read them.
Validation of research: I have no doubt my new values are correct. They come directly from a table, there is no room for interpretation, they match by calculation, they match by measurement, they match by two sources of direct listing. Download yourself at http://ecs.itu.ch/cgi-bin/ebookshop, Bt801-1.

Is colorbars(pixel_type = "RGB32") the basis for any conversions, therefore derived from Adobe?

I see no pattern in the errors. Theory: precompensated RGB for rgb->yuv? Otherwise, it's just wrong. Adobe was well known to be wrong in last version.

I *do* see a point to using defacto standards. My version is defacto too, was checked with professional equipment and matched exactly, yet defacto Adobe got known to be wrong, and ppl avoided it.

I suggest direct generation in yuv/rgb spaces.

PAL versions: There are several standards for testpatterns, not all of them are colorbars. A common one, is just the 7 colors, beginning with white, and 75% otherwise. This is valid for both NTSC and PAL. The tvout card automatically corrects the property called "setup".

mathematically correct NTSC and PAL versions

I am no longer advocating mathematically correct, I am simply repeating a table from the standard. There is no room for error. (And they are also mathematically correct).

[IanB]

Is colorbars(pixel_type = "RGB32") the basis for any conversions, therefore derived from Adobe?

Yes, the original ColorBars() was apparently ripped from NTSCBARS.BMP, I do not know who originally wrote it, I guess must have been Ben Rudiak-Gould, it was in the original project Richard created source.cpp 1.1, Wilbert added the pixel_type="YUY2" fairly recently and directly calculated the YUV values from the existing RGB, I added the the "YV12" soon after.

Any new numbers will be referenced or calculated in the correct initial colour space and converted once to the other colour space.

Can you please concisely tabulate in one post in this thread all your relevant numbers with references urls and/or standard publication names with page numbers.

Also if you have stumbled across some rec.709 patterns in your research please include them as well.

[jmac698]

Rec. ITU-R BT.801-1, Annex 2, P13-15, http://www.itu.int/rec/R-REC-BT.801-1-199510-I/en

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

Rec. ITU-R BT.1729, Page16, http://www.itu.int/rec/R-REC-BT.1729-0-200504-I/en

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

Rec.709 colorbars are also there.

SMPTE 170M-1999, Page 7, http://www.smpte.org/smpte_store/sta...&CurrentPage=5

White Level.....100IRE
Black (Setup) Level... 7.5IRE

Derivation, 92.5IRE=[16,235]

[IanB]

@jmac698,

Good post. Ta muchly!

Also can you please edit the name of this thread to be

ColorBars test pattern references

[hanfrunz]

i found another interesting EBU-document:

http://www.ebu.ch/CMSimages/en/tec_d...tcm6-37146.pdf

[jmac698]

EBU Tech 3305,Digital Television Test Pattern Sequence for
Operational Use, Page9, Pattern 2, http://www.ebu.ch/CMSimages/en/tec_d...tcm6-37146.pdf , Same as 100/0/75/0 colorbars.

Don't forget, register at http://ecs.itu.ch/cgi-bin/ebookshop to download ITU documents yourself. One of them even includes SMTPE1700 (BT.1700).

added Wilbert: updated link: https://tech.ebu.ch/files/live/sites...h/tech3305.pdf

[Mug Funky]

just for fun, i wonder what would happen if i get one of the decks here (DVW-A500P) to output PAL colourbars and capture them to 8-bit uyvy? i wonder which spec it'd match. after all, Sony are also big fans of making their own standards.

btw, the avisynth bars look a lot better than those output from premiere pro (they're so wrong it's hilarious). so much so that i'm using colorbars() on heads of DV tapes that i've exported lately. at the very least, they look just like ones that come out of the decks, so rounding/whatever error must be small.

[jmac698]

I suggest to use my colorbars in
http://forum.doom9.org/showthread.ph...068#post795068
Avisynth's are inaccurate.
I think Adobe uses a special scaling that can show full Y range.

Please make your test and report back. You will have to use this script to measure YUV, load the script in virtualdub, copy source frame to clipboard, paste to a paint program, then use the dropper tool, and "pretend" G is Y, B is U, R is V.

Y=avisource("...")
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))

I think you will see the standard Rec. ITU-R BT.1729, known as 100/100 full field.

[Wilbert]

avisource("...")
pointresize(720,480)

will do fine

[jmac698]

It would be fine if you want to measure RGB, but that involves a conversion. If you can read YUV, you can get the values originally stored in the cap. I'm using my script to copy YUV->GBR. Now it looks very strange, but at least you can measure the original YUV in a paint program.

[SeeMoreDigital]

Originally Posted by jmac698

Now it looks very strange, but at least you can measure the original YUV in a paint program.

Indeed...

HyperSnap allows you to assign values of anything between 000-255 for red, green and blue. I've been using it to read and change the colour values of individual pixels for some time

[Wilbert]

It would be fine if you want to measure RGB, but that involves a conversion. If you can read YUV, you can get the values originally stored in the cap. I'm using my script to copy YUV->GBR. Now it looks very strange, but at least you can measure the original YUV in a paint program.

Yes, it was a dumb remark. What I wanted to say was, why not use

AviSource(...)
Crop(...) # crop to a color bar
ColorYUV(analyze=true)

to read of the YUV values?

[jmac698]

Yes, that works too. It's the method used by hanfrunz recently to measure his colorbars. Personally I found it easier to use the first method than to figure out the correct crop commands at least 7 times.
Even better would be PixelInfo()

[Wilbert]

@jmac698,

I'm looking at BT.1729, but they only list 100/0/100/0 bars for Rec.709. I can calculate the 100/0/75/0 by hand, that's not the problem. But i was wondering why 100/0/75/0 bars is not listed there? Perhaps we should list it as an option to return the 100/0/75/0 or 100/0/100/0 bars?