It works best in Chrome as for some reason you can not set Floating point data into a Canvas object in Safari, even if it supports "display-p3" color space. Specifically Safari will never get to this line in the feature detector:
They don't. It's your eyes re-calibrating to something brighter showing up. The brightness of the SDR content didn't actually change, just like it doesn't when someone turns on the lights in the room even though it ends up appearing darker.
The perceptual issue of simultaneous contrast ( https://en.wikipedia.org/wiki/Contrast_effect ) is a much bigger problem with HDR content in general than people tend to consider. There's far too much HDR content out there that just slams the brightness because it can, essentially resulting in just being an SDR video that had the brightness cranked. Nearly all mobile HDR video falls into this category in particular.
This is not helped at all by the fact that prior to the introduction of gainmaps in images, which many slammed as "a hack" or "not true HDR", the mapping between HDR and SDR values was undefined. BT2048 has attempted to retroactively define that PQ & HLG at "203 nits" maps to "graphics white" (aka, SDR white), but almost nothing is authored to this expectation. The huge advancement of gainmaps, beyond per-pixel local tonemapping, was that the mapping between SDR & HDR was rigidly defined by the spec. So you could actually author content that could be displayed next to SDR content without destroying people's eyes.
I was initially hopeful about HDR but when I found out how it was implemented I thought: that's a way to make certain that both the SDR and HDR versions will look wrong every time.
On my Mac the blown out white areas look absolutely gray compared to setting everything in https://threejs.org/examples/webgpu_hdr.html to max. From testing on Windows in another comment, I have a feeling the canvas on this site is only set to wide gamut, not also wide range, so you're just comparing colorful SDR to normal SDR with it.
"Direct HDR" doesn't work on Firefox, Edge, or Chrome on Windows 11 with a HDR OLED screen (and HDR enabled in OS).
It's 2026 and we've figured out how to make computers talk in 100 languages, but not how to show pictures consistently.
I'm guessing: nobody's bonuses are tied to correct HDR display output at any megacorp. Until that happens, we will all just have to continue living in an 8-bit SDR world.
I'm also not seeing actual HDR display setup (DisplayHDR 1400) for some reason even though it works for other images/videos on other sites (Chrome+Windows for this test). The logs look clean:
isFloat16 true
isDisplayP3 true
isDisplayP3 with Float16 true
But the image is dull and/or blown out instead of actually displayed with HDR. Based on the above logs and poking around with the canvas context for a second, I think the issue might be the <canvas> seems to be using display-p3 and that only gives WCG. For HDR in <canvas> I think you need a different color space. See e.g. at https://testufo.com/#background=stars-hdr&text=color(rec2020... and then toggle between "WCG - Display-P3" and "HDR - Rec.2100 PQ".
A simple test of true HDR output is to move the mouse cursor over the brightest highlight in the picture. If the cursor looks "grey", then HDR is working. If it's the same brightness as the cursor, then it has been tone-mapped to SDR.
It works best in Chrome as for some reason you can not set Floating point data into a Canvas object in Safari, even if it supports "display-p3" color space. Specifically Safari will never get to this line in the feature detector:
https://github.com/bhouston/hdrify/blob/main/demos/web-conve...
one of my pet peeves of computing in this millennium has been images that make your screen arbitrarily go dark.
i presume this is a defect in how macs display HDR content embedded in an SDR container.
They don't. It's your eyes re-calibrating to something brighter showing up. The brightness of the SDR content didn't actually change, just like it doesn't when someone turns on the lights in the room even though it ends up appearing darker.
The perceptual issue of simultaneous contrast ( https://en.wikipedia.org/wiki/Contrast_effect ) is a much bigger problem with HDR content in general than people tend to consider. There's far too much HDR content out there that just slams the brightness because it can, essentially resulting in just being an SDR video that had the brightness cranked. Nearly all mobile HDR video falls into this category in particular.
This is not helped at all by the fact that prior to the introduction of gainmaps in images, which many slammed as "a hack" or "not true HDR", the mapping between HDR and SDR values was undefined. BT2048 has attempted to retroactively define that PQ & HLG at "203 nits" maps to "graphics white" (aka, SDR white), but almost nothing is authored to this expectation. The huge advancement of gainmaps, beyond per-pixel local tonemapping, was that the mapping between SDR & HDR was rigidly defined by the spec. So you could actually author content that could be displayed next to SDR content without destroying people's eyes.
I was initially hopeful about HDR but when I found out how it was implemented I thought: that's a way to make certain that both the SDR and HDR versions will look wrong every time.
It works great on my MacBook M3 display. And also on my HDR compatible external monitor.
The HDR content is literally is brighter than white on my monitors.
I wonder what is different about your setup?
On my Mac the blown out white areas look absolutely gray compared to setting everything in https://threejs.org/examples/webgpu_hdr.html to max. From testing on Windows in another comment, I have a feeling the canvas on this site is only set to wide gamut, not also wide range, so you're just comparing colorful SDR to normal SDR with it.
"Direct HDR" doesn't work on Firefox, Edge, or Chrome on Windows 11 with a HDR OLED screen (and HDR enabled in OS).
It's 2026 and we've figured out how to make computers talk in 100 languages, but not how to show pictures consistently.
I'm guessing: nobody's bonuses are tied to correct HDR display output at any megacorp. Until that happens, we will all just have to continue living in an 8-bit SDR world.
What do you mean "it doesn't work"?
What does your console say?
I actually log the HDR capabilities to console while feature detecting:
https://github.com/bhouston/hdrify/blob/main/demos/web-conve...
I'm also not seeing actual HDR display setup (DisplayHDR 1400) for some reason even though it works for other images/videos on other sites (Chrome+Windows for this test). The logs look clean:
But the image is dull and/or blown out instead of actually displayed with HDR. Based on the above logs and poking around with the canvas context for a second, I think the issue might be the <canvas> seems to be using display-p3 and that only gives WCG. For HDR in <canvas> I think you need a different color space. See e.g. at https://testufo.com/#background=stars-hdr&text=color(rec2020... and then toggle between "WCG - Display-P3" and "HDR - Rec.2100 PQ".A simple test of true HDR output is to move the mouse cursor over the brightest highlight in the picture. If the cursor looks "grey", then HDR is working. If it's the same brightness as the cursor, then it has been tone-mapped to SDR.