fbpx
3 Post Moderation Rule for New Boarders (25 Jan 2021)

New boarders will have their posts moderated - Don't worry if you cannot see your post immediately.

Brightness jump w C300 mkII log footage

More
09 Sep 2020 00:20 #109935 by Carsten Orlt
Does anybody have the same problem and/or a possible solution:
Imported clips from original c300 MKII mxf files via Canon FCP plugin. When stopping playback the levels of my C300 mkII Canon log2/cine-gamut footage jumps up a little and then down again.
OR
the levels jump up a little when starting skimming and down again when stop skimming
It is the same brightness shift in both scenarios.
Doesn't matter if there is, or is not, a LUT or effects applied, always does it.

The interesting bit is if I open one of the original MXF clips in Compressor and apply a ProRes transcode to it, I see the same brightness shift in the preview window on the right result side.

Something has changed how XF-AVC footage is interpreted. I just don't know if it is a bug, a bad upgrade to 10.4.9 (though I have deleted pref, deleted re-installed FCP, Motion and Compressor) or only happens in Mojave which I'm still on.

Any ideas much appreciated :-)
Cheers, Carsten

Please Log in to join the conversation.

More
09 Sep 2020 23:46 #109949 by Carsten Orlt
Addition: I just noticed that FCP allows now for XF-AVC log footage to be optimised, meaning you can select the clips and choose Transcode>Optimised. This was not possible before!
AND after you do this the brightness jump is gone because FCP now uses the ProRes version which doesn't have the problem.

It seems that Apple changed the way XF-AVC log footage is processed, but still don't understand why? Would be nice to get a word from Apple or Canon on this.

I experimented with workarounds and I worked out 3 options:
Ignore the brightness jump because the exports use the correct values.
Optimise all original clips - doubles storage so not ideal and a short term solution.
Transcode all to Prores using compressor and then relink to those and delete the XF-AVC Quicktime files.

Will be interesting to see how this issue develops. Might be one that never gets explained and you just learn how to live with it :-)

Please Log in to join the conversation.

More
10 Sep 2020 12:22 #109956 by JoeEditor
Which do you have selected in the Viewer menu, better performance or better quality?

Please Log in to join the conversation.

More
10 Sep 2020 13:31 #109959 by soundbite
I started experienceing this also on both my machines after upgrade to 10.4.9

My last project imported footage from C300 II, 5D IV, FS7 I all shooting log and this glitch only happens with the C300 footage.

I have reported it to Apple for what good that will do.

Please Log in to join the conversation.

More
10 Sep 2020 13:33 #109960 by soundbite
I made a short screen record to show Apple what was happening and they did look at it.

bit.ly/testfile4920

Please Log in to join the conversation.

More
10 Sep 2020 13:35 #109961 by soundbite
Ignoring the brightness jump really isn't an option beacuse it also jumps brighter when adjusting colour values which is a royal pain in the butt.

Please Log in to join the conversation.

More
10 Sep 2020 20:23 #109966 by Carsten Orlt
Happens in either mode.

Please Log in to join the conversation.

More
11 Sep 2020 05:36 #109973 by Carsten Orlt
good to know and I submitted it too but without any video :-)

Please Log in to join the conversation.

More
11 Sep 2020 12:47 #109975 by joema

cofe wrote: ...original c300 MKII mxf files...When stopping playback the levels of my C300 mkII Canon log2/cine-gamut footage jumps up a little and then down again...


Using the file that soundbite uploaded, I see the problem in 10.4.9 on Catalina, not just Mojave. It does not happen with 10.4.6 or 10.4.8. It happens whether clip is imported using "leave files in place" or copied to library. I have Apple Pro Video Formats 2.1.2 installed.

It does not happen if the timeline is rendered to cache, either manually via CTRL+R or automatically via background render.

However that is based on testing with soundbite's clip which I think is either a capture or a rendered Quicktime file -- not the original camera MXF. Why the behavior would persist in a captured or re-encoded file, I have no idea.

Using the media inspection tool Invisor shows several metadata fields are flagged with "unknown kind of value". Can anyone upload a short original C300 MXF file? If that is a tree-oriented format we'd need the ZIP'd folder tree holding that short clip, in order to ensure all sidecar metadata was present.

Please Log in to join the conversation.

More
11 Sep 2020 13:03 #109976 by soundbite
Hi -

Fortunately I have a card with 1 35s clip on it from yesterday which i have zipped up from the root CONTENTS and dropped in the same folder. It's about 1.7gb

You are right that the .mov file was pulled from an FCP library post import.

Please Log in to join the conversation.

More
11 Sep 2020 13:49 - 11 Sep 2020 14:01 #109977 by joema

soundbite wrote: Fortunately I have a card with 1 35s clip on it from yesterday which i have zipped up from the root CONTENTS and dropped in the same folder. It's about 1.7gb..


Thanks for doing that. I downloaded and tested the original MXF and confirm it's a bug unique to 10.4.9. It happens whether imported to library or with "leave files in place". Using color space override in Inspector>Settings does not help. In some previous problems that was a workaround.

A possible workaround is externally re-wrapping the material using EditReady2, then importing with "leave files in place". I tested that and it seems to work. Re-wrap is very fast since it's not transcoding. This also rolls up all the metadata into the single video file, enabling proper import with "leave files in place". Aside from this problem, that's a common workflow for certain tree-oriented media: www.divergentmedia.com/editready

Another workaround is fully render the timeline to cache, either via CTRL+R or background rendering. Obviously it will only render the timeline if there's some effect on the material, but for log material there's always a color effect of some kind.

It also doesn't happen if using ProRes proxies, but it happens if using H264 proxies. However it's not burned into the H264 proxies because if those are copied to a proxy-only library, it doesn't happen there.
Last edit: 11 Sep 2020 14:01 by joema.

Please Log in to join the conversation.

More
24 Sep 2020 22:18 #110212 by Carsten Orlt
All fixed w FCP 10.4.10 and Pro Video Format 2.1.3

Please Log in to join the conversation.

More
26 Sep 2020 11:05 - 26 Sep 2020 11:09 #110232 by soundbite
It is fixed thanks but it transpires that the true state of the colour grade was actually the one showing when playing or adjusting (ie the lighter more washed out state) not the darker state when static.

As the static grade was the one that seemed to export it was reasonable to assume the opposite so now I have to go back and regrade a whole bunch of clips from scratch.
Last edit: 26 Sep 2020 11:09 by soundbite.

Please Log in to join the conversation.

More
27 Sep 2020 08:12 #110253 by Carsten Orlt
I can confirm your observation. And I was thinking the same as you as to which is the correct state. Just glad it's fixed now

Please Log in to join the conversation.

More
10 Sep 2021 09:17 #116179 by BossB
It's fixed for those running newer operating systems, but if you're still on Mojave, it seems you are unable to upgrade further than 10.4.9. Like me. :'(

I have been using prores proxies and that solves it, but when it comes to colour grading it is a real pain because I dont want to use the proxies to grade.

Please Log in to join the conversation.