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?


Series

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:

Enjoy!

-pi

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!


Comments

32 thoughts on “Panel vs Mouse – Color Correction Math in DaVinci Resolve, Part 1”

    1. If, using the mouse, I did the color balance on Node 1 and the Gain contrast adjustment in Node 2 – it would act just like the control surface does and brighten the image without allowing the color balance imbalance to creep back in. This suggests there’s an order-of-operations difference between using the mouse vs. using a surface.

      But I don’t presume to know how the software is programmed and it could be something completely different.

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

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

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

  1. I’d love for one of you guys to give a complete rundown of the official DaVinci Resolve Control Surface from Blackmagic. My company just upgraded to it from the Tangent Element, and it’s quite intimidating! And surprisingly, there isn’t much information about it online or in the manual! 🙂

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

    1. Yes, great job, Patrick – you took my investigations to a whole new level – Thank you!
      It seems to me that the order in which the maths is applied is the key… UI gain dial, then UI differential gain ‘ball’, then panel gain? Or is that (UI ‘ball’, then UI gain dial), then panel? Not sure. I used the Pablo (Rio) & Neo panel before and I think that worked like the Resolve UI, which is why I started separating my contrast and colour adjustments.

  2. Well that was … intriguing. Starting with Resolve, I was of course total mouse/trackball based. And it was just so frustrating to get things to … well, go where I wanted them to and stay there. Felt really stuupid. Then with the Ripple & Elements panels, suddenly, I was SO much smarter/coordinated/whatever, if still a bit intimidated by the depth of the program’s options But …. naw … I wasn’t stuupid, just the program. Ha!

  3. I noticed this immediately as I recieved my Tangent Ripple!! It was so wierd… But I just got used to it. Thanks for this Video Patrick maybe Blackmagic will see this and fix it.

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

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

    1. “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.)

    2. 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?

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

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

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

  7. In the new 12.5.3 release notes:

    “Addressed an issue where the Lift, Gamma and Gain control on the Resolve interface do not maintain Color Balance”

    Sounds like they fixed it?

    I am deep into another project now so I don’t want to update yet so I cannot test if it is true.

Leave a Reply

Hundreds of Free Tutorials

Get full access to our entire library of 900+ color tutorials for an entire week!


Start Your Free Trial
Loading...