DaVinci Resolve Detective, Part 3: What’s Fixed (and what’s not)?
Blackmagic released a new update to DaVinci Resolve: DaVinci Resolve 12.5.3. In Parts One and Two of this series, I shared one serious problem with DaVinci Resolve’s behavior (for at least the past 4 years). Namely, a basic color balance operation followed by a contrast adjustment works differently depending on your input device. If you grade with a mouse then you get one set of results. If you grade with a control surface then you get a very different set of results.
Color correcting with a mouse was, literally, more difficult than using a control panel
I termed the difference between the two sets of results ‘Mouse Math’ and ‘Panel Math’. The sad net result of the differences? Mouse Math makes you feel much more untalented than Panel Math. When executing a simple ‘Color Balance + Contrast Expansion’ move using the 3-Way Color Wheels, Mouse Math didn’t maintain color balance—but Panel Math did.
Mouse-based colorists took longer to get to the same place—and it’s because the software was literally making color grading harder for mouse-based colorists.
Mouse Math also explained why I’m never as crisp teaching as I am working
When teaching, I (almost) never use a control surface since it’s harder for the audience to see what I’m doing. And yet, basic operations that worked wonderfully when grading in my suite—with a control surface—always took more work on a mouse. I’d often apologize on-stage for my unexpected fumbling, without realizing that the software literally worked differently with a mouse… I always chalked the difference to the pressure of being on-stage!
I offer a huge Thank You to Mixing Light member Jamie Dickinson, who pushed me to look into this whole Mouse Math vs. Panel Math issue.
Mouse Math also forced Mixing Light to put on hold a few new training initiatives
I’ve got a few training ideas (including a free series on learning how to actually *use* scopes, rather than just reading them) that I was about to start recording. Those ideas got put on immediate hold. It made no sense since I’d have to create multiple versions of each training series—depending if you’re using a Mouse or a Control Surface.
That gets us to the big question:
Did DaVinci Resolve 12.5.3 Fix the ‘Mouse Math’ problem?
In a nutshell: Yes.
Here’s what the 12.5.3 Release Notes say on this fix:
- Addressed an issue where the Lift, Gamma and Gain control on the Resolve interface do not maintain Color Balance
Yup. As you’ll see in the video below, Blackmagic fixed that big overall problem. As result, I’m taking my foot off the brakes on my new training ideas and moving forward.
And to all you mouse-based DaVinci Resolve colorists, you should find the new 3-Way Color Wheels MUCH easier to use. Especially when doing your initial color balancing and contrast expansion. You can end the two-node workaround that so many of you reported in our Comments and on LiftGammaGain.
The smaller bugs I reported have not been fixed
To me, those smaller bugs are not very important. They’re interesting, especially since they show the inputs of the Control Surface work differently than the same inputs using a mouse. But those bugs are edge cases and we almost never see them on real-life jobs.
The big problem is fixed (even though the Maths are still different)
When you’re solving a big color balance problem, Mouse Math produces different YRGB values than does Surface Math… but who cares? Those two different sets of numbers still get you to the same place with equal efficiency. You no longer need to modify your order of operations to accommodate Mouse Math.
Thank you Blackmagic for simplifying working in DaVinci Resolve!
They’ve made it easier for their end users to move between different input devices. They’ve made it easier for educators to teach DaVinci Resolve.
In the video below you see that Resolve 12.5.3 behaves like it should. And I point out the other two bugs we found in Parts 1 and 2 of DaVinci Resolve Detective that have yet to solved.