Wayland 1.21 Alpha Finally Introduces High-Resolution Scroll Wheel Support

[Artim]

https://www.helios.de/web/EN/solutions/hd-color.html

Except the color management bits for HDR are not included under Windows or MacOS its add a third party color management solution and then have the applications render correctly.

There is well done HDR that has metadata about it that transfers useful stuff. Then what Windows, MacOS, X11 .... does what is basically have a color management server and throw the job on the applications todo the colour corrections right..

That you took issue with my second paragraph means you are not really aware how its implemented generally. Mostly HDR is done poorly everywhere. Maybe Wayland will give is one done decently in time.

Are you seriously trying to prove your point with a software that doesn't seem to be running on Linux for two decades and doesn't really have any information on how it actually did handle HDR content in Linux? You really have to be desperate.

[Quackdoc]

I sorta disagree with "most (HDR) apps should do their own color management if at all possible". Unless a software is designed for non-composited fullscreen use and the computer is always displaying it through the same monitor, all the nuances in HDR mapping is probably better delegated to be managed by the desktop compositor, else it would be a pile of mess.

For example, if two apps want to display their HDR encoded material at the same time but their material are encoded in different HDR format, what should they do? Let them fight in a boxing ring?

even if the compositor was color managed, this use case still wouldn't work as far as I am aware unless one HDR format can properly encompass another (I assume this is possible in some situations), it should likely be the top most client that wins, since it's probably a safe assumption that it is the one being focused on. but that isn't really within the realm of color management, but rather the compositor determining which metadata should be sent through

as you have different kinds of HDR, (dolby, HDR10 etc.). the issue I have is because HDR is so... annoying to work with, I think leaving it to the app to do color management is best if possible. it's not that they should have to do color management. but if possible it should be delegated to the app to do it. and ofc the hope would be to support at least fullscreen HDR at the least since a good chunk of HDR media consumption would work with this.

I use MPV as an example because it's so darn powerful, I think wayland should be able to communicate color management and all, but all said and done, if the app can do it, the app should probably do it, (though the app should allow a toggle to let the compositor do it). and bypass as much as possible.

[oiaohm]

Are you seriously trying to prove your point with a software that doesn't seem to be running on Linux for two decades and doesn't really have any information on how it actually did handle HDR content in Linux? You really have to be desperate.

The open source world has a mirror to the software colord but even with that it does not make it work right. The reality is windows does not have proper metadata and depends on application rendering client side doing it colors right. The SDR abstraction Microsoft added for HDR is very much like running two X11 servers yes this shows up when at times your SDR colors are wrong and settings to correct it appear being ingored until you either restart windows or stop all SDR applications and start again. Yes the abstraction at times in Windows 10 decides not to take new values.

Artim the reality here is every major desktop OS is a buggy mess when it comes to HDR.

When Wayland does finally provide proper HDR metadata about the screen this will be a level above what Windows has been doing.

The software I pointed to is what you have to use under windows to try to get the HDR/SDR stuff to look right. Please not try it does not properly succeed either.

Colord on the open source is just as flawed.

Yes Colord is a independent to graphical stack protocol color profile server solution for X11 and Wayland like the one I pointed to for Windows and Mac OS. Except colord is is free and open source on the Linux/BSD... platforms.

The reality is you can get HDR to work with X11 with little extra horrible. Yes its working around the limitations of the X11 protocol not having the X11 protocol be that helpful. Yes HDR under Windows and Mac OS you also have to work around the limitations and that end up being having to buy bits of software to replace bits you get in the open source side of Linux for free so it somewhat works right.

I do hope HDR mess does improve at some point to be correctly functional out the box when you install a operating systems not the current mess of no matter what OS you install you have to be jumping through hoops so it works right.

[oiaohm]

even if the compositor was color managed, this use case still wouldn't work as far as I am aware unless one HDR format can properly encompass another (I assume this is possible in some situations), it should likely be the top most client that wins, since it's probably a safe assumption that it is the one being focused on. but that isn't really within the realm of color management, but rather the compositor determining which metadata should be sent through

This is what kind of leads back to the question of HDR should be handled purely by DRM leasing with applications needing HDR with monitor setting particular mode and in fact being locked to full screen. The idea of top most client wins can end up with dangerous flicker if users rapidly tab between windows as the HDR metadata sent throw is being changed resulting in color changes.

This HDR stuff no matter what OS you look at is a cursed mess. Has not been helped with the multi incompatible HDR standards.

The hard reality all operating systems HDR support is only partly done.

[Quackdoc]

This is what kind of leads back to the question of HDR should be handled purely by DRM leasing with applications needing HDR with monitor setting particular mode and in fact being locked to full screen. The idea of top most client wins can end up with dangerous flicker if users rapidly tab between windows as the HDR metadata sent throw is being changed resulting in color changes.

This HDR stuff no matter what OS you look at is a cursed mess. Has not been helped with the multi incompatible HDR standards.

The hard reality all operating systems HDR support is only partly done.

I think it's fine to implement fullscreen only as a temporary stop gap, it's better then nothing for sure. and wouldn't cause too many issues. I wonder if drm leasing supports handling metadata? if so I wonder if that could be put in place today for projects like kodi and mpv.

but handling metadata swapping is something for the compositor itself to determine, isn't reliant on wayland protocols. I think the largest issue right now is that there is now viable way to handle it at all. (I hardly consider using DRM without drm leasing viable, maybe for kodi)

[billyswong]

even if the compositor was color managed, this use case still wouldn't work as far as I am aware unless one HDR format can properly encompass another (I assume this is possible in some situations), it should likely be the top most client that wins, since it's probably a safe assumption that it is the one being focused on. but that isn't really within the realm of color management, but rather the compositor determining which metadata should be sent through

as you have different kinds of HDR, (dolby, HDR10 etc.). the issue I have is because HDR is so... annoying to work with, I think leaving it to the app to do color management is best if possible. it's not that they should have to do color management. but if possible it should be delegated to the app to do it. and ofc the hope would be to support at least fullscreen HDR at the least since a good chunk of HDR media consumption would work with this.

I use MPV as an example because it's so darn powerful, I think wayland should be able to communicate color management and all, but all said and done, if the app can do it, the app should probably do it, (though the app should allow a toggle to let the compositor do it). and bypass as much as possible.

Rec.2020 can encompass P3, AdobeRGB, and CMYK. All current HDR video formats are encoded in Rec.2020. But the sad reality is "HDR" monitors in year 2022 aren't really capable of displaying the whole range of Rec.2020. All of them are doing their own clamping / de-saturating transform. The lazy "temporary stop gap" path is of course let video players bypass the OS and feed the video stream directly to monitors, which will do their own thing and output whatever those monitors like. "Color management" is gibberish to most consumers anyway. But this path is useless for wide gamut photo editing and photo management.

The laziest path that still work for photo management that I can think of:
1) Create color profiles for HDR monitors, each describing their actual individual behavior
2) Provide those profiles to the applications similar to how one would provide monitor dpi information / scale factor to applications
3) Let each applications decide what clamping / de-saturating transform they want to do and make them do by themselves.

In such path, we can then get back to the status quo in most Windows environment - HDR / WCG photos and videos can look totally different depending on which applications you view them in, and each applications will claim what they do is the correct way while finger-pointing each others.

But before we take such path, I think the elephant in the room is we still need an OS-specified transform function for sRGB to monitor profile such that at least non-color-managed / sRGB images and videos are consistent across applications. Such transform function may or may not be hardcode-able into applications and need to be fetched dynamically from OS as different people may have different preference.....

[Quackdoc]

Rec.2020 can encompass P3, AdobeRGB, and CMYK. All current HDR video formats are encoded in Rec.2020. But the sad reality is "HDR" monitors in year 2022 aren't really capable of displaying the whole range of Rec.2020. All of them are doing their own clamping / de-saturating transform. The lazy "temporary stop gap" path is of course let video players bypass the OS and feed the video stream directly to monitors, which will do their own thing and output whatever those monitors like. "Color management" is gibberish to most consumers anyway. But this path is useless for wide gamut photo editing and photo management.

yeah, finding a compatible HDR is the biggest issue.

though it's not entirely useless, for photo editing and photo management, what I was talking about earlier, direct scanout should be able to work for it. hell even drm leasing would be good enough for many colorists as most I know have a dedicated monitor for displaying the picture anyway. it's just a matter of an application being able to utilize it in a meaningful way.

The laziest path that still work for photo management that I can think of:
1) Create color profiles for HDR monitors, each describing their actual individual behavior
2) Provide those profiles to the applications similar to how one would provide monitor dpi information / scale factor to applications
3) Let each applications decide what clamping / de-saturating transform they want to do and make them do by themselves.

I think this would work perfectly fine for a first steps kind of thing. it would at least set us on the right track

In such path, we can then get back to the status quo in most Windows environment - HDR / WCG photos and videos can look totally different depending on which applications you view them in, and each applications will claim what they do is the correct way while finger-pointing each others.

But before we take such path, I think the elephant in the room is we still need an OS-specified transform function for sRGB to monitor profile such that at least non-color-managed / sRGB images and videos are consistent across applications. Such transform function may or may not be hardcode-able into applications and need to be fetched dynamically from OS as different people may have different preference.....

for me, as long as we had at least drm lease level HDR it would send us on the right track. direct scanout would be the next step, and then from there just more building blocks, but HDR really is a big problem IMO that needs to be addressed sooner rather than later

[Spacefish]

The proposals for HDR Support + Color Management in Wayland are really nice.
See: https://gitlab.freedesktop.org/pq/color-and-hdr

they aim to do it "right" this time.. Not that broken mess, where only the application does the color translation into the output buffer..
And they want to combine HDR+Color Management which makes perfect sense.

Once this is implemented / agreed on, on the protocol level we need to have compositor support for it and later on support by the libraries used by the applications which render stuff.

Once this is implemented Linux Desktop will have one of the best HDR/Color Management systems out there. As the whole "pipeline" is aware of what´s going on and you will be able to control a lot of things, like how to handle legacy applications without color management support and so on.

Remember on windows it was a broken mess, which changed from version to version.. First HDR / Wide Gamut support, just threatet every "legacy" output surface as sRGB and did a sRGB -> Monitor Color Space / Gamma conversion (which is the right thing to do). Then users started to complain about "washed out colors".. After that they changed it to just lineary map "legacy" output surfaces to the monitor color space and gamma, which lead to extreme colors... In the current version they do something in between and have a slider to change the gamma mapping of SDR-Content to the output "HDR" brightnesses.. You can´t control how "legacy" colors are mapped to your output devices color space, as far as i know.

Will be a lot better on wayland, once the whole proposal is agreed on and implemented (see link above).

[Quackdoc]

they aim to do it "right" this time.. Not that broken mess, where only the application does the color translation into the output buffer..
And they want to combine HDR+Color Management which makes perfect sense.

I wonder how old my non existent kids will be by then. maybe graduating highschool.

[oiaohm]

I wonder how old my non existent kids will be by then. maybe graduating highschool.

Sounds about right it took about 20 years to get somewhat functional color management in SDR screens. Looks like HDR is going to take longer to get somewhat sorted out.

There are a lot of issues that people point to with Wayland that when you look closer there was not a good implementation anywhere to copy. Yes those areas are fairly much start from scratch and hope to get it right this time.. Yes starting from scratch on something complex like color management is a path to years of arguments just getting the core design sorted out before coding anything.