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

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

Viewing 33 reply threads
    • Does the behavior stay the same when you split color and contrast into 2 nodes?


    • Aaron H
      Member

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


    • Marc Wielage
      Participant

      Terrific investigation, Patrick. And I congratulate Jamie Dickinson for the discovery.


    • Marc Wielage
      Participant

      Blackmagic really should publish a more thorough guide to the daVinci Control Surface, particularly all the panel-specific shortcuts.


    • RobbieCarman
      Guest

      Dan and I have been talking about this! We’re outline a 3-4 part series now. Stay tuned.


    • Patrick Inhofer
      Guest

      🙂


    • Patrick Inhofer
      Guest

      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.


    • YuriiHydrick
      Guest

      That would be amazing, Robbie! 🙂


    • Jamied
      Guest

      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.


    • R.NeilHaugen
      Guest

      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!


    • Jose Santos
      Guest

      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.


    • Patrick Inhofer
      Guest

      You’re welcome. Just remember, if you want them to fix it you need to let them know using one of. A single blog post isn’t enough 🙂


    • Patrick Inhofer
      Guest

      Interesting, right?


    • Jose Santos
      Guest

      Did it the second I sinished watching the video 👍👍


    • Jamied
      Guest

      My approach is to balance in node 2 and adjust gain in node 1, kind of like getting the correct input for a LUT. But either way seems to work in this case.


    • Scott Stacy
      Participant

      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.


    • NickShaw
      Member

      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.


    • Martino C
      Member

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


    • walter
      Guest

      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
      Guest

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

      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
      Guest

      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.


    • NickShaw
      Member

      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
      Guest

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


    • Marc Wielage
      Participant

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


    • Nurali K
      Member

      that would be something!


    • Nurali K
      Member

      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
      Guest

      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
      Guest

      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.


    • account
      Guest

      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.


    • Patrick Inhofer
      Guest

      Correct. Mouse Math and Panel Math now seem to agree with each other. I’m still testing and will be releasing an update to this Insight later today.


    • Jean Paul Sneider
      Guest

      Necrothreading, but thought could be interesting for whoevere is following this insight now. Seems like the Mouse issues have been solved, on the other hand the inverting when using panel is still there. so easier with mouse and sometimes more useful for hard clips.


    • Pat Inhofer
      Guest

      Necrothreading. Heh. Like it. Yeah, in a later Insight I found a few more differences between the mouse and the panel that have never been addressed, 4 years later. Although I probably should revisit these. Maybe when Resolve Next is released? Being that we’re only a few weeks from the normal April release cycle for Public Betas and their team is listening and ready for bug fixes.

Viewing 33 reply threads
  • You must be logged in to reply to this topic.

Hundreds of Free Tutorials

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


Start Your Free Trial
Loading...