You seem to misunderstand the role of LUTs in color grading. LUTs (Look-Up Tables — a simple multi-dimensional array data structure) describe how one color is transformed into another, and they are used for efficient color transformations. In Resolve, the tools you described help build a LUT in memory, which is then applied to each pixel in each frame, often using SIMD instructions for efficiency. This avoids the need to procedurally apply each setting to each pixel individually, which is way slow.

Drawing windows, mattes, tracking, and other masking tools determine where and how the LUT is applied within the rendering pipeline.

> Source? That's a very gross oversimplification of what a color session is like. LUTs don't do tracking. LUTs don't do keys. LUTs don't do mattes.

I work in AAA games and have written code for tonemapping and color grading. We often use a gbuffer (graphics buffer that could be seen as a 2D screen-shaped image that is never shown) to mask different objects in the scene and apply different LUTs accordingly. So, it is not only LUTs that are applied in a similar screen-space way, but also masking is similar.

> There's so much more going into color grading than "apply LUT here". Just look at the control surfaces for Resolve and the number of knobs/buttons/rollers. Would something that just applied LUTs need all of that?

On a low level, it essentially is about applying LUTs. How you create these LUTs and how you mask their application are crucial aspects of the process. But ultimately, a LUT is applied to pixels. You are talking about the artistry techniques involved in making a LUT and masking where it is applied, which is not debated.

LUTs are not just files you can import and export to grade the whole image or frame. They are a fundamental compact data structure that makes SIMD operations easy, which is why they are used in grading. If you set up a color grading pipeline with nodes in Resolve, it is very likely compiled into one or more LUTs, which are then applied to the frames.