16-235 & smpte

[Mounir]

I'm trying to figure out how the smpte 170m is supposed to look like with 16-235 levels especially for the UV colors.

Please download it from here (http://en.wikipedia.org/wiki/File:SMPTE_Color_Bars.svg) and enlighten me, i'm lost.

Result of the analysis here (http://img3.imageshack.us/img3/2645/ysisw.png)

The script i use:

function int2mode(int index) { return Select(index, "classic", "levels", "color") } # HISTOGRAM
ImageSource("C:\smpte170mOG_(wikipedia)-%04d.png", 1, 1, 25.000, use_DevIL = true)
ConverttoYV12(matrix="rec601",interlaced=false)
ColorYUV(analyze=true)
Histogram(int2mode([<"HistogramMode", 0, 2, 2>])) # HISTOGRAM
ConverttoYUY2(interlaced=false) # VIDEOSCOPE
VideoScope("both", true, "Y") # VIDEOSCOPE


Note:
If you could upload the picture with your tweaks that'd be awesome

[2Bdecided]

In that image, the colour bars and white level are correct for RGB 0-255 video, but the black level isn't correct for anything AFAICT. It's trying to show NTSC's 7.5% set-up, but that doesn't (shouldn't!) appear in the digital world - it would be added by the analogue video encoder as the digital video was transformed to NTSC-M analogue. I think you can only treat that wikipedia graphic as an indication of what it should look like (unless there are accurate YUV values hidden in a different format of the image which I haven't found), rather than something that's accurate.

You can't include a PLUGE signal in RGB 0-255 video. Or I-only. Or Q-only. This pages discusses some of the issues...
http://www.kozco.com/calibrat/bars.htm

Does this help?
http://avisynth.org/mediawiki/ColorBars_theory

Cheers,
David.

[Mounir]

What i want is a measure with ColorYUV(analyse=true). The image is rgb if you convert it to YV12 i don't understand what would be the problem to show me what are the correct YUV values for 16-235 ? Perhaps it's too technical i don't know...

Edit:
You're saying this pattern is valid for 0-255 rgb yet the darkest black in this pattern equals 9 rgb at least on my monitor.

What i know about IRE & RGB (Analog vs Digital) is:
0 IRE- 108 IRE = 0-255 RGB
7.5 IRE - 100 IRE = 16-235 RGB
120 IRE = max value (never used)

[Mounir]

I'm back at it today.
Can someone with the knowledge take a look at this new smpte pattern i've made with procoder and tell me if it's more accurate, many thanks in advance:

Link: http://img15.imageshack.us/img15/7900/smpteprocoder.png

[Mounir]

Ive made a little comparison between the smpte pattern from wikipedia (http://en.wikipedia.org/wiki/File:SMPTE_Color_Bars.svg) and this (http://en.wikipedia.org/wiki/File:SMPTE_color_bars_on_NTSC_vectorscope.png) that's supposed to be a representation of 75% smpte and here is what i find (http://img842.imageshack.us/img842/6507/resultz.jpg).
I'm not sure of the accuracy because in the vectorscope it certainly is YUV but still...

Edit:
Here is a little correction (http://img856.imageshack.us/img856/2059/108irecorrection.jpg) i've made as i believe the waveform's max value is 120 IRE so i've cut to 108 IRE and upsized to match with the avisynth vectorscope in the hope this is accurate now (i doubt it though , Cyan & red are too high.

[Mounir]

Here is (http://img843.imageshack.us/img843/3717/resultbasedsmptecolorba.jpg) what i get when i modify the smpte (wikipedia) according to the vectorscope representation. I'm not able to get the IQ intensity and hue right though . More here (http://img189.imageshack.us/img189/2899/777zd.jpg).
What do you think?

[2Bdecided]

Isn't it just this if you want "PAL"...

colorbars(width=720,height=576,pixel_type="YV12")
changefps(25)
...and just colorbars(pixel_type="YV12") if you want NTSC?

http://avisynth.org/mediawiki/ColorBars

Cheers,
David.

[Mounir]

Thanks 2Bdecided i didn't know you could do this.
I'm tryin to analyse them but there are differences between the RGB32 & YV12. The RGB32 is natively with 16-235 levels whereas the YV12 isn't (0-255) so i'm using the Levels filter (output 16-235) but guess what the I,Q components don't produce the same effect (they're darker on the YV12).
Even stranger is the result of ColorYUV(levels="PC->TV") ... it does nothing !?
So again i'm left in the dark

[poisondeathray]

You're using the wrong matrix

When you convert to yuv from an rgb still image that has RGB 0,0,0 - 255,255,255 use a pc matrix in avisynth

RGB 0-255 => YUV 0-255

The pluge area 0-16 will become black and 235-255 will become white when decoded with regular rec601 matrix (ie. when decoding the YUV video and converted back to RGB for display)

If you want to do some tests you can use a belle nuit test chart. It gives you more information, including Rec601/709 stripes (read the instructions on how to interpret this)

http://www.belle-nuit.com/testchart.html

[Mounir]

Can you upload the colorbars for me in YV12, YUY2 16-235 only

[poisondeathray]

Can you upload the colorbars for me in YV12, YUY2 16-235 only

I don't understand what your're asking

You want the YUV content in 0-255 (full range, with superdarks and superbrights) when using a testchart derived from RGB.

So when the YUV video is converted BACK to RGB using Rec601 conversion, 0-16 and 235-255 become white & black respectively. That's how you use test charts

If you want to see how it would appear using Rec601

ImageSource("bellenuit.tif")
ConvertToYV12(matrix="Pc.601")
ConvertToRGB(matrix="rec601")

Comment out the last line if you are encoding a YUV video



I suspect your confusion is with RGB vs. YUV. You're not looking at YUV directly. You're looking at the RGB conversion or representation of that YUV video. When you specify Rec601 Y' 16-235 => RGB 0,0,0 - 255,255,255 . Ie. "black" is mapped to RGB 0,0,0 and "white" is mapped to RGB 255,255,255

[2Bdecided]

The I and Q test signals cannot exist in RGB colour space.

Stop trying to do the impossible, then you will get less frustrated! ;)

Cheers,
David.

[Mounir]

I found out myself using Procoder & Rec601. The result i get in YV12 is the same than the colorsbar(pixel_type="RGB") with a lighter I & Q which is what i suspected from the get go with some approximation though, picture here (http://img860.imageshack.us/img860/148/procoder.png)
RGB = YV12
16 = 15 (black
235 = 234 (white)

And so on

[IanB]

There was a lot of anguished discussion about this back in 2006. Start with this post "Are rec601 levels possible??". And related is this thread "ColorBars test pattern references".

And from the 2nd link in post #2 by 2Bdecided above...
While ycbcr is a valid color, the corresponding rgb value is not, since r is negative. Instead of rounding it to zero, the luminance is highered to make red zero (this is done in in AviSynth v2.57). As a consequence the green for the +Q signal is also positive. This way the phase of the YIQ signal is preserved. r is zero for R = -16/219 = -0.0731, and thus Y_601 = -0.0731+0.2067 = 0.1336. It follow that: ... (http://avisynth.org/mediawiki/ColorBars_theory)
Important things to note are both YUV and RGB patterns are [16..235], within Avisynth this is normal for YUV but abnormal for RGB.

In the RGB mode the +Q and -I signal have been tweaked slightly by increasing the luminance to ~13.4% so that R=0 for the -I panel, with the +Q panel following suite.

[Mounir]

Hmm interesting fact when i do a convertion colorsbarsYV12 > rgb32 (PC.601) i get a darker I & Q than, see picture (http://img850.imageshack.us/img850/3873/yv12rgbpc601.jpg)


colorbars(width=720,height=480,pixel_type="YV12")
ConverttoRGB32(matrix="PC.601",interlaced=false)


I don't understand why it's so dark in YUV though

[IanB]

WTF are you talking about. Did you read the threads I pointed to, all the maths is discussed there.

The +Q and -I are out of gamut signals! What you see for these is a side effect of how out of gamut signals are handled in the various displays.

ColorBars(pixel_type="YV12") produces accurate correct Rec.601 levels complete with out of gamut diagnostic signalling.

ConverttoRGB32(matrix="PC.601") with Rec.601 input will result it [16..235] RGB which will seem dark when processed in a system expecting [0..255] RGB.

Note: ColorBars(pixel_type="YV12").ConverttoRGB32(matrix="PC.601") is NOT the same as ColorBars(pixel_type="RGB32") the out of gamut values are handled differently.

[Mounir]

I'm back at it again in the hope to gather further info about something i do not quite understand but first thing first see this picture (http://imageshack.us/f/840/yv12.jpg/) after what someone may explain to me the significance of the 7 measured by coloryuv instead of 16 (One would except to see 16 somewhere i believe). Colorbars generated with avisynth indeed in YV12

[poisondeathray]

7 is darker than 16 . There are supposed to be "blacker than black" patches on the pluge bar, that's how you calibrate your TV

Look at your videoscope at the left stripe of the pluge bar, there is a line below Y=16, that is Y=7 . That is "blacker than black" and should correspond to IRE=3.5

[Ghitulescu]

Unless you're using a PC monitor aware of the Video levels, all your tests are useless.
For me is not really clear your intentions, but there are several companies that sell calibration tools/discs (I think there's a free DVD, too, among them) if that's what you're after. PC <-> Video levels change is only needed when one decides to pass from one type to another (inserting a photo into a video, or vice-versa, recoding a video to be watched on PC).

[Mounir]

So if i adjust the black level with a + 9 that would give me a good picture of how a ntsc video should look like, right ?
I don't have a videoscope, i'm trying to determine how a ntsc video should look like "ideally" (on a scope) if fine tuned correctly, black level specifically

Edit:
+9 (with Ylevels) give me This (http://imageshack.us/photo/my-images/195/yv12level9.jpg/)

[poisondeathray]

So if i adjust the black level with a + 9 that would give me a good picture of how a ntsc video should look like, right ?
I don't have a videoscope, i'm trying to determine how a ntsc video should look like "ideally" (on a scope) if fine tuned correctly, black level specifically

Edit:
+9 (with Ylevels) give me This (http://imageshack.us/photo/my-images/195/yv12level9.jpg/)


No. It should look the 1st screenshot. You shouldn't be able to see "blacker than black" area. The left most bar of the pluge area should not be distinguishable - it should look the same as the middle third . You should read up on monitor calibration and pluge bar

[Mounir]

Ok so when most people refer to 16-235 levels they don't realise it should be 7 - 235 (YUV) then , that's funny

[poisondeathray]

Ok so when most people refer to 16-235 levels they don't realise it should be 7 - 235 (YUV) then , that's funny


Nope, Y' should be 16-235 , with small excursions being acceptable.

You're not meant to see the 7, it's blacker than black . It's only detectable on waveform or on poorly calibrated monitors. If you see the demarcation, you know you've gone to far .

Have a look at the videoscope at the small line below 16 . It's only included so you can adjust equipment . Just like Y' >235 patches are often included in calibration videos so you can adjust the brightness. If you see patches >235 instead of 1 big white bar (e.g. on the belle nuite chart), then you've gone too far

[2Bdecided]

If you see patches >235 instead of 1 big white bar (e.g. on the belle nuite chart), then you've gone too farActually, on a real TV, the brightness of peak white is a personal preference (how bright do you want the TV to be?), and on conventional TVs it was almost impossible to make whiter-than-white merge into white - and by the time you did you were totally over-driving the tube.

I still don't have a clue what Mounir is trying to do. The simple and true answers have already been given near the top of the thread.

Cheers,
David.

[pandy]

I think that he (Mounir) is confused by concept 7.5IRE pedestal in NTSC - like many people Mounir think that pedestal is coded with compressed digital data but in real life pedestal is hardware generated by digital color encoder, also for this encoder 16 means black and 235 means white ie for 16 = 0 IRE and for 235 100 IRE, with presence of pedestal in signal (7.5 IRE) whole digital range is simply fitted as analog signal between 7.5 and 100 IRE without loosing levels.

[2Bdecided]

In an NTSC-M analog video encoder (i.e. the part that takes an ITU-R BT.656 SD digital video signal and generates composite, S-video, etc), Y=16 is mapped onto 7.5IRE (54mV above blanking). Y=235 is mapped onto 100 IRE (714mV above blanking).

For PAL-BDKIetc, Y=0 is mapped onto 0mV above blanking, and Y=235 is mapped onto 700mV above blanking. So much easier ;) The Japanese did a similar thing with NTSC.

Blacker than black is possible with analogue video, but too much of it and/or too low a level can confuse the sync-separator circuits and cause picture tearing or rolling on some displays. Whiter-than-white is trivial. With chroma on top, the composite video signal can go way outside these voltage "limits" (though arguably it shouldn't - or not by much - IIRC this caused problems on analogue satellite transmissions).

Cheers,
David.

[pandy]

So in hardware this look even more funny - most of digital color encoders use internally 9 - 12 bit DAC's - composite signal is created purely in digital domain and signal is converted to analog in DAC (output DAC is for example 0 - 2V) - 8 bit video is internally converted to coresponding DAC code, 7.5 IRE pedestal is added before DAC conversion.

AFAIR for PAL BGDK max level of composite video signal is around 133IRE (case for 100/0/100/0 color bars) with sync this should be around 1.25Vp-p for composite video - for RF broadcast this is saturated/limited to 100IRE anyway - RF broadcasts use AM modulation with negative (inverted levels) - sync tip is 100% (almost 100% - usually this is around 95% to prevent distortions) modulation (is transmitter use full power - highest range - thus for transmission quality sometimes we can say about SYNC conditions - ie picture is almost full of noise - barely visible however sync circuit in TV is able to extract sync pulses and works correctly) - i think that 7.5IRE improve range of transmission slightly biasing RF transmitter for higher output power (maybe in past this improve RF power amplifier linearity - not sure on this)
IMHO anything higher than 2/3 of sync tip (ie blacker than black less than 1/3 syn level) shouldn't destroy composite but can be issue for modern digital displays with ADC on input (similar for whiter than white).