I love how, if you do view it accurately, it just makes every other white look washed out and grey in comparison. Our visual system is just one big comparison machine.
It's really striking if you have a projector. Before you turn on a projector in a room that isn't dark, a white wall looks pretty white. Once the projector is on, that "pretty white" wall is now playing the role of black in the projected scene.
This is actually super interesting: for displays that can get bright enough for HDR content, but do not have self-illuminated pixels/local dimming zones/any other mechanism to display very dark content alongside very bright (like, say, most modern iPad and Mac screens), this is exactly what is happening.
macOS/iPadOS cranks the backlight brightness up but then adds a black filter to the non-bright content to sim it back to “normal” levels.
Next time you see a scene in a movie where people enter a house and you can see both the interior and exterior, think about the 1000x ratio and how much artificial light was needed inside the house to balance the lighting in the shot. (Assuming it's a real sunlit exterior and not a sound stage, of course.)
Sorry for self replying but I just had a look at the repo and it's definitely worth fully automating this.
A js/python snippet converting pngs to superwhite video frames should be fairly easy to implement.
It’s already in use at washingtonpost.com. About 4-6 months ago (IIRC) they had some superbright inline ads that made me doubt my eyes - I couldn’t understand how they were so vivid. Now I know how they did that.
This comment makes me wonder why ad companies haven't already used this to show ads. They are notorious for using any technology to grab users' attentions.
It works by embedding a video element with a one-frame mp4 file. That would technically turn the ad into a "video ad". I can imagine that video ads already have tighter restrictions in ad networks today. At least I'd hope so...
HDR content still explodes my M1 MacBook. The cursor jumps into the corner of the screen, triggering expose, so I have to move out of the corner and back into it to undo the explosion. Now the HDR video is as bright as the sun while everything else looks washed out. So I close the HDR content and have expose trigger again. I don't know who's fault this is, but I despise HDR content because of that.
I think one possibly underused utility of HDR is to have more saturated bright colors in various contexts. I would love a more saturated light blue color for text that is normally available in sRGB, just because #0000ff is too dark and I would like to just crank up its brightness instead of mixing in green and red. Think syntax highlighting or terminal colors.
What you're describing is a more intense (brighter, higher energy) blue, not a more saturated one. For more saturated colours, you need different RGB primaries than the ones defined in sRGB. The DCI-P3 colourspace used in HDR displays is exactly that, offering something halfway between sRGB and Adobe RGB. Of course it pales in comparison to filmic colour spaces like ACEScg, which can represent almost the entire visible gamut.
Thanks! Maybe I didn't express myself clearly, but what I meant is more saturated "light blue" than what's available in sRGB, with the same brightness. For me #0000ff doesn't qualify as "light blue", so the point of comparison would be something like #aaaaff.
Mixing in green and red is equivalent to brightening #0000FF with added white. Try #1AFFFF, for example, it's a magnificently bright light blue. You've not muddied it with brown as you would have by adding an equal amount of green paint and a tenth of red paint; RGB illumination color spaces don't work that way.
It still makes it less saturated though and makes it pale blue instead of what it could have been by just really cranking up the light intensity behind that blue subpixel.
Author says that it can’t be represented with css, but I think HDR is supported in Safari within Display P3 I believe, you can give a value higher than 1.0?
"HDR" contains multiple components:
- Electro-Optical Transfer Function. That's the famous "gamma" of the display which is no longer a gamma
- color space (which real-life color does RGB = 100%, 0%, 0% match)
- Absolute brightness. There are metadata in the video files that say that RGB=100%, 100%, 100% mean 2000cd/m2 (and gives the average frame brightness like 10%, which helps scales for displays not capable of 2000cd/m2 everywhere)
- Increased bit depth
Display-P3 is only the color space (and maybe the EOTF). This video uses the "absolute brightness" feature of HDR to increase brightness.
They've made the odd choice of placing the QR code as a mask on the video via CSS, rather than positioning a black & transparent image over the video (which would allow long press).
Not sure why they've done this, perhaps something about the HDR approach requires both the black and white to be a part of the same video render.
Also - I'm not sure if it's a browser default or some other website CSS but imo there's no real reason long press shouldn't work on a video anyway... videos need accessibility too.
I am on an iPhone 13 and to my surprise I actually saw the HDR QR code displaying way more brightly than the rest of the page, and sure enough when I turned my power saving mode on, it went back to looking like the other non-HDR QR code. Impressive! It will be interesting to see if CSS ever gets full support for it.
When I look at the two codes side-by-side with normal (full) brightness, the HDR one looks quite a bit brighter. If I dim my screen brightness substantially, the HDR one also gets a lot dimmer. Not sure if this solves that problem, though it could be an issue with my particular screen?
Readit News
macOS/iPadOS cranks the backlight brightness up but then adds a black filter to the non-bright content to sim it back to “normal” levels.
https://prolost.com/blog/edr
Also given how prevalent the issue of QR code brightness is for many use cases this could actually prove useful.
??? It's just an all-white video, with an overlay of black QR code applied by CSS. It's already "fully automated."
Both (the video and the overlay) are small enough to be base64'd right into the HTML.
Dead Comment
Once again webdevs creating another UX nightmare.
Dead Comment
Isn't that the sole purpose of HDR!?
You might be thinking of high gamut displays?
https://webkit.org/blog/10042/wide-gamut-color-in-css-with-d...
I might be wrong however.
Display-P3 is only the color space (and maybe the EOTF). This video uses the "absolute brightness" feature of HDR to increase brightness.
I’ve noticed that you cannot long press the brighter code to read it.
This works on the regular code next to it (tested in safari mobile).
Not sure why they've done this, perhaps something about the HDR approach requires both the black and white to be a part of the same video render.
Also - I'm not sure if it's a browser default or some other website CSS but imo there's no real reason long press shouldn't work on a video anyway... videos need accessibility too.
odd choice indeed, I wasn’t thinking clearly when I experimented and wrote the article.
putting a black and transparent image atop the video sounds like a much better idea — i will try it and see if it works. thanks for the suggestion!
I'm assuming there's some problem with screen-rendered QR codes that this solves, but my quick google search mostly just resulted in listicle spam.
What's the problem this solves?
I notice some airline apps and Google Wallet set screen brightness to maximum when you view a boarding pass.
When I look at the two codes side-by-side with normal (full) brightness, the HDR one looks quite a bit brighter. If I dim my screen brightness substantially, the HDR one also gets a lot dimmer. Not sure if this solves that problem, though it could be an issue with my particular screen?
I may make a difference with laser scanners or other more commodity hardware than smartphone cameras which are pretty amazingly good these days.