Alvise Tedesco
Well-known member
This stupid gamma shift baffles every effort I made of being unbiased shooting some side by side with my Raven.
12bit 4444 it's soo nice!
12bit 4444 it's soo nice!
C300: C300 MKII and FCPX Gamma shift with since latest firmware upgrade 1.0.6
- Thread starter cane141
- Start date
When looking at a 10 bit code value scope in say DaVinci Resolve, setting the footage to Full Range lands a black capped frame of Canon Log 1/3 at 128 - and that is the stated black point of Canon Log 1/3. When setting it to video levels, that level is brought down well below where the curve maps black. The curve literally does not allow for any data to fall below 128.
The REC Out terminal also fed to a 8 bit scale shows a live capped off shot at 32.
Everything I've seen leads me to believe the Canon Log's are encoded at full 0-255, while Wide DR is 16-255 (Video Levels with Super Whites) as you refer to balazer.
But that line in the white papers did give me doubt - I think it is just worded a little odd.
kohl-sudduth
Well-known member
Just tested similarly and I can confirm. PPro and Resolve both do not demonstrate this behavior in either the image itself, the 'in-app' scopes, or two sets of external scopes (FSI Monitor and Scopebox run through Mac Mini server). The behavior in FCPX for me is that pausing causes a brief Gamma spike when the space bar is hit and then Gamma immediately returns to normal. It's annoying but not a big drama.
I'm in contact with an FCPX dev. I'm happy to reach out to him to tell him about this behavior. So to clarify... as previously stated, there's a Gamma spike upon pausing playback with various flavors of C Log footage. Does this accurately express other's experience as well?
Screenshot of the same Log 3 clip played in QuickTime Player (left) and VLC (Right) - https://www.dropbox.com/s/3z0b8ug1jt03pcp/Skærmbillede 2017-01-18 kl. 23.26.08.png?dl=0
The QuickTime clip is similar to what it looks like in FCPX when it is done rendering, the VLC clip is what it looks like during rendering. To me the it looks like the VLC clips is the correct one?
The QuickTime clip is similar to what it looks like in FCPX when it is done rendering, the VLC clip is what it looks like during rendering. To me the it looks like the VLC clips is the correct one?
kohl-sudduth
Well-known member
Per this thread, I understand that's a QT issue: http://www.dvxuser.com/V6/showthread.php?351876-Adobe-Premiere-Color-Shift-On-Export-Solutions
Scopes in DaVinci Resolve don't show you 10-bit code values. The scale on the scopes is pure fiction. Resolve's pixel format is 32-bit floating point RGB, with reference white at (1,1,1) and reference black at (0,0,0). The top of the scopes is 1 and the bottom of the scopes is 0. At no point does Resolve show you the actual code values of the video file. The file gets decoded and interpreted and mapped into the 32-bit floating point values, and yes, that interpretation depends on how Data Levels is set in Clip Attributes. On the Mac, it can also depend on what interpretation Quicktime does when decoding the video file, before any image data is even passed to Resolve.
Here's what I'm seeing in Premiere Pro cc2017 on a windows 7 PC. C-log 1 black levels should be 7.3 IRE. They are at that level in all modes, except the internal RGB 444 modes, both 12 bit and 10 bit. The proxy files, the hdmi port,and the sdi port all put c-log black levels at 7.3, as does the c100mkII.
Here's a screen capture of my scopes in Premiere: https://vimeo.com/200226444
Here's a screen capture of my scopes in Premiere: https://vimeo.com/200226444
Hi, Alex.
Thanks for uploading. It was an elephant in a room, not black. I analyzed the clip, and it does have the H.264 VUI video_full_range_flag set. That would appear a bug in Canon's firmware, but I'd still like to analyze an all-black clip so I can be absolutely sure before I reach out to Canon.
Last edited:
sunnyjimfilms
Well-known member
This has been fixed with FCPX update.
kohl-sudduth
Well-known member
Hi balazer,
Sorry for the elephant, wrong clip -that clip was not even Clog. Here is the correct clip - https://www.dropbox.com/s/0wa8p9ibgaxd6pv/A009C503_1701186G_CANON.MXF?dl=0
As Sunnyjimfilms stated the shifting behaviour in FCPX is fixed with the latest update. However FCPX stil interpretes the C-log clips in what looks to be the "wrong gamma". See post #24 in this thread.
Sorry for the elephant, wrong clip -that clip was not even Clog. Here is the correct clip - https://www.dropbox.com/s/0wa8p9ibgaxd6pv/A009C503_1701186G_CANON.MXF?dl=0
As Sunnyjimfilms stated the shifting behaviour in FCPX is fixed with the latest update. However FCPX stil interpretes the C-log clips in what looks to be the "wrong gamma". See post #24 in this thread.
kohl-sudduth
Well-known member
If by THIS you mean a brief Gamma shift of over exposure various C Log files when viewed in Premiere in Source and Program panels and also through an external reference monitor and waveform (through ScopeBox), then in my experience, no it's not an issue. One idea is to test and retest on your system and see what you come up with.
As to the deeper discussion in this thread regarding data analysis and black level interpretation, that is beyond my understanding.
Thanks for sending the new clip.
Glad about FCPX fixing the weird level shifting, but I did confirm that the C300 Mark II 1.0.6 firmware is setting the H.264 VUI video_full_range_flag erroneously. Your sample video uses SMPTE/legal/TV/video/BT.709 levels, not full range levels. All of the Canon Log clips are *supposed* to show the same levels across all cameras, video apps, and firmware versions, whether recorded internally or externally. This bug in firmware version 1.0.6 means levels will be different for internally recorded clips in apps that know how to read the flag. FCPX is affected, apparently. DaVinci Resolve on the PC is not affected. Externally recorded clips won't be affected, which is to say that internally and externally recorded clips from firmware 1.0.6 won't match each other in FCPX, which is obviously a bad thing.
I will try to bring this bug to Canon's attention.
AndreeOnline
Veteran
It's not in error, Canon highlights the change in the firmware notes:
Firmware Version 1.0.6.1.00 incorporates the following fixes and enhancements:
1. Support for the OLED Electronic Viewfinder EVF-V70 *1 has been added.
2. Shutter Angle Priority has been added. A constant shutter angle can now be maintained, regardless of any other camera settings being changed.
3. Support for the WFT-E8 has been added.
4. Zebra Range Expanded Below 65%.
- The range of the Zebra 1 setting has been expanded to between 5% (±5%) and 95% (±5%) in steps of 5%.
- The range of the Zebra 2 setting has been expanded to between 5% and 100% in steps of 5%.
5. Built-in Mic Audio Off
- The internal microphone on the camera body can now be turned off.
6. In Browser Remote, the focus guide frame can now be displayed.
7. 2K Crop Audio Recording
- Audio can now be recorded when the camera is set in 2K crop mode.
8. Support for CFast cards (VPG130) has been added. *2
9. Support for peripheral illumination & chromatic aberration when the EF 24-105mm f/4L IS II USM lens is attached, has been added.
10. Metadata related to the XF-AVC range has been corrected.
- The range of Canon Log/Log2/Log3 has been corrected to full range.
11. The quality of autofocus has been enhanced.
12. The operation reliability after changing the recording mode has been enhanced.
There is indeed some weirdness involving black levels and the rgb 444 modes in Premiere Pro: http://www.dvxuser.com/V6/showthrea...emiere-Pro-on-444-modes-after-firmware-update
They didn't correct it. They screwed it up. It was right before, and then they made it wrong in the 1.0.6 firmware.
AndreeOnline
Veteran
From a perspective where 'full range' is wrong, you're right.
I personally much prefer full range, but that is beside the point. What I'm saying is that when Canon explicitly says the change is deliberate and according to what they feel is right, then they didn't screw it up.