AVIFify

HDR

.hdr

Greg Ward's 1989 RGBE format was one of the first to capture extended dynamic range, and it endures for 3D environment maps and image-based lighting.

specializedlossless

Radiance HDR (.hdr) is a 32-bit-per-pixel image format that records real light intensities, not display colours — the file a 3D renderer reads to light a scene. Greg Ward created it in 1985 for the Radiance lighting simulator, and its RGBE encoding still ships most environment maps today. This page separates two things people call "HDR" — the .hdr file format and the HDR display capability — and explains why the web reaches the second through AVIF, never through .hdr itself.

Two meanings of "HDR"

"HDR" names a file format and a display capability, which are unrelated technologies:

  • HDR the format — Radiance .hdr, a scene-referred container of linear light values for 3D rendering.
  • HDR the display — a screen that shows BT.2100 content at up to 10,000 nits with a wide gamut.

A .hdr light probe never appears on an HDR phone screen directly. A web HDR photo is an AVIF, not a .hdr. Confusing the two is the single most common Radiance HDR misconception.

Why Greg Ward invented it

Ward built .hdr in 1985 at Lawrence Berkeley National Laboratory so the Radiance renderer could store physical luminance. A standard 8-bit pixel maxes out at value 255; a sunlit cloud is thousands of times brighter than a shadowed wall, so 8-bit clips the scene. Radiance simulates daylight, glare, and architectural lighting, which demand the actual candela-per-square-metre figure, not a clamped 0–1 approximation. The .hdr file answered that need years before consumer HDR existed, per the Radiance file-formats reference.

How RGBE packs 76 orders of magnitude

RGBE stores each pixel as three 8-bit mantissas plus one 8-bit exponent shared across all channels:

  • R, G, B — one mantissa byte each, the linear colour ratios.
  • E — one exponent byte, a brightness scale applied to all three.

The decoded value is channel / 256 × 2^(E − 128). That packs a dynamic range above 10^38 — roughly 76 orders of magnitude — into just 32 bits, at about 1% accuracy, per the RGBE image format article. The cost: one shared exponent means a pixel that is bright red but dim blue quantises the blue coarsely. For lighting reconstruction the error is invisible; for editing masters, per-channel float (EXR) is stricter.

What the format is actually used for

The live job for .hdr files is image-based lighting (IBL): using a 360° photo of real light to illuminate a 3D scene. Examples: a studio HDRI lighting a car render, an outdoor sky probe lighting a building visualisation, a museum capture grading reflections on glass. Renderers that consume .hdr environment maps include Blender, Unreal Engine, Unity, Maya, and Houdini. Bright pixels in the probe cast bright light; the result beats hand-placed synthetic lamps for realism, which is why .hdr survives 40 years after release.

Why .hdr is not a web image format

No mainstream browser renders .hdr through an <img> tag — its MIME type image/vnd.radiance has no decoder in Chrome, Safari, or Firefox. Two reasons: the format is scene-referred linear light, not display-ready pixels, and it has no perceptual compression, so files run tens of megabytes. A browser would still have to tone-map every pixel before painting. The web therefore treats .hdr as a source asset, not a delivery format — exactly the role PNG plays for masters versus JPG for delivery.

How AVIF carries HDR to browsers

AVIF is the format that delivers HDR-display content to the web, where .hdr cannot. It inherits AV1's high-bit-depth pipeline:

  • 10-bit and 12-bit colour — enough tonal range for HDR without the banding 8-bit shows.
  • BT.2100 transfer functions — PQ (SMPTE ST 2084, up to 10,000 nits) and HLG for HDR signalling.
  • BT.2020 wide gamut — the colour primaries HDR displays expect.

AVIF is, per its specification overview, the web image format that correctly handles PQ/HLG HDR. The distinction matters: .hdr stores unbounded scene light for a renderer; AVIF stores bounded, tone-mapped display light for a screen. One feeds 3D software; the other feeds eyes.

From .hdr to AVIF: the pipeline

Getting Radiance HDR onto an HDR web page takes a tone-map step plus an HDR-aware AVIF encode:

  1. Tone-map the scene-referred .hdr to display-referred values (Reinhard, ACES, or Blender's Filmic).
  2. Assign BT.2100 PQ or HLG with BT.2020 primaries.
  3. Encode AVIF at 10-bit, keeping HDR metadata intact.

For ordinary (SDR) delivery, tone-map and export to WebP or JPG instead. Once you have AVIF masters or sources, these in-browser converters run locally with no upload: Convert AVIF to JPG, Convert AVIF to PNG, Convert JPG to AVIF, Convert PNG to AVIF. Encoder controls live in AVIF Compression Settings and AVIF Optimization.

Frequently asked questions

Can a browser open a .hdr file? No. Chrome, Safari, and Firefox have no image/vnd.radiance decoder; .hdr must be converted first.

Is Radiance HDR the same as an HDR photo on my phone? No. The phone shows AVIF or HEIC HDR; .hdr is a renderer input, not display media.

Does AVIF replace .hdr for 3D lighting? No. AVIF carries HDR to screens; renderers still need linear .hdr or EXR light probes.

How is .hdr different from EXR? RGBE shares one exponent across RGB; EXR uses independent per-channel float and extra channels. See EXR.

Should I compare AVIF and WebP for HDR delivery? Yes — only AVIF handles PQ/HLG; see AVIF vs WebP.

Authoritative references