I’m using Arch Linux and since version 1.25.0 monitor profiles doesn’t work anymore for me. ART claims that it only supports sRGB on my OS/desktop environment :
With 1.24.5 monitor profiles for color management are working:
Are you by chance running your DE atop of Wayland?
Related change in ART:
Like @guzzisti wrote, if you are using Wayland it was probably not working before either. Now art is more explicit about what you should be doing (i.e. set the monitor profile in your desktop environment), and what are the limitations under Wayland (i.e. clip everything to sRGB – probably not a big deal unless you have a wide gamut screen).
More info about the differences between Wayland and x11 here: doc/winsys_color_pipeline.md · main · Pekka Paalanen / color-and-hdr · GitLab
1 Like
Thanks for the reply. Yes, I’m using Wayland (GNOME DE) and I also have a wide gamut monitor. It’s not clear to my why forcing the monitor profile to sRGB should be necessary. Now (since 1.25.0) the image display in ART looks oversaturated (of course) which was not the case before.
The wide gamut color profile is also specified in the GNOME system settings and applications like gThumb seem to take this setting into account.
Hmmm, I was actually going by the Wayland description in the page I linked, which seems to imply that colour management is done by the compositor, and that apps are just assumed to render to sRGB unless they specify otherwise. If this is wrong, then certainly the new behaviour is a regression. I will need to investigate this more it seems…
I tried to search for some more definitive answer, but I didn’t find much. I changed the behaviour because of what is written here: staging: add color management protocol (!14) · Merge requests · wayland / wayland-protocols · GitLab
Which I assumed is what is currently implemented. But indeed it’s not fully clear… Maybe @swick is still around here and can comment?
Edit I suppose I could also implement a way to bypass the check and let the user restore the old behaviour – that shouldn’t hurt indeed
fwiw i switched to wayland a while ago and colour management kinda still works the same as on x11, with some caveats. i don’t think you’ll get away without letting the user pick the option:
- the behaviour depends on the compositor. for instance kde and sway might be completely different. one has to check which protocols they speak and what they do to your framebuffer.
- most compositors do nothing, i.e. show your buffers to the display as you left them, unchanged, for instance containing the values for the display profile as you were used to with x11.
- in this case, all you lose is the calibration curves, i.e. you want to create a display profile that depends on a manually adjusted white point via monitor hardware buttons. x11 applied this for you, wayland doesn’t (well in the case that the compositor doesn’t speak colour, see above).
there are apis/protocols for annotating your swapchain images with hdr metadata and primaries as well as HLG/sRGB TRC info, but i don’t know if there is a compositor that responds to this correctly yet (mine doesn’t).
on x11 i had a hack that would detect which monitors the pixel buffer overlapped and would colour manage each part for their display. such things now have to be re-implemented in more generality in all compositors before this works again. wayland does not allow you to find out where your window is (though you can of course conspire with the compositor to still find out, which you would have to do for all compositors now…).
(i know this sounds terrible but i still like wayland and i’m not going back. things are moving and i did get an hdr framebuffer through once, colour would be the next logical step from here)
Ah, I see. Good to know, then the current behaviour is definitely a regression 
I’ll revert the change then. Thanks for the info!
1 Like
That’s really appreciated. Thank you all!
Hi @micha1, can you check if this version works?
https://github.com/artpixls/ART/releases/download/nightly/ART-71257f1-linux64.tar.xz
Thanks!
Yes, this version works!
1 Like