What is an EXR File?

An EXR file is a high-dynamic-range image stored in the OpenEXR format: one or more named channels of 16-bit or 32-bit floating-point or 32-bit unsigned integer samples, plus header attributes that describe them. Pixel data can be uncompressed or use one of several lossless or lossy compression methods.

How EXR Files work

An OpenEXR file starts with a four-byte magic number (76 2f 31 01) and a version field whose flag bits mark a single-part tiled file, a multi-part file, or the presence of deep data. The tiled flag is set only for a single-part tiled image; in multi-part and deep files, each part’s type attribute says whether it holds scan lines or tiles. A header of named attributes follows, one per part; channels, compression, dataWindow, displayWindow, lineOrder, pixelAspectRatio, screenWindowCenter, and screenWindowWidth are required in every header. Pixels are stored in chunks, either scan line blocks or tiles, that are located through an offset table. Only tiled files can hold multiple resolution levels (mipmaps or ripmaps); a scan line file holds one. Since OpenEXR 2.0 a file can contain several independent parts and deep data, in which each pixel holds a variable-length list of samples. By convention, color channels are premultiplied by alpha. In production an EXR typically carries rendered or composited frames that are transformed later for display.

Key facts

  1. Do not assume one RGBA image. Each channel declares its own name and type: HALF (16-bit float) for regular image data, FLOAT (32-bit) where more range or precision is needed, such as depth, and UINT (32-bit) for discrete values such as object IDs. Only a few names, such as R, G, B, and A, have a predefined meaning; layers are a naming convention like light1.specular.R, and a multi-part file adds separately named parts. A converter has to be told, or has to choose, which of these become the output image.
  2. Image size comes from two rectangles, not one. The display window is the intended frame; the data window is the region that actually has pixels, and it may be smaller (a rendered region of interest) or larger (overscan kept for blurs or camera shake). Each window is given by the coordinates of its corner pixels, so a display window of (0, 0) to (1919, 1079) is 1920 by 1080. The OpenEXR documentation says pixels beyond the display window are not normally displayed and that a viewer fills display area outside the data window with a default color. Software that sizes its output from the data window alone gives such files the wrong dimensions or placement.
  3. Whether compression is lossless depends on the method and sometimes on the channel type. The header’s compression attribute applies to all of its channels, so a method has to be acceptable for every channel type stored together. PIZ, ZIP, ZIPS, and RLE are lossless. PXR24 keeps HALF and UINT channels exact but rounds FLOAT data to 24 bits. B44 and B44A are lossy for HALF channels and leave UINT and FLOAT channels uncompressed. DWAA and DWAB are lossy, DCT-based methods for RGB data. Deep data permits only uncompressed, RLE, ZIPS, or ZIP. The current documentation also lists newer methods: HTJ2K256 and HTJ2K32 (lossless, High-Throughput JPEG 2000), LJ2K (lossy), and ZSTD (lossless). Confirm that every reader in the pipeline supports the method you write.
  4. By convention, RGB values are linear to scene light, and 1.0 is not a clamp. The OpenEXR convention puts middle gray at 0.18, and bright objects such as fire and highlights legitimately exceed 1.0, so displaying such an image needs at least gamma correction and often tone mapping. This is a convention, not a guarantee: the documentation says images are supposed to be linear, and that the library does not require a declared color space to be a linear one. The file may not reliably say which RGB primaries it uses either: the documentation states that trust in the chromaticities attribute has been lost, that the absence of colorInteropID does not imply linear Rec. 709, and that colorInteropID, new in OpenEXR 3.4, is now the recommended identifier. Agree on the color space, including whether the values are linear, with whoever produced the files instead of inferring it.

When EXR Files matter

Visual-effects pipelines choose EXR for linear-light compositing, render passes, and high-precision intermediates. It is a working format: by convention its color values describe scene light, not a display signal, so producing a viewable derivative takes a deliberate color transform plus a decision about which channels, part, and window to use.

How Transloadit helps with EXR Files

Transloadit’s image formats table, which covers ImageMagick-based Robots such as /image/resize, lists EXR as a format those Robots can read and write. The row names the OpenEXR library version in the ImageMagick build, which bounds the compression methods and attributes that build can know about.

The table reports what the ImageMagick build can read and write. It does not document which channels, part, window, or color transform a conversion uses. Run a representative production file through your Assembly and inspect the result before depending on it.

Explore Transloadit’s file formats & compression capabilities

Sources

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free