Yes, ish. Right now KWin doesn’t expose the final color space with the ICC profile, but for profiling that should imo be unset anyways. That makes really sure there’s no intermediary conversions happening.
You just need to unset the ICC profile in the settings and it’ll work without further changes. Assuming argyllcms doesn’t try to do anything with the X11 gamma lut ofc.
A lot of companies are now starting at three to be competitive, but still, that’s not much.
They also rarely give any consideration for experience when calculating vacation accumulation, only your time with the company. As a result while I would have gone up to four weeks/year in two years, now I’m back to 3 weeks and 0 years of service (got a formal offer from Collins Aerospace on Friday, starting in early July).
For me, the vacation budget is already spoken for:
2 weeks for annual family trip somewhere
1 week to visit parents/old high school friends for the holidays
Any days I take off outside of this budget lead to less time visiting family and old friends back where I grew up over the holidays. Even the 1-2 days I took for BABBQ back in the day meant 1-2 fewer days with the family. The time budget above already makes trips that have longer flight times (such as Japan which I’d love to return to at some point) far less practical because so much of those 2 weeks are eaten by flying out and back.
While this is a valid workaround, and is similar to some work I did on the capture side of things to make RawTherapee’s role in camera profiling a bit easier ( WIP: Bundled profile for reference image by Entropy512 · Pull Request #6646 · Beep6581/RawTherapee · GitHub which solves Reference TIFFs are not tagged with an ICC profile that indicates linear data · Issue #5575 · Beep6581/RawTherapee · GitHub ) - from a user persepctive having to remember to unset the profile in display settings is a step where things can go wrong.
Ideally, there would be a way for an application to say “DO NOT perform any colorspace transforms on these pixels, pass them directly to the display unharmed”, as opposed to the user going out of their way to configure their pipeline in a way that HOPEFULLY does not cause an unexpected transform to happen. Some of @hanatos ’ comments indicate that there’s some infrastructure for this in Vulkan but it’s indeterminate whether or not the full pipeline is available to him for vkdt. He can definitely weigh in on that better than I can.
Operating systems (not just Linux, but this is also applicable to Windows and MacOS) are so bad at providing a “don’t mangle me” pipeline that Blackmagic’s official recommendation is “Buy dedicated hardware from us that lets DaVinci Resolve ensure that all OS color management is bypassed” - UltraStudio | Blackmagic Design - it would be nice if an OS supported a pipeline that Blackmagic trusted enough to not say “We give up, if you want consistency you need to use dedicated hardware”.
Has the wayland devs acknowledged this point and chose to ignore it? Or are they simply unaware? Their color management work is ramping up maybe we need to like the other poster says, add pressure.
You can already configure scaling, color profile, bit depth and adaptive sync per monitor how is that them ignoring the problem?
I’m not sure if that is what Graeme is trying to tell us
unfortunately my adventures with wayland are so far a long history of diverse failures. every so often i try to run things on wayland, but let’s say it’s difficult. <off-topic-rant>perhaps my largest problem is the prevalence of nvidia hardware in my computers. just to tell a few episodes, there was the egl vs gbm buffer allocation issue. some software outright refuses to run on nvidia hardware without even trying. i wanted to run dwl and failed. then there was an issue running glfw because of a crash with libdecor. i could sometimes run no problem on amd and on intel gpus. the last blocker was some bug in the nvidia driver resurfacing preventing the initialisation of vulkan on wayland altogether when using a wayland surface (glfw on wayland using an x surface works), even though the rest (e.g. plasma) runs fine</off-topic-rant>
that said i’ll continue to test this on wayland. i’m using an icc profile i generated from an x-rite i1 Display Pro using argyll on x11. i’m applying the profile depending on pixel offset (so i can correctly colour manage my window if it overlaps two screens) and apply the output matrix + TRC, assuming the VCGT is applied because dispwin or some such loaded it. i’ll need to find out whether my detection of pixel offsets works on wayland and as i understand it the VCGT will not be considered on wayland.
i’m rendering to floating point targets so if wayland doesn’t do it i suppose i can apply the VCGT in high precision myself, too.
the “please don’t touch my data” flag exists in vulkan but i don’t think is handled by wayland (because they make this a property of the surface, not the swapchain, i.e. vulkan allows me to reconsider this when resizing windows etc while wayland doesn’t).
“adding pressure” is almost always counterproductive in FOSS. As an outsider, you can’t really add pressure, since you have no control over anything. You can only add noise.
The best case scenario is that it is ignored. The worst is that you annoy developers who will focus on something else.
I trust that color management in Wayland will be resolved in the medium run. I just hope that it will be a solution with some common interface, not each compositor re-implementing it again.
Wayland is a protocol: it defines how clients talk to the compositor. What the Wayland project delivers is the protocol and a reference implementation with the Weston compositor.
This means, each compositor will have to implement support for the “color management” feature that is being added to the protocol. A common color management library could emerge at some point.
the color management community is small
and the opinions are near zero and unheard by the developers compared to most other FOSS communities. If a wrong approach is being undertaken then it should be made aware sooner than later. We have to pay attention to what the real experts are saying, not ignore them.
I’m not sure the problem is that Wayland devs don’t listen. It’s not black or white, it’s grey.
I read a good bunch of the protocol, as well as feedback on the merge request and other proposed variations.
From all those reads, what I understand is that there are constraints given by the way Wayland works (and for good reason), there are some constraints needed to do color management and there are some habits coming from other platforms (X11, MacOS, Win, …).
What the Wayland devs have to do is find a solution that makes color management possible without compromising basic Wayland concepts.
It takes time to design such a system and it existing app will have to be adapted to that new system because it has different constraints than the existing one.
Just an example, with X11 a single app may change a display colors curves, from a Wayland perspective, a single app does not have that power, it’s the responsibility of the compositor that will try to accommodate various applications need.
To move forward, “putting pressure” is useless, what you need is to find people that are ready to implement the protocol both on the compositor side (in progress in Weston and from what I read in KWin) and on the application side and be ready to report problems to the Wayland devs. The work is done in pull requests, and in code, not in forums 
If you follow the development discussions, all of this is happening, it just takes time.
No, that will not be a thing. I won’t go into this further, this has been talked about to death elsewhere and I won’t repeat that.
Like I said before though, for profiling specifically, I’d gladly offer a Wayland protocol to completely inhibit the ICC profile and related things that hurt the profiling use case, it just needs some application to implement it to actually be useful.
That’s a misunderstanding of what VK_COLOR_SPACE_PASS_THROUGH_EXT does. It just means that Vulkan won’t deal with color management for you / signal the color space to the OS, it does not mean that you get some “pass through to the display” mode. It’s for when the app wants to deal color management itself, for example through the Wayland protocol for that purpose.
Unfortunately you can neither configure nor even know the bit depth that gets output to the display yet. KWin always uses 10 bits per color buffers (if the GPU supports that), but the driver may only output 8 or even 6 bits per color, or YUV with chroma subsampling to the display. There’s still a lot of work required on the driver side to guarantee anything, even if this is already better than on X11.
You can’t get the window position, and on some compositors also not accurate output positions on Wayland. Please don’t try to do such hacks but just implement the Wayland protocol for color management.
You can change surface properties on a frame by frame basis, it’s more fine grained than swapchains.
Indeed. All we need at this point is applications implementing the protocol.
I’m not sure if we are on the same page. I am referring to this issue:
on the other hand you can also say that just saying: Do it the X11 way? why change things?
is also not really acknowledging that the Wayland model actually provides benefits and that there is actually people who want or even need those benefits.
The fact that some people disagree does not make the work they do irrelevant or prove they do not listen to the community needs in general.
In 4 years, a lot has evolved and some people learned a lot.
Not just profiling, unless you are willing to address the concerns @gwgill has raised regarding inability to query the current display’s profile.
Perhaps the issue is that Graeme’s focus has been on profiling so you haven’t seen the other use cases. Here’s one. This is RawTherapee on X11:
Why is this important? Let’s turn on the gamut check feature:
Is this use case supported by xx_color_management_output_v2 from https://invent.kde.org/plasma/kwin/-/raw/master/src/wayland/protocols/xx-color-management-v2.xml?ref_type=heads - It isn’t clear exactly what this is doing and what an “output” is - is that the display, or another more abstract concept? If this does solve Graeme’s question, why have you not pointed him to it? (Side note, is there any less painful way to view this in a more sanely rendered form?)
You’re directly conflicting with yourself here… You say you won’t do that, but then in the next paragraph you effectively say that you’re doing that, since your second paragraph is effectively “don’t mangle my pixels”.
As I’ve shown above, beyond the profiling use case, it’s necessary to be able to inform a user whether a pixel was mangled. This can be:
This assumption that Wayland doesn’t provide the display gamut is quite frankly insulting to everyone working on the protocols. As you noticed yourself, just grepping the xml with basically no knowledge about Wayland shows it’s wrong.
Apps shouldn’t use the display profile and instead use the profile the compositor tells you to use on the surface, so that the user can for example select which screen apps should target (in the case of mirrored displays), but that’s a different topic.
A wl_output can be a display, or a remote display, or a virtual display purely for screen recording, or whatever the compositor wants to expose as a display-like thing to apps. Usually it’s just a normal display, with a name, description, size etc. provided by Wayland.
Knowing the gamut boundaries isn’t enough for profiling.
Yes, there’s wayland.app. With wayland.app/protocols/wayland-protocols/MR (replace “MR” with the merge request number) you can view all the WIP protocols.
No, a special profiling mode - that applies globally to the whole display - is a very different thing to an app getting some very impractical “passthrough” mode. The former is something only a profiling app will use and activate, the latter is something probably a bunch of apps would use and break a lot of use cases with.
Apparently XnViewMP can already talk to the Wayland color management engine.
Those two screenshots were taken on KDE Plasma 6.1/Garuda Linux, newest XnViewMP version 1.7. System wide color management on. The first screenshot shows the photo in AdobeRGB, the second one in sRGB. However, even though there is a significant difference, the colors do not seem to be correct on the sRGB photo, the green is too little saturated, basically there should only be a difference in the reds. I have tested this with other photos as well, where the colors seem correct for the most part.
Edit: Apparently this is actually functional. I have just set a profile in XnView, and the colors are perfect, while Wayland color managment is active.
So apparently Wayland color management works best at the moment if the client says “let me do it”.
I have seen in the past that people have made icc profiles where you purposely switch say blue and red. Then it is clear if an app is using or reading the icc file you specify or ignoring it and just using something else. No need then trying to notice fine color differences…
