Thanks a lot for feeding me information
I totally get if you or anyone else gets fed up entertaining my curiosity, given I am only trying to understand the current state of things and my only contribution (at best) is reproducing that understanding in a way thatâs (hopefully, maybe?) accessible to someone thatâs not followed all of the past discussions on this. I am still continuing hoping to keep the constructive discourse going, but obviously am not demanding for anything (how could I?).
I still feel like I am missing something here: For all I see the wayland color management proposal fulfills your requirements (or they are explicitly out-of-scope for the proposal) and the summary of your protocol sketch pretty much matches waylandâs.
The requirements about being able to set the display color profile is not covered by waylandâs protocol. It explicitly states that it does not cover that process, but assumes display profiles are already in place. To me that doesnât mean thereâs no way to set display profiles, just that this proposal doesnât define how that happens. Basically an implementation is free to handle that however they want respectively that may get standardized in a separate proposal.
As to your sketch: 1) is not covered, at least I didnât see any provision in wayland for a compositor not doing color management. However that is basically the current, undesired âbaselineâ behaviour, right? 2) and 3) seems to be basically the same as the wayland proposal to me. And 4) is not fully covered, as in there is not explicitly such a mode, but the application can set their output color space to the display color space, which gets you essentially the same behaviour. Except that the application needs to handle multiple displays itself, i.e. needs to split itâs output into two surfaces if it spans multiple monitors to set different output profiles. As far as I understand that mode is mostly necessary for profiling though, so Iâd expect that to target a single monitor only at a time anyway.
Right now the discrepancies/critique I did get are: 1. waylandâs protocol doesnât cover it all (especially how to configure/change display profiles). 2. Complexity of adding color spaces to the protocol. To me 1. is orthogonal: It is obviously fundamental to a profiling software, but nothing in the current proposal prevents a compositor implementation or another proposal from providing a solution to do that. On 2. My understanding is that the compositor needs to be able to convert input of various sources into a common working spaces for blending, thus it needs to be able to handle the input color space and the protocol lists a few of those that a compositor should be able to handle. Is your point that there are too many of those, as thereâs already tools which can convert between them, so the compositor doesnât need to be able to handle all of them itself? I am out of my depth here clearly - I would expect you could even remove that from the protocol alltogether and let the compositor announce which color spaces it can handle to applications instead - however I am probably missing something there.
This is BAD. Not only does profiling app need access to it, but also advanced graphics app needs it. This not being part of standard cripples the standard.
Not really - client needs to have full access and knowledge about surface with no transforms, because doing 3 conversions as described by you may lead to great loss in precision (and in some cases HDR â SDR headaches). Personally Iâd also love if application could define important region of window to be color managed and leave rest for default color management
As for things âmissing in standard/left for compositor to decideâ - if thereâs no standard way of doing things, you might imagine krita (qt based) to have nice colours on KDE, but totally shit on Gnome, while other way would be true for Gimp. You donât leave crucial part of standard to âto be defined laterâ or âletâs implementations do their thingâ.
In the current protocol you can get the (current) display profile from the compositor via the protocol if you then set the surface (aka your window or part of your window if using a sub-surface) to that profile the compositor must do a no-op identity transform[1][2]. Other options (using a predefined color space, or assigning an ICC profile) are there mostly for e.g. web browser, videoplayers, simple image viewers, etc where the app doesnât care to much about 100% accuracy but still might deal with non sRGB images.
All of the above should be possible including defining just part of a window (via sub-surface).
Sorry - I donât currently have a lot of time (or energy) to replay past discussions on this and other lists at any length. One of the key problems it seems, is that a lot of the statements relating to this subject have little or no meaning to someone lacking the requisite life experience.
Then it seems to me that you are not reading what I wrote
Key point is that you canât make a problem go away by saying theyâre out of scope.
Anyone who has actually used a color managed system in anger knows that being able to color profile it and keep it in calibration is essential. It is not an option that can be waved away. The fact that all existing desktop application environments support this (and hence all existing applications that depend on color management expect this, and users expect this) is a hint as to the reality of the situation.
And while itâs perfectly reasonable to expect that implementation of a new facility will be incremental, anyone who has architected and participated in standardizing moderately complex systems knows the issues that result by not looking far enough ahead when architecting something. Too often you end up with a mess when you realize that early assumptions and simplifications are wrong, and that foundations need to be ripped up and redone, and/or horrible hacks have to be lived with because of momentum and sunk cost. If this was brand new territory, and everyone was on a learning curve, then a stumbling path to âperfectionâ is how it has to be, but this is not the case.
And that is a big problem. You havenât got a modern Color Management system if there is no standard way of doing Color Management things. (Converting pixels from one colorspace to another is not a Color Management system.) Saying âdo it some other wayâ is not going to happen. As the author of the only profiling system readily available on Linux, Iâm 100% sure that Iâm never going to hack into my code, distro or compositor specific code to load profiles or attempt calibration and profiling, even if there were a way to do so. Just like any other application author, I want a well thought out standard API to do these things, so that it can be written once and will work on all Wayland based systems. I get that on all the existing operating systems I support.
Wrong. I could digress and point out that the major difference between Wayland and X11 is that X11 does the rendering on an applications behalf - that is the way it worked well as a remote display protocol, and that in contrast Wayland assigns that responsibility to the Application, instead providing a smart âdumb frame bufferâ to the application. So logically it would follow that the Application should have the responsibility for Color Managing the pixels, since that is part and parcel of the rendering process !
But most Wayland Color Management proposals have included a Compositor pixel color transform capability for two reasons:
Itâs highly desirable in terms of making it easy for non color sensitive applications to be written that will work across the modern range of wide gamut and/or HDR etc. displays, without the authors having to be experts on, and clutter their code with extensive color management.
Itâs forced by the wrong assumptions made in the initial architecture of Wayland, that pixels on different displays are interchangeable, and that the application can be kept ignorant of which display they are rendering to. This was the very basis of how Wayland handles compositing, so itâs not easy to fix/work around. Wayland can move an applications window around between displays without the applications involvement, so it is a problem when the application is doing/has to do the pixel color conversion.
But letâs come back to why the application has to be able to manage pixel color conversion itself. And once again, this is something that becomes evident when you have written color managed applications, such as a Postscript RIP, or soft proofing application etc., but may not mean anything to you if you havenât:
The format of source color specifications is open ended. There are many standard ways of specifying a colorspace, but there are an infinite number of ways that arenât standardized, and people keep inventing more. As I have previously mentioned, for a taste of this, go read the Postscript or PDF specifications related to color. Even something like ICC profiles allows for up to 15 channels of color information, so to support the subset of ICC based color specifications within Wayland would mean that Wayland has to have a raster format capable of handling floating point rasters with up to 15 channels, named color ârastersâ etc.
The details of converting from one colorspace to another is open ended. There are some commonly used ways of doing this conversion, but when it comes to color sensitive applications, it can be very application specific, and people are constantly inventing new ways to do this. No clever technical tricks can hide this problem. In general, color conversions involve dealing with gamut differences between colorspaces, and the conversion needs to know the details of the source and destination colorspaces to setup specific flavors of conversions.
So a modern Color Management architecture has to allow applications to do their own pixel color conversion if it is to be comparable to existing systems. Making this possible while allowing Wayland to do the Compositing is one of the challenges. If Wayland had been architected with Color Management in mind, a lot of problems may have been avoided. (And Color Management was a well understood thing at the point in time that Wayland was created.)
See above. You canât assume that the Compositor can handle the pixel color conversion except in very carefuly controlled situations. And once source colors have been converted to a particular displays colorspace they can be blended as they always have been. It does offer the possibility of improving the blending operation by allowing it to compose in a linear light mixing space - knowledge of the EOTF would allow simple per channel curves to convert to a linear light mixing space and back, improving transparency behavior and anti-aliasing. I guess that may imply a change to Wayland implementations, if they are currently doing blending before windowing into particular displays, but then itâs hard to take advantage of display hardware acceleration if they were doing that.
For those who are a bit lost in the nuances of color, a strong parallel in the Wayland world is how it is coming to grips with displays with widely different DPIâs. When the application is doing the rendering, trying to hide which display the application is rendering for becomes difficult when different displays have different DPIâs. So some of the âpure visionâ that Wayland started out with, about how applications didnât have to know what screen they were rendering to, and âevery pixel is perfectâ have had to give way to reality. Many of the same compromises are needed for Color Management. People donât need to measure and re-measure their screens DPI though, since it doesnât drift or change, and itâs relatively straightforward to measure.
So is this already functional (usable/compilable) software (a âforkâ) that only needs to be merged resp adopted/packaged by distros? Has anybody tested it? Or is it just an idea?
As will be evident from perusing the link, it is a sketch of a protocol. Itâs the starting point for an implementation.
If it were at the point of merging, the discussion would be completely different âŚ
Xorg is not actively developped anymore; the only this that get regular commits it mostly the XWayland part (Fedora is changing the packaging of that for the next release).
Ubuntu, like Fedora has already done, defaults to Wayland. It does not mean that Xorg is not available anymore. It just means that on a default installation, and with the default desktop environment, it will start a wayland session. But itâs just a switch to do in the login screen to get an Xorg managed session
Color management is not used by everyone, and so proabably not that problematic for a lot of people.
If you want people to start moving and acting to a new system, you have to set it as a default, to start getting more feedback ,bug reports and make it evolve
I agree with all of that, but AFAIK, the proprietary nVidia driver does not work well with Wayland, and the open nvidia driver does not work with openCL. So, many of us are stuck with continuing to use X.
In fact Wayland on Nvidia EGLStream is already possible since Fedora 29, but not activated by default.
And there are development in progress both on the NVidia and Xorg/Waylang side to get this sorted out. See for example that news from Phornix
Now that I found this thread I have a question. When people say âWayland does not have proper color managementâ, what does that mean?
Currently Iâm using Gnome with Xorg on Manjaro, I have calibrated my screen display with DisplayCal and a Spyder3 but the correction was minimal (yay Dell!). If I were to switch to Wayland at some point (for instance when I have to reinstall my system, iâve had it for three years now), what specific problems will I have?
Will there be no correction at all when setting a profile?
Will the global gamma correction work, but color managed applications will not use the profile?
Will all the colors just be visibly wrong? Invisibly wrong?
Will there be error messages in for example darktable? Any indication that things may not be working as I think they are?
The final scenario (things being wrong but no way to know it) is very scary so if that is the case, why are there not big red warning labels on every Wayland package?