Why AI-edited iPhone photos lose HDR

iPhone HDR photos are not just brighter JPEGs. They usually rely on extra metadata or a gain map that tells compatible displays how to render highlights above normal SDR brightness. Many AI image editors return a flattened SDR export, so the edited file can look technically correct but visually dull.

What HDR means in this context

In normal SDR images, each pixel is expected to land inside a standard brightness range. If a sky, reflection, or light source should appear extra bright, the file mostly has to fake that with tone and contrast inside the same range as everything else.

HDR photo formats add another layer. In a gain-map based HDR image, the file contains a base SDR image plus extra data describing how much brighter parts of the image should become on an HDR-capable display. A compatible viewer can combine the base image and the gain map at display time. A non-HDR viewer can still show the base SDR image.

# Simplified mental model, not the exact ISO text:
display_rgb = sdr_rgb * gain
gain        = exp2(gain_map_value * gain_range + gain_min_log2)

# If gain is 1.0, the HDR view matches the SDR base.
# If gain is 2.0, that region may render about one stop brighter
# on a display path that supports HDR photo presentation.

Why AI editors often flatten the file

Most image-generation and image-editing models operate on regular RGB tensors, not on the full container structure of the original photo. The service decodes your image, edits pixels, then writes a new output file. Unless the product explicitly preserves or regenerates HDR metadata, the safest export path is a normal SDR PNG or JPEG.

That means the edit can be semantically right while the display behavior changes. Faces, background, clothing, or composition may look better, but bright regions no longer lift above the normal SDR presentation.

One way to see the problem is to inspect the edited export instead of only looking at it. The exact output depends on the app, but a flattened export often has ordinary dimensions and color tags with no obvious secondary HDR payload.

$ exiftool original-iphone-photo.jpg | egrep "HDR|Gain|Color|Profile|Aux"
Profile CMM Type                 : Apple Computer Inc.
Color Space Data                 : RGB
HDR Gain Map Version             : ...
Auxiliary Image Type             : ...hdrgainmap...

$ exiftool ai-edited-export.jpg | egrep "HDR|Gain|Color|Profile|Aux"
Color Space Data                 : RGB
# no gain-map / auxiliary HDR payload visible

How to tell if this happened

Compare the original and the edited export on the same HDR-capable device, with screen brightness and app/viewer kept the same. Do not judge from screenshots; screenshots usually collapse the comparison back into SDR.

• Look at sky, water, glass, lights, white clothing, food highlights, snow, sunsets, and reflections.
• If the edited version has similar composition but less highlight intensity, the HDR path was probably lost.
• If both versions look identical in a non-HDR viewer, that does not prove the HDR data is present or absent.

What HDRPop reconstructs

HDRPop starts from the edited SDR image and estimates where an HDR display should apply additional brightness. It then creates an Ultra HDR JPEG with a base SDR image and a gain map. The base image keeps compatibility with normal JPEG viewers; the gain map gives compatible viewers a way to render extra highlight range.

This is not the same as recovering the exact original HDR capture. If an AI edit clipped a white sky into a featureless patch, no tool can recover detail that is no longer present. The useful case is different: the edit still contains believable tones and structure, but it lacks HDR display instructions.

# Pseudocode for the reconstruction step:
sdr = read_rgb("ai-edited-export.jpg")
luma = estimate_luminance(sdr)
structure = preserve_edges_and_faces(sdr)

gain_map = predict_hdr_gain(luma, structure)
gain_map = smooth_without_bleeding_across_edges(gain_map)

write_ultra_hdr_jpeg(
    base_image=sdr,
    gain_map=gain_map,
    fallback="normal SDR JPEG"
)

The interesting constraint is that the gain map should not simply brighten the whole frame. Faces and midtones usually need restraint; specular highlights, sky gradients, water reflections, and small light sources can tolerate more lift. A bad gain map looks like a contrast filter. A useful gain map behaves more like display metadata.

What about Instagram and Threads?

HDR photos are supported in some Instagram and Threads paths on compatible devices. Meta has described HDR photo support for Instagram and Threads, including HDR upload and display behavior.

The annoying part is that support still depends on the whole chain: your file, the app version, the upload path, the viewer's device, display settings, and sometimes platform-specific processing. So the correct test is not “does this webpage say Instagram supports HDR?” The correct test is posting or previewing the actual output on the device and account you care about.

A reasonable workflow

1. Keep the original iPhone photo.
2. Run the AI edit and save the edited output.
3. Compare the original and edited output on an HDR-capable display.
4. If the edit is good but flat, run the edited output through HDRPop.
5. Open the restored JPEG in Photos, Preview, Chrome, or the social app you plan to use.
6. Only trust the result after viewing the actual file, not a screenshot of it.

Limitations

• HDRPop estimates a gain map; it does not restore the original camera gain map byte-for-byte.
• It cannot make non-HDR screens show HDR.
• It cannot force every social platform or every upload path to preserve HDR display.
• It cannot recreate detail destroyed by clipping, heavy compression, or aggressive AI edits.