AVIF Colour Depth and HDR Support

Bit depth describes how many distinct brightness levels a single colour channel can hold. The maths is simple: an 8-bit channel stores 2⁸ = 256 levels per channel. A 10-bit channel stores 2¹⁰ = 1,024 levels. A 12-bit channel stores 2¹² = 4,096 levels. Because a typical image has three colour channels (red, green, blue), the total number of possible colours is that figure cubed: 256³ = 16,777,216 for 8-bit; 1,024³ for 10-bit; and 4,096³ for 12-bit.

More levels mean smoother transitions between shades. When you have only 256 steps to describe a gradient from deep blue sky to near-white horizon, the encoder sometimes cannot find a level that sits precisely between two adjacent tones. The result is a hard staircase edge where the gradient should be smooth — a visible band of uniform colour called posterisation or banding. With 1,024 steps the staircase is four times finer, and with 4,096 steps it is effectively invisible to the human eye under normal viewing conditions.

This is not an abstract concern. Any image with a large smooth area — a sky, a product background, a human face in soft lighting, a fog layer in a landscape — can show banding when encoded at 8-bit with aggressive compression. Increasing bit depth is one of the two tools for fixing it; the other is reducing compression. Higher bit depth is essentially free precision that lets you compress further without the banding artifact appearing.

AVIF is built on the AV1 video codec and inherits its full colour capabilities. The format natively supports 8-bit, 10-bit, and 12-bit colour depth per channel. This is a structural property of the container (ISOBMFF) and the codec, not a bolt-on extension.

JPEG, by contrast, is defined as an 8-bit format. The baseline and progressive JPEG profiles both operate on 8-bit YCbCr data. There is a lossless JPEG extension that can handle 12-bit, but it is rarely supported outside specialised medical or scientific software and has never appeared in general-purpose encoders or browsers.

PNG has a 16-bit option at the specification level, but real-world tool support is uneven. Most image editors write 8-bit PNG by default, and many web pipelines silently strip 16-bit PNG down to 8-bit during optimisation. AVIF's 10-bit and 12-bit modes are first-class, not edge cases — libavif and major encoders support them, and Chrome, Firefox, and Safari all decode 10-bit AVIF correctly.

In practice, most web-destined AVIF files are encoded at 10-bit even when the source is a standard 8-bit photograph. Encoding an 8-bit source into a 10-bit AVIF does not add precision that was never there, but it gives the encoder more intermediate levels to work with when applying lossy quantisation, which can reduce banding at a given compression ratio.

High Dynamic Range (HDR) content captures a wider range of luminance than standard display conditions. An SDR display targets a peak brightness of around 100 nits; modern HDR displays can reach 1,000 nits or more. To encode that extra headroom, a different transfer function is used to map scene luminance to code values. AVIF supports two HDR transfer curves:

• PQ (Perceptual Quantiser) — standardised as SMPTE ST 2084, designed for absolute luminance up to 10,000 nits. Used in HDR10 and Dolby Vision content.
• HLG (Hybrid Log-Gamma) — standardised by the BBC and NHK, backwards-compatible with SDR displays. Used in broadcast HDR.

JPEG uses SDR transfer curves only — either the standard sRGB gamma (IEC 61966-2-1) or, with an embedded ICC profile, AdobeRGB. There is no way to embed a PQ or HLG transfer function in a standard JPEG file. This means HDR photographs, HDR video frames extracted as stills, and HDR camera output cannot be faithfully stored in JPEG without first tone-mapping them to SDR.

AVIF can also carry wide colour gamuts. The colour primaries field in the CICP (Coding-Independent Code Points) metadata block can specify Display P3 (DCI-P3 with D65 white point, used by iPhone cameras and Apple displays) or BT.2020 (the wide-gamut space used in UHD broadcast and cinema). A photograph taken on a modern iPhone in ProRAW or HEIC uses Display P3 primaries; when that image is converted to AVIF, the wide gamut can be preserved intact without any lossy gamut mapping.

JPEG embeds colour profile information almost exclusively through ICC profiles — binary blobs describing colour space transformations, white point, and tone response curve. ICC profiles are flexible but can be large (a full LUT-based profile adds dozens of kilobytes), and browser colour management of embedded ICC profiles has historically been inconsistent.

AVIF uses CICP as its primary colour descriptor. CICP encodes colour primaries, transfer function, and matrix coefficients as three small integer fields. A Display P3 / PQ / YCbCr file can be fully described in three bytes rather than a multi-kilobyte ICC blob. AVIF can also carry an ICC profile as an optional override, which is useful for specialised colour spaces that have no CICP identifier.

The practical implication is rendering accuracy. When a browser reads an AVIF with CICP Display P3 primaries, it passes those values directly to the OS colour management layer (ColorSync on macOS, ICM on Windows). If the browser is not colour-managed — or the operating system does not expose a wide-gamut compositing path — the colours will be clipped to sRGB at some point in the pipeline, making the image look slightly desaturated or shifted. This is not an AVIF bug; it is a display pipeline limitation. For ordinary web photography on sRGB displays, CICP sRGB is the correct choice and everything renders as expected.

When you convert an AVIF to JPG, two pieces of information are silently discarded if the source file used them.

Tone mapping (HDR to SDR). If the AVIF carries PQ or HLG metadata, a converter must tone-map the luminance range into the 0–255 range that JPG expects. Tone mapping is not reversible. Different converters apply different tone mapping curves (simple clipping, Reinhard, ACES filmic), and the result varies. Highlights that were encoded in PQ may clip to white, or they may compress into a flatter midtone region, depending on the tool. There is no lossless path from HDR AVIF to SDR JPG — only better or worse tone-mapping choices.

Bit depth quantisation (10/12-bit to 8-bit). Going from 10-bit to 8-bit is a 4x reduction in precision per channel: 1,024 levels collapse to 256. This step introduces quantisation error — values that sat between two 8-bit steps get rounded to the nearest one. The error is usually below the visibility threshold for most photographic content, but for smooth gradients or compressed files that were already near the banding threshold, it can push the image over the edge. The degradation is permanent once the file is saved as JPG.

Neither of these losses occurs if you convert to PNG instead. A lossless 16-bit PNG preserves the full 10-bit or 12-bit range and will not apply tone mapping. However, 16-bit PNG is large, and if the destination is a web page or a JPG-only platform, PNG is not always an option.

For most photographs published on the web, 8-bit is sufficient. A compressed AVIF displayed on a standard 1920×1080 sRGB monitor will look identical at 8-bit and 10-bit in the vast majority of scenes. The situations where 10-bit or 12-bit provides a visible benefit are narrower than marketing language suggests:

• Large sky areas with gentle gradient transitions, especially in blue or orange tones where banding appears first
• Skin tones in soft, even lighting where subtle contour shifts need fine resolution
• Fog, haze, or smoke layers in landscape photography
• Product photography on gradated neutral backgrounds (the gradient from mid-grey to off-white is exactly where 8-bit banding shows)
• HDR photography workflows where tone-mapped output will be further adjusted in post
• Professional delivery where downstream editors need headroom to make exposure or colour corrections without introducing banding

For portraits against solid-coloured studio backgrounds, street photography, food photography, and most e-commerce product shots on white, the practical difference between 8-bit and 10-bit AVIF at typical compression settings is not perceptible. The file size overhead of 10-bit over 8-bit for the same image content is small, so there is little reason not to use 10-bit if your encoder supports it — but do not expect a visible improvement in every case.

Even if an AVIF file is encoded at 10-bit with Display P3 primaries and PQ transfer, the visual benefit depends entirely on the display pipeline that renders it. There are several places where higher precision can be lost before the photon reaches the viewer's eye.

Most desktop monitors sold in the last several years are sRGB panels. Even if the operating system passes wide-gamut data to the display controller, the panel itself cannot reproduce colours outside the sRGB triangle. The display will either clip those colours or gamut-map them. A 10-bit file on an 8-bit panel may still benefit from the extra encoder precision (banding reduction), but the extra colour range is wasted.

Browser colour management matters too. Chrome and Safari are colour-managed on macOS; Chrome is colour-managed on Windows with appropriate OS settings; Firefox has its own colour management path. When a colour-managed browser on a P3 display renders an AVIF with CICP P3 primaries, the saturated colours render correctly. When the same file opens in a browser that does not colour-manage, the P3 values are passed to the display as if they were sRGB, making reds appear more orange and greens more yellow-green.

The takeaway: file capability and visual outcome are two different things. An AVIF can hold 10-bit P3 HDR content perfectly. Whether a viewer sees the benefit depends on their monitor, OS, and browser combination. For broad web distribution, encoding in 10-bit sRGB is a safe and practical choice — it reduces banding risk without relying on wide-gamut display support that most users do not have.

The right bit depth and colour space choice depends on what you are doing with the image.

• General web publishing (photos, e-commerce, blogs): 8-bit or 10-bit AVIF in sRGB. Use the AVIF to JPG converter or online converter for compatibility with older platforms.
• Professional photography delivery to clients: 10-bit AVIF or 16-bit TIFF. TIFF is still the standard for retouchers who need maximum headroom.
• HDR photography or video stills: Keep as AVIF with PQ or HLG. Converting to JPG permanently discards the HDR range.
• iPhone ProRAW or camera raw output in Display P3: Encode as AVIF with CICP P3 primaries for web delivery on Apple devices; add a sRGB fallback or convert to sRGB if broad compatibility matters more than colour accuracy.
• Archival master files: Do not use JPEG. Use lossless AVIF, PNG 16-bit, or the original camera RAW. Bit depth lost to JPG cannot be recovered.

If you are opening AVIF files that appear washed out or overly saturated, colour space mismatch is the most likely cause. Check whether the file has an embedded ICC profile or CICP metadata, and whether your viewer is colour-managed. On macOS, Preview and Safari are colour-managed. On Windows, Photos app is colour-managed; Paint is not.

The most direct way to produce a 10-bit AVIF is with avifenc, the command-line encoder bundled with libavif. Install it on macOS via Homebrew (brew install libavif), on Ubuntu via apt install libavif-bin, or build from source at github.com/AOMediaCodec/libavif. Once installed, a minimal 10-bit encode looks like this:

avifenc --depth 10 --speed 6 --min 20 --max 35 input.png output.avif

The key flags are:

• --depth 10 — forces 10-bit output regardless of the source bit depth. Use --depth 12 for 12-bit. If omitted, avifenc inherits the source depth and defaults to 8-bit for most JPEG or PNG inputs.
• --speed 6 — a value from 0 (slowest, best quality) to 10 (fastest, weakest quality). Speed 6 is a practical default for batch work; speed 4 is common for final-quality encodes.
• --min 20 --max 35 — quantiser range. Lower numbers mean lower quantisation noise. A --min 20 --max 35 range typically produces files roughly 40–70% smaller than a high-quality JPEG at perceptually comparable quality.
• --cicp 1/13/6 — optional flag to set CICP colour primaries / transfer function / matrix coefficients explicitly. The triple 1/13/6 is sRGB + sRGB gamma + BT.709 matrix, which is correct for most standard web photos. For Display P3 content use 12/13/6.

To verify the bit depth of the output, run avifinfo output.avif. Look for a line like Depth: 10 bits. Alternatively, magick identify -verbose output.avif | grep -i depth should return Depth: 10-bit.

A common confusion: passing a 8-bit PNG source with --depth 10 does not invent precision that was not captured. The original 256 levels are up-sampled to 1,024 levels mathematically, so the output file is 10-bit but the underlying image data is still 8-bit in character. The real benefit is that the encoder can now apply lossy quantisation within a 10-bit space, distributing quantisation error across more levels before any visible banding appears.

For batch encoding a directory of images, a one-liner in zsh or bash handles the loop:

for f in *.png; do avifenc --depth 10 --speed 6 --min 20 --max 35 "$f" "${f%.png}.avif"; done

Sharp (Node.js) and Pillow (Python 3.10+) both support writing AVIF via libavif under the hood. In Sharp: sharp(input).avif({ quality: 65, effort: 4, bitdepth: 10 }).toFile(output) maps roughly to the same avifenc parameters above.

Bit depth and chroma subsampling are two independent axes of image quality in AVIF, but they interact in ways that can matter for colour-critical work. Understanding both helps you choose the right encode settings for a given use case.

Chroma subsampling refers to how much colour (chroma) information is stored relative to brightness (luma) information. The three modes you will encounter are:

• 4:2:0 — one chroma sample per 2×2 luma block. This is the default for most lossy AVIF encodes and all standard JPEGs. File size is smallest; colour resolution is halved in both horizontal and vertical directions.
• 4:2:2 — one chroma sample per 1×2 luma block. Horizontal colour resolution is halved; vertical is preserved. Common in broadcast video and some professional photography workflows.
• 4:4:4 — full chroma resolution, one sample per luma pixel. File size is roughly 50% larger than 4:2:0 at the same quantiser. Used for lossless encodes, text-on-gradient content, and colour-critical photography where chroma detail matters.

The practical interaction with bit depth: chroma subsampling affects spatial colour resolution; bit depth affects tonal precision. A 10-bit 4:2:0 AVIF has more tonal steps per channel than an 8-bit 4:2:0 AVIF, but both have the same reduced chroma spatial resolution. A 10-bit 4:4:4 AVIF has both benefits simultaneously, at the cost of a larger file.

For typical web photographs, the differences collapse in most viewing conditions. The human visual system is far more sensitive to luma resolution than chroma resolution, which is precisely why 4:2:0 works at all. However, there are specific subjects where 4:2:0 chroma subsampling produces visible artefacts independent of bit depth:

• Text or fine lines rendered in saturated colours (red text on white, for example) show chroma fringing at 4:2:0 that 4:4:4 eliminates entirely
• Sharp transitions between saturated adjacent colours — a red–blue gradient at full saturation — can show colour smearing at 4:2:0
• Fabric with fine coloured patterns (plaid, tartan) loses colour fidelity with 4:2:0 subsampling

To encode AVIF with 4:4:4 chroma subsampling using avifenc, add the --yuv 444 flag:

avifenc --depth 10 --yuv 444 --speed 4 --min 18 --max 28 input.png output.avif

Expect the output file to be approximately 30–50% larger than the equivalent 4:2:0 encode at the same quantiser settings. For most photographic content on the web, the size increase is not justified. For images containing text overlays, technical diagrams, or fine coloured detail, the quality improvement is often visible and the increase in file size may be worth it.

When you convert a 4:4:4 AVIF to JPEG, the output JPEG will typically be stored as 4:2:0 by default (most JPEG encoders use 4:2:0 unless you force -sampling-factor 1x1,1x1,1x1 or the equivalent). This means converting a high-quality 4:4:4 AVIF to JPEG introduces chroma subsampling on top of any bit-depth reduction — two simultaneous quality costs that together can make colour-critical images look noticeably softer in the colour channel.