How far apart two normalised cameras actually land

Two normalised cameras land in the same place. Two log formats given the same scene light, each decoded with its own manufacturer's published inverse, disagree by at most 7.5e-13 stops across 21 format pairs and 6,000 scene values each, spanning minus six to plus six stops around middle grey. I took the published encoding formula and the published RGB primaries for seven log formats and nine camera gamuts, transcribed each manufacturer's own inverse function and conversion matrix, validated all of it against numbers those manufacturers print in their own documents, and then computed something I could not find published anywhere.

Zero. Not approximately zero. Zero to the limit of double precision arithmetic, in both tone and colour.

What this cannot show is whether two cameras look the same, because none of it touches sensor spectral response. That distinction runs through everything below.

The tonal residual is zero, and the zero is the point

The computation is simple to describe. Take a scene reflectance, encode it with Sony's published S-Log3 formula, decode it with Sony's published S-Log3 inverse. Do the same with Panasonic's V-Log pair, ARRI's LogC3 and LogC4, Canon Log 3, RED Log3G10 and Nikon N-Log. Compare where the seven land.

Across 21 format pairs and 6,000 scene values each, spanning minus six to plus six stops around middle grey, the worst disagreement is 7.5e-13 stops. That is double precision float rounding and nothing else.

There is no mechanism for it to be otherwise. Each manufacturer's decoding function is the algebraic inverse of its own encoding function, so encode-then-decode hands back the number you started with. The transfer function is a container, and with respect to each other the containers are lossless.

That result is dull on its own and interesting for how much argument it settles. Every claim that S-Log3 crushes something V-Log holds, or that LogC keeps more in the midtones, is a claim about the transfer function. On correctly normalised footage the transfer function contributes nothing, which is worth establishing with numbers rather than assertion. It also fits what falls out of putting the curves on one common code value scale: the ones argued about most are nearly the same curve.

If you want to check a specific pairing rather than read the aggregate, the log reference tool shows where any format places a given scene target, on all three scales at once.

What quantisation actually leaves behind

Real files hold integers, so the honest version includes rounding to a code value. Encode, round to the nearest 10-bit code as a recording does, decode.

Over minus four to plus four stops of middle grey, which covers essentially all photographed material, the worst residual between any two of the seven formats is 0.0416 stops, between Canon Log 3 and Nikon N-Log. The closest pair, Panasonic V-Log and ARRI LogC3, sit at 0.0145. S-Log3, V-Log and LogC3, the three compared most often, are within 0.0212 of each other at worst. At 12 bits every one of those drops by roughly a factor of four, to a worst case of 0.0112 stops.

For scale, 0.04 stops is 2.8 percent in scene linear. Nobody nudges an exposure control by four hundredths of a stop on purpose.

The residual is not spread evenly. Band by band at 10 bits, the worst across all pairs runs 0.1652 stops between minus six and minus five stops, 0.0839 between minus five and minus four, 0.0416 between minus four and minus three, then flattens at 0.014 to 0.015 stops everywhere from minus one upward.

That shape is arithmetic. A curve spending six code values on a stop in the deep toe, which is what Canon Log 3 does at minus six stops, cannot resolve that stop more finely than one sixth of it, and half a code value of rounding is then a real fraction of a stop. In the straight-line region the same curve spends 113 code values per stop and half a code value is nothing.

Put a neutral ramp through the whole pipeline, log encode, 10-bit quantisation, the manufacturer's inverse, its matrix to CIE XYZ, then Rec.709 at 8 bits, and the spread across all seven cameras at every stop from minus six to plus four is zero or one code value out of 255.

The gamut half, and what could be obtained

Colour differences between cameras come mostly from the primaries and the sensor, not the curve, so this is the harder half and where I expected to exclude things. All nine sets of primaries came from manufacturer documents. Canon Cinema Gamut took the longest: the coordinates that circulate come from third-party colour libraries, but Canon does publish them, in a multilingual leaflet on Canon's own download server, publication DIM-1102-000, whose PDF metadata carries Author "Canon Inc." and which is stamped copyright Canon Inc. 2013.

An earlier version of this piece covered eight gamuts and said Fujifilm's primaries were not available from the manufacturer. That was wrong, and the mistake was mine rather than a limit of what Fujifilm publishes. Section 3 of both the F-Log and the F-Log2 data sheet prints F-Gamut, at R 0.70800 0.29200, G 0.17000 0.79700, B 0.13100 0.04600 on a D65 white point, and has done all along. Both PDFs defeat a naive text extractor, which is the likely origin of the error. F-Gamut is now folded in, and no figure computed for the original eight moved.

Five of those gamuts, from four manufacturers, also publish a conversion matrix, which turns the derivation into something checkable rather than merely plausible. The decisive case is ARRI Wide Gamut 4, where ARRI prints its primaries to four decimal places and its matrix to eighteen. The matrix derived here from the four-place primaries reproduces ARRI's eighteen-place matrix to 1.11e-16, machine epsilon. That is not agreement within tolerance, it is the same calculation. Panasonic, ARRI Wide Gamut 3 and RED agree to about 5e-07, which is the six-decimal precision they printed their own matrices to: 4.70e-07, 4.51e-07 and, loosest of the three, 8.25e-07. Sony and Fujifilm are the two gaps, publishing primaries and no matrix, so those rows rest on a method confirmed against the manufacturers who do publish one rather than against Sony's or Fujifilm's own. F-Gamut has Sony's footing here, not ARRI's, and it is worth saying so plainly.

Adding Fujifilm turned out to add a name rather than a shape. Both data sheets specify F-Gamut as ITU-R BT.2020 and print BT.2020's primaries, which are the same coordinates Nikon prints for N-Log. The two derived matrices are therefore identical to the last bit, the nine gamuts span eight distinct triangles, and reading Fujifilm material as N-Log's gamut, or the reverse, costs exactly zero in colour. It is the only pair in the table with that property. The transfer functions still differ, so if a Fujifilm and a Nikon body will not reconcile, the gamut tag is not what is wrong.

The gamut residual, encoding a colour into a camera gamut and decoding it back with that manufacturer's own matrix, is below 1e-12 — 1.3e-13 across twelve reference colours and nine gamuts, in the implementation that re-checks it on every build. A figure that small is a bound rather than a measurement, and it is worth saying why: the same computation in Python prints 8.16e-14 from linear algebra identical to this one down to the last bit, because the two runtimes round the cube root inside CIELAB differently in that last bit. The matrices are invertible, so correct normalisation loses nothing here either. Both halves return zero, which relocates the question to what happens when normalisation goes wrong. There the numbers are large.

Decode footage recorded in one log format with a different format's inverse and the median error at middle grey across the 42 ordered pairs is 0.853 stops, roughly twenty times the largest quantisation residual. The extremes are worth stating exactly rather than as a rough band. The worst pairing is V-Log read as LogC4 at 2.407 stops, about fifty-eight times quantisation, with the reverse and the S-Log3 confusions close behind. The mildest is Log3G10 read as Canon Log 3 at 0.123 stops, which is still about three times quantisation. So even the gentlest mix-up is larger than everything correct normalisation leaves behind, which is the arithmetic behind why a shot match that will not settle so often turns out to be an input tag rather than a grade.

Read footage as the wrong gamut and the mean chromaticity shift over my reference set, across the seven camera-native gamuts, runs from 0.0052 to 0.0407 in CIE 1976 u'v', median 0.0230. One comparator is worth keeping: the u'v' distance from the Rec.709 red primary to the DCI-P3 red primary is 0.0457. A typical gamut mis-tag moves colour about half as far as the entire gap between Rec.709 and P3, and the worst ones move it that whole distance.

The error is zero on a grey card and grows with saturation

This is the useful shape of the gamut result. The same mis-tag applied to a red at falling saturation, all at one luminance, averaged over the 56 ordered pairs of the eight distinct triangles:

saturation	mean du'v'	worst du'v'
0 percent	0.0000	0.0000
25 percent	0.0019	0.0043
50 percent	0.0050	0.0118
75 percent	0.0112	0.0279
100 percent	0.0312	0.0913

At zero saturation the error is zero for every pair, because all nine gamuts are defined on the same D65 white point, 0.3127 and 0.3290, every one of them a number its own manufacturer printed. A neutral is neutral in all of them. Exactly so from the primaries; 2e-07 if you run it through the manufacturers' own matrices, which are printed to six decimals and imply a white point that far from the D65 the same documents state. That is their rounding, four orders below the next row of the table, and not a difference between the gamuts.

Which explains a familiar experience. A mis-tagged colour space survives the grey card, survives the face, then falls apart on a practical light or a saturated costume. The error is not hiding in the first two. It is absent there, and it arrives with saturation.

What none of this can reach

Everything above is arithmetic on encoding specifications, and three things that decide how two cameras actually look are not in any of it.

The first is sensor spectral sensitivity. A camera's three channels respond to distributions of wavelength that are not the CIE colour matching functions and are not the same between manufacturers, so two cameras pointed at one object under one light do not produce the same XYZ. They are not measuring the same quantity. Two surfaces that look identical to your eye can read differently on one camera and identically on another, which is why a tungsten practical, a sodium street lamp, an LED panel and a dyed fabric are the classic places two bodies diverge and no matrix rescues them. An encoding gamut is a container the manufacturer chose for numbers the sensor already produced.

The second is the sensor stack. Filter array dyes, microlenses, the infrared cut filter and the demosaic all move values before any encoding happens, none of it published as a matrix, and it varies between bodies from one manufacturer.

The third is each manufacturer's rendering intent. The display transform sitting on top of the log encoding is an aesthetic decision, and ARRI's rendering and Sony's rendering of one scene differ on purpose. These specifications describe the scene-referred encoding underneath that layer, not the layer.

So two cameras can be mathematically aligned, in the strict sense that the residual computed here is zero, and still not look the same. Correct normalisation is a precondition for matching, not the act of matching. This is why cameras that will not match usually need both a transform fix and an eye, and why reconciling Nikon bodies with other cameras starts with the transform and does not end there.

What it means for how you spend your time

The normalisation pass is binary and cheap. Either the input tag is right, in which case you carry a residual around 0.04 stops and one 8-bit code value, or it is wrong, in which case you carry between 0.17 and 2.4 stops and a colour shift comparable to the gap between Rec.709 and P3. There is no middle, and nothing is gained by fiddling with a correct transform.

So verify it once and stop. Check the tag, check a neutral, check a saturated element, move on. Time spent auditioning transforms against each other goes on the half arithmetic already closed, whether you are doing a straight S-Log3 to Rec.709 conversion, reconciling log against already-baked clips, or working out why CST, ACES and LUT paths disagree on one shot.

Spend what you save on the eyeball pass. Skin against skin, the practical in the corner, the wall behind the talent. This study is quiet evidence for why that work is not arithmetic: the maths converges exactly and two cameras still do not look the same, so whatever separates them was never in the maths.

Frequently asked questions

If the residual is zero, why do my cameras still look different?

Because the residual computed here is between encoding specifications, not between cameras. Two sensors record different values for the same object, since their spectral sensitivities differ from each other and from the human observer. Add the filter array, the infrared cut filter and each manufacturer's rendering intent, and you have three differences no published transfer function or gamut matrix describes.

Is 0.04 stops of quantisation residual worth worrying about?

Not in the midtones. It is 2.8 percent in scene linear, below any adjustment made deliberately. It is worth knowing six stops under middle grey, where the worst pairing reaches 0.165 stops, because curves with steep toes spend very few code values on the deepest stops. That is an exposure concern rather than a grading one: on those formats underexposure costs more, so protect the shadows in camera.

Why does a wrong colour space tag look fine on a grey card?

Because all nine camera gamuts here are defined on the same D65 white point, so a neutral encodes and decodes identically no matter which gamut you claim. The error scales with saturation, from zero at neutral to a mean shift of 0.0312 u'v' at full saturation. Checking a mis-tagged clip on a grey card tells you nothing. Check a saturated element.

What happens if I apply an S-Log3 LUT to V-Log footage?

It reads slightly bright, and the amount depends on where you look — which is the part that surprises people, because a wrong LUT feels like it should shift everything by the same amount.

Encode a scene through V-Log, decode it through S-Log3's published inverse, and the recovered value is 0.174 stops brighter than the truth at an 18 percent grey card. In the deep shadows, around 2 percent reflectance, that grows to 0.378 stops. Up at a 90 percent white card it shrinks to 0.049 stops. The error is largest exactly where you have the least signal to spare and smallest where you have the most, so the visible symptom is lifted, slightly milky shadows rather than a uniform exposure offset. Reverse the mistake — S-Log3 footage decoded as V-Log — and it goes the other way at a similar size: 0.185 stops dark at grey, 0.419 in the shadows.

Do not carry that shape to other pairs, because it does not generalise and the exception is instructive. Fujifilm's two curves run the opposite way: F-Log2 decoded as F-Log is 0.182 stops out in the shadows, 0.740 at grey and 1.315 at a 90 percent white card, growing upward rather than downward. The difference is what each pair disagrees about. S-Log3 and V-Log cover almost the same range and differ mainly in where they put black, which is a shadow-end disagreement. F-Log2 exists to fit three more stops of highlight into the same container than F-Log, so its disagreement with F-Log is a highlight-end one and widens as you climb. Whether a wrong tag shows up first in your shadows or your highlights depends on which pair you got wrong, so check the region the two formats actually differ about.

The more useful context is that this particular pair is unusually forgiving. Across all the pairings of the nine formats, the median absolute mis-tag error at middle grey is 0.830 stops. S-Log3 and V-Log land inside a quarter of that. This is the arithmetic behind the folklore that the two are "close enough" — the folklore is right about these two and badly wrong as a general rule, and nothing about the footage tells you which case you are in.

Two practical consequences. A fifth of a stop at grey is small enough to survive a casual look and small enough to hide inside an ordinary exposure correction, so this mistake tends to be discovered late, after the grade has been built on top of it. And since the tonal error is smallest at the top of the range and the gamut error is zero at neutral, a grey card will not reveal either half of the problem — you need a saturated element for the gamut half and a shadow region for the curve half. You can work any pairing in the set with the log reference tool.

How many stops off is it if I interpret LogC3 footage as LogC4?

1.891 stops, and it reads brighter. Reverse the mistake — LogC4 footage decoded as LogC3 — and it is 1.660 stops darker. Both figures are at an 18 percent grey card, and both are for LogC3 at EI 800. That qualifier has to travel with the number: ARRI publishes eleven LogC3 parameter sets from EI 160 to EI 1600, and the implementation here covers EI 800, ARRI's default. LogC4 carries no such dependency, which was one of the stated reasons for the redesign.

The mechanism is a single number. LogC3 at EI 800 writes middle grey at code 400 and LogC4 writes it at 284.8, so LogC3 footage arrives on LogC4's scale sitting 115.2 code values above where LogC4 expects grey. Push that gap through LogC4's own published inverse and it is 1.891 stops of light. Push the same 115.2 the other way through LogC3's inverse and it is 1.660, because LogC4 spends about 59 code values on the stop above its middle grey while LogC3 spends about 71 on the stop below its. One gap, two prices, set by whichever curve is doing the reading.

The answer in circulation is much smaller and points the wrong way, and its error is the one behind getting 425 for S-Log3 instead of 325 one level up: a code value handled as though it were a quantity of light. The method is to divide the two middle-grey percentages — 39 percent for LogC3 against 32 percent for LogC4 — get 1.219, and read that as an exposure ratio. It is not one. Code value is a logarithmic quantity, so a ratio of code values carries no exposure meaning and does not convert into one; the only route is back through the curve. Taken as light, 1.219 would be 0.285 of a stop, about a seventh of the real answer.

Direction is the cheaper check and it needs no arithmetic at all: if the footage's own curve writes middle grey higher than the receiving curve does, the footage must read bright. 400 against 285, so bright, necessarily. The circulating answer has it dark.

Two other tells that it was never checked against anything. The 32 percent is wrong — ARRI publishes 0.2784 for middle grey, which is code 285, or 27.84 percent full range — and the same answer goes on to say "approximately 27 percent" a sentence or two later, contradicting itself inside one paragraph. Our figure for LogC3 at EI 800 is 39.10 percent, so only one of the two inputs was right to begin with.

How many stops off is Canon Log 3 graded as S-Log3?

0.941 stops dark. The reverse — S-Log3 footage read as Canon Log 3 — is 0.764 stops bright. Both at an 18 percent grey card.

This pairing is a different kind of gap from the others here. There is no wrong answer to correct, because there is no answer: asked directly, search declines and refers you to Canon's documentation and Sony's. What makes that worth recording is that both endpoints are public and are quoted correctly in the same breath as the refusal — Canon Log 3 puts middle grey at about 32.5 on a legal IRE scale, which our implementation computes as 32.80, and S-Log3 puts it at 41. Both facts are already on the web. Combining them is the step that does not happen, and it is the step that matters, because it is not a subtraction: it means pushing one manufacturer's code value through the other manufacturer's published inverse.

Doing that gives the two figures above. Canon Log 3 writes middle grey at code 351.3 and S-Log3 writes it at 420, so Canon footage arrives 68.7 code values below where S-Log3 expects grey, and S-Log3 spends 72.89 code values on the stop below its own grey — hence 0.941 stops dark. Backwards, that same 68.7 lands on Canon Log 3, which spends about 91 code values on the stop above its grey, so it is worth only 0.764. The steeper curve charges less for the same confusion.

A second trap sits underneath the 351.3 and is worth knowing before reusing it. Canon labels its input axis "Scene Linear %", not reflectance, and normalises it so that 100 percent is a 90 percent white card. That puts an 18 percent grey card at 0.20 on Canon's axis rather than 0.18. Read the axis as reflectance instead and middle grey computes as code 339 rather than 351, and every figure downstream of it moves with it.

Does this mean the choice of log format does not matter?

For matching two correctly normalised cameras, the transfer function is not the variable. It matters elsewhere: how finely the deep shadows are quantised, how much range fits in the container, and how much latitude you have before banding shows. Those are separate from whether two formats agree once decoded properly.

Was any gamut data unobtainable?

All nine sets of primaries came from manufacturer documents. One gap is worth stating: Sony and Fujifilm publish primaries but no conversion matrix, so those matrices are derived by a method validated against the four manufacturers who do publish one rather than against Sony's or Fujifilm's own. Blackmagic, Apple and DJI are absent because their primaries are not available from a citable manufacturer URL, and rebuilding them from third-party sources would have put unverifiable numbers into a verified set. Fujifilm was on that list in the first version of this article and should not have been, since F-Gamut is published in section 3 of both Fujifilm data sheets. That gap is now closed, and closing it left every figure for the original eight unchanged.

Sources

Sony, Technical Summary for S-Gamut3.Cine/S-Log3 and S-Gamut3/S-Log3: https://pro.sony/s3/cms-static-content/uploadfile/06/1237494271406.pdf

Panasonic, V-Log/V-Gamut Reference Manual Rev.1.0, 28 November 2014: https://pro-av.panasonic.net/en/cinema_camera_varicam_eva/support/pdf/VARICAM_V-Log_V-Gamut.pdf

Canon, Canon Log Gamma Curves white paper, 1 November 2018: https://downloads.canon.com/nw/learn/white-papers/cinema-eos/white-paper-canon-log-gamma-curves.pdf

Canon Inc., Color Gamut Conversion for DCI-P3+ and Cinema Gamut, publication DIM-1102-000, 2013: http://gdlp01.c-wss.com/gds/8/0200003438/01/colorgamutinfo-dim1102.pdf

ARRI, ALEXA Log C Curve, Usage in VFX, 9 March 2017: https://www.arri.com/resource/blob/31918/66f56e6abb6e5b6553929edf9aa7483e/2017-03-alexa-logc-curve-in-vfx-data.pdf

ARRI, ARRI LogC4 Logarithmic Color Space Specification, 23 January 2025: https://www.arri.com/resource/blob/278790/dc29f7399c1dc9553d329e27f1409a89/2022-05-arri-logc4-specification-data.pdf

RED Digital Cinema, White Paper on REDWideGamutRGB and Log3G10, form 915-0187 Rev C: https://docs.red.com/955-0187/PDF/915-0187%20Rev-C%20%20%20RED%20OPS,%20White%20Paper%20on%20REDWideGamutRGB%20and%20Log3G10.pdf

Nikon, N-Log Specification Document v1.0.0, 1 September 2018: https://download.nikonimglib.com/archive3/hDCmK00m9JDI03RPruD74xpoU905/N-Log_Specification_(En)01.pdf

Fujifilm, F-Log Data Sheet Ver.1.1: https://dl.fujifilm-x.com/support/lut/F-Log_DataSheet_E_Ver.1.1.pdf

Fujifilm, F-Log2 Data Sheet Ver.1.1: https://dl.fujifilm-x.com/technical-data/F-Log2_DataSheet_E_Ver.1.1.pdf

Every number above is quoted from one of those documents or computed from a formula or matrix in one of them, and 77 validation checks against the manufacturers' own published values all pass. Two flaws found along the way are worth flagging. Sony's printed S-Log3 inverse has a typographical error, "out +" where "out =" is meant, obvious from context and confirmed by the round trip. And Nikon's specification does not round trip everywhere: the forward function switches branch at reflectance 0.328 while the inverse switches at code 452, which are not the same point, leaving a window 0.002 stops wide where Nikon's published pair disagrees with itself by up to 0.0013 stops. Neither changes anything here, and both are the kind of thing you only find by checking.