Panel vs Mouse – Color Correction Math in DaVinci Resolve, Part 1

Amazing insight. It helps to explain problems I would run into, but figured I was just messing up – especially, when going between my panel and mouse to mix repetitive hand movements up. I would look at my scopes and think, “…. what is going on here!” Now, I know.

I don’t think it’s an order of operations difference as such. The same numbers in the UI will always give the same result (I believe) no matter whether you get to them using the mouse or a panel. What varies is the way moving a control, either on a panel in the UI, changes the numbers.

Great insight Patrick! Keep us update if you find out more…

The first tab in the new resolve (the GUI color wheels) is a relatively new introduction in resolve, the legacy is the second tab where the bars are. The panel is linked to those controls.

if you use the YRGB bars you will get a 100% match between the GUI mouse action and the panel (BM surface or tangent).

get the test from Patrick, go in the bar tab, make the red match the use the Y: it just works as for the panel.

The Idea that the panel is mapped to the color wheels, is a misconception.

Should they work the same? Yes IMHO. but I will not call this a BUG.

“if you use the YRGB bars you will get a 100% match between the GUI mouse action and the panel…” I don’t see that. If I get a blue-ish colour matte, balance it to dark-ish grey, then use the UI horizontal YRGB gain dial to raise the gain I get a different result to using a panel to raise the gain (even though the same YRGB numbers are changing). This is true in either tab. (I don’t mean using the Y, the panel doesn’t control that on its own.)

i’ve got this working the same as you have. Balance with the red colourbar and then gain with the Y colour bar only on 100 lum mix. But surely the point is that once you balance with the red colourbar and then use the overall YRGB gain wheel underneath the colourbars this should just gain everything up without changing the colours?

Walter – one point… you say, “The Idea that the panel is mapped to the color wheels, is a misconception.”

Here’s what the manual says on page 721 of the June 2016 Edition: “The Master Wheels correspond to the rings surrounding the trackballs on the DaVinci control surface, which let you modify image contrast via YRGB adjustment (as opposed to modifying image contrast via Y-only adjustment, covered later in this chapter).”

In case you think this language is new to the Resolve manual, here’s what it says on page 327 of the Resolve 9 manual (January 2013 edition): “The master wheels correspond to the rings surrounding the trackballs on the DaVinci control surface, which let you modify image contrast via YRGB adjustment (as opposed to modifying image contrast via Y-only adjustment, covered later in this chapter).”

You may be correct about the ‘why’ of the behavior described in this Insight… but if it’s a ‘misconception’ then it’s one being actively spread by the software developers themselves… since very introduction of those features.

Nick – you are correct. That’s not what’s being discussed. Rather I’m pointing out that Jamie Dickinson was correct: using waveforms and not numerical values, the same ‘move’ between the two input devices generate very different numerical values resulting in the colorist having to grade differently depending if they’re on a mouse or a control surface.

Yes, I understand. My intent was to clarify. When people refer to “order of operations” they normally mean colour processing order of operation, i.e. gain followed by gamma does not have the same effect as gamma followed by gain. What is varying here is the maths used to translate movement of a control to changes in YRGB values.

I wasn’t sure if some people might be thinking that the same numbers were giving different results depending on whether they were dialled in with a panel or the GUI. The title referring to “color correction math” could possibly make people think this is what you mean.

Nick – Gotcha. Understood. Thanks for sharing your thoughts!

That damned math will get you every time. There’s been no comment on this from BMD, by the way.

that would be something!

Wow thats great news Robbie!
i started working on advanced panel a month ago and was surprised how little info and how much digging i had to do to find info about it.
Looking forward to your insights on it, like small hacks and tricks, whatever you wanna share.. 🙂

Patrick, what do you make of the fact that the Lumetri color wheels work more like the Resolve UI in that they don’t maintain balance, where as Speedgrade does? I did a test (see tweet I sent with link) and was a little surprised by the results.

Neither here nor there. From my perspective, the problem with Resolve is that the control surface gives different results when doing the exact same moves on the mouse. They should mirror each other perfectly. As to the difference in SpeedGrade vs Premiere – since they’re two different apps, not a problem.

If SpeedGrade were still being developed then I’d encourage Adobe to unify their behaviors so that users don’t get confused. I’ll have to take a closer look at this behavior in both Premiere and FCPX and offer workflow suggestions that minimize mousing when working in apps that fail to maintain color balance when adjusting gain in the same instance of the filter.