Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
6th March 2006, 21:20 | #1 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
ColorBars test pattern references
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. Last edited by jmac698; 7th March 2006 at 16:06. |
6th March 2006, 22:49 | #3 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
all wrong, sorry :(
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() |
7th March 2006, 04:23 | #6 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
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. |
7th March 2006, 06:31 | #7 | Link | |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
validation
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". Quote:
|
|
7th March 2006, 07:52 | #8 | Link | |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
Quote:
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. |
|
7th March 2006, 08:47 | #9 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
references
Rec. ITU-R BT.801-1, Annex 2, P13-15, http://www.itu.int/rec/R-REC-BT.801-1-199510-I/en
Code:
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 Code:
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 SMPTE 170M-1999, Page 7, http://www.smpte.org/smpte_store/sta...&CurrentPage=5 Code:
White Level.....100IRE Black (Setup) Level... 7.5IRE Last edited by jmac698; 7th March 2006 at 08:57. |
7th March 2006, 16:12 | #12 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
Another one
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 Last edited by Wilbert; 11th April 2015 at 16:55. |
17th March 2006, 00:55 | #13 | Link |
interlace this!
Join Date: Jun 2003
Location: i'm in ur transfers, addin noise
Posts: 4,555
|
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.
__________________
sucking the life out of your videos since 2004 |
17th March 2006, 04:55 | #14 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
try these; do your test
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. Code:
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)) |
17th March 2006, 17:15 | #16 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
Measuring YUV
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.
|
17th March 2006, 17:30 | #17 | Link | |
Life's clearer in 4K UHD
Join Date: Jun 2003
Location: Notts, UK
Posts: 12,227
|
Quote:
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
__________________
| I've been testing hardware media playback devices and software A/V encoders and decoders since 2001 | My Network Layout & A/V Gear |
|
|
17th March 2006, 17:46 | #18 | Link | |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
Code:
AviSource(...) Crop(...) # crop to a color bar ColorYUV(analyze=true) Last edited by Wilbert; 17th March 2006 at 17:50. |
|
17th March 2006, 18:07 | #19 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
analyze to measure YUV
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() Last edited by jmac698; 17th March 2006 at 18:10. |
20th March 2006, 00:14 | #20 | Link |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
@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? |
Tags |
colorbars theory |
Thread Tools | Search this Thread |
Display Modes | |
|
|