Every editor has lived this one: the grade looks great on your timeline, you export, you open the file in QuickTime, and the whole thing is washed out. Or the client opens it on a MacBook and asks why it looks flat. Nine times out of ten the footage is fine and the export is fine… the two of you are just looking at the same pixels through different color assumptions. This page is the reference for all of those assumptions: what Rec.709 and sRGB really are, what the log curve on your camera is doing, what PQ and HLG mean when a delivery spec asks for them, and why macOS keeps sabotaging your contrast.
Bookmark it. This is a reference page, not a gear guide, so there are no products and no affiliate links here. Just the tables and the answers.
Last updated: August 2026.
TLDR
If you just need to know what to set for a delivery, start here. Everything below the table explains why these are the answers.
| Delivering to | Color space (gamut) | Gamma / transfer function | Notes |
|---|---|---|---|
| Web, YouTube, social | Rec.709 | Grade at 2.4, viewers see ~2.2 | Spot-check on a consumer screen before you send it |
| Broadcast SDR | Rec.709 | BT.1886 (effective 2.4) | The reference-suite standard |
| Streaming HDR | Rec.2020 container | PQ (SMPTE ST 2084) | HDR10 and Dolby Vision are both built on PQ |
| Broadcast HDR | Rec.2020 container | HLG | One signal serves HDR and legacy SDR sets |
| Theatrical / DCP | DCI-P3 | Gamma 2.6 | ~6300K white point, mastered for a dark theater |
| Apple devices | Display P3 | sRGB-style curve (~2.2) | P3 gamut, D65 white. Not the same P3 as cinema |
Rec.709 vs sRGB: same colors, different brightness
Here is the fact that untangles most of the confusion: Rec.709 and sRGB have identical color primaries and the identical D65 white point. The red, green, and blue corner points are the same numbers in both standards. Same triangle, same gamut, covering about 35.9% of what human vision can see. If someone tells you sRGB is “smaller” than Rec.709, they’re repeating a myth.
The difference is the transfer function, the curve that decides how bright a given code value looks on screen. And this is where a detail trips people up: the BT.709 standard itself describes the camera side of the pipeline, not the display side. Display gamma for Rec.709 comes from a separate standard, ITU-R BT.1886, which specifies an effective gamma of about 2.4 for a reference display in a dark grading suite. sRGB, by contrast, uses a curve that approximates gamma 2.2, tuned for a moderately lit office or living room.
So the practical rule: Rec.709 the gamut is a solved problem that every display on earth can handle. Rec.709 the gamma is a choice between 2.4 and 2.2, and picking wrong is the root of “my grade looked different on my client’s laptop.” An image finished at 2.4 looks slightly lifted and flat on a 2.2 display; an image finished at 2.2 looks darker and more contrasty at 2.4. Grade broadcast work at 2.4 in a dim room. For web-only work, know that nearly every viewer is on a ~2.2 screen in a lit room, and check your export there before it ships. And none of this matters if your monitor is drifting, which is why the calibration guide exists.
Camera log formats, compared
Log footage looks flat and gray on purpose. A log curve packs the camera’s full dynamic range into a limited bit depth by bending the signal: a toe at the bottom that protects shadow detail, and usually a shoulder at the top that rolls highlights off gently instead of clipping them. You trade a pretty image off the card for maximum latitude in the grade. Every manufacturer shapes that curve differently, which is why a Sony LUT does nothing useful on Canon footage.
| Format | Maker | Dynamic range | Curve character | Path to Rec.709 |
|---|---|---|---|---|
| S-Log3 | Sony | ~14 stops | Based on a revised Cineon curve; no shoulder, reduced toe, closest to pure log | Sony’s official S-Gamut3.Cine/S-Log3 LUTs, or color management |
| C-Log3 | Canon | ~14 stops | Smoother shadow rolloff than the original C-Log; more stops below middle grey than C-Log2 | Canon LUTs, shared across the Cinema EOS line |
| V-Log | Panasonic | 14+ stops | Full V-Log on cinema bodies; V-Log L on GH-series is a reduced-range variant of the same curve | Panasonic V-Log LUTs |
| N-Log | Nikon | 12+ stops | The newest of the four; Nikon owns RED now, so expect these two ecosystems to keep converging | Nikon N-Log LUTs, or color management |
Treat the stop counts as ballpark claims rather than spec-sheet promises. The exact number varies by camera body and by how the manufacturer counts, so “about 14 stops” is as precise as an apples-to-apples table can be.
Blackmagic RAW is not a log format (and that matters)
BRAW gets lumped in with log formats, but it works differently in a way worth understanding. Blackmagic ships numbered generations of color science (Generation 5 is current as of July 2026), each with its own “film curve” gamma. Gen 5’s film curve is a dynamic 12-bit gamma curve built to hold more data in the highlights and shadows, which shows up as better skin tones and cleaner rendering of saturated sources like neon and taillights in high-contrast scenes.
The part that separates it from the table above: because BRAW is raw sensor data, the generation is a metadata tag, not a baked-in curve. S-Log3 footage is S-Log3 forever. BRAW footage shot years ago under an older generation can be reprocessed with Gen 5 color science today, in Resolve, with a dropdown. Your back catalog inherits every improvement Blackmagic ships. No other format in this article can do that.
HDR: Rec.2020, PQ, and HLG
First, a distinction people conflate constantly: Rec.2020 is a gamut, not an HDR system. It is a very large color triangle. HDR is a brightness system, defined by the transfer function. The standard that ties them together is Rec.2100, which takes the Rec.2020 primaries and pairs them with one of two HDR transfer functions. Which one you use is the whole decision.
| PQ (SMPTE ST 2084) | HLG (Hybrid Log-Gamma) | |
|---|---|---|
| Signal type | Absolute: code values map to specific nit levels on any display | Relative, scene-referred: the display scales it to its own capability |
| Peak brightness | 10,000-nit theoretical ceiling; real masters sit at 1,000 to 4,000 nits | Nominal reference peak of 1,000 nits |
| SDR compatibility | None; an SDR set needs a separate SDR version or a tone-mapped conversion | An SDR set can decode the same signal and get a watchable, if flatter, image |
| Built on it | HDR10, Dolby Vision, most streaming HDR, UHD Blu-ray | Broadcast HDR (BBC and NHK co-developed it) |
| Pick it when | The delivery spec is streaming/OTT or disc | The delivery spec is broadcast, or one signal must serve both HDR and SDR sets |
Notice what’s missing from that table: taste. PQ vs HLG is almost never a creative decision. The delivery spec decides for you. Streaming masters go PQ, broadcast goes HLG, and your job is to read the spec sheet, not to have an opinion about transfer functions.
For reference, BT.2100 defines the viewing environment these numbers assume: peak white of at least 1,000 cd/m² for small highlights, black level at or below 0.005 cd/m², and a 5 cd/m² D65 surround. That last line is also the polite way of saying most “HDR” monitors can’t show you this signal as it’s meant to be seen. Which monitors can pull it off is exactly what the grading monitor guide covers.
The three P3s
“P3” on a spec sheet is doing more work than it should, because there are two common P3 standards and they share nothing but the gamut. The RGB primaries are identical; the white point and gamma are not.
| Variant | White point | Gamma | Where it lives |
|---|---|---|---|
| DCI-P3 | ~6300K “Cinema White” | 2.6 | Theatrical projection, dark rooms |
| Display P3 / P3-D65 | D65 (same as Rec.709 and sRGB) | sRGB-style curve, ~2.2 | Every wide-gamut Mac, iPhone, and iPad |
When a client says “make sure it looks good on an iPhone,” the P3 in question is Display P3. DCI-P3’s 6300K white and 2.6 gamma exist for a dark theater and look wrong everywhere else. And here is the monitor-shopping trap: a panel advertising “99% P3 coverage” is telling you about the gamut only. It says nothing about which white point and gamma the panel is calibrated to, and DCI-P3 mode and Display-P3 mode are different picture settings even on the same panel. Coverage is not calibration.
Color management: Resolve RCM vs ACES
Once you’re mixing S-Log3 A-cam footage with BRAW B-cam and a drone shooting who-knows-what, you need a system that normalizes everything into one working space and then transforms out to whatever the delivery needs. That’s color management, and the two systems you’ll meet are Resolve Color Management (RCM) and ACES. Both are scene-referred, both solve the same problem, and the choice between them comes down to who else touches your project.
RCM is Blackmagic’s own system, built into Resolve. Three settings do the work: an Input Color Space per source clip in the Media Pool, a Timeline Color Space everyone grades in, and an Output Color Space that gets baked into the deliverable. No image data is clipped in the input-to-timeline conversion, the color page behaves the way Resolve users expect, and there’s nothing to configure beyond those three menus.
ACES is the Academy’s open, cross-application standard, built so that color stays mathematically consistent across facilities, vendors, and tools that have never heard of your Resolve project. ACES 1.3 runs input transforms into a working space and out through the RRT and ODT transforms; you grade in ACEScct (a log space with a toe, so shadows grade without overshooting) or ACEScc (pure log, no toe), while ACEScg is the linear space where CGI and VFX compositing happen. ACES 2 replaces the split RRT/ODT with a unified rendering transform and targets the known 1.x complaints, the skewed highlight hue-shifts and extreme-saturation clipping. As of this writing, application support for ACES 2 is still rolling out, so confirm your whole toolchain speaks it before building a show on it.
| Your situation | Use |
|---|---|
| Solo editor or colorist, grading your own footage, delivering to web/social/clients out of Resolve | RCM |
| Small studio, everything lives in Resolve end to end | RCM |
| Outside VFX vendor, DI facility, or multiple NLEs and tools on one show | ACES |
| A studio or streamer spec that mandates ACES compliance | ACES (not optional) |
RCM for a solo operation or a Resolve-only studio, ACES the moment your color pipeline crosses a company boundary. ACES exists to make handoffs exact, and if there are no handoffs, you’re paying its complexity tax for nothing. Netflix’s own partner documentation supports an ACES workflow in Resolve for productions that need it, which tells you where the line sits: it’s a facility and contract tool, not a solo-colorist upgrade.
Tone mapping, briefly
Tone mapping is the compression step between a bigger range and a smaller display: taking HDR’s extended brightness and color and remapping it into what an SDR screen (or a dimmer HDR screen) can reproduce, rolling highlights off instead of clipping them. It’s the reason a PQ master doesn’t simply die on an SDR screen. Two names you’ll see attached to it: the ACES output transforms (the film-industry default, part of the pipeline above) and ITU-R BT.2390, the broadcast-side HDR-to-SDR recommendation. Premiere Pro’s built-in Tone Mapping controls and Resolve’s HDR-to-SDR tools are implementations of the same idea. The full how-to belongs with delivery workflows, not here; this page just wants you to recognize the names when a spec sheet drops them.
Why your export looks washed out on a Mac
Now the section half of you scrolled here for. You grade in Premiere, export, open the file in QuickTime Player, and the contrast is gone. The blacks are milky, the color is thin, and the file is “broken.” It’s not broken. What happened is a gamma disagreement between your NLE and macOS.
The root cause: macOS’s ColorSync pipeline has historically interpreted Rec.709-tagged video with a non-standard gamma of about 1.96, instead of the broadcast-standard 2.4 (or the 2.2 most non-Mac software assumes). Premiere displays and grades assuming 2.4. When QuickTime Player, Safari, or any other ColorSync-aware app opens the export, the 1.96 interpretation lifts the midtones and flattens the contrast. On Windows the same file lands closer, not correct: 2.2 sits nearer Premiere’s 2.4 than macOS’s 1.96 does, so the shift is milder rather than absent. That spread is why you and your client can watch the identical file and see two different movies.
The available fixes, and what each one costs you:
- Premiere’s Viewer Gamma setting (Lumetri Color > Settings > Project) is the current control. Pick 2.4 Broadcast, 2.2 Web, or 1.96 QuickTime and the program monitor shows you what that target will show your viewer, so you grade against the gamma the file is headed for. Cost: it changes the viewer, not the export, so you have to choose a target and commit to it. Adobe’s old Gamma Compensation LUT, which darkened the export to pre-compensate for ColorSync’s 1.96 read, was the fix in previous versions of Premiere; Viewer Gamma replaces the need for it.
- Resolve’s “Rec.709-A” gamma tag (the A is for Apple) embeds a flag so ColorSync-aware players render the file correctly. It sidesteps the mismatch instead of baking in a correction, which makes it the cleaner fix when your audience is Mac-heavy.
- Do nothing, and brief the client. Underrated. If the deliverable’s real destination handles color correctly, one preview link viewed in Safari is not worth re-engineering your export chain over.
And the flat statement no forum thread wants to give you: there is no universal fix. The mismatch lives between operating systems and players, not inside any one export setting, so every remedy above trades correctness on one platform for error on another. Pick the fix that matches where your audience watches, and stop hunting for the magic checkbox. It does not exist. For the same problem viewed from the device side (why the iPhone in particular shows you a different image), that story is in why your exports look different on your iPhone.
FAQ
Do I need to shoot log?
Only if you grade. Log buys you latitude in post at the price of mandatory color work; ungraded log looks like gray soup. If your footage goes out with minimal correction on a fast turnaround, a standard picture profile serves you better than a log clip you never had time to grade.
Is Rec.2020 the same thing as HDR?
No. Rec.2020 is a gamut, a set of color primaries. HDR is a brightness system defined by the transfer function (PQ or HLG). Rec.2100 is the standard that combines them. You can put SDR inside a Rec.2020 container, and plenty of “HDR” content never comes close to using the full 2020 gamut.
My monitor says 99% P3. Why does my footage still look wrong?
Because coverage is not calibration. That 99% describes the gamut the panel can reach, not the white point or gamma it is set to, and DCI-P3 and Display P3 differ on both. Check which P3 mode the monitor is in, then check when it was last calibrated. The calibration guide takes it from there.
Do I need ACES?
If you’re asking, probably not yet. ACES pays off when color must survive handoffs between companies and applications. Solo and single-studio Resolve work gets the same scene-referred benefits from RCM with less setup. The exception: a contract or streamer spec that mandates ACES, in which case the decision was made for you.
Where this fits
This page is the theory layer under the color content on this site. The grading monitor guide tells you which displays can reproduce these spaces honestly. The calibration guide makes whatever you own tell the truth about them. The color grading suite build puts the whole signal chain together. And the iPhone exports piece covers the device side of the gamma-shift story you just read.
In conclusion
And that’s it! The whole subject compresses to three questions: what gamut, what transfer function, and who decides. For most work the delivery spec answers all three, and the failures people spend hours debugging (the washed-out export, the flat client preview, the “wrong” P3 monitor) come from mismatched assumptions rather than broken files. Standards move, so treat the ACES 2 and BRAW generation notes as July 2026 facts and check the source when it matters. If something here saved you a support-thread spiral, bookmark the page for the next one. And if you hit a color mystery this page does not cover, leave a comment… it might become the next section.
