Apple’s “Extended Dynamic Range” Brings HDR to Non-HDR Displays

I think Windows provides all the tools necessary for accurate color management, it's just that not everyone has done the necessary bookkeeping for it to work.

The underlying problem is that APIs describe colors in the display colorspace. #ffffff means "send full power to the red, green, and blue subpixels"[1], without describing what color the red, green, and blue subpixels are. That was not a major problem until relatively recently; every display used the same primary colors, so there was no need to specify what colorspace you were sending values to the OS in. But, then it became cheap and easy to use better primaries ("wide gamut"), and we had a problem. Every color written down in a file suddenly became meaningless; an extra piece of information would be required to turn that (r, g, b) tuple into a display color. So, everyone kind of did their own thing! Image formats long had a way to tag the pixel data with a colorspace, so images with tags basically work everywhere. Applications can read that and tell the OS that colors are in a certain color space, and it can map that to your display. Most applications do that; if you have a wide-gamut display and take an AdobeRGB-space image off your digital camera, the colors will be better than if you looked at it on an sRGB display. Even web browsers handle this fine; if they are presented with an image with a colorspace tag, they'll make sure your monitor displays the right colors.

The problem is sources of color data that don't have a tag. CSS is a big offender. CSS doesn't specify the colorspace of colors, so typically browsers will just send whatever is in there directly to the display. That means if you're a web designer and you pick #ff0000 on your sRGB display, people using a wide-gamut display will see a much more vibrant shade of red, and everything will look off. In fact, pretty much everyone using a wide-gamut display will see wrong colors everywhere because of this; I have one, and I just forced into sRGB mode because it's so broken. (On the other hand, a lot of people like more vibrant colors, so they think it's a good thing that they get artificial vibrance enhancement on everything they view. And are then disappointed when an application handles colors correctly, and what they see on their monitor are the same boring colors their digital camera saw out in the field.)

But, the problem is not Windows, the problem is applications and specs those applications use. Authors of specs don't want to say "sorry, there is no way you can ever use colors outside of sRGB without some new syntax", so they just break colors completely for everyone. That's why things look terrible on monitors that aren't sRGB; the code was built with the assumption that monitors will always be sRGB. Get rid of that assumption and everything will look correct!

There are also plenty of images out there that don't include color space tags, so it's undefined as to what colors they're actually trying to display. Some software assumes sRGB. Some software assumes the display colorspace. It's inconsistent. (I used to produce drawings in Adobe RGB and upload them to Pixiv, and their algorithm totally gets colorspaces wrong. It will serve your verbatim file to some users, but serve a version of the file to other users with the color tag removed, so that there is no possible way the viewer can see the colors you intended. I gave up on wide gamut and restricted myself to sRGB, because the Internet sucks.)

[1] It gets more complicated for shades of grey, involving gamma correction. #7f7f7f doesn't mean "send half as much electrical power to each subpixel", but rather maps to an arbitrary power level. The idea is to use the bits of the color most efficiently for human viewers; it's easy to tell "0 power" from "0.01% power". (You'll see this in practice when you write some code to control an LED from a microcontroller; if you just use the color as a PWM duty cycle, your images won't be the right colors on the display you just made. Of course, many addressable RGB LEDs do the gamma correction internally, so your naive approach of copying the image pixel values to the addressable LED will actually work. I learned this the hard way when I got addressable LED panels from two separate batches, and the old batch did gamma correction and the new batch didn't. I didn't realize it was gamma at play, so built an apparatus to measure the full colorspace of the LEDs with a spectrophotometer (https://github.com/jrockway/apacal). When I plotted the results, I immediately realized one was linear and the other was gamma-corrected... which meant all the code I wrote to build a 3D LUT for the LEDs was pointless; some simple multiplication was all I needed to make the LEDs look the same. But I digress...)

What are the requirements for it? The section is there but I can't see the toggle, on both SDR screens.

I have a Dell UP2414Q, which is a wide-gamut 4K monitor with a relatively high 375 nits peak brightness and 10-bit input.

It's not technically HDR, but if I view HDR videos with it in SDR mode with the brightness turned up to maximum, there is definitely a bit of an "HDR effect", similar to what Apple has achieved.

However, under Windows, without support from the operating system, this doesn't really work. The colours are shifted and the brightness of the content is way too low.

Microsoft could add something similar, but this is a company that thinks that colour is a feature in the sense of:

    Colour: Yes.

We're approaching 2021 rapidly. I suspect we'll have to wait to 2030 before Microsoft gets its act together and copies even half of what Apple has in their display technology now.

wow. no one is calling this the hoax it is. it’s reducing contrast on the SDR so that the HDR content is subjectively brighter. i mean it’s fine and all, but you’re not seeing HDR on a non HDR screen. you wouldn’t be able to use it for color grading.

One issue that is very visible is the Control Panel versus the new Settings app.

A key feature of Control Panel was that it was "pluggable": vendors could add their own items, and often did. These are ordinary Win32 apps written to match the style of the era. Worse, some system control panel items have plugins in turn. E.g.: drivers can define extra "tabs", network cards have protocol-specific popup windows, etc...

There is just no way to update the look & feel of these to match the new Settings app style, most of the code is third party and ships as binary blobs.

The Microsoft Management Console (MMC), used mostly for Administrative Tools and server consoles has a similar problem.

Combined, these two make up the majority of the OS GUI!