Nothing is wrong with the file. Two screens were told different things about it.
Why the Same Photo Looks Different on Every Screen
You take a photograph of a sunset and it is extraordinary on the phone — the sun genuinely bright, the sky still holding its color. You send it to yourself, open it on the computer, and it has gone flat. Nobody edited it. The file has the same name and very nearly the same size. What changed is that the two devices were given different amounts of information about what those numbers in the file are supposed to mean — and since 2023 there has been an entire second layer inside photographs that one screen can read and the other cannot.
A photograph does not store colors
Open any photograph and what is inside it, underneath the compression, is a grid of numbers. A pixel near the middle of that sunset might be 236, 94, 40. Those three numbers are not a color. They are a recipe, and a recipe is useless until you know whose kitchen it was written for.
The missing ingredient is the color space: the agreement that says how much red the number 236 means, how the numbers scale between dark and light, and where the boundaries of the palette sit. Feed 236, 94, 40 into one agreement and you get a particular orange. Feed the identical numbers into a wider agreement and you get a noticeably more saturated one, because in that agreement the maximum is further out.
Microsoft puts some scale on how narrow the common agreement is. In its developer documentation on advanced color, it notes that “mainstream consumer displays can often reproduce colors only within the sRGB gamut, which represents only about 35% of all human-perceivable colors.” That is the baseline almost everything on the web assumes, and it was settled in the 1990s around the capabilities of a cathode-ray tube.
Image formats have a place to write the agreement down. The CSS Color specification describes a tagged image as one “explicitly assigned a color profile, as defined by the image format,” and says this “is usually done by including an International Color Consortium (ICC) profile.” It names the formats that provide for it: “For example JPEG, PNG and TIFF all specify a means to embed an ICC profile.” So the label can travel with the picture. The question is what happens when it does not.
The rule that makes an unlabeled photo sRGB
The answer is written into the specification, and it is unusually direct. Under the heading “Color Spaces of Untagged Colors,” CSS Color Level 4 says: “For compatibility, colors specified in HTML, and untagged images must be treated as being in the sRGB color space unless otherwise specified.” The same section defines the term it is ruling on — “An untagged image is an image that is not explicitly assigned a color profile, as defined by the image format.”
Browser makers implement it exactly as written. Apple’s WebKit team put it in one sentence on their own engineering blog: “If an image doesn’t have a tagged profile, WebKit assumes that it is sRGB.” The reason given is practical rather than photographic — it makes the colors in an image match the colors declared in the page’s stylesheet, so a background image and a CSS background can agree.
The reverse case is handled, and the same WebKit post is candid about how well. “If you serve wide-gamut images to users not on a wide-gamut display, WebKit will color-match the images and show them in the sRGB space.” Then the caveat: “this conversion into sRGB can be done a few ways and isn’t guaranteed to happen identically on other browsers or platforms.” Two browsers, both behaving correctly, both squeezing the same photograph into the same smaller palette, and no promise that they will land on the same answer.
What a gain map actually is
Everything above has been true for two decades. The genuinely new thing, and the reason this problem became noticeable again around 2023, is that phone cameras started writing a second image inside the photograph.
Apple’s developer documentation defines its version in a single sentence: “The Apple HDR gain map is an 8-bit, single-channel luminance map that’s stored with an image.” Single-channel means it has no color of its own — it is a grayscale picture. It is also small: the same page states the gain map “is 1/4 the resolution of the original image.”
What that grayscale picture holds is not brightness. It is instruction. Each of its pixels says how much the corresponding part of the photograph is allowed to be pushed beyond ordinary white if the screen has room. Google’s specification for the same idea describes the pattern plainly: “The brightest areas of the image typically have recovery(x, y) values close to 1.0, while darker areas of the image have values around 0.0.” The sun gets a high number. The pavement in shadow gets nothing.
The word for how much room a screen has is headroom, and Apple defines it precisely: “The headroom is the ratio of the luminance of the image’s brightest white to the luminance of standard dynamic range (SDR) white, in the image’s native color space.” Apple then publishes the arithmetic that combines the two, and it is one line:
hdr_rgb = sdr_rgb * (1.0 + (headroom - 1.0) * gainmap)Look at what happens when the headroom is 1 — an ordinary screen with no room to spare. The bracket collapses to 1.0, every multiplier becomes 1, and the result is exactly the ordinary picture. The gain map has not been ignored. It has been applied, and correctly evaluated to no change.
That is the whole mechanism. One normal photograph, one small grayscale instruction sheet, and a number describing the screen. The same file resolves to a restrained image on a laptop in an office and a vivid one on a phone held up outdoors, and both are the intended output.
Three companies, one standard, July 2025
The complication is that this good idea was invented more than once, at roughly the same time, by companies who ship most of the world’s photographs. Apple documented its Apple HDR gain map. Google published Ultra HDR, introduced — in its own words — “with Android 14.” Adobe promoted a gain map approach for its editing tools. Same concept, different containers, different metadata, different assumptions about what the reader already knows.
Google’s format is a worked example of how the container problem is solved. Its specification opens by stating that the document “defines the behavior of a new file format that encodes a logarithmic range gain map image in a JPEG image file,” and the packing is described exactly: “The gain map is stored in a secondary image JPEG, and therefore must be encoded using 8-bit, unsigned integer values, thus in the range [0, 255].” A photograph, with a second small photograph riding inside it.
Three dialects is one too many for a photograph that gets sent between families on different phones, and the industry appears to have agreed. Apple’s own documentation carries a note saying the technique it describes “has been proposed for standardization at the International Organization for Standardization (ISO) as part of ISO/NP 21496-1.”
That proposal is no longer a proposal. ISO’s catalogue entry for ISO 21496-1:2025, titled Digital photography — Gain map metadata for image conversion — Part 1: Dynamic range conversion, records the status as Published, edition 1, sixteen pages, from technical committee ISO/TC 42. Its abstract states that the document “defines a gain map used in HDR digital photography applications, for dynamic range conversion between two image representations,” including “how to specify the gain map and associated metadata, and how to apply the gain map using this metadata.”
The dates in its own life cycle are worth a glance. The project was approved on 6 July 2023. The International Standard was published on 7 July 2025. Two years and a day, for sixteen pages, to agree on how to write down a grayscale multiplier.
The dull version is the designed outcome
Here is the part that reframes the whole complaint, and it is stated openly in the engineering documents rather than hidden.
Google’s Ultra HDR specification lists the requirements the file format had to meet, and the first one is this: “Be backward compatible, so that on naive viewers, the conventional SDR image is displayed.” The introduction says the same thing from the other side: “Legacy readers that don’t support the new format read and display the conventional low dynamic range image from the image file. Readers that support the format combine the primary image with the gain map and render a high dynamic range image on compatible displays.”
Google’s guidance for app developers puts it in plain language for the device case: images display “in their full intensity” on Android 14 or higher with a screen that supports HDR, and “on other devices, the images still display, but they’re shown in standard dynamic range.”
So the flat version on the old laptop is not damage and not a bug. It is the fallback doing precisely the job it was specified to do. Somebody sat down and decided that a picture which is merely ordinary everywhere is better than a picture which is spectacular on new hardware and broken on everything else — and given how photographs actually travel between people, that was the right call.
It does leave a real gap between what you saw when you pressed the shutter and what the recipient sees, and nothing in the file can close it. The recipient’s screen has no headroom. There is nowhere for the highlights to go.
What survives a share, and what does not
Both layers — the color profile and the gain map — are extra material wrapped around the pixels, and both are vulnerable to the same thing: software that rebuilds the file rather than copying it.
A byte-for-byte copy is safe by definition. Move a photograph onto a drive, into a folder, onto a memory card, and every one of those bytes arrives, including the profile and including the secondary image holding the gain map. Nothing has been asked to make a decision.
A re-encode is a different act. The image is decoded to raw pixels, the container is thrown away, and a new file is written from scratch. Whatever was in the old wrapper exists in the new one only if the code that wrote it deliberately carried it over. There is no rule of nature keeping it there.
| What the software does | The color profile | The gain map |
|---|---|---|
| Copies the file — drive to drive, card to PC | Survives. It is part of the bytes | Survives, for the same reason |
| Re-encodes to save space — typical of chat and social routes | Kept only if the encoder writes it back | Frequently the first thing dropped, because it is a whole second image |
| Converts between formats — for instance HEIC to JPEG for compatibility | Usually rewritten to something the target format supports | Depends entirely on whether the converter knows the concept exists |
| Edits and re-saves | Normally preserved or deliberately replaced | Must be recomputed for the edited pixels, or it describes a picture that no longer exists |
The fourth row is the interesting one, and it is not a matter of carelessness. A gain map is a per-pixel description of a specific image. Brighten that image, crop it, or rotate it, and the old map no longer lines up with anything. Carrying it across unchanged would be worse than dropping it. Recomputing it is real work that an editor has to have been built to do.
None of this is visible from the outside. A photograph that has lost both layers opens instantly, looks perfectly reasonable, and gives no indication that it is now a smaller claim about the world than the file it came from. The same is true of the dates inside it, which is the subject of what photo exports actually give you.
What Windows does with all of this
Most people reading this are looking at the disappointing version of their photograph on a Windows PC, so it is worth being specific about what that platform does and when it started doing it.
Microsoft’s documentation dates the support: “Windows 10, version 1709 first shipped Advanced Color support for HDR displays,” and “The Windows 11, version 22H2 release adds Advanced Color support for SDR displays that have accurate provisioning data.” That second clause carries a condition most machines do not meet. The same documentation explains that accurate data from a manufacturer-supplied display profile is needed, and that consequently “only SDR displays that have been specifically provisioned by the manufacturer or a display calibration provider with a valid profile are eligible for auto color management.”
There is also a quiet unit conversion sitting underneath the whole thing. Microsoft’s table of luminance behavior says that on an SDR display the value 1.0 is interpreted “as the reference white level of the display,” while on an HDR display it is interpreted “as 80 nits (nominal reference white).” Reference white itself is defined as “the brightness at which a diffuse white object (such as a sheet of paper, or sometimes UI) appears in an HDR scene.”
That difference is the mechanism behind the other common complaint, which is the opposite of the one this article started with: switch a Windows machine into HDR mode and ordinary content can look washed out and gray. Nothing has been corrupted. Content authored against one definition of white is being shown on a screen using another, and the two definitions were never the same number.
What we could not establish, and will not guess at, is which everyday Windows applications read gain maps today and which ignore them. We went looking for a first-party page that states it plainly, for any of the major photo viewers on any platform, and did not find one. The standards are public and the support status is not. If you want to know how your own software behaves, the only reliable method is the one in the last section: open the same file in two programs and look.
Five things widely repeated that are not true
Each of these is confidently asserted in forum threads. Each is a misreading of something genuinely real.
- “The photo got compressed, that’s why it looks flat.” Compression artifacts look like blocks, smears and banding. A flat photograph with clean detail has not been over-compressed — it has been rendered without information the sending device had. Those are different failures and they have different fixes.
- “My screen is just worse.” Often it is, but that is not the whole story, and the gain map arithmetic shows why. A screen with headroom of 1 produces the base image exactly. The picture you are seeing is not a degraded version of the vivid one; it is the other output of the same instruction, evaluated for the hardware in front of you.
- “Saving as JPEG loses the HDR, so use a modern format.” The container is not the deciding factor. Google’s Ultra HDR carries a gain map inside an ordinary JPEG file, by storing it as a secondary image. What decides the outcome is whether the software writing the file bothers to include the extra layer, not which format it chose.
- “Now there is an ISO standard, this is solved.” The standard was published on 7 July 2025 and defines how to write and apply gain map metadata. It says nothing about which applications have implemented it, and it cannot reach backwards into software already installed on a few hundred million machines.
- “A photo with no color profile is broken.” It is not broken, and that is precisely the problem. The rule is that an untagged image “must be treated as being in the sRGB color space.” It will be displayed, without warning, under an assumption that may be wrong. Nothing errors. Something quietly guesses.
What you can control, and what you cannot
Sorting this into two piles makes it much less maddening, because roughly half of it is genuinely outside your reach.
Outside your control: the recipient’s screen, the recipient’s software, and what a messaging service does to an image in transit. If a route re-encodes to save bandwidth, your file is rebuilt and the extra layers are the encoder’s business, not yours. No setting on your end changes that.
Within your control: keeping an untouched original somewhere, and knowing which copy is which. Every layer discussed here survives a plain copy and is at risk from everything else, so the archive copy should be the one that came off the camera, not the one that came back out of a chat thread. Our note on sharing photos is written around that distinction — send a rendition, keep the master.
There is also a diagnostic worth ten minutes, because it tells you which of the two problems you actually have. Take one photograph that disappoints you and open it in two different programs on the same machine, side by side.
- If the two programs disagree, the information is still inside the file and one of them is not reading it. That is a software gap, and it closes over time as applications adopt the standard.
- If both agree and both look flat, the extra layers are probably not in that copy any more. Go back to where the file came from and check whether the original on the original device still looks right.
- If the original looks right and every copy does not, you have found the step in your routine that rebuilds files — and that is the step to route your keepers around.
That last case is the common one, and it is oddly cheering. It means nothing is wrong with your screen, your software or your photography. It means one link in the chain is making a file smaller, exactly as it was designed to, and you had not been told.
Open one photo in two programs
Pick the picture that disappointed you most. Open it twice, in two different applications, on the same screen. Ten minutes tells you whether the information is missing from the file or missing from the software — and those need completely different responses.
The photo formats your PC can and cannot open Choosing tools for your libraryFrequently asked questions
Why does my photo look amazing on my phone but flat on my PC?
Because modern phone photos often contain a second hidden layer, called a gain map, that tells capable software how far to push the highlights on a screen with brightness to spare. Software or displays without that capability show the ordinary picture underneath instead. This fallback is deliberate: the format specification requires that on viewers which do not understand it, the conventional standard dynamic range image is displayed.
What is a gain map in a photo?
It is a small grayscale image stored alongside the photograph. Apple describes its version as an 8-bit, single-channel luminance map stored with an image, at a quarter of the original resolution. Each of its pixels is a multiplier saying how much brighter that part of the picture may become if the display has the headroom for it. Bright areas carry values near the maximum and dark areas carry almost nothing.
Does sharing a photo remove its HDR?
It can, if the route re-encodes the image. Re-encoding decodes the picture to raw pixels and writes an entirely new file, and anything in the old container survives only if the new encoder deliberately copies it over. A gain map is an entire second image, so it is often among the first things dropped when the goal is a smaller file. A plain byte-for-byte copy never has this problem.
What happens to an image with no color profile?
It is displayed anyway, under an assumption. The CSS Color specification states that untagged images must be treated as being in the sRGB color space unless otherwise specified, and browser engines implement exactly that. A photograph shot in a wider palette whose profile was lost will therefore be rendered as though it had always been sRGB, which typically makes it look duller than it should.
Is there a standard for HDR photos now?
Yes. ISO 21496-1:2025, "Digital photography — Gain map metadata for image conversion — Part 1: Dynamic range conversion", was published on 7 July 2025 as a sixteen-page first edition from technical committee ISO/TC 42. It defines the gain map metadata and how to apply it. A published standard does not, however, tell you whether the particular program you are using has implemented it.
Why do my photos look washed out after turning on HDR in Windows?
Because the definition of white changes. Microsoft documents that on a standard dynamic range display the maximum value is interpreted as the reference white level of the display, while on an HDR display it is interpreted as 80 nits of nominal reference white. Content authored against one definition and shown under the other will look wrong even though nothing in the file has changed.