| Series |
|---|
Part 2: Exploring Three Workarounds (and finding another Mouse UI Problem)
In theory, the only difference between color correcting in DaVinci Resolve on a control surface vs. using a mouse is your movements. With a mouse, you make only one adjustment at a time. With a control surface, you make multiple adjustments simultaneously. But the actual math behind using the two different input devices should be the same, in theory. As we all recently discovered, the theory doesn’t match reality. Watch my previous Insight on the ‘Mouse Math Bug’ if you haven’t already. It’ll give you the full details of the surprising difference between grading with a mouse vs. with a control surface.
Is this ‘Mouse Math Bug’ really a difference in math and is it truly a bug?
I’ve come to the conclusion that no, it’s not a difference in math. Based on my experimentation and some new information gleaned from a short email response to me from Blackmagic… this behavior is not intentional. In fact, it looks like Blackmagic found another bug’ish behavior when using a mouse in the Primary Bars interface. Since this behavior is not intentional and since it actually makes color grading with a mouse harder than color grading with a control surface and since this new Primary Bars behavior is definitely not helpful… I’m comfortable calling this a bug. Even if some of my more accomplished peers disagree with this assessment (which is fine, diversity of opinion is what makes our lives worth living).
In this Insight, you’ll see a new bug in action
It has to do with a mouse shortcut that allows us to make YRGB moves when using the Primary Bar interface (which typically only allows for a single color channel adjustment at a time). This new bug was suggested to me in a very short email from Blackmagic. They asked me to confirm what they were seeing on their end. This is good news since it means the Resolve team is digging into this.
While coming up with workflow suggestions for dealing with these bugs, I discovered another little quirk in the Primary Bars that is 100% repeatable. But it is only evident is very specific situations using a mouse.
You’ll also learn three solid strategies for dealing with this Mouse Math Bug.
In the video below I share three techniques for mouse-based colorists to work-around this bug:
- In the comments for Part 1 of these Insights, lots of members shared their long-time workflow for dealing with this problem. Break up your initial color balancing adjustments into two nodes. It’s a good way of solving this problem but at the cost of extra nodes and complexity to your Node Graphs.
- Another common suggestion was to follow up on your color balancing adjustments in the color wheels with a Y-only move in the Primary Bars. You’ll see that solution in action, plus my thoughts on why it’s not always appropriate.
- Finally, I found a 100% solid workaround. It involves using Curves to solve color balance issues. Follow up the curves adjustment with a Master Wheel adjustment in the same node—and you get the same behavior as on a control surface.
As always, leave your comments, thoughts, and suggestions below!
Enjoy!
-pi
