Wayland color management

Software
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

540

I am running the Nvidia drivers, version 515.65.01 on openSUSE. I use KDE over Wayland with no problems.

1 Like
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?

542

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”.

1 Like
543

News:

2 Likes
544

From the release announcement:

  • 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…

1 Like
545

This just explains that work is still in progress. Release announcement also said that better support for HDR monitors prepared. The only thing is that color management for Wayland is progressing and far from being completely done. Even if work is quite slow, things seems to go in good direction. For correct and complete Wayland color management, we just have to wait again.

1 Like
546

I have to boggle a bit at what was said in the presentation.

HDR compositing is actually straightforward - you do the composition in the colorspace of the display. You do it that way because it is the displays colorspace that sets the capabilities and limitations. The means to be able to do this by knowing the colorspaces of the display and all the other elements you want to compose - i.e. their color profiles. To hear the presenter admit that they find the prospect difficult, seems perfectly consistent with the admission that they don’t know much about color profiles.

[ They have been successful in implementing compositing in linear light by following up on my observation that you can achieve this in any approximately linear additive 3 component colorspace by working in light linear components - something easily achievable when you know the color profile. i.e. you don’t have to transform to some other set of primaries to do this. ]

2 Likes
547

sRGB isn’t necessarily so limiting IF and only if you somehow allow negative values (such as passing float16 buffers). Sometimes that is referred to as scRGB, since that was one particular (Microsoft-specific) implementation of wide gamut ( scRGB - Wikipedia ) - sRGB color space but using floats to operate unbounded. Original scRGB wasn’t float-based, but I’ve seen references to float-based implementations as “scRGB”. Makes compositing in simple sRGB buffers from non-HDR/non-wide-gamut apps easier is my guess as to the rationale here. (Just need to linearize, no gamut conversion)

1 Like
548

I don’t think any gamut lost in transformation to sRGB can be recovered for a subsequent transformation to a higher-gamut destination, no? I’m a bit dense math-wise, how would working unbounded mitigate that?

549

Mere transformtion won’t lose information, it’s transformation that is followed by bounding that loses information in the bounding step.

Nothing is lost if you don’t clamp to (0,1) - out-of-sRGB-gamut values are represented by negative components. For example, an RGB triplet of (2,-0.5,-0.5) would encode a reddish value outside of the sRGB gamut. (I pulled those numbers out of my head, so that might even wind up outside of the realm of real colors.)

JPEG XR (*.jxr) file format support · Issue #6612 · Beep6581/RawTherapee · GitHub is one example of HDR/wide-gamut content encoded as linear sRGB - those files have negative values in them. Also a lot of EXR files appear to be linear sRGB (again, with negative values present to represent out-of-gamut colors)

3 Likes
550

This might be relevant here

4 Likes
551

hardware acccelerated color management

1 Like
552

While it is interesting I am suspecting this hype is for gaming side of HDR and not proffessional colour managed graphic application side of things. We are lucky that HDR is related to colour management. But as far as i see it is all about gaming in HDR not about colour accuracy and more about vibrant bright good looking images.

In addition to above link I would like to list some more interesting ones here

You would get an idea that wayland colour management with graphical app is really going to come late with all the need for new mechanism, implementation, and portals needed for apps to work correctly. Meanwhile distro people are in a hurry (understandably) to drop X11 saying that all is well, that will leave us with some broken workflow and issues as always happens with artists using linux.

553

Raghavendra Kamath @kamathraghavendra 1 week ago

Resolved 1 week ago by Xaver Hugl

@zamundaaa is there a way to donate money to kde-e.v and get you a calibration device for initial testing? May be a used colormunki smile. It works with displaycal.

I love volunteering our money, and this seems like an excellent use, eh @patdavid

@raghukamath did anything ever come of that?

1 Like
554

@raghukamath I think we need to band together as a wider graphics community to let them know this is important to us.

3 Likes
555

Hi @paperdigits,

Xaver told me that they will ask their employer to purchase it.

I definitely agree on this. Going through the discussion of Wayland it seems to me that there is a big disconnect between the wayland devs and graphics dev and graphic users.
I think we (users of GIMP krita inkscape scribus darktable) along with the developers of graphic applications should form a group which can give feedback, voice our opinion in this matter.
Most of the feedback when given by single person doesn’t have any impact. Users of these apps are scattered and may even not know about all this. And due to this situation, lack of feedback and noise from actual users would make it seem like we are very small group or a subset of users as evident by this reply by a gnome dev to Gimp developer.

I understand that the graphic application devs are really busy and have many other things on their plate and I do not know how we can bring our user community and devs together to have a seat on this table. May be a initiative on pixls or mailing list thread for all the apps to discuss or arrange a meeting etc.

2 Likes
556

This is true.

The only reason gaming HDR is going forward so quickly is due to Valve’s funding and additional push to both serve their interests and the ever growing portion of people using Linux for gaming, be it Steam Deck users or regular ones.

Plus the community is much larger, they are more vocal and random devs are more likely to play games than use a color managed setup.

557

Excellent. @Jehan is here occasionally as well.

We should decide where the best place to voice our concerns, what exactly we need, and how to organize the users.

3 Likes
558

I don’t really like the term “banding together”, which feels a lot like a mob going for lynching others (actually one of the reason why I never participated to this long thread is that I remember some others — developers none the less! — had been actively calling for doing exactly this in this thread; I cannot condone this).

Assaulting, insulting and trying to overtake a report by the numbers is never a good solution and is not acceptable nor decent, even less when many are contributing as volunteers or within a community.

For instance in one of the report mentioned above, I had to stop quickly someone who started to insult the Wayland project. This is not constructive and can only make things worse. Actually I definitely feel a lot of defensiveness in all Wayland-related reports, which leads to passive-agressiveness too from Wayland or desktop environments devs, probably comes from having a lot of attacks.

So please everyone: no “banding together” please, don’t go on reports trying to make everyone’s voices heard (thinking it will make people change their minds). All it might create is more defensiveness, possibly closing comments in reports and not reading more technical comments drowned in the middle of everyone else’s comments. Please. :pray:

But I do agree that it’s important to show that the graphics art are not a small edge use case. I did have this feeling of some of developers apparently taking us as a weird edge case not to take in consideration. Indeed here:

But also in some other reports and even one person on our IRC (presenting themselves as a Wayland dev, though I’m not sure how true it is, since I’ve never seem them actually in a report or maybe using a different nick?) explicitly told us this one day (something along the line of nobody caring about our weird use cases or something :confounded:).

Yet it’s just not true. Graphic software ecosystem is huge (that’s the main focus of Adobe which is one of the biggest software company in the world! How could it be small?), it’s pervasive in absolutely every other types of business in the world. Whatever you do, at some point, you need graphic. The only thing is that you see this part of their business less (you see “products”, not the graphic part in it) so it feels invisible. But that’s because it’s actually everywhere. Unlike what @hatsnp says 2 comments above, I am not even sure that the gaming community is larger than the graphic community. They are probably more vocal, and more visible. But maybe not even more numerous.
I think the Wayland project will have to understand this eventually.

Another thing that I felt a few times is this:

I felt this a lot in the “sRGB as default” topic when I was told repeatedly that some consider over-saturated displays as expected (??? :scream:). In the report I opened, they clearly stated as example to back up the claim:

Apparently the steam deck for example does increase the saturation artificially because it “looks better”.

It nearly reads that they would consider this a sign of quality which is crazy. I can actually see where this comes from, which is that TV and screen sellers have been selling their displays for years with this business speech where they’d just oversaturate all the screens and show to customers that the one with the most radioactive colors has to be (necessarily!) the best. Right? :person_facepalming:

I’m pretty sure I even saw articles (though I can’t find them again) about this very strange phenomenon which goes against dozens of years of studies and improvements in how we should manage display colors. Years of work destroyed by a few marketing stunts. I would hate that mediocrity wins over quality in this area. I mean, if we have proper color management anyway, if someone absolutely wants bright vivid screens instead, it will be extremely easy for them to do this anyway (just calibrate your display on wide gamut, but set up a display profile corresponding to a smaller gamut, and every colors are stretched towards saturated colors… I mean, if that’s your kick, sure, have fun). On the other hand, if we have this as a default, it will only be a huge annoyance to every people who actually need their display to have correct colors; or even the normal users who don’t want to have GUI colors screaming at them in every basic app.

All this being said, I’d like to finish on a positive note:

  • This is being worked on. A few months ago, we even set up a video meeting with a Wayland developer (and even had at least 1 more impromptu meeting after that), and we are working to have more because it is clearly important to us all (to the GIMP team of course, but also to all graphic users; I am not only GIMP maintainer, I literally work in the graphic industry).
  • Now that I’ve read the proposed protocol in detail, I think it’s globally fine and that it will improve and go ok in the end. What bothered me where mostly 2 things:
    1. The first is that they don’t want to make sRGB as a default space for untagged surfaces. Yet it feels like we are going to be able to make a compromise into at least mentioning this as a recommendation. What I want is that generic use case compositor developers don’t just go and see the “no-default” and decide “then it’s the output space” (then we’ll have various random app with saturated colors, constantly messing up with our eyes and perception of colors; or even title bars, window borders, task bars, menus, etc.). If sRGB is explicitly cited then at least these generic compositors will think twice. And I’m hopeful it should be enough to have GNOME, KDE or other generic desktop environment doing the right choice. Then if the Steam desk or some other game OS wants to have screaming colors at every corner, honestly I don’t care too much.
    2. The second issue was that I realized that this protocol doesn’t even provide API for the “calibration/profiling” side of things, which felt weird to me. I mean, it’s great that you can tag surfaces as being in a specific color space, but you also need to profile your output otherwise all the rest is useless. Now I won’t lie: at some point, I got extra-scared by one of the answers which was basically suggesting that people would have to set the output profiles… in each software preferences instead! Like you’d do this on each of your graphic software (redoing it each time you profile again), and all the other software would have utterly broken colors by default, with no way to do anything about it. This felt like an answer from outer space, from someone not understanding for a second the need. But then, we could diverge into more proper solutions, such as a portal. This suddenly got a lot more reasonable.

Therefore, even though I admit that I was scared more than once and that it doesn’t always feel like they understand the graphic industry and our needs (most of their examples are video games or people who expect vivid colors or whatnot; which makes me believe that @raghukamath is right about what their current and possibly main input is currently: the gaming industry), I think that things are getting better. It might still take some time. Even if this protocol gets merged and implemented in some environments, we’ll have to add one more step for it to be meaningful: the profiling step. Now it’s highly possible that it will be dealt quicklier, first with some per-desktop solution, before we get a standardized freedesktop portal (which is to be implemented by profiling software such as DisplayCAL). So it might be quicker than expected.

In any case, it’s not finished, but it’s not as bad as it might look from outside.

Who has read the protocol and has any more comment? Would there be something I missed and which might be a problem for us? As I said, I will talk more directly with the Wayland developers soon so now is the time if there is a specific problem with the current protocol and if I missed it.

Thanks all!

5 Likes