Filmlight LUT formats in detail

(LUT_1D and LUT_3D sizes above reflect what this specific export produced — Baselight lets you change resolution before export for most of these, within each format’s supported range.)

---

2. Family groupings — formats that are essentially the same thing wearing a different label

A. The “.cube” family (Resolve-style ASCII cube, floats 0–1, LUT_3D_SIZE keyword)

AMIRA, BMD, BlackMagic, IRIDAS, Truelight cube’s 3D portion are all the same underlying syntax — plain-text, LUT_3D_SIZE N, then N³ rows of R G B floats from 0–1. Differences in comment header text.

Any app that reads “Resolve cube” will read all of these interchangeably.

B. The Autodesk “.3dl” mesh family (ASCII integers, input-code-value header line)

Autodesk, Arri, DVS, Scratch, Autodesk Lustre, LUTher classic .3dl structure: a header line listing the input code values (e.g. 0 64 128 192...1023), then rows of output R G B integers. Differences: – Bit depth of the output values varies: Autodesk/Arri/DVS use 10–12-bit scale (0–1023/4095), Scratch uses full 16-bit (0–65535), LUTher uses 10-bit but with a plain entry-count header instead of a code-value line. – Arri explicitly lists 10-bit (0–1023) input code values rather than Autodesk’s 12-bit (0–4095) range. – Lustre adds extra non-standard tokens (3DMESH, Mesh, trailing LUT8 gamma block) on top of the same mesh body — a generic .3dl parser that doesn’t expect these tokens may choke on a Lustre file even though the numeric mesh itself is standard. This is the most fragmented family: same idea (integer mesh + code-value header), different bit depths and optional wrapper tokens.

C. The Quantel/DVS/Evertz “plain row” 1D & similar small-header families

DVS 1D, Colorfront 1D, Quantel (17³), Evertz all reduce to: minimal/no header, then rows of values. These are the most “fragile” formats — barely any metadata, so the receiving software must already know the grid size and scale convention.

D. XML process-list formats (chainable, ACES-adjacent)

CLF and Autodesk CTF are structurally the same idea: an XML <ProcessList> containing one or more typed nodes (<Range>, <Matrix>, <LUT1D>, <LUT3D>), each with explicit inBitDepth/outBitDepth and an <Array dim="..."> of values. Difference: CLF is the official, vendor-neutral AMPAS/ACES standard (xmlns="urn:AMPAS:CLF:v3.0") with mandatory InputDescriptor/OutputDescriptor color-space tags — built for interchange. CTF is Autodesk’s earlier, proprietary precursor format with similar structure but no formal interoperability guarantee outside Autodesk/FilmLight tools. CLF is the one you should prefer for archival/interchange; CTF is mainly for Flame/Lustre pipelines.

E. Camera/monitor manufacturer “branded” formats

Canon gamma 1D / Canon gamut 3D, Panasonic, Sony, Sony BVME, Arri, AMIRA are not really new mathematical formats — they’re cube/mesh/1D data wrapped in a header the manufacturer’s own software (or monitor firmware) expects to see, often with a specific grid size or coordinate convention (Sony’s “MESHCOORDINATES UPPER” is a non-trivial difference — it changes how the mesh is indexed, not just the wrapper). Treat these as “give the camera/monitor what its own ingest tool wants,” not as a distinct color science.

F. Proprietary/binary outliers

Barco (packed binary “LUT-CLUT”) and ICC (binary ICC color profile with embedded CLUT) are not human-readable text at all and aren’t really “LUT files” in the editable sense — they’re compiled binary containers meant only for their target device (Barco projector, ICC-aware color-managed app/OS).

G. Vendor-system “mesh in proprietary key-value” formats

Pandora, Nucoda, Quantel 65x65x65, CineSpace each invent their own small header syntax around an otherwise ordinary R/G/B float or integer grid. CineSpace stands out because it also supports independent pre-LUT 1D shaper curves per channel ahead of the 3D cube — a feature most of the others lack.

---

3. Compatibility — grading software & cameras

---