The HDR file (.hdr, .pic)

A .hdr file is most often a Radiance RGBE image. Greg Ward created the format for Radiance, the lighting simulation software he began writing at Lawrence Berkeley National Laboratory in 1985, to store how much light reaches each pixel rather than what a screen should show. It was the first widely used high-dynamic-range image format, and for years the only one.

Its trick is the shared exponent: each pixel stores three 8-bit numbers for red, green and blue plus one 8-bit exponent that scales all three. That gives an enormous range of brightness in 4 bytes per pixel, the same size as an 8-bit RGBA PNG before compression. Today the format's biggest use is HDRI environment maps: panoramic photos of real places, used to light and surround 3D scenes in Blender, game engines and product rendering.

Three things a Radiance .hdr file is not:

• Not an "HDR photo" from a phone. Phones save HDR pictures as JPEG or HEIC files, sometimes with a gain map for HDR screens.
• Not an ENVI or Analyze header. Remote-sensing and medical imaging software use .hdr for a header file that sits next to the image data.
• Not an OpenEXR file. EXR is the other common HDR format, with more precision, alpha and layers.

To store a pixel, take its largest component and write it as a fraction between 0.5 and 1 times a power of two. That power, plus 128, becomes the exponent byte. Each component is then divided by the same power of two and multiplied by 256 to give its 8-bit mantissa. Here's the example from the Radiance documentation, (1.0, 0.5, 0.25):

encode (1.0, 0.5, 0.25)
  largest value:  1.0 = 0.5 × 2^1      exponent byte = 1 + 128 = 129
  mantissas:      value × 256 / 2^1    1.0 → 128, 0.5 → 64, 0.25 → 32
  stored bytes:   80 40 20 81

decode 80 40 20 81
  value = mantissa × 2^(exponent − 136)
  128 × 2^(129 − 136) = 128 / 128 = 1.0
   64 × 2^−7 = 0.5      32 × 2^−7 = 0.25

four times as bright, (4.0, 2.0, 1.0)
  4.0 = 0.5 × 2^3                      exponent byte 131
  stored bytes:   80 40 20 83          same mantissas, exponent + 2

What follows from this design:

• Huge range. The exponent byte runs from 1 to 255, covering about 76 orders of magnitude, far more than any real scene. An exponent of 0 means black.
• About 1% precision. The largest component always gets 8 significant bits, so it's stored to within 1%. That's fine for light, which the eye judges in ratios.
• Weak colours next to strong ones lose detail. In a pixel like (100, 0.01, 0), the exponent is set by the 100, and 0.01 rounds to 0. Saturated, very bright colours can show slight colour noise.
• No negative values and no alpha. Every component must be zero or positive, and there's no fourth channel for transparency.
• Small rounding differences. Radiance's own decoder adds 0.5 to each mantissa before scaling, to land in the middle of the rounding step; many other readers don't, so values can differ by a fraction of a percent between programs.

The header is plain text, one setting per line, ended by an empty line. Radiance's own tools also record the commands that made or processed the picture, so a header can be a small history of the image. Then comes the resolution string, which sets both the size and the orientation:

Almost every file uses the standard form, and some readers support nothing else. The pixels themselves are usually compressed with the newer run-length encoding: each scan line starts with 02 02 and its width, and the red, green, blue and exponent bytes are each encoded separately, in runs (code above 128) and literal stretches (code up to 128). Separating the components makes runs much more likely, because exponents and mantissas change at different rates.

• Only widths from 8 to 32,767 are run-length encoded. Narrower or wider images are stored as flat 4-byte pixels.
• Older files (Radiance 1.4 and earlier) used a different scheme, in which a special pixel repeats the previous one. Readers still support it.
• It's lossless, but the RGBE conversion before it isn't: a floating-point image converted to .hdr keeps 8 significant bits per pixel.

An HDRI (high-dynamic-range image) environment map is a 360° panorama, usually stored as an equirectangular image twice as wide as it is high, made by merging photos taken at several exposures. Because the file keeps the true brightness of the sun, sky and lamps, a 3D renderer can use it as the light source: objects get realistic reflections and shadows that match the place where the panorama was shot.

• In Blender: add an Environment Texture node to the World and load the .hdr file.
• In game engines: Unity and Unreal Engine import .hdr panoramas for skyboxes and image-based lighting.
• Online libraries of free HDRIs commonly offer each panorama as both .hdr and .exr, in sizes from 1K to 16K or more.

Why .hdr rather than EXR for this? The files are reasonably small, every 3D application reads them, and 1% precision is plenty for lighting. EXR wins when you need alpha, more precision or more compression options.

If a .hdr file won't open as an image, check its first bytes in a text editor or with head -c 16 file.hdr:

"HDR" on a phone means something different. A phone's HDR mode merges several exposures into one photo saved as a normal JPEG or HEIC. Newer formats such as Android's Ultra HDR add a gain map inside the JPEG, so HDR screens can show brighter highlights while ordinary viewers see the standard picture. None of these are .hdr files.

A 16-bit TIFF or PNG has fine steps but stops at white, so it isn't HDR in the same sense: there's no way to store a value brighter than the brightest the format allows.

• It won't open. The file may start with #?RGBE, which some readers reject; changing that first line to #?RADIANCE in a hex editor usually fixes it. It may also be an XYZE file or not a Radiance image at all (see the table above).
• It looks too dark or too bright. An HDR image has no single correct brightness. Viewers pick an exposure; adjust it, or apply a tone-mapping operator when converting to JPEG or PNG.
• It looks flat or washed out. The values are linear light. A viewer that doesn't apply the sRGB curve shows them dark; one that applies it twice shows them pale.
• It's upside down or rotated. The resolution string isn't the standard -Y … +X …, and the reader ignored it.
• The sun or lamps look white and flat in an export. Values above 1.0 clip in 8-bit formats. That's expected; the detail is still in the .hdr file.
• There's no transparency. RGBE has no alpha channel. Use EXR for images that need one.

• View it: free HDR viewers such as tev let you change the exposure. Photoshop opens .hdr in 32-bit mode, and GIMP (since 2.10) and Affinity Photo open it too.
• Use it for 3D lighting: Blender, Unity, Unreal Engine and most renderers load it directly as an environment map.
• Make one: merge bracketed exposures in Photoshop (Merge to HDR Pro), in dedicated HDR software, or render one from Blender.
• Convert it on the command line: OpenImageIO (pip install OpenImageIO) or ImageMagick.

# inspect the size and channels
oiiotool --info -v sky.hdr

# HDR to EXR (half float, no loss of range)
oiiotool sky.hdr -d half -o sky.exr

# HDR to an 8-bit sRGB PNG, one stop darker first
oiiotool sky.hdr --mulc 0.5 --tocolorspace sRGB -d uint8 -o sky.png

Like other image files, .hdr files contain no scripts. The text header can name the software, commands and sometimes file paths used to make the image; check it with a text editor before sharing.