Manifold Phosphor

You don't need a LUT, you need a pipeline

What 'colour managed' actually means, why a LUT is a symptom not a solution, and how to set up OCIO without wanting to die.

You downloaded a LUT pack. You dragged the .cube file onto your adjustment layer. The footage looked cinematic. You shipped it.

Then you got a project that was shot on a different camera, and the LUT looked terrible. So you found another LUT. And another. And now you have a folder with 400 LUTs and a growing suspicion that there’s a better way.

There is. It’s called colour management, and it’s simpler than the OCIO documentation makes it sound.

What a LUT actually is

A LUT is a sampled snapshot of a colour transform at a specific grid resolution. It takes input RGB values and maps them to output RGB values. It knows nothing about what camera the footage came from, what display you’re viewing on, or what colour space you’re working in. It’s a lookup table. It looks things up.

When someone hands you a LUT called “ARRI_LogC_to_Rec709.cube”, that LUT encodes a specific conversion from a specific log encoding to a specific display standard. Change any variable (different camera, different display, different working space) and the LUT gives you the wrong answer. It’s not broken. It’s just answering a different question than the one you’re asking.

0%25%50%75%100%scene-linear exposure (stops)code valueshadow crush

This is why your folder of 400 LUTs exists. Each one is a frozen answer to a specific question. A colour managed pipeline asks the question dynamically instead.

What a pipeline is

A colour managed pipeline separates the transform into steps:

  1. Input transform. What colour space and encoding is this footage actually in? ARRI Log-C4 with Wide Gamut 4 primaries? Sony S-Log3 with S-Gamut3.Cine? The input transform converts from the camera’s encoding to a common working space.

  2. Working space. Where you do your grading. This is a defined, documented colour space that doesn’t change between projects. In ACES, it’s ACEScg (linear, AP1 primaries). In a custom OCIO config, it could be whatever makes sense for your facility.

  3. Display transform. What are the characteristics of the monitor you’re looking at right now? Rec. 709 SDR? P3 D65? PQ for HDR? The display transform converts from your working space to whatever the display needs.

Each step is a defined, swappable, documented transform. Change the camera? Update the input. Change the monitor? Update the display. The working space stays the same. Your grade stays the same. That’s the whole idea.

Pipeline (adapts)
LUT-based (frozen)
⇔
LUT-based (frozen)
Pipeline (adapts)

Same grade, different camera. The LUT breaks. The pipeline adapts.

Why LUTs still exist

LUTs aren’t evil. They’re useful in specific situations:

  • On-set monitoring. A LUT on a SmallHD gives the DP an approximate look. Fast, predictable, and the monitor doesn’t need OCIO installed.
  • Client review. Baking a LUT into dailies gives the producer a consistent look without requiring colour management on their laptop.
  • Final delivery. Some delivery specs require baked LUTs in the output.

The problem is using LUTs as your colour management strategy rather than as a delivery format. A LUT on your monitoring chain is fine. A LUT as the only thing standing between your camera negative and your grading software is not.

Getting started without losing your mind

The OCIO documentation assumes you already understand colour science. You don’t have to. Here’s the minimum viable setup:

Step 1: Pick a config

Don’t build your own. Use one that already exists:

  • ACES 1.3. The industry standard. Well-documented, wide support, good default for most work. Download the OCIO config from the Academy’s GitHub.
  • SPI-Anim / SPI-VFX. Sony Pictures Imageworks configs. Battle-tested in VFX. Simpler than ACES if you don’t need the full pipeline.
  • Studio config. Many post houses have a house config. Ask before building your own.

Step 2: Tell your software where it is

Every colour-managed application needs to know where your OCIO config lives. Set the OCIO environment variable:

export OCIO=/path/to/your/config.ocio

Or point to it in your application’s preferences. DaVinci Resolve, Nuke, and Blender all have OCIO config fields in their colour management settings.

Step 3: Set your input

When you import footage, tell the software what encoding it’s in. If it’s ARRI footage, the input should be ARRI LogC3 or LogC4 (depending on the camera). If it’s Sony, S-Log3. If it’s a VFX render, it’s probably linear with whatever primaries the render engine used.

This is the step that LUT workflows skip entirely. The LUT assumes it knows the input. The pipeline asks you to be explicit about it.

Step 4: Set your display

Tell the software what monitor you’re looking at. If it’s a standard HD monitor, that’s Rec. 709. If it’s a P3 display, that’s DCI-P3 or Display P3. If it’s HDR, that’s PQ or HLG depending on the spec.

That’s it

Those four things (config, environment variable, input, display) give you a colour managed pipeline. Your grades are now portable between cameras, between monitors, between facilities. You can change any variable without the image falling apart.

The folder of 400 LUTs

You don’t have to delete it. But you probably won’t open it much anymore. When the pipeline handles the colour management, the LUTs become what they always should have been: creative looks and delivery conversions, not structural dependencies.

The day you stop thinking about which LUT to use and start thinking about which input transform matches your footage is the day colour management starts working for you instead of against you.