Well, no offense taken but your “personal frustration” is indeed quite “in the face”. I’ve seen other discussions, too and to be honest, I can understand both “sides” (if there are any…in the end we are in the same boat). But really, fine by me!
I get it that wayland does not support every aspect of proper color managment, eventhough there seems to be progress. For me right now there is no reasonable way to switch to an x-based environment. What I am looking for is dependable information on what works and what does not.
And sure “looks right” is absolutely the wrong way to go about it. That is precisely the reason why I am here and bought an instrument for objection measurement, not merely trusting my eyes.
What I am still unsure of - and maybe someone can speak to this - is if waylands current lack of features impedes my workflow in any way.
If I create a proper profile on Windows or maybe an x-based environment and asign/load this profile with colord in wayland, does that apply and properly work in darktable too, even though it uses xwayland?
Does soft proofing in darktable work in a setup as described above or not?
Am I running (to the best of your knowledge) any risk of getting a useless/wrong profile by doing what I did? I.e. creating a profile on wayland/xwayland and using it with colord?
I am okay with “yes” or “no” or even “don’t know” answers. But these are the question that matter for me personally at the moment. I understand that the situation is not ideal and I understand that there is no “clean” way with wayland at the moment, but I am willing to take detours if the results are reliable. I have no clue, and I do not want to start a wayland vs x-debate.
I’ve seen lots of posts and lots of discussion but I am none the wiser.
I think part of the rough part of wayland is the number of compositors, so the answer will depend specifically on which compositor you’re using. Generally speaking, wayland should be able to use colord to load an ICC profile and apply it to the screen.
I don’t know if xwayland is also capable of this and I don’t know if darktable or other raw editors are capable or reading that pipeline. One way to test might be to take an ICC profile that swaps some channels and apply it as your display profile. No clue if that’s a valid test, just thinking out loud.
Thanks! Thats helpful. Maybe someone or myself gets around to test this. Not today, not tomorrow but it is a starting point.
Edit: more insight on github! It seems vital to make sure to work on “clean” gamma tables as the github comment suggests. Other than that, things seem to work more or less when it comes to profile creation and setup. That is not to imply that everythings works as intended with DT. Anyway, useful info.
I’m on Fedora 38 KDE. I use x11 and color management works.
Every once in a while I try Wayland to test if it works. It still doesnt work. Until they merge upstream I see no reason to hack a way to make Wayland work when X11 is working.
I dont see how “I use x11 and see no reason to switch to wayland” is helpful for wayland specific questions. Thanks for all the other feedback though. Some nice suggestsions, helpful replies on github. Seems like calibration and color management can be achieved if you are careful and know what to watch out for. I guess thats my way then until things improve and get more streamlined/implemented in the first place.
I tested DisplayCAL again today on Fedora 38 under Wayland. DisplayCAL 3.8.9. runs under Wayland and it does show the colourpatches to calibrate.
The moment is goes wrong is when it tries to install the profile at the end of the calibration cycle.
I got a error message:
“The profile could not be installed/activated.
ArgyllCMS: Dispwin: Error - We don’t have access to the VideoLUT for clearing”
DisplayCAL does seems to create a profile, stored under
/home//.var/app/net.displaycal.DisplayCAL/data/DisplayCAL/storage/
but when I try to install the profile in the KDE Colour Management settings of my Display I can not assign the icc profile. The “Assign Profile” button doesn’t seem to work.
As we collectively figured out, the actual color patches are displayed via xwayland. And as well explained in github comment 1 and github comment 2 displaycal and more specifically argyll cannot access the video card gamma tables, eventhough they “assume” they can. So you really have to make sure you calibrate from a clean slate. I don’t know the state of things in KDE but the gnome-UI does not seem to work reliably when it comes to assigning/enabling profiles. This is also mentioned in the comments.
That being said, the error message is reasonable. Have you tried the latest version of displaycal? It was forked ages ago to support Python 3 and since then, development went on. You can get it from here for example.
I have no clue what KDE uses to install/manage ICC-profiles but if its colord, too by default, you can follow the guidance in the github comments or take a look at the excellent Arch-wiki. There are tips and explanations for other programs too if you prefer/use any of those.
You have expressed the frustration better than me in mild words. I got too heated in the moment and ranted on forums. Hopefully it will be ready when distros start ditching X11. I have got many replies for my questions and rant and often these stem from the fact that devs do not understand our workflow nor do they have equipment and this thing seem to be last on the priority list. All we get is replies to handle the situation and avoid bad PR for the projects from our frustrated rants.
