Color Management #4377
Comments
|
doubt I'll impl this before the proto gets merged because I want wlroots to impl it for a guideline on how to do it. I have no clue how icc works |
It's possible to use Gnome's lacking implementation already & if they eventually figure this one out, then it might just continue working the same way as now. |
|
wlroots seems to have a MR open that implements the simple color correction and profile loading: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4280 Seems unrelated to the protocol however. |
|
If you have a wide gamut screen and absolutely need color management for the colors not to look oversaturated, you can use a profile that contains only profiling data and no calibration curves. You can set the icc profile inside firefox, and some other color managed apps such as geeqie, digikam/showfoto, darktable, rawtherapee etc. You cannot set display icc profiles in other browsers than firefox though. However, if your screens color space is very similar to p3, e.g., then you can choose p3 in chromium e.g., because that's built in. |
|
As a modern display system, this is absolutely indispensable. |
|
if you need it so much you can write a screen shader that implements the color correction. That's what hyprland would be doing anyways once this is implemented. |
|
Well, implementing color management does not make sense at the moment because clients (apps), such as firefox, Gwenview etc cannot communicate with the wayland color management engine yet. I think it's a bit more than just a screen shader. I will post the sway commits in a moment. |
|
Just one more remark: well, we are waiting for the first clients to implement system wide wayland color management, afik they don't exist yet. Sebastian Wicks talk at LGM2024 was about this topic but the graphics devs still seem to be rather skeptical. |
|
I don't see how clients are involved here at all, the only idea I can see is an app (idk a game?) being able to send to the compositor what ICC profile to load. The wlroots MR in question seems to me like it does exactly what I'd suspect, loads the ICC stuff and transforms the colors at the output with a shader: I do not write vulkan and I've never done ICC but it seems to me like all it is, is just transforming the final image. Further reinforced by this: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4693 Since when you use a color transform, you have to re-render the image and can't push it straight to the gpu. |
|
HDR is sent differently yes, and once #6608 is done I am planning to do some HDR stuff eventually, though no immediate plans. After the full migration (and some bugfix period) I want to push HW plane support into aquamarine and get Hyprland to use hw planes as much as possible. They have a huge performance/battery life potential and more people would benefit from it than ICC or HDR, IMHO.
IMO it's the better approach. For many apps, 100% color accuracy is redundant and useless. (idk a file manager) and the disadvantage of having to do an extra pass where you could use direct scanout is a major con. |
|
Well clients are involved since they need to tell the compositor in which color space the image they show is. Also applies for e.g. a web browser. The compositor/wayland does the actual color management. |
Exactly, that's it. |
|
Ok, sorry for writing so much, but you need to understand two different things: the icc profile contains profiling data=info about the size of the screen 's color space, and it can also contain calibration curves. I tested sway-git and unfortunately, what it did was this: for some reason it gave my screen a dark blue cast even though my screen profile does not contain calibration curves. But the saturation was ok. |
|
You seem way more knowledgeable in this than me so I invite you to write the implementation yourself in hl and make a MR once I am done with the migration to aquamarine. You also seem to have way more of a need than me, or most other people, for it. As I've said before, plane stuff and explicit sync will probably be on the table before color management if I am to do it, because it will benefit more people. |
|
Yea, I already thought about that, and my biggest wish is to do it, but unfortunately so far I can only fix tiny little bugs with the help of AI. As you can see on my website, I am mainly a photographer, a tester (I am really good at that!) and an IT journalist. |
|
To help moving on with this feature, Sway and wlroots did it in the vulkan renderer this way: swaywm/sway#7681 and https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4280. It's apparently doable in GLES3 too: swaywm/sway#1486 (comment) |
|
the proper way to do color management is what is WIP at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 (and has been for literal fuckin years) The way sway does color management atm is wasteful and IMHO dumb. It's definitely doable in gl (I don't see why even gl3 would be needed) but I have no plans atm of implementing it due to many drawbacks |
That makes sense, no worries
For my curiosity (and maybe to avoid someone spending time on it until the wayland protocol is ready maybe one day), what are the drawbacks and why do you find it dumb? |
|
color management should be done by the application. The app should get info about preferred color modifications and implement the management itself. Right now, sway will instead do it itself, meaning after rendering your scene, it will texture it again and re-render it applying a color profile.
|
Got it, thanks! I thought that compositor side color mapping was a preferred option, to avoid falling in the case of Windows for example, when the color profile is rarely applied as it often depends on the apps to make use of it or not. |
I'm not very familiar with color management, but my understanding was that ideally you let programs provide and use the ICC profile themselves, and if they don't then just assume the program is sRGB. Which would work fine if you have the monitor profile set right since it'll know how to transform from sRGB to your monitor. It sounds like what sway is doing is to assume all programs are sRGB (since no color management protocol yet), but also allow transforming everything after the fact to the profile you provide? Someone tell me if I am getting all of that right. |
|
sounds about right |
|
Id say you actually want both options, but with some degree of customizability. Ideally, all of this list is true:
The latter point is what I think compositors should do, as it fits neatly in the concept that a compositor or display driver or WM can, and should, when not contraindicated, provide a normalized color space for all applications. YMMV, but for me personally, having the latter makes running multi-display systems immensely nicer. The concerns about speed, latency, and the wastefulness of multiple roundtrips through the pipeline are a real concern, but id think theres got to be a sane way somewhere to make CM work without incurring that much cost. To me, its been a real regression in the wayland era in general. As far as direct scanout goes, what happened to graphics drivers being able to load a 2d or 3d LUT to provide color profiling along with direct scanout? Edit:.... theres also monitors that provide display side LUT functionality, but those are even less consistently implemented... |
that's there, but DRM/KMS doesn't support it yet on Linux |
|
For those interested in super basic color management in Hyprland: I probably will not submit a formal PR because, for this usecase, it is kind of a hack and shouldn't be the direction Hyprland goes. (But maybe there would be interest in a more generalized version for enhanced shader customization?) |
|
tbh since screen shaders are a thing just writing your own LUT converter in glsl is completely reasonable (that's what sway does on vk afaik anyways) you get output uniforms as well so it can work with multimon |
|
Maybe we can contact the maintainer of ArgyllCMS in order to get some advice on color management. |
|
While I think just implementing a user screen shader for a LUT would be fine, there's one thing missing: As far as I can tell there's no way to define additional uniforms for the screen shader, in particular nothing to load additional textures. So I think for this to be a valid workaround for the color management issue, Hyprland would either have to add a generic way to load textures that are passed into the screen shader, or add a setting for a LUT specifically (sort of how @gnusenpai's branch does it). I'm not sure what the best direction would be design-wise, but having a |
|
it still won't work for multiple displays with different LUTs each. Furthermore, although this is a fine temporary band-aid, what about 10bit? 256x LUTs are, well, 256. 8bit. Don't ICC profiles encode what LUTs do using continuous functions instead? In that case they would be better. I don't think we'll manage to get LUTs make sense without allowing arbitrary texture loads into user shaders. |
|
Well, at least for multiple displays we do have the monitor ID as a uniform, but yeah it's not much more than a band-aid for sure. |
The PNGs can be 16-bit and the shader does work with it.
Going off of Reshade's shader
Would skipping the PNG sampling be faster? probably but not really the biggest reason for wanting to drop the PNG requirement. |
|
I wasn't talking about sampling time but rather accuracy
But they still are 256x no? which limits them to 256 pixels, 2^8. |
I'm a bit confused about what's being discussed here. LUTs can really be any size. 1D LUTs can easily be 256x which should be small enough to be embedded in a shader directly, if you wanted. In-between values on 10-bit displays can be interpolated. 1024x is doable, but I don't think they are commonly used. 3D LUTs pretty much only go up to 65x65x65, which is basically transparent with interpolation and sufficient bit-depth. |
|
alright I am not well versed in color management, excuse my ineptness |
Maybe we can also get a look to the respective frog protocol. |
|
I'd wait for an impl from some other player (at least draft) to gain some practical insight As I've said here:
I read both fifo and color-mgmt from frog and in fifo I am unsure how it works, and in color-mgmt I don't understand half the techy terms :P ah.eto.bleh.mp4 |
We may ask to mantainers of feog-protocols for some advice on how to implement their protocols in Hyprland. |
|
@gnusenpai Now supports 1D and 1D+3D LUTs, 1DLUT doesn't need the patch for a PNG injection, instead it stores data from a .cal in a vec3 array. |
|
Too many messages for me to read the entire history, but I'm getting that there's two separate issues being discussed here:
So (1) seems to already be implemented in sway, KDE, GNOME. But (2) is blocked on color management protocol to be merged. It seems to me like (1) is the more important one; I don't really have any color managed apps, and if I understand correctly, anything color managed that supports Linux, or even Windows+Wine, already has to assume system-level color management isn't an option and instead has preferences to configure color space mapping within the program itself. Let me know if there's anything wrong with my little summary here. Also, should the two issues be split? They have very different scopes and timelines. |
|
Yes.
sway* *only with the vulkan renderer
Honestly, this one is more about the first one IMO, as color-mgmt is not merged so thats a non-issue atm |
|
feels like pain coming from mac m1 (asahi linux) |
|
For a lot of people having no way to manage colors or apply an ICC profile is a big pain point. |
that's the case for me on AMOLED, because i feel like i'm back to my old TN screen |
|
Ok, I want to remind you guys, there's no hurry There is still no image viewer that can properly communicate with the wayland color management engine. So from my point of view coding such an image viewer would be more important. |
Eye of Gnome, Eye of MATE and GIMP can all use the system-installed ICC-profile. See https://wiki.archlinux.org/title/ICC_profiles#Applications_that_support_ICC_profiles |
Yes, they can use the wayland color management, but they cannot show colors outside srgb. So it's the same as switching your screen to srgb mode. |
I think we are trying to focus more on the ability to apply an ICC profile in the compositor to the entire graphical environment, to correct the display's own color rendering to be more accurate. That's a separate issue (as I said above in my longer comment) from allowing apps to advertise a different color space on their buffer, for the compositor to be able to translate correctly. |
|
One more quick comment:
My main use case for this is an OLED laptop display - I have no way of setting it to an accurate srgb mode (or make any adjustments, really), so my only way of getting non-horrible colors would be to apply the vendor's ICC profile at the compositor level. |
|
I think getting an implementation to simply correct the sRGB coverage using an ICC-profile is enough for now and it seems to be pretty straightforward. Adding HDR-support is a whole another story like people already said and probably only a good idea once wlroots or other similar compositors release a reference implementation for something other than just Vulkan. |
Ah, ok, sorry for the "attack" then. I didn't think of that situation. But actually I also have a new laptop with a dci p3 screen that has no srgb mode. But what you can do: you can set the profile inside Firefox and image viewers that can do color management (use those). Desktop Icons etc. would be oversaturated then of course. Not sure just cutting away the extra colors by brute forcing srgb via the compositor is the best method right now. Afterall the screen can display colors outside of srgb and should. |
No worries! I do that in mpv for example by explicitly passing the profile when watching something on the laptop screen, but in the normal case I use both the laptop display and multiple external ones, so ideally this would be configured per output in the compositor - I don't think this would be possible on the application level. |
Yea you are right. System wide color managementhas so many benefits, or at least would have. System wide color management will also be great for apps that cannot do color management. I actually like tons of such apps, e.g. cutebrowser, but can't really use them with my wide gamut screens. I don't know how to make all those graphics devs make implement the wayland color management protocol into their tools. They are still just so suspicious of Wayland... we are sitting and waiting... |
This is the solution I was using to calibrate color on Hyprland, using vkbasalt Now sway has ICC profiles, I just use that. |
How do you do this in Hyprland; it uses a GL ES backend for rendering I thought? Or are you just applying it to individual games? |
You apply it to anything you want, browser, games, video player... It's not ideal and kind of a hassle to setup the first time, but it works. |
Description
Hey! I'd love to see color calibration/correction on Hyprland as well.
Specifically, a way to load an ICC profile per monitor to make normal SDR monitors display sRGB decently, making multi-monitor use suck less.
Plasma 6 seems to have implemented this, allowing correction for sRGB color space along with HDR/REC.2020.
While the proposed wayland protocol isn't merged, it does seem to be inching closer and closer as well.
This relates to #3423, which assumed lack of support for color management (with colord, specifically) was a bug.
I don't think so, but I'd sure love to have this!
The text was updated successfully, but these errors were encountered: