HDR Screenshots and Recordings Look Washed Out? HDR Capture, SDR Conversion, Tone Mapping & Platform Compression Explained

｜ HK GPU Fix

重點摘要

A screenshot can look washed out even when the game looks vivid, because capture adds conversion stages the live picture never passes through. This guide traces the HDR-to-SDR pipeline, explains tone-mapping differences, compares capture paths, and gives a simple same-frame test to locate where colour is lost.

The Live Picture and the Captured Picture Are Not the Same Thing

A game running in high dynamic range on a capable display can look vivid, deep, and full of contrast, and then the screenshot taken from that very same scene can look flat, pale, and washed out. The natural reaction is to suspect the screenshot tool, the game, or the display, and sometimes one of those is indeed at fault. More often, though, the washed-out result is not a fault in any single component at all. It is the expected outcome of a pipeline that converts a wide-range picture into a narrow-range picture, using a mapping that differs from the mapping the display used for the live image.

The key insight is that a screenshot is not a photograph of the screen. It is a copy of picture data taken from a particular point in the rendering and display pipeline, and then converted, encoded, and stored in a file format that a viewer must interpret. Every one of those steps can change how the picture looks, and the live picture on the display never passes through most of them. Comparing a live HDR picture directly with a captured file, and expecting them to match exactly, is therefore comparing two different objects that happen to depict the same scene.

This guide works through that pipeline stage by stage, so that a washed-out result can be traced to the stage where the colour actually changed, instead of being blamed on whichever component happens to be most visible. It covers the three stages of capture, the role of tone mapping, the differences between screenshot and recording paths, the file-compatibility problem, the further shift introduced by platform recompression, and a simple same-frame test that separates a capture problem from a viewing problem.

The Three Stages of the Capture Pipeline

A captured HDR picture passes through three broad stages, and colour can shift at any of them. The first stage is the game HDR output itself: the game renders a scene with a wide range of brightness values, from deep shadow detail to bright highlights, and hands that wide-range data to the display pipeline. The second stage is the capture-tool conversion: the capture tool takes that wide-range data and converts it into a stored picture, and where the stored picture is a standard dynamic range file, that conversion involves tone mapping, which compresses the wide range of brightness into the narrower range the file can hold. The third stage is viewing and distribution: the stored file is opened on a viewing display, which may or may not be an HDR display, and if the file is uploaded, the hosting platform re-encodes it again for its own delivery.

Each stage has its own mapping decisions, and those decisions do not have to agree with each other. The display showing the live game applies one tone-mapping curve, chosen by the display and the game together, to make the wide-range data look good on that particular panel. The capture tool applies its own curve when it converts the same data into a stored file. The viewing display then applies yet another interpretation when it shows the stored file. When all three curves happen to align, the captured picture looks close to the live picture. When they do not, the captured picture looks washed out, even though every component did exactly what it was designed to do.

Understanding those three stages reframes the whole problem. A washed-out screenshot is rarely a mystery to be solved by changing one setting at random. It is a question with a specific address: did the shift happen at capture, at conversion, or at viewing? The rest of this guide gives each stage the detail it needs.

Why Washed Out Happens: Values Read With the Wrong Map

The most common mechanism behind a washed-out HDR screenshot is simple to state and important to understand: HDR brightness values are read as if they were standard-range values, or they are mapped through a different curve from the one the live display used. Standard dynamic range and high dynamic range do not merely differ in how bright they can go; they differ in how brightness values are encoded and interpreted. A value that means a bright, detailed highlight in HDR encoding can mean a flat, clipped white when it is read as a standard-range value, because the standard-range interpretation has no room for the extra information the HDR value carried.

Tone mapping is the process that bridges that gap, and it is best understood as a translation, not a copy. A tone-mapping curve decides how each level of HDR brightness should be represented within the narrower standard range: which highlights to preserve, which to compress, how much shadow detail to lift, and where the mid-tones should sit. Different curves make different choices, and there is no single curve that preserves everything, because the narrower range simply cannot hold all the information the wider range held. Something must be compressed, and different tools compress different things.

That is why two screenshots of the same scene, taken with different tools or different settings, can look noticeably different from each other, and why both can look different from the live picture. The live display had its own curve, tuned for that panel. Each capture tool has its own curve, tuned for its own output format. Neither curve is wrong in any absolute sense; they are different translations of the same scene, and translations differ. A screenshot that looks washed out is often a translation that compressed the highlights and lifted the shadows more aggressively than the live display did, leaving a picture that is technically complete but perceptually flat.

A related confusion comes from brightness settings applied on top of HDR. If the live picture was tuned with display brightness, game HDR calibration, or system HDR settings that the capture tool does not reproduce, the captured file will reflect the underlying data without those tuning layers, and the difference will read as washed out. The capture tool did not lose the picture; it captured a version of the picture before some of the display-side tuning was applied. Separating game and display tuning from capture behaviour is therefore an important diagnostic step, and it is one of the reasons the same-frame test at the end of this guide compares the live view and the capture under controlled conditions, rather than from memory.

Screenshots and Recordings Take Different Paths

Screenshots and recordings are often discussed as if they were the same thing, but their capture paths differ in ways that affect colour. A screenshot captures a single frame, converts it, and stores it as a still file. A recording captures a continuous stream of frames, encodes them with a video encoder, and stores them as a video file. The still path and the video path make different trade-offs, use different conversion settings, and are affected by different bottlenecks, so a screenshot and a recording of the same scene can easily look different from each other, even when both were taken from the same live picture.

Within recordings, the path matters further. There are three common recording paths, and each sits at a different point in the pipeline. In-game capture is built into the game itself, and it captures frames from inside the game engine, close to the source data. Driver-level capture is provided by the graphics driver, and it captures frames as they pass through the driver layer, across many games with one consistent tool. OBS capture is provided by an external capture application, which intercepts frames from outside the game and encodes them according to its own settings. Each path has its own conversion behaviour, its own settings, and its own failure modes, and a colour problem that appears on one path may not appear on another.

Encoder load is a separate topic from colour conversion, and it deserves its own treatment. An overloaded encoder produces its own artefacts, such as stutter, dropped frames, and blocky compression, which can make a recording look poor for reasons that have nothing to do with tone mapping. Readers who suspect encoder overload should consult the separate guide on encoder overload, which covers that subject in full. This guide points there rather than repeating it, because mixing encoder-load diagnosis with tone-mapping diagnosis produces a tangle in which neither problem can be seen clearly. The diagnostic discipline is to settle the colour question first, using the same-frame test below, and to pursue encoder load only when the symptoms point in that direction.

The practical consequence of these path differences is that a colour complaint should always name its path. A statement such as 'my capture looks washed out' is incomplete; the useful version names whether the capture was a screenshot or a recording, and whether it came from in-game capture, driver capture, or an external capture application. That detail often explains the whole discrepancy: the same scene captured through two paths is two different conversions, and expecting them to match exactly is expecting two translators to choose identical words.

HDR Screenshot Files and Standard-Range Viewers

A further complication is file compatibility. Some screenshot files preserve HDR information, and some do not, and the difference decides what a viewer can do with the file. A file that carries HDR data can only show its full range on a viewer and a display that understand HDR data. Opened on a standard-range viewer, or on a standard-range display, the same file may be shown with its HDR values interpreted through a standard-range lens, and the result is the familiar washed-out look: highlights flattened, contrast reduced, and colours that seem to have lost their depth.

This is a viewing problem, not necessarily a capture problem, and distinguishing the two is essential. If a screenshot file looks washed out on a standard-range display but looks correct when opened on an HDR display with an HDR-capable viewer, then the capture itself preserved the information, and the washed-out appearance was produced by the viewing stage. If the file looks washed out on both kinds of display, then the shift more likely happened earlier, at capture or conversion. That single comparison, which the same-frame test formalises, separates two very different diagnoses and prevents a correct capture from being discarded as faulty.

File format choices add another layer. Some formats and some capture settings store a tone-mapped standard-range version of the picture, discarding the HDR range at capture time. Others store HDR data that only a compatible viewer can show properly. Neither choice is universally right; the right choice depends on where the picture will be viewed and shared. A picture intended for wide sharing on standard-range screens is usually better stored as a well-mapped standard-range file, so that every viewer sees the same intended picture. A picture intended for HDR viewing should be stored with its HDR data intact, with the understanding that standard-range viewers will not show it as intended. Confusion arises when the storage choice and the viewing environment do not match, and the mismatch is blamed on the capture tool.

Platform Uploads Shift Colour Again

Uploading a screenshot or a recording to a sharing platform introduces yet another conversion, and it can shift colour a second time. Platforms do not generally store and serve uploaded files exactly as received; they re-encode them into their own delivery formats, at their own resolutions and compression levels, so that files play smoothly across many devices and connections. That re-encoding applies its own colour handling, its own compression, and sometimes its own brightness or contrast adjustments, and the delivered picture can differ visibly from the file that was uploaded.

This matters because it creates a second gap between what the creator saw and what the audience sees. The creator may have produced a capture that looks correct on their own display, uploaded it, and then found that the platform version looks washed out, flat, or shifted. The natural conclusion is that the capture was wrong, but the capture may have been entirely correct, and the shift happened in the platform re-encode. Comparing the uploaded platform version with the original local file, side by side, is the test that separates those two explanations, and it should be done before any capture setting is changed.

Platform behaviour also varies over time and between delivery paths, as platforms update their encoding pipelines and serve different versions to different devices. A picture that looked one way on upload day may look slightly different months later, after a re-encode, and a picture viewed on one device may differ from the same picture viewed on another. Those variations are a property of distributed delivery, not evidence that the original capture keeps changing. Creators who need colour-critical delivery should therefore treat the platform version as a separate object from the local file, check it on the devices their audience will actually use, and judge the capture by the local file rather than by the platform copy.

The Same-Frame Test: Locating Where Colour Is Lost

The most useful diagnostic in this whole area is also the simplest, and it requires no special equipment. It is a same-frame comparison, carried out in two steps, that locates the stage where colour changed. The first step compares the live picture with the capture: view the same frame directly on the HDR display, live in the game, and then view the screenshot or recording taken from that frame. If the live view looks vivid and the capture looks washed out, the shift happened at capture, conversion, or storage, and the investigation belongs in the capture path. If the live view and the capture look similar, the capture is probably sound, and the problem lies further downstream.

The second step compares the capture across viewing environments: open the same screenshot file on an HDR display with a compatible viewer, and then open the same file on a standard-range display. If the file looks correct on the HDR display and washed out on the standard-range display, the shift is a viewing-stage effect, and the capture preserved more information than the standard-range viewer could show. If the file looks washed out on both displays, the shift happened earlier, and the capture or conversion settings are the place to look. Running both steps, in order, gives a clear address for the problem: capture, conversion, viewing, or platform.

A few cautions make the test more reliable. Compare the same frame, not a remembered impression of a scene from minutes earlier, because scenes change and memory smooths over differences. Keep display settings unchanged between the live view and the capture view, where possible, so that a brightness or HDR setting change is not mistaken for a capture effect. And compare the local file, not the platform-uploaded copy, when judging the capture itself, because the platform version carries its own additional conversion. Done carefully, this test replaces guesswork with a location, and a location is what turns a vague colour complaint into a fixable setting.

What to Adjust, in Order

Once the same-frame test has located the shift, adjustments can be made in a sensible order, starting from the stage that was identified. If the shift is at capture conversion, the capture tool tone-mapping and output-format settings are the first place to look, because they decide how the wide range is translated into the stored file. If the shift is at viewing, the viewer and display combination matters more than any capture setting, because no capture setting can force a standard-range viewer to show HDR data it cannot interpret. If the shift is at the platform stage, the upload format and the platform preview should be checked before the capture is reworked, because reworking a correct capture to compensate for a platform re-encode produces a local file that looks wrong everywhere else.

It is also worth checking game and system HDR calibration before concluding that a capture tool is at fault. Calibration settings shape the live picture, and a live picture that depends heavily on display-side tuning will always differ from a capture that does not include that tuning. Aligning the calibration, then re-running the same-frame test, often narrows the gap without any capture setting being changed. The general principle throughout is to change one stage at a time, re-test with the same frame, and stop when the capture and the live view agree within the limits of the formats involved. Changing several stages at once may eventually produce a better-looking result, but it will not reveal which change mattered, and the next capture will be just as mysterious as the last.

Common Myths, Dismantled

Myth: A washed-out screenshot means the game HDR is broken. The live picture and the captured picture pass through different stages. A vivid live picture with a washed-out capture usually points to conversion or viewing, not to the game rendering itself.

Myth: All capture tools produce the same file from the same scene. Different tools apply different tone-mapping curves and different conversion settings, so the same scene captured through different paths can look noticeably different. Path must be named before results can be compared.

Myth: A screenshot is an exact copy of what was on screen. A screenshot is picture data taken from a point in the pipeline and converted into a file, which a viewer must then interpret. Display tuning applied to the live picture may not be part of the captured data at all.

Myth: If a file looks washed out everywhere, the display is at fault. A file that looks washed out on both HDR and standard-range displays more likely shifted at capture or conversion. A file that looks correct on HDR and washed out on standard range points to the viewing stage instead.

Myth: Uploading a file shows it exactly as captured. Sharing platforms re-encode uploads for delivery, applying their own colour handling and compression. The platform version is a separate object from the local file, and it should be judged separately.

Myth: Fixing washed-out colour is only about brightness. Brightness is one control among several. Tone-mapping curves, output formats, viewer compatibility, and platform re-encoding all shape the result, and brightness alone cannot restore range that a conversion has already compressed.

Frequently Asked Questions

Why does my game look vivid but my screenshot looks washed out? Because the live picture and the screenshot pass through different mappings. The display maps HDR data with its own curve, while the capture tool maps the same data with a different curve when it stores a standard-range file. The difference between those curves is what reads as washed out.

Is a screenshot or a recording more likely to look washed out? Neither is inherently more prone, but they take different paths with different conversion and encoding settings, so they can differ from each other on the same scene. Name the path, whether in-game, driver, or external capture, before comparing results.

Why does the same screenshot look fine on one display and washed out on another? Because the file may carry HDR information that only an HDR display with a compatible viewer can show properly. On a standard-range display, the same values are read through a standard-range interpretation, which flattens highlights and reduces contrast.

Why does my picture look different after uploading it? Because sharing platforms re-encode uploads into their own delivery formats, applying their own colour handling and compression. Compare the platform version with the original local file before changing any capture setting.

How do I tell whether the problem is capture, viewing, or the platform? Use the same-frame test: compare the live HDR view with the capture, then open the same file on an HDR display and on a standard-range display, and finally compare the local file with the platform version. Each comparison rules out one stage.

Should I store screenshots as HDR files or as standard-range files? It depends on where they will be viewed. For wide sharing on standard-range screens, a well-mapped standard-range file gives every viewer the same intended picture. For HDR viewing, store the HDR data intact, accepting that standard-range viewers will not show it as intended.

When to Seek Professional Help

If washed-out capture persists across capture paths, across viewers, and across displays, and the same-frame test shows the shift happening before any viewing stage, the cause may be a graphics or display-path fault rather than a settings problem, such as a driver fault or a display-output fault that affects how HDR data is handed to capture tools. In that case, a professional inspection can separate a settings problem from a hardware problem before parts are replaced unnecessarily.

HK GPU Fix is located at Dali Plaza, Room 1209, Shek Mun. For display or graphics-related inspection, call 2186 8010 or reach us on WhatsApp at 6558 6806. Inspection and repair fees follow the published three-tier structure of HK$400 to HK$2,800, depending on the work required, and any final fee is subject to a written quote after inspection. Note that we do not operate a Mong Kok shop, and we do not offer a door-to-door service; visits are by appointment at the Shek Mun workshop.