Page 2 of 6 FirstFirst 123456 LastLast
Results 11 to 20 of 60
  1. Collapse Details
    #11
    Junior Member
    Join Date
    Nov 2016
    Posts
    21
    Default
    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.


    Reply With Quote
     

  2. Collapse Details
    #12
    Senior Member
    Join Date
    Jun 2013
    Location
    Dubai & London
    Posts
    189
    Default
    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??


    Reply With Quote
     

  3. Collapse Details
    #13
    Senior Member
    Join Date
    Nov 2013
    Posts
    176
    Default
    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....


    Reply With Quote
     

  4. Collapse Details
    #14
    Junior Member
    Join Date
    Nov 2016
    Posts
    21
    Default
    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.


    Reply With Quote
     

  5. Collapse Details
    #15
    Senior Member indiawilds's Avatar
    Join Date
    Apr 2011
    Location
    New Delhi, India
    Posts
    1,221
    Default
    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.
    Sabyasachi Patra / Wild Tiger Productions
    Equipment Reviews:http://www.indiawilds.com/diary/category/equipment/
    Youtube channel:https://www.youtube.com/user/IndiaWilds
    Profile:http://www.indiawilds.com/about.htm




    Reply With Quote
     

  6. Collapse Details
    #16
    Senior Member
    Join Date
    Jun 2013
    Location
    Dubai & London
    Posts
    189
    Default
    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


    Reply With Quote
     

  7. Collapse Details
    #17
    Senior Member
    Join Date
    Aug 2014
    Posts
    164
    Default
    Quote Originally Posted by cane141 View Post
    https://vimeopro.com/acenlab/cane



    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?
    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


    Reply With Quote
     

  8. Collapse Details
    #18
    Senior Member
    Join Date
    Jun 2013
    Location
    Dubai & London
    Posts
    189
    Default
    Quote Originally Posted by Macaholic View Post
    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
    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.


    Reply With Quote
     

  9. Collapse Details
    #19
    Senior Member
    Join Date
    Jan 2011
    Posts
    251
    Default
    Quote Originally Posted by Macaholic View Post
    "10. Metadata related to the XF-AVC range has been corrected.
    - The range of Canon Log/Log2/Log3 has been corrected to full range."
    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 by balazer; 01-17-2017 at 08:06 PM.


    Reply With Quote
     

  10. Collapse Details
    #20
    Junior Member
    Join Date
    Nov 2016
    Posts
    21
    Default
    Here is a sample file with lens cap on, firmware 1.0.6, Canon Log 3 : C.Gamut, preset.

    https://www.dropbox.com/s/8u4vda7pg6...CANON.MXF?dl=0


    Reply With Quote
     

Page 2 of 6 FirstFirst 123456 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •