Which log formats survive 8-bit recording

Record a log curve in 8 bits and one recorded code moves the finished picture further than one code of the file you deliver it in — everywhere above about three and a half stops under middle grey, which is everywhere a viewer looks. Record the same curve in 10 bits and it does not, bar the last stop before the conversion clips. Your recording, not your deliverable, is setting the size of the steps in that sky.

That settles the argument without appealing to anyone's eye. But "never shoot log in 8-bit" is still the wrong shape of answer, because the nine formats are not one thing: across the mids they span a factor of 1.71 between best and worst, four stops down they span 2.53, and the order changes. Canon Log 3 is the second most 8-bit tolerant curve of the nine in the mids and the least tolerant of all nine in the shadows.

We can compute this because we hold the curves: nine manufacturer-published log encodings, each validated against that manufacturer's own printed anchors, published as a log format code value reference. The script behind every number below is scripts/eight-bit-study.mjs in our repository; running it reproduces this article.

What was computed, and what was assumed

The recording. A log curve's output is a number between 0 and 1 that a recorder quantises to integers. How coarse that ladder is per stop depends on the curve and the bit depth alone.

The conversion. Banding belongs to the picture a file becomes, not to the file, so each recorded step is pushed through a normalisation with no free parameters and no proprietary look: scene reflectance into the ITU-R BT.709-6 transfer function, whose item 1.2 prints V = 1.099 L^0.45 − 0.099 above L = 0.018 and V = 4.500 L below it, then onto a BT.1886 reference display, exponent 2.40. That puts an 18% grey card on Rec.709 signal 0.409 and applies no tone mapping — which BT.709-6's own footnote flags as the simplification it is.

The visibility threshold, which is a judgement and is labelled as one. Report ITU-R BT.2246-8 sets the criterion in exactly these terms — the step in displayed luminance between consecutive codes should stay under the minimum detectable contrast — and puts that minimum, as a Weber ratio, "between 1/50 and 1/100". So 1% is strict below and 2% lenient. Those two numbers are theirs and are an assumption; the arithmetic is ours. The report adds that the ratio "increases below and above certain luminances", which matters later.

What the bit depth costs, and what the range setting costs on top

Local code values per stop at an 18% grey card. BT.709-6 item 4.6 sets 8-bit black at 16 and nominal peak at 235, so a limited-range 8-bit recording has 219 quantisation intervals, not 255.

Two separate decisions are hiding in that table, and it is worth pulling them apart rather than blaming both on the bit depth.

Bit depth alone costs almost exactly four, whichever range convention you hold fixed. Full to full is 1023/255 = 4.012. Limited to limited is 876/219 = 4.000, because BT.709-6 puts 10-bit black at 64 and peak at 940. So the familiar "divide by four" is right, and our own banding after grading and export is right to use it — its 8-bit shadow budgets are full-range figures and they check out.

The range setting costs a further 16% on its own. At 8 bits, 255 intervals against 219 is a ratio of 1.164, and that is a menu choice on cameras that offer data levels, not a consequence of the bit depth at all.

Only if you change both at once — a 10-bit full-range reference against an 8-bit limited-range recording — do you get 1023/219 = 4.671. That figure is real and it is the one many people actually live with, but it is two decisions, and only one of them is the bit depth.

Higher up each curve these converge on the straight-line slopes in how log formats allocate code values, reproducing them at the top of each curve to within a code value.

What one recorded code does to the picture

The conversion treats all nine alike: middle grey lands on display code 104 of 255 at 11.70% of peak luminance, two stops under on code 44 at 1.49%, four stops under on code 13 at 0.078%, and it clips at +2.474 stops. Its local gamma runs from 1.206 at +2 stops to a flat 2.400 below −3.322 stops, where BT.709's linear segment takes over and magnifies everything beneath it.

Each cell is how many 8-bit display code values, out of 255, separate two adjacent recorded codes after conversion. Above 1.00 means plateaus that wide.

In 10 bits that column at middle grey runs 0.417 (F-Log) to 0.708 (LogC4) — every one under half an output code. Scanning finely gives the crossings: in 10 bits all nine stay under one output code from six stops under grey up to between +1.40 and +2.46, where the conversion clips. In 8-bit full range five of the nine manage it only below about −3.5 to −4.0 stops, Log3G10 only below −5.22, and Canon Log 3, LogC4 and N-Log never do. Between −4 and −3 stops the picture displays at 0.08% to 0.40% of peak white — so the one region where an 8-bit log recording is finer than its own deliverable is the region nobody sees into.

Where 8-bit runs out first

Display codes say what is in the file; whether it shows is a contrast question. The same measurement as the Weber step in displayed luminance, 8-bit full range:

"Knee" is the stop at which the step has doubled from its straight-line value — the honest answer to where 8-bit runs out on that curve. "Half-slope" is where the curve's own code values per stop have halved, computed from the curve alone, and it drives the knee.

In the mids and above, all nine sit outside the lenient threshold in 8 bits and inside it in 10 bits. At an 18% grey card the 8-bit steps run 3.91% to 6.70% — two to three times the lenient 2%, four to seven times the strict 1%. The same curves in 10 bits give 0.963% to 1.637%. That comparison is the case for 10-bit, whichever curve you shot.

In the deep shadows the numbers are enormous and mean less than they look. S-Log3 six stops under grey gives a 58% luminance step and Canon Log 3 gives 226% — but that sample displays at 0.0028% of peak white, and BT.2246-8's qualification applies exactly there. A 58% step at three thousandths of a percent of peak is not the same claim as a 4% step at mid grey, and this study does not pretend it is.

Together they invert the usual framing. The widest plateaus in the file sit in the brightest region — a sky at +2 stops carries the largest steps anywhere measurable — while the widest steps relative to the code budget sit in the shadows, where the eye can least resolve them. Both coincide in the upper mids and highlights, exactly where 8-bit log banding gets reported: skies, walls, the falloff behind an interview subject. The shadow code-value budget, which most of this discussion measures, is not where the failure shows.

The ranking, twice

Most to least tolerant at 18% grey: F-Log 3.91%, Canon Log 3 4.47%, N-Log 4.59%, S-Log3 5.11%, LogC3 5.28%, F-Log2 and V-Log 5.38%, Log3G10 6.04%, LogC4 6.70% — a spread of 1.71. At four stops under: F-Log 16.78%, V-Log 17.01%, S-Log3 17.08%, LogC3 17.19%, F-Log2 19.33%, Log3G10 25.98%, N-Log 30.94%, LogC4 40.45%, Canon Log 3 42.47% — a spread of 2.53.

F-Log wins both for the same reason it has the least highlight headroom of the nine: a curve covering only 5.34 stops above middle grey can describe each finely. LogC4 is last in the mids for the mirror reason, 11.35 stops out of the same container. The formats that tolerate 8 bits best are the short-range ones, and the two that tolerate it worst are curves you would struggle to find in an 8-bit file at all.

Canon Log 3 and N-Log are the pair worth knowing: second and third in the mids, ninth and seventh in the shadows, half-slope points at −1.81 and −1.75 stops against −4.45 for S-Log3. They buy generous mids by compressing deep shadows harder than anyone, and in 8 bits that bill arrives about two and a half stops higher up the frame than on a Sony, Panasonic or ARRI curve — the arithmetic behind the advice in how to grade C-Log3 footage and how to grade N-Log footage to get exposure right in camera.

Limited range costs a flat 1.164 on every format, 255/219, with no ranking change. And to check none of this is an artefact of the transform it was measured through, the script re-runs everything on a pure power-law chain with no linear segment and no offset: the mid-region order comes back identical and the spread moves from 1.713 to 1.711. The ranking is a property of the curves.

What this does not say

It says nothing about noise: quantisation and sensor noise are different failures, and grain dithers these steps for free, which is why a textured frame hides what a clear sky exposes — see noise when grading log footage. It measures luma only; chroma in a 4:2:0 file is a second axis this arithmetic does not touch.

It also measures a bare normalisation, not a grade. A contrast curve multiplies these steps by its own local slope, by definition; a linear exposure lift does the opposite, taking S-Log3's codes at −4 stops from 17.08% to 11.69% when lifted two stops, because the lift moves them off BT.709's steep linear segment. Above +2.474 stops it measures nothing, the conversion having clipped; a show LUT restores those stops by compressing them, which only makes the steps smaller.

Where Leumos fits

Leumos is our own product, a browser color grading studio, and none of this changes what it can do for an 8-bit file: code values the camera never wrote cannot be recovered downstream by anything. What it does do is carry named input transforms for the formats it supports, so normalisation is a menu choice rather than a hunt for a LUT; match a shot to a still-image reference; and render finished video out rather than grade data or LUTs, keeping the integer round trips few. Its halation and film-texture stages break up plateaus the way grain always has — concealment, not repair. If your source is 8-bit log, the fix was at the camera.

Frequently asked questions

Can you shoot log on an 8-bit camera?

You can, and the arithmetic says what it costs. At an 18% grey card one recorded code moves the picture by 3.91% to 6.70% of its luminance, against a minimum detectable contrast Report ITU-R BT.2246-8 puts between 1% and 2%. The same curves in 10 bits give 0.963% to 1.637%. 8-bit log works on textured, well-exposed material and fails on large smooth gradients.

Which log format holds up best in 8 bits?

Fujifilm F-Log, on both measures: 3.91% at middle grey and 16.78% four stops down, best of the nine each time. It wins by encoding the shortest scene range, 5.34 stops above middle grey. LogC4 is last in the mids at 6.70% for the opposite reason, and Canon Log 3 last in the shadows at 42.47%.

Does the full range versus limited range setting matter?

Yes, and it is the cheapest improvement available. BT.709-6 puts 8-bit black at 16 and nominal peak at 235, so limited range gives 219 quantisation intervals against 255 — a flat 1.164 penalty on every format, changed with one menu setting where a camera offers the choice.

Why does my 8-bit log sky band when the shadows look fine?

Because the widest plateaus in the delivered file sit in the brightest region. Two stops over middle grey, adjacent recorded codes land 2.91 to 4.79 display code values apart, against 0.60 to 2.05 at six stops under. The shadows carry a larger step relative to their code budget, but display at a fraction of a percent of peak white, where the eye is least able to resolve it.

Is 10-bit log actually enough, and does a heavy grade change that?

For a normalisation, 10-bit is enough by the criterion used here: one recorded code moves an 8-bit Rec.709 output by less than one output code across effectively the whole displayable range. A grade is a separate expansion on top. A contrast move multiplies the step by its own local slope, by definition; a linear exposure lift does not, and can improve matters — lifting S-Log3's codes at four stops under grey by two stops takes the step from 17.08% to 11.69%.

Sources

Twenty-seven computed code values were cross-checked against that CSV — three stops for each of the nine formats — and all twenty-seven match exactly. The nine curves themselves come from the manufacturers' own specifications. Run it and get different numbers; I would like to know.

Related: log footage explained and how to expose S-Log3 correctly.