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
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
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
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?
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
This might be relevant here
4 Likes
hardware acccelerated color management
1 Like
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
-
Kwin Merge request to load monitor profile - backends/drm: support applying icc profiles with color management (!4471) Ā· Merge requests Ā· Plasma / KWin Ā· GitLab (limited to srgb and with limitations of application not knowing about display and its profile, applications need to output to srgb for now for this to work)
-
GIMP developerās questions and feedback on the wayland protocol in the MR - WIP: staging: add color management protocol (!14) Ā· Merge requests Ā· wayland / wayland-protocols Ā· GitLab
-
Another discussion with GIMP developer - color management protocol: Assuming sRGB for untagged surfaces (#17) Ā· Issues Ā· Sebastian Wick / wayland-protocols Ā· GitLab
-
Krita developers feedback and questions in the same MR - WIP: staging: add color management protocol (!14) Ā· Merge requests Ā· wayland / wayland-protocols Ā· GitLab and here - WIP: staging: add color management protocol (!14) Ā· Merge requests Ā· wayland / wayland-protocols Ā· GitLab
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.
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
@raghukamath I think we need to band together as a wider graphics community to let them know this is important to us.
3 Likes
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
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.
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
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. 
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 
).
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 (??? 
). 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? 
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:
- 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.
- 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
Hey @Jehan Thanks for responding and also for reading the protocol and giving feedback to the wayland devs (also thank you very much for working on GIMP)
I think you misunderstood our intent when we say banding together. From what I understand @paperdigits did not mean to go and spam the Merge request or bug reports. Some of us have filed bug reports for colour management and also for graphic tablet configuration Ui in wayland (which is another pain point often overlooked) And as far as I know we have not harassed or attacked anyone while doing that. Personally for me I agree I may have ranted on forums like this about the situation but not on issue tracker nor anywhere directly to the devs. I understand that merge request and issue trackers are not discussion forums.
Having said that I feel there is definitely a disconnect between the developers or compositors, wayland devs and us. I am not sure if they know exactly how we work. What do we need for having a colour managed artwork or a photo. I think @paperdigits suggested that we join hands together here on this forum or somewhere to discuss these things (not with the devs directly) and may be when we have some feedback present it to the wayland or any concerned devs.
I also do not see any bigger input between the graphical app developers. yes some developers like you and inkscape have met the wayland people like during sprints but as far as i know many have yet to go through the protocol thoroughly and respond like you or Dmitry from krita did. I might be wrong in this assumption may be some are going through it and formulating the response etc.
In any case when the inevitable X11 to wayland change happens many artists are going to write bug reports and at that time it will probably be a bit late to course correct any issue (if there is any) in the protocol etc.
2 Likes
Donāt worry, I didnāt really misunderstand and I did imagine what you are telling me right now. Nevertheless I just wanted to be double-clear. First because I also get a lot of attacks myself on GIMP bugtracker or elsewhere (and lately Iāve been getting exhausted by all the bad faith and mean people saying mean stuff) so I definitely know how others in similar situations can feel and how they could live this too (badly). Also that makes me more sensitive these days. 
Also because at some point I kinda took some distance from the pixls.us community because of a few of the people here which were virulent towards others. I know some of them have left since then, fortunately. But these kinds of things leave some traces, and thatās the reason why I donāt browse this forum as much these days (I near-only look when Iām mentioned now, so I get a notification).
For reference, what I was specifically referring to in my previous message is this comment, from a once prominent member of this community (and developer too), overtly calling to harass other people (in some jurisdiction, Iām not even sure that this comment is lawful, apart from being outright disgusting in any case):
And it was even liked by 6 people (so it cannot even be argued that it was an isolated thing).
This is the reason why, even though I did read this @paperdigitsā comment the way they/you meant (Iām not completely obtuse 
), I needed to be double-sure, especially when I read such a wording on this forum. Because I donāt and wonāt ever engage in any kind of harassing. I only believe in benevolent and welcoming communities.
It is true that not all software developers seem to have been engaging in active discussion. I would not blame them. With all the code I do, it took me months myself before I decided to really look more closely at it. I would imagine itās the same for other software devs. And these back and forth messages with Wayland devs also take me a lot of time (which I therefore canāt use on GIMP code).
Actually I wished that Wayland project had tried to more proactively get in touch with us and requested our inputs sooner and more often. I mean, when talking and specifying a color management protocol, itās a bit weird that they donāt ask the first and most obvious users (graphic software). Iāve been told that people doing X11 code used to more actively ask for our input back in the days (e.g. we had quite some contacts with GNOME Color management developer as I understand from GIMP developers which have been around longer than I have).
Anyway globally I think we agree.
Possibly. Thatās why I repeat what I said in the previous comment: if anyone has specific concerns, based on actual issues in the current protocol draft (donāt bombard me with fears without solid basis 
) which I have missed, please make me aware of them.
Or even if you disagree with some of the things I said above (about the sRGB for untagged surfaces and the need for a standard profiling API) by the way, feel free to tell me why.
Moreover people are free to explain me your specific use case and workflow, what you do (color-management wise, I mean) to work on a photo, or painting, or design, for print or for the screen, from A to Z. I do believe I know pretty well a lot of the most common workflows, but who knowsā¦ especially for people doing some very specific things or in less common specialized fields. Itās always interesting to broaden your horizon and see if I missed anything. Then we can find some generic enough solutions for all workflows to be possible. This knowledge would be usable not only for Wayland but also for GIMP. 
If we can make the whole protocol tight and robust now (and plan for next steps), then issues should be limited in the future. It might take a bit of time (more than we hoped for), but there is no reason we cannot make it go well too. 
3 Likes
Thanks for the response.
Yeah that is indeed a nasty comment. 
I assure you I donāt mean any harm to the devs nor I condone such behavior.
With regards to the issues on wayland the one that I see is colour profiling and calibration will be an issue. I get to know from this issue that displaycal works in wayland but I am not so sure, from what I read in the displaycal github discussion it needs a way to put color patches in the right spot so that the calibration device reads it correctly. And as far as I know application canāt do this under wayland by design. They donāt even know which display they appear on nor they can display window or patches of color (in case of displaycal) on desired location. This may have been solved now I do not know but we would need to be sure that calibration software is running smoothly otherwise there is no meaning to colour management. May be @eoyilmaz can shed some light on this.
Second issue is I do not know how I will be able to use my wide gamut Adobe RGB monitor if everything will be limited to srgb. And it seems that atleast on KDE kwin apps canāt know the monitor profile yet nor it is possible to use anything other than sRGB. Then until we have proper color management and support in the compositors we will be using apps under xwayland which adds another level of complexity.
I donāt want to brigade or shame or anything of that sort. I guess what Iām thinking of mostly manifests itself in āopen letters.ā Saying that there are a sizable number of people who need this feature. Thatās it.
It seems like @Jehan or Dimitri or other one off people are just being brushed off by the protocol. It is frustrating because I canāt see how this is going to work reliably. Things like āside effectsā or āweāre at odds with traditional color management peopleā absolutely does not inspire confidence.
On the other hand, there seem to be many wayland proponents who have declared it ready for me and take great offense that it is not ready for a very simple color managed photo editing workflow. Iāve had negative exchanges on several occasions.
If you think itāll work sometime in the future @Jehan then that is promising, but to me it still seems like it is years off.
Iām not sure what else to do besides keep talking about our use case and our needs. Trying to band together the larger community seems like a good idea. If you think it isnāt then we wonāt move forward with it.
Sorry this reply meandered a bit.
4 Likes
Can someone explain in simple terms what that means for the average Ubuntu user? Can we switch to Wayland install our icc profiles and live happily ever after?