Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[stevep30]

Hi,

I am running my desktop with HDR which is connected to a LG OLED TV and this is the only monitor / TV that is connected.

When using Theatre View, everything looks colourful and bright.

When watching 4K HDR movies everything looks good - TV detects HDR content correctly.

When playing SDR content the TV still thinks it has got HDR content ( even though JRVR states that the output is SDR), so when dark scenes come up, the blacks are crushed and the scene becomes very blocky, which I understand why.

I have waited until MC29 as I thought this might have been cured, as I think that the OS HDR should be disabled when playing SDR content and re-enabled when the SDR content has finished?

[Hendrik]

Running your desktop as HDR is not recommended, and not something we have any automatic switching for. Instead, if you were to run your desktop in SDR, MC would turn on HDR if you play HDR content. That way everything would look right.

[stevep30]

OK, no problem. This method does work, just thought I would ask.

[bogdanbz]

I'm not Hendrik, but I'm quite sure if HDR is enabled in Windows, then it's supposed to stay enabled no matter what content type you are watching.

From a reply I got after I mentioned SDR extras on UHD HDR Blu-ray discs don't look good when viewed in JRVR, I discovered that JRVR relies on the fact that Windows DWM will handle the color transforms of sRGB back-buffer contents to wide gamut HDR. So yeah, JRVR will create sRGB back-buffers to store its output, which is why the OSD shows SDR as the output.

But this raises a situation that I'm not sure is handled well: sRGB data is supposed to be stored already encoded using the sRGB gamma function, so the tone mapping done by Windows interprets the starting data as being pre-encoded using the sRGB gamma function and maps it to HDR10 color values. This tone mapping done by the DWM is not doing an additional "darkening" of the input image which is what an SDR TV that is applying an inverse 2.4 gamma function (or the BT1886 function) is doing.

In your case however, the "too dark" image is likely because the display is crushing the blacks too much in HDR mode. You can try to mitigate this by using the HDR to SDR white-point setting by moving the slider in the Windows HD Color settings (just type that while the Start menu is open).

[Hendrik]

Windows 10 is not that great in converting SDR content to HDR. I'm told Windows 11 is much improved in that area, for what its worth, and many people are happy to leave HDR mode active.

And of course JRVR behaves identically with SDR content no matter what windows is set to, so if it looks good in SDR mode, but not when Windows is in HDR mode, the fault does lie with Windows.

Windows 10 seems to process 2D applications more or less fine, but for some reason any advanced (3D) rendering is not processed well, which both Theater View and video rendering use. But apparently in Windows 11 they did work on this, and improved it.

In short, on Windows 10 I would really not recommend leaving HDR mode on. On Windows 11, that is another question entirely.

[bogdanbz]

I don't think I made myself understood.


A SDR PC display monitor is usually configured to apply a gamma transform to the incoming video signal, so that the overall gamma transform is 2.2.
A SDR TV set is usually configured to apply a gamma transform to the incoming video signal, so that the overall gamma transform is 2.4.

Most of us using Theater View do so with a TV display, so our displays make so that overall the gamma transform is 2.4

PC and TV displays in HDR mode no longer apply different tone mapping (which is what the gamma transform is) to the incoming video signal, because HDR defines fixed luminance points (in nits) for each RGB value. It falls on the shoulders of the Windows WDM to emulate the tone mapping of different SDR displays, when it converts the sRGB content of various applications to HDR10 code points, because HDR displays receive these HDR10 values and display them as is, it's no longer their role to apply an additional arbitrary gamma transform to their input like they do in SDR mode.

The Windows DWM, when faced with a buffer containing sRGB content (so, RGB values pre-encoded according to the sRGB gamma) doesn't know that:
- oh, I have to transform the content of this front buffer (of Calc.exe for instance) to HDR RGB values so that the overall image luminance is the same as when the content is displayed on a SDR display that applies a 2.2 gamma overall value
- and oh, I have to transform the content of this other front buffer (of the Theater/Display view window in MC.exe) to HDR RGB values so that the overall image luminance is the same as when the content is displayed on a SDR display that applies a 2.4 gamma overall value

Since Windows is a PC OS, it assumes that it has to apply a mapping that emulates what a PC SDR display monitor does, so a overall 2.2 gamma. What that means is that when we look at SDR movies rendered by JRVR on our TV in HDR mode, we are very likely seeing them with an overall 2.2 gamma applied, instead of the overall 2.4 gamma (which is darker) when we see them on the same TV in SDR mode.


In order for Windows to know that it has to map the front buffer of those two applications in a different manner to HDR code points, the content of the back-buffer needs to be somehow be flagged in a way that lets the DWM know: map the content of the front buffer to HDR the same way a SDR display configured for overall 2.2 gamma would, and map this other front buffer to HDR the same way a SDR display configured for overall 2.4 gamma would. I believe such way of tagging already exists, it's what you are already using to tag the swap chain content as HDR10.

There is of course, still an issue: that slider in the Windows HD Color settings which lets one modify to which HDR code point to map the SDR white. I think by default it's set to map the SDR white to 80 nits, which is usually much less than what people use their SDR displays at. Modifying the mapping to a higher value will also mess with the tone mapping of SDR to HDR.

Btw, I have my TV display configured to use a 2.2 gamma for SDR now, which is why I don't actually see much difference between watching SDR content on the TV in SDR mode or in HDR mode. As long as you use the slider to increase the brightness of the SDR content when viewed in Windows HDR mode, it will look quite similar.

[Hendrik]

Differences in gamma do not really account for that. Not for the small difference of 2.2 and 2.4. Its a noticeable difference on a good screen, but it would not introduce actual black crush or artifacting as described above.
There is also an option in JRVR to change the gamma for output, which by default preserves the encoded gamma in the video for SDR without further alterations, as thats what most people expect to see, which for most videos is closer to 2.2 then 2.4 anyway.

Such an explanation also does not account at all for the fact that Windows 11 somehow does it just better. That alone speaks to the fact that Windows 10 just doesn't do it all that well.

[bogdanbz]

2.2 to 2.4 is a large difference. It affects values near black where our senses perceive a very large gap for very small luminance deltas, in total contrast to how we don't notice the same amount of variance between larger luminance values. And even 2.2 to sRGB gamma is not a small difference, the normal 2.2 is visibly darker near black than sRGB.

I agree that the black crush and artifacting is most likely due to the TV handling of near-black in HDR, not due to SDR to HDR mapping in Windows. Although a brighter tone mapping as that performed by Windows trying to emulate a 2.2 SDR display would reveal macroblocks that would otherwise be harder to notice on a SDR display applying a 2.4 gamma tone mapping.

I don't know what Windows 11 does differently, maybe there are some issues with the SDR to HDR color mapping in Windows 10 that are fixed in Windows 11 indeed. But the tone mapping of SDR to HDR has to follow the same process as described by me above, Windows has to know what kind of SDR gamma to emulate between all the possible gamma values when it does this SDR to HDR mapping, and it can't know that without some hints on the front buffers regarding the content.

The alternative is for the application itself to use a swap chain flagged as HDR10, where it puts SDR content tone-mapped by itself to HDR10. Then the Windows DWM doesn't need to apply an arbitrary tone map to this content anymore.

[jmone]

FWIW, I've upgraded all my HTPC to Windows 11 and now leave OS HDR On all the time (they all have HDR displays).  I've no longer had any issues (like I did with Windows 10) with odd looking SDR.  It just works, and works surprisingly well.