Laurence,

I've ran some tests on Youtube regarding this issue. It appears that provided you send an mp4 with good levels, it doesn't matter which space video/computer you use. YouTube seems to be able to figure out where the blacks and whites are supposed to be either way. Note that using different formats (ie Windows Media or Quicktime) can have very different results.

I also believe it is misleading to think of these as two separate and distinct color spaces, and calling one sRGB is inevitably going to cause confusion with this.

I may be wrong about this, but I think with mp4 there is really only one format that you are outputting to, YUV, or YCbCr, and the only difference is whether you encode with illegal (ie, superblack and superwhite) levels or not.

Vegas's documentation leads to a lot of confusion in this regard. You might think, for example, that the full-range pixel format outputs computer levels, but if you encode your mp4s in the full-range 32-bit mode, no matter where you set your levels, your output will be broadcast-legal! Clear as mud, as they say.

I've ran some tests on Youtube regarding this issue. It appears that provided you send an mp4 with good levels, it doesn't matter which space video/computer you use. YouTube seems to be able to figure out where the blacks and whites are supposed to be either way.

If that is true, would you agree with the following scenerios:

1/ You upload an mp4 that is sRGB legal (colors between 16,16,16 black and 235,235,235 white). Youtube should set the range from 16 to 235 as it converts to flash video format and everything should look as good. Pass

2/ You adjust the video so that the preview looks good in the Vegas preview window. This means your color will end up being pretty much cRGB and fall between a 0,0,0 black and a 255,255,255 white. You render this out to Youtube and it analyzes it and sets the range between 0 and 255 as it converts the video and everything looks good. Pass

3/ You leave the video in sRGB space but add titles without scaling the color. You do not put a media generator black underneath the bottom track or apply any sort of broadcast filter to the output. Your mp4 render has whites of only 235,235,235 and blacks of only 16,16,16 but within the render are whites of 255,255,255 in the titles and blacks of 0,0,0 in the black background behind the titles and in fades between scenes so as the Youtube analyzer looks at the video, it decides to encode your video into flash at values between 0 and 255. Your video looks washed out on Youtube. Fail

4/ Same scenario as 3, but you have a really nice setup with a calibrated broadcast monitor and high quality preview card like a 1394 setup for SD or an AJA or secondary monitor. If you are using a Windows secondary display, you check the "use color management" box, the "use studio RGB (16 to 235) box" and choose a "monitor color profile" that gives you very accurate color on your broadcast quality monitor. Everything looks good, but you still use the default settings for text color (255,255,255 white) and your blacks still go down to 0,0,0 whenever something else isn't on the screen. The white text looks fine and you can't even see a difference with the blacks. You render out a project with nice looking color and upload it to Youtube. Youtube analyzes it and because of the 255 white text and 0 black, sets the range from 0 to 255 as it converts to flash. Your video that looked so great on the monitor looks washed out on Youtube. Fail

I think you've perfectly described the problem -- Vegas' handling of generated media like titles means your video can look great in preview, but YouTube sees the wrong black/white levels on upload.

My tests didn't include titles, so I nver noticed it. Thanks for pointing this out!

How on earth is the average Vegas user to supposed to know about this stuff???

How on earth is the average Vegas user to supposed to know about this stuff???

No kidding!

I received notification that Vimeo will be offering an "Uploader" program to run on the user's PC. It will be interesting to see if there are any tools to insure image accuracy built in.

I'm doing my own tests (with Vimeo Plus rather than Youtube for now) and I'm finding that sRGB looks a little too washed out even with careful attention to not going over 235 white or under 16 black.

cRGB looks good for the most part, but on my computer at least, the highlights look blown out.

The best results I'm getting so far are with a custom AAV preset which looks exactly like cRGB except with the peaks pulled back a bit so they don't blow out. I'll post examples later.

I just noticed my laptop tends to look like the highlights are blown out if you look at it from certain angles, but fine if you look at it from others. Thus I am back to sRGB to cRGB for preview and video hosting service upload.

Here are screen captures of the difference between an sRGB and cRGB upload to Vimeo:



Here is the actual video with http://vimeo.com/6986140studio RGB[/link] levels.

Here is the same video with http://vimeo.com/6987927computer RGB levels[/link]

To me the Vimeo video from the sRGB mp4 upload looks washed out whereas the one from the cRGB mp4 upload looks more vivid. This is from an older video shot with my single CMOS Sony HVR-A1 which has much less vivid color than my 3 CMOS HVR-Z7, but you still get the idea.

Laurence, good information as usual but I think it is going to be very confusing to continue referring to studio RGB as sRGB which has a completely different meaning.

Jerry

You're uploading an encoded file to Youtube. You just need to make sure you encode *that format* correctly.

So if you are outputting a MPEG-2 or MPEG-4 with Vegas' default codecs, those codes expect studio RGB levels.

2- Looking at your Vimeo videos, the studio RGB version seems correct. Your title shows a white with 254 254 254 RGB... that's close enough to 255 255 255 (which is where white should be). The sky is less blown out in the studio RGB version than the computer RGB version.

3- Also see this article if you want to rescue highlight detail from the superwhites that your camera will record:
http://www.glennchan.info/articles/vegas/color-correction/tutorial.htm

You can use the curves in there to make your image "pop" more like in the computer RGB vimeo video.

Laurence, good information as usual but I think it is going to be very confusing to continue referring to studio RGB as sRGB which has a completely different meaning.

I thought "studio RGB" and "sRGB" was the same thing. What's the difference?

sRGB is a standard intended to primarily represent the color space of the lowest common denominator of personal computer screens as they existed in 1996 (i.e. the CRTs of the day) and basic printers of the era. It was meant to be the "internet" consumer standard.

Adobe RGB is one of many other standards that provide a wider color gamut (i.e. more colors can be seen).

Studio RGB is SCS/Sony's name for 16-235 RGB (as opposed to the 0-255 Computer RGB). I think the intention was to better interoperate with 16-235 YUV and its potential superblacks and superwhites.

Other NLEs work in YUV, but Vegas works in RGB, hence the need.

I'll stop using "sRGB" interchangeably with "studio RGB".

You know what look I like? I like the way a studio RGB levels .mxf render looks when you play it back with the PDV-X10 player. Whatever that does on playback to the studio RGB levels is exactly what i want to do to my Youtube HD and Vimeo HD uploads.

I like the way a studio RGB levels .mxf render looks when you play it back with the PDV-X10 player.

Connected to what?

How is that "what" calibrated?

You have to look at the whole chain.

Showing studio RGB footage on a Computer RGB monitor can look very dramatic thanks to the crushed blacks, etc. This works great until you show footage that was shot "dark" with dependence on the viewer being able to see the action in the shadows.

Laurence:
Some media players will apply image "enhancements" to the image- that might be what you're seeing???
One enhancement would be to make the lowest blacks in the image at 0... and there are other things out there.

Try apply s-shaped curves to your footage if you like high contrast looks.

2- In my opinion, it doesn't make much sense to say that something is a studio RGB render. There is only one way to handle the levels correctly. For some codecs you need to feed them studio RGB levels and for others it is computer RGB. Either the encoded levels are correct (from a technical, not aesthetic perspective) or they are wrong.

2- In my opinion, it doesn't make much sense to say that something is a studio RGB render. There is only one way to handle the levels correctly. For some codecs you need to feed them studio RGB levels and for others it is computer RGB. Either the encoded levels are correct (from a technical, not aesthetic perspective) or they are wrong.

Glenn, your "Color spaces and levels..." paper lists a number of codecs and whether they expect studio RGB or computer RGB. Under quicktime you say most but not all wants to see and decodes to computer RGB. My question is, how do we determine which a codec wants to see and decodes to, if it isn't in your chart? Would it be correct to render a test chart with 0, 16, 235 and 255 and test the rendered output. If we can distinguish between 0 and 16; and 235 and 255, the codec is looking for and decoding to computer RGB? If we can't, then it is studio RGB?

Jerry

Jerry

Yep, I would do that.