it appears hdr/colour management is maturing on wayland. at least the rendering side of things, not sure about profiling.
i managed to master a raw image in 10 bit/ST2084 on an hdr capable monitor, using vkdt on hyprland. it’s fun developing images completely without display transform/curve.
it’s a bit tricky to use but came a long way since i last tried it. in case you’re curious here’s a pointer to the vkdt issue / branch..
you can’t try without an hdr monitor and you’d need to compile some code. the vkdt side of things should be independent of hyprland though, maybe it works on recent kde too. who knows. it appears this thing also supports colour transforms for different primaries. i’m in the lucky position that my monitor understands rec2020, so that’s what i’m using.
The protocol for wayland to do HDR was announced a few months ago, so its nice to see this get added into places. I’m sure mutter/kwin will also support it soon if they don’t already. No fancy monitor for me, so I can’t test
yeah the protocol announcement / merge is not very relevant for practical use… both ways: some features just work in some compositors without an officially merged protocol/just the xx_ version of it, and also merging it officially doesn’t mean there is support weird ecosystem.
not sure this monitor is super fancy. you get hdr/180Hz monitors for under 300EUR here (though probably not 10 bit and only 400nits).
thanks for the pointer. this firefox thing doesn’t seem to work here (and no idea about the desktops he calls “bloaty” ).
i think i’ll merge the hdr stuff and enable it only if ENABLE_HDR_WSI=1. seems useful but rough.
used spotread with a colorimeter to find out whether the colour management side of things works. i don’t think the compositor reads the primaries i annotated to the swapchain, but instead the rec2020 flag on the framebuffer together with my monitor being run in rec2020 mode kinda work. the results are close, but not accurate. leaves some room for future improvement here.
also thumbnails are currently stored in bc1/sRGB, i.e. have no hdr headroom and thus look dull. not sure how to deal with this, probably need a PQ mode for thumbnail images too.
Well I dont have an hdr monitor but we have that 8 year old sony 4k tv which does have an hdr mode. Never tried it so far though really, once I switched on this mode accidentally and the picture looked extremely contransty
well it’s colour management as you know it… if you don’t input whatever the tv expects (probably BT2020 + PQ transfer function) it’ll look odd. srgb input instead of BT2020/PQ would look weirdly contrasty and saturated.
not sure i’ll stay with the hdr mode to tell the truth… need to get used to how to master images in this setting. anyhow at least windows apparently has a dreaded auto-hdr mode that will behind your back destroy your framebuffer if you don’t have the ability to react and output hdr in the right format, so i think having the code is necessary even before it leads to proper colour management on wayland.
And brightness is an even bigger discrepancy. The best HDR TV’s probably can’t even match concrete illuminated by mid day sun, let alone white walls, sand, etc.
But why is it that I get red eyes if I set monitor brightness to more than 160 candela? And watch it a few hours.
Btw you get red eyes outside as well if its very sunny and you spend a few hours outdoors without a hat or sunglasses, but thats mostly because of uv light. Probably.
Lets watch hdr screens with sunglasses?
Edit: maybe a clarification: afaik hdr screens need a high brightness in order to work properly.
IIRC in one of the recent monitors unboxed videos, he said that SDR content has a spec of 160nits. if that brightness makes your eyes hurt after a while then yes your room might be too dark. similar values are mentioned in this thread:
i think that’s close to how it works. you keep the rest for “hdr headroom” and only light up the portions of your image that need to be “overbright”. you can master your images for this setup by disabling the film curve/display transform that would limit the range to [0,1) and instead just let the values go through the roof. works up to like 4.5stops > 1 in the setup i tried.
btw the branch is merged and something mostly works on kde and hyprland. also on macos hdr support seems to be working somewhat, now only i’ll need to figure out how exactly to work with it and whether the colours are correct.
while this looks like a stupid salesman comparison for hdr i think it really shows the hdr headroom. it’s a photograph of a monitor, left with film curve display transform applied, right without (data just goes > 1). both are stopped up to generate bright pixels, so the left just compresses through the curve near 1.0. the monitor runs in hdr mode so the srgb 1.0 limit is where white clips on the left (and is where the ui elements stay below), while there is some headroom with definition in the colours to be used (right). i find it interesting that the range supplied by monitors (i think this one has 1600 nits) is enough to just leave away the display transform/curve completely and let the eye do the job instead.
weird ecosystem.