One Grade, Every Screen: The Unsolved Problem of Color Management
It started, as most post-production disasters do, around 11 PM with a nearly empty cup of coffee and a timeline that looked perfect on my calibrated monitor. I’d spent the better part of an afternoon grading a short film - BRAW footage from a Blackmagic Pocket, careful work, the kind of grade where the shadows sit exactly where you want them and the skin tones actually look like skin. Exported to H.264. Opened it on my phone. The highlights were crushed, the shadows had gone muddy brown, and the whole thing looked like it had been filtered through a layer of sadness.
I had made, without knowing it, the classic mistake. I had graded for one screen and exported for all screens without thinking about what happens in between.
What Color Profiles Actually Are
Before diving into the pain, it’s worth getting the vocabulary straight, because this field has accumulated enough acronyms to fill a flight manual.
When your camera records an image - or when your display renders one - it needs to agree with every other device in the chain about what numbers mean colors. A pixel value of 128, 64, 200 in red, green, blue channels only means something if you know the rules of the game: which physical colors do those numbers map to? How bright is full white? What’s the relationship between the number 128 and the actual light output at that level?
A color space defines the range of colors (the gamut) a device can represent, and where those colors sit in relation to absolute physical reality. A color profile encodes that definition so software can understand it and convert between spaces. Think of it like character encoding for color: ASCII and UTF-8 both represent text, but if you open an ASCII file assuming it’s UTF-8, certain characters will look wrong. Same data, wrong interpretation.
The common color spaces you’ll encounter:
sRGB is the default for the web, consumer screens, and most JPEG exports. It’s a relatively small gamut - covers roughly 35% of the visible spectrum - but it’s universal. If you don’t know what color space something is, assume sRGB and you’ll be right most of the time.
Rec.709 is sRGB’s broadcast television cousin. Nearly identical gamut, slightly different transfer curve (the mathematical relationship between numeric value and light output). This is what standard HD video is displayed in, and what most NLEs assume you’re working in unless you tell them otherwise.
DCI-P3 is wider - it covers more saturated colors, especially reds and greens. Cinema projectors use it. The iPhone display uses it. High-end computer monitors use it. If your display is P3-capable, you’re already living in a wider world than most of the internet can see.
Rec.2020 is wider still - theoretically capturing nearly the entire visible spectrum. Almost no consumer display actually covers the full Rec.2020 gamut. It’s more of a container standard for HDR mastering than a display technology you’ll encounter on someone’s laptop.
Then there’s the question of HDR vs SDR. Standard Dynamic Range (SDR) maps everything from black to white within a relatively compressed range - roughly 100 nits peak brightness on a reference display. High Dynamic Range (HDR) - in formats like HDR10 or Dolby Vision - can specify content up to 1000, 4000, or even 10,000 nits. A properly graded HDR master can render a specular highlight on a chrome surface as genuinely blinding, rather than as a flat washed-out white.
Why Log Footage Makes This More Complicated
Modern cameras capable of serious work - the Blackmagic series shooting BRAW, Sony A7 family shooting S-Log2 or S-Log3, Arri cameras shooting Log C - don’t record footage that looks like anything at all when you first open it. It looks flat, washed out, grey. This is intentional.
Log encoding is a mathematical trick to cram more dynamic range into a limited recording format. Human vision (and camera sensors, to some extent) perceive brightness on a logarithmic curve: the difference between nearly-black and slightly-less-black is perceptually significant, but the difference between two shades of very bright highlight matters much less. Log formats exploit this by encoding shadows with more numerical precision and compressing the highlights, preserving information across a much wider range than a “normal” recording would.
The trade-off: before you can do anything useful with the image, you need to transform it back into a viewable form. That’s where LUTs (Look-Up Tables) enter the picture.
A LUT is exactly what it sounds like - a table that says “input color value X maps to output color value Y.” A technical LUT (sometimes called a transform LUT or 3D LUT) handles the color science conversion: log-to-linear, or log-to-Rec.709, or BRAW to DCI-P3. A creative LUT sits on top and adds the artistic look - the warm bleach bypass, the teal-and-orange cinema grade, whatever the project needs.
In a sensible pipeline, you apply a technical LUT first to get your image into a known, usable state, then do your creative work in that space, then apply another technical transform at export to target your delivery format. Simple in theory.
The Core Problem: One Grade, Every Output
Here’s where it falls apart. Suppose you nail a grade and need to deliver to:
- A cinema DCI projection (DCI-P3, up to 14 stops of dynamic range)
- A broadcast client who wants Rec.709 masters for television
- YouTube (which accepts Rec.709 but HDR content is increasingly common)
- Instagram (sRGB, compressed within an inch of its life, displayed on everything from a calibrated OLED to someone’s cracked iPhone in direct sunlight)
- Print production stills (CMYK, a completely different color model entirely)
These are not the same problem. Not even close.
The most immediately obvious issue is gamut clipping. If you’ve graded beautiful saturated reds that live in the DCI-P3 gamut, and you export that grade unmodified as an sRGB file, those reds will be clipped - they’ll be squashed to the nearest in-gamut color, which is a different red. Your carefully chosen color palette just got modified by mathematics you didn’t control.
The second issue is tone mapping. HDR content graded to 1000 nits needs to be tone mapped - compressed - to fit into an SDR container that assumes 100 nits maximum. Automatic tone mapping exists, but “automatic” is doing a lot of work in that sentence. Automated tone mapping will preserve luminance relationships but may sacrifice color saturation, shift hues, or handle highlights in ways that look fine technically and terrible artistically. A shot graded for HDR with intentional specular pop will, through automatic tone mapping, just look bright and a bit washed out in SDR.
The third issue is more philosophical: perceptual intent. There are different strategies for how to handle colors that are out-of-gamut in the target space. Colorimetric rendering tries to preserve accurate in-gamut colors and clips anything outside - your reds, if they’re out of gamut, get hard-clipped. Perceptual rendering compresses the entire image to fit - your reds shift slightly but remain distinguishable from orange. Neither is correct. They’re trade-offs, and the right choice depends on the content.
The Real-World Pain
I want to be specific about what this looks like in practice, because the abstract version undersells how annoying it is.
You’re grading a sunset scene. Gorgeous. The sky has a deep, saturated orange-red gradient that you’ve carefully shaped to sit at the edge of DCI-P3. On your P3-capable editing monitor - even a relatively modest one - it looks exactly like you want it. The color is vivid without being garish. You export Rec.709 for a client preview.
On their laptop: slightly less saturated, acceptable. On their phone: noticeably different, the orange has gone slightly muddy. On the conference room projector (an older unit, sRGB gamut): the whole sky looks distinctly less rich, and the color story you built around warm tones versus cool shadows has partially collapsed because the relative saturation difference is smaller in the narrower space.
The grade isn’t “wrong” in any absolute sense. But it doesn’t transfer cleanly. And there’s no single export that will look identical on all those displays, because the displays are fundamentally different.
The SDR-to-HDR direction is even worse. If someone with an HDR display watches an SDR master, the platform may apply an “automatic HDR” uplift algorithm - a black box that guesses how to map the SDR content into HDR headroom. These algorithms have improved dramatically, but they’re still guessing. Your carefully placed shadows may get lifted. Your highlight relationships may shift.
Scene-Referred Versus Display-Referred, and Why Professionals Care
This is where the conversation moves from “frustrating” to “actually addressable,” at least if you’re prepared to restructure your entire workflow.
The traditional approach to color grading is display-referred: you work in the final delivery color space (Rec.709, usually), on a calibrated monitor that represents that space. What you see is what you get - for that one delivery format.
The modern approach, used in high-end film and television production, is scene-referred: you maintain your footage in a “scene linear” state that references the actual light levels captured, independent of any specific display. You grade in this space, and at the end, you generate multiple outputs by applying different display transforms.
The most common framework for this is ACES (Academy Color Encoding System), developed by the Academy of Motion Picture Arts and Sciences specifically to solve the multi-output problem. In an ACES pipeline, everything gets transformed to a common “ACES” encoding on the way in, you grade in ACEScct (a log-like working space), and ACES Output Transforms handle the conversion to each delivery format on the way out. Change the Output Transform, get a different delivery.
OpenColorIO (OCIO) is the open-source engine that powers most of this in professional tools - DaVinci Resolve, Nuke, Blender, and others all support it. It’s essentially a configurable color management layer you drop into your pipeline, define your transforms, and let it handle the math consistently everywhere.
Neither ACES nor OCIO makes the fundamental problem go away. A cinema master and an Instagram export will still look different on their respective delivery platforms, because those platforms are different. What they give you is control and consistency: the differences are intentional, defined by your Output Transforms, not surprises from undocumented export settings.
ACES is opinionated in ways that some colorists love and others find limiting. The default ACES look is quite desaturated in the highlights and handles skin tones in a specific way. Some productions use modified ACES setups or entirely custom OCIO configs. The framework is a starting point, not a straitjacket.
How Professionals Actually Handle This
I’ve spent enough time talking to colorists and digging through post-production workflows to offer a reasonably honest picture of how studios that get this right approach it.
The first thing is calibrated monitoring. You cannot make consistent color decisions on an uncalibrated display. This is non-negotiable at any professional level. At minimum: a hardware colorimeter, a monitor with a reasonable gamut, and a calibration profile applied consistently. On the high end: a dedicated reference monitor calibrated to within tight tolerances against a standard. You have to know what you’re looking at.
The second is explicit color management throughout the pipeline. Every piece of software in your chain should have color management explicitly configured, not left at defaults. This means telling your NLE what color space your footage is in, what your working space is, and what your output space is. Leaving it to “auto” or “default” is asking for inconsistency.
The third is versioned deliverables with documented transforms. For any project with multiple output destinations, you create a delivery matrix: each output destination, the Output Transform applied, any manual adjustments. When a client says the Instagram version looks slightly different from the broadcast master, you want to be able to say “yes, here’s exactly why, and here’s why it’s correct.”
The fourth, and most important for anyone starting out: work in the widest gamut your pipeline supports for as long as possible, and only convert to the target at the end. Don’t grade in sRGB if your source footage is BRAW and your NLE supports P3 or scene-linear. The wider your working space, the more color information you preserve for when you make the final conversion. Every premature gamut conversion throws away information you can’t recover.
An Honest Conclusion
Color management is one of those areas where the more you learn, the more you realize how much of what you see on your screen is an interpretation, not a truth. The “real” color of your footage exists somewhere in the scene-linear realm, in the actual photons that hit your sensor. Everything after that is a series of mathematical transforms, and every transform is a decision about what to preserve, what to sacrifice, and what your viewer’s display is actually capable of rendering.
The multi-output problem doesn’t have a clean solution. It has workflows that minimize the inconsistency and give you more control over where the inconsistency lives. An ACES pipeline, a proper OCIO config, a calibrated monitor, and versioned output transforms - this is the professional answer, and it’s still imperfect, because DCI-P3 and sRGB are different gamuts and always will be.
What you can do is stop being surprised by it. Stop grading on a P3 monitor and exporting for sRGB without thinking about the gamut conversion. Stop treating the Instagram version and the cinema version as “the same thing but smaller.” They’re different deliveries for different display environments, and they deserve different attention.
The coffee at 11 PM tastes the same on every screen. Your grade does not.
If you want to go deeper on any of this, the ACES documentation from the Academy is thorough and freely available. DaVinci Resolve’s color management documentation is also excellent - specifically the section on DaVinci YRGB Color Managed and DaVinci Wide Gamut workflows, which is Blackmagic’s take on the scene-referred pipeline problem. For the OCIO side, the OpenColorIO documentation and the ACES GitHub repository both have real-world config examples.