My FCP Workflow
 

1/ Copy contents from CF card.
2/ Import contents in FCP.
3/ Edit using native H.264
4/ Colour grade within FCP.
5/ Duplicate Sequence. (*backup)
6/ Change FCP Sequence to ProRes codec.
7/ Render out

*Good to keep native timeline backup.

Via Compressor:
8/ Encode to media destinations.


This works if your system can play back H.264 alternatively you can lower the playback quality to avoid dropped frames within FCP.

If you leave the sequence in H.264, colour grade then render out the quality is degraded quite considerly.

Try two sequences one with native H.264 and one with ProRes then look at 100% crops.

Re-encoding H.264 from H.264 due to colour grading reduces detail. Re-encoding to ProRes from H.264 keeps more detail even then going back to H.264 for online services like Vimeo.

You can encode all footage before hand to ProRes but if you cut first in Native H.264 you avoid encoding unused content.

Back up your smaller H.264 masters and FCP project and then delete your final Prores files and scratch files after final print encoding to media destinations.

Pro's: Quicker to render, holds more detail.
Con's: Takes a lot more room.

James

Thank you for sharing this workflow,

It sounds great, however does not read/produce full 0-255 RGB colorspace, that 5mk2 provides.

Through initial research my colleagues find, that QT from the get go, does not transpire the color space cutting it to 16-235.

Reading RGB as 0-255 will only give full color information that the camera provides.
Otherwise we will see lots of crushed blacks and clipped whites. For certain tastes it's OK,
Yet it\s limitation.


On a Windows platform so far apparently only Carbon interpret .mov files from the camera correctly.

(possibly the new Mac/FCP firmware has a new video option, colorspace adjustment) I guess this is related to RGB vs. enhanced RGB?

True but outside of 16-235 the levels are also outside of the legal broadcast range.

I don't have a problem with clipped whites or crushed blacks as I have used the custom profile 'Flat2' found here.

Index of /canon5dmk2/Presets

http://www.millermiller.co.uk/canon5...sets/Flat2.pf2

James

Thanks James,
What hardware are you using to edit?

Hi Don,

Some old G5 duel's 2.0 (7 years old!) networked for compressor and a Intel Macbook that plays the H.264's faster.

Hi Oleg, I understand the issue and it would be great if the full range was native in FCP or as an option but using a modded preset you can avoid most of the clipping problems.

James Hi, thank you, I
think there is a solution found, Mpeg Streamclip, it repackages files, interpreting codec for a full range, 0-255, more about it in Vegas thread.

It really works, confirming!

Evan Donn, appreciate your help!

Hi Oleg, I use MPEG streamclip alot, I downloaded the current version and opened up the link from the other thread. It does not work on mine with that file.
Still has clipped wings.
James

Hi, James!

I was too quick to say that Mpeg Streamclip produces full 0-255.
Further analysis shows that is not a fact, you are right,

a better conversion/codec, plugin has to be discovered/developed for getting full gamma from the camera.

One good thing I was told today, Apple Color can interpret original footage correctly..

Hi, Oleg and fellow Dvings

Attachments from Apple Color - Showing primary luma curve adjustment.

Images:
• Original with scopes
• After Luma adjustment with scopes
• Luma curve

The information is there you just have to get it back.

This is also what can be done within 'Picture Styles' in the Canon software, addressing the issue at source.

Just a quick one and not meant to offend, but do scopes remind anyone else of the 'Turin Shroud'.

Wow.
That's freaky.

-Bill

James, thank you, so Color works, thats great!
I have to thank my colleague Alexandr Oleynik for letting me us know that!

Yes, please thank Alexandr.

I had forgotten how quick and powerful Color is, once you get round the interface.

James

Yep, sorry about that, I spoke too soon as well - it looks like the streamclip conversion recovers some black detail (not highlights though) but nothing compared to what you can pull back in in Color.

I've been meaning to spend more time in Color anyway, so I guess this camera is a good excuse!

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.

Evan,

We found the same thing the Picture Style Editor user interface is worthless. I'm going to make another thread for the PSE.

Evan,

What software/process did you use to create your curves in the pictures above? I thought I'd be able to do that in the PSE, but we're finding it to be less than user friendly.

The example is from Color, unfortunately I've had no luck getting similar results in the picture style editor.

My math whiz son and I got something working in PSE. We're dealing with software installs and such right now, but once we get our tools set, we'll choose the best profiles and post the results in the PSE thread.

I found a workaround, but I have to admit its pretty hardware intensive.

I take the hdmi out signal from the 5d, go thru a convergent design konvertor which transfers the hdmi signal to Hd-SDI, and take that signal into the Backmagic HD capturing card.

Then I capture the signal to apple prores.

I admit its bizarre, and you could do it cheaper with a hdmi capture card from blackmagic, not to mention that you are losing all the nonlinear advantages of tapless recording.....

But in the end thats a way to get the signal into finalcut without the 16-235 problem.
Looks exactly like the hdmi output of the 5d