Nope, that's wrong. Canon Log 2 uses video levels, not full range. This is easy to verify by shooting a black frame. Black comes in around code value 95, which is 3.54% only when interpreted as video values. And Canon Log 2 does use color values below 10-bit code value of 95. That's how it encodes negative linear reflection values, which result from out-of-gamut colors. This too is easy to verify, and it's independent of whether you interpret the video as video levels or full range. Shoot a black frame and note the black level. Then shoot some highly saturated colors, and you will see color values in one or two of the color channels falling below the black level. The Canon Log 2 EOTF explicitly handles 10-bit code values below 95. Check Canon's "Input Transform Version 201612 for EOS C300 Mark II" and you'll see what they're doing.
Navigation
Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
More options
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
C300: C300 Mark II, Log 2 strange color reproduction and noise pattern / aliasing
- Thread starter Alex P
- Start date
Thank you so much for the informative replies.
Could this be a reason why the particularly saturated colours like the purple and the green are so noisy? Because Resolve is misinterpreting the way the camera stores these out-of-gamut colours?
Does the same thing happen in CLog3?
On a side note, I was also playing around with some C700 footage from here: https://www.lensrentals.com/blog/2017/02/first-impressions-of-the-new-canon-c700/
and I didn't see this thing happening. Any ideas why that might be the case?
Could this be a reason why the particularly saturated colours like the purple and the green are so noisy? Because Resolve is misinterpreting the way the camera stores these out-of-gamut colours?
Does the same thing happen in CLog3?
On a side note, I was also playing around with some C700 footage from here: https://www.lensrentals.com/blog/2017/02/first-impressions-of-the-new-canon-c700/
and I didn't see this thing happening. Any ideas why that might be the case?
The noise is because the colors are dark and the exposure and/or ISO setting are too low.
Resolve has no problem handling negative color values. Everything below zero gets clamped to zero in the output, or you can use a transformation to bring the colors back inside the gamut.
Canon Log 3 also encodes out-of-gamut colors with color values below the black level.
That C700 footage doesn't have any highly saturated colors, so everything fits within the gamut.
Resolve has no problem handling negative color values. Everything below zero gets clamped to zero in the output, or you can use a transformation to bring the colors back inside the gamut.
Canon Log 3 also encodes out-of-gamut colors with color values below the black level.
That C700 footage doesn't have any highly saturated colors, so everything fits within the gamut.
Black comes in around code value 95, which is 3.54% only when interpreted as video values.
When I shoot a black frame - and bring it into DaVinci in "Auto", I get black falling far below 95. When I change clip attributes to Full, black lands right at 95. It's easier to tell with Log 3 or 1 as that black falls right on the 128 line.
Everything I've seen implies the Canon Logs are using full range - including the new firmware update they released with a note about adding a full range tag in the metadata of Log footage.
I need to explain the video encoding and decoding process a little for you to understand what you're seeing.When I shoot a black frame - and bring it into DaVinci in "Auto", I get black falling far below 95. When I change clip attributes to Full, black lands right at 95. It's easier to tell with Log 3 or 1 as that black falls right on the 128 line.
The camera takes its raw linear sensor values, debayers them if necessary, scales the red, green, and blue channel values to balance for white, and then applies a matrix to transform from the raw sensor domain to linear XYZ color values. Then the camera applies a chromatic adaptation matrix to transform the white point to the white point of the output color space, D65 in the case of standard HD video. Then it applies a gamma curve, which is most often something similar to the BT.709 curve.
At this stage the video signal consists of red, green, and blue color channels which range from 0% to 100%, that range being the range of brightnesses the display can produce in each of its color channels. 0% in all three channels is the display's black, and 100% in all three channels is the display's white. The underlying mathematical representation of the signals are numbers that range from 0.0 to 1.0, but for convenience we often describe them as percentages. (Some people call them IRE, but that's incorrect)
Next, the red, green, and blue signals are transformed into a different representation that has a luminance signal (Y), and color difference signals (Cb and Cr). The luminance signal is the weighted average of the red, green, and blue channel values, with coefficients 0.2126, 0.7152, and 0.0722. The luminance signal is supposed to be a representation of how bright the image is. You could display only the luminance signal, and you'd have a black-and-white image. The blue color difference signal is the blue channel signal minus the luminance signal. The red color difference signal is the red channel signal minus the luminance signal. The point of transforming from RGB to YCbCr is that the color difference signals will be sampled at a lower resolution, just one half or one quarter the resolution of the luminance channel. It's a kind of compression, because our eyes are supposed to have less resolving power for colors than for brightness.
At this point the luminance signal has a range of 0 to 1, and color difference channel signals have a range of -1 to 1. Color difference subsampling is performed at this stage. Next the signals need to be digitally encoded. If we're using 10 bits for each sample, there are 1024 possible binary codes, which are used to represent integer code values in the range 0 to 1023. But we don't use that full range to represent the 0-1 signal range. We use a range of 64 to 940 for the luminance channel, and 64 to 960 for the color difference channels. A code value of 512 in the color difference signals is the neutral value, corresponding to 0.0. So (64,512,512) in the digital representation is black, and (940, 512, 512) in the digital representation is white. You'll note that the full range of possible code values wasn't used. That allows encoding of values above 1.0 or below 0.0. Code values (1023, 512, 512) for example encode a brighter-than-white "superwhite" with an RGB value of (109.47%, 109.47%, 109.47%). (1023-64)/(940-64) = 1.0947
When you read a video file in DaVinci Resolve, it decompresses the video file to get the code values, then it transforms from YCbCr to RGB. When Clip attributes Data Levels is set to Video, Resolve uses the levels encoding that I mentioned above. (940, 512, 512) becomes (1.0, 1.0, 1.0) and (64, 512, 512) becomes (0.0, 0.0, 0.0).
The next thing to understand is that DaVinci's Resolve's video scopes aren't showing you code values. It's showing you Resolve's 32-bit floating point working space, which has black nominally at 0.0 and white nominally at 1.0. The scopes are labeled with a scale that goes from 0 to 1023, but that's false. The real scale of the scopes is 0.0 to 1.0. Resolve never shows you the code values of the video file. It only shows you 32-bit floating point values, after decoding the code values and transforming to RGB.
Canon Log 1, 2, and 3 are not display-referenced color spaces. They are scene-referenced, and they use the video signal in an unconventional way. 0% is not black and 100% is not white. Using Canon Log 2 as an example, black is 3.54% and the scale goes up to 109%, though the maximum value that the C300 Mark II will produce in Canon Log 2 is 92%. In Canon Log 1, black is 7.3% and the maximum is 109%.
So when you shoot black in Canon Log 2 and bring that into DaVinci Resolve with Clip attributes Data Levels set to Video, black is right around 3.54%, right where it's supposed to be according to the Canon Log 2 specification. 3.54% is 36 in Resolve's false 0-1023 scale.
So the main thing to understand is that Resolve never shows you code values, and the scopes being labeled with a scale of 0-1023 doesn't mean it's showing you code values. Resolve decodes the video and transforms the code values into 32-bit floating point RGB, and that's what scopes are showing you. If you have Clip attributes Data Levels set to Video, Resolve reads the code values assuming a range of 64-940 in the luminance channel and 64-960 in the color difference channels, and that is consistent with the way all of the Canon Cinema EOS cameras encode their Canon Log footage. If you want to see the actual code values of the video file, you need to use a tool other than Resolve.
I need to explain the video encoding and decoding process a little for you to understand what you're seeing.
So I'm not as heavy on the science side as you Balazer - but when I see that highlight information that I know was captured in camera now being clipped in Resolve - and that setting the range to full brings back that detail and gives me the exposure I was expecting; it makes me lean towards the idea that the footage is in fact full range and doing the legal scale on a data file was causing the clipping.
Is there a more engineering explanation for that? I just feel like the option that gives me exposure identical to in camera (Full Range) would be the right option...
Genuinely asking, thank you!
In Resolve with Clip attributes Data levels set to Video, nothing is clipped. Your highlights are there, between 100% and 109%. If you want that range of highlights to be preserved in the output, they need to be pulled down below 100%, which you can easily do in Resolve by dragging the gain or offset sliders down. LUTs can also access that range. Most LUTs only read 0% to 100%, but my Logarist LUTs for Canon Log, for example, read up to 109%. By the way, Only Canon Log and Canon Log 3 use values up to 109%. Canon Log 2 on the C300 Mark II stops at 92%.So I'm not as heavy on the science side as you Balazer - but when I see that highlight information that I know was captured in camera now being clipped in Resolve - and that setting the range to full brings back that detail and gives me the exposure I was expecting; it makes me lean towards the idea that the footage is in fact full range and doing the legal scale on a data file was causing the clipping.
If you're wondering why Canon decided to use values above 100%, I'm not really sure, but it was a common thing for camera manufacturers to do. A lot of professional camcorders do that. Sony S-Log does it. In BT.709 with no knee for example, 100% to 109% gives you an extra quarter stop of highlight range that would normally be hidden, but can be pulled down below 100% in post if desired.