Why Your LUT Looks Different in Another App

The preview looked right, the export looked wrong. This is the most common LUT complaint, and in almost every case the file is fine. Work through this list in order — it goes from most likely to least.

1. Gamma: sRGB is not Gamma 2.4

This is the big one. sRGB has a piecewise transfer function, not a pure power curve. Rec.709's display encoding is a pure 2.4 power curve. They are close in the midtones and visibly different in the shadows and highlights.

This tool exports two spaces:

• sRGB → sRGB for photographs.
• Rec.709 primaries, Gamma 2.4 as a creative look for already-normalised SDR video.

Loading a Gamma 2.4 table as if it were sRGB lifts the shadows and washes the blacks. Loading an sRGB table as Gamma 2.4 crushes them. Check which one you exported, and set your editor's LUT input colour space to match exactly.

2. Log footage that was never normalised

A creative LUT expects Rec.709 display-referred values. If your footage is still in S-Log, V-Log, C-Log or a similar curve, apply the camera profile first.

Symptoms: everything looks dark and flat, and turning the exposure up gives you noise and no highlight detail. That is a conversion problem, not a LUT problem.

You can check the transfer characteristics on the command line:

ffprobe -i input.mp4 -show_streams -select_streams v:0 \
  -show_entries stream=color_transfer,color_primaries,color_space

bt709 for transfer means Rec.709 gamma. smpte2084 means PQ/HDR, which this tool does not handle at all.

3. Wrong input space in the node

Most editors default a LUT input to something. If you do not set it, you are relying on a default rather than on the file. Set it explicitly, every time:

• Video creative look: Gamma 2.4 input.
• Photo LUT: sRGB input.

And leave the output space alone. The CUBE header does not configure your project's colour management for you — a table cannot do that.

4. Exposure that differs between the two views

If the preview was of a still and the editor is showing a video, the editor may be applying its own exposure compensation, a highlight rolloff, or a scope-based auto-level. Check that no auto-correct or auto-level is enabled on the node.

5. White balance set twice

If the timeline was already white-balanced and the reference look assumes it was not, the LUT adds a second cast. Decide where the balance lives: either the camera profile corrects it, or the LUT does. Doing both is the same as doing neither.

6. Interpolation

A 33-point table is sampled trilinearly in every modern editor, which is fine. Two edge cases are worth knowing:

• A 65-point table is measurably better on very smooth gradients, because it is re-sampled from the underlying function rather than interpolated up from 33.
• Some older tools, and some "smart" image viewers, apply nearest-neighbour sampling. A 33-point table shows visible terracing in a flat gradient under nearest-neighbour; a smooth gradient is a quick way to spot this.

7. Limited versus full range

Some applications tag video as limited (TV) range and some as full (PC) range. A LUT applied across that mismatch shifts the whole image by roughly 16–235 versus 0–255. If your blacks are at 16 rather than 0 before grading, that is the cause.

A quick isolation test

If you are still stuck:

1. Export the same grade at 0% strength. That is an exact identity table. If the image changes, the problem is not your LUT — it is range, colour management or a node setting.
2. Apply a known-good third-party LUT at 100%. If that also looks wrong, the problem is in your project setup, not in any file.
3. Check the exported file's TITLE and colour-space comment lines. They record what the engine actually built.

If step 1 changes your image, no amount of LUT swapping will fix it.