Ya, Carbon Coder costs 5000$ ...I could buy a Mac for that price!

NewTek SpeedEDIT interprets files correctly if anyone is interested. To make the color space fit inside RGB colorspace just check the "Non ITU-R BT601 color" checkbox in the Layer Settings dialog :)

[QUOTE=Oleg Kalyan;978970]I see Carbon Coder, a universal transcoding application for $20 in a few places

Ohh... sorry, I wonder if the cost i saw on their website is a business license cost?

http://www.rhozet.com/rhozet_priceList.pdf

Can i ask a question Oleg - is it a effects plugin? Do i add it to my effects before transcoding to, say Cineform? Or do i need to use the standalone app?

In Vegas it's simple to translate from Computer RGB to Studio RGB. In an 8-bit project, apply the color corrector plugin to your track and select the "Computer RGB to Studio RGB" preset.

There has been a lot of conjecture that the 5D MkII was crippled for marketing reasons, but I'm thinking that this was a case of photo engineers making a video product. They did a great job with imaging, but didn't know how much they didn't know about video.

The evidence?
* 30p, rather than 29.94p (let alone no 24/25, etc) NOTHING is 30p in the video world.
* 0-255, rather than 16-235. Sure, it's better for images (a few more levels), but it's not standard video. If you want more levels, give us 10-bits.
*Nutty algorithms like making the shutter 1/focal length. It's bad enough that they didn't give us manual control, but to choose stuff like that is just plain off-the-wall.

In Japan, project teams have a lot on internal loyalty. I get the feeling that the video function was developed by the camera team with complete secrecy from the video teams. It might have helped politically, but led to some "odd" technical decisions.

It seems that "$20 Carbon Coder license" is not for business purpose. Maybe only for "home" usage (I hope you understand what it's means).


The Phozet Carbon Coder utility retains full level range of 5Dmk2 video (Upper histogram).
Other NLE's lose information: red areas on histogram's ends; gaps in the histogram. The result - too contrast picture, crushed down blacks, highlights without details.
http://www.dvinfo.net/conf/attachmen...dmkii_hist.jpg


I know only one way to resolve the "contrast" problem on PC platform:
- convert .MOV-files to .AVI-files by Phozet Carbon Coder;
- work with resulting AVI-files in your NLE.

P.S.
I have no NewTek SpeedEDIT, so can't comment.
The MPEGStreamClip utility was tested. It interprets 5Dmk2 video incorrectly (lose information the same way as others NLE's).

Jon, I tryed this way. It's not resolve the "contrast" problem of origin MOV-files.

The origin video and histogram:
http://www.videomax.ru/forum/uploads.../IMG_Vegas.jpg
http://www.videomax.ru/forum/uploads...HIST_Vegas.JPG


The origin video (translated from Computer RGB to Studio RGB):
http://www.videomax.ru/forum/uploads...oStudioRGB.jpg
http://www.videomax.ru/forum/uploads...oStudioRGB.JPG

The histogram remains the same form. It was squeezed, but without appearance of new details (see sky).



The video after Carbon Coder and histogram (see details on the sky):
http://www.videomax.ru/forum/uploads...IMG_Carbon.jpg
http://www.videomax.ru/forum/uploads...IST_Carbon.JPG

Look at appearance of histogram. Now we adds new areas on ends. And gaps disappeared.


Finally let's try "Computer RGB to Studio RGB" to Carbon Coder's video:
http://www.videomax.ru/forum/uploads...oStudioRGB.jpg
http://www.videomax.ru/forum/uploads...oStudioRGB.JPG

Feel the difference.

Ivan: Am I understanding this right: What your last example appears to show me is that the detail is not lost in Vegas, its just a matter of applying the proper manipulations through filters, or post Vegas processing to get to that point. Question I have is there away to do this in Vegas without resorting to Carbon Coder.

And by the way, is this OEM outfit legitimate ?

This is what SpeedEDIT looks like when the footage is first imported, the switch to correctly interpret color and the resulting image, all with RGB waveform to verify clipping. The big plus is that you can start editing right away instead of waiting for any transcoding, not to mention the quality hit/extra space.

Ivan,

Your examples shows the problem clearly. The source material is encoded as 0-255, but the Quicktime decoder seems to expect 16-235 AND it is stretching 16 to 0 and 235 to 255. The decoded clips in Vegas are clipped as soon as decoding occurs.

I verified the incompatibility between the 5D MkII output and Quicktime Pro by exporting as a PNG. I get the same results (clipped clouds) on the PNG as I do in Vegas.

If somebody has Quicktime Pro on a Mac, it would be interesting to see if this is a problem on that platform too.

Either the 5D is encoding to the wrong levels, or the metadata is incorrect. It's probably the latter, considering that other decoders can handle it.

Aside from buying new tools, it seems that one solution would be to create a custom profile in the camera. This will reduce dynamic range slightly (219 vs 255 => 14%), but will avoid clipping.

Here's the PNG export direct from QT. Note the flat/clipped clouds: http://colcrush.com/jon/MarketMan_Frame001.png

This is a long-standing issue with quicktime - it first showed up years ago when people noticed luminance shifts in renders with DV footage. The 'solution' was to give FCP the option to render in YUV and use the full range, but it didn't solve the underlying issue of quicktime forcing RGB into the 16-235 range. Now we're working with a camera that encodes to an RGB codec and the problem is just showing up - hopefully this will prompt Apple to do something about it, but considering how long it's been around without them really solving it I wouldn't hold my breath.

I tried TMPGEnc 4.0 Express (a reasonably flexible encoder of various formats for $99), but it had the same problem. It also relies on the Quicktime file decoder to open the .MOV file.

It seems that custom presets are the only workaround, short of buying a custom ($$$) Quicktime decoder.

It would be interesting to know if there was something in the file.MOV metadata that could be tweaked to make Quicktime decode it properly...

Jon, you are the Man! You can understand my poor English!

I think you are right here: "The source material is encoded as 0-255, but the Quicktime decoder seems to expect 16-235 AND it is stretching 16 to 0 and 235 to 255. The decoded clips in Vegas are clipped as soon as decoding occurs."

You wrote: "Either the 5D is encoding to the wrong levels, or the metadata is incorrect. It's probably the latter, considering that other decoders can handle it."

I also think that problem is with metadata.

I don't know who should resolve the "5D MOV metadata" problem. Either Canon, or NLE's manufacturers, or Apple with Quicktime.

I wonder what is a secret with that Phozet Carbon Coder, it can correctly decode 5Dmk2 MOV-files.

Ok so what does this mean? I'm confused. I dropped the raw 5D file in, set my project properties to match file...? I don't see any weird spaces in my histogram. Am i doing something wrong?

Ivan, your English is perfectly clear. Thanks for demonstrating the problem with the 5D MkII output.

Mike, I saw the same result (no gaps) at first. Make sure that your project is 1920x1080 and that your preview is Best and Full. Otherwise, Vegas will do some filtering and smear the values. Even without the gaps, you can see the peak at black.