At Gafpa Gear, we are developing the Kinefinity → ARRI Color Match OFX: a formula-based camera-matching plugin for DaVinci Resolve. Not a loosely interpreted “ALEXA look,” but a transformation built around controlled camera measurements, with ARRI Wide Gamut 3 / LogC3 or ARRI Wide Gamut 4 / LogC4 as output options.
Our ambition is not simply to bring individual colors closer to the ARRI reference. We want to do so while preserving the relationships between them: subtle distinctions, smooth gradients, and predictable behavior across exposure.
That is what makes this project exciting. A convincing camera match should not require you to trade away the integrity of your original image.
Development update · 12 October 2026
A big step forward — and the new tests are still ahead of us
We have made substantial progress with CameraMatchLab. Applying our latest matching techniques to recordings from our existing test archive has produced much stronger overall matches than our earlier approaches. We are extremely excited by what we are seeing, especially because these improvements have been achieved before our new, more advanced test programme has even begun.
Working again with the same recordings has been particularly revealing: the source material has not changed, but our ability to characterise and translate the differences between cameras has. We now evaluate more of the scene alongside the chart, look more closely at the behaviour of dark tones, and assess the match across the available exposures. That has helped us make more convincing choices about the whole image.
The latest MAVO S35 Mk1 work brings a better overall match to the ARRI reference using information from the wider scene. With the Sony FX6, the most significant recent improvement is in the rendering of dark tones, while keeping the chart colour match broadly consistent. These are meaningful steps forward on the material we have, with separate matches for ARRI Legacy and REVEAL.
More materials, more demanding charts, better measurements
Our next round of camera tests will use a much more extensive setup: more advanced charts, a far broader selection of real materials, and more tightly controlled acquisition. Fabrics, pigments, skin, neutral surfaces and saturated colours will give us a richer basis for understanding where cameras agree and where their responses diverge. We will also reserve separate scenes and lighting conditions for validation, so that the new matches are tested beyond the material used to build them.
A central part of this work will be a controlled sensor sweep: a sequence of precisely stepped exposures through which we measure how the recorded signal responds, from the low-signal region towards clipping. Repeated measurements will help us distinguish consistent camera behaviour from noise and capture variation.
We will map that response ourselves from the measurements, rather than base the calibration on an assumed manufacturer log-to-linear conversion. A published log curve describes an encoding; it does not, by itself, characterise the complete response of a particular camera and recording pipeline. Our sweep will establish the relationship between exposure and recorded values for the setup actually being tested, including the chosen recording and decoding path. That measured relationship will guide the calibration and define where the data remain reliable.
These new acquisitions are still ahead of us. The comparisons below come from our older test recordings and already show how far the matching methods have progressed. They also let you examine the differences that remain. Seeing this much progress with the existing material makes us extremely enthusiastic about putting the same techniques to work with a much richer, purpose-built set of measurements.
Explore the camera matches
Compare our matched MAVO S35 Mk1 and Sony FX6 recordings directly with the ARRI reference. Select Legacy or REVEAL, move through the available chart exposures, and inspect the image alongside its RGB parade and vectorscope.
Both sides use the same ARRI viewing transform for the selected pipeline. The scopes measure the original float images; preview scaling and browser display conversion do not change those measurements. These comparisons show how the matches behave in our existing test setup, including the differences that remain.
Open the full CameraMatchLab comparison ↗
To explain our approach, we need to start with something that often gets overlooked: what does a camera actually measure when it records a color?
What a camera measures
To us, a dress is red. A camera has no concept of a “red dress.” It receives light distributed across different wavelengths, and its color channels respond to that light.
Those responses are not universal. One camera’s red channel does not necessarily have the same spectral sensitivity as another camera’s red channel. Light at a particular wavelength can therefore contribute differently to the RGB values recorded by each camera.
At this stage, RGB values are camera-specific measurements, not universal descriptions of color. ¹
For an ordinary reflective surface, the essential relationship involves three things:
The spectrum of the light source × the reflectance of the material × the spectral sensitivity of the camera.
Each channel combines those contributions across the wavelengths to which it responds. The resulting measurements then pass through the camera’s processing pipeline before becoming the image you see.
This distinction matters. The sensor’s physical response, the camera’s color processing, and the image’s log encoding are different parts of the system. Changing one does not automatically reproduce the others. ¹
Metamerism: the chart and the fabric
Imagine a red patch on a color chart and a piece of red fabric. Under a particular light, they look identical to us.
That does not mean they reflect identical spectra.
The chart’s pigments and the fabric’s dyes may absorb and reflect different wavelengths. Those different spectral combinations can nevertheless produce the same perceived color. When different spectra produce matching color values within a particular observer or measurement system, they are called metamers. ²
Now consider two cameras with different spectral sensitivities. A transformation might make their recordings of the chart patch match beautifully, while the fabric still looks different.
The transformation has found a good solution for that particular chart material. It has not necessarily found an equally good solution for every material we would describe as “the same red.”
This is one reason research into camera-to-camera mapping emphasizes the importance of testing real materials alongside standard color-chart patches. ¹
A color chart is an excellent measurement tool. It is not a complete inventory of the visible world.
Lighting changes the camera relationship
Two lights labeled 5600 K can have very different spectral distributions. Their color temperature does not tell you where all their spectral peaks and gaps are.
Those differences can change how materials appear to different cameras. The Academy’s work on the Spectral Similarity Index addresses precisely this issue: evaluating the spectral characteristics of lighting for motion-picture production, rather than relying on color temperature alone. ³
White balance is essential, but it does not solve every spectral mismatch. Making a gray card neutral does not guarantee that every colored material will now reproduce identically across cameras. ¹
So, “these cameras match on this chart under this light” is a useful result. It is not proof that they will match every material under every light.
From measurements to a camera transform
A common approach is to record the same chart or scene with two cameras, measure corresponding colors, and calculate a transformation that maps the source values toward the reference values.
This is data fitting: deriving a mathematical relationship from measured examples. It is a legitimate and useful part of calibration, and there are many possible models for doing it. ⁴
The result might be delivered as a LUT or implemented inside a plugin. Those are delivery mechanisms, not guarantees of a particular calibration method.
A 3D LUT stores sampled transformation values on a grid and interpolates between them. A plugin can use a LUT, mathematical functions, or a combination of methods. The format alone does not tell you whether the underlying camera match is good. ⁵
It would therefore be misleading to say that data fitting is inherently bad, or that every competing LUT or OFX suffers from the same problem.
The important question is what a model is allowed to do to the rest of the image in order to match its measured samples.
Calibration accuracy and overfitting
A sufficiently flexible model can reduce the errors on its calibration samples very effectively. But a lower error on those samples does not automatically mean better behavior elsewhere.
Research into polynomial color correction provides a useful example. Some polynomial models can improve accuracy at the calibration exposure while producing unwanted hue and saturation changes when exposure changes. Alternative formulations were developed specifically to address that behavior. ⁴
Exposure-dependent behaviour and overfitting are distinct issues. Overfitting occurs when a model becomes too closely adapted to the particular data used to construct it; exposure tests examine how that model behaves as the recorded signal changes.
Imagine applying a strong, localized correction to make one difficult chart patch land exactly on its target. What happens to the surrounding colors? Do they remain distinct? Do they still change smoothly? Are small differences being unnecessarily exaggerated or compressed?
These are separate questions from whether the patch itself now matches.
For us, they are central to the quality of a camera transform.
We do not want a better chart score at the expense of a less coherent image.
Our Kinefinity → ARRI Color Match OFX is being developed around a different priority: modeling the relationship between cameras while also controlling how the transformation behaves.
We use measurements. We derive model parameters from those measurements. But reproducing the calibration samples is not our only objective.
Four principles behind our development
Our development approach rests on four principles.
1. Characterize each camera separately
Each supported camera model receives its own characterization. We do not treat “Kinefinity” as one universal response that can be applied unchanged across every model.
Our measurement protocol uses ARRIRAW for the ARRI reference, with a defined development pipeline. Both cameras are manually white-balanced using the same black, gray, and white reference chart. Residual differences in white balance, exposure, and black level are investigated separately.
The purpose is straightforward: a small setup error should not become embedded in the transform as though it were a permanent characteristic of the camera.
We also distinguish between the recorded image pipeline and the sensor itself. Decoding a log curve gives us a linearized representation of that recorded signal. It does not magically turn processed footage back into original sensor measurements.
2. Test across exposure
A single correctly exposed chart frame is not enough for our development protocol.
We use exposure sequences, keeping the scene, stable illumination, lens, and aperture fixed while varying exposure through shutter time.
This lets us examine whether a difference is consistent, whether it depends on signal level, and where noise or clipping makes a measurement unreliable.
Rather than asking only, “Where does this color land?”, we also ask, “How does its relationship to the reference behave as exposure changes?”
The transform should describe more than one favorable test frame.
3. Control the behaviour between measured colours
Our model-selection criteria include more than the error at the measured points. They also address neutral colors, exposure behavior, and the way neighboring colors move through the transformation.
By lower distortion, we do not mean avoiding color changes. A camera match has to change colors.
We mean avoiding unnecessary side effects: abrupt hue changes, unstable saturation, excessive local compression, or exaggerated differences between colors that were originally close together.
A transformation can be mathematically smooth and still bend a color region too aggressively. Smoothness is necessary, but it is not the whole test.
Our preference is therefore not automatically for the most complicated model. It is for a model that explains the relevant camera differences without introducing more freedom than the task requires.
These are design objectives to be tested, not qualities we assume simply because the transform uses formulas.
4. Validate on independent material
Our validation plan separates calibration material from independent test material.
That separation needs to be meaningful. Different pixels from the same chart patch are not a genuinely new material. We want to examine other surfaces, exposures, and lighting conditions.
Synthetic color gradients also have a role. They do not prove that a camera match is accurate, but they can reveal unwanted discontinuities, compression, or abrupt changes in the transformation.
That gives us two complementary tests:
Does the transformed footage approach the reference? And does the transformation handle color responsibly between the measured samples?
Both matter.
Direct formula evaluation in the OFX
Our new OFX is designed to evaluate the camera-matching model directly for each pixel, rather than represent the entire match only through a finite 3D-LUT grid.
A LUT samples a transformation at grid points and estimates intermediate values through interpolation. Direct evaluation avoids that additional grid approximation for the camera-matching stage. ⁵
This does not mean a well-designed LUT necessarily creates visible problems. LUT resolution, interpolation, input encoding, and the underlying transformation all affect the result.
Nor does a formula automatically guarantee a better match.
A precisely calculated mistake is still a mistake.
That is why we are addressing both sides: how the camera relationship is modeled, and how that model is evaluated.
The OFX architecture also lets us keep the camera translation, signal encoding, and color-management handling conceptually separate. Our goal is a tool that fits into a controlled grading pipeline, not a look that only works when everything around it happens to line up.
What an RGB transform can and cannot recover
There is still a fundamental boundary.
Suppose two different spectra produce exactly the same RGB values in the source camera, but different RGB values in the reference camera.
A fixed RGB transformation would receive the same input twice and need to produce two different answers.
Without additional information, it cannot do that. This follows directly from the information ambiguity described by metamerism. ²
This is why overfitting and metamerism must not be confused.
Overfitting is a modeling problem we work to avoid. Missing spectral information is a limitation we cannot simply calculate away.
Likewise, the OFX does not add genuine sensor dynamic range or reconstruct fully clipped channel information. Selecting LogC4 output does not physically turn a Kinefinity sensor into an ALEXA 35 sensor. Encoding, color processing, and image capture are different things.
These limits do not make camera emulation less useful. They define what a good camera transform should do: translate the available information as reliably as possible, without claiming to have recorded information that was never there.
DaVinci Resolve workflows and supported cameras
The Kinefinity → ARRI Color Match OFX is being developed for DaVinci YRGB, DaVinci YRGB Color Managed, and ACES workflows, with the appropriate input and output configuration.
The announced first-release Kinefinity models are TERRA 4K, MAVO S35 MK1 and MK2, MAVO LF MK1 and MK2, MAVO Edge 6K and 8K, and VISTA.
Alongside these Kinefinity models, the Sony F5, Fujifilm X-H2S, Sony FX6, Sony VENICE 2, Nikon ZR and Panasonic LUMIX S1II will be supported from the first release.
We have already tested the LUMIX S1II’s ARRI-certified LogC3 option against our ARRI reference. In our tests, we found the colour match mediocre. LogC3 compatibility alone does not reproduce the full colour response of an ARRI camera. Our camera-specific conversion will deliver a substantially better match, with support for both ARRI Legacy AWG3 / LogC3 and REVEAL AWG4 / LogC4. The more extensive test programme described above will let us refine and validate that conversion across a wider range of materials, lighting conditions and exposures.
The engineering is technical. The purpose is practical: a more dependable starting point for your grade, with less time spent correcting camera differences and more freedom to shape the image.
The interactive comparisons above are our first step in sharing the results. We will add further exposure tests and measurements as the new test programme progresses. That is where the quality of the transformation must ultimately demonstrate itself, beyond the explanation of the method.
We are not building this simply to make the chart match. We are building it for the footage you shoot after the chart leaves the frame.
Development pre-order and release
The development pre-order price is €79 excluding VAT, available until 1 November 2026. Release is scheduled for 14 November 2026, with a regular price of €179 excluding VAT. Future supported camera profiles are included.
