AI system for automatic video color correction: pipeline and LUT

Manual color correction cannot keep up with the volume of an archive: footage waits its turn, and a consistent look is lost when the specialist changes. We develop turnkey automatic color correction systems — we train a model on your source footage and configure the process to your workflow. Bringing a scene to reference is accelerated severalfold, and a consistent style is maintained across the entire media library.
Frequently Asked Questions

Automatic color correction: where the manual pipeline breaks

A manual pass through scenes is linear: the colorist opens a fragment, sets white balance using neutrals, adjusts curves and saturation, then transfers the settings to the next one.

On homogeneous footage this is predictable, but as soon as the lighting or camera changes in a shot, the values stop working, and the selection starts from scratch.

The main point of failure is color variation between takes. The same shot, filmed with two cameras or at different times during a shift, differs in temperature, contrast, and skin tone; to match takes seamlessly, the colorist selects values manually and checks the result by eye.

The more takes, the more pairs to compare — and the higher the chance that a discrepancy will be noticed at the final review rather than during the process.

The colorist's labor costs grow faster than the volume of footage. Twice as long does not mean twice as many identical operations: each new scene must be analyzed separately, and the number of transitions, exceptions, and local edits accumulates.

When working in multiple shifts, the human factor adds up — two specialists interpret "neutral" and "warm" differently, and a noticeable boundary between blocks appears in the series.

This is discovered late — during assembly or acceptance, when the edit affects already mixed sound, titles, and graphics. Then the delivery is missed: part of the work has to be repeated, and the schedule of subsequent projects shifts following the current one.

Below we break down how this is solved: where manual trial and error is replaced by calculation based on reference frames, how a LUT is built, and what exactly automation takes on.

What changes after implementation: measurable effects

First pass: minutes instead of a shift

Previously, primary color correction took a colorist a full shift: scenes were reviewed manually, white balance and contrast were set almost frame by frame.

Now the base pass is assembled automatically using reference frames and the project's LUT set, and a rough version is already ready at the output, which only needs to be refined.

The duration of the first pass is reduced severalfold — the picture appears the same day, not the next.

Repeatability and removed edits

The same sequence of frames is run twice and produces an identical export — this is verified by comparing results, not by eye.

The share of scenes with manual edits drops to isolated cases: skin, sky, and mixed lighting are handled confidently, while the algorithm flags controversial frames for a human.

At the same time, a whole class of errors disappears — white balance drifting between cuts, different skin tones in adjacent frames of the same scene, and contrast "jitter" at transitions.

Team workload and deadlines

The final refinement remains in DaVinci Resolve and with the colorist, but the routine — analyzing footage, matching scenes, rough grading — no longer consumes their time. The freed-up hours go to complex shots and working with the director, rather than mechanical passes.

Delivery deadlines become predictable: the volume of footage almost does not affect the estimate, because productivity is counted by the number of scenes, not by the number of available specialists.

Comparison of approaches: manual adjustment, presets, model training

The choice of mode is determined not by taste, but by the homogeneity of the footage. Manual frame adjustment holds the reference on complex scenes, but time grows linearly with volume, and the result depends on the specific colorist.

Presets cover serial shoots, but break down where lighting and camera change within a single project.

Training on your own footage removes variation between sources: the model adapts to specific optics, sensor, and lighting scheme. The price for this is an annotated sample and mandatory testing on scenes that were not in it.

Option When suitable Limitations
Manual frame adjustment complex lighting, individual scenes, reference for comparison time grows linearly with footage length, result depends on the colorist
Presets and LUT serial shoots of one type, stable camera and lighting mixed sources and autoexposure cause failures, manual refinement of some scenes is needed
Training on your own footage lots of similar footage, repeatable lighting scheme needs an annotated sample, quality drops on unfamiliar scenes
Hybrid mode long footage with heterogeneous sources more difficult to configure and accept, quality control required

In practice, hybrid mode works more often: the model handles the bulk of frames, controversial ones go to manual refinement, and presets remain the basis for comparison and rollback.

The limitations of any approach are visible only on your own footage — running a hundred scenes immediately shows where the mode breaks, how many frames require intervention, and what happens at the junctions between scenes.

Implementation stages: from source audit to handover

Work begins with an audit of the source footage, not with setup: we look at what the archive was shot with, how cameras differ within a single project, where white balance and exposure fluctuate between takes.

Already at this step it is clear which scenes will require separate logic and which are covered by a common scheme.

  1. Source audit. We analyze footage by cameras, lighting conditions, and scenes, marking problematic groups: mixed lighting, underexposed takes, transitions between rooms.
  2. Reference scenes. The colorist manually brings a selection of scenes to the target look — it is fixed as a reference against which every automatic result is then compared.
  3. Processing scheme. We determine what is solved by rules, what by conversion tables, and what by the model, and in what order operations go so that correction does not destroy previous layers.
  4. Setup. We calibrate parameters against the reference, create separate profiles for camera types and shooting conditions, and achieve smooth behavior at transitions between scenes.
  5. Testing on a control sample. We run scenes that were not involved in setup, calculate deviation from the reference and the share of shots accepted without manual editing.
  6. Fine-tuning. We adjust behavior on exception scenes until the acceptance rate stops dropping from iteration to iteration.
  7. Handover to operation. We embed processing into the current editing process, provide regulations, profiles, and documentation, train the team, and remain on support.

Each stage ends with an artifact: archive markup, a set of references, a description of profiles, a report on the control sample. Therefore, when a metric drops on new footage, it is always clear which decision caused it — and what exactly to rebuild.

What is handed over: configurations, schemes, regulations

We deliver the system so that it can be maintained on your own — without us and without access to our environment. Therefore, what is handed over is not only a working service, but also a kit by which it can be reconfigured, checked, and accepted. All artifacts are placed in your repository and versioned together with the code.

  • Processing configurations — settings files for frame-by-frame analysis and correction: trigger thresholds, profiles by scene type, rule priorities. They are edited without rebuilding the system.
  • Pipeline scheme — the sequence of stages from receiving the source to outputting the master file, with branching points and storage locations for intermediate results.
  • LUT library — by scenes and cameras, with a note indicating which footage each is calibrated for and how to add new ones.
  • Access rules — role matrix: who launches processing, who changes tables, who sees only the finished result.
  • Documentation — deployment, parameter descriptions, typical failures, and procedures for them.
  • Acceptance regulations — a reference set of clips with expected results and metrics: deviation by color channels, stability at scene boundaries.
  • Rollback instructions — how to return the previous version of the configuration and tables in one step.

We close the handover with a walkthrough on live footage: your engineers run the reference set themselves and change parameters. After that, the system is considered accepted.

Case study: before and after on a real footage archive

A production with an archive of documentary series: several seasons, hundreds of hours of source footage from different cameras, part of the material shot under mixed lighting.

Before implementation, an episode was assembled manually in DaVinci Resolve: the processing cycle took 6–8 hours, edits came back through 3–4 iterations, and the average tone between episodes relied on the colorist's memory — if the shift changed, the second episode drifted noticeably.

What was changed

First, a reference library was assembled from already approved episodes: scenes with different shooting conditions, used to calculate the base palette.

Then automatic color correction builds a LUT for each shot based on edit cuts, rather than for the entire episode as a whole — so a close-up does not drag along with the general look.

Each LUT is versioned together with the project and attached to the edit assembly.

A verification step was added: the system compares average parameters of neighboring episodes and provides a report with discrepancies that the colorist reviews before delivery, not after editorial notes.

Metrics before and after

The episode processing cycle was reduced from 6–8 hours to 40–60 minutes, and most of this time is verification and approval, not manual editing. The number of iterations dropped from 3–4 to one: edits are made to the base LUT, rather than repeated in each episode anew.

The share of returns for re-assembly decreased from 35% to 5% — scenes that were previously re-assembled due to drifting balance now undergo verification in advance.

Consistency between episodes became measurable: the discrepancy of average parameters across a season decreased severalfold, and transitions between series stopped reading as foreign.

On an archive volume of hundreds of hours, this gave a predictable pace — new series are processed with the same base set, rather than configured from scratch.

How does automatic color correction differ from LUT presets?

A preset is a fixed mapping table: each input hue is preassigned an output. It is the same for all frames and therefore does not distinguish overexposure on skin from an intentional highlight.

A model trained on your footage evaluates each frame separately and builds a transformation for the specific scene.

Approach How it works Where it hits a wall
LUT preset one color table for all footage no adaptation to the scene
Preset plus manual edits operator adjusts shots one by one time grows with footage length
Adaptation model evaluates the frame and selects a transformation needs a training sample for your camera and lighting

The main discrepancy is exposure and balance. A preset is applied to all footage, but where lighting or shutter speed changed, the same table gives a different result: overexposure in one shot, crushed shadows in another.

At transitions between scenes, this reads as a color jump, and the effect has to be cut by shots and smoothed manually.

A preset's resilience to different shooting conditions is zero: it processes mixed indoor lighting and open sun the same way.

Therefore, in series with stable lighting and a unified style, a preset remains a reliable tool — like color correction nodes in DaVinci Resolve, giving a predictable "look" on top of already matched footage. We take the model as a base: it matches scenes to each other, and we set the style with a preset.

Engineer's doubts: accuracy, control, and predictability

Automatic color correction raises predictable objections from a technical client: where is the boundary between the algorithm and the artistic decision, what to do with a heterogeneous archive, who is responsible for an error at the output. We explain how this is structured in our workflow.

How to maintain control over the result?

The model suggests rather than decides: the output is an intermediate LUT and a report on scenes with low confidence. The colorist approves the scheme, and only the approved version goes to render — random "beautiful" processing is excluded.

What to do with archival materials and heterogeneous sources?

We normalize the archive to a common working space and mark mixed lighting separately. Heterogeneous sources are not mixed in a single run: each type goes through its own branch, otherwise the balance drifts.

How does model fine-tuning on our footage work?

We take 15–20 minutes of reference-processed scenes, transfer the colorist's decisions into annotations, and fine-tune the model for your projects. Accuracy grows on your footage, not on an abstract sample.

By what criteria is the work accepted?

We fix acceptance criteria before the start: permissible deviation of tone and saturation, a unified look within a scene, absence of artifacts at transitions, the share of scenes without manual editing. Controversial frames are analyzed on the reference sample.

Let's discuss the task: what to send for an estimate and plan

To come back with an estimate and work plan, a full technical specification is not required. It is enough to describe the task in free form and attach several representative materials — we will clarify the rest and record it in a document.

The project is estimated based on the array of source footage and requirements for the output color, not on the volume of correspondence.

It is enough to send:

  • Problem statement — what is currently done manually, on what volume and at what frequency, and what exactly is unsatisfactory about the current result: time is lost, color "drifts" between frames or from shift to shift.

  • Example materials — 2-3 fragments of 30-60 seconds from different conditions: mixed lighting, interior and exterior, different cameras. The most valuable fragment is one where the color is already satisfactory, as a reference.

  • Requirements for the result — a unified look for the entire array, format and color space of output files, whether a LUT is needed for further shooting or analysis of an existing archive.

  • Constraints — where the sources are stored and how they are transferred, whether there are requirements for processing time, where to put the result and in what form the editing department takes it.

  • Approval procedure — who accepts the work, how many rounds of edits to budget for, and on which frames we verify the intermediate result.

Describe the task in whatever way is convenient. We will come back with a work plan: stages, the result of each stage, acceptance criteria, and approval procedure — without general wording.

AI Development Areas

Latest works

  • Development of a web application for FEEDME
    Development of a web application for FEEDME
    1393
  • Development of an online store for the company FURNORO
    Development of an online store for the company FURNORO
    1368
  • B2B Advance company logo design
    B2B Advance company logo design
    815
  • Development of a web application for Enviok
    Development of a web application for Enviok
    1139
  • AIDER company logo development
    AIDER company logo development
    1057
  • CRM development for Chasseurs
    CRM development for Chasseurs
    1152