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

September 12, 2016

Does the color correction math in DaVinci Resolve change depending if you're using a mouse versus using a colorist control surface?


Does a colorist control surface use different math compared to a mouse?

The most intimidating presentations I give involve color correcting in front of a live audience

I often find that my carefully prepped material doesn’t quite ‘grade up’ the way I expected, when doing it live. It seems I’m making more ‘moves’ and feel a little sloppier than when I’m grading in the comfort of my suite. I’ve always chalked it up to a combination of nerves and being in a terrible color correction environment. Except I recently discovered… maybe it’s not me. Maybe DaVinci Resolve is changing its color correction math when I’m up on stage???

What? How can the color correction math change when grading in front of a live audience?

It makes no sense, right? But a recent Tweet by Jamie Dickinson to my Twitter account directed me to a forum thread he started:

Click on his link and you’ll end up at LiftGammaGain where Jamie poses a simple problem:

  • If he balances a highlight using the mouse and then lifts the Gain with the user interface Wheel – the color balance gets thrown off
  • If he balances the same highlight using a control surface and then lifts the Gain using the control surfaces’ Wheel – the color balance is maintained.

My first reaction: There’s a problem with his system

But as I read his post and his subsequent follow-up questions to people who responded to him, he’s quite lucid. He’s able to replicate this problem on-demand. So I decided to follow the steps he outlined.

You know what?… the color correction math between a control surface and a mouse IS different!

I was able to perfectly reproduce his results. In fact, I took his test a bit further and determined that the math in the Lift and Gain Primary Wheels is very different depending on your input device—mouse vs control surface. (I found the Gamma math to be the same between the two different input devices)

Unfortunately for mouse users, most of the time you’re doing more work than control surface users

As you’ll see in the video below, on typical color correction tasks the behavior of the control surface is more desirable. Control surface moves for the Lift and Gain operations completely eliminate the back-and-forth movements that mouse colorists are forced to endure.

I’m saddened to say, DaVinci Resolve does make mouse-based colorists feel more un-talented than their control surface peers. It probably also feeds into the color grading newbie’s feeling that color correcting takes too much work; since they’re almost certainly starting with a mouse.

This also explains why I feel un-Talented color correcting in front of a live audience

The color correction moves I’m used to making are all done with a control surface. But when I take footage that I’ve graded professionally in my grading suite and re-create them for a live audience… I usually choose to use a mouse (since it’s easier for the audience to follow a mouse and see my moves).

Moving to the mouse changes the color correction math—and those simple color correction moves on a control surface take a lot more work to duplicate using a mouse. Suddenly I start struggling. And, until now, I never understood why. Thank you Jamie for helping me discover I don’t suck at color correction… it’s just the software making me feel that way!

But the ‘control surface math’ isn’t always better than the ‘mouse math’

As I pushed my testing of this ‘bug’, I discovered the differences between color correcting on a mouse vs. a control surface go deeper than just using the contrast wheels. The Color Wheel / Trackball inputs also give us different results for the Lift and Gain tonal controls.

And with extreme color balance problems, the mouse behavior is actually better. On extreme corrections, the mouse is MUCH more gentle on our images and the control surface behavior is terrible!

If you want to see what I’m talking about – watch to the end of the video

I’ll also share my thoughts on how you can use this knowledge in your day-to-day work. And if you think this is something that needs to be fixed (which I do—unless there’s some rock-solid logic behind all this), you can post on Blackmagic’s forum or directly contact them using the Email form at the bottom of their Support page.

Seriously, while we always welcome comments here on Mixing Light – when it comes to bug fix requests and feature requests, the Resolve team doesn’t care what I say or think. They care about what hundreds of us say and think. If you want Blackmagic to unify the mouse and control surface behaviors follow the links I just provided and… say something.

Download my DaVinci Resolve test project

This project file should be opened in DaVinci Resolve 12.5.2 or later. You can recreate and deconstruct what I’m doing in the video:



P.S – I do apologize for the noise in my on-camera setup for this Insight. I’ve started testing new lights and I seriously under-exposed myself 🙁  I really need to start using a light meter!


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

Page 2 of 3

  • Scott Stacy

    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.

  • Nick Shaw

    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…

  • walter

    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.

  • Jamied

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

  • Patrick Inhofer

    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.

  • Patrick Inhofer

    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.

  • Nick Shaw

    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.

  • Patrick Inhofer

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

  • Marc Wielage

    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.. 🙂

  • Jamied

    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.

  • Patrick Inhofer

    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.

Page 2 of 3

Log in to reply.

1,000+ Tutorials to Explore

Get full access to our entire library of over 1,100+ color tutorials for an entire week!

Start Your Test Drive!