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.

My impression is that PMing this is really hard. And then each of the other guys is going to have an opinion that this shouldn't be done because it's so rare, etc.

Something must be organizationally right for something like this capable engineering to have succeeded on such a barely noticeable feature.

I love it when products casually have cool things like this. Not quite the same scope but IntelliJ's subpixel hinting option has each element of the drop down displaying with the hints that it describes. You don't have to pick an option to see it. You can just preview it off directly.

It really is beyond belief that an organization with so many employees can fail to adhere to a uniform vision and standard and focus on correcting details.

I'm a life long Windows and Android user. But honestly, seeing articles like this and how smooth the UI on macOS and uniformly they apply new updates and UI changes makes me extremely jealous and resentful that Microsoft is so bad at something so basic.

Features are great, but users at their start point interact with UI first. They need to fix that before anything else.

Now they want to give you the option to run Android apps on Windows through emulation. This just going to create a bigger jumbled mess.

This is a bit misleading. The backlight isn’t at a higher level than necessary for sRGB content all the time, just whenever any HDR encoded videos or EDR apps are open. When you open an HDR video you can see the highlights getting brighter as the backlight gets pushed.

What I like about conclusions of this piece is it points to how strategic Apple is thinking in its leverage due to the breadth of distribution of advanced hardware and software.

Apple is able to set entire new standards of expectation for customers that are _very_ hard for competitors to follow.

While competitors fixate on some single feature like night photo quality, Apple is also subtly chipping away at something like this.

> it’s strange and new, and possibly unique to Apple.

But that is exactly how Windows 10 does it with HDR displays, too. So not really unique to Apple. To the article's benefit, it did say "possibly" :)

I'm using Win 10 myself with an HDR display, and HDR white appears brighter than "desktop" white just like in the article photo.

There is also a slider in Win10 HDR settings that allows you to bring SDR/"desktop" white up if you wish to oversaturate SDR.

In particular https://gitlab.freedesktop.org/swick/wayland-protocols/-/blo... was linked which discussed how a wayland compositor would have to display mixed "HDR" and SDR content on the same display. This document even has references to EDR. Ultimately this would end up achieving a similar result as what's described in the blog post here.

If you're interested in the technical details on what may be necessary to achieve something like this, the wayland design document might be a good read.

The first thing you think is, how was I OK with this terrible standard video to begin with? The HDR version just looks SO MUCH better and the standard looks so flat next to it. Like comparing an old non HDR photo with an HDR one.

What is the source for this? I don't see any justification for this claim in the article. There are plenty of ways to implement this feature that don't involve permanently throwing out dynamic range on all your SDR panels. I'm not even convinced from reading this that they aren't HDR panels to begin with - the idea of an iPhone having a 9-bit or 10-bit panel in it isn't that strange to me, and while that wouldn't be enough for like Professional-Grade HDR it's enough that you could pair it with dynamic backlight control and convince the average user that it's full HDR.

Considering Apple controls the whole stack and uses a compositor there's nothing stopping them from compositing to a 1010102 or 111110 framebuffer and then feeding that higher-precision color data to the panel and controlling the backlight. Since they control the hardware they can know how bright it will be (in nits) at various levels.

> But at key parts of the story, certain colors eek outside of that self-imposed SDR container, to great effect. In a very emotional scene, brilliant pinks and purples explode off the screen — colors that not only had been absent from the film before that moment, but seemed altogether outside the spectrum of the story’s palette. Such a moment would not be possible without HDR.

I think the author knows that this is a special case of the effect where you limit color palette to some range of colors for a duration of the film and then exceed that range in places—no HDR in particular fundamentally needed to make this possible.

True, HDR can give a greater effect in absolute colorimetric terms when full palette is revealed, but the perceived magnitude depends on how restricted the original palette was prior to the reveal, and how masterfully the effect is used in general.

I seems that the new MacBook Air with M1 can't play HDR content on external displays. :(

For the 5-6k that this display from Apple costs, I would certainly expect it to be an OLED display at LEAST. But it's not.

How is this the best we can get and it's NOT OLED? Dimming zones for 6k? I don't understand what's going on, I just want a nice OLED monitor that will fit on my monitor arm. I'll even pay the same price that you can get an AMAZING 55" OLED TV from LG for; 1500-2k.

White is white. White on a display is the brightest point the display can display.

What Apple is doing, as the article explained, is showing regular white as gray. That’s not cool, that just stupid. It’s exactly what TVs at Best Buy do when showing SD vs HD content: They ruin the regular image just so you can see the difference.

The issue is that my monitor is not a demo display, it’s what I use sometimes in daylight, and I’d very much appreciate that extra brightness that Apple takes away from me.

You know what this means for you? Everything you see and watch on your computer is not a bright as it could be. On an LCD screen that’s a big deal because suddenly your blacks are brighter (because of the backlight at 100%) and your whites are dimmer (because Apple saves brightness on the off chance that you have HDR content)

#ffffff is L=100%. What is L=800%? It exists in HDR content, and we can’t just make the web color #ffffff a dim gray to the eye.

We must start thinking in terms of HSL or LAB or even RGBL, and consider that L > 100% is where HDR peak brightness lives.

HDR’s color space exceeds the luminosity that sRGB hex triplets can represent, and remapping HDR color spaces into sRGB hex gives you horrendous banding and requires complex gamma functions. The CSS colors spec is finalizing on this, but essentially we’re at the last days of hex codes being a great way to express color on the web. They’ll remain good as a last resort, but it’s time to move a step forward.

Apple is pinning sRGB hex #ffffff to “paper white” brightness because the hex color specification can’t encompass the full spectrum of monitors anymore. The different between #ffffff and #fefefe can be enormous on a display with 1800 nits of peak brightness, and if you map #ffffff to peak brightness, you burn out people’s eyes with every single web page on today’s legacy sRGB-color Internet (including Hacker News!). That’s why HDR has “paper white” at around 400 lumens in calibration routines.

So, then, sRGB hex colors have no way to express “significantly brighter than paper white #ffffff”, and UI elements have little reason to use this extended opportunity space - but HDR content does, and it’s nice to see Apple allowing it through to the display controller.

But there’s no way to make use HDR in web content - other than embedded images and videos - if we continue thinking of color in terms of hex codes. This insistence that we remap hex codes into thousands of nits of spectrum is why web colors in Firefox on an HDR display make your eyes hurt (such as the HN topbar): it’s rescaling the web to peak brightness rather than to paperwhite, and the result is physically traumatic to our vision system. Human eyes are designed for splashes of peak brightness, but when every web page is pouring light out of your monitor at full intensity, it causes eye strain and fatigue. Don’t be like Firefox in this regard.

“But how do we conceive of color, if not in hex codes?” is a great question, and it’s a complicated question. In essence you select color and brightness independent of each other, and then make sure that it looks good when peak brightness is low, and doesn’t sear your eyes when peak brightness is high.

If this interests you, and you’d like to start preparing for a future where colors can be dimmer or brighter than sRGB hex #FFFFFF, here are a couple useful links to get you started:

https://news.ycombinator.com/item?id=15534622

https://news.ycombinator.com/item?id=22467744

As a final note, there are thermal reasons why peak brightness can be so much higher than paperwhite: your display can only use so much power for its thermal envelope. Yes, HDR displays have thermal envelopes. So overusing peak white, such as scaling #ffffff to the wrong brightness, can actually cause the total brightness of the display to drop when it hits thermal protections, while simultaneously wasting battery and hurting your users’ eyes.

https://hbr.org/2020/11/how-apple-is-organized-for-innovatio...

Most frameworks don't let applications touch pixel data without jumping through some hoops, because by restricting it you can implement things like lazy loading, GPU jpeg decoding GPU resizing, etc.

It's easier when you control all parts of the stack. No way they could have pulled that one off with NVidia who were "famous" for breaking with Apple years ago when Apple demanded to code the drivers themselves... for valid reasons when one looks at the quality of their Windows and Linux drivers. The Windows ones are helluvalot buggy and the Linux ones barely integrate with Linux because NVidia refuses to follow standards.

Latest Windows 10 iteration is by far the snappiest OS I've used in a long time since it uses GPU acceleration for the desktop window manager. You can check this in task manager. The icing on the cake, if you gave a laptop with 2 GPUS(Optimus) is when you can run a demanding 3D app like a game in windowed mode in parallel with other stuff like watching videos on youtube and you can see in task manager how windows uses the external GPU to render the game and the integrated GPU to accelerate your web browser, all running butterly smooth.

>In fact, their OS is in such shambles and is a disoriented mess with respect to UI consistency.

True, but that's what you get with 30 years worth of built in backwards compatibility. I can run a copy of Unreal Tournament 1999 that was just copied off an old PC with no sweat right after ripping and tearing in Doom Eternal. Can you run 20 year old software on current Apple without emulation? Apple can afford to innovate in revolutionary ways when it dumps older baggage whenever it feels like it and start from a fresh drawing board without looking back, see intel to apple silicon transition. In 2 years x86 apps will be considered legacy/obsolete on Mac hardware. Microsoft can't really do this with windows so yeah, it's a mess of new GUI elements for the simple stuff and windows 2000 era GUI elements for the deep pro settings. The advantage is that if you're an old time Windows user you can easily find your way using the "old" settings and if you're new to windows you can do most configs through the "new" GUI without touching the scary looking "old" settings.

I worked at Facebook for years and it now has a similar problem. Developers are evaluated every six months on their 'impact', which results in many dropping boring work and joining teams that are doing new things, even if they aren't needed.

Windows struggles to correctly display Adobe RGB (wide gamut but not HDR) JPG images I've downloaded in 1999, now over 21 years ago and counting.

They'll get there... eventually. Maybe next decade, by which I mean 2030, not 2021.

If you’re not spent time in a huge company, this might seem to be the case. But really, Apple’s uniform standard really is the exception. I’m sure there are other organizational costs for this, such as it being harder to take risks with products or execute quickly.. but gosh they are good at producing a cohesive, mostly consistent set of products. I deeply appreciate their attention to detail and long term commitment.

Yup, I think this has to be the case. But the crazy thing is, I can't perceive any shift in UX brightness whatsoever, even a flicker, when I open/close an EDR video.

I would have thought that there would be some slight mismatch at the moment the backlight is brightened and pixels are darkened -- whether it would be a close but not perfect brightness match, or a flicker while they're not synced. But nothing.

As I mentioned in another comment, the only giveaway is that my cursor (mouse pointer) disappears for a second or two. I have to guess that adjusting its brightness happens at a different layer in the stack that can't be so precisely synced.

So that's why Lunar[1] reads a much higher brightness and makes all external monitors as bright as ten thousand suns when HDR content is played.

I wonder if there's any way to detect this and read or compute the SDR brightness instead.

[1] https://github.com/alin23/Lunar/issues/86

but what about blacks? If you have a dark scene with bright highlights (eg. campfire at night), does the black parts of the scene get blown out because backlight bleed?

The cheaper version of this display has a price tag of $5k, the more expensive one $6k.

I never spent even remotely as much money on a display, so I cannot speak from first-hand experience. But a quick search for graphics-design displays yields several competitor products that have similar or better specs, at generally even lower price tags.

Apple does many things, but certainly not bleeding-edge innovation. Of course it likes to sell its products as such, but I guess that's just how marketing works.

When you toggle HDR on Windows, the desktop becomes dull gray and desaturated exactly because they pull down the previous desktop brightness to something less than 255. So you have to then adjust your monitor's brightness up to compensate. The monitor's brightness effectively sets the upper cap of the HDR brightness, so let's say your brightness was set at 50% before, now you've got to fiddle with the monitor to boost the screen brightness to 100% to allow HDR to function, and to achieve your previous desktop white brightness (you'll probably also have to adjust the software "desktop white" point slider you mentioned, since MS has no clue what the correct monitor brightness and SDR pull down amount should be, so good luck matching your previous desktop colors and brightness). In my experience very few people successfully manage to setup their Windows HDR correctly, and even if you do there's no way to "seamlessly" switch between the two modes (which you have to do since tons of stuff on Windows doesn't work properly when HDR mode is enabled). I haven't checked Surface or other MS hardware, perhaps they're able to do something more clever there?

What Apple does, is that when your display brightness is 50% and you display HDR content, the HDR content will seamlessly appear at a brightness somewhere between 75% to 100% of the maximum screen brightness. That is a seamless HDR effect, giving you the whiter than white experience next to your other windows that just works.

Macs and its apps have been properly color managed for decades. That's why the transition from SDR to HDR monitors has been painless. Apps have been ready for it for a long time.

It's gonna be five minutes before everybody's extra important call-to-action buttons and probably ads are max brightness too