Youtube Mangles cRGB

musicvid10 wrote on 7/5/2010, 11:01 PM

I set out this afternoon to find out why YouTube increases the contrast in all of my .m2t uploads. What I found out exceeded the scope of my original question.

-- YouTube apparently performs sRGB->cRGB conversion on every clip that is uploaded, regardless of colorspace or format. This is astonishing; it means if I want cRGB back, I have to upload sRGB. If I upload cRGB in any format, it comes back from YouTube crushed and clipped, badly so.

http://shell.dim.com/~musicvid/YTcRGB.swf
(I love DemoCreator!)

-- One can only speculate as to the reason for YouTube to expand the colorspace of every video that is uploaded -- however a reasonable guess is that there are probably more WMV uploads from people using WMM than just about any other format, and we all know what WMV does to colorspace. So rather than deal with a bunch of complaints about flat, washed-out video, they chose to goose everything that comes up the pipe. Heaven forbid that they should do a rapid analysis pass and waste their precious resources just to determine if a video actually needed it!

Back to post

Comments

PerroneFord wrote on 7/7/2010, 10:36 PM

Vegas does struggle a bit with some DPX files. I think they only implemented a subset of the full spec so not everything works. It creates basic DPX files fine though. I was able to deal with the DPX stuff I had ok, but EXR stuff is uhh... not so great!

Anyway on to the scopes.

Vegas comes default with the waveform set to display 16-235 mapped as 0-100. It stays this way regardless of project settings. So if you select either 8 bit or 32bit video levels and bring in footage that has super-black or super-white, that footage will display on the waveform monitor as exceeding 100 IRE and dippinng below 0 IRE. This is expected behavior.

However, if you set your project type to Full Range, you might reasonably expect the 0 to map to RGB zero, and the 100 to map to RGB 255. However this is not the case. They map just the same as 8bit and 32bit video. In order to set the scope correctly, you have to change the scopes setting manually from 16-235 ro 0-255. And then your superblack and superwhite will fit in the 0-100 IRE range. If you bring in footage that was shot in sRGB then the blacks will ride well above the RGB 0 line, and the whites will be well below the 100 line.

I prefer to have my scopes set such that ALL the material I plan to put on the timeline will be between the 0-100 and this is ONLY possible if I select full range, and I manually change the scope values.

Grazie wrote on 7/8/2010, 1:55 AM

PF! Spectacular explanation. Simple and with examples of your own usage. I wish everybody would follow your format. And yes, I learnt from your feedback too.

BR

Grazie

farss wrote on 7/8/2010, 4:18 AM

I just runs some more tests.
I created three grads, 0-255, 16-255 and 16-235. Rendered as AVI and also saved as png.
Put all back onto T/L, set scopes to 0-255.
Changing 32bit mode between Full and Video makes no difference to what the scopes read. In 8bit mode all is as expected.
In both 32 bit modes the png files are being seriously messed with, what should be a straight line on the scopes has now got a bend in it. The AVI file is as straight. Applying the cRGB>sRGB transform via the Color Corrector does not fix this alteration of levels. Correcting the PNG files with the same transform also doesn't fix the black gamma error.

In pictures, what should look like this:

[IMG=http://i192.photobucket.com/albums/z102/RobRoySyd/8bitmode.jpg]

ends up like this:

[IMG=http://i192.photobucket.com/albums/z102/RobRoySyd/32bitmode.jpg]

Bob.

robwood wrote on 7/8/2010, 6:18 AM

sigh. i really wish Sony had offered 16bit precision like AE... i just don't want banding or color combing.

Andy_L wrote on 7/8/2010, 7:34 AM

Bob, that's a bug. I reported it a long while back. It manifests as darker than expected shadows in all png jpeg and some other image formats.

Sony apparently doesn't think this is a big enough deal to fix. I believe, however, that it goes away if you select 8-bit in project properties.

PerroneFord wrote on 7/8/2010, 7:35 AM

What do you think 32bit mode is?

PerroneFord wrote on 7/8/2010, 7:36 AM

I was going to suggest something along those lines. I'd be curious to the difference with lossless video and not image files.

robwood wrote on 7/8/2010, 8:13 AM

"What do you think 32bit mode is?" i think it isn't 16bit.

when i use16bit in AE it doesn't matter what footage i hand it, i get back what i give it. that is not guaranteed to happen using 32bit in Vegas. working with TIF, TGA, PNG, AVI, QT, and a number of camera formats, then matching in 32bit is not a joy. in 8bit mode everything goes as i expect.

perhaps i'm wrong and 16bit would have the same problems as i've encountered matching footage in 32bit. but i don't think so. feel free to disagree, but 32bit is not 16bit and having both as choices isn't a bad idea.

PerroneFord wrote on 7/8/2010, 8:24 AM

I see what you're saying. My intent was to say that 32 bit doesn't give the banding issues. I don't think the issues with not getting back what you put in, has anything to do with bit depth. I think it has to do with implementation, if that makes sense.

robwood wrote on 7/8/2010, 8:49 AM

"I think it has to do with implementation, if that makes sense."

yeh i get what you're saying, and yeh you're likely right, given some formats work fine while others not-so-fine.

using AE has associated 32bit with linear for me (something i rarely work with as the comping is usually done before it gets to me). i default AE projects to 16bit due to the number of banding/color-loss issues i see (approx 1 in 20 projects) when the calculations are 8bit.

... then again, now that i'm having to think about it, i don't get as many banding issues in Vegas 8bit as AE 8bit... so maybe i should let this go.

sorry to divert this otherwise useful discussion... topics dealing with colorspace, codecs, and transfers between NLE's and/or platforms are a big part of my bread-and-butter so its been great reading whats been posted on this thread.

Yoyodyne wrote on 7/8/2010, 9:07 AM

Great discussion guys, this is very interesting.

Just to throw this out there. i uploaded some color bars to Vimeo as a little test for myself. Rendered out a wmv file, one section as sRGB and the other section as cRGB just to see what they do to the color space upon re-compression.

Here are the results:

http://www.vimeo.com/8211579

It seems to me that they are not adding a color space conversion upon re-compression because the pluge in sRGB looks "elevated" and the pluge in cRGB looks correct. Does this all sound right? The results of this test seem to match my experience with color space/gamma handling when uploading wmv files to Vimeo. This is from a "normal" sRGB project if that info helps.

PerroneFord wrote on 7/8/2010, 9:13 AM

Try this...

From an 8bit Vegas project, create 10 seconds of color bars on the timeline. Check to make sure it looks right on the scopes.

Render that to:

WMV
Sony AVC

Do the same in 32bit Video mode, and 32bit full. Name each of the renders something descriptive so you know whether it came from 8 or 32bit, and from video mode or full.

Upload them all to Vimeo or Youtube. Let us know your results.

Andy_L wrote on 7/8/2010, 12:41 PM

if you are not applying a computer-to-studio levels correction to generated media in video levels vegas projects, they will look incorrect when rendered--blacks and whites will be clipped. This has nothing to do with Vimeo or YouTube processing.

musicvid10 wrote on 7/8/2010, 12:50 PM

The color and test bars in Vegas are already 16-235.

It's the other media generators you have to be careful with.

Andy_L wrote on 7/8/2010, 1:20 PM

That...is remarkable.

farss wrote on 7/8/2010, 2:51 PM

" I'd be curious to the difference with lossless video and not image files."

I thought I covered that in my post before the screenshots but anyway.
With DV, the curve is linear so easy enough to correct.

Regarding a 16bit integer mode. Absolutely needed and it should involve way less overhead that using 32bit float. You don't need AE to get it either, PPro has it for editing 10bit sources such as digibetacam. From my experience a significant number of users who have problems with Vegas crashing have been using 32bit float. Many of them when asked why they're using that mode say because their video looks better. What they've not understood is their video looks "better" because of the level shift which could have been achieved much easier.

Bob.