HDR Images, and What Happens When They Are Not Tone-Mapped

We built a test scene where the sun sits about three stops past what an ordinary 8-bit picture can represent, then ran it through FileFlip's actual conversion path with nothing else applied. Half that frame, 51.8% of it, came back as flat white with no shape left in the sun at all. One extra step, a tone curve run before the final save, brought that number to zero.

Should you tone-map before you convert, or just convert?

Tone-map first when:

• The source is a real scene-referred HDR file, an .hdr, an OpenEXR render, a RAW capture, with values brighter than "1.0" in it, and the target is a hard 8-bit format like JPG or plain PNG. Convert HDR to PNG will not do this for you. It clips, which is exactly what we measured below.

Just convert, no extra step needed, when:

• The file is a phone's gain-map HDR photo, HEIC or JPEG, and a normal-looking picture is all you need. Convert HEIC to JPG keeps the SDR base photo intact; you only lose the extra brightness a compatible screen would have added.
• The source carries an HDR-capable extension but no pixel in it ever went past "1.0", which is common. Nothing to tone-map, nothing to lose.

HDR, AVIF, HEIC and JPG at a glance

JPG is the only one of the four with no HDR capability and no lossless mode, the whole reason a conversion into it is one-way. What the table can't show is how much extra brightness the other three actually hold, further down this page.

What does converting HDR straight to an 8-bit format throw away?

Every value above the format's ceiling, with nothing to show where it used to be.

Our test scene's sun sits almost 3 stops above the 1.0 ceiling an 8-bit format has, saved as a genuine Radiance .hdr file. Converting it the way FileFlip's own image worker does, reading it and writing straight to an 8-bit target with no extra step, clipped 119,404 of 230,400 pixels, 51.8%, to a flat 255, 255, 255. Every one of those pixels reads identically. Whatever shape the sun had is gone.

A tone-mapping curve like the Reinhard pass compresses the top of the range harder than the bottom, so the highlight keeps its shape and the shadows stay put. Clipping isn't the only failure, either. The "linear rescale" column is the other common fix: scale every value down until the brightest pixel fits under 1.0, then convert. Nothing clips, but 1.9% of the same frame, the darkest sky, crushes to within 5 levels of pure black, and the whole middle of the range moves down with it. That flat, low-contrast look is what "washed out" means, and it comes from treating a wide range and a narrow one as if one multiplication could reconcile them.

How many stops of dynamic range does an HDR image actually need to hold?

More than an SDR screen shows, by design.

An SDR display targets 100 cd/m² reference white. PQ, the curve behind HDR10 and Dolby Vision, targets a reference display up to 10,000 cd/m², about 6.6 stops higher, for what that source calls spectral highlight detail: chrome, sunlit clouds, a bare filament, the kind our synthetic sun stands in for. Real gain-map photos use less: a public ISO 21496-1 test set spans 2.3 to 4.0 EV.

Which formats can actually hold that many stops?

Three of our four can, each a different way.

Radiance's RGBE format stores each pixel as an RGB mantissa plus one shared exponent, which is why our sun and a sky a thousand times dimmer sat in the same file with no ceiling forcing a choice. AVIF carries real 10 or 12-bit samples under the AV1 Image File Format spec, tagged with the curve that says how to read them. JPG has none of this: 8 bits, one gamma curve, a hard stop at 255.

Whoever converts a file last is responsible for tone-mapping it, unless something upstream already did that job. A phone's camera app does it automatically writing a plain JPEG, which is why a backlit photo looks reasonable straight off the camera despite being ordinary SDR. A raw HDR file, our .hdr scene included, has had none of that done yet. FileFlip's own HDR reference page says to convert it "once the image has been tone-mapped for a normal display," and the converter itself does not do that step. It reads and writes pixels, nothing more.

What is a gain map, and what happens to it when you convert the photo?

A gain map is a second, much smaller image riding alongside your photo: a per-pixel map of how much to brighten the SDR rendition to reach the target HDR one, stored in log2 space so a display can scale the boost to its own peak brightness rather than one fixed amount, per Google's Ultra HDR spec. Apple's own developer documentation describes the same mechanism under the same name: a recent iPhone saves a complete, ordinary SDR photo with a small, quarter-resolution grayscale image bundled beside it, and anything that doesn't look for that second image just shows the first.

We downloaded a real ISO 21496-1 gain-map JPEG from that same test set and ran it through FileFlip's exact conversion path, ImageMagick.read then image.write, no options touched, the call the app makes if you never open Advanced settings. exiftool confirmed the 6,689,603-byte source held two images: the primary photo and a 2,467,056-byte gain map, 37% of the file, tagged MP Image Type: Gain Map Image. ImageMagick flags the same thing on read, reporting jpeg:hdrgm: true. After conversion, at the identical quality setting the source used, both signals were gone: the 4,750,364-byte output carried no gain map field at all, only the base photo.

The base image is built to survive exactly this: a complete, correct SDR photo on its own, so anything that doesn't understand the gain map still gets a normal picture. What you lose is the extra brightness a compatible screen would have added, and it doesn't come back from the JPG or PNG on the other side.

What you lose converting an HDR file, and what to watch for

• Highlight detail, permanently, from a direct HDR conversion. Our measurement above clipped over half a frame to solid white with no warning in the output. Tone-map real overexposed detail before converting, not after.
• The gain map, permanently, from a HEIC or gain-map JPEG conversion. It does not travel through a plain re-encode, and there is no way to reattach it once it's gone.
• File size, in the other direction. Our real gain-map photo lost 29% of its size dropping the gain map, a rough sense of how much of a typical iPhone HDR photo the gain map accounts for.

Common questions

Is an HDR photo the same thing as an .hdr file?

No. An .hdr file is one specific format, Radiance's RGBE encoding, built for 3D lighting and environment maps rather than photography. An "HDR photo" off a phone is usually an ordinary HEIC or JPEG carrying a gain map, a different mechanism solving a similar problem. See colour profiles, and why your photo changed colour for the related case of a tag, not a format, deciding how a photo's numbers get read.

Can I recover the clipped highlights after converting an HDR file to PNG?

No. Once a pixel is written as 255, 255, 255, any value it held above that is gone. Go back to the original HDR source and tone-map before converting again, rather than editing the PNG.

Does my screen need to support HDR to see any of this?

Only to see the extra brightness. A gain map's base image is ordinary SDR and displays correctly everywhere. Converting to JPG or PNG with FileFlip sidesteps the whole question, since the output is always plain SDR.

How to convert an HDR file or an HDR photo

FileFlip converts HDR to PNG and HEIC to JPG directly in your browser, on a WebAssembly build of ImageMagick. The file never leaves your machine, there's no account, and nothing is queued on a server. Neither route applies a tone-mapping curve; if the source has real overexposed detail worth keeping, apply a tone curve in an HDR-aware editor first, then convert what comes out of that. AVIF and HEIC also carry more bits per channel than JPG regardless of HDR; see bit depth and banding for what that's worth on its own.

See the HDR, HEIC, AVIF and JPG format references for what else each container can hold.

How we measured this

• Test scene: synthetic 640×360 linear-light scene built in ImageMagick, a radial "sun" gradient peaking at 7.97x reference white over a sky bottoming out at 0.0072x reference white, saved as a genuine Radiance .hdr file. About 10.1 stops end to end, log2(7.97 / 0.0072).
• Conversions compared: direct, magick scene.hdr -colorspace sRGB -depth 8 out.png, matching the image worker's plain image.write(target) call, checked against a flag-free magick scene.hdr out.png control that clipped within 0.3% of the same count; linear rescale, dividing by the scene's peak before the same write; Reinhard tone map, value / (1 + value) per channel via -fx, before the same write. Pixel values read back and counted with magick out.png txt:-.
• Gain-map file: image 01 from Eric Chan's public ISO 21496-1 test set, whose ten images span 2.3 to 4.0 EV of headroom. Converted with magick gainmap01.jpg gainmap01_out.jpg, no flags. Gain map presence and size checked with exiftool -a -G1 and magick identify -verbose.
• Tools: ImageMagick 7.1.2-28 Q16-HDRI, ExifTool 13.55, macOS.
• Caveat: the test scene is synthetic, built to isolate clipping, not a real photograph; a real source clips a different share depending on how much of the scene exceeds the format's range. The gain-map file is a public test photo, not our own capture, and the byte counts include some ordinary JPEG re-encoding noise beyond just the missing gain map.

Reproduce it with magick and exiftool from the commands above; there's no dedicated script for this one yet.