[lonjil]

8-bit can have banding even without "HDR". Definitely not enough. 10 bit HDR video is becoming more common, and popularity for images will follow. Adoption is hampered by the fact that Windows has bad HDR support, but it all works plenty well on macOS and mobile platforms.

[adgjlsfhk1]

unfortunately linux HDR is pretty much completely absent. That said, Wayland slowly looks like it's getting there.

[spookie]

KDE Plasma 6 has HDR support.

https://zamundaaa.github.io/wayland/2023/12/18/update-on-hdr...

[toastal]

X11 supports 10-bit SDR… which Wayland doesn’t

[JyrkiAlakuijala]

It would be nice if everything was non tone-mapped HDR all the time for software, and the windowing system or the monitor would do the (local) tone mapping.

[kllrnohj]

No, you don't want that. You want your windowing system & UI/graphics layers working in display native range (see eg, Apple's EDR). The consistency of appearance of the SDR range is too important to leave it up to unknown tone mapping.

Also it's too power expensive to have your display in HDR if you're only showing SDR UIs, which not only is the common reality but will continue to be so for the foreseeable future.

[JyrkiAlakuijala]

I think both approaches have advantages.

Requiring every game, photo viewing app, drawing program, ... every application to decide how to do it's HDR->SDR seems unnecessary complication due to poor abstractions.

The locality of local tone mapping (the ideal approach to HDR->SDR mapping) would expose the window boundaries. Two photos or two halves of the same photo in different windows (as opposed to being in the same window) would create an artificial discontinuity for the correction fields being artificially contained within each window instead of spanning the users visual field as best as possible.

Every local tone mapping needs to make an assumption of the surrounding colors: is the window surrounded by black, gray, colored or bright light should influence how the tone mapping is done at borders. This information is not available for an app: it can only be done at the windowing system level or in the monitor.

The higher the quality of the HDR->SDR mapping in a system, the more opportunity there is to limit the maximum brightness, and thus also the opportunity for energy savings.

[kllrnohj]

> Requiring every game [..] to decide how to do it's HDR->SDR seems unnecessary complication due to poor abstractions.

Games already do this regardless and it's part of their post processing pipelines that also govern aspects of their environmental look.

What's missing is HDR->Display which is why HDR games have you go through a clunky calibration process to attempt to reverse out what the display is going to the PQ signal, when what the game actually wants is what MacOS/iOS and now Android just give them - the exact amount of HDR headroom which the display doesn't manipulate.

As for your other examples, being able to target the display native range doesn't mean you have to. Every decent os has a compositor API that lets you offload this to the system.

[account42]

X11 does but many X11 applications and window managers don't.