For my software, I got about 10 minutes into reading about how OSs do color management and just stopped. As a result, I do all the color management in my software, and assume the OS is just blatting that to the raw display, and it works fine in both Ubuntu and Windows.
Wayland posed a unique problem, though. Now this may be a bit dated, but when I implemented my dynamic display switching (display transform is switched and re-calculated when I move the window from one display to another), it suddenly stopped working on Ubuntu one day. Took me a bit to correlate that with the recent OS upgrade, which switched my default rendering library from X11 to Wayland. Turns out, Wayland version at the time didnāt provide a notification event/API to detect display switchingā¦
To be fair, itās a challenging interface to design; if you want the OS to do more, the image software needs to provide more information to support. A lot of software is left in the lurch at thatā¦
As things stand (and to be fair, Iām not tracking any recent changes, but Iād be surprised if thereās been any change in basic direction):
No way to calibrate (barring perhaps particular hacks that allow calibration curves on the main display - see Richard Hughes changes to allow colord to do something), since Wayland doesnāt believe in application software having access to the hardware.
No (easy) way for applications to know which display they are rendering to, so no way of applying the appropriate color conversion
- or -
a hacked up color management where the application source color space has to be transformed into some compromise RGB intermediate space that Wayland then color transforms onto the actual display.
No way to perform calibration or profiling, since Wayland doesnāt believe in application software having access to the hardware or display configuration.
My thoughts (from the view of someone who has a reasonable understanding of color management with regard to both color management tools and how applications use color management, as well as a grasp of how color management works on X11, OS X and MSWindows), on how color management could be incorporated in Wayland without burning it to the ground and starting again, are here.
AFAIK the basic issue is one of philosophy and resulting structure - the bright idea for Wayland and the big difference from X11 was to isolate the rendering code from frame buffer details, so that the application can do rendering without having to worry about where the pixels were going. This is a workable idea for many situations, but makes some assumptions that are simply wrong in the modern world. In the modern world RGB values are not interchangeable, since modern displays have different resolutions, different dynamic ranges, and different color spaces, so the rendering has to be specific to these details. You can then go down the path of imagining that the application can render to some intermediate frame buffer space and have Wayland re-render to the actual display, but itās a can of worms - the result is far from perfect and will have many visual warts, since there will be noticable fidelity loss in such a process. Bottom line is that maximum fidelity display requires rendering to the display details. The thing that a modern display architecture can bring, is to make this process as easy as possible, and make it so that the vast majority of non-critical applications can get good results on the full range of displays without having to do anything at all. A display architecture that makes no provision for how it is going to be configured (i.e. profiled and calibrated) is seriously incomplete, and woefully behind existing systems. The configuration issue also seems to be a design philosophy problem - Wayland is not intended to be a complete graphics system, just part of one. Leaving significant parts āout of scopeā is not a viable approach to enabling application development. Arriving at a situation where one of the most niche desktop environments (Wayland on Linux) has 6 different ways of configuring (or being unable to configure!) the display system and expecting CM applications to cater to all of them, is delusional.
Resolution: If you donāt know the DPI, should you render to a high resolution and assume that the display system (Wayland) will down sample to the actual resolution, since that will give the highest fidelity ? But given that there are some quite high res. displays out there now, what resolution is sufficient ? But rendering to a high resolution when you only have a medium or low resolution display is a huge waste of CPU/GPU power and display memory. And what about font hinting ? Rendering at high res, and down sampling throws away any advantage of font hinting for lower resolution displays.
(I donāt think Wayland is taking the approach - instead theyāve punctured their isolation between rendering and display to allow the renderer to aware of the display boundaries and DPI. Being an after thought, the mechanism is a bit ugly though. This at least is a win for other aspects of rendering that need to know which display they are on.)
Dynamic range: Do you render assuming HDR and assume that the display system will clip to maximum brightness ? But many HDR sources have hints and other information that may inform such a process, and allow it to be done in a much higher quality way, such as compressing highlights while maintaining color values (simply per channel clipping can result in very ugly wrong color blocks of pixels). What about non-HDR mapping source - what brightness should that be rendered to if you are rending as HDR in the assumption that the display process will clip it if the output is non HDR ? Too high and range will be clipped. Too low and the output may be too dim.
Color: What intermediate color space is chosen to render to ? If itās big, then the display system will have to clip colors that lie outside the display space, causing color posterization, and even resulting in false colors if it takes a per component clipping approach. If it was to compress the out of gamut colors, then it risks unnecessarily desaturating colors that are within the gamut of the display. If the intermediate colorspace is small, then the full gamut of the display canāt ever be used. You simply canāt create an optimal gamut mapping from one color space to another without simultaneously knowing both color spaces.
Alright, thanks for the lecture! (And I mean seriously, no sarcasm
I was naively assuming that you had some kind of basic info about the target, but certainly I didnāt think this throughā¦
1 Like
DanielLikesDT
(Daniel, who is an enthusiast for F/OSS and photography)
531
Hello Everyone,
with the new ubuntu version 22.04 out supporting Wayland on basically all nvidia cards this topic becomes more interesting for many users here, I assume. Can someone with a good understanding update / summarize the possibilities to calibrate a monitor / use color management in Wayland?
Couldnāt we simplify this if we used sort of a identity XYZ colorspace with floating precision (for HDR exposition information)? Given a source colorspace (whatever the compositor/app tells it is delivering) and given a destiny colorspace (what we want to see) and a display profile, couldnāt we do all sort of transformations?
Encoding is a solved problem - there are many choices that will work.
The point is (afaik) the very design of Wayland is based on keeping the (application) rendering code ignorant of display details such as its resolution, color behavior, dynamic range etc., so that the application can render without needing to be aware of the boundaries between the actual display surfaces, and that wayland can then change or move these boundaries without any input from the application. So at no point does any processing element have simultaneous knowledge of the source and destination gamut.
Fixing this means cutting across the fundamental design idea of wayland.
If I got it right, it is not impossible, but I understand the problem we are getting into, application would need to do color management itselfā¦ The application would only need origin and destiny colorspace and compositor would only need destiny colorspace and monitor profile. The app side get responsible for treating themes and images so they conform to destiny colorspaceā¦ Maybe DEs framework could take care of this?
I believe the intended path there is to expose that information to applications, i.e. information about the transforms towards the display in use. If a profiling app knows that, it should be able to profile just fine, shouldnāt it?
Iām not sure what you mean by āintended pathā or who you think has such a path. My suggestion on the Wayland list that color management needed to know about the underlying display characteristics and needed to be able to set the display calibration state was very vigorously rejected, including adding the āit would break securityā seal to make sure no-one went there again!
I understand someone is working on HDR support, but itās unclear to me whether color management is being tackled in a serious fashion as well, and whether the Wayland gatekeepers have back-tracked on their utter rejection of the whole idea.
Progress is glacial and it does seem that one major contributor is more focused on HDR than āclassic colormanagementā. The last checkbox in the roadmap I linked above and the entire last section are about profiling - I donāt see any categorical rejection. Which would be non-sensical, whatās the point of having display profiles if you prevent measuring the display.
DanielLikesDT
(Daniel, who is an enthusiast for F/OSS and photography)
539
This is not a direct reply. Instead I am using this thread to ask for support.
I am using ubuntu 22.04 running X11 because for some reason wayland is not an option. This is basically fine for me as everything runs stable and quick. But now ubuntu asks me to do a āpartial upgradeā of some components (mainly kernel stuff but also nvidia wayland drivers) which I find very strange.
Can anyone help what this is about? Is there already a good way to enable wayland with Nvidia? Is doing a partial upgrade a good thing? Any advice is appreciated.
Thanks. Daniel
I am running the Nvidia drivers, version 515.65.01 on openSUSE. I use KDE over Wayland with no problems.
1 Like
DanielLikesDT
(Daniel, who is an enthusiast for F/OSS and photography)
541
Problem with the partial upgrade solved ā¦ I just had to wait a day or so before actually doing the upgrade.
My main problem still remains: can we use wayland without losing color management completely? What is the lookout for the future for Linux user?
The same still as in my 2 months old comment, just above:
A few tests and HDR tasks done since then. So no you canāt use it without loosing color management, and it looks like youāll get it eventually - however just āeventuallyā.
Continued work on color management infrastructure:
In Weston 11, if you enable the tentative, experimental and WIP color
management option, Weston will not only blend in linear light, but
you can also set up a monitor ICC profile and Weston will do some
kind of color mapping from sRGB to that profile. Furthermore, you can
configure a monitor into HDR mode and deliver HDR characteristics from
weston.ini to the monitor, but Weston will not produce proper HDR
content yet, meaning the display is incorrect.
So, software has to deliver sRGB images to the compositor? Methinks you folk with high-gamut displays will be disappointedā¦
