Baselight 8: The feature list is the easy part

For those who do not know the tool: Baselight is FilmLight’s professional color-grading and finishing system for film, episodic productions, commercials and broadcast. It combines creative grading with conforming, color management, finishing and final delivery, and is available both as dedicated Linux-based systems and, through Baselight S and Baselight M, on macOS. Put less formally, it is one of the places where a production stops being a large and argumentative collection of camera files and becomes the image the audience will actually see.

With Baselight 8 coming in 2027, the interesting part is not the number of new buttons. Some features continue or substantially expand work introduced with Baselight v7, while others rethink long-standing specialist tools, extend mastering and cloud workflows, or make greater use of machine learning and the growing FilmLight API ecosystem. So we did not ask what each feature does, but why FilmLight built it and what problem it is intended to remove before that problem becomes an expensive evening shift. To explain it all, we sat down with Martin Tlaskal and Daniele Siragusano.

Audio tracks: Mastering without pretending to be Pro Tools

DP: Let us begin with the suspicious appearance of audio tracks in Baselight. Have you decided that colorists are insufficiently busy and should also edit dialogue?

Martin Tlaskal: Absolutely not. Creative audio editing is not the target, and we have no interest in turning Baselight into a digital audio workstation. We do not expect people to cut dialogue, assemble a soundtrack or begin composing the score while waiting for a render. Colorists have enough on their plate without adding that!

The purpose is mastering and deliverables. Baselight has to import scratch tracks and stems, place them correctly, monitor them and include the correct combinations in the final outputs. It is audio management for the person who may not have cut a single second of sound, but still has to pull the entire master together without discovering five minutes before delivery that channel seven is empty.

DP: What does the new system contain?

Martin Tlaskal: There is a complete track-and-bus structure. You can create multiple audio tracks, define as many channels as required and configure their layouts. In the timeline, you can display all the waveforms (to check visually whether there is something in that track), show only the useful ones, or hide the entire audio section while grading. In many facilities, an assistant or finishing operator will configure the sound, and the colorist will then hide it until the project reaches mastering.

The timeline can hold the relevant language settings, frame rates and delivery metadata for formats including IMF, QuickTime and Broadcast Wav. The important change is that this configuration lives visibly in the timeline and can be configured and monitored there. The render panel then becomes much simpler. You choose which track or bus belongs in the output, select the codec and render. The complexity has already been organised so that people can inspect it. Baselight can monitor individual channels, and it displays a red warning when a section of the timeline has no audio. That makes it possible to quickly scan the project and find a short gap rather than learning about it from the client’s quality-control department.

Each audio strip has an Audio Operator defining its source. That source may be stems, embedded movie audio or a fixed tone. There are settings for audio conversion ratios, a Mixdown Operator for declaring which inputs feed which outputs, and keyframeable gain. These are not there to encourage ambitious mixing sessions, but because real deliverables require channel routing, level changes and conversions, even when the creative mix happened somewhere else.

DP: Baselight could already generate DCP and IMF packages, including supplemental IMFs. What was actually wrong with the previous workflow?

Martin Tlaskal: It could do the job, but the audio side could be painful to configure and difficult to monitor. The new system makes the audio structure explicit. You can see what is present, listen to individual channels, identify gaps and understand which bus will go into which deliverable. The aim is not to expand the colorist’s job description, only to make the mastering part of that job less dependent on hidden settings and optimism.

Remote Baselight: The desk stays, the computer can leave

DP: “Cloud grading” has been “ready” for several years, depending on which exhibition booth one happens to be standing in. What has FilmLight actually completed?

Martin Tlaskal: There have been several successful tests, and the core software is largely in place. A Baselight can run on a remote instance connected to cloud storage, while our REMOTE software sends the video output back to the colorist. Depending on the available bandwidth, that stream might use JPEG XS or H.265. The other part of the problem is the control surface. We have now completed the work required to remote all our desks, including Blackboard control surfaces that are around 15 years old. Moving the Baselight process into a data centre is not especially useful if the colorist can’t seamlessly continue to use their existing control surface. 

DP: How do the older Blackboard surfaces connect to a modern Mac or Linux workstation?

Martin Tlaskal: Some configurations need what we call a Blackboard Bridge. It is a small computer based on a Raspberry Pi that acts as an interface between the control surface and the workstation. Whether you need one depends on the particular desk and host system.

For example, a Blackboard 2 expects a DVI video input and a USB communication input. A Linux workstation can support that through suitable hardware, but the same arrangement is not available on a Mac. In that case, the Bridge converts the required Blackboard interface to Ethernet and handles the video output. Older Blackboards using DVI can similarly be converted into an interface that a current Mac or Linux system can use. Some desks, like the Blackboard Classic can connect without the Bridge, particularly as the required Ethernet interface is already present. The purpose is not to place a Raspberry Pi in every grading room as decoration. It is to preserve compatibility with existing desks whilst making the Mac a first-order Baselight platform and supporting remote workflows.

Direct S3 access: Removing the filesystem tax

DP: The “larger, hipper” cloud development is direct S3 access. Before we pull out diagrams and an AWS consultant, what problem is that solving?

Martin Tlaskal: The storage itself is not necessarily the expensive part. An S3 bucket can hold several terabytes of project data at a reasonable cost. The problem is that very little post-production software can read object storage directly.

Most applications expect a conventional filesystem. Facilities therefore put another layer between the application and S3. A simple FUSE wrapper may work when bandwidth requirements are low, but it is not suitable for something like uncompressed OpenEXR playback requiring very high throughput. More sophisticated filesystems and NVMe caching schemes can provide the speed, but they can also multiply the effective storage cost three, four or five times. At that point, the inexpensive object storage has acquired a very expensive wrapper.

FilmLight REMOTE: Next-Generation Remote Color Grading

DP: What changes when Baselight can mount the bucket directly?

Martin Tlaskal: Baselight or Nara can read from and write to the S3 bucket without an intervening filesystem. You enter the bucket identifier and credentials, mount it directly and use it as a first-order filesystem from inside the application. That includes high-resolution playback and the possibility of hosting a Baselight cache in S3.

This changes the economics particularly for long-form work. A commercial may not need a huge amount of storage, but a long-form production can involve a great deal of data. Removing an additional intervening filesystem makes the storage architecture cheaper and more efficient. It also removes another system that has to be configured, monitored and explained to somebody during the inevitable Friday evening failure.

DP: Does the Baselight itself have to be running inside AWS?

Martin Tlaskal: No. An on-premises Baselight can mount the S3 bucket over the internet and access the media directly. If the available internet bandwidth can’t sustain the required playback rate, Baselight can use its strip-caching system to bring the material required by the timeline into the local disk cache.

That means a client can provide a bucket, the facility can conform from it and Baselight can pull down the relevant media. The facility pays the egress charge when the material is retrieved, but subsequent playback comes from the local cache. Once the work is finished, Baselight can render directly back into S3. The media does not need to be copied through a separate virtual filesystem simply because the grading application cannot understand the storage.

Daniele Siragusano: It opens more workflow possibilities. Productions rarely exist in one building now. The source media, grading system, operators, review clients and delivery destination may all be in different locations. Treating object storage as part of the Baselight filesystem makes those combinations more flexible.

Before Baselight 8: The Baselight 7 pipeline work

DP: Before we accidentally credit Baselight 8 with every piece of code written this decade, which developments are actually arriving in Baselight 7?

Martin Tlaskal: Consolidate and Transcode will arrive in a Baselight 7 point-release. It has been in development for quite some time and contains a large number of changes, many of them related to FLAPI, our Python and Javascript API.

Our general rule is that most new functionality should have a FLAPI interface. We use the API ourselves, and each release expands the amount of the application that facilities can access programmatically.

DP: Let us start with versioning. What did Baselight already support?

Martin Tlaskal: We already had filename-based versioning, sometimes described as Nuke-style versioning. The version is encoded in the filename as V1, V2, V3 and so on. Baselight can recognise the pattern and scan for all versions matching the pattern, allowing the user to quickly switch between all the different versions in the UI.

Baselight v7 refines the colourist’s toolkit

We also support OpenClip versioning. OpenClip is an open XML-based format that acts as an indirection point between the application and the media. Instead of Baselight pointing directly at one image sequence, it points at the OpenClip file, and that file lists the available versions. Larger animation studios use this because their production database can generate a directory of OpenClip files. When Baselight synchronises, it sees the updated media automatically.

DP: Why add explicit versions if those two systems already work?

Martin Tlaskal: Some facilities do not want another file sitting between their production database and the Baselight scene. They already know which versions exist and want to write that information directly into Baselight.

With explicit versions, an FLAPI call can add a version to a particular shot, provide the paths and names, attach categories, declare which version is current or delete a version. The database can control the versions inside the scene rather than maintaining a parallel layer of OpenClip files. Both approaches remain useful. The point is to let facilities choose the versioning model that suits the rest of their pipeline.

DP: What are categories in this context?

Martin Tlaskal: A Baselight category is essentially what another system might call a tag. It contains a string and a color. In versioning, categories allow the facility to express the status and intended use of each version.

An animated feature might have categories for “approved by director”, “approved by DP”, “work in progress” or “not ready for review”. Version 27 may physically exist, but that does not mean it should automatically replace version 26 in the timeline. The categories make that distinction visible. An operator can see what may be shown, what is still being worked on and which version has been selected as the current production version.

DP: Can the system update without interrupting the person in front of Baselight?

Martin Tlaskal: Yes. Version scans can be started programmatically and run in the background rather than forcing the front-end user to wait for image scanning. The Shots View can display the available versions and let the operator change the active one there.

Good versioning saves a remarkable amount of operator time. Facilities increasingly have to do more work with fewer people, so a versioning system that can be driven from a database or a comparatively small script can remove a great deal of repetitive checking.

Consolidate and Transcode: A shot-based delivery engine

DP: What is the Transcode part of Consolidate and Transcode?

Martin Tlaskal: It is another view onto the Baselight renderer, but organised around shots. It is intended for VFX pulls, proxies and essentially any other operation where each shot must be rendered as a separate output.

The important part is not merely that it renders shots. It has a detailed naming system that can construct the output filename from the source filename, shot metadata or a combination of both. It can also create the required directory structure, decide whether the outputs keeps their input resolution or are normalised to another format, choose the color space and control the file type and metadata.

DP: What happens with frame numbers and handles?

Martin Tlaskal: A VFX pull may need every shot to begin at frame 1001, with handles placed before and after the main range. The Transcode system can generate that numbering pattern rather than simply retaining the timeline frame number or source sequence number.

This sounds like a small detail until 300 shots arrive in a VFX facility with inconsistent starting frames, differently named handles and three departments interpreting the convention in three creative ways. The purpose of the system is to define the rule once and apply it consistently.

DP: How does it prevent files from overwriting one another?

Martin Tlaskal: It checks for naming collisions. The same raw shot may appear more than once with different debayer settings, for example. Although both outputs originate from the same source sequence, they are not the same image and must not receive the same output name.

If the naming expression would overwrite another output, or even overwrite the source, Baselight rejects it. Alternatively, the preset template can contain what we call a repeat disambiguator. Baselight then adds an A, B, C or similar suffix to make the filenames unique. The whole point of our Transcode functionality is to enable automation – that doesn’t work if you can’t be extremely confident that files won’t conflict with one another..

DP: Can the actual transcode happen on another machine?

Martin Tlaskal: Yes. The operation can be distributed to another system and appears in the Baselight render queue. When the render completes, Baselight can update the scene to point to the newly generated media.

The transcode can also be registered as a new explicit version. That is useful in workflows such as restoration or dust removal, where material is rendered out, processed in another application and brought back as a new version of the same shot. The versioning and transcoding systems are designed to work together rather than passing folders to one another and hoping both departments guessed the same filename.

Daniele Siragusano: Conceptually, it covers some of the work associated with systems such as HIERO or Nuke Studio. Starting from a conformed timeline, Baselight can prepare plates and a file structure for other departments, then receive the resulting media back.

If Baselight is already the finishing system and already understands the color pipeline, it makes sense to distribute the material from there. Otherwise, the facility may conform the project in one package, move it to another package to prepare the plates and then try to preserve the same color decisions between them. Baselight can instead apply the intended color science while preparing the media and keep the resulting versions connected to the finishing scene.

FilmLight fl-enhance: Baselight Tools Escape Into Python

DP: Where does FLAPI enter that workflow?

Daniele Siragusano: FLAPI (The FilmLight API) can be used to trigger whatever custom code the facility needs. A transcode can notify a production database, create a Nuke script in Nuke, register shots with a restoration pipeline such as Diamant or run another site-specific process.

The intention is not to replace every production-management system. It is to let Baselight participate properly in those systems. If a facility has 25 studios sending material into one project, Baselight can sit at the centre of the color and finishing workflow while the scripts handle the communication with everything around it. Or it can cleanly feed into the studio pipeline at every point where it makes sense. It’s the user’s choice.

Hierarchical presets: Putting experience into the settings

DP: The Transcode interface contains a hierarchical presets system. Why does a renderer need a hierarchy?

Martin Tlaskal: Because facilities need a way to express policy. People move between productions and companies, and new operators may arrive without knowing the house rules. Someone experienced has to define how the facility creates a VFX pull, where the files go, which color space is used and what metadata is retained.

Baselight has traditionally exposed a powerful interface and expected people to learn it. That offers flexibility, but it is not especially helpful when someone simply wants to create a valid proxy. The preset system lets FilmLight provide factory starting points, lets the facility publish its own site-level policy and lets a particular scene override only the settings that genuinely need to differ.

DP: How does the hierarchy work in practice?

Martin Tlaskal: You might start with a factory preset for a classic consolidate or a VFX pull. At the scene level, an operator could change the output directory, decide whether to process selected shots or all shots, change to a different flavour of EXR  or attach additional categories.

Baselight marks which values differ from the previous level of the hierarchy. If the scene-level preset has changed the output path and handle length but retained the site’s format and color-space policy, that difference is visible. A tested scene preset can then be copied to the site level or job scope and published for everyone in the facility.

DP: What kinds of choices can a facility encode?

Martin Tlaskal: The preset can define naming expressions, directory structures, dates, job codes, output resolution, color space, file type, metadata, tape name, timecode source and whether the result becomes an explicit version. It can also attach categories such as “transcode” to the generated material.

The critical part is often not the path or filename. It is the technical taste behind the preset. For a VFX pull, the facility may decide that the output should be ACES Linear, remain at the input resolution, use a particular OpenEXR configuration and take timecode or tape metadata from a defined source. Those decisions can then be made once by the person qualified to make them.

DP: Can the facility prevent operators from changing settings that should remain fixed?

Martin Tlaskal: The preset can hide settings that should not normally be changed. An operator may be allowed to choose the project name, output path and handles while the codec, color space, file type, image options and metadata remain hidden.

This is not an irreversible security lock. The settings can still be revealed and inspected when necessary. The point is to make the normal workflow clear and reduce accidental changes. A professional finishing tool has a very large blast radius. One incorrect option can affect every shot in a delivery, which is a worrying amount of responsibility for a dropdown menu.

DP: Does the same preset approach apply beyond Transcode?

Martin Tlaskal: Yes. Other complex operations, such as timeline sorting and multi-paste, will use the same system. A factory preset could, for example, configure the correct starting settings for copying metadata from an ALE file. The user still provides the file, but does not have to discover every required option independently.

The aim is to make complicated functions approachable without reducing their power. Experienced users can reveal everything. New users can start with settings that are likely to work. The interface becomes less cluttered, and the facility can preserve the decisions it has already made.

Daniele Siragusano: Everything available in the interface can also be done through FLAPI. In that sense, the user interface is a view onto the API. A facility can perform the operation manually, automate it completely or start with a preset and customise only the site-specific parts.

Color : The ninja tool receives a map

DP: Colour Crosstalk is not a new Baselight tool. Why rebuild it?

Daniele Siragusano: Colour Crosstalk has existed since Baselight 5. The old interface showed a collection of similarly presented sliders for the red, green and blue outputs, plus offsets. The processing was powerful, but the interface made it very difficult to understand what a particular slider movement would do.

Over time, experienced colorists developed a feel for it. They could also produce fortunate accidents, look at the result and decide that it was excellent without being entirely sure how they had arrived there. It became a genuine ninja tool. Our question was whether the image processing was still valuable, and whether the interface could be reformulated so that people could use it deliberately rather than through informed gambling.

DP: What is Colour Crosstalk doing under the interface?

Martin Tlaskal: Most simple grading operations treat red, green and blue independently. Many photographic and film-like effects do not. Input in one color channel can influence the output of another channel. Those cross-color interactions are part of what makes some film processes interesting.

Technically, Colour Crosstalk is a matrix multiplication. Each output channel is calculated as a weighted combination of the three input channels. The green output, for example, may contain a weighted contribution from the red, green and blue inputs. There are nine core relationships in a three-by-three RGB matrix. The old interface exposed those relationships as numbers. The new interface gives the colorist a visual way to manipulate the same underlying matrix.

DP: What does the visual interface change for the colorist?

Daniele Siragusano: You can select the reds and move them toward yellow, blue or magenta. Baselight translates that visual instruction into the matrix values underneath. You are still using the same mathematical operation, but you no longer have to remember which combination of nine sliders moves a skin tone or changes a particular relationship between yellow and blue.

Opponent colors are represented in the interface because some adjustments are linked. To alter yellow, for example, the blue channel becomes important. The visual representation helps the user understand those connections and arrive at settings that would be extremely difficult to create by adjusting the underlying numbers at random.

DP: Why is the matrix useful near the beginning of the grading stack?

Daniele Siragusano: A matrix is a linear operation. It preserves scene linearity, so straight relationships in the scene-linear data remain straight. You can make very large changes without introducing nonlinear bends that may create fringes or cusps.

That makes it useful for correcting a camera calibration matrix before the creative grade. A camera matrix may have been fitted for a standard light source, but the same camera can respond differently under an LED source. An additional Colour Crosstalk matrix can compensate for that lighting situation and create a more plausible starting point before the colorist begins the look development.

DP: Can that correction be used across a scene?

Daniele Siragusano: Yes. Once you have found a matrix that gives one shot a better starting point, you can copy it to the other shots in the scene. It can become an early technical correction beneath the creative work.

The same tool can also be used creatively. You can alter skin colors, push reds toward another hue or change the relationship between greens and yellows. The difference is that the new interface lets the colorist understand and repeat the operation rather than preserving the result as a sacred accident.

The new grain model: Not just noise on top

DP: Baselight already has grain. Why start again?

Daniele Siragusano: The creative use of grain has changed. In many modern productions, the grain added to a digital image is considerably more visible than the grain that would have appeared in the original film process. We therefore wanted a more flexible model rather than a simple texture placed over the image.

The new model operates in linear light. Grain responds to exposure, and linear light gives us a physically meaningful space in which to model that response. The colorist can control how the grain behaves over the tonal range, instead of applying one uniform noise level to the entire image.

DP: How does that distinguish film grain from digital sensor noise?

Daniele Siragusano: Digital photon shot noise tends to be strong in the shadows and much cleaner in the highlights. Film negative distributes grain differently, retaining more of its structure through the midrange and into the highlights while behaving differently in the deepest shadows.

The tonal-response control lets the colorist move between those models. You can create a response that behaves more like a digital sensor, one that behaves more like camera negative or something deliberately positioned between them. The grain is not simply assigned an amount. It is given an exposure-dependent behaviour.

DP: What controls define the color of the grain?

Daniele Siragusano: The model includes color correlation. Film contains interlayer effects, so the apparent grain in the color channels is not channel independent. The colorist can shape those relationships and move from an unpleasant magenta-green interaction toward something more characteristic of yellow-blue film behaviour, or toward another result entirely.

DP: You also described spectral shaping. What does that mean here?

Daniele Siragusano: The grain contains structures at different scales. Some components appear as larger clusters, while others contribute fine texture. Spectral shaping allows the colorist to alter those parts independently.

You can increase or reduce the large-scale structure, change the smaller details and generally mould the texture rather than controlling it only with a single size parameter. Two grain patterns can contain a similar overall amount of variation while feeling completely different because their energy is distributed differently across those scales.

DP: And then we reach kurtosis, the point at which the colorist quietly searches for a statistics textbook?

Daniele Siragusano: Kurtosis describes the statistical distribution, particularly how tightly the values cluster and how frequently more extreme outliers appear. In practical terms, the control lets you create grain where most values sit close together, with very few exceptional bright or dark points, or grain containing more pronounced outliers.

You can also bias those outliers toward the highlights or shadows. One process may produce occasional bright clusters, while another creates more dark outliers. This gives the colorist control over the statistical character of the grain, not only its size, amount and color. The name is less friendly than the result.

DP: Can the system measure existing grain instead of asking the colorist to reproduce it by eye?

Daniele Siragusano: Yes. You can select a suitable area with a picker, and Baselight analyses the grain characteristics. For a reliable measurement, the system needs enough data. That may come from a large area in one frame or from sampling multiple frames.

Multiple frames are particularly useful for the lower-frequency structures, because a small sample does not contain enough statistical information about the larger patterns. Baselight separates the grain from the underlying picture, derives the model and synthesises a matched version.

 DP: Does sampling a grey patch only produce a match for grey?

Daniele Siragusano: No. Because the result is a physical and statistical model, the sampled information is used to reproduce the grain behaviour across the image colors. The grey sample provides the data required to estimate the model, but the result is not limited to grey pixels.

Once the grain has been matched, it can be saved as a preset. A facility might sample a particular 35 mm stock, a grain plate used across several productions or another source with a useful texture. That preset can then be applied to another scene.

DP: Is the match fixed, or can the colorist still alter it?

Daniele Siragusano: It remains procedural. A matched grain is a starting point, not a flattened texture. The colorist can reduce the grain in the highlights, increase it in another part of the tonal range, alter the color correlation or reshape the spectral distribution.

That is similar to the philosophy behind Chromogen. You can begin with a model derived from a known process and then modify it. The source provides the character, but the colorist is not locked inside a historical reconstruction that refuses all creative requests.

DP: Can it also model digital camera noise?

Daniele Siragusano: Yes. The distribution and tonal-response controls can represent digital noise as well as film grain. A typical multi-camera workflow might denoise all the cameras and then apply one common grain model so that the final material shares a consistent texture.

If one camera is shooting film, the production could record a flat field, sample that grain, denoise the digital cameras and add the film-derived model to them. Alternatively, you can match everything to a digital source. Or, should the cinematographer arrive with a passionate request for the character of an imaginary 1962 Warsaw camera, the controls are unlikely to stop them.

DP: Martin, you stressed that this is not an ordinary additive grain pass. What is the difference?

Martin Tlaskal: Many grain tools add a noise image on top of the picture. The underlying image remains perfectly resolved, and the grain sits over it like a transparent layer.

This model modulates the image through the grain structure. If the grains become very large, fine image detail cannot remain fully resolved because the image is effectively being formed through that structure. That is closer to the physical behaviour of film. You cannot have image detail that is much finer than the structure producing the image and still expect it to remain untouched.

Daniele Siragusano: Although the colorist can blend detail back when the physically realistic result is not the desired result. That may be less realistic, but it is available. Physical plausibility is the default, not a disciplinary procedure.

DP: This sounds computationally expensive. How does it remain interactive?

Daniele Siragusano: Grain normally sits near the end of the grading stack. That makes conventional output caching inconvenient, because every change to the grade would require the final grain result to be cached again.

We divide the process into two parts. The first creates the digital emulsion, comparable to producing the unexposed grain structure. That stage does not depend on the image. The second stage modulates the actual picture through that structure. Baselight can therefore precompute and cache the image-independent substrate while continuing to calculate the image-dependent part during playback.

DP: How large is that internal cache?

Daniele Siragusano: In the demonstration, the cache contained 250 frames. Once those frames had been generated, Baselight reused them. The initial frames were not yet real-time while the cache was being created, but playback became real-time after the bucket was available.

The demonstration ran in a UHD scene on an M1 Mac while the image was enlarged for grain inspection. An indicator on the operator shows that internal caching is active. The colorist does not have to cache the final graded shot simply to make the grain playable.

Color Correlation: Baselight’s tenth way to add saturation

DP: Baselight already contains several saturation tools. How many does a responsible grading application need?

Daniele Siragusano: Color Correlation is probably our tenth saturation algorithm, and colorists genuinely need different ways to add and remove saturation. Saturation is difficult because there is no simple physical equivalent. You cannot make a red dress more saturated by adjusting the camera or moving a lamp. At some point, you need a redder dress.

Removing saturation is comparatively straightforward because the RGB values can be moved toward a common value. Adding saturation is more problematic because ordinary methods can push colors outside the available gamut, where they begin clipping, glowing or behaving unpleasantly.

DP: How do conventional saturation controls normally work?

Daniele Siragusano: A basic implementation converts the RGB values into a representation such as HSV and scales the saturation component. More sophisticated tools may use a perceptual color space such as Lab and increase the chroma dimensions there. Then there are norm-based methods.

Color Correlation takes a different approach. It stays in the RGB domain and looks at the statistical correlation between the red, green and blue channels. Increasing saturation reduces that correlation, moving the RGB values farther apart. Reducing saturation brings the channel values closer together. The operation changes how the channels relate to one another rather than first converting the image into a separate saturation model.

DP: How does that help with gamut?

Daniele Siragusano: The colorist can define a boundary and a set of primary colors toward which the operation works. Those primaries might represent Rec.709 or another standard gamut, but they can also be chosen creatively.

As the correlation changes, colors inside the boundary can become more saturated while colors already near or beyond the intended primaries are compressed toward them. In the demonstration, some magentas became less saturated while other colors gained saturation. The result is not simply every color moving outward by the same amount. The operation reshapes the saturation distribution while trying to keep the result within the defined gamut.

DP: So this is partly a technical gamut-management tool and partly a creative one?

Daniele Siragusano: Yes. The colorist can steer the saturation toward a standard output gamut or toward a deliberately chosen set of creative primaries. There are also controls affecting where the operation acts across exposure.

Groups View: Letting machine learning organise the timeline

DP: The new Groups View is not another grading operator. What is FilmLight trying to change?

Martin Tlaskal: We are trying to help users view and manipulate a scene in ways that make the grading process more efficient. One of the initial FLAPI scripts analyses the project and attempts to detect narrative scenes and camera angles.

It looks for shots that appear visually similar, groups matching angles and identifies shots that seem to belong to the same location and period in the story. Groups View then presents those relationships so that the colorist can work with them through Baselight’s “grouped grading” system.

DP: What information does the machine-learning analysis use?

Martin Tlaskal: It generates embeddings, which are numerical vectors representing the image content in a latent space. In less ceremonial language, the model turns what it sees in each shot into numbers that can be compared with the numbers from other shots.

It also creates histogram information describing the rough color structure of the image. Baselight combines the content representation with the color representation and clusters shots according to their similarity. The output includes narrative scenes, angle groups and global angle groups.

DP: What is the difference between a narrative scene and an angle group?

Martin Tlaskal: A narrative scene is intended to represent a section of the story occurring in the same general place and time. Within that narrative scene, the angle groups collect shots that appear to come from the same camera position or setup.

The demonstration identified a broad scene, then separated the wide shot, two-shots and close-ups inside it. The result was not perfect, particularly where two visually related parts of one location could plausibly be treated as separate scenes, but it provided a useful initial structure.

DP: How does that structure affect the grade?

Martin Tlaskal: The colorist can select a narrative scene and apply a common grouped grade, then move into the angle groups and refine individual setups. For a documentary, the analysis might separate talking heads from exterior material. For a drama, it can organise the project by scene and angle rather than requiring the colorist to move through the entire timeline linearly.

Baselight already has sophisticated grouped grading. The difficulty has been creating and maintaining the groups. Colorists with large assistant teams could take full advantage of it. Many others decided that constructing the groups manually required more time than the grouped grade would save.

DP: How accurate does the ML need to be for this?

Daniele Siragusano: The machine learning may create around 80 percent of the grouping. The user interface is intended to make the remaining 20 percent fast. The objective is not to make the machine the final authority on the dramatic structure of the film. It finds the visual similarities, and the colorist or assistant corrects the places where the model misunderstood the scene, divided it at the wrong point or combined material that should remain separate.

DP: What correction tools are available?

Martin Tlaskal: There is a sensitivity control that changes how readily the analysis divides the timeline into groups. When the model is uncertain about whether two sections belong together, the user can increase or decrease that sensitivity.

The operator can also lock the groups above the current position, preserving the sections that have already been checked. Groups can be split, joined or rearranged by dragging and dropping. The idea is to work down the timeline, approve what is correct and repair what is not without repeatedly destroying the earlier work.

DP: Why describe this as a move from linear grading to hierarchical grading?

Daniele Siragusano: A traditional timeline encourages the colorist to think from shot one to shot two to shot three. Groups View lets the colorist think first about the scene, then about the camera angle and then about the individual shot.

Spending five minutes organising the project at the beginning can save a great deal of time later. Machine learning is good at finding visual similarities, and similar shots usually need related grades. The hierarchy therefore reflects the way filmmakers and editorial teams already discuss the story, as scenes and setups, rather than reducing the project to a long row of thumbnails.

DP: Could those groups also represent storytelling ideas that are not purely visual?

Martin Tlaskal: Yes. A production might identify all scenes set in the past, all material photographed with another camera or all shots intended to receive a particular stock, grain, saturation treatment or haze.

The ML may find some of those relationships from the images, but the grouping keys can also come from metadata. If the production already knows from the script or editorial database which scene each shot belongs to, it can write that information directly into Baselight rather than asking the model to rediscover it.

DP: What does Groups View store underneath the interface?

Martin Tlaskal: At the data level, the system is comparatively simple. It creates columns in the Shots View, such as narrative scene or angle, and writes values into them. Shots sharing the same value belong to the same group.

That is important because it means FilmLight’s own ML analysis is not mandatory. A facility can use information from a script, editorial system, animation database or another analysis tool. An FLAPI script creates the column and writes the appropriate values, and Groups View presents the result. The interface is sophisticated, but the underlying exchange is deliberately uncomplicated.

DP: Could an animation studio group every shot containing a particular character?

Martin Tlaskal: Yes. An animation studio often knows exactly which characters appear in each shot because that information already exists in its production database. It can write those character names or identifiers into Baselight and create a character-based view of the project.

The grouping key can be anything suitable. It might come from editorial, After Effects, a production tracker or another database. Groups View does not care whether the value was discovered by a machine-learning model or supplied by someone who already knows the answer.

DP: You also tested automatic actor detection during the demonstration. How did that work?

Martin Tlaskal: That was very experimental. A newly added FLAPI script ran a face detector across the shots, generated a numerical representation for each detected face and clustered similar faces together. The resulting groups appeared as Actor 1, Actor 5 and so on.

The model identified several actors correctly, but it also produced aliases where the same person appeared as two separate identities. The user could join those groups and replace the numerical identifier with an actor or character name. The important data-model change is that one shot can now contain multiple group values, because a shot may contain several people.

DP: Would anyone really want every face in a crowd shot to become a grading group?

Martin Tlaskal: Probably not. A useful implementation would need controls that ignore cases where the number of faces becomes irrelevant. A close-up containing one actor may be useful for beauty work or review. A crowd shot containing 30 people is unlikely to require face-level grading for every person.

That is another reason why the ML output needs a user interface and adjustable rules. The model can detect things, but the facility still decides which detections have production value.

DP: What other grouping axis could be useful?

Martin Tlaskal: Resolution is an obvious example. Groups View could show every 8K shot, every 6K shot or all material using a particular input color space. The operator can then select that group and transcode, inspect or process it.

The traditional project views are A-mode and C-mode, essentially the edited timeline and the source-oriented view. Groups View asks how many other useful views can exist. A facility may need wide shots, close-ups, one camera format, one actor, one location or one class of media. Each is another way to narrow the project down to the material relevant to the current problem.

DP: What production uses do you imagine beyond grading scenes and angles?

Daniele Siragusano: A commercial could group every shot containing a particular product. If a territorial version requires one can, watch or package to be replaced by another, the facility can immediately find the relevant shots.

The same structure could be used to collect every final shot containing a particular actor, render approved HDR stills and create a review package. It could locate every shot requiring a beauty correction, help mine a project for trailer material or identify all media that needs a technical conversion.

Martin Tlaskal: The interesting part is that facilities can write their own analysis scripts. They do not have to use our ML model or even our ML framework. A Python script can call another model, create a new column through FLAPI and write the resulting values into it.

Once the data-model work supports the required information, the analysis itself can be relatively small. That is the larger point. Groups View is not one fixed automatic scene detector. It is an interface for looking at a project through many different kinds of grouped information.

DP: Does this also mean FilmLight is changing the existing grouped grading system?

Martin Tlaskal: Not yet. The first step is making the groups easier to create and correct. If users find the view useful, we can then improve how those groups connect back into the timeline and develop the grouped grading system further.

Grouped grading has received relatively little attention because creating the groups was such a burden. Once useful groups can be generated in minutes, there is a much stronger reason to expand what the grading system can do with them.

Chromogen ML: Dismantling the LUT without losing the look

DP: Chromogen ML is another Baselight 7 development. What problem is it addressing?

Daniele Siragusano: A cinematographer may arrive with a favourite LUT. It creates colors they like, but it also converts from a camera log space to Rec.709, contains artefacts or produces a structure that is unsuitable for an HDR version.

The colorist wants the character of the LUT without being trapped inside the LUT. An experienced user could rebuild an approximation manually in Chromogen, but that may take half a day. In a real grading session, asking the production to pause while the colorist reverse-engineers an beloved LUT is unlikely to be popular.

DP: What does the machine-learning model produce?

Daniele Siragusano: It analyses either the LUT or a grading stack and attempts to recreate the look using editable Chromogen and Base Grade operators. Different models can use different levels of complexity.

In the demonstration, the system identified an exposure reduction of approximately 1.1 stops, added flare and constructed separate stages for saturation, shadows, crosstalk, pure-color adjustments, bleach, pastel behaviour, contrast, brilliance reduction and highlight tinting. Instead of returning another opaque LUT, it returned a procedural grading structure.

DP: Earlier demonstrations used a web service. Why move the model onto the Baselight workstation?

Daniele Siragusano: Colorists and facilities may not want to upload proprietary LUTs to an external service. Some grading environments do not have an internet connection at all. The revised system runs locally on the Baselight machine. The LUT does not leave the facility, and the result does not depend on a cloud service being available. That makes the workflow more suitable for secure productions and more practical in facilities with restricted networks.

DP: How closely does the result match the original LUT?

Daniele Siragusano: It provides a reasonably close starting point, but it is not guaranteed to reproduce every possible LUT exactly. A LUT can contain arbitrary shapes, including hard kinks and other irregular behaviour. Chromogen is constructing a plausible procedural look, so it may not reproduce those pathological details.

That limitation can be useful. Some LUTs were built in questionable ways. Chromogen ML can retain the useful color character while replacing some of the less defensible behaviour. Martin described it as a LUT healer, which is probably kinder than several LUTs deserve.

DP: What can the colorist do once the look has been reconstructed?

Daniele Siragusano: Every stage can be inspected, bypassed and changed. The colorist can increase the saturation in the sky, alter the contrast, reduce a highlight tint or modify the part of the look responsible for a particular color relationship.

That is more useful than placing corrections before and after a broken LUT. Instead of trying to compensate for the LUT from outside, the colorist can go inside the reconstructed look and change the operation causing the problem.

Nara: Now with More Sync, Less Scream

A more regular major release, within reason

DP: Baselight 7 became an unusually large release. Is Baselight 8 part of a move toward a more regular schedule?

Daniele Siragusano: That is the intention. The intervals between earlier major releases were long, and Baselight 7 grew into a very large development cycle. With Baselight 8, we are trying to move toward something closer to an annual major release.

That does not mean the engineering work becomes small. It means trying to package the work into releases with a clearer scope rather than allowing every major version to become a multi-year collection of everything we have thought of since the previous one.

Martin Tlaskal: Baselight 7 was simply too big. We are trying to reduce the size of the jump. The amount of work underneath can still be substantial, but the release should be more manageable for development, testing and users.

DP: Why are you reluctant to promise an exact release date?

Martin Tlaskal: Our rule is that we do not ship rubbish. We know many of our customers personally, and it is not fair to give them a build with known serious problems merely because a date was placed on a slide several months earlier.

We want the first beta to be reasonably feature-complete rather than dividing the functionality across four or five beta stages. But if feedback reveals that a feature could be substantially improved with another few weeks of work, we may choose to do that work. The schedule is important, but the software still has to survive contact with an actual production.

DP: Why does the internal data model make that especially important?

Martin Tlaskal: Baselight is connected to several related products and workflows, including Avid, Nuke and BLG interchange with other applications. We have a compatibility rule that any release carrying the same major version should be able to open projects created by another build in that major-version family.

Users should not have to inspect a build number before deciding whether one Baselight system can open another system’s scene. That limits how freely we can change the data model after the first release. We therefore have to make sure the structure is correct before the version ships.

Groups View follows the same philosophy. Machine learning performs the repetitive first pass, but the user remains responsible for narrative meaning, production context and the final structure. Chromogen ML similarly dismantles a LUT into editable operations instead of declaring the original black box sacred.

Baselight can now help arrange the shelves, label the bottles and warn when the audio has vanished. The colorist still decides whether the entire film really needs the grain of a fictional Warsaw camera from 1962. That part of the process remains reassuringly human.