Don’t know how far this will go, but the direction at least is encouraging - KDE Plasma 6 Desktop Environment Promises Basic HDR Support - 9to5Linux
I just hope they won’t break SDR Xorg colour management in the process, not even temporarily…
Maybe you should consider some background
- Red Hat's HDR Hackfest Sounds Like It Was A Success - Phoronix
- Asahi Linux To Users: Please Stop Using X.Org - Phoronix
so instead of clinging to the past we should help to progress to the future.
Sorry. My XOrg/KDE system has been working so well, and all I see on the forum is that Wayland has problems. For example:
I know one cannot reasonably expect 100% working solutions, especially if there is no one testing them; I’m just worried that some, who are eager to push development forward, may force something on me that breaks what I currently have. I just own a full-HD, SDR display. For movies and games, HDR may be important even now, but colour fidelity is often not considered crucial. It’s not exactly ‘crucial’ for my needs, either, but it’s certainly ‘nice to have’.
This super short thread actually was the base for the wayland color management spec
That’s not how the thread reads - the thread reads as “Wayland developers ignored the concerns of one of the foremost color management experts” (Graeme)
Because said expert mostly said “stop inventing something new and keep doing what XOrg is doing” … and ignoring that this might not fit how wayland works.
Its cool they’re making progress and its vital that wayland eventually has working color management, but let’s not confuse the future with the present. X works and Wayland likely has at least a few years before all the necessary tooling catches up to its color management.
I think you may be being too optimistic when it comes to colour management. My guess would be that if there are limited resources then HDR would be their higher priority.
Maybe I’m missing something… How would HDR work w/o color management?
Do note that this title is a little bit clickbaity, they’re talking about Asahi Linux only, since they support only Wayland in their very specialized OS.
Color/HDR aside, a lot of distro’s are defaulting to it with reason, it’s more secure and at least on KDE/Gnome it works great even with nvidia (even better than x11 in my case, specially when it comes to desktop animations).
While it screws up new digital art users who get it defaulted to them, changing to x11 should be two or three clicks away and not everyone can be catered for, specially such a tiny percentage of the already smallish gnu/linux userbase.
Please stop mis-characterising what I have said.
I’ve gone to some trouble to lay out a viable color management direction for Wayland
as well as all the reasoning behind it, but it’s unclear if anyone involved has paid any attention or not.
By putting is some hacks that assume typical HDR and SDR display characteristics, rather than allowing for specific colorspace and display profiles. (I have no idea if this is what is actually being worked on, or whether in reality it’s being done better than this.)
By assuming that Wayland will do all the color conversion, and that it will only be given RGB data. (Great for a “quick fix”, rather insufficient if you want accurate control over color.)
This is the impression I’ve gotten too - what their architecture will do “OK” for is if you just “trust the display to do what’s right”.
Modern displays are at least a bit more consistent in their behavior than previously, but if you REALLY care about accuracy you need to profile the display and use that profile properly, which seems to be a gigantic hole in what I’ve seen for Wayland.
That does lead to something I have been wondering - in this age of dynamic backlighting/local dimming, total brightness limits as a result of power budget, etc - is it even possible to get a sane profile from a display without disabling most of the display’s core features? Even my really old Sharp TV seemed to be impossible to profile due to dynamic contrast that led to lots of discontinuities in the results.
The basic spectral characteristics of a display with 3 primaries shouldn’t change with backlight manipulation, so chromatic characterization should remain useful. If the display has 4 primaries (i.e. RGBW) then it will probably only be profiled well with a cLUT based profile, but its color gamut is likely to be poor in any case (i.e. narrow gamut near maximum brightness).
If local dimming is implemented properly, then the display behavior should be consistent and repeatable. If it’s implemented badly, then the display won’t be suitable for high accurate color.
Total brightness limiting displays are going to be somewhat problematic, but the usual workaround is to only measure a small test patch, (5-10%), maybe with constant total power etc.
Time related brightness limiting will mess profiling up badly, so unless you can turn it off, such a display isn’t really suitable for accurate color reproduction. Any dynamic image processing gimmicks will also mess things up, and should be turned off if a display is to be calibrated and/or profiled.
Now it is getting silly… Color Management is coming to gaming Updated AMD Linux Graphics Driver Patches For Color Management - Phoronix (gamescope is also running on top of wayland)
Pretty much only the “basic color management” needed for HDR and wide-gamut displays, not the “full color management” needed for color accuracy in photo/video editing.
Using gamescope greatly decreases complexity since it’s basically eliminating the compositor and the system is only displaying one application at a time fullscreen.
“Color Management” and “functionality that can manipulates pixel values” are somewhat different things.
The latter can serve the former, but that doesn’t make it the same thing.
“Color management” means handling images and colors with an awareness of what color the pixel values represent. By “color” I mean the human sense of perceived color. Although we talk about an RGB pixel value having a color, the actual color it represents is unknown without a corresponding color profile (i.e. tag) that define the relationship between the pixel values and the colorimetric (i.e. CIE XYZ or equivalent) value.
Un-tagged pixel values are often called “mystery meat” for a reason!
To add to this, here is an article about the new release of Weston, the Wayland reference compositor. There is a very brief mention of colour management.
Seems like both Blender and GIMP have given good feedback to the current proposal.