The .cube LUT format, line by line

A minimal 3D .cube

This is a complete, valid 2-point identity LUT — it changes nothing, which makes it a useful test file:

# An identity LUT
TITLE "Identity 2x2x2"
LUT_3D_SIZE 2
DOMAIN_MIN 0.0 0.0 0.0
DOMAIN_MAX 1.0 1.0 1.0
0.0 0.0 0.0
1.0 0.0 0.0
0.0 1.0 0.0
1.0 1.0 0.0
0.0 0.0 1.0
1.0 0.0 1.0
0.0 1.0 1.0
1.0 1.0 1.0

Read the data lines in order and the pattern is visible: red flips every line, green every two lines, blue every four. That is the red-fastest ordering, and it is the single most common thing tools get wrong when they write a .cube by hand.

The header keywords

Keyword	Meaning	Notes
TITLE "…"	A human-readable name	Optional. LUTLINE shows the file name in the library, not the title, so a stale title from another tool does no harm.
LUT_3D_SIZE N	Grid points per axis of a 3D table	N³ data lines follow. 17, 25, 33 and 65 are typical; LUTLINE accepts 2–65.
LUT_1D_SIZE N	Entries of a 1D table	N data lines follow, one per channel value. LUTLINE expands a 1D table into a 33-point cube so the pipeline has one shape.
DOMAIN_MIN r g b	Input value that maps to the first grid point	Defaults to 0 0 0.
DOMAIN_MAX r g b	Input value that maps to the last grid point	Defaults to 1 1 1. Values outside the domain are clipped.
LUT_3D_INPUT_RANGE lo hi	IRIDAS-style alternative to DOMAIN_MIN/MAX	Also accepted for 1D tables as LUT_1D_INPUT_RANGE.
#	Comment line	Ignored, as are blank lines.

How big is a table?

The data section grows with the cube of the size. A 33-point table is 35,937 lines; a 65-point table is 274,625 lines, typically 6–8 MB of text. That is why creative looks are usually 25 or 33 and only conversion tables from camera makers tend to be 65: a Log curve packs many stops into the low code values, and a denser grid keeps the shadows from banding.

Size	Data lines	Approx. file size
17	4,913	~120 KB
25	15,625	~400 KB
33	35,937	~900 KB
65	274,625	~7 MB

How a renderer applies it

For every pixel the renderer scales the input RGB into grid coordinates using the domain, finds the surrounding grid points, and interpolates their stored outputs — trilinear (eight neighbours) or tetrahedral (four) interpolation. Apple's Core Image, which LUTLINE uses, wants the table as a packed float array in exactly the red-fastest order the format specifies, which is why a file with the axes swapped produces a bizarre but "valid" result: every colour is sent to the wrong place, cleanly.

Errors that make a .cube fail to load

• Wrong line count. Fewer or more data lines than N³. Usually a truncated download or an editor that added lines.
• NaN or Inf values. Produced by some exporters when a curve divides by zero.
• Wrong channel count. Lines with two or four numbers instead of three.
• Out-of-range domain. A DOMAIN_MAX below DOMAIN_MIN, or non-finite values.
• Excessive size. A size that would need more memory than the device has. LUTLINE stops at 65.
• Wrong encoding. A UTF-16 export from a spreadsheet, or a file that is not text at all.

LUTLINE checks all of these before a table reaches the renderer and reports which one failed. A file that loads is a file that will render.

Technical vs. creative .cube files

The format does not say what input a table expects; only the author knows. A conversion table from a camera manufacturer expects that camera's Log profile; a creative look expects Rec.709. LUTLINE keeps them in different places for that reason: conversion tables are imported in the Source sheet and run first, creative tables in the Custom LUTs folder of the Looks tab and run after the adjustments. Both are the same file format.

Frequently asked