Youtube Mangles cRGB

john_dennis wrote on 7/5/2010, 11:23 PM

Since I just uploaded a perfectly beautiful video to youtube with lots of detail in the "shadows", all of which disappeared when they processed it, it looks as if I'm going to have to learn waaaaaaay more about their color space processing than I ever wanted to know.

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

It's the pits.

A. Grandt wrote on 7/6/2010, 2:14 AM

I wish their "Optimizing your video uploads" page would tell us these things.

PerroneFord wrote on 7/6/2010, 4:52 AM

YouTube, like other sites, expects you to upload video from your camera. And video cameras don't (as a rule) record cRGB. Vimeo does this conversion as well automatically. This is not new behavior.

Upload sRGB to these upload sites and all is well.

john_dennis wrote on 7/6/2010, 7:34 AM

See, I've already learned waaaaaaay more about this than I ever wanted.
Thanks Perrone.
I'll look at the sRGB color space settings.

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

"we all know what WMV does to colorspace" i don't.

tho i don't use it anymore as an upload format (switched to h264 & flv formats), WMV does nothing to colorspace i'm aware of.... it is RGB and that's what you get (actually, now i'm not sure WMV is RGB, it might be YUV... hmmm)

and what is cRGB? is this the same as YUV? i find no references to cRGB on google searches. please point me to reference.

TheHappyFriar wrote on 7/6/2010, 8:23 AM

I'm assuming cRGB = computer RGB, 0-255. Studio RGB does ~16-235 (or so).

Since m2t *IS* a camera format it could well be assuming it's in sRGB color space. What happens if you upload HD wmv or mov to the tube? Could be you. :D It would be like rendering to a DV file as a delivery format when they asked for the origional footage & not telling the person on the other end it's already been CC'ed.

I've never noticed my colors being off (at least not more then compression artifacts) when I upload WMV or MOV.

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

oh yeh. Sony's new terms for already existing standards... i forgot, thx.

musicvid10 wrote on 7/6/2010, 9:00 AM

Vimeo does this conversion as well automatically. This is not new behavior.

You read my mind again. That is the next thing I was going to test. Thanks for posting that.

"we all know what WMV does to colorspace" i don't.

Flat, washed out wmv is a fairly common complaint. I may actually like Perrone's theory more. Maybe they just expect most people will not edit their video.

"What happens if you upload HD wmv or mov to the tube? Could be you. :D"

I uploaded over thirty files yesterday in every format and container I could think of, including .m2t, .mpg, .mp4, .mov, .avi, .mxf, .m2ts. In every case that was "accepted" by Youtube, sRGB came back cRGB, and cRGB came back blown out. I made the post after I was sure of the behavior, but thanks for asking.

TheHappyFriar wrote on 7/6/2010, 9:12 AM

just checking. :)

I'll have to download some of my stuff & see what it's done. Is the mp4 that you're allowed to download also changed?

musicvid10 wrote on 7/6/2010, 9:22 AM

Dunno. I download the HD .mp4 (highest bitrate allowed) with DownloadHelper.
Comparing the download with the upload is just confirmation of what I'm already seeing at any playback resolution.

john_dennis wrote on 7/6/2010, 10:52 PM

"Since I just uploaded a perfectly beautiful video to youtube with lots of detail in the "shadows", all of which disappeared when they processed it, it looks as if I'm going to have to learn waaaaaaay more about their color space processing than I ever wanted to know."

I went back and looked at this video and learned little about color space (at least directly). I discovered that my stills had lots of detail in the shadows, but the video in the project preview started looking dingy from the time I dropped the still image sequence on the timeline.
I learned that I had selected: Pixel Format: 32 bit full range in Vegas Project Properties. Changing the Pixel Format setting to 8 bit improved the color balance to more closely match the original still images. I don't understand it, but I can't blame this one on youtube.

Improved video:

The two panels the electricians are installing are the reserve electrical busses for the next 2000 servers.

John Dennis
http://www.youtube.com/user/TheDennisChannel

farss wrote on 7/7/2010, 12:57 AM

32 bit floating point (full range) will indeed play havoc with your levels.

If you really absolutely believe you must use 32 bit float select the "(video range)" variant.

Bob.

john_dennis wrote on 7/7/2010, 6:57 AM

Thanks Bob,

I think for the output target, 32-bit color is not necessary. I'm not sure why either was checked except someone came into my office while I was trying to get the snippet of video rendered and posted so I could get the link into my weekly report.

PerroneFord wrote on 7/7/2010, 7:05 AM

Bob, I use 32bit full for every project that I do. I never have any levels issues. But like anything, it's a matter of learning your workflow and delivery. I prefer working in full range because it gives me a very consistent workflow regardless of whether my output is going to web (cRGB), DVD/BluRay (add cRGB > sRGB effect), or one of the video services(add cRGB > sRGB effect). It works for using still and video in the same timeline, it works for when I am working with cameras that adhere to REC 709, etc.

This may not be the best choice for everyone, but it's as valid a choice as anything else.

farss wrote on 7/7/2010, 8:02 AM

Well I just checked it again, just to make certain that it didn't get changed between V8 and V9. Still get the same problem.
Yes, you need to apply a cRGB > sRGB conversion on the output however adding a JPG still image to the T/L it also had it's levels shifted. There's no simple answers to these riddles, today by design cameras record images all over the place. The Cinegammas in the EX1 can go from 0 to 110, the 5D from -10 to 110 (roughly) so there's no magic way for anything to know what's coming into it.

For anything that matters I check everything with the scopes.

Bob.

PerroneFord wrote on 7/7/2010, 9:05 AM

I consider using the scopes akin to using a monitor. It's done of every piece of media in every project I do. That's why I guess this kind of thing doesn't bother me or trip me up. I always shoot in cinegamma on the EX1. But I have my highs roll off around 104 IRE. My new T2i is in Adobe RGB mode though the standard is sRGB. I prefer the extra color space since I'll be manipulating in post anyway.

musicvid10 wrote on 7/7/2010, 9:44 AM

As someone who receives work from videographers who have a variety of equipment and skills, I can tell you what a problem this is.

There are generally three approaches they take:
1) None
2) Stay just inside 0-255 and let some of the speculars go
3) Bring everything inside 16-235, an overly conservative approach IMO.

Obviously, those who employ method #1 never work for me again.
I prefer method #2 to #3, because I can easily make it sRGB if the need arises (broadcast or Youtube ;?)
I use one guy who employs method #3, and I have to remember to remind him to loosen his goose on my shoots, because having to expand his stuff back out impacts both actual bit depth and chroma levels, the latter sometimes visibly.

PerroneFord wrote on 7/7/2010, 10:33 AM

Exactly. If the sensor can grab it, I want to record it. We can sort out the clamps later. I want all the dynamic range my money paid for in that camera. You can't invent it later on in post.

farss wrote on 7/7/2010, 4:27 PM

Now I'm thoroughly confused as to what you mean. First you say:

" I prefer working in full range because it gives me a very consistent workflow ..."

Then you say:

"I consider using the scopes akin to using a monitor. It's done of every piece of media in every project I do. That's why I guess this kind of thing doesn't bother me or trip me up."

So what's the difference between working in Full compared to 32bit float (video mode)?

From my and others tests in Full your levels are messed with, what goes into the pipeline is not what comes out. You need to apply another transform.

In Video what goes in is what comes out. If you edit in 8 bit and switch to 32 bit float (video mode) you get the same outcome.
Discussions about preserving dynamic range are irrelevant as both modes are 32bit floating point.

The only time I see any significant advantage to using Vegas's 32bit modes would be with 10bit sources. My only issue then is Vegas seems clueless when it comes to correctly reading 10bit Log.

Bob.

Andy_L wrote on 7/7/2010, 5:17 PM

The way I understand it, in the video levels mode, when you import video into a project, Vegas maps black to black and white to white as the camera sees it.

In full range, Vegas maps super black to black and super white to white, such that both the camera's white and the camera's black become grayer.

In other words, Vegas clips super blacks and whites (as it should) in video levels mode; in full range, these values are mapped as if they are legitimate values within the 0-255 computer RBG space.

This behavior may not be the same for all codecs.

In any case, there is a certain logic to the way Vegas handles levels, but I find it deeply, deeply confusing.

musicvid10 wrote on 7/7/2010, 5:41 PM

I find your explanation deeply confusing.

PerroneFord wrote on 7/7/2010, 8:07 PM

"In full range, Vegas maps super black to black and super white to white, such that both the camera's white and the camera's black become grayer.

In other words, Vegas clips super blacks and whites (as it should) in video levels mode; in full range, these values are mapped as if they are legitimate values within the 0-255 computer RBG space."

And I WANT my super-blacks as 0, and I want my super whites inside that 255. I do NOT want them clipped. If they need to be moved into broadcast legal range then I will do it gracefully, rather than having them hard clipped.

When I work in 32bit full mode, I know that no matter if I am bringing in files from my EX1, from a RED, the 5D/7D, an ARRI, DPX files, whatever, they are NOT going to be hard clipped, and they are going to fall within 0-100 on my scopes. This is the behavior I prefer. Others, particularly those set up to go to broadcast, may not want this behavior and I completely understand that.

farss wrote on 7/7/2010, 10:10 PM

"When I work in 32bit full mode, I know that no matter if I am bringing in files from my EX1, from a RED, the 5D/7D, an ARRI, DPX files, whatever, they are NOT going to be hard clipped, and they are going to fall within 0-100 on my scopes. This is the behavior I prefer. Others, particularly those set up to go to broadcast, may not want this behavior and I completely understand that. "

With a mixture like that there's considerable scope (pun intended) for things to end up all over the place. I had a few goes at trying to figure out what the heck Vegas is doing with DPX and gave up. I downloaded a couple of the common test images and yikes. I've tried stuff I'd shot myself that decodes OK in AE and got black in Vegas regardless of project settings.

I'm confused by your "0-100 on my scopes" bit. Which scopes and what are they calibrated for. I would have thought most "broadcast" people would generally like to see things sitting between 0 and 100% IRE.

Bob.