Apple Log is one of the eight formats in the transform library this site ships, and one of the six it bakes 33×33×33 conversion LUTs from. The catalogue's Apple Log entry is tagged for iPhone 15 Pro and iPhone 16 Pro. Everything below is about the format, not the body: a log curve is a fixed rule mapping scene reflectance to a file value, the same wherever it runs.
Every figure here was computed by running that library. The few non-numeric facts come from repo files named at the end.
Middle grey sits at 48.8%
Feed 18% reflectance into the Apple Log encode function and it returns code value 0.488272 — 48.83% of the container. That is the single number to carry.
For scale, the homepage FAQ puts S-Log3's middle grey at 41% IRE. The computed S-Log3 code value is 41.06%, agreeing to within a tenth of a point. Apple Log's grey sits 7.8 points higher.
Other anchors on the same curve:
| Scene value | Apple Log code value |
|---|---|
| Zero reflectance | 15.05% |
| 4 stops under grey (1.125% reflectance) | 21.62% |
| 1 stop under grey | 40.89% |
| Middle grey, 18% reflectance | 48.83% |
| 1 stop over grey | 57.06% |
| 90% white card | 68.17% |
| Ceiling — code value 100% | linear 12.000002, i.e. 6.06 stops over grey |
Code value 100% decodes to linear 12.000002, two millionths above twelve times the linear value a 100% reflector carries. Whether the round number was intended is not something this file records. Treat it as the measured ceiling.
6.06 stops of headroom, the least of the eight
Headroom above middle grey is log2(decode(1.0) / 0.18). Run it across all eight formats and Apple Log finishes last:
| Format | 18% grey | Headroom above grey | 10-bit codes per stop at grey |
|---|---|---|---|
| Apple Log | 48.83% | 6.06 stops | 82.9 |
| Canon C-Log3 | 33.10% | 6.50 stops | 82.3 |
| Sony S-Log3 | 41.06% | 7.74 stops | 74.5 |
| DJI D-Log M | 39.88% | 7.87 stops | 74.4 |
| Panasonic V-Log | 42.33% | 8.00 stops | 70.9 |
| ARRI LogC3 | 39.10% | 8.26 stops | 72.3 |
| RED Log3G10 | 33.33% | 10.00 stops | 63.2 |
| Blackmagic Film Gen5 | 38.36% | 10.27 stops | 59.8 |
Codes per stop is a centred difference across one stop at grey — encode(0.18·√2) − encode(0.18/√2), ×1023 — the same definition the RED Log3G10 page states. An instantaneous slope at grey reads about 0.1 higher on the steeper formats; this measures the code budget a whole stop actually gets.
The spread across the eight is 15.73 points of code value at grey and 4.215 stops of headroom. Apple Log is the extreme of both, and those two facts are the same fact. The curve spends 48.83 points of its range below middle grey and 51.17 above it, and it spends them widely — 8.12 points of code value per stop at grey, the widest of the eight there, rising to a flat 8.55 points higher up. Wide spacing inside a fixed container means fewer stops fit.
That last figure is a usable shortcut. Above middle grey the spacing is near enough constant:
stops over grey ≈ (code value % − 48.8) / 8.55
From middle grey to the ceiling that lands within 0.071 stops of the truth, worst at the ceiling itself. It stays inside a tenth of a stop down to one stop under grey, where the error is 0.075. Below that it drifts — at two stops under it reports 1.79 against a true 2.00 — so treat it as a highlight tool only.
What the shoulder does, and where 95% comes from
Converting to Rec.709 needs a tone map: log curves encode far above diffuse white, and a bare OETF would clip everything over linear 1.0. One shared shoulder serves all eight formats, extended Reinhard with WHITE = 8.0.
shoulder(8.0) returns exactly 1.0, and the Rec.709 OETF of 1.0 is 1.0. So linear 8.0 is display white by construction, and 8.0 is 5.47 stops over middle grey.
In Apple Log code values, linear 8.0 is 95.00%, and everything above that renders as clipped white through this site's chain. That leaves just under 5 points of code value — 0.585 stops — above what the shoulder can show. It is the smallest overflow of the eight: the same calculation gives RED Log3G10 4.53 stops and Blackmagic Film Gen5 4.80.
Read that as an accounting note, not permission. Those stops are in the file, and another tone map or a wider delivery can show them. Through this chain they do not survive.
The cross-check worth knowing: all eight formats, exposed at their own middle grey, land on Rec.709 0.3731 — 95 in 8-bit. Six return 0.373142 on every channel. Apple Log is the one that spreads, 0.373124 to 0.373160, for the reason in the next section; across all eight the total spread is 3.6×10⁻⁵.
The matrix: rows sum to 1, and what that does not buy you
Apple Log carries Rec.2020 primaries. The library's matrix to Rec.709 is:
[ 1.6605, -0.5876, -0.0728 ] row sum 1.0001 [-0.1246, 1.1329, -0.0083 ] row sum 1.0000 [-0.0182, -0.1006, 1.1187 ] row sum 0.9999
The row sums are 1.0 to within 1×10⁻⁴. Apple Log is the loosest of the eight on this: ARRI LogC3 is next at 1×10⁻⁶ and the other six are exact to floating point.
What the property buys. Rows summing to 1 means an equal-channel input comes out equal-channel — grey in, grey out. Sweeping the whole code range through the full chain, the worst channel spread on a neutral input is 4.08×10⁻⁵, or 0.042 of a 10-bit code, at code value 60.4%. There is one exception, at 25.21%, where the spread reaches 2.64×10⁻⁴.
That exception is not the matrix. The Rec.709 OETF in this file switches from 4.5x to 1.099x^0.45 − 0.099 at linear 0.018 and is discontinuous there by 2.48×10⁻⁴, and 25.21% is the neutral code value that lands on the join. Channels the matrix has separated by one part in ten thousand fall on opposite sides of it. Even so the error is 0.27 of a 10-bit code, reaching a full code only at 12 bits.
What it does not buy. It says nothing about whether the light was neutral. A cast in is a cast out. Push a warm triplet, linear [1.00, 0.75, 0.45], through the matrix and it comes back [1.187, 0.721, 0.410] — still warm, and with the R:G ratio moved from 1.333 to 1.646. That change is correct, not a fault: the same physical light has different coordinates in Rec.709 than in Rec.2020. But the matrix neither removes a cast nor preserves its numbers. White balance is a separate operation, done first.
A saturated input can also leave the matrix negative. Linear [0.05, 0.10, 1.00] comes out with red at −0.0485, and the chain clamps negatives to zero. That clamp is a gamut limit, not an exposure one, and it is where a saturated colour stops being distinguishable. The stage lasers and LED walls guide covers it from the grading end.
Carrying another format's target costs you a measurable amount
Meter Apple Log to a target learned on another format and you are underexposed by this much:
| Target you are carrying | Its grey code | Apple Log lands at | Error |
|---|---|---|---|
| Panasonic V-Log | 42.33% | 0.102 linear | 0.81 stops under |
| Sony S-Log3 | 41.06% | 0.091 linear | 0.98 stops under |
| DJI D-Log M | 39.88% | 0.082 linear | 1.13 stops under |
| ARRI LogC3 | 39.10% | 0.077 linear | 1.23 stops under |
| Blackmagic Film Gen5 | 38.36% | 0.072 linear | 1.33 stops under |
| RED Log3G10 | 33.33% | 0.044 linear | 2.02 stops under |
| Canon C-Log3 | 33.10% | 0.043 linear | 2.05 stops under |
It runs the other way too: put Apple Log's 48.83% on an S-Log3 waveform and you are 1.05 stops over, on RED Log3G10 2.40 over. The target is a property of the curve, not a habit.
What follows for exposure
- Put middle grey on 48.8%. That is where 18% reflectance encodes. If your reference is a 90% white card instead, the computed figure is 68.2%.
- Read the waveform as a stop count. Subtract 48.8, divide by 8.55, and above grey that is your stops over, within a tenth.
- Treat 95.00% as the wall for this site's chain. Above that code value the shoulder is already at display white. There are 0.585 stops of file above it, and 6.06 stops between grey and the ceiling — 4.2 stops less than Blackmagic Film Gen5.
- Correct exposure on the log image, then convert, then apply the look. That order is the site's standing position, stated in the FAQ. Details in log to Rec.709 conversion done right.
- Do not carry an S-Log3 or C-Log3 target across. Off by 0.98 and 2.05 stops respectively, both towards underexposure. If S-Log3 is your other camera, its numbers are in the S-Log3 exposure guide.
More on the whole pipeline in the Academy.
How these numbers were produced
Every figure above comes from public/js/color-transforms.js, the library this site ships to the browser and loads in Node. To reproduce:
const CT = require('./public/js/color-transforms.js');
CT.encode('Apple Log', 0.18); // 0.488272 → 48.83%
Math.log2(CT.decode('Apple Log', 1) / 0.18); // 6.0589 stops of headroom
CT.encode('Apple Log', 8.0); // 0.950032 → the shoulder's white point
CT.matrix('Apple Log').map(r => r.reduce((a, b) => a + b, 0));
CT.toRec709('Apple Log', [0.488272, 0.488272, 0.488272]);
// → [0.373160, 0.373142, 0.373124], i.e. 95/255 on every channel
Comparison figures are the same calls looped over CT.CAMERAS. Stop spacing is a central difference of encode in log2 space. The neutral sweep steps code value in 10⁻⁵ increments through toRec709 and records the largest channel gap; a coarser step misses the spike at 25.21%. CT.shoulder(CT.WHITE) returning exactly 1.0 is what makes linear 8.0 display white. Round trips were checked first: decode(encode(0.18)) returns 0.18 for all eight formats to within 9×10⁻¹⁷.
Sources
public/js/color-transforms.js— the transform library this site ships: Apple Log's encode and decode curve, its Rec.2020 → Rec.709 matrix, the shared extended-Reinhard shoulder withWHITE = 8.0, the Rec.709 OETF and its join at linear 0.018, and the clamp on negative channels. Every number above is computed from this file.SITE.md— the site's colour-pipeline notes: Apple Log's Rec.2020 primaries, 18% grey at 0.4883, and Apple Log as one of six formats with a baked 33×33×33 conversion LUT.db/init.js— the catalogue seed, where the Apple Log entry carries the iPhone 15 Pro and iPhone 16 Pro tags.public/index.html— the homepage FAQ: S-Log3 middle grey at 41% IRE, and the correct-then-convert-then-look order.