It's not so simple:

http://www.audioholics.com/tweaks/calibrate-your-system/hdmi-black-levels-xvycc-rgb

These days, most LCD TVs support 0-255 over HDMI and DVI (since they are often used also as computer monitors), but you never know, unless you check the LCD with testing software.

farss>>

Full RGB (RGB Full Range) is the term that the PS3 uses when talking about RBG levels that are 0-255. Limited RGB is the term by the PS3 for RGB levels that are 16-235.

http://manuals.playstation.net/document/en/ps3/current/settings/rgbfullrange.html

Video is not RGB yes, but really that means not encoded as RGB... however some players (such as the PS3) can output the video via HDMI in RGB or Y,CbCr (it is a user setting for Blu Ray & DVD playback on the PS3). XrossMediaBar (PS3 OS) outputs RGB by default... when a DVD or Blu Ray is played it will switch to whatever colorspace is selected in the preferences via HDMI (RGB or Y,Cb,Cr - I should also point out though that this option can only be set when using HDMI).

When playing video files from XrossMediaBar, either locally stored or via a UPnP network - the videos will be sent in RGB to the TV (as the OS, XrossMediaBar is outputting RGB).

So what I am trying to learn is if LCD TVs should be able to support RGB levels, or Y values that are 0-255. This would help in setting black levels if I knew for the correct levels that the TV is capable of displaying. I.E use a Windows Media file with the Plunge bars (or a PNG with the same image).

EDIT: I should add that obviously RGB can only be set as an output colorspace when using HDMI.

Cheers,
Chris

chris...

stumbled across your post. I display HD content on my samsung 46"LCD via a Western Digital WDTV. I've done the precise test you mentioned, only I used a pluge pattern for REC709. In the native mode, without any adjustment, the display showed the full RGB 0-255 in the most beautiful way.

Thanks Bill!!

I am assuming the LCDs (specifically ones made in the last 2-3 years) 'should' be able to display 0-255 (why else would the PS3 have the setting?) - What I find funny is that there is no mention of it in the specs or manuals. They should add some blurb there as the PS3 manual states 'For RGB video signals, the range of color scale that is input varies depending on the TV in use.' But if they are not telling us then how do we know.

Which format did you use for the Plunge test? I am using Windows Media as the encoder does not clip the below black levels like MPEG2 or AVC does. I think I will just create a PNG and load that on the PS3.

Cheers,
Chris

Chris, I think you might be confused because you are conflating the contexts of "0-255" and "16-235". It's like throwing out the numbers about temperature but not being clear about whether you're talking about Celsius, Fahrenheit, or Kelvins.

2- The easy answer is this... there's only one way to make a proper digital master. Black and white level have to be a particular way on your master. See the example workflows here:
http://www.glennchan.info/articles/vegas/v8color/v8color.htm

3- There is a way to encode your footage in such a way that you preserve values that are blacker than black and whiter than white. But usually there is no point in doing so... the viewer is not supposed to see that stuff. As for broadcasters, they don't care if your color bars get clipped at black. For the program, any material below black level and above white level should be clipped.

4- To hopefully clarify confusion:

As far as the HDMI interface signal goes, there are different "encodings" that the signal can use:

a- RGB with the legal values from 0-255
b- RGB with the legal values from 16-235, i.e. 0-15 can hold values blacker than black and 236-255 can hold values whiter than white. (*I don't know much about this format over HDMI.)
c- Y'CbCr, where the legal values for Y' is from 16-235

b and c can both hold values blacker than black and whiter than white.

DVDs and Blu-rays only hold the material as c. A computer video card's output buffer will hold its picture as a. Converting between the various formats (a/b/c) technically causes some information to be lost (though rarely is that an issue), so it does make sense for HDMI to support various formats so data isn't thrown away unnecessarily.

---
In most situations, you don't care about values blacker than black and whiter than white... you're not supposed to see those colors. In rare cases (e.g. calibrating a CRT), you might care. So suppose you are in one of those rare situations.

If the video is being sent over the interface as a, then you'll never see those colors.

If the video is being sent over the interface as c, then you might see those colors. First off, the media player (e.g. a DVD player) might decide to throw away illegal values... some do this and others don't. The display might also do this. But let's say these illegal values get through. For blacker than black, it's physically impossible to display that because negative light does not exist. You'd have to mis-calibrate your display to see those values, such that black produces more light than the blacker than black values. (This can be a case where the blacker than black values can be useful, because it can indicate if the display is mis-calibrated.) For whiter than white values, some displays will show them (poorly) and others won't. LCDs shouldn't display them.

5- The audioholics article ( http://www.audioholics.com/tweaks/calibrate-your-system/hdmi-black-levels-xvycc-rgb ) is confusing and possibly incorrect. I would ignore it.

Hi Glenn,

Yes I understand that - in the end I am trying to make a test image that will show blacker than black so I can collaborate my LCD TV.

I don't plan on encoding any videos with below black levels. The PS3 can display RGB 0-255. So what I think make sense is to play back an image or video with below black levels and black levels (when I say black levels I mean a value of 16) - and with that image on the screen adjust brightness till I cannot see a diff. between the below black and black levels. As well as doing the same with the white levels. I think doing this with a image as opposed to a video might make more sense to insure that the encoders are not clipping the below black levels (if it did that I would not be able to adjust as I wouldn't be able to see the below black bars).

However on a side note... I found that the Sony LCD TVs have a auto dimmer that just kicks in far too often when the output of the PS3 is set to FULL. From what I can tell - if there are any signals below a certain level (I am guessing around 16) for too long (i.e 3 seconds) the auto dimmer kicks in and the picture becomes darker. This does not have (as often) if the PS3's output is set to Limited. I downloaded a software up for the TV that is supposed to help some what - how much I don't know... will test it later tonight.

Chris

Well you can do that by:

a- Throwing the colors bars on the Vegas timeline.
b- Encode that using Vegas' default Main Concept MPEG-2 encoder.
c- Don't do it in a 32-bit project... use the 8-bit mode. (Because Vegas changes codec behaviour in 32-bit.)


I'm not sure if there is any benefit to doing this for a LCD hooked up via a digital connection. The digital connection won't drift, so that won't need calibration. A LCD display itself won't drift in its black level like a CRT might. The only thing to check is whether something in your signal path is screwed up that is causing the video to be decoded incorrectly (which may be worth doing).

Since you incorrectly used the term twice, I have to assume that you don't know that the correct term is "pluge" and not "plunge"

"Pluge" is an acronym that stands for "picture line-up generation equipment" and a "pluge pattern" is a test pattern used to calibrate black levels on a monitor.

Thank Glen,

That is what I am doing in fact... however I found the Main Concept encoders (both AVC and MPEG2) were clipping the blacks, and I did use an 8bit project. Same with Sony's AVC encoder. Windows Media was the only one that wasn't I guess that it does not clip as Windows Media is mainly for computer playback (did not try Advance Profile however). What I am going to do is use Vegas to create the color bars and save the preview window as a PNG.

I am not sure of the benefit either... I just want to adjust my brightness and such so that my blacks are too black (as in cannot see them) or that they are not dark grey either LOL.

John, thanks for the correction... any other useful tips? ;-)

It's a Vegas thing that it's possible to throw color bars on your timeline and get screwed up levels.

That's why you're confused and think that Windows Media does not clip blacks. It does. It cannot describe values that are blacker than black.

The Main Concept encoders do not.

Read the Vegas 9 levels article carefully!!!
http://www.glennchan.info/articles/vegas/v8color/vegas-9-levels.htm

2- Remember that some equipment will clip away illegal values.

Also remember that you cannot see blacker than black colors unless you miscalibrate your monitor.

3- The calibration on your LCD TV (as far as black and white levels go) may be as good as it gets... you might be trying to fix something that is not broken.

Many LCD displays have menu settings allowing them to be used either as computer monitors or as "TVs."

When shooting video (in a controlled environment) that is heading for post work to squeeze out maximum quality, just forget about 16-235 and set up your camera for 0-255 (or better 0-1023 :O), using a wave form monitor.

Adapting this to 16-235 can be done as a last step for delivery to those who need it.

In the meantime you have more to work with, to craft the best look for each clip.

This of course doesn't apply to ENG (news) shooting where the camera media have to be handed over to a standardized broadcast work flow within minutes.

The 16 digital normal black (not superblack) is often confused with the old 7.5 IRE analog setup (pedestal), which was originally created to prevent early vacuum tube TVs from showing an ugly retrace when there was no picture visible in the signal. At that time, the problem was cheap DC power supplies.

I can't wait for the last TV engineer to be laid to rest (hopefully voluntarily :O), so that we can get rid of all this olde stuff that's just getting in the way when everything is done with computers, like interlacing, setups, 16-235, etc.

Blech!

You were right Glenn,

The encoder does not clip the blacks... however it was the decoder (ffdshow AVC) that is decoding to different levels which are 0-255 - so I am guessing the decoder was clipping it. I did another test video and encoded it to AVCHD and then opened that m2ts in Vegas and the colors were all there - nothing clipped. I then open the m2ts file with Virtual Dub via Avisynth and rendered to RGB 24bit AVI Uncompressed - opened that in Vegas... and all the colors were clipped.... so in short my decoder decodes to 0-255 even if the source is 16-235. FFDshow does have a level adjustment with it so I am able to bring the levels back up for anything I encode to watch on the TV.

Chris

the problem with all this is that mpeg, some encoders and some decoders(mostly the playback devices), will clip 16-235. if you're gonna go thru the trouble of making a true 0-255 colorbar and pluge, you have to avoid mpeg encoding. As i said, I encode to wmv or h.264 with MPEG_streamclip, then playback the footage thru a production monitor with an onboard waveform monitor to verify that I have true 0-255, then use the encoded playback, playing thru the same WDTV(with HDMI feed) to cal my samsung to the proper 16-235 pluges. The difference between 0-16 and 16-> is so small that it is quite subtle, at least on my samsung LCD. And a sidenote, as you've discovered, some displays play funky with the signal. Use a production monitor or a display that allows you to turn off all "auto" anything. My production monitor definitely shows 0-16 and 235-255 when fed by an HD-SDI or HDMI signal..

In the words of the inimitable bard..."...it's a long and winding road"

1- Daagh! Why do people insist on talking about "0-255" and "16-235" while omitting the units? Context is everything.

Otherwise, you will have confused people arguing over whether water freezes at 0 or 32 or 273.15. And they'd all be right (Celsius, Fahrenheit, Kelvins).

so in short my decoder decodes to 0-255 even if the source is 16-235
A decoder should take 16-235Y' values and convert 16Y' to 0RGB (computer RGB) and 235Y' to 255RGB (computer RGB). That is the right behaviour... it's supposed to do that. Vegas doesn't always do that and that is the wrong/bad/confusing.

Remember, in normal conditions, you're not supposed to see the below black values. So you can't tell the difference between 15 Y' and 16 Y' unless your monitor is mis-calibrated. You probably need a CRT to see it, and that CRT has to be fed by a signal chain that supports below black values (e.g. Vegas --> DV/firewire via a camcorder --> CRT).

2- What do I mean by the decoder clipping the values?

Suppose you encode a DVD with proper color bars on it. Take different DVD players and feed the output into a CRT TV. Mis-calibrate the CRT so that the brightness control (actually the black level control) is turned all the way up.
*Depending on what DVD player you use*, you'll be able to see the below black/blacker than black values on some DVD players and not others. Some DVD players decide to get rid of illegal values, and others leave them alone.

Anyways, that is likely not the issue here.

3- The problem is not MPEG. The various MPEG formats (the ones in common use anyways, e.g. MPEG-2 / DVD) support below black values.

Relax Glenn, we are all here to learn and enjoy these kind of discussions ;-) It's all good.

OK OK so to be more precise... yes my decoder (FFDshow) does take 16Y and convert it to 0 RGB as well as taking 235Y and convert it to RGB 255. The thing I am seeing is if I take a Pluge test (media generated) and plop it on the time line (project 1080i 60 - not that that matters) and render it out to AVCHD (Sony's AVC encoder)... play that render (m2ts file opened via Directshow with the Haali Splitter and FFdshow decoder) in Windows Media Player - the below black levels are gone... where 16Y was is now 0RGB - there for it makes sense that I cannot see any of the 'Below Black' bar.

Now if I take that very same file - plop it into the timeline in Vegas (again 1080i project) the decoder in Vegas does NOT have the same behaviour, which is to decode 16Y to 0RGB and 235Y to 255RGB - instead its 16Y = 16RGB and 235Y = 255RGB. So the confusion is which is correct? Is there a difference in a computer decoder versus say a DVD player or Blu Ray player? What levels are the DVD/Blu Ray players decoding to?

If I am to play an m2ts file with 16Y-235Y on my PS3 - what will it decode to? 0RGB-255RGB? I think that is a setting in the PS3 itself (there is the option I mentioned above of setting the RGB output via HDMI to 'Full' or 'Limited').

If so, then to set the Black Level (brightness) on my TV... I am thinking that I should set the PS3 RGB output to Limited (16RGB-235RGB - at least i presume thats what the 'Limited' setting does) so that the decoder will not change the levels from the source (Blu Ray, AVCHD files etc... as those AFAIK should be mastered to 16Y-235Y)... then take my Pluge test and while playing adjust my brightness so that the 16Y level bar disappears or blends with the Below Black bar.

Or I could just set the PS3 to 'RGB Full' and let it decode 16Y-235Y to 0RGB-255RGB. and leave the TV at it's default brightness - which I assume is already calibrated, but may need some tweaks for the room.

On a side note... I also found last night that Vegas does take MJPEG and convert 16Y-235Y to 0RGB-255RGB. Vegas does that for MJPEG but not AVC - perhaps its to do with the project's bit depth as you articles suggest.

Chris

If I am to play an m2ts file with 16Y-235Y on my PS3 - what will it decode to? 0RGB-255RGB?
Yes.

I think that is a setting in the PS3 itself (there is the option I mentioned above of setting the RGB output via HDMI to 'Full' or 'Limited').
I'm not 100% sure on what it does. It might be the clipping of the sort as in the DVD player example. But then again, maybe not.



Depends on the codec. (And the codec used can depend on the container, e.g. AVI or Quicktime.)

May by useless info but if anybody cares.... the Full and Limited RGB settings for the PS3 make no difference to the how it decodes AVC video (and I doubt that it affects any other decoders). The PS3 decodes AVC 16Y-235Y to 0RGB-255RGB.... something to remember when mastering then ;-) If the levels are 0Y-255Y then it will lose info on the decode.

Chris

Another remark on this subject:

It's also important to know how your camera treats luma levels. I have a Canon HV20 HDV camera that records some superblacks but superwhites all the way up to 255 YCbCr. These values outside of the 16-235 range are transferred as-is when input into Vegas, as confirmed by SCS:

QUOTE
Q. When I display the histogram of captured HDV footage it shows video data over the whole 0-255 RGB range. Does Vegas on input remap 16-235 YCbCr to 0-255 RGB?
A. We do not map YUV 16-235 to RGB 0-255, in fact we keep YUV 16-235 as RGB 16-235, so if you are seeing histogram values below 16 or above 235, it’s because your camera recorded them, and it’s one of the reasons we retain the full YUV range into RGB so we don’t lose this data. You can use the Levels plug-ins to legalize these values for proper display on properly calibrated video equipment.
UNQUOTE

When doing MPEG2 or AVC output the following should be considered:

QUOTE
Q. On (MPEG2 and AVC) output, RGB values under 16 and over 235 are lost. I therefore need to put the "Computer RGB to Studio RGB" FX on the output. Is this by design?
A. In the same manner, when RGB is converted to YUV for MPEG-2 and AVC output, the RGB 16-235 maps to YUV 16-235. Full-range RGB content should be brought into video range using the Levels plug-in with the “Computer RGB to Studio RGB” preset.
UNQUOTE

So I always apply the "Computer RGB to Studio RGB" FX on the final output to get the correct image quality. Of course, this is for this specific camera, others may differ.

Finally, the Vegas "Computer RGB to Studio RGB" FX doesn't clip superblacks and superwhites, it remaps 0-255 into 16-235.

Lou

"So I always apply the "Computer RGB to Studio RGB" FX on the final output to get the correct image quality. Of course, this is for this specific camera, others may differ"

No. If your camera is recording black to superwhite then applying that will shift you black above black. I use a custom Color Curve with an eye on the scopes. Very similar to the one in Glenn's article. I'd post a link to Glenn's curve but I can't find it anywhere. all of this is assuming you wish to map the highlights above legal into legal, you may wish to simply clip them in which case the Broadcast Colors FX is the go.
Bob.

Coming in late to the thread. Small tidbit I learned a couple weeks ago:

If you use the ffdshow decoder-filter to view your output footage, there is a "Levels" control on the Decoder Properties, in which you can show a realtime histogram of the input "levels". I have found this to be valuable for tracing down mistakes in my colorspace translation, especially when creating output using the frameserver & megui/avisynth (which will raise black level to ~32 if the magic incantation of convertToYV12("matrix=pc.709") is not invoked). Check "Full Range" and "Show Histogram".

My curves are here:
http://www.glennchan.info/articles/vegas/color-correction/curves-and-secondary-presets2.veg

Tutorial explaining how I use them:
http://www.glennchan.info/articles/vegas/color-correction/tutorial.htm

Bob,

In this specific case I get the best results by following SCS's advise to use the "Computer RGB to Studio RGB" FX. After all, I don't want to clip these illegal values like in Glenn's tutorial, I indeed want to map them into the legal range as they do contain image data.

I don't understand your remark about "shifting black above black". Could you clarify this?

Lou