QA Testing for HDR and Color Output

HDR is where a game can look stunning or quietly wrong, and the difference is hard to articulate in a bug report. A player says the colors look washed out, another says the dark scenes are pure mud, and a third insists everything is too dim. They are all describing real problems in your tone mapping and output pipeline, but on your single calibrated monitor none of them reproduce. Color output testing means treating SDR and HDR as distinct rendering targets, each with its own failure modes, and building a process that turns vague impressions into specific, checkable results across the displays your players genuinely own.

SDR and HDR are two different products

The most common mistake is treating HDR as a brightness toggle on top of the SDR image. In practice the two paths use different tone mapping curves, different working gamuts, and different white points. The SDR path compresses your scene into a roughly Rec.709 sRGB container with a fixed reference white, while HDR maps into a wider Rec.2020 style gamut with peak brightness measured in nits that varies per display. A change that fixes contrast in SDR can simultaneously crush shadows or blow out highlights in HDR, so you cannot validate one by looking at the other.

Build your test plan around this split. For every scene you care about, capture how it should look in SDR and in HDR separately, and review each on hardware that represents that mode. Reviewing HDR on an SDR panel, or vice versa, tells you almost nothing. Keep at least one true HDR display and one ordinary SDR monitor in your test bench, and ideally a couple of HDR panels with different peak brightness so you can see how your tone mapping behaves on a modest 600 nit screen versus a brighter one.

Hunt for washed-out and crushed images

Two failure shapes dominate color bugs. Washed-out images come from highlights that map too flat, an incorrect transfer function, or treating SDR assets as if they were already in linear space. The picture looks foggy, contrast is low, and bright areas lose detail. Crushed images come from the opposite: a tone curve that slams everything below a threshold to black, hiding texture in shadows. Test both by loading scenes with deliberate extremes, a bright sky over dark interiors, a candlelit room, a snowfield, and checking that you can still read detail at both ends.

Color, not just brightness, deserves the same scrutiny. An incorrect gamut conversion can shift skin tones orange or push foliage toward neon. Put a known reference frame in front of testers, ideally a still you have signed off as correct, and compare side by side rather than from memory. Memory is a terrible color reference. If you can, drop in a small color and grayscale ramp overlay during testing so banding, clipping, and hue shifts become obvious against a neutral target instead of being lost in busy scene content.

Make the HDR calibration screen trustworthy

Most HDR games ship a calibration screen asking the player to set peak brightness and paper white. The single most embarrassing bug here is a calibration screen whose sliders do not actually drive the output, so the player adjusts carefully and nothing changes. Test every slider by setting it to its extremes and confirming the image responds, then by restarting the game and verifying the chosen values persist. A calibration that resets on relaunch silently sends every player back to defaults and undermines the entire feature.

Calibration also has to be honest about the display's real limits. Querying the panel for its reported peak brightness is useful, but many displays lie, so your tone mapping should degrade gracefully when the player overshoots. Test with the brightness pushed past what a modest panel can show and confirm highlights roll off rather than clipping into a flat white blob. Equally, confirm that switching the player's system HDR setting on and off while the game runs does not leave it stuck in a half-configured state with mismatched gamma.

Keep UI and color-coded gameplay legible

HDR changes how interface and gameplay color reads. A pure white menu that looked fine in SDR can become painfully bright in HDR if it is mapped to peak brightness rather than paper white. Test every overlay, subtitle, and menu in HDR and confirm text sits at a comfortable luminance, not searing and not so dim it vanishes against bright scenes. Anchor UI luminance to the calibrated paper white value so it stays consistent regardless of how bright the player set their peak.

Gameplay that encodes meaning in color needs extra care across output modes and for color vision deficiency. If enemy health bars, team colors, or status effects rely on hue, verify those hues stay distinguishable after gamut conversion and that they do not collapse toward each other in HDR. Test with the common color blindness simulations turned on as well, since a wider gamut does not help a player who cannot separate red from green. Where possible reinforce color with shape or pattern so the information survives any display configuration.

Setting it up with Bugnet

Color complaints are the hardest to reproduce because the report depends entirely on the player's display and system settings, details they rarely think to mention. Bugnet's in-game report button captures device and platform context automatically, so a washed-out HDR complaint arrives with the display mode, HDR on or off state, and platform already attached. Pair that with a screenshot and you can often tell at a glance whether the player was in HDR on a panel your tone mapping handles poorly, instead of trying to extract that from a frustrated description.

Because the same display families produce the same artifacts, color reports cluster. Bugnet groups duplicate occurrences into one issue with a count, so if forty players on a particular HDR configuration all report crushed blacks you see a single prioritized item rather than a scattered pile. Add custom fields for HDR enabled, peak brightness, and panel type, and you can filter the dashboard to confirm a fix landed for the exact configurations that failed. That structured context turns subjective color griping into something you can triage and verify.

Build color review into every milestone

Color correctness drifts as art, lighting, and post-processing evolve, so a single sign-off early in development is worthless by launch. Establish a small set of reference scenes, capture approved SDR and HDR stills of each, and re-review them at every milestone on your reference displays. Add a debug overlay that reports the active output mode, transfer function, and target peak brightness so testers always know which path they are evaluating. The goal is to catch a regression the build after it lands, not in a launch-day storm of washed-out screenshots.

Finally, accept that you cannot test every panel, so design for graceful degradation rather than per-display perfection. A tone mapping curve that rolls off highlights and preserves shadow detail across a range of displays beats one tuned beautifully for your single monitor and broken everywhere else. Calibrate your defaults conservatively, make the calibration screen trustworthy, and let captured context guide your fixes. Players forgive a game that looks merely good on their hardware far more readily than one that looks broken.

SDR and HDR are different products. Compare against approved reference stills on real displays, and never trust a calibration slider you have not watched move the image.