I do see colors outside of sRGB when I switch on and off softproof.
2 Likes
Ok, I was wrong. Apparently xlsclients is not reliable, if I use xwininfo, I do see the cross when I hover over the color swatches, but the gui itself is Wayland native. So argyllcms indeed uses Xwayland.
Apparently the same applies for vkdt @hanatos , but RawTherapee on the other hand seems to be 100% Wayland native.
Edit: maybe vkdt is Wayland native when itâs compiled and not running from the Appimage?
1 Like
I think that this is a very pessimistic reading.
Remember that X11 was released in the late 1980s, and color management tools became integrated into mainline distros around 2010, and it never really matched the color management suites of eg Apple devices even at its best. Thatâs approximately a 2-decade lag, and hopefully it will not happen again. But things do take time.
From the video you linked, I find it heartening that the Wayland devs are thinking about adding a decent color management suite. I donât really care if it happens because HDR, as long as it happens.
Yet you are right that it is currently nowhere near ready, and we need X11 to tide us over. Fortunately all distros still have X11 as an option and will probably continue for a long time.
That said, I think that a friendly attitude towards Wayland devs from users who need color management will make it happen sooner than later. Yes, I also want it ASAP (I find Wayland is great in a lot of respects), but being condescending, patronizing, or angry towards Wayland devs and contributors is not going to help.
5 Likes
Oh I have no issues with wayland developers you misunderstand me. I merely stated what I observe that they do not seem to prioritize colour management in terms of print side. And it is not false that they have been funded by companies for doing HDR which is targeted towards gaming and multimedia rather than print.
On the other hand I do have issues with distro devs who seem to be rushing to drop X11. But even then I have not personally attacked anyone. in free software world niether the devs or the users own any one anything. So I am not here to sugar coat things. If it is doesnât work it doesnât work. If there is a communication gap we have to call it that.
Discounting the fact that desktop publishing itself began around 1980 I would not be surprised if Xorg did not have tools right of the bat so you can say less than 2 decade long gap. And one learns from the past mistakes right. When they have the example of xorg they should not be repeating its failures right? I would have assumed that they do colour management right from the start when they started wayland development which is 15 years ago. After all it is a protocol to display thing on screen.
I think we will see the first clients that can properly communicate with the wayland color management engine very soon, the frist ones probably being Gwenview or the Gnome image viewer.
3 Likes
the appimages are using glfw with xorg. you need to link against glfw-wayland otherwise. i suppose i can build such packages on github automatically as well if thatâs convenient.
1 Like
They are rushing to make wayland default, not drop x11. And this is with good reason in my opinion. The average user doesnât care if their monitor is calibrated or not, but most seem to care that their monitors with mixed refresh rates work properly, VRR with multiple monitors works properly, no horrible screen tearing, and so on.
Wayland adoption for the masses needs to happen so developers are motivated to support it. We had the exact same issue with pipewire, and now pipewire is the standard everywhere and imo a massive step up in linux audio, especially for artists that donât need to have an install where their only audio server is jack which doesnât work with most applications.
Artists can always use an X11 session in most if not all distros without any trouble or serious effort. And for those that donât want to âmessâ with their system, I guess itâs why distros like ubuntu studio exist. Those can always keep x11 as the default for longer.
3 Likes
Wayland was default for quiet some time. Nobody has issue with that. Kde spin of fedora dropped x11 and if not for some volunteer going against them there would not have been a way to run x11 on it. It is the fedora kde team that said Wayland is ready. They also gave me PResque reply stating that they do care about artists etc. later I got to know that this reply was for people who were reading my complaint and not for me. They want to handle the reputation but spread false things. That is my issue. I also have issue with people telling Wayland is ready like zealots while it is not. I know it takes time but people should not be dishonest and spread false info with half knowledge
That is exactly what I am doing running debian and most artists will do the same when debian too stops supporting x11then I guess most will look at proprietary offerings. So fedoraâs policy of forcing user to test Wayland so that bugs are ironed out is a failure. There are better ways to gather feedback than forcing users to migrate.
Pipewire migration was really seamless they did implement most of the features required for full migration hence there was no complaints or issues. That is how it should be done or you should provide fallback. Even when pipewire was made default nobody dropped support or stopped shipping older system.
2 Likes
It seems like high pessimism to believe that when debian drops X11, wayland with color management will not be ready 
Wayland by all accounts, at least today and for the average user, is more or as ready as X11.
1 Like
Yeah may be it will be ready then it will be good. Apps will take time to implement colour management too. We do have time till 2028 or 2032 I think.
Yes I do not disagree with you. But it is not ready for all particularly for artists who want colour accuracy, not so hard to accept that.
1 Like
I think this is widely understood (especially if you want to calibrate), and I am not sure if anyone is claiming otherwise.
But at the same time, it is important to recognize that concrete steps have been taken to fix the issue. There are still quite a few components missing from a complete solution, but I think it will get there in the medium run.
Indeed. Now, give us a basic capability to allow a program to direct-render on the hardware allows that program to manage the display render how it sees fit. Then, we sit back and see if/how managed display architectures provide compelling color management capabilities.
1 Like
Likely only by nature of GTK3, to my knowledge no one has done anything app-side to support Wayland.
Any hostility from the user/application developer space is a direct result of over a decade of hostility from the Wayland developers. From Graemeâs overview at Argyll Color Management System Home Page - "Starting in 2013 I attempted to engage the Wayland developers in discussing the challenges of adding proper support for display color management under Wayland, but in general received (and continue to receive) a very hostile response. "
2 Likes
Please do if itâs not much work. I think I am not the only person interested in it.
1 Like
Not to many. See for example fedora developers.
In NixOS, we have vkdt-wayland. I havenât used it tho.
It might well be OK, although you have to be content with no per-channel calibration etc.
Of course if newer versions of Wayland start color converting application pixels from sRGB to HDR etc., then this may not be so good in the future.
Less likely to work for ArgyllCMS and application will be the situation of more than one display - unless XWaylandâs emulation of XRandR is very detailed. Even if it is, itâs doubtful that a native Wayland application will know which screen it is rendering to, hence which profile to use for those pixels. (Wayland is designed to hide the particular display identity from a Wayland application, and only the addition of the HiDPI extension exposes this information. Even an application that makes use of the HiDPI extension will struggle to relate the Wayland display ID with the corresponding XRandR ICC profile.) Such are the issues of a system that wasnât designed with color management in mindâŚ
3 Likes
I tried very hard, and they werenât receptive (see the discussions on the Wayland mailing list starting in 2013). If there is going to be any change in that situation, itâs up to them to make the approach.
On the (very rare) occasion that a dev in the Wayland space has approached me, Iâve tried to help them to the best of my ability.
3 Likes
Apple introduced ColorSync in 1993, as well as helping establish the ICC to standardize general purpose computing color management. So the clock has been ticking since at least then, and there were many proprietary approaches to color management in the decades before 1993.
X11 has never had color management as part of its tool set. What it did do is keep out of the way of implementing color management on top of X11.
LOL. Quite the opposite. Whereas X11 kept out of the way of color management, Wayland has been architected to make it extremely difficult. The core foundation of Wayland (as best I understand it) was to divorce rendering from the display hardware. This lead to the idea of providing the application (or the rendering toolkit an application may be using) with a display buffer, and then mapping that to actual displays using the Wayland compositor. Applications are deliberately kept in the dark about which display they are rendering to. This is/was seen as a key advantage of Wayland. In reality the assumption that pixel values are interchangeable between displays is a fundamental error, as becomes extremely obvious when confronted by displays that have radically different resolutions (HiDPI) or pixel depths, or color spaces (AdobeRGB, Rec2020, HDR). In addition, many of the developers seem to have a fixation about âsecurityâ that is irrational to the point of being unable to grasp that users need to be able to configure their computers, or that color management applications are just applications used to configure a graphic interface.
There appears to be an enormous amount of pride that Wayland is not like X11, in spite of some developers being involved in both projects.
Very bad assumption, 100% incorrect. It appears the me that no original Wayland developer had any awareness of color management when the project was started, and once it got some momentum up, very little interest in coming to grips with a set of requirements that may contradict the principles of Waylands foundation.
5 Likes
Perhaps because they know the limitations of X11? My understanding is that it had been increasingly difficult to keep the X11 protocol working given competing demands of GPU rendering, multiple displays (with different DPI, frequencies, etc), security, etc.
I fully understand the frustration of people for whom color management is the most important aspect, and they just want to keep it working. Yes, it would have been way better to design Wayland with color management included from the ground up, and it must have been frustrating for people who tried to make this happen but were ignored.
Nevertheless, very few people are familiar with the theory and practice of color management, and their input is the only way to make it happen. For better or worse, Wayland is now becoming the de facto standard, so from a practical perspective it may be best to ignore the frustrations and mistakes of the past and engage constructively with the Wayland devs. It would be great if people like you could help with the process, despite their previous experience.
2 Likes