Windows HDR: managing SDR content brightness and HDR screenshots

[yinjunonly]

Hi all,

I have been looking into the practical side of keeping Windows HDR enabled all day, especially on OLED / MiniLED / HDR monitors.

This is not about calibrating HDR with DisplayCAL directly. The pain point is more mundane: HDR games and videos can look fine, but SDR desktop apps often feel too bright, too dim, or washed out depending on room lighting and the Windows SDR content brightness value. Regular screenshot tools can also make HDR scenes look blown out.

I built a small tray utility for myself that keeps separate day/night SDR content brightness presets, restores the preferred value when something changes it, and captures region/fullscreen HDR screenshots with tone mapping.

Disclosure: I am the developer. I am mostly looking for feedback from people who understand the Windows HDR / SDR mapping problem better than typical users.

What display model do you use, do you keep Windows HDR enabled on the desktop, and what SDR content brightness values feel comfortable?

[DaniJ]

Windows maps SDR to HDR using a strange curve that makes it look washed out. Until this can be properly tuned, I’ll just use HDR only when dealing with HDR aware apps.

[Dmytro Huzenko]

Windows usually expects the display to have ST.2084 PQ EOTF for HDR. For “SDR over HDR”, it uses that to reach the sRGB EOTF with a specific brightness (though the Windows HDR brightness setting is in the range of 0–100, it corresponds to brightness levels of 80–480 nits).

It works fine if the display follows PQ, but otherwise you may receive different EOTFs for different brightness settings, as well as the wrong brightness level. That can be a cause of the effects you described, and HDR calibration may fix it.

It’s worth noting that the sRGB EOTF looks washed out compared to 2.2 gamma. At https://github.com/dylanraga/win11hdr-srgb-to-gamma2.2-icm you can find MHC2 profiles to get 2.2 in “SDR over HDR”, but I wouldn’t recommend using them. First, because it affects HDR, and second, when an EOTF differs from what is expected, it affects color saturation as well, because matrix colorspace conversion occur in non-linear space.
Though apps can request 2.2 and 2.4 EOTF for themselves in “SDR over HDR” or ACM mode without negative effect, apps that do this are rare even among video players.

• This reply was modified 2 weeks, 5 days ago by Dmytro Huzenko.

[yinjunonly]

Thanks, both of you. This is exactly the kind of distinction I was hoping to get from this forum.

DaniJ, I agree that for many people the practical answer is still “only enable HDR for HDR-aware apps”. That is the cleanest workflow if switching is not annoying.

Dmytro, your explanation helps a lot. I had been thinking about this mostly from the user-facing Windows SDR content brightness setting, but the point about the display’s PQ tracking is important: if the display does not follow ST.2084 well, then changing the Windows SDR slider is not just changing a comfortable white level, it may also expose different EOTF behavior and saturation errors.

So I think the right way to frame my utility is narrower:

– It should not pretend to fix Windows HDR color management or SDR-over-HDR gamma.
– It can help users keep a preferred SDR brightness value once they have found one that works for their display and room.
– It should probably tell users to run the Windows HDR Calibration app first, before relying on any day/night SDR brightness presets.
– For screenshots, it is only doing a practical tone-mapped PNG output, not a calibrated color-managed capture pipeline.

The sRGB EOTF vs gamma 2.2 point is also useful. I will avoid suggesting the utility is making SDR-over-HDR “correct”; “more comfortable / more consistent” is a more honest description.

One follow-up question: when people report SDR-over-HDR looking washed out, would you consider Windows HDR Calibration the first thing to recommend, or would you first ask them to verify the monitor’s HDR mode / PQ tracking / EDID behavior?

[Dmytro Huzenko]

The Windows HDR Calibration tool doesn’t allow you to calibrate a display’s EOTF.

To calibrate the HDR EOTF, you need to measure the display with a tool like DisplayCAL, then create an MHC2 profile or a 3D LUT and apply it. For SDR, you can find ICC profiles on the internet, but for HDR you can’t find measurement results in a useful format, so you must take them yourself. This requires a measurement device that may cost more than the display itself.

Most people would prefer using HDR only for HDR content, or “sRGB to 2.2” MHC2 profiles, rather than bothering with HDR calibration and color accuracy.

[yinjunonly]

Thanks, Dmytro. That is a helpful correction.

I should be more precise: the Windows HDR Calibration app is useful as a first sanity check for clipping / HDR system setup, but it does not replace measuring and calibrating the display’s HDR EOTF.

For this utility, I will avoid presenting calibration as something it can solve. The app is only meant to help with the practical SDR-content-brightness workflow after the display/HDR path is already in a reasonable state.

I appreciate the clarification.

[DaniJ]

Another pain point: while some monitors can get you quite neutral greys with the help of the RGB balance setting in SDR, the setting becomes disabled in HDR making one rely on MHC2 and/or other software to compensate.

[Author]

Posts