Rendering AVIF Gain Maps Across Mixed-Brightness UI

Modern operating systems balance high-dynamic-range (HDR) imagery and standard-dynamic-range (SDR) user interfaces by leveraging AVIF gain maps to dynamically adapt image brightness to target displays. By decoupling a standard base image from an auxiliary gain map channel, the OS compositor calculates real-time brightness headroom to render vivid HDR highlights within an image viewport while preserving consistent, unclipped brightness levels across adjacent SDR text, controls, and UI chrome.

The AVIF Gain Map Structure

An AVIF gain map (standardized under ISO 21496-1) consists of two main visual elements packaged within a single file: a primary base image (typically tone-mapped for standard SDR displays) and an auxiliary grayscale or color gain map metadata track. When an operating system encounters this format, it reads metadata tags defining minimum and maximum headroom values, gamma parameters, and color space boundaries. This dual structure guarantees backward compatibility with legacy pipelines while providing instructions on how much to boost each pixel's luminance on HDR-capable hardware.

Establishing the Shared Composition Space

Operating system compositors—such as Windows Desktop Window Manager (DWM), Apple Quartz/Core Animation, and Android SurfaceFlinger—do not composite mixed UI layers in standard sRGB. Instead, they transform all incoming UI layers into an intermediate, wide-gamut, floating-point color space. Common composition spaces include scRGB (a linear space using sRGB primaries where 1.0 represents SDR white) or Rec. 2100 Linear.

In this pipeline:

• Traditional SDR UI elements (buttons, menus, text) are normalized to a defined target reference luminance, commonly known as SDR white (typically mapped between 80 and 203 nits depending on system calibration).
• The compositor assigns these SDR elements a relative luminance value of 1.0, ensuring their appearance remains stable regardless of overall panel brightness settings.

Calculating Real-Time HDR Headroom

Before decoding and displaying the AVIF image, the OS queries the display hardware to determine current display headroom (\(H\)). Headroom represents the ratio between the display's peak instantaneous luminance and its current SDR white luminance.

Because display brightness changes based on ambient light sensors, user sliders, and power-saving profiles, headroom is dynamic. The OS uses this ratio to compute a weight factor between 0.0 (render base SDR image directly) and 1.0 (render full HDR reconstruction). If the display provides intermediate headroom, the OS interpolates between the minimum and maximum capacity defined in the AVIF metadata, preventing hard clipping of highlight detail.

Tone Reconstruction and Mixed-Layer Compositing

Once the OS determines the appropriate scaling factor, it reconstructs the image pixels in a GPU shader:

1. Base Pixel Extraction: The shader samples the base SDR image and converts it from non-linear encoding (such as sRGB transfer function) to linear floating-point values.
2. Gain Application: The shader samples the auxiliary gain map, normalizes it according to the computed display headroom, and mathematically multiplies it with the linear base values.
3. Color Space Alignment: The resulting values are transformed to match the OS compositor’s linear composition space. Regions intended to be specular highlights or bright light sources expand to values well above 1.0.

Finally, the compositor draws the scene in back-to-front order or via an off-screen render target. The UI framework places the reconstructed floating-point AVIF texture alongside the 1.0-capped SDR window borders, text glyphs, and controls. The combined framebuffer is sent to the display controller, which outputs the correct drive levels to the panel, achieving localized HDR pop within the image container while preventing surrounding UI components from appearing dim, washed out, or excessively bright.