WEBPery

EXR

.exr

OpenEXR from Industrial Light & Magic — the VFX-industry standard for 32-bit floating-point HDR image storage and multi-channel render passes.

specializedbothTransparency

Origin and design intent

OpenEXR (.exr) was developed by Industrial Light & Magic (ILM) in 1999–2002 to solve a specific problem in visual effects production: existing image formats could not store the full dynamic range and colour fidelity that modern film rendering produces.

A digital camera capturing a real-world scene records intensities across a range of perhaps 1000:1 from darkest to brightest. A film camera captures around 10,000:1. A computer-generated rendering can produce intensities across millions or billions of orders of magnitude — light sources, reflections, refractions, and shadows that exceed any physical camera's dynamic range. Storing these values requires more bits per channel than the 8-bit JPEG/PNG world supports, and it requires a numeric representation that handles extreme values gracefully.

OpenEXR's design priority is high dynamic range storage with full editing fidelity. The format became open-source in 2003 and was donated to the Academy Software Foundation in 2019. It is the industry-standard format for VFX, animation, colour grading, and any pipeline where bit depth and dynamic range matter more than file size.

OpenEXR won the Academy Award for Technical Achievement in 2007 — one of the few image formats with an Oscar.

File structure

An EXR file consists of:

  • Magic bytes (4 bytes) — 0x762f3101.
  • Version field (4 bytes) — version number and feature flags.
  • Header — a sequence of attribute name/type/value triples. Common attributes include channels, compression, dataWindow, displayWindow, lineOrder, pixelAspectRatio, screenWindowCenter, screenWindowWidth.
  • Optional offset table — for tiled or multi-part files.
  • Pixel data — the actual image content, organised by channel.

The channel system is OpenEXR's most distinctive feature. Each channel is stored separately with its own pixel type, allowing files to contain:

  • Standard RGB or RGBA.
  • Multiple alpha channels for compositing.
  • Depth channels (Z-buffer) for 3D scene reconstruction.
  • Motion vector channels for motion blur and frame interpolation.
  • Object IDs for re-coloring or masking specific scene elements.
  • Custom AOVs (Arbitrary Output Variables) from renderers — diffuse, specular, indirect light, ambient occlusion, sub-surface scattering, each as a separate channel.

A single EXR file from a renderer might contain 20 or more channels, allowing compositors to fine-tune the final image without re-rendering.

Pixel types

OpenEXR supports three numeric representations per channel:

  • HALF — 16-bit floating point. The most common choice. Captures roughly 30 stops of dynamic range with reasonable precision. Files are half the size of 32-bit float files.
  • FLOAT — 32-bit IEEE single-precision float. Used when extreme precision matters (deep compositing, scientific imaging, very wide dynamic range). Files are twice the size of HALF.
  • UINT — 32-bit unsigned integer. Used for ID channels and similar non-image data.

The HALF format is OpenEXR's signature contribution. Until OpenEXR, 16-bit floating point wasn't a standard data type — ILM defined a specific IEEE-754-like layout (1 sign bit, 5 exponent bits, 10 mantissa bits) that became widely adopted in GPU and ML contexts.

Compression options

EXR supports several lossless and lossy compression methods:

  • NONE — uncompressed.
  • RLE — run-length encoding. Fast, modest compression on flat content.
  • ZIPS — DEFLATE compression on each scanline. Good for organic content.
  • ZIP — DEFLATE compression on blocks of 16 scanlines. Better compression than ZIPS.
  • PIZ — wavelet-based compression. The default for many pipelines; produces good results on noisy content.
  • PXR24 — lossy. Truncates 32-bit floats to 24 bits.
  • B44, B44A — lossy. Fixed compression ratio designed for real-time playback.
  • DWAA, DWAB — lossy. The most recent additions, similar to JPEG but operating on floating-point HDR data.

The choice depends on workflow: ZIP for archival, PIZ for general use, DWAA/DWAB for delivery where some lossy compression is acceptable. The lossy options are still designed to preserve HDR fidelity — they discard imperceptible detail, not the dynamic range itself.

Tiled vs scanline storage

EXR supports two storage layouts:

  • Scanline — pixel data ordered row by row. Simple, standard for most images.
  • Tiled — pixel data organised into rectangular tiles. Allows efficient random access to portions of very large images, supports mipmaps and ripmaps for level-of-detail rendering.

Tiled EXR is the standard for high-resolution VFX work (4K-16K renders), texture mapping in production rendering, and any pipeline where partial-image access matters.

Multi-part EXR

Modern EXR files can contain multiple "parts" — essentially multiple images packaged in a single file. Each part has its own dimensions, channels, and compression. Used for:

  • Stereoscopic content — left-eye and right-eye images in one file.
  • Deep images — multiple depth samples per pixel for advanced compositing.
  • Multi-layer renders — beauty passes, technical passes, and utility passes as separate parts.

This is OpenEXR's most powerful feature and the reason it dominates VFX production.

Browser support

Most web browsers do not render EXR natively. Chrome and Edge added experimental support for HDR images via the image/hdr-rgb and related MIME types in recent versions, but support is incomplete and not aimed at OpenEXR specifically.

For web delivery of HDR content, the practical formats are:

  • AVIF — supports 10-bit and 12-bit HDR encoding with broad browser support.
  • JPEG XL — supports HDR; browser support is limited.
  • WebP — does not support HDR.

EXR is a production format. For web delivery of HDR content originating from EXR, the workflow involves rendering or tone-mapping the EXR to a web-compatible HDR format like AVIF.

Modern relevance

EXR matters for:

  • Visual effects (VFX) production — the industry-standard format for film, television, and high-end advertising.
  • 3D rendering and animation — output format for V-Ray, Arnold, Cycles, Renderman, and other physically-based renderers.
  • Compositing pipelines — Nuke, Fusion, After Effects HDR workflows.
  • Game engine HDR captures — screenshot and reference frame storage.
  • HDR photography — bracketed exposures merged to HDR are often saved as EXR.
  • Image-based lighting (IBL) — environment maps for 3D rendering.
  • Scientific imaging — astronomy, microscopy, any domain capturing high-dynamic-range data.
  • AI/ML training datasets — synthetic data generation pipelines often produce EXR with multiple channels per sample.

EXR does not matter for:

  • Standard web delivery — file sizes are large; browsers don't render it.
  • End-user photography sharing — JPEG, HEIC, and AVIF handle consumer HDR.
  • General document or email use — not viewable in any common tool.
  • Web design — use AVIF or WebP for content delivery.

File size

EXR files are large by web standards but reasonable for their target use cases. Rough sizes for a 4K (3840×2160) image:

  • EXR HALF, PIZ compression — 30–80 MB depending on content.
  • EXR FLOAT, ZIP compression — 100–250 MB.
  • AVIF HDR at high quality — 1–4 MB.
  • JPEG at q=90 — 1–2 MB.

The size difference reflects what's stored. EXR preserves every photon's worth of intensity data across the full dynamic range, suitable for further processing. AVIF or JPEG stores a tone-mapped derivative suitable for display but not for further editing.

Conversion guidance

For getting EXR content into web-friendly formats:

  • Tone-mapping — the EXR's HDR range must be compressed to fit the dynamic range of the target format. This is a creative step, not a mechanical one. Tools include Photoshop's HDR Toning, Affinity Photo, Photomatix, or built-in tone-mapping in VFX tools like Nuke.
  • Direct export from VFX/3D tools — most production tools export to JPEG, PNG, WebP, or AVIF with built-in tone-mapping.
  • OpenImageIO (oiiotool) — command-line tool for batch EXR processing: 
    oiiotool input.exr --tonemap reinhard --colorconvert linear sRGB -o output.jpg

For Node-based pipelines, Sharp does not support EXR directly. Use OpenImageIO or ImageMagick (which uses OpenEXR libraries under the hood):

# Basic EXR to JPEG via ImageMagick (note: tone-mapping is naive)
convert input.exr -quality 90 output.jpg

# EXR to WebP (HDR data clipped to SDR)
convert input.exr -quality 80 output.webp

The conversion from HDR EXR to SDR formats inherently loses information. Plan for the conversion as part of the artistic workflow, not as an automated build step.

When to use EXR today

Choose EXR when:

  • The content is high dynamic range and the workflow benefits from preserving it.
  • The file is going through VFX or 3D rendering pipelines.
  • Multiple channels (beauty pass, depth, AOVs) need to travel together.
  • Editing or compositing will happen downstream.
  • Scientific or technical imaging is involved.

Choose other formats when:

  • The image is for web delivery (use AVIF for HDR, WebP/JPEG for SDR).
  • The image is final and won't be processed further.
  • The file is for end-user consumption.
  • Storage efficiency matters more than fidelity.

Further reading