Two quiet file properties cause most "it looked right on my machine" transfers: data range - whether black is stored at 16 or 0 - and alpha interpretation - whether transparency is stored only in the alpha channel or smeared into the RGB. Get either wrong and the file is not damaged, merely disagreed about: the image doesn't lose data, it loses the agreement about where zero is. This is the deeper diagnostic under why video looks different in a review link - that post covers the delivery pipeline; this one covers the file itself.
Limited vs full: the numbers
Limited (video) range reserves headroom and footroom: ITU-R BT.709's signal table puts nominal black at 16 and nominal peak at 235 in 8-bit (64 and 940 in 10-bit), with chroma running 16-240 (64-960). Full (data) range uses everything: 0-255 at 8-bit, 0-1023 at 10-bit - the full-range formula in ITU-R BT.2100 defines it as D = Round[(2^n − 1)·E′]. One standards quirk worth knowing before it surprises you: film-heritage tools define "full" slightly differently - DaVinci Resolve's reference manual says full range fits image data "into the full numeric range of 4 to 1023" (the DPX convention), while its video definition is the familiar "64-940" for luma and "64-960" for chroma. The mismatch mechanism follows from the numbers: media stored limited but read as full lifts the blacks (16 becomes a mid-gray footroom), and media stored full but read as limited crushes shadows and clips highlights - Resolve's colorist guide states the symptom directly: "If your final video looks substantially darker or lighter than it appears in the viewer of the color page, the data levels may be incorrectly assigned."
Who lets you fix it (and who doesn't)
| Tool | Range control | Where |
|---|---|---|
| DaVinci Resolve | Per-clip Levels: Auto / Video / Full (Auto = "determined based on the codec of the source media"); again at export | Clip Attributes → Levels; Deliver → Advanced Settings → Data Levels |
| Premiere Pro | No documented range override - Interpret Footage covers frame rate, pixel aspect, field order, alpha; the documented per-clip override is color space | Modify > Interpret Footage; Clip > Modify > Color > Override Media Color Space |
| Final Cut Pro | No range override documented - FCP auto-interprets range flags; mis-flagged media needs fixing before import (transcoders like EditReady document explicit range controls) | — |
Resolve's fix is explicit on both ends, per the reference manual and colorist guide: set the clip's levels correctly, and if an export still disagrees, "make test exports with the Data Levels set to Video and/or Full until you find the correct data level." Premiere and FCP push the fix upstream: correct the file before import or paper over the symptom with a contrast adjustment - which is why proxies and transcodes made in tools with explicit range controls (Resolve itself, or a transcoder) save the whole argument. If the symptom only appears after export, Adobe's own troubleshooting page for washed-out Premiere exports exists for the gamma-flavored cousin of this problem - same family, different cause.
Alpha: straight vs premultiplied
Alpha channel trouble is its own diagnostic. Adobe's After Effects documentation defines the two storage conventions: with straight (unmatted) alpha, "transparency information is stored only in the alpha channel, not in visible color channels"; with premultiplied (matted) alpha, transparency also lives in the RGB, "multiplied with a background color" - "sometimes said to be matted with color." Mislabel one as the other and the classic artifact appears: "a halo... along the semitransparent edges." Adobe's docs add the trade: straight retains more accurate color; premultiplied is compatible with more players. After Effects lets you reinterpret (Guess / Ignore / Straight - Unmatted / Premultiplied - Matted With); Premiere's Interpret Footage carries the same Ignore/Straight/Premultiplied choice - the one alpha control both NLEs reliably document.
Why graphics turn black in delivery
The other alpha trap is codec-level. Alpha survives only in specific codecs: Apple's ProRes white paper says ProRes 4444 XQ and 4444 "are the only ProRes codecs that support alpha channels" (up to 16 bits, mathematically lossless), and Adobe notes alpha support depends on the container/codec pairing. Consumer delivery codecs - H.264, HEVC in typical profiles - do not carry alpha at all, so the moment a lower-third lands in the H.264 review export, its transparency flattens, usually to black. Grounding the mechanism in the two facts above (alpha is codec-dependent; only 4444-class ProRes carries it in practice) explains the whole symptom family: the graphic that looked transparent in the NLE viewer but sits on black in the client's browser player. The review-side habit: send composites with their real background for approval - the client judges the frame they will ship, not a checkerboard - and keep the alpha-bearing master in the archive alongside the conform data (review export vs delivery master draws that line).
The five-minute diagnosis
- Washed out / milky blacks? Limited-range media read as full. Fix the reader (Resolve: Clip Attributes → Levels) or fix the file (transcode with correct flags).
- Crushed, contrasty, clipped? Full-range media read as limited. Same controls, opposite correction.
- Wrong only after export? Check the export side too - Resolve's Deliver → Data Levels, and the codec's native range expectation.
- Halos around graphic edges? Alpha interpretation mismatch - reinterpret straight vs premultiplied at import.
- Transparency gone black? The delivery codec dropped alpha - approve on composited background, deliver the alpha master separately.
- Still wrong everywhere? It is not range - walk the five delivery-pipeline causes in the review-link diagnosis (transcodes, resolution caps, color management, proxies, the client's screen), and remember HDR has its own range rules - BT.2100 codes PQ and HLG in the same narrow 64-940 pattern (the HDR review guide).
FAQ
What is the difference between full range and limited range?
Limited (video) range stores black at 16 and white at 235 in 8-bit (64/940 in 10-bit), reserving values for headroom per ITU-R BT.709; full (data) range uses 0-255 (0-1023). The values are metadata, not pixels - when reader and writer disagree, the image shifts. Film tools like Resolve define "full" as 4-1023, the DPX-era convention.
Why does my exported video look washed out?
Most often a range mismatch: limited-range media interpreted as full lifts the blacks. In Resolve, set Clip Attributes → Levels to Video (or test the export's Data Levels both ways per Blackmagic's guidance); in Premiere and FCP there is no documented range override, so fix the file with a transcode before import. Adobe also publishes a troubleshooting page for washed-out exports when the cause is gamma/color-management rather than range.
What is the difference between straight and premultiplied alpha?
Straight (unmatted) alpha stores transparency only in the alpha channel; premultiplied (matted) alpha also multiplies the RGB with a matte color. Read one as the other and semitransparent edges show halos. After Effects and Premiere both let you reinterpret the interpretation at import.
Which codecs support alpha channels?
Codec-dependent, per Adobe's docs - and in the ProRes family, only 4444 and 4444 XQ support alpha (Apple's white paper, up to 16-bit lossless). H.264 and HEVC delivery profiles carry no alpha, which is why graphics composites flatten to a black background the moment they hit a web player.
Does HDR change any of this?
The pattern survives: ITU-R BT.2100 codes both PQ and HLG in narrow (limited) 10-bit range - black 64, nominal peak 940 - with a full-range option defined. The same disagreement mechanics apply; the numbers just move.
How do I stop range problems from happening at all?
One convention per pipeline: transcode camera media once, at a known range, in a tool with explicit range controls, and keep that flag through conform and export - the same single-convention discipline as frame rates in the mixed-frame-rates guide. When a review link and the NLE still disagree, the file properties above are the first suspects before the pipeline ones.