The parametric log transform: one equation, every camera

A timeline arrives with footage from three cameras. The A-cam shot ARRI LogC4. B-cam was a Sony VENICE in S-Log3. The drone sent back RED Log3G10. Three different log encodings, three different white papers, three sets of transfer function equations that look nothing alike.

Except they are alike. They are the same equation with different constants.

That claim sounds reductive, but it holds up under scrutiny. Every major cinema log encoding, from every major manufacturer, is an instance of a single parametric form: a piecewise function with a logarithmic segment, a linear tail near black, and a handful of published coefficients that fully define the curve. Knowing this changes how conversions work, how new cameras get supported, and how much of “camera colour science” is actually just six numbers in a table.

The shape of a log curve

Every cinema log encoding does the same job. The camera sensor captures light linearly, meaning twice the photons produce twice the signal. But the human eye doesn’t work that way. Perception is roughly logarithmic: the difference between 1 and 2 candles feels the same as the difference between 100 and 200. Storing linear sensor data directly would waste most of the code values on highlights that all look “bright” and starve the shadows where banding actually matters.

A log curve redistributes code values so that each photographic stop gets a roughly equal share. That’s why log footage looks flat. It’s not damaged or wrong. It’s been packed for efficient transport, and it needs a known transform to unpack it for viewing.

The question is: what specific curve does the packing?

One equation to rule them all

OpenColorIO, the open-source colour management framework used in most professional post-production software, defines a transform called LogCameraTransform. It implements what the OCIO documentation calls a “parametric Lin-to-Log / Log-to-Lin” model. The core equation for the log segment (above a linear cutoff) is:

LogValue = LogSideSlope * log10(LinSideSlope * linear + LinSideOffset) + LogSideOffset

And below the cutoff, a simple linear segment takes over:

LogValue = LinearSlope * linear + LinearOffset

That’s it. Five coefficients for the logarithmic region (LogSideSlope, LogSideOffset, LinSideSlope, LinSideOffset, and base), two for the linear tail (LinearSlope, LinearOffset), and a cutoff point where one region hands off to the other.

Every major camera manufacturer’s log curve is an instance of this parametric form. Different constants, identical structure. ARRI LogC4 is this equation with one set of numbers. Sony S-Log3 is this equation with another set. They look like proprietary formats. They are published constants for a shared mathematical form.

What each coefficient does

Understanding the coefficients turns the equation from abstract notation into physical intuition.

LinSideSlope scales the linear input before the logarithm. It controls the overall gain applied to the scene-linear data. A higher value stretches the input range that gets mapped into the log curve, effectively determining how many stops of dynamic range the encoding can represent. ARRI’s LogC4, designed for a sensor with over 17 stops of range, uses a different LinSideSlope than Sony’s S-Log3, which targets around 15 stops.

LinSideOffset shifts the linear input before the log is taken. This is the term that handles what happens near zero and below. Real camera sensors have noise floors and can produce negative values (through black level subtraction). The offset ensures the argument to the logarithm stays positive, preventing the curve from heading toward negative infinity. It also controls where “scene linear zero” maps in the output.

LogSideSlope scales the output of the logarithm. It determines the steepness of the curve in the code value domain. A steeper LogSideSlope means each stop of exposure occupies more code values, giving finer gradation per stop but covering fewer total stops within the 0 to 1 output range.

LogSideOffset shifts the entire log output up or down. This positions the curve vertically, controlling where middle grey lands in the code value range. Most log encodings place 18% grey somewhere between 0.38 and 0.42 in normalised code values, but each manufacturer chose slightly differently. The LogSideOffset is how they did it.

LinearSlope and LinearOffset define the straight-line segment near black. Below a certain exposure level, the logarithmic curve would curve too steeply, creating issues with noise amplification and quantisation. The linear segment replaces the log curve in this region with a gentle straight line. The slope and offset are chosen so that the two segments meet with matched value and matched first derivative, producing a smooth, continuous function with no visible kink.

The parameters, side by side

Camera log curves

Parametric log encoding — published coefficients

Here are the actual published constants for four widely used log encodings, expressed as OCIO LogCameraTransform parameters:

Parameter	ARRI LogC4	Sony S-Log3	RED Log3G10	Canon C-Log2
LogSideSlope	0.0647954	0.255958	0.224282	0.092864
LogSideOffset	0.5515593	0.410557	0.386053	0.556929
LinSideSlope	14.0	5.26316	155.975327	87.099375
LinSideOffset	0.0928	0.01125	2.0	1.0
LinearSlope	6.359295	6.62194	0.01	4.889494
LinearOffset	0.092778	0.037584	0.0	0.133337
Lin break	0.01	0.01125	0.000064	0.0001
Log break	0.1574	0.1673	0.0928	0.1350

These numbers are not secrets. ARRI publishes LogC4’s specification. Sony’s S-Log3 white paper includes the full transfer function. RED released Log3G10’s coefficients. Canon documents C-Log2 in their camera SDKs. OCIO’s built-in configs collect them all in one place, normalised to the same parametric form.

Look at the table and some patterns emerge. ARRI’s LogSideSlope is the smallest, reflecting LogC4’s design for very high dynamic range (the curve is shallower per stop, but covers more stops). RED’s LinSideSlope is enormous because Log3G10 normalises its linear input differently, using a larger scale factor before the log. Sony’s LinearSlope is steeper than the others, meaning S-Log3’s linear-to-log transition happens with a slightly more aggressive shadow segment.

But these are differences of degree, not of kind. Every camera manufacturer solved the same optimisation problem: how to distribute a finite number of code values across a wide dynamic range in a way that minimises visible quantisation at every exposure level. They arrived at the same mathematical form and chose constants tuned to their sensor characteristics.

The linear tail

The linear segment near black deserves its own moment. It exists because of a practical problem: the logarithm of zero is negative infinity.

If you trace the pure log curve down toward zero exposure, the output value drops without bound. In a real system with finite bit depth, this means the lowest exposure levels would demand an absurd number of code values. Worse, sensor noise in the deep shadows would be amplified by the steepening curve, turning subtle noise into visible banding.

The solution is to define a “linear break point” below which the log curve switches to a straight line. The linear segment is gentler, gives the shadows enough code values to stay clean, and joins the log segment smoothly. The break point itself varies by manufacturer. ARRI’s LogC4 transitions at about 0.01 in scene-linear. RED’s Log3G10 breaks much lower, at 0.000064. That difference reflects a design choice about how much deep shadow detail the encoding prioritises.

Getting the break point wrong (or ignoring it entirely) is a common source of errors in hand-written log transforms. The parametric model handles it automatically. Define the six coefficients and the break point, and the math guarantees continuity.

Why this matters in practice

When you understand that all these log curves share a common form, several things become clear.

First, converting between log encodings is not a lookup table problem. It’s an analytic inverse. You can go from S-Log3 to scene-linear and then from scene-linear to LogC4 with exact math. No sampling grid, no interpolation error, no 33-point cube approximation. The inverse of the parametric log equation is another parametric log equation. OCIO does this by default when you chain LogCameraTransform operations.

Second, when a new camera comes out with a new log curve, you don’t need to wait for someone to ship a LUT pack. You need six numbers and a break point. If the manufacturer publishes a white paper with the transfer function (and they almost always do), you can extract the OCIO parameters directly. The curve is fully defined.

Third, comparing cameras becomes less mystical. The difference between LogC4 and S-Log3 is not “ARRI colour science versus Sony colour science.” It’s a different LinSideSlope, a different LogSideOffset, a different break point. You can see exactly where the curves diverge and by how much. The engineering is transparent. The same transparency applies to the colour space matrices that sit alongside these transfer functions.

And fourth, custom log encodings for VFX pipelines or virtual production become straightforward. If your LED wall needs a specific transfer function to match the response of a particular camera, you build it by choosing six parameters, not by sculpting a LUT by eye.

They published the numbers

This is, in some ways, the most remarkable part. Camera manufacturers could have kept their log curves as opaque black boxes. Some older encodings were exactly that: undocumented curves that you had to reverse-engineer from test charts and reference images.

But the major manufacturers chose to publish. ARRI’s LogC4 specification is a free PDF. Sony’s S-Log3 white paper walks through the math. RED’s IPP2 documentation includes Log3G10’s full definition. Canon, Panasonic, and Blackmagic have all followed suit. The industry converged not just on a shared mathematical form, but on a culture of documenting it openly.

OCIO’s LogCameraTransform is the practical expression of that convergence. It says: here is the general equation, and here are the constants for every camera we know about. If your camera isn’t in the list, give us the constants and it will be.

The next time you see “S-Log3” in a dropdown menu and feel a flicker of uncertainty about what that means, remember: it’s five coefficients, a linear tail, and a break point. The same five coefficients, linear tail, and break point as every other camera in the list. The equation is the same. Only the numbers change.

References

ARRI. “ARRI LogC4 Logarithmic Color Space: Specification.” ARRI Technical Documentation, 2022.
Sony. “Technical Summary for S-Gamut3.Cine/S-Log3 and S-Gamut3/S-Log3.” Sony Professional White Paper, 2014.
RED Digital Cinema. “Image Processing Pipeline (IPP2).” RED Technical Documentation, 2017.
Canon. “Canon Log Transfer Characteristic.” Canon Cinema EOS White Paper, 2020.
OpenColorIO Contributors. “LogCameraTransform.” OpenColorIO Documentation, Academy Software Foundation. https://opencolorio.readthedocs.io/
OpenColorIO Contributors. “Built-in Transforms: Camera Log Encodings.” OCIO v2 Configuration Reference. https://opencolorio.readthedocs.io/
Selan, Jeremy. “Cinematic Color: From Your Monitor to the Big Screen.” VES Handbook of Visual Effects, 2012.