Home Software Grading Controls Should Be More Like Guitars…

Grading Controls Should Be More Like Guitars…

by alexis
New FCP X Color Balance Controls

UPDATE July 2nd 2018

I’ve been told by those who would know that the anomaly discussed by part of this article has been addressed in a recent version of FCP X. It’s taken me a while to get back to this, but in my latest batch of tests, it would appear that, in Rec.709 mode, FCPX 10.4.3 has solved the issue and the color wheel controls act as I’d expect. In Wide Gamut mode with Rec.2020 color space, these controls still work a bit differently to how I’d expect, but it’s consistent and not tragic (at least from what limited testing I’ve done).

I stand my my desire for customizability, however.

Admittedly, that’s two similes in a row in titles on this blog, but since my writing output here has been so meagre, I suppose rhetorical crutches are to be expected.

As busy as I’ve been, there’s been enough of a kerfuffle surrounding Final Cut Pro X version 10.4’s new color correction controls, specifically the new color-balance controls, that it’s penetrated my curtain of tasks and made me curious. The process of examining FCP X further gave me food for thought concerning the differences between color-balance controls in different grading applications, the lack of true cross-platform standardization in this area, and the need for more user-accessible customization in this area.

But First, New Color Controls in Final Cut Pro X

Before I say anything else, let me just go on the record that I’m very happy to see the Final Cut Pro team putting effort into more professionalized integrated grading tools. As much as I love me my dedicated grading applications for their superior grade management capabilities and greater depth of tools, editors need integrated color controls in every NLE for a wide variety of reasons and situations, and I really hated the way the old color board worked.

New FCP X Color Balance Controls

New FCP X Color Balance Controls

And not only did they add color-balance control driven grading, but they added a set of color curves for RGB, and ALSO a set of HSL curves! It was like Christmas on, well, almost Christmas! Not only that, there’s even some new thinking with an innovative hue-limited Saturation vs. Luminance control (called COLOR vs. SAT), which defaults to Orange (ORANGE vs. SAT) but that can be set to any hue of the color wheel, with a nifty auto-naming color picker control. SEA FOAM vs. SAT anyone? I can see this being quick and useful for anyone doing product shots, or for fine-tuning skin tone intensity.

FCP X Customizable HUE vs. SAT control

The new FCP X Customizable HUE vs. SAT control

So, new tools, hooray. However, I’ve been swimming in a river of unexpected work as 2017 turned into 2018, I didn’t have any time to look more closely at them. Over time, I caught a bit of unhappiness at the edges of social media, where some responses seemed to be, “yeah, the new color controls are nice and all, but the color wheels and contrast controls are a little wonky.”

So that’s what prompted me to finally have a look for myself. I loaded up a few shots, including a pre-rendered ramp gradient I use for testing color pipelines, and did some grading with the new color wheel controls.

In an effort to be fair-minded, I’ll start with what I like about the new Final Cut Pro color-balance controls:

  • They exist.
  • The controls corresponding to each tonal range include saturation, which is really useful.
  • The visual design of the controls is sensible, with crosshairs, space-efficient vertical sliders, and muted hues.
  • While I’m not a fan of having to add a color tool to a clip prior to adjusting it, I do like the ability to have multiple instances of tools, making management of color adjustments a layered experience, which is useful.
  • I like that all adjustments made by dragging within the color controls work like a virtual trackball, and make adjustments are relative to the previous color adjustment, for smooth operation.
  • I kind of like the option of switching between a single mode-switchable color control and a simultaneous group of four, however to be honest I’m not sure how useful that really is. I think if the single control could also simultaneously show all four tonal control handles, and if it got bigger and smaller as the Inspector’s width changed, it would be more interesting.
  • I like that you can Option-drag controls to make slower, fine-tuning adjustments.
  • I like that you can select a control handle and use the Arrow keys to adjust it, although I’m not sure how much I would actually do this in practice since you’re incrementing in coarser units when you do so.

Moving on to things I don’t like:

  • I don’t like that there’s only one reset button governing the color, contrast, and saturation controls for each tonal zone, so you can’t seem to reset contrast without also resetting color, etc.
  • I don’t like that you have to click right on the center control of the color-balance controls to actually make an adjustment. Other implementations let you click anywhere within the color wheel, so you don’t have to be so nit-picky.
  • I don’t like how the contrast and saturation vertical sliders make absolute adjustments to jump the adjusted level right to where you click with your mouse, requiring you to make a precision click right on top of the slider handle to drag up or down from the previous level.
  • I wish they hadn’t used the terms Shadows, Midtones, and Highlights to name these controls, or that the documentation explained in any amount of detail how these tonal ranges are defined. These names have come to mean something very different since Final Cut Pro 3 added similarly named controls 17 years ago (that actually did more of a Lift/Gamma/Gain operation). It’s time every application stuck to standardized terminology, so as not to be confusing.
  • Lastly, and the reason for this article, I don’t like how the color-balance and contrast controls interact with one another as you make adjustments. This is probably my biggest complaint. It’s also possibly a bug.

This last point is immediately noticeable to anyone who’s used color controls across different platforms, and while it’s not horrific, it’s not ideal, at least for me. Lift/Gamma/Gain controls typically pin the highlights in place (relative to 100 percent) as you raise or lower Lift, pin the shadows in place (relative to zero) as you raise or lower Gain, and pin both the shadows and highlights in place as you raise or lower Gamma. In this way, you can make structured adjustments and not have to worry that a change you’ve made to the gamma is going to cause radical changes to the shadows and highlights levels you’ve just set. Now, in practice, there’s usually a small bit of interactivity, but it shouldn’t be that noticeable.

Furthermore, any small interactivity is usually compensated for though the act of using a color correction control surface of some kind that lets you simultaneously adjust Lift and Gain, or Gamma and Lift, or whatever combination you require. Simultaneous adjustment makes it easy to compensate for this sort of thing as you turn the rings, dials, or knobs used to adjust contrast, to the point where you may not even really know it’s happening. On the other hand, weekend warrior colorists driving with the mouse will notice this kind of interactivity a lot, since they’ll be making adjustments one at a time, such that a change to Highlights making a change to Shadows will necessitate an adjustment to Shadows which in turn alters Highlights so you need to readjust Highlights and then, well, you get the idea. It’s somewhat less than ideal.

In FCP X, at least on my system, grading in Rec. 709 exhibited an enormous amount of interactivity among the Shadows/Midtones/Highlights contrast controls. I casually mentioned this on Twitter, and colleague Marc Bach helpfully pointed out Simon Ubsdell’s YouTube video which helpfully seeks to explain why this is happening, and which (spoiler alert) points out that these behaviors change when you set the project to Rec. 2020. My only complaint about Simon’s video is that it doesn’t specifically show the steps he used to set up the Library, Project, and Media to reproduce his results. However, since you need to set the Library that contains the content you’re grading to Wide Gamut HDR in order to set a new project to Rec. 2020, I assumed that was the proper combination of settings. I was a bit confused by the “Rec. 2020 PQ” banner at the top of the video scopes in Simon’s video where we see the Gamma control finally working properly, since a standard dynamic range gradient shouldn’t show a linear response if the color space OETF/EOTF is set to PQ, but maybe he was using a ramp that’s linear in PQ space. On the other hand, I don’t know FCP X that well, and maybe I was doing something wrong. So I set about to explore this issue more thoroughly to see if I could reproduce his results.

Long story short, using my own gradient .mov file, I found reproducing Simon’s results difficult to do. I first set the Library to Wide Gamut HDR and then the Project to Rec. 2020, and still found myself getting a wonky contrast response. I then set the Library back to Standard but left the Project set to Rec. 2020, which I didn’t think would be possible since you can’t set a Project to 2020 unless you’ve first set the Library it’s in to Wide Gamut, but it’s possible (seems like a bug). I tried every combination of color management settings FCP X allows, and while the contrast response differed, it was still wonky and not at all “standard” to the way I’d expect these controls to work.

Then, I finally stumbled upon the magic combination of settings. Turns out I needed to:

  1. Create a new Project.
  2. Import a ramp gradient .mov file into the same Library, and edit it into the timeline.
  3. Set the Library to Wide Gamut.
  4. Set the Project to Rec. 2020.
  5. (Here’s the step that makes a difference) Select the ramp gradient clip in the timeline, and use the New Compound Clip command to turn it into a compound clip.
  6. Exit the compound clip back to the overall timeline, select the compound clip you just created, and add a Color Wheels layer.
  7. NOW, select the Library, and set the color processing setting to Standard.
  8. Once you’ve done this, using the Color Wheels contrast controls to adjust the clip in the still-Rec. 2020 identified Project timeline results in exactly the kind of adjustments I would expect from Lift/Gamma/Gain operations in other applications.


Given all the screwing around with the Color Management settings required to force a clip to grade correctly with these controls,  clearly the math that governs these controls is being handled incorrectly relative the Color Management settings, so I believe Simon’s assessment is generally correct. And frankly, I’m happy to stop there, because from my experience working with the development teams of Final Cut Pro classic, Apple Color, and DaVinci Resolve, I have no doubt there’s way more going on under the hood of FCP X that affects these operations than any simple tests can really clarify. Color management is not simple to implement, and the interactions of color management and color grading operations are especially not simple, so I’m sympathetic.

Happily, all this has been addressed.

And Really, It Doesn’t Matter

And at the end of the day, the why of all this really doesn’t matter to me as an artist. To offer a metaphor, if I build a guitar and give it to a musician, and they play it and tell me they don’t like it, the process of explaining to the musician why the guitar sounds the way it does doesn’t help. The bottom line is, the musician expects a certain result when manipulating the instrument in a familiar way, and if that result is not forthcoming, there’s not enough math in the world to change that musician’s mind.

Which brings up a point I’m actually more interested in discussing. As I mentioned on Twitter when chatting about some of this, most grading software I’ve used varies slightly in how the tonal ranges affected by Lift, Gamma, and Gain are defined. The falloff of Gamma towards Lift and Gain might be a bit wider or a bit narrower, steeper or shallower, and the curves governing the falloff of Lift and Gain against one another may also vary by small amounts. Not enough to make these controls work night-and-day differently, but enough to feel just a bit different.

Additionally, color management affects all of this. For example, working in different timeline color spaces in DaVinci Resolve makes the controls feel different, more or less sensitive in different ways within different zones. And these small differences matter to color grading artists, who play their control surface like an instrument from which they expect to get a particular result when they make a particular set of adjustments to the trackballs or contrast rings/dials/knobs.

I find that colorists tend to prefer the controls of the last grading application they used professionally, which makes sense since you’ve built up muscle memory to know what motions correspond to which corrections, and who wants to learn new instincts all over again? Even small changes take a while to get used to.

Furthermore, each application’s variances are rooted in no doubt the soundest of reasons, and I have no interest in litigating who has the best controls. They’re all great. But they’re all different.

Standards, Anyone?

From a workflow perspective, however, it’s a bit vexing that something as fundamental as Lift/Gamma/Gain hasn’t really been formally standardized across grading platforms. The closest we’ve got is the standardization of the ASC CDL Slope/Offset/Power/Saturation adjustments, which isn’t quite the same thing, but which is serving as the cross-platform glue in pre-production through post-production look management workflows for many projects and organizations. However, in many instances, the SOPS operations need to be translated to/from an application’s own Lift/Gamma/Gain operations. It’s not really a big deal, but I always have the supernatural fear of extra steps introducing the potential for extra problems. I know, too much of a life spent in post has made me paranoid.

Now, I admit it’s improbable that a standardization of Lift/Gamma/Gain will ever happen. Grading applications would have to give up their time-honored and thoroughly-justified wrinkles on Lift/Gamma/Gain functionality in favor of math from someone else “who’s been doing it wrong all these years.” Even worse, giving up your in-house Lift/Gamma/Gain functions risks alienating a user base that has spent years building muscle memory for different corrections. Nobody wants to get used to another application’s operational differences if they can help it.

On the other hand, Lift/Gamma/Gain standardization could offer an opportunity, were it to be implemented in such a way as to be globally customizable. Application-wide presets would allow each company to tailor the “custom tuning” of Lift/Gamma/Gain to their in-house standard, while also offering access to the “standard tuning” of the industry standard. Furthermore, this would facilitate project exchange as each companies variation could be described and implemented within the new standard.

Think of it, NLE’s could finally exchange meaningful color grading information with grading applications without having to resort to CDL tools, or custom plugin solutions, or black box math that can’t be adjusted. Project grading could be moved from one grading application to another in emergencies. Colorists who find themselves forced to use another grading application for a single job could switch to the controls they’re used to in order to be maximally effective. And new colorists could choose to get used to an industry-wide standard that every application would be able to implement.

Of course, this is a utopian vision that isn’t completely realizable, because control response isn’t just based on the math of the color operations those controls perform. An application’s color management, render pipeline, image processing order of operations, UI widget implementation, and control surface implementation all affect how an adjustment “feels” while you make it. But standardizing at least one set of parameters would get us closer to a portable world of people moving image data among different apps as necessary.

Playing Slack-Key Guitar

However, the guitar analogy points the way towards another useful metaphor; that of the slack-key guitar player.

Modern guitars have a standard tuning, so that any guitarist can pick up a guitar that’s in tune and immediately play a song with a reasonable chance of success. However, there are numerous traditions of guitarists who modify the tuning of their guitar to play a particular type of music.

With this in mind, I think about how nice it would be if the potentially standard tuning of Lift/Gamma/Gain controls across platforms provided a guaranteed means of customizing this response in subtle and useful ways to be able to work differently enough to make grading different kinds of projects easier. Imagine having one set of controls that you like to use when grading night shoots, and another set of controls you like to use when grading bright desert shoots. Maybe they’re not night and day different (I’m sorry), but I could see having slightly different tonal ranges for each making these scenes a bit faster to grade.

Now, there are already applications that allow you to customize the tonal range affected by a given Lift/Gamma/Gain control, and that even let you adjust the slope of these ranges, but there still many grading applications and plugins that don’t. Ideally, a Lift/Gamma/Gain standard would also encompass a standardized means of customization that would be available as an application-wide (or project) setting, such that every application and plugin that implements Lift/Gamma/Gain would be easily able to implement it, thus providing the benefits described above to everyone in postproduction, on every platform.

Wouldn’t that be nice…

















You may also like


Cedric Lejeune January 29, 2018 - 7:59 am

Well, as a guitar player myself, I find the analogy very interesting. As you mentioned, the tools behave differently within the same tool, whether you work in a colourdumb workflow or a colour managed one. We could think ACES could help in that, as ASC-CDL tried, but we ended up with a lot of ACES spaces for different uses (at least you can easily translate from one to another). At the end of the day, pretty much like the player that will have a different guitar to play reggae and metal, you try to reduce the set of behaviors to something manageable, but for that you need to have a proper understanding of what’s lying underneath, tools processing, colour management, and we do know it’s not easy 🙂 Keep on rockin”

alexis February 2, 2018 - 8:42 pm

Thanks for weighing in, Cedric. A lot of folks have commented on twitter, using ACES as an example of “yet another example of attempted standardization making things more complicated,” but I think that’s a bit unfair. Not that ACES isn’t complicated and ever-changing, but I feel that ACES has so many agendas that the evolution it’s undergoing was inevitable. I feel like something as relatively limited in scope as lift/gamma/gain operations could have a chance, if the postproduction software companies of earth could come together in harmony. But of course, that’s crazy talk…

Oliver Peters June 14, 2018 - 9:56 am

You should write a follow-up. At NAB 2018, with the release of FCPX 10.4.1, Apple changed how the color wheels work. They are now largely in line with LGG expected behavior.

– Oliver


Leave a Comment

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More