I have yet to thank you for that. So, thank you! <SMILE>

Quicktime 7.6 on the mac opens the h.264 files with the discussed over bright gamma when the 'Final Cut Studio color compatibility' preference is checked.

The info text below displays ' When enabled, video is not displayed using ColorSync. Source colors are read with 2.2 gamma and are displayed in a color space with 1.8 gamma.

After the QT 7.6 update Mpeg Stream Clip now displays a great image and renders out to Pro Res without the need to go into Apple Color.

Can you guys tell me if this is what I should be doing on a PC with either Premiere or
Vegas....

Open Quicktime, open 5DMKII movie, export movie using same settings as the original movie, then open either Premiere or Vegas and edit the output movie from quicktime as usual??

Does this sound right, or am I missing something

For Vegas, I recommend using the latest version of Quicktime. For quick edits, you can just put the clips on the timeline and edit. The blacks won't be crushed, but for some reason, the mid-tones are artificially lifted.

For the cleanest results, you can still re-wrap. Details are here:
http://www.dvinfo.net/conf/canon-eos...rap-vegas.html

Neither solution deals with the hungry nature of this codec. It won't play in real time on most Vegas systems. That's another topic though...

After I ran the update I'm still having the same issues in fcp & quicktime player, but things look fine in MPEG Streamclip...

I've been intrigued by this update and i've been looking more closely at some stuff and without getting into it too much I think some problems remain.

essentially what seems to be happening is that quicktime is performing a conversion from YUV to studio RGB (at least it's scaling it properly without clipping the "superwhite" and "superblacks'), but then it stretches the range back out to cRGB and that's the output. This reduces the detail - you can see there are 36 gaps in the histogram for the RGB channels.

Ideally given our 8-bit RGB colorspace limitations, Quicktime would convert from YUV straight to cRGB, scaling the levels properly, leaving us with all of the details and full 8-bit (256 levels) resolution. I still see this as an improvement over what we had, which seemed to be YUV->sRGB (without properly scaling the out of bounds levels) and then passing clipped 220-levels cRGB.