Mark III Color Shift / Rec 709 Color Space Problems

[Picture and Color]

I'm having an absolute hell of a time dealing with the MkIII footage, especially when I'm cutting it with my Mark II stuff.

I'm shooting with the All-I 1920 x 1080 24p setting and using FCP7. When I first tried to transcode using Compressor, all my reds were messed up and shifted magenta. All the flesh tones were wrong.

Example heres:

http://www3.telus.net/sampat/Mk3/mk3_transcode.jpg

http://www3.telus.net/sampat/Mk3/mk3_transcode2.jpg


I soon figured out that I needed to use 5D-to-RGB to transcode instead. The footage came out correctly when I selected the 709 Matrix along with the full range.

Happily I started to edit and put together my footage. However, when I went to export in my usual way using Final Cut Pro (x264 encoder), the colors got messed up again. Back to pushing magenta and crushed dynamic range. I suspect it's cause I'm using compressor via FCP7 to encode my final work.

How do I fix this? I don't see anywhere in export process to change to rec 709 color space or the full luminance range.

I spent 5 hours on this edit, and it's pretty much undeliverable at this stage. Please help.

[Axel]

I honestly never understood the logics behind these shifts. Therefore these are no answers, but more questions:

> you transcoded to ProRes for editing. I understand the codec is not accepted by log&transfer? Is that the reason why you used Compressor for the transcoding? And then you transcoded with another batch-transcoding-application named 5D2rgb?

> since you edit in a ProRes-sequence, why don't you export a master in ProRes as "self-contained movie"? Because, if this is a problem of a colorspace-shift (the notorious Quicktime gamma-shift only affects gamma, hence the name) and if the colors look right in ProRes, this may be a matter of checking a box before you encode as mp4. My x264 plugin module has a lot of options. I export with MpegStreamclip, because with QT7pro (residing in [i]Utilities[/i], I saw by the screenshots that you don't use it as player) there are considerably less options.

> doesn't the colorspace change to YUV again with mp4? Why haven't you experienced the same problems with mii?

[Picture and Color]

Thanks for responding Axel.

I have been using x264 encoder due to QT's notorious gamma shift as u mentioned, but u gave me the idea of using QT again. With the gamma shift, the final export actually looks very close to what i saw in my timeline. A happy accident.

I think I need to do some tests with editing the all-i right on the timeline. I've always transcoded to ProRes first because it feels so much faster on the timeline.

To answer your questions, yes, even with the EOS plugin the mkIII footage cannot be ingested via L&T.

Admittedly the mark ii has the luma troubles as well, but it doesn't shift in color.

Even if I do export a master in ProRes, I still need something to reliably convert it to H264 for web... something I don't currently have.

[Axel]

Again I am out of my depth, but I try my best ("act as if you know!"). Shouldn't you have a LUT for the colorspace to judge it correctly? Or to get it presented in the right way in the first place? (Which of the two sentences is more wrong?) Seems it isn't just "RGB" or there would be no shift. The QT gamma-shift doesn't change the values of the pixels, it shifts the gamma just when the video is played. Isn't this something similar with the colorspaces? All you know for sure is that the result looks bad. There could also be a filter saved once and for all to compensate for the shift (and then easier applied on a ProRes master than earlier or later). Best of course, if you find out why this happens at all.

[see ya]

Just tranfer the color matrix of you mkII sources to BT709 and that should be sufficient. Then both mkII and III will be BT709 which is the default for HD unless flagged in the stream otherwise.

How you transfer the matrix you'll need to search, I use Avisynth but may not be suitable for you, your NLE hopefully has a filter or something to transfer the matrix BT601->BT709. The color matrix relates to conversion of YCbCr sources to RGB and therefore playback.

With regard to the other query, as soon as you transcode or import Canon native files your full luma gets squeezed and then expanded back to so called RGB levels by the NLE because of the h264 having metadata in the header of the stream signalling full range luma so instead of just leaving levels where they are the NLE squeezes luma 16 - 235 in order to do the typical 16 YCC maps to 0 RGB and 235 YCC mapped to 255 RGB in order to maintain levels when the data is RGB in the NLE for color processing but in the process you loose fine gradation of original levels. It can be clearly seen when it happens by thickened horizontal lines at regular intervals in your luma waveform monitor.

I explain here: www.blendervse.wordpress.com transcoding is unnecessary to fix full luma handling a simple remux with a VUI Options aware tool like a custom build of MP4Box will surfice as explained in the blog post.

But if transcoding for playback reasons you could remux to dump the metadata and you'll be able to transcode to any codec you like and keep full luma including Prores.

Whether this process is suitable for Mac I don't know.