Same file, four apps, four different images

Open the same ProRes in Resolve, Premiere, FCPX, and VLC. Four different images. None wrong. All different. The disagreement is about colour interpretation, and it is predictable.

Open a single ProRes 422 HQ file tagged 1-1-1 (BT.709 primaries, BT.709 transfer, BT.709 matrix) in four applications. DaVinci Resolve shows saturated, punchy colour. Final Cut Pro looks brighter, with lifted shadows. Premiere Pro looks like one or the other depending on a checkbox. VLC shows something else entirely.

The pixels have not changed. The decode is identical. The four applications disagree about what the decoded values mean on the way to your display.

This is not a format or decode problem. Every application is reading the file correctly. The disagreement is specifically about colour interpretation: gamma curves, gamut mapping, and whether to honour the display’s ICC profile. That disagreement is predictable once you know what each application actually does.

What the file declares

Every QuickTime and MP4 file can carry colour metadata in its colr atom. The Apple variant is nclc (nonconstant luminance coding). The ISO variant is nclx. They encode three integers and, for nclx, a flag:

  1. Colour primaries (which red, green, and blue define the gamut)
  2. Transfer characteristics (the gamma curve or OETF applied during encoding)
  3. Matrix coefficients (how RGB was converted to YCbCr)
  4. Full range flag (nclx only: code values 0-255, or legal range 16-235)

These values are enumerated in ISO/IEC 23001-8 (also ITU-T H.273). The same metadata can appear inside the video bitstream itself, in the VUI (Video Usability Information) of H.264 and H.265 streams. ProRes stores its own copy in the elementary stream frame header.

The metadata is not ambiguous. 1-1-1 means BT.709 primaries, BT.709 transfer, BT.709 matrix. 9-16-9 means BT.2020 primaries, PQ transfer, BT.2020 non-constant luminance matrix. The values are defined. The disagreement between applications is not about what the file says. It is about what they do with that information on the way to the screen.

Gamma Comparison
1.96Apple / QuickTime
2.2sRGB / web
2.4BT.1886 / broadcast
Notice how lower gamma values lift the midtones, producing a brighter image from the same data.

Four applications, four rendering pipelines

Resolve: bypass by default

DaVinci Resolve in its default colour science mode (DaVinci YRGB, colour management off) does not transform pixel values from the file’s colour space to the display’s colour space. It sends decoded values straight to the GPU. On a Mac with a Display P3 panel, BT.709 code values land on P3 primaries without gamut mapping. Reds and greens are visibly oversaturated compared to a BT.709 reference monitor.

This is deliberate. Resolve bypasses macOS ColorSync entirely. Blackmagic’s assumption: anyone doing serious colour work has a calibrated reference monitor on SDI through a DeckLink or UltraStudio, where the output path sends exact code values and the monitor handles its own calibration. The GUI viewer is a preview, not a reference.

Switch to DaVinci YRGB Color Managed mode and the behaviour changes completely. Resolve reads the colr atom, assigns an input colour space per clip, transforms through a wide-gamut working space (DaVinci Wide Gamut / Intermediate), and outputs to the chosen delivery space. This is a real transform-graph pipeline with explicit intent at every stage. But it is off by default in new projects, and a substantial number of Resolve users never enable it.

Final Cut Pro: full ColorSync, gamma 1.96

Final Cut Pro is fully colour-managed. It reads the file’s colr atom, passes the tagged colour space to macOS ColorSync, and ColorSync transforms the image to the display’s ICC profile. On any Mac display manufactured since roughly 2015, that profile is Display P3 with a D65 white point.

The critical detail is the transfer function. Apple’s ColorSync applies a display gamma of approximately 1.96 to BT.709 content. Not 2.4 (BT.1886, the broadcast reference standard). Not 2.2 (sRGB’s effective gamma). The value 1.96 descends from the original Macintosh system gamma of 1.8, adjusted upward for modern panels. The practical result: BT.709 content in Final Cut Pro renders brighter and lower-contrast than the same file on a BT.1886 reference monitor. Shadows lift. Midtones open up. The image looks “washed out” to anyone expecting broadcast contrast.

This is a deliberate rendering decision for bright-room viewing conditions on a consumer display. It means Final Cut’s viewer will never match a grading suite. A colourist who grades on a reference monitor calibrated to BT.1886 and exports a QuickTime will hear “it looks washed out” from every client reviewing on a Mac.

Premiere Pro: two modes, two images

Premiere Pro 25.x performs automatic colour space conversion, transforming each source clip from its detected colour space into the sequence’s working space. The default SDR working space is BT.709 with 2.4 gamma.

The complication is the Display Color Management toggle in Preferences > General. When enabled, Premiere compensates for the display’s ICC profile via ColorSync, matching Final Cut’s rendering path. When disabled, it sends values to the GPU without display compensation. On a P3 Mac, disabled means the same oversaturation as Resolve’s default. Enabled means the gamma 1.96 lift, matching Final Cut.

Same file. Same application. Two different images. The toggle is off by default and buried deep enough that many editors have never seen it.

Premiere also has a history of omitting NCLC tags from exported QuickTime files. Without the tag, QuickTime Player falls back to default assumptions and applies its own gamma transform. The colourist’s export looks different from the editor’s export. Not because of the grade. Because of missing metadata.

VLC: minimal interpretation

VLC reads BT.709 and BT.2020 tags and can perform rudimentary colour space conversion, but it does not honour the display’s ICC profile. It does not transform to the monitor’s actual gamut.

On a P3 Mac, VLC shows more saturated colours than Final Cut because it is not mapping BT.709 content back to the intended gamut. It shows darker midtones than Final Cut because it does not apply the Apple gamma 1.96 lift. Against Resolve’s default viewer, VLC looks similar but not identical: both bypass system colour management, but their decoders handle the BT.709 transfer function with slightly different precision.

VLC is showing the data with almost no interpretation applied. That is useful diagnostic information. It is not a reference.

Why the gamma 1.96 problem persists

The single most common colour complaint in post-production: a colourist grades on a reference monitor calibrated to BT.1886 (gamma 2.4), exports a QuickTime, and the client says it looks washed out. The colourist’s monitor showed one thing. The client’s Mac showed another. Neither is lying.

The mechanism is specific. A file tagged 1-1-1 (BT.709 primaries, BT.709 transfer, BT.709 matrix) triggers Apple’s ColorSync gamma 1.96 rendering path. Blacks lift to not-quite-black. Contrast softens. The pixel values are unchanged. The display rendering is lighter than what the colourist approved on a 2.4 monitor.

Two workarounds exist. Resolve can export with “Rec 709-A” gamma tags, which signal a 1/1.961 transfer function and avoid triggering the ColorSync lift. The BBC’s open-source qtff-parameter-editor rewrites NCLC tags in QuickTime files after export. Both are workarounds for a fundamental disagreement: Apple and the broadcast world use different gamma models for BT.709 content on consumer displays, and neither is planning to change.

The range trap

On top of gamma and gamut disagreements sits the full-range vs. limited-range question. BT.709 video uses “legal” range: code values 16-235 for 8-bit luma, with 0-15 and 236-255 reserved for headroom and footroom. Full range uses 0-255. The nclx atom has a full_range_flag to signal which encoding was used. Many encoders set it incorrectly. Many decoders ignore it.

The symptoms are specific. Limited-range data treated as full-range: the image looks washed out, blacks sit at dark grey (code value 16 rendered as 16/255 instead of 0), whites never reach peak white. Full-range data treated as limited-range: shadows crush to black, highlights clip. This is the single most common cause of “my video looks flat.”

Range errors compound with gamma and gamut mismatches. A file with wrong range AND wrong gamma AND wrong primaries is three interpretation errors stacked together. Each one makes the others harder to isolate.

What “it looks right in Resolve” actually means

“It looks right in Resolve” means: the image on Resolve’s GUI viewer, bypassing system colour management, rendering to whatever display is connected, with whatever project colour science is active, looks acceptable to one person in one room.

It does not describe what the file contains. It does not predict what a reference monitor would show, what the client will see in QuickTime, what the broadcast chain will do with the signal, or how the image will render in a browser on a phone.

The file’s colour metadata describes what the pixel values mean. The application’s rendering pipeline decides how to present those values on a specific display. Those are different operations. Conflating them is the root of almost every colour disagreement in post-production.

Diagnosing which interpretation is correct

The viewer is not the diagnostic tool. The metadata is.

Pull up FFprobe and read the colour tags directly:

ffprobe -v quiet -show_entries stream=color_primaries,color_transfer,color_space,color_range -of default=noprint_wrappers=1 input.mov

This tells you what the file declares. color_primaries=bt709, color_transfer=bt709, color_space=bt709, color_range=tv (limited range). If any of those fields say “unknown,” the file is missing metadata and every application is guessing. That is the first thing to establish.

Next, compare scopes, not pictures. A waveform monitor is not affected by the display’s ICC profile, the GPU’s gamut mapping, or the room lighting. It shows the code values. The viewer shows an interpretation of those values through a rendering pipeline. When scopes and viewer disagree, the scopes are correct.

If the file’s tags are present and correct, the question becomes: which application’s rendering pipeline matches the intended viewing environment? Content graded for broadcast delivery on a BT.1886 monitor is correct at gamma 2.4. The same file viewed through ColorSync on a Mac will look different. Neither rendering is wrong. They are rendering for different display standards.

The practical diagnostic sequence:

  1. Probe the file. Confirm the colr atom values (or VUI parameters for H.264/H.265). Confirm range.
  2. Check the scopes. Do the code values match what the grade intended? Black at 16 (limited) or 0 (full)? Peak white at 235 or 255?
  3. Identify the target display standard. BT.1886 for broadcast. ColorSync/gamma 1.96 for Mac consumer delivery. sRGB for web.
  4. Choose the application whose pipeline matches. Resolve with colour management off matches no standard. Final Cut matches Apple’s consumer rendering. Resolve with colour management on, pointed at BT.1886 output, matches broadcast.

The file is not the problem. The rendering disagreement is the problem. And the rendering disagreement is resolvable once you stop asking “which app looks right” and start asking “right for which display, in which viewing conditions, for which audience.”

References