Are Canon .mov Files in YUV or RGB Color Space?

R

rszebras

Well-known member
I've searched the internet for an answer to this question but I'm not 100% sure of the answer. I have this question about the color space of the h.264 files because of a situation I encountered using the zebras in Magic Lantern. The settings are 0 - 255 RGB, with presets at 5 and 250. At these settings the highlights are blown out and the blacks are crushed when I look at the waveform in PremPro CS3. So I changed the settings to 16 and 235 (the IRE equivalent), and now no more blown highlights or crushed blacks.

If the h.264 file is in YUV color space then I would assume it is 7.5 - 100 IRE. If the file is in RGB color space, there is extended range. I know Sony Vegas has a setting for super whites, that allow extended dynamic range with RGB color space, but I haven't found anything like that in PremPro CS3. I'm not sure how CS5 natively handles these Canon files in regard to color space. Is there wider dynamic range available (0 - 255 RGB) if you use CS5? Of course, this depends on the answer to my initial question.
 
the native footage is in Y'CbCr (or YUV is the analog equivalent)

Y' can contain data from 0-255 , but most RGB conversions convert Y' 16 => to RGB [0,0,0] and Y' 235 => RGB [255,255,255] . Thus Y' <15 and >235 are "clipped" . But many cameras can record usable data in the range >235 (i.e. superbrights) , for example the 7D does.

Vegas is different in 8-bit mode because it uses "studio RGB" . i.e. instead of doing the RGB conversion by "mapping" white and black to RGB 0,0,0 and RGB 255,255,255 , black is at RGB 16,16,16 and white is at RGB 235,235,235. Thus it leaves "head & tail" room once in RGB space. This is better for highlight & shadow preservation & recovery, but it "squashes" the middle range (there is less range between white & black) . So there are pros/cons to either method

CS5 is different in that some filters are applied before RGB conversion. They are labelled "YUV" effects. So you can access the YUV data before RGB conversion. So you can preserve highlights better. In CS3, it's too late because you have already incurred a Rec.601 conversion (i.e. the clipping has already occurred)
 
So everyone using the 5D, 7D, T2i, 60D is in the same boat. The camera is capable of recording a wider dynamic range but it's really not useable. I guess that's why when I started using Magic Lantern's zebras and had it set to 250, the exposure meter showed I was really overexposed. And I was, because all of those hightlights clipped. But when I set the zebra to 235, the exposure meter showed I was a little overexposed but the waveform in PremPro CS3 showed no clipping of the highlights. So I guess what I should do with my t2i is exactly what I've been doing: use the zebras just like broadcast zebras at 7.5 and 100 IRE (16 and 235 RGB), make sure there's no clipping or crushing (unless there's an aesthetic reason for it), and adjust exposure within those parameters.

Do you know how to convert RGB values to IRE? I'm curious what the RGB value is for 70 IRE and 60 IRE, which I've used on other cameras for exposing highlights on the face.
 
I sold my 7D a while back, and never used Magic Lantern, so I cannot comment on what's happening there exactly

You're doing what most people should be doing "by the book". ie.. attempting to use legal range by using zebras. But sometimes the conditions aren't perfect, or shoot doesn't go exactly as planned. Sometimes you need to recover some of the data. This is when avoiding a BT601 conversion maybe necessary


Do you know how to convert RGB values to IRE? I'm curious what the RGB value is for 70 IRE and 60 IRE, which I've used on other cameras for exposing highlights on the face.
Click to expand...
This actually varies a bit by software and how you have your scopes set up. You would usually take testcharts or RGB images with known values (eg.. make greyscale patches with known RGB values in photoshop), and import into your software for software scopes. If testing scopes on camera or other monitoring devices, you can use testcharts

That works out ok with RGB images. The problem is when you import video, it's in a different colorspace (the RGB interpretation of that video is different depending on how you do Y'CbCr <=> RGB conversion). In CS3, it undergoes a BT601 conversion for most import formats (except v210), even if you have HD material (it should be using BT709 for HD, but the canon DSLR's actually use BT601 for their matrix coefficients, so the "error" works out ok in this case)
 
I can actually import the Canon .mov files directly into PremPro CS3 without transcoding first, but the footage is slow (even with my quad core pc) and it seems buggy. So I've been using the free method of transcoding using MPEG Streamclip into the Avid DNxHD codec. But using either of these methods results in the same conversion process as far as I can tell, as I compared the footage in PremPro looking at the waveform and they both look the same.

I do realize sometimes the conditions aren't perfect so I try to use a reflector, diffuser, lights, etc. to narrow the dynamic range. After that I just have to choose if I want highlights blown or blacks crushed (or sometimes a little of both). But I think I'm on the right track by trying to use the cameras full range with the zebras. It's great that this inexpensive camera now has these features.
 
Yeah it's amazing what you can do with these. Just think a few years ago, something like this would cost many times more

It doesn't record much usable data on the low end (if it's crushed, there is no usable data in my tests) , but the high end Y'>235 there is a fair bit of usuable data there. Stuff like clouds - instead of looking like white blobs, you can often tease back some of the detail back.

The "damage" is done by CS3's RGB conversion when importing native footage . Actually MPEGStreamclip also clips it even when using the "Rec.709" setting. (it converts to RGB internally then converts to Y'CbCr 4:2:2 when using DNxHD)

If you had to save some "superbrights", you would either color correct in Y'CbCr space with other programs (you can't do this with PP CS3) , or convert to RGB using full range (instead of BT.601 or 709) and edit a full range RGB intermediate format. By using full range, Y'[0,255] gets "mapped" to RGB[0,255] , so the entire range is preserved. By the strictest definition, this is the highest "dynamic range" possible from the native recorded format
 
You must log in or register to reply here.
Back
Top