In order to pull this off, you need to know exactly how many nits bright the display is, as well as having complete software control of the actual hardware brightness. On Windows, you have neither. Enabling HDR mode completely throws off your current colors and desktop brightness and you have to reset both your physical monitor settings and dial in the new desktop white point with a software slider Microsoft buried in the advanced HDR settings (that almost nobody knows how to use) to hopefully be somewhere in the vicinity of what you had before.
When it comes to display technology, having vertical integration is a huge benefit. Look at high-DPI: state-of-art on Windows in 2020 is nowhere near as good from a software implementation or actual user experience point of view as it was on day 1 when Apple introduced Retina MacBooks back in 2012.
On Windows the systemwide "color management" basically consists of assigning a default color profile that applications can choose to use - which is generally only done by professional design/photo/video software, and not by the desktop or most "normal" apps.
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...)
CSS defines that all hex and rgb() colors are always in the sRGB colorspace. There is also support for other colorspaces, such as P3 and Adobe RGB. [1]
The Safari web browser does color management for wide gamut displays correctly, so #ff0000 looks correct and not too vibrant. The biggest offenders are Chrome and Firefox, because they are not color managed. Those web browsers (and Windows) give you the wrong colors.
> 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.
Images without colorspace tags have been defined to be sRGB images by the web specs [1] and all web browsers should already do that. Other software may do something else, as you said. I hope all software will copy how web does it.
FWIW I think the Windows approach to color management has proven wrong and off-base for today's world. It stems from the 90s where color management was seen as something only "pro" applications would ever need to do, so it was okay to require a lot of effort from those few application developers to implement color management in their apps. The MacOS approach where applications tag their surfaces with one of a few standard color spaces and the system does the rest is less powerful in theory but, on the other hand, means that things will actually work. Plus, I think MacOS has escape hatches so that apps can do their own color management based on output device ICC profiles if they really want to.
(see the edited preface to https://cameratico.com/guides/web-browser-color-management-g... )
I wonder what happens if you try this on the LG 5K hooked up to a mac. It is physically the same panel that's in the iMac, so in theory it can present the same range. But if the OS needs to know the exact physical abilities of the display, it might not be able to detect that LG display. Or maybe apple does detect it, because they partnered with LG.
This might explain why I’ve experienced a slight difference when working with photos and video on the iMac monitor vs the LG UF5k. Interestingly I have a small program synchronizing the brightness of my LG with the iMac, the LG would light up ever time I opened the video on the iMac and then come back down on closing. This might explain som weird brightness behaviors I’ve been noticing on the 5k every now and then, I use to decouple the syncing whenever that happens and now I might know why.
Linux seems better somehow but I haven’t had as much time with it there, so I’m not exactly sure why.
> The operating system is complicit in this trickery, so the Digital Color Meter eyedropper shows “white” as 255, as do screenshots.
I wonder if other measurement tools (e.g. Adobe color picker) are also fooled by the OS in this case.
Digital Color Meter shows both UI white and video white as exactly #fff despite the video white being much brighter!
Even at full screen brightness, the video white was noticeably brighter
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.
https://appleinsider.com/articles/20/08/03/what-hdr-hdr10-an...
That plus P3 gamut means a video playing on a display is closer to what a filmmaker intended.
https://en.wikipedia.org/wiki/DCI-P3
What's cool is: 1) 4-year old Macs have become HDR laptops and 2) the implementation is subtle- you get full brightness in the HDR video without having the rest of the UI blast to full brightness.
That video can have a very bright sky, for instance. You can have a bright sky and a blinding text box or neither in other OSs.
It’s also a very bright display in its own right, with 1600 nits vs the 300-400 of a regular one. And 1,000,000:1 contrast as well.
If my screen is already at 100% brightness then there's no HDR effect. 100% brightness is true 100% brightness, the max capability of my backlight.
The only difference is that if my screen is at less than 100% brightness, the HDR content can be brighter than the rest of the screen because it has the headroom.
Does that make sense?
Also, per later comments, this feature only kicks in when you're actually viewing SDR content, so there's no downside (even contrast) in everyday use.
But it seems like Apple might be gradually moving from 8-bit to 10-bit displays. They don't really advertise it clearly, but if the technical specifications say "millions of colors" it means 8-bit, if they say "billions of colors" it means 10-bit. (256^3 vs 1024^3.)
So if you've got the iMac model with the 4K screen, it's 10-bit and therefore capable of 1,024 levels of color. So remapping the UX to e.g. 512 will still be fine, assuming (safely, I think?) the compositing is all done using 10-bit color.
Basically: if I set my display to ~75% brightness and open the video, the whites in the video are 100% brightness, way brighter than #FFF interface white on the rest of my screen.
But if I increase my display brightness to 100%, the whites in the video are the same as the interface white, because it obviously can't go any brighter.
If I decrease my display brightness to 50%, the whites in the video are no longer at maximum 100% brightness, maybe more like 75%.
But it's also kind of buggy -- after messing around with system brightness a bit, the video stops being brighter and I've got to quit QuickTime and restart it again for effect. Also, opening and closing the video file makes my cursor disappear for a couple seconds!
I'm wondering if it switches from hardware dimming to software dimming when the video is opened and closed, and if that switch has to do with the cursor disappears. If it is, though it's flawlessly undetectable in terms of brightness -- the interface white and grays don't change at all.
Interestingly confirming it: taking a screenshot of the video while screen is at 75% brightness show massive brightness clipping in the video, since it's "overexposed" in the interface's color range. But taking a screenshot while screen brightness is 100% shows no clipping, because the video is no longer "overexposed" to the interface.
I'm just so surprised I had utterly no idea macOS worked like this. I'd never heard of this feature until now.