Cutsio Blog

ARRI Look File 4 (ALF4) Workflow: From Set to DaVinci Resolve Without Baking the LUT

Learn how ARRI Look File 4 (ALF4) travels from camera through cloud dailies to DaVinci Resolve grade — non-destructive look metadata that survives the pipeline without baking into review proxies.

How does ARRI Look File 4 (ALF4) travel from set to DaVinci Resolve without baking the LUT?

ARRI Look File 4 (ALF4) is a non-destructive look metadata format used with the ARRIRAW or ARRICORE MXF workflow. It carries the look created by the DP on set — including CDL values and 3D LUT-based color decisions — as metadata rather than baked pixel data. In the dailies pipeline, the ALF4 look can be read from the MXF package and applied to the review stream as a viewing transform. When the original file reaches DaVinci Resolve for grading, the colorist can use the ALF4 information and a verified dailies reference as the starting point without touching the original LogC4 camera data.

The ALF4 format replaced the older ALF2 format for ALEXA 35-class REVEAL workflows. ARRI documents ALF4 for ALEXA 35, ALEXA 35 Xtreme, and ALEXA 265, with support for the REVEAL color pipeline and look creation through ARRI tools.

The core advantage of ALF4 over a baked LUT: the original LogC4 image is never modified. The ALF4 look is applied as metadata during the rendering or viewing pipeline, and it can be removed or adjusted at any point.

Working with raw camera footage? Check out How to Build a Searchable Library From ARRIRAW, RED R3D, and ProRes Footage.

Streamline your workflow with How to speed up video editing workflow 10x.

How is an ALF4 look created and saved on set?

The ALF4 look is typically created by the DP or DIT using ARRI Look Creator or the ARRI Reference Tool. It can also be created directly in the camera menu on Alexa 35 and Alexa 35 Xtreme.

The creation workflow:

  1. The DP shoots a reference frame or selects an existing frame from the day's footage
  2. Using ARRI Look Creator or the in-camera look menu, the DP adjusts CDL values (slope, offset, power, saturation)
  3. If desired, a 3D LUT is selected or imported for creative color transformation
  4. ARRI Textures are selected for grain and structure characteristics
  5. The complete look is saved as an ALF4 file with a descriptive name (e.g., "Day_Scene_24_Warm.alf4")
  6. The ALF4 is loaded into the camera or embedded into the ARRIRAW/ARRICORE MXF header during offload

The ALF4 file is typically 10-50 KB in size — it contains only metadata, not pixel data. Multiple ALF4 files can be created for different scenes or lighting conditions and swapped in the camera or during the offload process.

When the DIT offloads cards using Codex Device Manager or Silverstack, the ALF4 look metadata is automatically embedded into the MXF file header if the look was active during recording. If the look was created later, the DIT can embed it during the offload or verification step.

How does the ALF4 look survive the dailies pipeline to the review stream?

The ALF4 metadata travels inside the MXF file container. Every MXF-wrapped ARRIRAW or ARRICORE clip contains a header section where the ALF4 look data is stored alongside timecode, lens data, and camera metadata.

When the MXF file is uploaded to Cutsio through the enterprise raw ingestion add-on, the cloud transcode reads the ALF4 metadata from the header. The look is applied as a viewing transform to the review stream — the same LogC4-to-Rec.709 conversion that ARRI's own software applies, with the ALF4 creative adjustments on top.

The review stream the director and DP see matches the intended look. The CDL values, 3D LUT reference, and Texture selections are all reflected in the streamable review asset. The original MXF file remains completely unmodified — the ALF4 metadata is read, not written.

Pipeline stage by stage:

| Stage | ALF4 Status | What the User Sees |

| :--- | :--- | :--- |

| Camera recording | ALF4 embedded in MXF header (if active) | Look visible in camera monitor |

| DIT offload | ALF4 verified in MXF header | Look confirmed in playback |

| Cutsio upload | ALF4 read from MXF header | Review stream with look applied |

| Director/DP review | Look displayed in review stream | Approved look in browser player |

| Colorist download | Original MXF with ALF4 intact | Raw LogC4 + ALF4 reference in Resolve |

| Final grade | ALF4 used as reference or discarded | Graded output independent of ALF4 |

How does DaVinci Resolve handle the ALF4 look during grading?

DaVinci Resolve's handling of ALF4 metadata depends on the Resolve version, ARRI SDK integration, project color management, and the way the look was created. Do not assume that every ALF4 look will appear automatically as editable Resolve nodes. Verify the imported image against a known-good render from the DIT cart, ARRI Reference Tool, or approved dailies.

The colorist has three options:

  1. Use the ALF4 look as the starting reference for the grade. If Resolve exposes the look metadata or CDL values, the colorist can build from there.
  2. Recreate or modify the look in Resolve. The CDL values, LUT reference, or reference still can be translated into Resolve-native grading decisions. The original ALF4 metadata in the MXF header is not modified by normal grading.
  3. Discard the ALF4 reference entirely and start the grade from the flat LogC4 image.

The key technical point: the original camera file should remain read-only in the grading workflow. Resolve project adjustments live in the project database, while the MXF camera original remains the source of truth.

For ALF4 looks that include 3D LUTs or custom color management, verify that the required LUTs and look package are accessible to Resolve. If a dependency is missing, the imported image may not match the approved dailies reference.

How does the ALF4 workflow differ from using a baked LUT in proxies?

The traditional dailies workflow bakes a viewing LUT into ProRes proxy files. This creates the "it looked better in dailies" problem because the baked LUT is permanent and cannot be removed. The ALF4 workflow avoids this entirely.

| Property | ALF4 (Non-Destructive) | Baked LUT in ProRes Proxy |

| :--- | :--- | :--- |

| Original LogC4 data | Preserved in MXF file | Lost in proxy (replaced by LUT-applied pixels) |

| Colorist starting point | Flat LogC4 + ALF4 reference | Must reverse-engineer the baked look |

| Look adjustability | Fully adjustable or removable | Permanent (cannot be removed) |

| Dailies review accuracy | Matches intended look | Matches intended look |

| Conform complexity | Low (same file for review and grade) | High (proxy look must be matched) |

| Archive suitability | Excellent (metadata + original data) | Poor (look is permanent) |

The practical difference for the colorist: with ALF4, the colorist starts from the flat sensor data with the creative look available as reference. With baked proxies, the colorist must try to match the dailies look by eye, often leading to the director saying "it looked better in the dailies."

Can ALF4 looks be applied to ARRICORE footage the same way as ARRIRAW?

Yes, ALF4 is part of both ARRIRAW and ARRICORE MXF workflows on ALEXA 35-class systems. Still verify the exact behavior in the dailies tool and grading application, because decode support and look interpretation are software-version dependent.

The ALF4 look file itself is format-agnostic. An ALF4 created for an ARRIRAW production can be applied to ARRICORE footage from the same camera system, and vice versa.

FAQ

Can I create an ALF4 look file after the shoot is complete?

Yes. ALF4 looks can be created retrospectively using the ARRI Reference Tool or ARRI Look Creator. Load a reference frame from the day's footage, create the look, and embed the ALF4 into the MXF headers of the selected clips using Silverstack, Codex Device Manager, or the ARRI Reference Tool.

Does Cutsio support ALF4 look display in the review stream?

Cutsio can use ALF4 metadata in the enterprise raw ingestion workflow when the look package is present and supported by the decode path. The original MXF file remains unmodified; verify the review stream against the DIT-approved reference.

What happens if the ALF4 file is missing or corrupted?

If the ALF4 metadata cannot be read from the MXF header, the Cutsio review stream applies the standard LogC4-to-Rec.709 viewing transform without the creative look. The original MXF file is unaffected and can be re-uploaded once the ALF4 issue is resolved.

Does the ALF4 look transfer through XML/EDL workflows?

The ALF4 look metadata is embedded in the MXF file, not in the XML or EDL. When a timeline XML is imported into DaVinci Resolve, Resolve reads the ALF4 metadata directly from the MXF file that the XML references. The look does not travel through the XML itself.

How does ALF4 handle ARRI Textures?

ALF4 includes Texture selection as part of the look metadata. The Texture selection is applied during the viewing or rendering pipeline and is visible in the Cutsio review stream. In DaVinci Resolve, the Texture information is available as metadata but requires the ARRI SDK integration to apply the Texture rendering. Not all third-party color grading tools support ARRI Texture rendering in the grade.

ALF4 looks. Non-destructive. From set to grade.

Upload native ARRIRAW or ARRICORE MXF files to Cutsio. The ALF4 look is applied to the review stream. The colorist downloads the original — LogC4 intact with ALF4 reference.

  • ALF4 look in review stream — matches the DP's intent

  • Original MXF unmodified — LogC4 + ALF4 intact for the grade

  • Visual Search indexes review assets with the production look

class="no-underline inline-flex items-center justify-center rounded-full bg-indigo-600 px-8 py-3.5 text-sm font-semibold text-white hover:bg-indigo-700 dark:bg-white dark:text-slate-900 dark:hover:bg-neutral-100 transition-colors shadow-sm">

Try Cutsio Free

No credit card required. 60 minutes of free processing.