HDRify: True HDR image viewer, and tool set in pure JavaScript | Hacker News Reader

HDRify: True HDR image viewer, and tool set in pure JavaScript

hdrify.benhouston3d.com

18 pointsbhouston12 comments

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

"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:

  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.

Firefox doesn't support HDR at all on any platform. https://bugzilla.mozilla.org/show_bug.cgi?id=hdr

For Edge and Chrome I'm surprised it doesn't work for you with HDR enabled in the OS, but did you by chance turn the SDR brightness all the way up in the OS settings as well? Since desktop OLED displays are not very bright you might have done this. And if so then there's simply no more brightness range left for HDR to use, so you basically have an SDR display at that point regardless.

That said, Windows also has by far the worst HDR support of any platform. Possibly because they were one of the first so everyone else got to learn from their mistakes, but they also haven't seemingly tried to fix it, either, which is odd

Firefox does support HDR video on macOS https://www.firefox.com/en-US/firefox/100.0/releasenotes/#:~... just not images/canvas (which this uses).

That said, this page seems to be displaying everything as just WCG and not HDR anyways.

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.

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.

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.

Reply on news.ycombinator.com