I'm actually wondering if that's the correct way to go - knowing that the info isn't lost and an be easily recovered as needed when you grade (assuming you're using color), wouldn't it be best not to pre-adjust this in the picture style? It seems like it would be better to take advantage of the full 0-255 range of values in your source files.

tweak in camera or in post?
 

I've got the XHA1 and while it looks flatter right out of the camera, and not as colorful as the Pannys, people a lot more technical than I am say the XHA1 gives them more data to play with in post.

I wonder if that's true for the Canon 5D Mark III as well. If so I'd rather gather as much visual data as possible shooting on the street, then take my time tweaking in Final Cut/Color.

Anyone care to chime in?

If I understood correctly, H264 is technically a YUV codec. So levels should span from 16-235. However the camera records 0-255. Does this mean it's not properly mapping the values? or are we getting more information?

In either case, QuickTime decoder ignores anything below 16 or above 235.

Is this correct?

Any workarounds for the mac platform?

Unaware of this problem, my current workflow is to batch convert the original clips to Apple ProRes using compressor, then cut in FCP.

The potential trouble with leaving contrast high and colors saturated is clipping channels. That can't be recovered in post. But I'm not sure yet the way to go. I plan to "dial in",as much as possible, the color look I want in camera, and also set a custom white balance. The too warm, yellowish skin Canon's can produce can be difficult to correct later. The camera is capable of beautiful skin tones of all types. But it never does good white balance in artificial light.

Canon has choosing as the default a very filmic look - crushed blacks and saturated colors. It's interesting to me how some video people make 24p so important. I find most video from better 1/3 x 3 cameras sterile at any "p". Good EX1 footage is highly detail and very impressive, but its almost too technically perfect. This Canon I don't find sterile.

Salvador, unfortunately, exporting to Prorez does not recover loss in 16 235 readout.

there has to be Quicktime update developed addressing issue, or possibly another signal treatment by Canon yielding 16 235..

I think the solutions are these:

* Canon fixes their metadata, properly signaling the 0-255 range (if this is even possible.)

* Apple fixes Quicktime for 0-255 RGB - and possibly adds metadata for proper signaling. (See above.) We don't want the Quicktime fix to break existing 16-235 RGB video.

* We make custom profiles for the 5D MkII that compress the range to 16-235 using the supplied Picture Style Editor. Load the profile into the camera, and the video will be in-range. No need for a firmware update.

This applies to both the Windows and Mac situations. (See the related Vegas Workflow thread. The problem being discussed is identical. Good to know that Quicktime is consistent across platforms!)

This is what apple calls superwhite in FCP and there are rendering preferences that allow you to choose how to deal with it, but only for YUV codecs - and it doesn't recognize or treat h.264 as a YUV codec so these options are unavailable for h.264.

I actually am back to thinking this may be a good idea, but not just because of the range issue - I'm noticing that even when working with stuff in color there is a lot of crushing of values around black and white, as if the camera is applying a strong S gamma curve.

Shifting just the input/output in the luma curve brings back the detail lost due to the qt rgb clipping issue, but still leaves the blacks and whites crushed. Take a look at the example below - the first is the straight clip, the second is with Jon's luma adjustment, the third with an inverted S-curve. That may be too flat depending on your taste but to my eye that's what we need in a color profile in order to get away from baking in the high contrast look in camera.

Nice example, Evan,

I think the flatter result (3rd example) would lend itself to the most flexibility in post - especially when working in 32-bit mode. However, if you know you want crushed blacks, go with the second example.

According to wikipedia H.264/MPEG-4 AVC - Wikipedia, the free encyclopedia
H264 standard supports YUV structures. This means Quicktime is decoding the video properly mapping 16-235 (YUV) <-> 0-255 (RGB). The problem is the way the video is being encoded by the camera. Doesn't this qualify as a bug on behalf of Canon? They market the camera as being able to record video to H264. Enough evidence to prove that they're not complying with the H264 standard.

Again, by applying a custom profile, we can make it comply. It would be better if it complied out of the box, but at least there is a fairly simple workaround.

I prefer the second one. It handles white better without decreasing contrast too much. The third one does pull out some dark detail, but at the expense of contrast in the lower mid tones.
With Color it should be possible to bring out some shadow detail with affecting overall contrast. I'm curious how good shadow detail looks noise-wise.
What was the ISO on these clips?

Evan,

On your inverse S-curve, the end points are still in clipping territory (0 and 255). Ideally, they would end at 16 and 235, but you would still have some inverse S-curve applied. The curves could be more subtle in that case.

Not sure what you mean - that S curve brings all values in the original image into the 0-100% range on the scopes just like your example does - nothing is clipped. If you did want a more subtle curve you might need to pull the end points in, but my goal was to make use of the maximum available data.

Not sure on the ISO, that was just a random clip I grabbed. There's certainly a lot of room to adjust the overall image in Color but you do have to watch out for shadow noise, which seems to be compounded by macroblocking from the compression. With the curve I wasn't actually looking to produce the most pleasing final image as much as figure out how to maximize the image data before compression and hopefully minimize the shadow noise - better to crush it back down in post than have to stretch it too much.

As Jon mentioned the curve would be best when you know you're going to do extensive grading in post and for more casual stuff you'll probably something with a little more contrast. I'm going to try a few different curves in the picture style editor and see how they affect the shadow noise and clipping.

Edit: just spent a few minutes messing with the picture style editor... this is going to be more difficult than I thought. The gamma curve control is pretty bad, it doesn't lend itself to much more than fairly subtle adjustments because it has very strong fixed bias through the control points. It looks as if you actually can't really move the end points either - manually entering 16-235 for the endpoints results in a steep 90 degree bend in the curve.