I purchased the color checker to get more accurate colors and also because it can be a huge time saver. While I am pretty happy with the results in more controlled indoor environments, I am struggling to get accurate colors without color banding in outdoor environments.

I try to exposure 18% grey properly via Zebra at roughly 40IRE.

When I match colors within Resolve via color match tool, the colors look accurate but e.g. within the sky it introduces heavy color banding.

The effect us reduced or almost gone when shooting 4K25p at 10bit. However I will need 50p to capture fast moving objects (e.g. rc-helicopters). 4K50p at 10bit is not supported with my GH5.

Probably an external recorder that captures 4K50p at 10bit is a solution. But for budget and portability reasons I would like to avoid that if possible.

On a side note: If it sounds like I am an amateur at color grading that is because I am This might just be a limitation of my toolchain.

Yes, I did select VLog as source gamma and rec709 as target gamma. Also the right colorchecker type.

Do you think the issue will always be there in these cases, or are there things I can do to at least mitigate? Regarding exposure maybe? I just wonder why indoors the problem is not really noticeable to me.

banding is a "side effect" of 8bit - log will make it more pronounced. hence why your 10bit footage is better.

But are you monitoring on a 8 bit monitor? or a 10bit monitor and utilizing a true 10 bit monitoring chain (decklink for monitor output). If its a computer monitor, then most likely 8bit which will show banding even if not present in the footage. Its just a limitation of the monitor.

@Cary: Files uploaded on http://www.microheli.net/att/colormatching.zip1_* is the log footage right out of the GH5.2_* with color matching applied3_* same with reduced highlights so that they won't clip, as I noticed they are heavily clipped in 2_*

@Jeff: I had the feeling this is a challenge, after spending some time with the issue. I am on a LG 34UM88-P, I believe it supports 10bit color?

I did not have the color checker back then, all grading was done manually and that is why some colors are off in a few scenes (hence me buying the color checker). But now, when using the color checker, it seems that banding gets a lot more emphasized - am I doing something wrong here?

If you are monitoring on a computer screen, there is another possible source of banding: any adjustment of the colors for the screen with the help of a probe and software will introduce that calibration on the graphics card. If the path from that card to the screen is 8 bit only, you can get 'fake' banding (only on display).

The better solution is monitoring on a calibrated video monitor via an I/O device from BM. That's the way Resolve is intended to be used.

Hi Ole, thanks, yes I know this video. In fact it is one of the reasons why I bought the color checker

8:18 shows a manual way to adjust single colors and intensities as far as I can see. But you give away most of the time saving aspect, which I thought was one of the USPs of the color checker auto match approach...

In my video snippets it appears that in order to achieve color checker blue = davinci resolve blue (which I understand is the point of the whole approach) an adjustment is needed that will break 8bit footage and introduce color banding.

I wonder why this is happening. Because if I did, I might understand how to avoid it...

1. If blue is clipped in the log footage straight out of the camera, why does the parade still have that much headroom? Something I did wrong when shooting? It never exceeds 896 in parade, where the V-Log reference curve would support up to 1024.

2. Correct exposure: Most of the time it is a compromise, because outdoors I am shooting grass (-2EV) & sky (+2EV), depending on conditions. I usually expose at 0EV when 50% of both is visible. Is that the right approach?

3. I did another video, fully white balanced from color checker. Manually graded I can not spot any color banding. But as soon as I auto-match with Resolve, banding gets introduced. This is the video manually graded:

I will try to provide zoomed-in pictures of both variants to make a little clearer what I mean.

Christian Ruck wrote:1. If blue is clipped in the log footage straight out of the camera, why does the parade still have that much headroom? Something I did wrong when shooting? It never exceeds 896 in parade, where the V-Log reference curve would support up to 1024.

V-Log does support this level but the GH5 supports V-Log-L which is a limited range of V-Log. Check you camera levels by making a shot with the lens cap on (don't use auto ISO) and one shot into a light source (but avoid the sun you do not want to damage your sensor) to get full sensor saturation. Then you can see the V-log range your camera is using. Make sure you leave headroom in the highlights because the camera will be able to record higher spikes if the sensor is not fully saturated (and this is good for HDR renditions).

Christian Ruck wrote:2. Correct exposure: Most of the time it is a compromise, because outdoors I am shooting grass (-2EV) & sky (+2EV), depending on conditions. I usually expose at 0EV when 50% of both is visible. Is that the right approach?

It depends a bit on what you are going to do with the footage, I know a lot of people think that "expose to the right" is their preferred way to expose in log but personally I think that unless you have not enough light and you are forced to do that you should generally not do that and avoid highlight clipping and/or harsh highlight roll-off. This is especially true if you want (in a future time) to color grade an HDR version of your footage.

Christian Ruck wrote:Cary,3. I did another video, fully white balanced from color checker. Manually graded I can not spot any color banding. But as soon as I auto-match with Resolve, banding gets introduced. This is the video manually graded:

Christian Ruck wrote:@Cary: I did what you described, and learned, that my GH5 V-Log L profile covers 120min - 768max.

what do you have the Luminescence level set to in the body? To get the most range out of the footage you want it to be 0-1023 for 10 bit, and 0-255 for 8 bit. I think the default is 64-940 for 10 bit and 16-235 for 8 bit.

Christian Ruck wrote:@Dan: Bookmarked! I am using the whitebalance board from the Color Checker Video Passport, also in the above video, that should do it as well, no?

imo, the passport isn't as accurate, because it's a small target, and can be skewed if you get glare. The expodisc works like a filter so you can't get glare, and is a lot quicker to use.

Christian Ruck wrote:Now that you are pointing out V-Log vs Panasonic V-Log L, I am selecting "V-Log" as source gamma in the color matching window. "V-Log L" is not in the list. Can that also be problematic?

No the Panasonic gamma transfer is fine. However I would not use the gamut but keep it Rec709. In ACES this is a problem because the gamut transfer cannot be deselected.

If you use the gamut the colors will be a bit more saturated, but some people may even like this look.

Jean, any specific reason why you would want to select Rec 2100 over Rec709 as the input gamut?

Hi Cary,

Sorry for my late response.

The reason is that I used mediainfo to read the source clip and noticed that it was Color Range = FULL (vs limited)

One of the best solutions (the fastest for this test) was to use the RCM using a digital representation that knows how to integrate the FULL range color. The RCM then 'transformed' mathematically into REC709, gamma 2.4 (the format of the timeline) but without clipping.

If we look at REC.2100 Wiki, it says:For full range color, 10-bit levels are 0 for the black level, 512 for the gray level and 1023 for the nominal peak, and 12-bit levels are 0, 2048 and 4092 (values 4093-4095 are avoided to exclude clipping errors on 10-bit ADC / DAC circuits which have 1023 steps)

There is surely other solution but I did not seek.I wanted to keep the greatest dynamics without clipping.

Jean, any specific reason why you would want to select Rec 2100 over Rec709 as the input gamut?

Hi Cary,

Sorry for my late response.

The reason is that I used mediainfo to read the source clip and noticed that it was Color Range = FULL (vs limited)

One of the best solutions (the fastest for this test) was to use the RCM using a digital representation that knows how to integrate the FULL range color. The RCM then 'transformed' mathematically into REC709, gamma 2.4 (the format of the timeline) but without clipping.

If we look at REC.2100 Wiki, it says:For full range color, 10-bit levels are 0 for the black level, 512 for the gray level and 1023 for the nominal peak, and 12-bit levels are 0, 2048 and 4092 (values 4093-4095 are avoided to exclude clipping errors on 10-bit ADC / DAC circuits which have 1023 steps)

There is surely other solution but I did not seek.I wanted to keep the greatest dynamics without clipping.

You answer confuses me, I fail to see the relevance with full versus limited range.

Regardless whether you select Rec709 or Rec2100 gamut, neither option will clip anything in Resolve. However there will be a difference in color saturation due to the fact that the Rec2100 color volume is larger than Rec709.

I would make sure not to take the last few frames as the shadow is overlapping the third patch on the bottom (go frame by frame at the end and you will see what I mean). Also there is grass over the patches which, because the image is already so small makes an accurate reading harder.

I don't have out of camera frames from the blue sky video so if you include that I can see what the effect of these settings are wrt banding.

that's the real benefit of open source software projects -- you do not have to guess around somewhere in opaque fog, but dig dipper and isolate the real technical cause of nasty issues resp. share your insights and findings...

Christian Ruck wrote:@Martin: Thanks for the hint - would love to try but Resolve requires me to at least select one GPU

sorry -- i didn't think about this...

but in fact i'm not sure, if your issue is really related to this much more complicated OCIO GPU troubles? even if you think, you are doing something comparable in your manual correction, but it looks much worse, this doesn't have to be the case in reality. it's very hard to really reproduce, what resolves color checker really does. the actual modifications could be much more radical than your human reproduction...

but 8bit VLog is always quite unsatisfying. on the gh5 you really should make use of the 25/30fps 10bit recording capabilities for VLog or choose CineD otherwise. 10bit VLog is the much better alternative, if you really want get the best color reproduction, because CineD isn't exciting in this respect, but if you have to use 8bit at all costs, CineD is usually the better alternative, because of all this well know quantification artifacts of 8bit VLog. they are not only related to the quite small amount of used values in the luma plane by VLog, but also by the much wider VGamut color space, which also concentrated actually used values to a quite small range resp. lots of quantization artifacts and bad suitability for grading.

It's all down to recording settings, scene nature and how much you push it during grading. You may do 100 projects and have no real problem and then 101 may show up very bad banding. 8bit is just simply not enough.

To re-iterate: I am not seeing color banding when grading the same scene manually.

Does that not rule out 8bit & V-Log L, as a root cause?

>> It's all down to recording settings, scene nature and how much you push it during gradingIn that regard: Is auto-color matching just pushing it harder than manual matching?

I did purchase the X-Rite color matcher to save time, but it seems for 8bit & V-Log L, I am back at manual grading...

In result, it just seems to me as if when using auto-color matching, certain adjustments are happening that are breaking the limits of 8bit & V-Log L. And I wonder if that needs to be, or if this is a bug.

Christian Ruck wrote:I did purchase the X-Rite color matcher to save time, but it seems for 8bit & V-Log L, I am back at manual grading...

i think, most of us have seen this of kind of very unsatisfying banding artifacts in cases of manual processing of 8bit V-Log just as well. unfortunately it's a well known issue.

but if you really want to proof your judgment, just compare it with similar solutions in other software. resolves color checker tool isn't such a uncommon invention. there are some very similar implementations around, which do the same job in a little bit more transparent way:

2.) another one could be seen in the Colorcheck tool of imatest (the free demo version is enough for testing), which can calculate color correction matrices that can be used in resolve via some 3x3 matrix workarounds (you just have to utilize the same color reference system in both applications!).

3.) there is also a very interesting -- but unfortunately harder to use -- similar solution available in the matrix optimization feature of DCamProf. this one is really interesting, because it even allows to set different weight adjustments to groups of color patches, which is a very useful feature in practice.

sure -- this manual calculation of color correction matrices may look a little bit crazy and much to complicated, but it's perhaps a quite useful way, to understand better, whats going on beyond the surface of resolves black magic. it also helps to grasp, what kind of corrections can be solved in a sufficient way by these techniques, and what kind of color distortion can't be sufficient handled by them, because you would need much more complex approaches. in fact, they only work well, if you footage is still transformed to the right color space by adequate import filters, and only some minor refinements concerning ambient light or white balance are necessary. in other cases (eg. complex translations between different color spaces or real camera profiling) the limited amount of color patches on a CC24 target would also hinder acceptable results.

i hope, this strange excursion will convince you by practical experience, or otherwise help you to objectify your judgment.

Christian Ruck wrote:To re-iterate: I am not seeing color banding when grading the same scene manually.

Does that not rule out 8bit & V-Log L, as a root cause?

>> It's all down to recording settings, scene nature and how much you push it during gradingIn that regard: Is auto-color matching just pushing it harder than manual matching?

I did purchase the X-Rite color matcher to save time, but it seems for 8bit & V-Log L, I am back at manual grading...

In result, it just seems to me as if when using auto-color matching, certain adjustments are happening that are breaking the limits of 8bit & V-Log L. And I wonder if that needs to be, or if this is a bug.

Are you talking about those examples in earlier post?Your manual process may push different parts of original data then "automated" grading, so one may reveal more banding than other. This is normal.I see banding in both examples, but end look is very different so for the eye one may look better than other (in terms of banding). Again- this is normal, but still doesn't change fact that cause of banding is your 8bit Log recording.