Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

prolost.com

Post reply on HN
Print view View original

191–200 of 214 posts

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

#191

Post by jiggawatts »

AnssiH wrote: post #73
gardaani wrote: post #63

Earlier quoted context omitted.

The huge Windows flaw is that it isn't color managed by default. It means that colors in most applications look extra saturated on wide gamut displays. I wonder if it the same flaw applies to HDR.. apps would look extra bright. 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.

> I wonder if it the same flaw applies to HDR.. apps would look extra bright. No, apps on Windows HDR look normal unless they are HDR-aware and use the "extra brightness".

Windows apps don't even look correct on an SDR display!

I have a wide-gamut display and I can notice the difference between applications that incorrectly "stretch" sRGB to the display gamut versus apps that actually colour manage and map the colours correctly.

No app on Windows colour manages the UI widgets such as the icons, toolbars, etc... This is because the WDDM shell doesn't do any kind of colour management, it leaves that up to the application developers.

The sad thing is that Vista introduced an extremely wide scRGB gamut and WDDM had a number of internal features built around it. Unfortunately, it was only ever enabled for full-screen games, video overlays, and for internal use by apps that do colour management. They should have converted the entire desktop manager to use it.

https://en.wikipedia.org/wiki/ScRGB

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

#193

Post by [deleted] »

ClumsyPilot wrote: post #149
qubitcoder wrote: post #80

Earlier quoted context omitted.

Just in recent weeks: - M1 [0] - A14 in the iPhone 12 Pro (first 5-nanometer chip with 11.8 billion transistors) [1] Previously, they introduced the first 64-bit CPU in a mobile device, which stunned competitors at the time [2]. Not to mention their excellence in hi-dpi displays. In 2012, Apple launched the MacBook Pro a with "retina" display. It took _years_ for non-Apple alternatives to materialize. In fact, the on…

Thats cool, but nothing on that list strikes me as revolutionary kind of development. To me revolutionary is invention of the GPS, or a transistor, or the combustion engine, or a lightbulb - those inventions changed the world. With everything on that list, thru made a better version of something that already existed, especially with display - it's not like they were the ones developing and manufacturing the displays.…

[deleted]

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

#194

Post by gardaani »

jrockway wrote: post #181
dognotdog wrote: post #102

Earlier quoted context omitted.

Is there a way to get Windows to behave better? I was sorely disappointed by how things look in HDR mode, especially the fact that gamut seems to be abysmal compared to the same display in SDR mode, not even considering the terrible black level artifacting :/

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 rel…

> 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.

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.

[1] https://www.w3.org/TR/css-color-4/

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

#195

Post by [deleted] »

crazygringo wrote: post #36

Wow, that's crazy, it actually works -- just tried out the sample videos in QuickTime on my 2016 13" MBP (P3 gamut, running Big Sur) and confirmed working. 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 sam…

[deleted]

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

#196

Post by raindropm »

loh wrote: post #141
Animats wrote: post #40

Now browsers will have to be modified to support colors in excess of 255. Flashing ads will be brighter than ever!

It's amazing to me that there are still people out there who don't use adblockers in 2020. The web is unbelievably painful to browse without an adblocker. I've also gotten into the habit of using uBlock Origin to kill all of the "Accept Cookies" type popups without ever clicking accept. Those are just as intolerable as ads to me.

I think most users never even heard about Adblockers or how it will improve their web browsing life considerably. It's the thing people never know they want.

On other story, I give my junior advice that she should install adblocker on her browser, her reply was: "How can I watch the commercial then?" Umm...OKAY.

My assumption:

1) people just didn't know better or

2) they actually loves those flashing ads all along

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

#197

Post by nottorp »

amluto wrote: post #154
SaladFork wrote: post #79

Earlier quoted context omitted.

The video from the screenshots: https://www.youtube.com/watch?v=tO01J-M3g0U

I looked at that, and it does not appear to result in brighter-than-white output on my iPhone 12 mini.

That went through one or more conversion steps so who knows...

I'm not willing to give my email addy out for those sample clips either, so I guess I won't know too soon.

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

#198

Post by sirn »

dylan604 wrote: post #139
sirn wrote: post #78

Earlier quoted context omitted.

The main issue with comparing the spec is the difference are not really shown in these specs, e.g. luminance and chromaticity uniformity (aka Delta E), among other things. Consumer grade monitor usually do not have these, and when combining with wide color gamut and _measured_ color space (not claimed), we're talking about at least higher grade EIZO monitors which are not less than $1k. The monitor that are comparabl…

Random story about routine calibration. The old Sony CRT reference monitors were weird with their calibration as well. Had a 32" 16x9 HD monitor that had the mass of a dying star. It was in a dedicated film xfer/color correction bay. Once installed, it never moved until we moved to a new location. Once in the new location, it had some weird anomalies even after the typical calibration steps. Our Sony tech realized th…

Very fascinating! I wondered about this and went to search around a bit, and found this bit[1] (though this is more about CRT TV)

> When we used to manufacture TVs, we'd produce them for customers in the southern hemisphere too. When building these, we had to run them through our production lines upside down.

> When the old cathode ray tube TVs were built, the earth's magnetic field was taken into account during the production process. This ensured the current flowed the right way through the TV and so the TV was able to function normally.

[1]: https://twitter.com/SonyUKTEC/status/1228239522166501376

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

#199

Post by formerly_proven »

gardaani wrote: post #194
jrockway wrote: post #181

Earlier quoted context omitted.

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 rel…

> 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. 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…

Firefox (and I think Chrome as well) does color management for images, and I think they even do it correctly these days (i.e. no tag = assume sRGB), which they did not for some time (out of the box).

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.

Post reply on HN