Share a Review Grade as a LUT—or Send Editable Settings and a Reference?
Share a Review Grade as a LUT—or Send Editable Settings and a Reference?
The request arrives as one small sentence: can you send me the LUT for the approved look? One file, for a whole grade, already signed off by a director. It sounds like a file-management task. It isn't.
A lookup table can carry a defined color mapping. It cannot carry every operation that produced the frame you approved. Those are different claims, and the gap between them is where handoffs go wrong: the recipient applies the file, gets something plausible, and both sides spend a week discovering that a local repair, a track, or a compositing step never made the trip.
So the useful move isn't "export the LUT." It's inventory the grade, then choose deliberately between two materially different packages: a declared global transform with its input conditions, or editable settings plus an approved reference. The rest of this piece is about making that choice on purpose.
Separate the approved appearance from the operations behind it
Start with two artifacts, not one.
The first is the reference: the frame or short clip where the look was approved, kept at the settings under which approval happened. That's the target. The second is a written list of everything the grade does, in order. Not for the recipient yet — for you. Most failed exports are inventory failures wearing a file-format costume.
Then apply one question to every entry on the list: does the output at a pixel depend only on the color arriving into that pixel?
If yes, the operation is pointwise, a mapping from color value to color value, and a table is the right shape for it. Global curves and levels, color balance, saturation and vibrance, split toning, a film-emulation look, a channel mixer, a lift applied uniformly across the frame — all of these key off the pixel's own value.
If no, the operation reaches outside the pixel:
- Position. A feathered shape or brush mask, a gradient used as a mask, a vignette drawn by hand. The same color inside and outside the mask is treated differently because of where it sits.
- Neighbors. Blur, sharpening, grain, denoise, distortion and lens correction. The output at a pixel depends on the pixels around it.
- Other layers. Keys, mattes and compositing steps that compare a pixel against something else in the stack.
- Time. A correction animated over the shot, a tracked shape, anything whose value depends on which frame you're on.
A vignette is worth pausing on, because it reads as global to the eye and shows up in the middle of otherwise portable stacks. It darkens a corner and leaves the center alone. That is a rule about distance from the center of the frame, which is position. It will not be in the table.
Now the caution that matters most, because it's the one people get wrong in both directions. A selection is not the test. "Select the reds and pull them toward orange" is a rule about color, so it's pointwise and a table keyed on the whole color can express it. "The label, not the wall" is a rule about place. The question isn't whether a mask or a selection was used; it's what the rule reads.
One more piece of good news before the bad news. Pointwise steps compose. If every link in a chain is pointwise, the whole chain is a single function, and in principle a long stack of tonal adjustments can collapse into one table. The reason exports fail is never that the stack was long. It's the specific links that reach outside the pixel's own value.
Two patches, one input value
Here is the limit in its barest form. The numbers are invented for the explanation — they are not measurements from an image.
Two patches arrive at the grade at 0.4 in the channel being corrected. They are identical in every channel. The only thing that distinguishes them is where they sit in the frame. The approved grade requires the left patch to leave at 0.5 and the right patch to leave at 0.7.
A table's rule is a function: one input value, one output value. A function that maps 0.4 to 0.5 cannot also map 0.4 to 0.7. Since the two pixels are indistinguishable in the key the table looks up, no color-keyed table can separate them — not a per-channel table, not a table keyed on the full RGB triple, regardless of grid size or file format. The distinguishing information is location, and location isn't in the key.
That is the whole proof, and it is enough to establish a representability limit. It is also narrower than it's often quoted as being. Two things it doesn't say:
It doesn't say every selective operation is unrepresentable. If the two patches differ somewhere else in the triple — the wall is slightly warmer than the label — a table keyed on the full color can separate them. That's real, and it's how hue-targeted secondaries make it into shared looks all the time. But notice what you've bought: the rule now follows color, and the mask you drew followed place. They agree in this frame because the wall happened to be redder than the label. Put the same color on a different object, or deliver a new take where the label sits under a different light, and the color-keyed rule goes somewhere the mask never would have.
It doesn't say anything about a particular application's export behavior. The math says a single color-keyed table can't encode that local difference. Whether your software includes the masked adjustment anyway, ignores it, refuses the export, or something else entirely is an empirical question about that application and version — answered by running the export and looking, not by reasoning from the arithmetic.
And even the representable part is approximate. A table is sampled and interpolated between its sample points, and the pipeline may round between steps. "Reproduces" has to mean "matches within a tolerance you have actually checked," not "is identical."
Two handoffs, and what each is for
Transform-only. You send the table plus three written statements: what mapping it's meant to represent, what input it expects, and what was deliberately left out. That third one is not optional. A recipient who isn't told the local repair exists will eventually find it, usually in front of a client.
Editable handoff. You send the native project or settings, the dependencies it legitimately needs — source media, fonts, licensed effects, tables already inside it — the application and version, and the approved reference. Native files are not automatically portable either. Missing sources, an effect renamed or removed in another version, a plugin the receiving facility doesn't own: any of these can change the result, which is exactly why the reference travels with the settings.
The reference's job is worth stating plainly, because it's routinely confused with the other two. A reference shows the target. It does not encode the route. Settings without a reference can't be verified. A reference without settings is a puzzle. And neither one is a table.
Most real handoffs are a hybrid, and should be: the transform, the reference, and a residual list naming the operations that stayed behind. That's not a compromise position. It's the accurate description of a grade that is partly portable and partly not.
Before you choose, ask what the recipient is doing with it. A camera department wanting a preview approximation on a monitor needs a checked global transform and a note. A finishing house continuing the grade needs the settings and the reference, because the remaining work is the whole point.
Declare the conditions before anything moves
A table is not a look. It's a mapping defined for a particular input, meant to sit in a particular place. Four things belong in the covering note:
Input interpretation. What encoding does the table expect the receiving pipeline to feed it? A table built for one input encoding, fed another, produces a wrong result that still looks like a color choice — which is the worst kind of wrong, because it survives review by eye.
Color spaces. The space the table was built for and the space it should land in. Vague, but not optional.
Placement. Where in the receiving chain does the mapping belong — before or after a camera transform, before or after any tone-mapping step? Placement is a pipeline decision with its own consequences, and it's invisible in the file.
Format. Ask the recipient which formats their pipeline accepts rather than assuming one universal type. Tables differ in dimensionality, grid size and expected encoding, and they are not interchangeable. A per-channel table can't make the reds behave differently from the blues; a table keyed on the whole triple can. Neither can make two identical triples behave differently, which is the section above.
On the mechanics of producing one: Adobe's Photoshop help page on exporting color lookup tables describes the export in terms of an eligible document-and-adjustment arrangement, together with the color-space and format conditions that apply. That is a description of how a table gets produced from a setup the application accepts. What it doesn't say — and no export dialog can make true — is that a spatial correction, a track or a key travels inside the resulting file. Check your actual document against the documented eligibility and format conditions rather than assuming your working stack qualifies as it stands.
One habit that saves arguments later: keep any transform-only test on its own copies. Never overwrite the approved native original, and never test the table on a copy of the already graded frame.
Reapply on the actual source, not the graded copy
The verification step that people skip, or perform in the wrong order.
Build a fresh application of the table on the original ungraded source, with the declared input interpretation, at the declared position in the chain. Not on the graded render. Applying a table to its own output composes the mapping with itself and answers a different question — whether the look survives being applied twice. That result will look plausible enough to be mistaken for a reproduction test, which is why it keeps happening.
Then set three images side by side:
- The approved reference.
- Global-only: original source plus the table.
- Full native: original source through the whole project.
Each comparison tells you something different, and both handoffs get tested at once.
If global-only matches the reference across every area you know to be locally corrected, within the tolerance you checked, the global transform is sufficient for this handoff. That's a practical verdict about this deliverable, not a finding about which operations the grade contains — a small local correction can hide inside the tolerance band and never show up in the comparison. Say the transform is sufficient, and send it.
If global-only matches outside the locally corrected area and differs inside it, you've isolated the residual. That's the local correction doing what the limit says it must do. Document it; don't try to tune the table against it by eye, because the table cannot represent it, and any apparent improvement will be a coincidence elsewhere in the image.
If global-only differs broadly, work in this order before touching a control: input interpretation, transform order and placement, missing pointwise steps, then precision and interpolation. Tuning a table that's being fed the wrong input builds a second problem on top of the first, and the two are hard to separate afterward.
If full native differs from the reference, you have the other handoff's failure mode — a drifted project, missing media, an effect that changed under a version update. Different disease, different remedy. It's worth knowing which one you have before you start treating it.
Where to look while comparing: the difficult highlights, the saturated extremes, the boundary of the locally corrected area, and the feather around it. Not the average appearance, which is exactly where three different pipelines agree with each other.
Then write down where reproduction stops. A successful export establishes that a file was generated, and nothing more.
One side experiment is worth running once, because its answer is genuinely useful and genuinely unknown until you run it: export with the local mask included and record what the application does — bakes it, drops it, rejects the document, or something else. Whatever you find is a fact about that version of that application. It isn't a fact about the mathematics, and it shouldn't be generalized into advice. No such export was run for this article, and no table was built, applied or compared; the walk-through above is a plan with invented values, not a result.
The package you actually send
By the end, you should be able to say which of two sentences is true of your handoff.
The recipient can reproduce this. Here is the table, here is the input it expects, here is where it goes, here is what it does not contain — name each thing. They can reproduce the global mapping, and they will know precisely which parts of the frame depend on your project, your mask, your track or your time.
The recipient needs the settings. Here is the project, here are the dependencies and the version, here is the approved reference, and here is what will change if any of those pieces are missing on their end. Native files are not automatically portable either; the difference is that this package contains the work, so the portability problem is solvable.
Whichever you send, the reference goes with it. The reference is how anyone on the other side checks their result against the thing that was approved — and how you find out, early and cheaply, that the one LUT you were asked for was a request for a file, while what was wanted was a reproduction.
Frequently asked questions
Can one LUT reproduce an approved grade?
Only when every operation in the grade depends solely on the colour arriving into each pixel. A LUT can carry a defined colour mapping, but it cannot carry operations that depend on position, neighbouring pixels, other layers, or time. The practical move is to inventory the grade and ask of each operation whether its output at a pixel depends only on that pixel's colour value.
What is the basic limit that a colour-keyed LUT cannot overcome?
Two patches can arrive at the same colour value but sit in different places, and the approved grade may require them to leave at different values. A LUT's rule is a function: one input value gives one output value, so it cannot map the same input to two different outputs. Location is not in the key. If the patches differ elsewhere in the RGB triple, a table keyed on the full colour may separate them, but then the rule follows colour, not the mask you drew.
What belongs in a transform-only handoff versus an editable handoff?
A transform-only handoff is the table plus written statements of what mapping it represents, what input it expects, and what was deliberately left out. An editable handoff is the native project or settings, its legitimate dependencies, the application and version, and the approved reference. The reference shows the target; it does not encode the route. Settings without a reference cannot be verified, and a reference without settings is a puzzle. Most real handoffs are a hybrid with a residual list naming what stayed behind.
What conditions should be declared before a LUT is shared?
Declare the input interpretation or encoding the table expects, the colour spaces it was built for and should land in, where in the receiving chain it belongs, and the formats the recipient's pipeline accepts. Tables differ in dimensionality, grid size, and expected encoding, and they are not interchangeable. Placement is invisible in the file but can change the result, so it should be stated rather than assumed.
How should a LUT be verified after export?
Reapply the table to the original ungraded source with the declared input interpretation and at the declared position in the chain, not to the already graded render. Compare the approved reference, a global-only version made from the source plus the table, and a full native version made from the source through the whole project. If global-only differs only inside a locally corrected area, the residual is isolated; do not tune the table by eye against it. If it differs broadly, check input interpretation, transform order and placement, missing pointwise steps, then precision and interpolation. A successful export only establishes that a file was generated.