Skip to content
uncompressed.io
Start free

Colour tagging, from the format up

The QuickTime gamma shift.
What the file format documents, and what nobody documents.

It is usually explained as a bug in a player or a browser. The documented mechanism is narrower and far more useful: a QuickTime file can carry two competing colour descriptions, the standard says which one wins, and a file that carries none at all gets an assumption made on its behalf. Here is the format, the assumption, and the exact line where the documentation stops.

See the plans

Video hosting for filmmakers · 5 GB free · Paid plans from USD 9/month

By uncompressed.io · Updated September 2026

Setting the folklore aside

It is not a player secretly brightening your film;
it is a file that forgot to describe itself.

Search this problem and you will be told, confidently and without a citation, that one application applies a gamma of 2.2 while another applies 1.96, or that a particular browser brightens QuickTime files. No standards body, no browser vendor and no platform publishes that. What is published is narrower, and it explains far more of what people see.

A QuickTime movie does not just carry pixels. It carries a description of what those pixels mean: which primaries they were mixed from, which curve sits between the stored numbers and the light a display should emit, and how luma and chroma were derived from red, green and blue. When that description is present and correct, a reader has nothing to guess. When it is missing, or when the file carries two descriptions that disagree, the reader falls back on an assumption, and different readers were written at different times against different assumptions. That is the whole mechanism. It is a metadata problem wearing a rendering problem’s clothes.

3

Indices in colr

Colour primaries, transfer function and matrix, each stored as a 16-bit value.

1-1-1

The HD triplet

Index 1 is ITU-R BT.709 for each of the three. TN2227 gives 1-1-1 as the Rec. 709 triplet.

SMPTE-C

The untagged assumption

Apple documents untagged media as colour managed by QuickTime X as if created in SMPTE-C.

0

Re-encodes here

The player streams the exact bytes uploaded, so the tag you wrote is the tag that is served.

The file format

Two colour extensions,
and the one that supersedes it.

Inside a QuickTime file, each video track has an ImageDescription: the structure that tells a reader how to decode the picture. Codec, dimensions, depth, and a set of optional extensions hang off it. Two of those extensions describe colour, and only one of them is current.

The colour parameter atom, colr, is a required extension for uncompressed Y’CbCr formats. It carries three 16-bit indices, and each index selects a published specification rather than a number the file invents. Index 1 is ITU-R BT.709 for all three: primaries, transfer function and matrix. BT.709 is not a historical document either; the current version is BT.709-6, approved in June 2015 and in force, defining the parameter values for HDTV production and international programme exchange. So a correctly tagged HD file is not asserting a taste. It is naming a standard that has a number and a date.
What the index selects
Index 1 means
What goes wrong if a reader assumes differently
Colourprimaries
The chromaticities of red,green, blue and white
ITU-R BT.709
Hue and saturation drift.Skin and sky move first.
Transferfunction
The curve between storedcode values and light
ITU-R BT.709
The tone curve is remapped.This is the gamma shift.
Matrix
How Y'CbCr was derivedfrom R'G'B'
ITU-R BT.709
Colour separates frombrightness incorrectly.

The three indices of the QuickTime colour parameter atom, from Apple's QuickTime File Format documentation. TN2227 gives 1-1-1 as the HD triplet for Rec. 709. The right-hand column describes the class of error, not a measured delta; no published document quantifies one.

The older extension is gama, which carries a single gamma value rather than a full colour description. It has been superseded, and the format documentation is unusually direct about what that means in practice.

From the QuickTime File Format documentation, verbatim

The ‘colr’ extension supersedes the previously defined ‘gama’ ImageDescription extension. Writers of QuickTime files should never write both into an ImageDescription, and readers of QuickTime files should ignore ‘gama’ if ‘colr’ is present.
Read that as two separate instructions, because it is. The first is aimed at whatever wrote your file: do not put both in. The second is aimed at whatever opens it: if both are there anyway, colr wins. In the real world tools do write both, usually because a legacy export path added gama years ago and a newer path added colr without removing it. Nothing about such a file is illegal, and a reader that follows the rule handles it correctly. The risk is that you have handed the file’s appearance to the diligence of whichever reader opens it, on a question the standard already answered.
colr present, gama absent
Both written
Neither present
What the filetells a reader
Three explicit indices
Two descriptions, one ofwhich is superseded
Nothing. The reader mustassume something.
What the formattells a readerto do
Read colr
Ignore gama, read colr
The format does not say
What Apple documentsfor QuickTime X
Not stated as aspecial case
Not stated as aspecial case
Colour managed as if the mediawere created in SMPTE-C
Practicalexposure
None. The filedescribes itself.
Depends on the readerfollowing the rule
Depends entirely on thereader's default

Sources: Apple's QuickTime File Format colour parameter atom documentation for the colr and gama rule, and Apple Technical Note TN2227 for the untagged case. Both fetched 4 September 2026.

The case that actually bites

A file with no tag does not get no colour space;
somebody else picks one.

Most files that trigger this complaint are not carrying a wrong tag. They are carrying no tag, usually because they went through a step that copied the picture and dropped the metadata. Apple documents exactly what its own player does in that situation.

Apple Technical Note TN2227, verbatim

Important: Media without a ‘nclc’ tag will be color managed by QuickTime X as if it were created in the SMPTE-C color space.
SMPTE-C is the standard-definition colour space of the analogue-era North American broadcast chain: the primaries and transfer characteristics that 525-line television was built around. It is a perfectly good specification. It is simply not the one your HD or UHD timeline was graded in. Rec. 709, defined for HDTV and currently at BT.709-6, uses different primaries and a different transfer characteristic. When a colour-managed player reads an untagged file, it assumes the SD characteristic, converts from that assumption toward the display, and every code value in the picture lands somewhere other than where the colourist put it.
The tone curve is where people notice it first, because the transfer function is the part of the description that governs the relationship between numbers and brightness. Convert from an assumed curve that is not the encoding curve and the mid-tones and the low end move together: shadows lift, contrast flattens, and the whole frame reads as washed out and slightly milky. The size of that shift depends on the content, the conversion and the display, and no published document gives a figure for it, so this page gives none either. The direction is the part that is mechanical, and the direction is what everybody reports.
Two boundaries on that, both important. This is a documented behaviour of QuickTime X, stated by Apple about its own player; it is not a claim about web browsers and should never be quoted as one. And it is a statement about media without an nclc tag, which means the fix is not to fight the player but to stop shipping files that make one guess. For the symptom-side version of this problem, including the parts that have nothing to do with tagging, see washed out colors after upload.

Where the documentation stops

Nobody publishes the browser half.
Say so, then engineer around it.

This is the section most articles on this query skip, because saying “this is not documented” feels weaker than a confident answer. It is not weaker. It is the only statement here that will still be true next year.

What browser vendors publish

Codec support, and only codec support. Chrome's platform status entries describe HEVC hardware decoding and its conditions. Microsoft's Edge table lists which codecs are supported and which are conditional. Firefox's release notes announce hardware-accelerated HEVC on Windows. WebKit's posts name which video tracks a feature handles. Every one of these is about whether a stream decodes. None describes how an untagged file's colour is handled.

What Apple publishes for web video

The HLS Authoring Specification for Apple Devices, which requires H.264, HEVC, Dolby Vision or AV1, and requires one colour space per stream, chosen from Rec. 601, Rec. 709, DCI-P3 or Rec. 2020. Note what that requirement implies: Apple's own delivery spec assumes the stream declares its colour space. It does not describe a fallback, because a conforming stream never needs one.

What follows for you

Tag explicitly and never rely on a default. A default you cannot cite is a default that can change in a point release, differ across operating systems, or differ between the machine you tested on and the one your client opens the link on. An explicit tag removes the variable instead of predicting it.

There is a version of this page that names the lighter browser. It would be more satisfying to read and it would be made up. The correct posture in the presence of an undocumented default is always the same: do not consume the default. Write the description into the file, verify that it survived, and the behaviour you cannot look up becomes behaviour you do not depend on.

The part you can run today

Check the tag, set the tag,
then prove it survived the trip.

Four steps, in order. The third one is the one people skip, and the fourth is the one that catches the tool in your pipeline that has been quietly stripping metadata for a year.

1

Read the file before you blame anything

Open the master in a media inspector that reports the ImageDescription extensions, not just the codec and the resolution. You are looking for three values: colour primaries, transfer function and matrix. An HD or UHD Rec. 709 deliverable should read as the 1-1-1 triplet. If the inspector reports the fields as unknown, unspecified or absent, you have an untagged file, and you have found the problem before writing a single email.

2

Set it explicitly on export, every time

Every colour-managed finishing application exposes the output colour space in its export settings. Set it, rather than accepting whatever the preset inherits from the project. Set it on the client-viewing export as well as the archival master: the viewing export is the file people actually watch, and it is the one most likely to come from a preset nobody has opened in two years.

3

Never ship a file carrying both colr and gama

The format tells writers not to write both and tells readers to ignore gama when colr is present. If your inspector shows both, re-export from a path that writes only the current extension, or remux through a step that carries the colour description rather than re-deriving it. Do not solve it by deleting colr, which leaves you with the superseded description and no way to name your primaries or matrix at all.

4

Test the round trip you actually use

Build a ten-second test: a grey ramp, a chart, and five seconds of your real graded footage, exported the way you export deliveries. Send it through your whole pipeline, whatever that is, and inspect the file at the far end. If the three indices changed or vanished, you have located the step that strips tags, and you know it before a client sees a delivery rather than after.

Why the round trip is the step that pays

A tag written correctly on export can still be absent by the time a viewer plays the file, because any step that decodes the picture and re-encodes it is writing new metadata rather than carrying yours. That is not sabotage, it is what re-encoding is. It just means the only version of your file whose tagging you can actually assert is the one you tested end to end.

What this means for hosting

A host that re-encodes writes new colour metadata;
a host that does not, passes yours through.

Keep this section in proportion. Hosting is one step in the chain, and it is not the step that renders the picture.

A platform that builds renditions has to re-encode, and the new files carry colour metadata written by that encoder as part of the process. Both major platforms state that they re-encode. Vimeo puts it plainly: during transcoding, your video file is re-encoded into several formats that will be available to view on Vimeo. YouTube states that it always re-encodes videos to optimize their playback quality, and separately recommends BT.709 as the SDR colour space for uploads. Neither of those is a defect. A documented target colour space across a whole ladder of renditions is a reasonable design, and it is one of the reasons a platform rendition looks the same across a spread of devices.
uncompressed.io works the other way. There is no transcode anywhere: the player streams the exact bytes you uploaded, so the ImageDescription you wrote on export is the one served, unchanged, to everyone who opens the link. Uploads run to 5 TB a file with no codec allowlist; a browser plays H.264, HEVC or AV1. ProRes 422, ProRes 4444 and DNxHR are hosted for client download rather than streamed, and that download is a byte-for-byte copy. The honest trade sits alongside it: with no adaptive ladder, a viewer on a weak connection buffers rather than sliding down to a softer rendition.
Now the limit of that claim, stated as plainly as the claim itself. Passing the tag through untouched is the most a host can do about colour, and it is not the same as controlling the picture. The final rendering happens in the viewer’s browser, on the viewer’s display, in the viewer’s room, and no host, format or codec has authority over any of the three. And if what you need is reach and discovery, YouTube costs nothing and no private host competes with it; if you need a marketing suite, an OTT product or Vimeo’s player, those have no equivalent here. Just do not expect any of them to fix an untagged master.

The honest ending

If the file is tagged and it still looks wrong,
the remaining variables are not yours.

Tagging is a solvable problem, and this page is mostly about solving it. Once it is solved, the difference a client is describing on the phone comes from somewhere you do not control and cannot ship a fix for: an uncalibrated laptop panel, a brightness slider two notches from where yours sits, a display profile chosen at first boot, a warm-tone filter that turns on at sunset, a window behind the monitor. No codec, bitrate or host touches any of that.
What you can do is make the conversation specific. Ship a grey ramp alongside the cut so there is a shared object to talk about, ask what they are watching on, and state which colour space the delivery is in, now that you can point at the three indices in the file and name the standard each one selects. That is a stronger position than arguing about whether a browser has a gamma bug, and it is the one the documentation actually supports.

Questions

Frequently asked

Is the QuickTime gamma shift a browser bug?

There is no official document that calls it one. What is officially documented is the file format and one player behaviour: the colr extension carries three explicit colour indices and supersedes the older gama extension, and Apple's Technical Note TN2227 states that media without an nclc tag is colour managed by QuickTime X as if it were created in the SMPTE-C colour space. That is a QuickTime X statement about untagged media. It is not a statement about any web browser, and this page will not turn it into one.

What is the colr atom?

It is an ImageDescription extension in a QuickTime file that describes how the picture's numbers map to colour. It is a required extension for uncompressed Y'CbCr formats and it carries three 16-bit indices: colour primaries, transfer function and matrix. Index 1 is ITU-R BT.709 for each of the three, which is why a correctly tagged HD file reads as the triplet 1-1-1.

What happens if my file has no colour tag at all?

The file stops describing itself and every reader has to assume something. Apple documents its own assumption: media without an nclc tag is colour managed by QuickTime X as if it were created in the SMPTE-C colour space. SMPTE-C is the standard-definition space, and its transfer characteristics are not Rec. 709's, so material graded for Rec. 709 gets pushed along a curve it was not built for. That is the documented path to the lifted, flat look people describe.

Does one browser show my file lighter than another?

No browser vendor publishes how its video element treats an untagged file. The public browser documentation covers codec support, not colour management of untagged media, and Apple's published web-video guidance is the HLS authoring specification, which names H.264, HEVC, Dolby Vision and AV1 and requires one colour space per stream. So the honest answer is that it is not documented, in either direction. Tag the file and the question stops mattering.

Should a file ever carry both colr and gama?

No, and the format says so in one sentence: writers of QuickTime files should never write both into an ImageDescription, and readers should ignore gama if colr is present. A file that carries both is still legal to read, because the rule tells readers what to do, but it is a file whose fate depends on how carefully the reader that opens it was written.

Does uploading to uncompressed.io change my colour tags?

No. There is no transcode anywhere in the pipeline, so the bytes served are the bytes you uploaded, tags included. That is a claim about the file, not about the picture on your client's monitor: the final rendering is still done by their browser and their display, which no host controls.

My file is tagged correctly and the client still says the colour is wrong. Now what?

Then the file is no longer the variable. What is left is their display and their viewing environment: an uncalibrated panel, a brightness slider, a colour profile chosen at setup, an OS-level night filter, a phone in daylight. Send a reference chart alongside the cut, ask what they are watching on, and calibrate the conversation rather than the export.

Tag it once, then stop re-encoding it

uncompressed.io streams the exact bytes you upload. Nothing is transcoded, so the colour description you wrote on export is the colour description that gets served. Start free with 5 GB, no credit card.

See the plans

Sources

  1. 1.Apple, QuickTime File Format: Color Parameter Atom (colr), the three 16-bit indices and the rule that colr supersedes gama (fetched 4 September 2026)
  2. 2.Apple Technical Note TN2227: media without an nclc tag is colour managed by QuickTime X as SMPTE-C, and the HD triplet 1-1-1 for Rec. 709 (fetched 4 September 2026)
  3. 3.ITU-R BT.709-6, Parameter values for the HDTV standards for production and international programme exchange, approved 06/2015, in force (fetched 4 September 2026)
  4. 4.Apple, HLS Authoring Specification for Apple Devices: required codecs and one colour space per stream, chosen from Rec. 601, Rec. 709, DCI-P3 or Rec. 2020 (fetched 4 September 2026)
  5. 5.Chrome Platform Status: HEVC hardware decoding, shipped Chrome 107, platform conditions (codec support only, no colour-management statement) (fetched 4 September 2026)
  6. 6.Microsoft Edge video playback support table: codec support matrix, HEVC conditionally supported (fetched 4 September 2026)
  7. 7.Firefox 134.0 release notes: hardware-accelerated HEVC playback on Windows (fetched 4 September 2026)
  8. 8.WebKit, Safari 18.4 features: H264, HEVC and AV1 video tracks named for MediaRecorder (fetched 4 September 2026)
  9. 9.Vimeo Help Center, FAQ Video transcoding: every uploaded file is re-encoded into several formats (fetched 4 September 2026)
  10. 10.YouTube Help: YouTube always re-encodes videos to optimize their playback quality (fetched 4 September 2026)
  11. 11.YouTube Help, recommended upload encoding settings: BT.709 recommended as the SDR colour space (fetched 4 September 2026)

Keep reading

Washed out colors after uploadVideo hosting that does not compressHEVC 10-bit 4:2:2 and browser playbackProRes delivery