C300: C300 MKII and FCPX Gamma shift with since latest firmware upgrade 1.0.6

C

cane141

Well-known member
Hi,


Since I have upgraded to the latest C300 MKII firmware 1.0.6 I am now getting a gamma shift, raised blacks when I playback the footage or scrub a clip in FCPX ( also latest version on El Capitain)

I narrowed it down to the firmware upgrade as the culprit as when I viewed the footage ( all recorded on the previous firmware 1.0.5 ) the footage plays fine but all the footage from projects since the latest firmware produces this gamma shift / low contrast look which is very annoying.

The other way to get rid of it is to transcode the clips out of FCPX in some converter and then it plays fine but FCPX was fine before so I would love to know if it is possible to go back to the previous firmware, any ideas would be much appreciated.
 
Cane,

In the new firmware there is an interesting note about additional metadata being added to Canon Log 1/2/3 footage indicating the video is full range (0-255) as opposed to limited (16-255).

"10. Metadata related to the XF-AVC range has been corrected.
- The range of Canon Log/Log2/Log3 has been corrected to full range."

As I've seen in a lot of NLE's, detailed in this post I did here, the footage was being misinterpreted causing clamped (and clipped) highlights and shadows. So data was being lost essentially on import.

So, without knowing Final Cut X specifically, I would imagine the image you are now seeing is actually proper compared to the clamped and more conttrasty image you were seeing previously.
 
I have noticed this potential bug: When shooting in clog-1, when I change between 12-bit 4444 mode and any other mode, the black levels change. They appear "correct" in the non 12-bit modes. This is in the current version of Premiere Pro Creative Cloud.
 
Drummondb,

"Correct" in this situation could be interpreted differently.

Remember, we are shooting a log curve here with elevated blacks. Canon Log 1 and 3 has a black point of 128 on a 10 bit scale or 32 on an 8 bit scale (like Lumetri's)

If there is anything beneath the 32 code value on your lumetri scope (before any grading obviously) then it is actually incorrect. I have a feeling the RGB information is actually going to be correct, where as your YCC modes are being incorrectly scaled.

I ran a simple test with the previous firmware on the camera - shoot all the modes with a body cap on and look at where black falls on the Lumetri Scope - and found that they were all being clamped improperly, causing me to loose highlight information and start off with deeper blacks. Building a Full Range to Legal Range scaling LUT (versus the clamp or "chop" that is happening in Premiere) allowed me to properly grade my footage in Lumetri.
 
Let me rephrase--I've been shooting C-log 1 on various C100's for years. I know where the black is going to be once graded with an official Canon LUT. If if shoot on a black background in C-log, drop on the clog-to-widedr-full LUT, I know I'm going to get a nice black background at zero IRE.

When I first got the C300mkii a few months ago, I used C-log 1 as a safety blanket, since I knew how to grade it. And yes, C300mk2 footage shot in C-log 1 responded to the LUTs the same way they always have on C100 footage. But now after the update, my black levels are different based on what color mode I'm in. It seems "wrong" to me when shooting in the 12-bit 4444 modes.

Could the footage always have been "wrong" before, and now it's "right?" Maybe, but I don't think so. I'll have to test further.
 
Hi Macaholic,

Before the latest C300 MK II firmware upgrade i.0.6, it seemed fine, but now I get a gamma shift every time I play the footage so when it's rendered it raises the blacks but when un-rendered it plays with a normal contrast look.

Which one is right?

Can I set the "data" levels in FCPX so it doesn't always play like this, every time I press stop/space-bar or scrub through the clip it's really distracting with the gamma constantly shifting, I don't get why the firmware update would do this unless it's a bug?

In Canon XF utility player, it plays at the normal contrast level and it matches the same as when I scrub through the footage in FCPX, so if this is the case, then FCPX seems to be interpreting it differently and maybe trying to correct it as you mention but whats the fix?

I can't seem to find the previous firmware 1.0.5 version on the Canon website either, right now I would love to go back to that as it was totally fine!

I pasted the images below of what happens, this is meant be C-LOG 3. I can still work with it by adding more contrast or crushing the shadows a tad more than before but it's thrown my workflow off as I had LUTS for other edits I could just copy paste but now i need to re-adjust the blacks and overall contrast...

Looking at the below images, I thought the more contrasty look (still LOG) would've been true to the C-LOG3 and the raised blacks/flatter look more like C-LOG2, I wonder if anyone else is experiencing this problem?


Screen Shot 2017-01-13 at 2.55.14 PM.jpg
Screen Shot 2017-01-13 at 2.54.38 PM.jpg
 
Last edited:
drummondb said:
And yes, C300mk2 footage shot in C-log 1 responded to the LUTs the same way they always have on C100 footage.
Click to expand...

I know C100 Mark II footage in the .MP4 format had the same issue - as in it was being read wrong in Premiere and the blacks were being crushed (again we are talking pretty slightly, but usually exacerbated by a LUT). Can't speak to the C100 MK I AVCHD though as I never shot that.

Again the simple and most sure test is to run a few frames of black in Canon Log 1 or 3, import it like you normally would, and see where it falls on your waveform, just above 26 or just below? This is something I do when on-boarding any new camera system now.

cane141 said:
now I get a gamma shift every time I play the footage so when it's rendered it raises the blacks but when un-rendered it plays with a normal contrast look.
Click to expand...

That's odd - does your waveform drop when you are playing vs. when you are paused?

cane141 said:
Can I set the "data" levels in FCPX so it doesn't always play like this
Click to expand...

I wasn't able to find anyway to dictate the data range in Final Cut Pro when I used it. I was on an older version as I won't update to Seirra just yet.

cane141 said:
In Canon XF utility player, it plays at the normal contrast level and it matches the same as when I scrub through the footage in FCPX, so if this is the case, then FCPX seems to be interpreting it differently and maybe trying to correct it as you mention but whats the fix?
Click to expand...

I would be inclined to say that it XF Utility is going to be showing the image scaled correctly. If you can get the final cut preview window right next to the xf preview window and they are at all different then I would say there is a problem.

In my version of Final Cut there is no way to change the waveform to code scale or smaller IRE values than 25, so it's impossible to check for certain like you can in Premiere.

In your two images Cane, the bottom one looks correct to me for Canon Log 3. In fact bringing the two into DaVinci, I can see that the bottom has blacks all above 128 (since there is no pure black portion in the scene this is what I would expect) and image 1 has blacks plunging down to the 70's - something that is not technically possible in an unadulterated Canon Log 3 curve.

Canon Log 2's black point is actually 96, so while the mids and highs are more compressed then Canon Log 3/1 giving visually a flatter image, the black point of Canon Log 2 being 96 will technically result in ever so slightly blacker blacks out the gate. Don't confuse that for crushed blacks/less information though, as the curve is actually showing us detail from the 96-128 region.
 
Last edited:
[video]https://vimeopro.com/acenlab/cane[/video]


Hi Macaholic,

Thanks for all your help on this, I have attached a screen capture to show what happens, with waveforms in the edit screen also. (apologies for all the teeth showing :) )

Yep, the waveform actually drops when paused, you will see this in the clip.

At this stage I would love to go back to the previous firmware version but can't seem to find it on the Canon websites, is it even possible to go back?

For some reason the clip shows up right here when using Firefox but with Safari it's not showing. I pasted a link above also.

Let me know your thoughts
Cheers!
Cane
 
Last edited:
Hi Cane

I have the exact same issue - MBPr mid 2012 macOS Sierra 10.12.2, FCPX 10.3.1, C300 Mark II 1.0.6.

The problem is there in both Rec. 709 and Rec. 2020 projects. I would also presume that the "more contrasty" version is the correct one, as that is what I am seeing when playing back the files directly from the Cfast cards. I see this as a rather serious issue as I can't use the waveforms and LUT´s also seem to be affected.

I see that you have just posted on the official FCPX support community. I hope that there will be a solution ASAP.

Cheers
Alex
 
Just reporting I have no issues with latest Canon firmware and PP/CS6 and Resolve 11.5
Shot Log 3/Cinema Gamut/Production Camera.
 
This is defininitely a FCPX problem. I've just planned a phone call with Apple support tomorrow morning (CET) I do not have high hopes though, but will chime in after.
 
Hi Alex,

The thing I've noticed, is that all the footage shot on the previous camera firmware 1.0.5 doesn't have this issue, It only happens with any footage shot with the latest 1.0.6 firmware.

I figured this out when I noticed NOT all my projects had this issue. I then looked at a bunch of footage that had the issue and without in XF utility and noticed straight away it was the firmware version that was different.

So I think it might actually be a camera issue somehow, strange!

Have you tried loading up older projects to see if the prob is across all your footage?

I also checked different c-log versions but it still behaves in the same way, something in this new firmware is culprit but also it does seem to be only happening with FCPX.

VLC player and XF utility play the footage fine??
 
Starting in FCPX 10.3, FCPX automatically applies a LUT to log footage. This is new, it didn't do it previously.

Just thought I'd give a heads up about it.

It's not a "bug" because Apple actually lists it as a feature of FCPX 10.3?!

You can turn off the LUT via the Info pane but you have to do it for each clip. Info Pane>Settings>Switch Log to None.

I'm wondering if that is what some of you are running into. It would explain why other NLE's don't have the problem with the same clips.

I have let Apple know via FCPX's feedback form that this is not good. That it should not default to applying a LUT and at best there should be a Preference to turn it on or off.

If you are used to grading on your own or applying your own LUT via a plugin this new behavior in FCPX 10.3 is a pain.

It's listed here under "Application". Camera Look Up Tables (LUTS) automatically applied to....
 
Hi Cane,

I just recently got the camera, so I dont have any footage from the previous FW to check with. However I just realised that when playing back the footage directly from the Cfast card using QuickTime player, I get the same "low contrast" result as in FCPX. In VLC it displays the footage correct. So it may have something to do with the Apple Pro Video Formats?

Just to confirm problem is there in all Log picture profiles, I have just tested BT. 709 preset, and the problem isn't there.

Log Processeing is set to None, so unfortunately that isn't the issue.
 
I agree with Jon. I also grade on my own in FCPX. In december I was to edit a documentary and before that I updated the FCPX. Immediately, it appeared as if I F**ked the exposure. I was stunned. Somehow I tried postponing the editing. Then I realised that it was an FCPX issue. Later I found out that FCPX automatically senses that the footage is shot in log and applies the LUT. There are options for C-log, C-log 2, Arri log, BMC etc etc. Just select none and it should be ok.

However, I haven't updated to the latest firmware just because I didn't have time to update the firmware and test it before shooting. Generally Canon firmwares are stable. Nevertheless after the FCPX issue, I am becoming bit more conservative in updating firmwares.
 
Hi Jon,

It is definitely not the LUT, this is just a slight gamma shift or rating of the blacks in the image, the LUT is far more extreme and out was the first area I looked at when I had the issue.

All the clips have LUT turned off but if you look at the clip ( posted on page 1 of this post ) I posted you will see the gamma shift intermittently as I press pause/start, this is definitely something else that is somehow linked with c-log footage being interpreted differently by FCPX
 
cane141 said:
[video]https://vimeopro.com/acenlab/cane[/video]


Yep, the waveform actually drops when paused, you will see this in the clip.

At this stage I would love to go back to the previous firmware version but can't seem to find it on the Canon websites, is it even possible to go back?
Click to expand...

Well look at that...

So in my opinion, the paused portion looks correct, with the slightly elevated blacks for Log or Log 3. The range shift is effecting your highlights a bit too, you could see this if you have a clip that has some almost clipping items in it when paused, I bet they will go up and clip while playing...that's why having the right range is more important, highlights.

Is this footage transcoded to ProRes? Transcoding may fix the issue because...

I believe this is caused by the Full Range metadata tag Canon added into the latest firmware (as it says it is only applied when shooting in Log). Like Bill said, it works fine in Premiere and DaVinci - so while it is triggered by the updated tag, Final Cut Pro seems to be creating the actual issue you're seeing.

I do not know if you can downgrade firmware, that's something I would ask Canon. On my old camera systems I would always save the firmware files on my computer in case of this exact issue...but I've grown far lazier unfortunately haha
 
Macaholic said:
Well look at that...

So in my opinion, the paused portion looks correct, with the slightly elevated blacks for Log or Log 3. The range shift is effecting your highlights a bit too, you could see this if you have a clip that has some almost clipping items in it when paused, I bet they will go up and clip while playing...that's why having the right range is more important, highlights.

Is this footage transcoded to ProRes? Transcoding may fix the issue because...

Yep, it transcodes it automatically when I import the footage.

I believe this is caused by the Full Range metadata tag Canon added into the latest firmware (as it says it is only applied when shooting in Log). Like Bill said, it works fine in Premiere and DaVinci - so while it is triggered by the updated tag, Final Cut Pro seems to be creating the actual issue you're seeing.

I do not know if you can downgrade firmware, that's something I would ask Canon. On my old camera systems I would always save the firmware files on my computer in case of this exact issue...but I've grown far lazier unfortunately haha
Click to expand...

The thing is, it seems to be an FCPX issue really, as PP, DaVinci and XF utility all seem fine, so I guess the firmware is ok, it's more how FCPX interprets it with the tag you mention.
 
Macaholic said:
"10. Metadata related to the XF-AVC range has been corrected.
- The range of Canon Log/Log2/Log3 has been corrected to full range."
Click to expand...
Sigh... If that's what Canon has done in this new firmware, then they have screwed up. Canon Log 1/2/3 are *not* full range. They use standard BT.709 level range encodings, though with an extended range of highlights above 100% (superwhites). It's all documented in Canon's white papers.

On Macs, in FCPX (and in DaVinci Reslove for H.264 files; not sure about XF-AVC), this is going to be a problem, because Quicktime automatically compensates when the full_range flag is set in the recorded media. If you record externally, no such flag would be set. And on Windows, DaVinci Resolve doesn't know how to read the full_range flag, and so everything is interpreted according to BT.709 encodings (automatically for most formats, or if you set data levels to Video), which will be correct for all variants of Canon Log. So this new problem will only be visible if you use FCPX (and maybe DaVinci Resolve) on the Macintosh with internally recorded video files.

You can test by recording black and measuring the black level in your NLE's video scope.

Canon Log has black at 7.3% RGB. If you see black at 12.5%, it's wrong.
Canon Log 2 has black at 3.5% RGB. If you see black at 9.3%, it's wrong.
Canon Log 3 has black at 7.3% RGB. If you see black at 12.5%, it's wrong.

Canon Log White Paper: On page 10 in figure 9, 0% reflection corresponds to 7.30597% video out. Also you can see that they use BT.709 level encodings, because 0% video out has an 8-bit code value of 16. In a full_range encoding, 0% video out has a code value of 0.

Canon Log 2 White paper: On page 7 in figure 6, 0% reflection corresponds to 3.54% video out. As with Canon Log 1 you can see that they use BT.709 level encodings, because 0% video out has a 10-bit code value of 64. The math all works out for BT.709 level encodings: 0% reflection has a 10-bit code value of 95. (95-64)/(940-64) = 3.5%. In a full range encoding, code value 95 is 95/1023 or 9.3%.

It would be really good if some of you could help out with getting sample files recorded with firmware 1.0.6 and with 1.0.5, so I can analyze and compare and be able to go back to Canon with exactly the right information about what they need to fix. A short clip recorded with the lens cap on will be sufficient.
 
Last edited:
You must log in or register to reply here.
Back
Top