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. |
22nd February 2006, 05:51 | #1 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
Are rec601 levels possible??
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? |
22nd February 2006, 07:55 | #2 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
still doesn't add up
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. |
22nd February 2006, 10:47 | #3 | Link | ||
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
I didn't check the numbers of jmac698, but i guess they are correct and the same as the upper bars in ColorBars.
Quote:
Quote:
The pluge signal of "-4" is the one that falls outside [16,235]. |
||
22nd February 2006, 13:57 | #4 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
pluge
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. |
22nd February 2006, 21:22 | #5 | Link | |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
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? |
|
23rd February 2006, 04:15 | #6 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
Secrets of PLUGE
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? Last edited by jmac698; 23rd February 2006 at 04:22. Reason: btw,... |
23rd February 2006, 11:04 | #7 | Link | ||||
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
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. Quote:
Quote:
Code:
ColorBars(pixel_type="RGB32") Crop(...) RGBAdjust(analyze=true) Quote:
Quote:
Code:
ConvertToXXX(matrix="PC.601") # and "PC.709" Last edited by Wilbert; 23rd February 2006 at 11:08. |
||||
23rd February 2006, 11:25 | #8 | Link |
Registered User
Join Date: Feb 2002
Location: Germany
Posts: 540
|
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 |
23rd February 2006, 11:38 | #9 | Link | ||
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
Quote:
|
||
23rd February 2006, 12:52 | #10 | Link | |
Registered User
Join Date: Feb 2002
Location: Germany
Posts: 540
|
Quote:
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 Last edited by hanfrunz; 23rd February 2006 at 13:03. |
|
23rd February 2006, 16:58 | #11 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
much ado about yellow
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? Last edited by jmac698; 23rd February 2006 at 17:02. |
23rd February 2006, 17:23 | #12 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
choice of patterns
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. |
23rd February 2006, 22:31 | #13 | Link | |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
|
|
25th February 2006, 23:06 | #15 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
Yiq
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. |
26th February 2006, 02:15 | #16 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
PAL color bars
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...standards.html |
27th February 2006, 22:37 | #17 | Link | |
Registered User
Join Date: Feb 2002
Location: Germany
Posts: 540
|
Quote:
|
|
28th February 2006, 23:05 | #18 | Link | ||
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
@jmac698,
Quote:
Quote:
|
||
1st March 2006, 00:28 | #19 | Link |
Registered User
Join Date: Feb 2005
Location: Lyon
Posts: 718
|
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? |
1st March 2006, 03:11 | #20 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
yiq formula; the squares in colorbars
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. |
Tags |
colorbars +q -i, colorbars theory |
Thread Tools | Search this Thread |
Display Modes | |
|
|