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.
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 models are TERRA 4K, MAVO S35 MK1 and MK2, MAVO LF MK1 and MK2, MAVO Edge 6K and 8K, and VISTA.
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.
Before release, we plan to publish comparisons, exposure tests, and measurements. 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.
