Free tool · nothing is uploaded
3DL ↔ CUBE
Autodesk’s LUT format and Adobe’s, in either direction. Drop a file and the tool works out which way you are going.
Drop a .cube or .3dl LUT
The direction is chosen from the file you drop. Converted on your device; nothing is uploaded.
The same data, written two different ways
Both formats describe a cube of sampled colours. They differ in three details, and every one of them is a chance to produce a file that looks valid and is wrong.
| .cube | .3dl | |
|---|---|---|
| Entry order | red fastest | blue fastest |
| Values | decimals, 0–1 | integers, unstated scale |
| Grid size | stated (LUT_3D_SIZE) | implied by the shaper ramp |
The first row is the dangerous one. Swap it and every colour still maps to a valid colour, the file opens, the histogram looks plausible — and the image has its red and blue axes exchanged. There is no error to catch, which is why it is worth stating that this converter transposes and is tested against a reference file written by hand for that purpose.
Frequently asked questions
What is a .3dl file?
Autodesk's 3D LUT format, originally from Lustre and still used across Flame and Smoke. It holds the same kind of data as a .cube — a three-dimensional table mapping input colours to output colours — but writes the values as integers rather than decimals, and orders them differently.
Why would a converted LUT come out with red and blue swapped?
Because the two formats disagree about which channel varies fastest through the list of entries. A .cube advances red first; a .3dl advances blue first. A converter that copies the triplets across in order produces a file that parses without complaint, has the right number of entries and renders with the red and blue axes exchanged. Both directions here transpose, and the conversion is tested against a hand-written reference file rather than only round-tripped — a round trip alone would pass even if both directions were wrong in the same way.
How does the tool know a .3dl's bit depth?
It infers it, because the format does not record it. The values are integers on some scale — 10-bit tops out at 1023, 12-bit at 4095 — and the only available evidence is the largest number in the file. That is what OpenColorIO does too. It is reliable in practice and fails in one specific way: a LUT whose output never approaches full scale can be read one step low, which looks washed out. The depth actually used is displayed so you can catch it.
Which bit depth should I export?
12-bit unless you have a reason. Every current reader handles it and it quantises finely enough that gradients stay clean. Choose 10-bit for older Lustre pipelines that expect it, and 16-bit only when you know the target reads it — some older Flame builds do not.
Is anything lost in the conversion?
The grid itself is untouched — the same number of entries with the same values, reordered. The only loss is quantisation when writing .3dl, since decimals become integers: at 12-bit that is a rounding error of about 0.012%, well below anything visible. Going from .3dl to .cube is exact, because integers convert to decimals without loss.
Is my LUT uploaded?
No. The file is read with the browser's File API and converted on your own device. Nothing is transmitted.