I have thoughts I wish I could directly explore regarding the comments here on crushed blacks and such.

I have experienced problems with video where the software being used to edit the video doesn't properly handle the incoming dynamic range of the source correctly.

As an example I use Avid Liquid to edit video from my V1U. Liquid will not accept video above the equivalent of 100IRE (anything above about 235 on 8 bit luminance). What happens is Liquid till truncate any data over 235 and make your highlights look blown out. This is a real problem with my V1 since it easily handles "super white" up to about an IRE of 110-112.

I wonder if the same thing is happening on the bottom end with editing software expecting the video from the 5d to have a 7.5% equivalent pedestal and since it may not have that pedestal the software is truncating anything below about 016, crushing the blacks.

I hope to have a 5D in hand early next year (as I see them in stock again). I am curious to the nature of the problem and suspect the custom gama curves people are putting in the cameras are bringing the video in line with what you would expect to see in the normal analog video world (7.5-100% IRE).

These are just thoughts. I have no data to go on yet. I do think its worth looking into more.

Yes, this is exactly what is happening, although the issue doesn't seem to be specific to the editing software - it's an issue with quicktime, so any software using quicktime to interpret the files crops above and below 16/235.

I don't think it will be specific to any one editing package either.

I think that FCP might have a bit of an advantage since it can be configured to accept 'superwhite' but the bottom its going to take the work-around others are doing with the gama curves.

What we need is shoots of camera test charts. Sounds boring but those charts are calibrated and will tell us exactly what is going on with the files. I want to try remapping the luminance values to see if it can be fixed that way too.

There's a pretty clear indication and proof of the issue showing in this thread about resolving in Vegas.

http://www.dvinfo.net/conf/canon-eos-5d-mk-ii-hd/139418-vegas-workflow.html


Hopefully, there will be a resolution.

There's a pretty clear indication and proof of the issue showing in this thread about resolving in Vegas.

http://www.dvinfo.net/conf/canon-eos-5d-mk-ii-hd/139418-vegas-workflow.html


Hopefully, there will be a resolution.

That thread explains exactly what I was thinking.

I'll have to check and see what can be done to remap the values and bring them into the expected range.

I think that FCP might have a bit of an advantage since it can be configured to accept 'superwhite' but the bottom its going to take the work-around others are doing with the gama curves.

FCP only handles superwhite with YUV codecs, not RGB - it treats h.264 as an RGB codec, so that doesn't work, and the image correction filters simply ignore anything outside of the 16-235 range.

So far remapping it in the picture style editor can't fully solve the issue because the gamma curve editor doesn't allow you to change the 0 or 255 values and has an extreme and uncontrollable bias through the points on the curve.

Color does allow you to remap the luminance values and regain the clipped data - so the workflow I'm seeing come out of this is shooting with a slightly flattened color profile, then finishing in Color to eliminate any remaining clipping . Not sure what the equivalent solution will be on the PC side.

This has all been covered pretty extensively in these other threads in addition to the vegas thread linked above:

http://www.dvinfo.net/conf/canon-eos-5d-mk-ii-hd/139602-my-fcp-workflow.html
http://www.dvinfo.net/conf/canon-eos-5d-mk-ii-hd/139869-picture-style-editor-creating-profiles.html